Sie sind auf Seite 1von 26

Unidades Tecnolgicas de Santander.

Ingeniera de Telecomunicaciones. Docente: Ingeniero Rogerio Orlando Beltrn Castro.

PRCTICA 1 (Base de Datos Relacional ORACLE)


OBJETIVO Modelo Entidad Relacin TEORIA
BASE DE DATOS Cambios sociales han creado estructuras econmicas y sociales grandes y complejas. Estas organizaciones necesitan integrar el uso de su informacin para el planeamiento y control. Una organizacin como sistema transforma entradas de recursos, bienes, informacin y servicios para obtener un producto Desde hace mucho tiempo, los datos se han registrado en varios medios (papel, piedra, etc) con el fin de dejar constancia de un fenmeno o idea; a estos datos se les ha dado una interpretacin para convertirlos en informacin til. DATO Vs INFORMACIN Percepcin del mundo real que puede ser vista como una serie de fenmenos diferentes que algunas veces mantienen alguna relacin entre si Dato: Hechos conocidos que pueden registrarse y que tienen un significado implcito. Informacin: Cualquier aumento de conocimiento obtenido a travs de la interpretacin y uso de datos. UN SISTEMA DE INFORMACIN: Es un medio de ofrecer la informacin necesaria para una organizacin. Un sistema de informacin recibe la informacin, almacena sta, la procesa, y ofrece el acceso de esta, a los usuarios de la forma que ellos desean

BASE DE DATOS

Datos tiles

Recoleccin y Almacenamiento Bases de Datos

Conjunto de datos relacionados entre s.


Representa algn aspecto del mundo real, en ocasiones llamado Minimundo o Universo de Discurso. La informacin contenida en la BD debe representar un instante (estado) de una aplicacin determinada. Cada cambio en la Base de Datos es un reflejo de un evento (o secuencia) que ocurre en este ambiente. Toda BD se disea, construye y se puebla con datos para un propsito especfico. Est dirigida a un grupo de usuarios y tiene ciertas aplicaciones preconcebidas que interesan a dichos usuarios. Una BD tiene un fuente de la cual se derivan los datos, cierto grado de interaccin con los acontecimientos del mundo real y una serie de usuarios que se encuentra activamente interesado en su contenido.

Prctica 01, Base de Datos Relacional UTS.

1 de 26

Unidades Tecnolgicas de Santander.


Ingeniera de Telecomunicaciones. Docente: Ingeniero Rogerio Orlando Beltrn Castro.
DEFINICION FORMAL Es un conjunto exhaustivo (en su modelizacin del mundo real) de datos estructurados, fiables y homogneos, organizados independientemente de su utilizacin y de su implementacin en mquina, accesibles en tiempo real, compartibles por usuarios concurrentes que tienen necesidades de informacin diferentes y no predecibles en el tiempo. SISTEMA DE GESTION DE BASE DE DATOS Sistema de informacin computacional, cuyo objetivo principal es gestionar grandes cantidades de Informacin. Consta de 4 componentes:

Hardware Usuarios

Software
SGBD (Sistema de Gestin de Bases de Datos) Conjunto de programas que permite a los usuarios cear y mantener una base de datos.

Datos

Por lo tanto, el SGBD es un sistema de software de propsito general que facilita el proceso de definir, construir y manipular bases de datos para diversas aplicaciones. SOFTWARE SGBD (Sistema de Gestin de Bases de Datos)

HARDWARE reas de memoria secundaria en las cuales est localizada la BD (discos, cintas, etc.), junto con los dispositivos asociados (controladores, canales, etc.) USUARIOS Son los actores que laboran para mantener el entorno del sistema de BD Administrador de Bases De Datos (DBA) Persona que supervisa, Administra y controla los recursos: base de datos, SGBD y el SW con ste relacionado. Encargado de autorizar el acceso a la BD, coordinar y vigilar su empleo y adquirir los recursos necesarios en Hardware y Software, adems es el responsable por la seguridad y por el funcionamiento general del SGBD Diseadores de Bases de Datos se encargan de identificar los datos que se almacenaran en la BD y de elegir las estructuras apropiadas para representar y almacenar dichos datos. Usuarios Finales son las personas que necesitan tener acceso a la BD para consultarla, actualizarla y generar informes; la BD existe primordialmente para que ellos la usen. Tipos: Usuarios Autnomos y Usuarios Finales: Espordicos, Simples y Avanzados.

Prctica 01, Base de Datos Relacional UTS.

2 de 26

Unidades Tecnolgicas de Santander.


Ingeniera de Telecomunicaciones. Docente: Ingeniero Rogerio Orlando Beltrn Castro.
Analistas de Sistemas determinan los requerimientos de los usuarios y desarrollan especificaciones para transacciones programadas que satisfagan dichos requerimientos. Programadores de Aplicaciones Implementan esas especificaciones en forma de programas y luego prueban, depuran, documentan y mantienen esas transacciones programadas.

Arquitectura de un SGBD

Caractersticas deseables en un SGBD

1. 2. 3. 4. 5. 6. 7. 8.

Control de Redundancia Restriccin de accesos no autorizados Almacenamiento Persistente (SGBDOO) Inferencias de las BD mediante reglas de deduccin Suministro de mltiples interfaces con los usuarios Representacin de vnculos complejos entre datos Cumplimiento de las restricciones de Integridad Respaldo y recuperacin

Arquitectura de tres Esquemas. Las BD persiguen un objetivo general: Integrar toda la informacin del sistema para evitar redundancias sin que se pierdan por ello las distintas perspectivas que de ella tienen los usuarios. Las herramientas de software (SGBD) que se construyen para aplicar estas tcnicas deben asegurar la independencia, la integridad y la seguridad de los datos. Un SGBD permite la definicin de la BD a tres niveles de abstraccin: Interno, Conceptual y externo. La definicin de la base de datos en cada uno de estos niveles se denomina esquema. El Objetivo de la arquitectura de tres esquemas consiste en formar una separacin entre las aplicaciones del usuario y la BD fsica.

El Nivel Interno tiene un Esquema Interno, que describe la estructura fsica de almacenamiento de la BD. El Esquema Interno emplea un modelo fisico de datos y describe todos los detalles para su almacenamiento, as como los caminos de acceso para la BD. El Nivel Conceptual tiene un Esquema Conceptual, que describe la estructura de toda la BD para un grupo de usuarios.

Prctica 01, Base de Datos Relacional UTS.

3 de 26

Unidades Tecnolgicas de Santander.


Ingeniera de Telecomunicaciones. Docente: Ingeniero Rogerio Orlando Beltrn Castro.
El Esquema Conceptual oculta los detalles de las estructuras fsicas de almacenamiento y se concentra en describir entidades, tipos de datos, vnculos, operaciones de los usuarios y restricciones. El Nivel Externo o de vistas incluye varios Esquemas Externos o Vistas de Usuario. Cada esquema externo describe la parte de la BD que interesa a un grupo de usuarios determinado, y oculta a ese grupo el resto de la BD El proceso de transformar solicitudes y resultados de un nivel a otro se denomina correspondencia o transformacin (mapping).

Independencia de los Datos Se puede definir como la capacidad para modificar el esquema en un nivel del sistema de BD sin tener que modificar el nivel inmediato superior. Independencia Lgica. Es la capacidad de modificar el esquema conceptual sin tener que alterar los esquemas externos ni los programas de aplicacin Independencia Fsica. Es la capacidad de modificar el esquema interno sin tener que alterar el esquema conceptual o los externos Lenguajes del SGBD Lenguaje de definicin de Datos DDL Este lenguaje permite definir el esquema conceptual de una BD con un conjunto de condiciones expresadas en este. Lenguaje de definicin de Almacenamiento SDL Este lenguaje permite especificar el esquema interno. Lenguaje de definicin de Vistas VDL Este lenguaje permite especificar las vistas de usuario y sus correspondencias con el esquema conceptual. Lenguaje de manipulacin de Datos DML Este lenguaje permite realizar las operaciones de manipulacion de datos mas comunes como la obtencion, la insercion, la eliminacion y la modificacion.

Existen dos Tipos: Procedimental C, JAVA, PASCAL, C++, VB No Procedimental SQL, + Ineficientes + Fciles

Tipos de SGBD Modelo de Datos Relacional Representa una BD como una coleccin de tablas. Modelo de Datos de Red Representa los datos como tipos de registros y un tipo de vnculos llamado tipo de conjunto. Modelo Jerrquico Representa los datos como estructuras jerrquicas de rbol. Modelo OO Define la BD en trminos de objetos, sus propiedades y operaciones.

Ventajas de las BDs

1. 2. 3. 4. 5. 6. 7. 8.

Pueden ser aplicadas restricciones de seguridad Redundancia reducida Datos Incorrectos o duplicados Evitar Inconsistencia Datos compartidos por varias aplicaciones Pueden aplicarse restricciones de seguridad Integridad de los datos Datos Correctos Independencia de los datos Cambio de almacenamientos sin cambiar aplicaciones Informacin Actualizada

Prctica 01, Base de Datos Relacional UTS.

4 de 26

Unidades Tecnolgicas de Santander.


Ingeniera de Telecomunicaciones. Docente: Ingeniero Rogerio Orlando Beltrn Castro.
Desventajas de la BDs 1. 2. 3. 4. 5. Costos incrementales Mantenimiento complejo Vulnerabilidad: Naturaleza centralizada Proceso de recuperacin de fallas ms costoso Los costos de hardware, software y programadores son ms altos.

MODELADO DE DATOS

MODELAR consiste en definir un mundo abstracto y terico tal que las conclusiones que se puedan sacar de l coincidan con las manifestaciones aparentes del mundo real. Es un expresin utilizada para describir la organizacin lgica de los datos correspondiente a una determinada realidad.

Componentes Bsicos ESTRUCTURAS Entidades Una entidad es cualquier cosa que exista o sobre el cual se pueda pensar Atributos Un atributo es una propiedad asociada a un determinado tipo de entidad. Una entidad es descrita en trminos de los valores de sus atributos ESTRUCTURAS No existe un consenso general sobre que conceptos deben ser utilizados como base para definir la estructura de los datos En la prctica, no obstante, tres conceptos son difundidos largamente como componentes bsicos del modelado 1. 2. 3. Entidades Atributos Asociaciones

Asociaciones Una asociacin representa relaciones significativas entre entidades Las asociaciones establecen asignaciones entre entidades. Esta asignaciones pueden ser: Uno para Uno Muchos para Uno Uno para Muchos (N:1) (1:N) (M:N) (1:1)

Muchos para Muchos

MECANISMOS DE ABSTRACCIN Definicin de Abstraccin Es un proceso mental a travs del cual nos concentramos en los aspectos relevantes de un conjunto de objetos desconsiderando sus diferencias. Son usados como mecanismos bsicos de modelado por varios modelos llamados conceptuales. Los 3 mecanismos de abstraccin son: Clasificacin, Agregacin y Generalizacin

Prctica 01, Base de Datos Relacional UTS.

5 de 26

Unidades Tecnolgicas de Santander.


Ingeniera de Telecomunicaciones. Docente: Ingeniero Rogerio Orlando Beltrn Castro.
Clasificacin (es miembro de) Es un mecanismo de abstraccin usado para definir un concepto como una clase de objetos del mundo real caracterizados por propiedades comunes. La clasificacin se utiliza en el diseo de bases de datos para definir una categora (clase o tipo) a partir de sus ejemplares (datos almacenados en el esquema), las cuales tienen propiedades comunes por las que se caracterizan.

Agregacin (son parte de, es ejemplar de) Es un mecanismo de abstraccin a travs del cual una nueva clase de objetos es definida a partir de otras clases que representan sus partes componentes. La Clasificacin y Agregacin son las abstracciones bsicas para construir estructuras de datos.

Prctica 01, Base de Datos Relacional UTS.

6 de 26

Unidades Tecnolgicas de Santander.


Ingeniera de Telecomunicaciones. Docente: Ingeniero Rogerio Orlando Beltrn Castro.
Generalizacin (Es un) Es un mecanismo de abstraccin a travs del cual un conjunto de clases de objetos llamados categoras se relacionan con otra que es considerada una clase En una generalizacin, todas las propiedades (abstracciones) definidas para la clase genrica son heredadas automticamente por todas sus categoras.

TIPOS DE MODELOS

Utilizados para describir la estructura de una base de datos en un nivel de abstraccin independiente de los aspectos de implementacin.

Disponen de conceptos muy cercanos al modo en que la mayora de los usuarios percibe los datos. Se encuentran: 1. 2. 3. Entidad-Relacin Funcional Orientados a objetos

MODELOS LGICOS Utilizados para describir la estructura de una base de datos en un nivel de abstraccin mas prximo de las estructuras fsicas de almacenamiento de datos. Se Encuentran 1. 2. 3. 4. Relacional Deductivo Red Jerrquico

MODELOS FSICOS

Describen cmo se almacenan los datos en el computador: El formato de los registros

Prctica 01, Base de Datos Relacional UTS.

7 de 26

Unidades Tecnolgicas de Santander.


Ingeniera de Telecomunicaciones. Docente: Ingeniero Rogerio Orlando Beltrn Castro.
La estructura de los archivos (desordenados, Los mtodos de acceso utilizados (ndices, etc.). ordenados, etc.) y

MODELO ENTIDAD-RELACION

INTRODUCCIN Introducido por Peter Chen en 1976 El modelo entidad-relacin est formado por un conjunto de conceptos que permiten describir la realidad mediante un conjunto de representaciones grficas y lingsticas. Independiente de los aspectos de implementacin Posee una notacin grfica bastante concisa y de fcil comprensin: DIAGRAMA ER.

ENTIDAD Cualquier tipo de objeto o concepto sobre el que se recoge informacin: cosa, persona, concepto abstracto o suceso. Por ejemplo: casas, empleados, clientes, empresas, oficios, productos, conciertos, excursiones Notacin Grafica Se representan grficamente mediante rectngulos y con su nombre en el interior, ste slo puede aparecer una vez en el esquema conceptual.

Persona
Relacin Es una correspondencia o asociacin entre dos o ms entidades. Cada relacin tiene un nombre que describe su funcin Notacin Grafica Se representan grficamente mediante rombos y su nombre aparece en el interior.

Cardinalidad: Especifica el numero de vnculos en los que puede participar una entidad con otra. Cardinalidad de Relaciones Mxima. 4 Combinaciones (1:1), (N:1), (1:N), (M:N)

(1:1)

A A A A

R R R R

B B B B
8 de 26

(N:1)

(1:N)

(M:M)

Prctica 01, Base de Datos Relacional UTS.

Unidades Tecnolgicas de Santander.


Ingeniera de Telecomunicaciones. Docente: Ingeniero Rogerio Orlando Beltrn Castro.
Relacin Cardinalidad Mnima define la parcialidad (0)/totalidad (1) CARD_MIN(E,R) = 0 Participacin opcional (parcial)

A A
Atributo

R R

B B

CARD_MIN(E,R) = 1 Participacin obligatoria (total)

Es una caracterstica de inters o un hecho sobre una entidad o sobre una relacin. Los atributos representan las propiedades bsicas de las entidades y de las relaciones Notacin Grafica Se representan mediante bolitas que cuelgan de las entidades o relaciones a las que pertenecen.

Cardinalidad Mxima

Atributo Monovalorado = 1

*
Cardinalidad Mnima

Atributo Monovalorado > 1

Atributo Opcional = 0 Atributo Obligatorio > 0


Tipos de Atributos

Simples Tiene un solo componente, que no se puede dividir en partes mas pequeas. Compuestos Tiene varios componentes. Un grupo de atributos se representa mediante un atributo compuesto cuando tienen afinidad en cuanto a su significado, o en cuanto a su uso. Extensiones Jerarquas de Generalizacin GENERALIZACIN (enfatiza semejanzas) Dos o ms entidades comparten varios atributos y/o relaciones, de donde se deduce la existencia de una entidad de nivel superior (supertipo) que contiene los atributos y las relaciones comunes a todos los subtipos. ESPECIALIZACIN (enfatiza diferencias)

Prctica 01, Base de Datos Relacional UTS.

9 de 26

Unidades Tecnolgicas de Santander.


Ingeniera de Telecomunicaciones. Docente: Ingeniero Rogerio Orlando Beltrn Castro.
Una entidad tiene ciertos atributos y/o relaciones que tienen sentido para unos ejemplares pero no para otros, por lo que es conveniente definir uno o varios subtipos que contengan esos atributos y/o relaciones especficas, dejando en el supertipo los que son comunes. Tipos No Disyunto (O). Entidades que pueden ser miembros de mas de una subclase de la especializacin. Intercepcin <> O Disyunto (D). Una Entidad que pueden ser miembro mximo de una subclase de la especializacin. Intercepcin = O

Identificacin Un identificador de un tipo de Entidad E es un conjunto I de atributos de E que identifican de manera nica todas la instancias de E Todo atributo identificador de una entidad debe ser monovalorado y obligatorio.

Cdigo Persona

Cdigo Nombre
Direccin

Dependencia de Identificacin Existen entidades para las cuales no es posible definir un identificador con base nicamente en sus atributos; estas entidades dependen de la relacin con otras para que puedan ser identificadas. Entidades Fuertes Aquellas que pueden ser identificadas internamente con base a sus atributos. Entidades Dbiles Aquellas que requieren de un identificador externo total o parcial

Prctica 01, Base de Datos Relacional UTS.

10 de 26

Unidades Tecnolgicas de Santander.


Ingeniera de Telecomunicaciones. Docente: Ingeniero Rogerio Orlando Beltrn Castro.
Formas normales El anlisis de un sistema de base de datos consta de varias fases. Entre ellas, las principales son: Anlisis conceptual (o lgico, o relacional): es un anlisis abstracto de aquellas entidades que formarn la base de datos, as como las relaciones que establecen unas con otras y las restricciones que se aplican a cada una de ellas. El resultado de esta fase de anlisis se ve reflejado en algo llamado Modelo Conceptual o lgico, que es una descripcin de las entidades, atributos, relaciones y restricciones que compondrn la base de datos. Existen varios mtodos para realizar este anlisis: Entidad/Relacin, Mtrica, Merisse, UML, Yourdon, etc. El anlisis conceptual es abstracto, por lo que no depende de la base de datos que vayamos a utilizar ni del sistema en que se vaya a implementar la base de datos. Anlisis fsico: consta de un anlisis especfico teniendo en cuenta que base de datos se va a utilizar (Oracle, Sybase) y en qu arquitectura se va a implementar la base de datos (entornos multiusuario, plataformas NT) Las formas normales no son ms que tres reglas que se deben tener un cuenta dentro del Anlisis conceptual, utilizando concretamente Entidad/Relacin. El proceso de aplicar las tres formas normales se llama normalizacin. Un diseo de base de datos que no cumpla la primera forma normal no ser correcto. Cuantas ms formas normales cumpla el diseo de base de datos, significar que la base de datos est ms correctamente analizada. Primera forma normal: Identificar cada tabla con una clave primaria, y poder los datos en tablas separadas, de manera que los datos de cada tabla sean de un tipo similar (desde el punto de vista conceptual). Segunda forma normal: Sacar las columnas que slo dependen de una parte de la clave primaria a otra tabla. Tercera forma normal: Incluir en cada tabla slo datos que pertenezcan a la misma unidad lgica. Estas tres normas las vamos a explicar con un ejemplo: Dado esta definicin de la tabla FACTURA Columna Descripcin Cliente Direccin cliente Telfono cliente Importe Tipo A(50) A(20) A(30) A(10) N(12)

Tenemos la necesidad de identificar cada uno de los registros de esta tabla inequvocamente. No podemos utilizar la descripcin porque es posible que haya dos facturas con la misma descripcin (dos ventas de tornillos), tampoco el cliente porque un cliente suele tener ms de una factura. Ni tampoco el importe porque es normal tener varias facturas con el mismo importe. Para ello tenemos que definir una nueva columna que nos identifique cada una de las facturas Es posible (y bastante comn) que no encontremos una columna que sea capaz de identificar a al registro completo, por ello se puede definir ms de una columna dentro de la clave. En este caso es el conjunto de valores de las columna seleccionadas el que no se podr repetir. Esta columna (o conjunto de ellas) se denomina clave primaria (o primary key). Columna (*) Referencia Descripcin Cliente Direccin cliente Telfono cliente Importe Tipo A(10) A(50) A(20) A(30) A(10) N(12)

Las columnas marcadas con (*) son las que componen la clave primaria.

Prctica 01, Base de Datos Relacional UTS.

11 de 26

Unidades Tecnolgicas de Santander.


Ingeniera de Telecomunicaciones. Docente: Ingeniero Rogerio Orlando Beltrn Castro.
Ahora podemos estar seguros de que no habr dos facturas con la misma referencia por lo que podemos consultar la factura con referencia = FFR00123 y estaremos seguros de que slo habr una. El siguiente paso de la primera forma normal es poner los datos en tablas separadas, asegurndonos de que los datos de una tabla son datos correspondientes a aquello que almacena la tabla. En este ejemplo podemos ver cmo en la tabla FACTURA se estn guardando datos del cliente (direccin y telfono). En caso de que un cliente tenga ms de una factura, estaremos repitiendo la direccin y el telfono para cada una de las facturas. Esto se denomina redundancia de datos y produce tres efectos negativos: 1.- Mayor ocupacin en disco de los datos: el mismo dato se repite N veces. 2.- Posibles inconsistencias de datos: es posible que en una factura el telfono sea 555-111111 y en otra 555-111112 (cul de las dos es la correcta?) 3.- Problemas a la hora de cambiar datos repetidos: si un cliente cambia de direccin tenemos que modificar todas sus facturas para cambiarle el dato. Hay casos muy especiales en los que la redundancia de datos se recomienda por razones de rendimiento, aunque esta es la excepcin que confirma la regla. La solucin que da la primera forma normal a este problema es poner los datos en tablas separadas, dependiendo del origen de la informacin: la informacin perteneciente a factura ir en la tabla FACTURA y la informacin perteneciente a clientes ir en la tabla CLIENTE. Podemos encontrarnos con el problema que los clientes de pases distintos tiene una codificacin independiente, es decir, que pude existir el cliente 1 de Espaa y el cliente 1 de Francia a la vez. Un diseo que cumpla la primera forma normal podra ser: FACTURA Columna (*) Referencia Descripcin Cd pas Cd. Cliente Importe Tipo A(10) (*) Pas A(50) N(3) N(5) N(12) Descripcin Telfono Direccin A(20) A(50) A(10) A(50) CLIENTE Columna (*) Cd. Cliente Tipo N(5)

Tan slo se almacena el cdigo del cliente para cada una de sus facturas, y cuando se tenga que modificar la direccin, se modificar para todas las facturas de ese cliente. Con esto ya hemos hecho que se cumpla la 3 forma normal. Y para la tabla CLIENTE hemos tenido que aadir una nueva columna (Cdigo) que sirva para identificar a cada cliente con un cdigo. Dado que es posible que exista el mismo cdigo de cliente varias veces (una vez por cada pas), la columna Pas se ha tenido que incluir dentro de la clave primaria. La segunda forma normal nos dice que hay que sacar las columnas descriptivas que pertenezcan a la clave a otra tabla. La primera forma normal no nos dice que la tabla CLIENTE est mal definida, ya que todos los campos son datos relacionados con el cliente. Pero vemos que el Pas se repetir varias veces, volviendo a caer en el error de la redundancia. Para ello hay que crear una tabla aparte en la que se incluya el cdigo y la descripcin del pas, as a la hora de almacenar el pas en la tabla CLIENTE, slo se almacenar un cdigo y no su descripcin completa que ocupa mucho ms espacio. Adems a la hora de modificar una descripcin, slo habr que modificarla una vez.

Prctica 01, Base de Datos Relacional UTS.

12 de 26

Unidades Tecnolgicas de Santander.


Ingeniera de Telecomunicaciones. Docente: Ingeniero Rogerio Orlando Beltrn Castro.
El esquema en segunda forma normal quedara as:

FACTURA Columna (*) Referencia Descripcin Cd pas Cd. Cliente Importe Tipo A(10) A(50) N(3) N(5) N(12)

CLIENTE Columna (*) Cd pas (*) Cd cliente Descripcin Telfono Direccin Tipo A(2) N(5) A(50) A(10) A(50)

PAIS Columna (*) Cdigo Descripcin Tipo A(2) A(50)

En este punto, aunque slo hayamos aplicado la primera y segunda forma normal, ya tenemos la base de datos normalizada, ya que la tercera forma normal, se cumple en todas las tablas. Una forma de abreviar las formas normales es aplicando directamente la tercera, ya que si un esquema de base de datos cumple la tercera forma normal, automticamente est cumpliendo la primera y la segunda. Concepto de relacin: Se denomina relacin a todo aquellos vnculos que establecen unas tablas con otras, debidos a la aplicacin de las formas normales. En el ejemplo anterior, hemos creado relaciones entre unas tablas y otras desde el momento en que se separan los datos en ms de una tabla y se utiliza el cdigo como enlace entre unas y otras. Una relacin que hemos creado ha sido la que se establece entre la tabla CLIENTE y la tabla PAIS. Ambas tablas estn "intercomunicadas" por una de sus columnas: Cd Pais para CLIENTE y Cdigo para PAIS. Con esta relacin sabemos que todo campo Cd Pas de la tabla CLIENTE, tiene un registro equivalente en la tabla PAIS.

Relacin 1-1 La relacin 1-1 se establece cuando un registro de la tabla A tiene un solo registro relacionado en la tabla B. Esta relacin se podra establecer por ejemplo si creamos una tabla de Pagos de facturas. Suponiendo que una factura se paga de una sola vez, podemos definir la siguiente tabla para almacenar cuando se pagan las facturas: PAGOS_FACTURA Columna (*) Referencia Fecha pago Importe original % Recargo por retraso Importe final Tipo A(10) F N(12) N(3) N(10)

Podemos ver que la clave de esta tabla slo es la referencia de la factura. Esto es el dato relevante que nos dice que la relacin establecida entre una tabla y otra es 1-1. En la tabla PAGOS_FACTURA slo puede aparecer una vez cada referencia. Y el la tabla FACTURA slo puede aparecer una vez cada referencia. Desde el punto de vista conceptual, las relaciones 1-1 son necesarias y convenientes, para que se cumpla la tercera forma normal y que en cada tabla slo aparezcan datos correspondientes a su nivel lgico. Sin embargo, desde el punto de vista productivo y prctico, una relacin 1-1 se puede sustituir por ms registros en la tabla principal. Ya que un registro de A solo puede tener un registro en B, entonces las columnas de B pueden entrar a formas parte de A. En un anlisis ms prctico que exhaustivo podramos haber definido facturas de la siguiente manera:

Prctica 01, Base de Datos Relacional UTS.

13 de 26

Unidades Tecnolgicas de Santander.


Ingeniera de Telecomunicaciones. Docente: Ingeniero Rogerio Orlando Beltrn Castro.

FACTURA Columna (*) Referencia Descripcin Cd pas Cd. Cliente Importe Fecha pago %Recargo por retraso Importe final Tipo A(10) A(50) N(3) N(5) N(12) F N(3) N(10)

Relacin 1-N Una relacin 1-N es ms comn que 1-1, ya que, tanto desde el punto de vista conceptual, como desde el prctico, es necesario hacerlas. Volviendo al caso de los pagos de las facturas, podemos permitir que una factura se pague fraccionada, por ejemplo a 30, 60 y 90 das. Para este caso necesitamos que una referencia aparezca ms de una vez en la tabla de PAGOS, por lo que la clave primaria debe ser cambiada. Si la definicin de la tabla para una relacin 1-N hubiese sido la siguiente: PAGOS_FRACCIONADOS_FACTURA Columna (*) Referencia (*) Fecha pago Importe original % Recargo retraso Importe final por Tipo A(10) F N(12) N(3) N(10)

Entonces una referencia puede aparecer N veces, una por fecha distinta introducida. As podemos pagar una factura en las siguientes fracciones. PAGOS_FRACCIONADOS_FACTURA Referencia RF1102 Fecha 1/5/2000 Importe orig. 100.000 % Recargo 0% Importe final 100.000

RF1102 RF1102

10/6/2000 1/7/2000

100.000 100.000

10% 0%

110.000 100.000

Si la clave se hubiese definido slo como "Referencia", no podramos haber insertado ms de una fecha para la misma referencia. Sin embargo al definirla como "Referencia, Fecha", podemos introducir tantas parejas Referencia-Fecha como queramos. En nuestro ejemplo se ha pagado una factura fraccionada en tres pagos con un mes de diferencia entre ellos. Las relaciones 1-N tambin son llamadas normalmente maestro-detalle, donde el maestro es la tabla A (el 1 en la relacin) y el detalle es la tabla B (el N en la relacin). En nuestro ejemplo FACTURA es el maestro y PAGOS_FRACCIONADOS_FACTURA un detalle de FACTURA. Como norma general (lgicamente tiene sus excepciones) podemos decir que las columnas de la clave primaria de una tabla detalle tienen que ser las mismas que su maestro, aadiendo una (o varias) columnas a la clave (que marcan la diferencia entre el maestro y el detalle). Esta norma se cumple para nuestro ejemplo.

Prctica 01, Base de Datos Relacional UTS.

14 de 26

Unidades Tecnolgicas de Santander.


Ingeniera de Telecomunicaciones. Docente: Ingeniero Rogerio Orlando Beltrn Castro.
Las relaciones 1-N pueden ser optativas u obligatorias en ambos sentidos. Es decir, la tabla A puede estar obligada (o no) a tener registros relacionados en la tabla B, La tabla B puede estar obligada (o no) a tener registros relacionados en la tabla A. Una relacin tpica maestro-detalle, es optativa en sentido A-B pero obligatoria en sentido B-A. Significa que un maestro puede tener o no tener detalles, pero el detalle tiene que tener maestro obligatoriamente. El concepto de relacin es muy comn dentro de las bases de datos y est presente continuamente. Es preciso que se maneje con soltura a la hora de definir las claves primarias para cada una de las tablas. Claves forneas Una vez establecidas las relaciones entre las tablas, debemos estar seguros de que stas se cumplen siempre. En nuestro ejemplo anterior debemos de asegurarnos de que si hay un registro en PAGOS_FRACCIONADOS_FACTURA, debe existir la correspondiente factura, y que si sta es borrada, se haga lo mismo con sus pagos. Las bases de datos nos ofrecen esta posibilidad a travs de las claves forneas, que no son ms que un tipo de clave (como la primaria) que hace referencia a otras tablas. As la tabla PAGOS_FRACCIONADOS_FACTURA debe definir una clave que compruebe que siempre que se inserte un pago, exista la factura correspondiente (en la tabla FACTURA). Adems la base de datos se encarga de que si queremos borrar una factura (en la tabla FACTURA) no nos deje si existen pagos o bien borre todos los pagos correspondientes. Las claves forneas deben crearse sobre las tablas "hijo", o las tablas B en cada relacin, normalmente en los detalles. En nuestro ejemplo de las tablas FACTURA, CLIENTE y PAIS se deben aplicar las siguientes claves forneas (restricciones). CLIENTE: Comprobar que no se puede dar de alta un cliente a un pas que no exista. Adems no se podr borrar un pas siempre que existan clientes dados a ese pas. Clave fornea en CLIENTE( cod_pais ) hace referencia sobre PAIS( codigo ) FACTURA: Comprobar que no se puede dar de alta una factura a un cliente (pas, cliente) que no exista. Tambin se comprobar que no se pueda borrar un cliente que tenga facturas. Clave fornea en FACTURA(cod_pais,cod_cliente) hace referencia sobre CLIENTE(cod_pais,cod_cliente)

Se puede ver como la tabla PAIS no tiene ninguna clave fornea, ya que es "padre" o tabla A en todas las relaciones establecidas. Como norma general, cada relacin debe tener una clave fornea, y debe crearse sobre la tabla B de la relacin que representa. Normas bsicas de codificacin A la hora de definir una tabla hay que tener en cuenta ciertos aspectos en la codificacin: 1. 2. Slo deben ser numricas aquellas columnas que sean susceptibles de operaciones aritmticas. Es decir, un cdigo de factura, no debe ser numrico ya que nunca se van a sumar los cdigos. A la hora de codificar columnas alfanumricas, hay que tener en cuenta el sistema de ordenacin: Dada la siguiente lista de valores (de distinto tipo de dato): Alfanumrico '50' '41' '21' '1' '5' '20' '100' '13' '10' '2' Numrico 50 41 21 1 5 20 100 13 10 2

Prctica 01, Base de Datos Relacional UTS.

15 de 26

Unidades Tecnolgicas de Santander.


Ingeniera de Telecomunicaciones. Docente: Ingeniero Rogerio Orlando Beltrn Castro.
La lista ordenada ser la siguiente: Alfanumrico '1' '10' '100' '13' '2' '20' '21' '41' '5' '50' Numrico 1 2 5 10 13 20 21 41 50 100

El orden, como vemos, difiere mucho uno de otro. Sin embargo, dada la siguiente lista de valores (de distinto tipo de dato): Alfanumrico '050' '041' '021' '001' '005' '020' '100' '013' '010' '002' La lista ordenada ser la siguiente: Alfanumrico '001' '002' '005' '010' '013' '020' '021' '041' '050' '100' Numrico 1 2 5 10 13 20 21 41 50 100 Numrico 50 41 21 1 5 20 100 13 10 2

La diferencia est en que el mtodo alfanumrico ordena por posiciones, no por valores absolutos.

Prctica 01, Base de Datos Relacional UTS.

16 de 26

Unidades Tecnolgicas de Santander.


Ingeniera de Telecomunicaciones. Docente: Ingeniero Rogerio Orlando Beltrn Castro.
3. Las descripciones deben ser lo suficientemente largas como para almacenar el caso ms desfavorable para la columna, aunque tampoco se deben crear columnas demasiado largas.

Por ejemplo: para albergar nombre y apellidos nos valdr un 2 nombres de 10 caracteres cada uno, ms dos apellidos de 15 caracteres cada uno. Total 35 caracteres. Para darnos un margen de error podemos poner 40 caracteres. Ms de esta estimacin ser una longitud exagerada para el campo. 4. Codificacin compuesta o "claves inteligentes"

En bases de datos antiguas haba una prctica muy comn que consista en utilizar una sola columna con varios significados. El significado de la columna dependa de las posiciones de los dgitos. Por ejemplo, se podra definir la siguiente regla para almacenar las referencias de las facturas: Dgitos 1-2 Da de emisin. Dgitos 3-4 Mes de emisin. Dgitos 5-8 de factura. Ao de emisin. Dgitos 9-14 Cdigo de cliente. Dgitos 14-20 Nmero

As la referencia de la factura nmero 1, emitida a 23/8/1999, para el cliente cdigo 567 sera: 23081999000567000001 Esto no tiene ningn sentido, ya que queda mucho ms claro separar cada valor a su columna correspondiente, y si es necesario, definir todas las columnas necesarias como clave. Fecha Cliente Nmero

23/8/199 567 1 9 El origen de esta prctica viene de la poca de las bases de datos jerrquicas en las que la clave slo poda estar formada por un campo. Entonces era la nica manera de definir una clave compuesta. Estndar de nomenclatura de objetos Cuando un equipo de desarrollo da los primeros pasos en un proyecto informtico (de bases de datos o de cualquier otro tipo), lo primero que se debe definir es qu estndar de nomenclatura de objetos se va a utilizar. El objetivo principal de esta tarea es que el esquema sea consistente y homogneo, adems de permitir una memorizacin ms rpida de los objetos. El estndar debe responder a las siguientes preguntas: 1. 2. 3. 4. Los nombres de objetos van en maysculas o minsculas? Debo utilizar nombres lo ms descriptivos posibles o sin embargo nombres muy cortos? Puedo usar abreviaturas? Los nombres deben ir en singular o en plural?

El estndar debe ser un documento que tengan presente en todo momento el equipo de desarrollo, y siempre debe aplicarse salvo contadas excepciones. A continuacin daremos ciertas normas, que aunque no pretenden ser un estndar, si que son de recomendado uso: 1. Los nombres de objetos (tablas, ndices, claves primarias, claves forneas) deben ir en mayscula. Oracle interpreta por defecto todos los objetos en mayscula a no ser que se escriba su nombre entre comillas dobles: Nombres Factura, factura y FACTURA "FACTURA", "factura", "Factura" Interpretacin de Oracle Equivalente. Distintos objetos.

2. Los nombres de objetos deben ir en singular ya que el nombre representa a la entidad que almacena, y no las entidades que almacena. Una razn prctica es que con los nombres en minscula se ahorra 1 2 letras, lo cual no es despreciable. Entidad Facturas Facturas de proveedores Facturas que no han sido pagadas Nombre recomendado FACTURA FACTURA_PROVEEDOR FACTURA_PENDIENTE_PAGO

Prctica 01, Base de Datos Relacional UTS.

17 de 26

Unidades Tecnolgicas de Santander.


Ingeniera de Telecomunicaciones. Docente: Ingeniero Rogerio Orlando Beltrn Castro.
Los nombres a utilizar deben ser descriptivos, aunque no deben ser demasiado largos. Oracle admite hasta un mximo de 30 caracteres para los identificadores, aunque no es recomendable llegar hasta el lmite. Entidad Empresas pertenecientes al sector de la construccin Clientes que han tenido algn impago Proveedores que se suelen retrasar en sus entregas Facturas caducadas de empresas del sector de la construccin Nombre recomendado EMPRESA_CONSTRUCCION CLIENTE_MOROSO PROVEEDOR_LENTO, PROVEEDOR_RETRASO FACTURA_CONSTRUCCION_CADUCADA

4. Es recomendable utilizar abreviaturas, sobre todo si el nombre ms descriptivo es demasiado largo. Para nombres cortos no es necesario utilizar abreviaturas. Entidad Nombre recomendado

Empresas pertenecientes al sector de la construccin que han tenido alguna demolicin EMPRESA_CONSTR_DEMOLICION Clientes que han tenido algn impago CLIENTE_MOROSO

Proveedores que se suelen retrasar en sus entregas de empresas del sector de la PROVEEDOR_CONSTR_LENTO, construccin PROVEEDOR_CONSTR _RETRASO Facturas caducadas de empresas del sector de la construccin Almacn de productos terminados para empresas del sector de la construccin FACTURA_CONSTR_CADUCADA ALMACEN_ CONSTR _PROD_TERM

5. A la hora de nombrar tablas relacionadas entre si, es recomendable que el nombre empiece por el sufijo que representa la entidad principal. Entidad Facturas Lneas de Factura (detalle de FACTURA) Desglose de las lneas de factura (detalle de FACTURA_LINEA) Factura impagadas (Relacin 1-1 con FACTURA) 6. Se pueden establecer ciertas abreviaturas para los nombres de columnas: Columnas tpicas Cdigo de Descripcin de Referencia de Importe de Precio de Porcentaje de Unidades de Tipo de Nmero de Abreviatura C_xxx D_xxx REF_xxx IMP_xxx PRC_xxx PCT_xxx UDS_xxx TIP_xxx NUM_xxx Nombre recomendado FACTURA FACTURA_LINEA FACTURA_LINEA_DESGLOSE FACTURA_IMPAGADA, FACTURA_IMPAGO

Cualquiera que aparezca un elevado nmero de veces en el esquema 7. Los nombres de clave primaria deben ir precedidos del prefijo PK_ (Primary key), los de ndices por IND_, y los de clave fornea por FK_ (Foreing key). El nombre restante ser el de la propia tabla para las claves primarias, el de la tabla referenciada para las claves forneas y para los ndices una o dos palabras descriptivas que indiquen la razn por la que se crea ese ndice (si es posible).

Prctica 01, Base de Datos Relacional UTS.

18 de 26

Unidades Tecnolgicas de Santander.


Ingeniera de Telecomunicaciones. Docente: Ingeniero Rogerio Orlando Beltrn Castro.
PRACTICA La tiende don Jacobo nos ha pedido que realicemos el diseo de una base de datos para guardar la informacin correspondiente a las ventas que realiza, nos ha entregado la siguiente informacin 1. Nos entreg un documento en donde factura la venta

Factura Cliente Direccin PLU 100 222 302 310 250 364 214 158 192 120

Fecha FC00000023 Jos Antonio Daz Calle 23 # 2 -12 Nombre Clasificacin $ Unitario ARROZ Abarrotes $ 500.00 YUCA Verduras $ 600.00 ACEITE Abarrotes $ 800.00 JABON Aseo $ 1,000.00

25 DE ABRIL 2006 Cnyuge Mara Prez Gmez Telfono 636789 IVA Cant. Total 10% 5 $ 2,500.00 0% 2 $ 1,200.00 16% 4 $ 3,200.00 0% 4 $ 4,000.00 $ $ $ $ $ $ BASE $ 10,231.35 IVA $ 668.65 TOTAL $ 10,900.00

2.

Nos solicit almacenar la informacin correspondiente a los clientes:

Cdula. Nombre. Direccin. Telfono. Celular. Lugar de Nacimiento. Fecha de Nacimiento. 3. Adems no solicito que guardramos la informacin del cnyuge

Cdula. Nombre. Celular. Lugar de Nacimiento. Fecha de Nacimiento. 4. De los articulo desea guardar la siguiente informacin

PLU: Cdigo nico de identificacin. Barras. Nombre. Clasificacin (Abarrotes, Verduras, Cosmticos, Papelera, etc.) Costo: Precio de Compra. Venta: Precio de Venta. IVA. A partir de esta informacin comenzamos a realizar nuestro diseo.

Prctica 01, Base de Datos Relacional UTS.

19 de 26

Unidades Tecnolgicas de Santander.


Ingeniera de Telecomunicaciones. Docente: Ingeniero Rogerio Orlando Beltrn Castro.
Pasos para la realizacin de un Diseo de Base de Datos. 1. Identificar las Entidades principales.

Para nuestro caso identificamos que existen inicialmente las siguientes Entidades: Artculo Cliente 2. Realizar el modelo entidad relacin extendido, rompiendo todas las relaciones M-M, dejamos solo las relaciones 1M o 1-1

Primer Modelo.

Segundo Modelo.

Prctica 01, Base de Datos Relacional UTS.

20 de 26

Unidades Tecnolgicas de Santander.


Ingeniera de Telecomunicaciones. Docente: Ingeniero Rogerio Orlando Beltrn Castro.
Tercer Modelo.

3.

Identificar los campos propios de cada entidad.

Cuarto modelo

Prctica 01, Base de Datos Relacional UTS.

21 de 26

Unidades Tecnolgicas de Santander.


Ingeniera de Telecomunicaciones. Docente: Ingeniero Rogerio Orlando Beltrn Castro.
4. Identificar Campos Multivalores: Los campos multivalores se identifican porque son descripciones o clasificaciones que le dan caractersticas a la entidad por lo general son de tipo cadena o alfanumrico. Existen de dos tipos: Finitos: Son aquellos que al momento de la definicin del modelo relacional conocemos con exactitud cuntas variaciones pueden tener, por ejemplo el campo estado en donde solamente puede tener valores de activos e inactivos. Este campo queda como campo. Infinitos: Son aquellos que al momento de la definicin del modelo relacional no conocemos con exactitud cuntas variaciones pueden tener, por ejemplo el campo color el cual no sabemos con precisin cuantas variaciones de colores sean necesarios, por lo cual debemos crear una entidad que los agrupen, por lo general, esta entidad tiene dos campos un cdigo de tipo numrico y un nombre de tipo alfanumrico, se realiza la relacin con la entidad de origen, se elimina el campo de donde surgi la entidad multivalorada y se realiza el anlisis relacional.

En el ejercicio los campos multivalorados son: a. Cliente: Sexo. Lugar de Nacimiento. b. Conyuge Sexo. Lugar de Nacimiento. Quinto Modelo d. c. Artculo. Clasificacin. IVA Factura_Articulo. IVA

Prctica 01, Base de Datos Relacional UTS.

22 de 26

Unidades Tecnolgicas de Santander.


Ingeniera de Telecomunicaciones. Docente: Ingeniero Rogerio Orlando Beltrn Castro.
5. Identificar Llaves primarias Entidades Padres o Fuertes: Las entidades fuertes o padres son aquellas que su existencia no dependa de la existencia de otras, es decir no tiene relaciones 1:M que le lleguen como M. Adems hay otras entidades que tienen dependencia de otras pero su campo primario es de fcil identificacin, recuerde que un campo primario es nico y obligatorio y que est compuesto por un campo o por la combinacin de varios.

Sexto Modelo

Prctica 01, Base de Datos Relacional UTS.

23 de 26

Unidades Tecnolgicas de Santander.


Ingeniera de Telecomunicaciones. Docente: Ingeniero Rogerio Orlando Beltrn Castro.
6. Identificar Llave secundarias: Las llaves forneas, en las relaciones 1:M, son los campos heredados por las entidades de origen 1 a las entidades de destino M, o de las entidades que tienen relacin 1:1 la entidad fuerte le hereda a la entidad dbil. Los campos heredados son los campos que conforman la llave primaria. En las relaciones 1:1 la llave fornea, tambin se vuelve primaria para tener un modelo fuertemente relacional.

Sptimo Modelo

Prctica 01, Base de Datos Relacional UTS.

24 de 26

Unidades Tecnolgicas de Santander.


Ingeniera de Telecomunicaciones. Docente: Ingeniero Rogerio Orlando Beltrn Castro.
7. Identificar Llave primarias en entidades hijas de relaciones M-M: El anlisis de las llaves primarias de las entidades hijas de relaciones M-M, la primera opcin es identificar como llave primaria la combinacin de las llaves forneas de sus padres si esta combinacin es nica y obligatoria formara la llave primaria de lo contrario se crea un campo adicional con un valor consecutivo y este campo es primario.

Octavo Modelo

Prctica 01, Base de Datos Relacional UTS.

25 de 26

Unidades Tecnolgicas de Santander.


Ingeniera de Telecomunicaciones. Docente: Ingeniero Rogerio Orlando Beltrn Castro.

Primer Taller de Base de Datos


Pasos para la realizacin de un Diseo de Base de Datos. 1. 2. 3. 4. 5. 6. 7. Identificar las Entidades principales. Realizar el modelo entidad relacin extendido, rompiendo todas las relaciones M-M, dejamos sol relaciones 1-M o 1-1 Identificar los campos propios de cada entidad. Identificar Campos Multivaluados. Identificar Llaves primarias. Identificar Llave secundarias Identificar Llave Primarias

1. Construir un diagrama Entidad - Relacin para una compaa de seguros de autos (placa, color, ao, serial) con un conjunto de clientes (DNI, nombre, Direccin, Telfono, Ciudad), cada uno de los cuales es propietario de un nmero de autos. Cada auto tiene un nmero de accidentes (Cdigo, Direccin, Fecha) registrados. 2. Disponemos de los siguientes elementos de informacin: TARJETAS DE CREDITO (identificadas por un nmero y que pueden ser de diferente tipo), PERSONAS PROPIETARIAS de esas tarjetas (de las que conocemos DNI, domicilio y telfono), CUENTAS CORRIENTES (con un nmero, un saldo y una fecha de apertura). Las siguientes restricciones semnticas han de satisfacerse: Cada persona puede tener ms de una tarjeta. Cada tarjeta pertenece a una persona. Cada tarjeta lleva asociada una nica cuenta. Podemos cargar ms de una tarjeta a un cuenta determinada. Cada cuenta pertenece a una sola persona. Una persona puede tener ms de una cuenta.
3. La cadena de Video-Clubs Glob-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 su ttulo, nacionalidad, productora y fecha (p.e., Quo Vadis, Estados Unidos, M.G.M., 1955). 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 cliente (DNI, nombre, direccin, telfono). Se desea almacenar la fecha de comienzo del alquiler y la de devolucin. Cada socio puede tener alquilados, en un momento dado, 4 ejemplares como mximo. Un socio tiene que ser avalado por otro socio que responda de l en caso de tener problemas en el alquiler.

Prctica 01, Base de Datos Relacional UTS.

26 de 26