Katya

Base de Datos II 1
UNIVERSIDAD SALESIANA DE BOLIVIA
CARRERA INGENIERA DE SISTEMAS
DOSSIER
BASE DE DATOS II
Quinto Semestre
Lic. Katya Maricela Prez Martnez

Base de Datos II 2
INDICE
1.1. Sistemas de bases de datos y sus aplicaciones.............................................................5
1.2. Objetivos de los sistemas de bases de datos................................................................5
1.2.1. Redundancia e inconsistencia de datos.............................................................5
1.2.2. Dificultad para tener acceso a los datos............................................................5
1.2.3. Aislamiento de los datos...................................................................................6
1.2.4. Anomalas del acceso concurrente....................................................................6
1.2.5. Problemas de seguridad....................................................................................6
1.2.6. Problemas de integridad....................................................................................6
1.3. Sistemas de bases de datos...........................................................................................6
1.4. Los distintitos niveles de abstraccin de una base de datos........................................9
1.4.1. Abstraccin de la informacin......................................................................9
1.5. Usuarios y administradores de la base de datos.......................................................10
1.6. Componentes de los sistemas de bases de datos........................................................11
1.6.1. Estructura general del sistema.........................................................................11
1.7. El modelo entidad-relacin........................................................................................12
1.7.1. CONJUNTO DE RELACIONES CON DERIVACIN MLTIPLE............15
1.8. Diseo de un esquema de base datos.........................................................................17
1.9. REDUCCIN DE DIAGRAMAS E-R A TABLAS......................................................17
1.9.1. GENERALIZACIN Y ESPECIALIZACIN..............................................18
1.9.2. AGREGACIN..............................................................................................19
1.10. El modelo relacional..............................................................................................20
1.10.1. Relaciones...................................................................................................20
1.10.2. Propiedades de las relaciones......................................................................22
1.10.3. Tipos de relaciones......................................................................................22
1.10.4. Claves..........................................................................................................23
1.10.5. Esquema de una base de datos relacional....................................................25
1.11. Diseo de esquemas relacionales de bases de datos..............................................26
1.11.1. LA NORMALIZACION.............................................................................26
1.11.2. DEPENDENCIAS FUNCIONALES..........................................................26
EJERCICIOS........................................................................................................................32
II. LENGUAJES DE CONSULTAS FORMALES...........................................................35
2.1. Los Lenguajes de Consulta a Bases de Datos Relacionales...................................35
2.2. lgebra Relacional.................................................................................................35
2.2.1. Seleccin ()...................................................................................................35
Base de Datos II 3
2.2.2. Proyeccin ():...............................................................................................36

2.2.3. Producto Cartesiano (r1 x r2):.........................................................................36
2.2.4. Unin de Conjuntos (r1 r2):........................................................................37
2.2.5. Diferencia de Conjuntos (r1 - r2):...................................................................37
2.2.6. Interseccin de Conjuntos (r1 r2):...............................................................38
2.2.7. Unin Join o Producto Theta (r1 P r2):.......................................................38
2.2.8. Producto Natural (r1 x r2):......................................................................39
2.3. CALCULO RELACIONAL...................................................................................39

2.3.1. CALCULO RELACIONAL DE TUPLAS.........................................................39
2.3.2. CALCULO RELACIONAL DE DOMINIOS....................................................41
2.4. LENGUAJE QBE (Query By Example)................................................................42
2.4.1. MANIPULACION DE DATOS EN QBE..........................................................43
III. LENGUAJES DE CONSULTA COMERCIALES....................................................47
3.1. INTRODUCCION..................................................................................................47
3.2. LENGUAJES DE CONSULTA.............................................................................47
3.3. LENGUAJE DE CONSULTA SQL.......................................................................47
3.4. DDL (Data Description Language)........................................................................47
3.5. DML (Data Manipulation Language )....................................................................48
3.6. DCL (Data Control Language )..............................................................................48
3.7. Caractersticas del lenguaje DML..........................................................................48
3.8. Cmo se crea una sentencia SQL en SQLSERVER?...........................................49
3.8.1. Mensajes que emite al ejecutar una consulta......................................................50
3.9. CONSULTAS SIMPLES........................................................................................50
3.9.1. ESTRUCTURA BASICA...................................................................................50
1.1.1. LA CLAUSULA SELECT..............................................................................51
1.1.2. LA CLAUSULA WHERE..............................................................................52
3.10. CONDICIN DE BSQUEDA. TEST DE PERTENENCIA BETWEEN.......54
3.11. CONDICIN DE BSQUEDA: TEST DE PERTENENCIA A UN
CONJUNTO (IN).............................................................................................................54
3.12. CONDICIN DE BSQUEDA: TEST DE VALOR NULO (IS NULL)..........54
3.13. CONDICIN DE BSQUEDA: TEST DE CORRESPONDENCIA CON
PATRN LIKE.................................................................................................................55
3.14. CONDICIONES DE BSQUEDA COMPUESTAS.........................................55
3.15. CONSULTAS MULTITABLA...........................................................................56
3.16. UNIN, INTERSECCIN, EXCEPCIN........................................................56
Base de Datos II 4
3.16.1. LA UNION DE TABLAS UNION.................................................................56

3.16.2. LA DIFERENCIA EXCEPT...........................................................................57
3.16.3. LA INTERSECCIN INTERSECT...............................................................57
3.17. EL PRODUCTO CARTESIANO CROSS JOIN................................................58
3.18. LA COMPOSICIN INTERNA INNER JOIN.................................................58
3.19. ACTUALIZACION DE DATOS MEDIANTE INSERT, UPDATE Y DELETE
59
3.19.1. Insertar datos creando una nueva tabla..........................................................59
3.19.2. INSERTAR EN UNA TABLA EXISTENTE INSERT INTO.......................60
3.19.3. Insercin de varias filas...................................................................................61
3.20. UPDATE- MODIFICAR DATOS ALMACENADOS.......................................61
3.21. ELIMINAR FILAS DELETE..........................................................................62
3.22. OPERADORES AGREGADOS.........................................................................63
3.22.1. AGREGACIN POR GRUPOS.....................................................................63
3.23. HAVING.............................................................................................................65
Ejemplo Having...............................................................................................................65
3.24. SUBCONSULTAS..............................................................................................65
3.25. Tipos de Datos en SQL.......................................................................................66
3.26. CREATE INDEX................................................................................................67
Ejemplo Create Index.......................................................................................................67
3.27. CREATE VIEW..................................................................................................67
3.28. DROP TABLE, DROP INDEX, DROP VIEW..................................................68
IV. SEGURIDAD E INTEGRIDAD.............................................................................69
V. BASE DE DATOS ORIENTADA AL OBJETO (OODBMS)......................................77
VI. BASE DE DATOS DISTRIBUIDAS.......................................................................110
VII. DATAWAREHOUSE...............................................................................................133
Evolucin del Depsito......................................................................................................156
Base de Datos II 5
I. INTRODUCCION A LAS
BASES DE DATOS
I.1. Sistemas de bases de datos y sus aplicaciones.
Los sistemas de base de datos se disean para manejar grandes
cantidades de informacin, la manipulacin de los datos involucra tanto
la definicin de estructuras para el almacenamiento de la informacin
como la provisin de mecanismos para la manipulacin de la
informacin, adems un sistema de base de datos debe de tener
implementados mecanismos de seguridad que garanticen la integridad
de la informacin, a pesar de cadas del sistema o intentos de accesos
no autorizados.
Un objetivo principal de un sistema de base de datos es proporcionar

a los usuarios finales una visin abstracta de los datos, esto se logra
escondiendo ciertos detalles de cmo se almacenan y mantienen los
datos.
I.2. Objetivos de los sistemas de bases de datos.

Los objetivos principales de un sistema de base de datos es disminuir los
siguientes aspectos:
I.2.1. Redundancia e inconsistencia de datos.

Puesto que los archivos que mantienen almacenada la informacin
son creados por diferentes tipos de programas de aplicacin existe la
posibilidad de que si no se controla detalladamente el almacenamiento,
se pueda originar un duplicado de informacin, es decir que la misma
informacin sea ms de una vez en un dispositivo de almacenamiento.
Esto aumenta los costos de almacenamiento y acceso a los datos,
adems de que puede originar la inconsistencia de los datos - es decir
diversas copias de un mismo dato no concuerdan entre si -, por ejemplo:
que se actualiza la direccin de un cliente en un archivo y que en otros
archivos permanezca la anterior.
I.2.2. Dificultad para tener acceso a los datos.

Un sistema de base de datos debe contemplar un entorno de datos
que le facilite al usuario el manejo de los mismos. Supngase un banco,
y que uno de los gerentes necesita averiguar los nombres de todos los
clientes que viven dentro del cdigo postal 78733 de la ciudad. El
gerente pide al departamento de procesamiento de datos que genere la
lista correspondiente. Puesto que esta situacin no fue prevista en el
Base de Datos II 6
diseo del sistema, no existe ninguna aplicacin de consulta que

permita este tipo de solicitud, esto ocasiona una deficiencia del sistema.
I.2.3. Aislamiento de los datos.

Puesto que los datos estn repartidos en varios archivos, y estos no
pueden tener diferentes formatos, es difcil escribir nuevos programas
de aplicacin para obtener los datos apropiados.
I.2.4. Anomalas del acceso concurrente.

Para mejorar el funcionamiento global del sistema y obtener un tiempo
de respuesta ms rpido, muchos sistemas permiten que mltiples
usuarios actualicen los datos simultneamente. En un entorno as la
interaccin de actualizaciones concurrentes puede dar por resultado
datos inconsistentes. Para prevenir esta posibilidad debe mantenerse
alguna forma de supervisin en el sistema.
I.2.5. Problemas de seguridad.

La informacin de toda empresa es importante, aunque unos datos lo
son ms que otros, por tal motivo se debe considerar el control de
acceso a los mismos, no todos los usuarios pueden visualizar alguna
informacin, por tal motivo para que un sistema de base de datos sea
confiable debe mantener un grado de seguridad que garantice la
autentificacin y proteccin de los datos. En un banco por ejemplo, el
personal de nminas slo necesita ver la parte de la base de datos que
tiene informacin acerca de los distintos empleados del banco y no a
otro tipo de informacin.
I.2.6. Problemas de integridad.

Los valores de datos almacenados en la base de datos deben satisfacer
cierto tipo de restricciones de consistencia. Estas restricciones se hacen
cumplir en el sistema aadiendo cdigos apropiados en los diversos
programas de aplicacin.
I.3. Sistemas de bases de datos

Los inconvenientes de los sistemas de ficheros se pueden atribuir a dos
factores:
La definicin de los datos se encuentra codificada dentro de los

programas de aplicacin, en lugar de estar almacenada aparte y de
forma independiente.
No hay control sobre el acceso y la manipulacin de los datos ms all

de lo impuesto por los programas de aplicacin.
Base de Datos II 7
Para trabajar de un modo ms efectivo, surgieron las bases de datos y

los sistemas de gestin de bases de datos (SGBD).
Una base de datos es un conjunto de datos almacenados entre los que

existen relaciones lgicas y ha sido diseada para satisfacer los
requerimientos de informacin de una empresa u organizacin. En una
base de datos, adems de los datos, tambin se almacena su
descripcin.
La base de datos es un gran almacn de datos que se define una sola

vez y que se utiliza al mismo tiempo por muchos departamentos y
usuarios. En lugar de trabajar con ficheros desconectados e informacin
redundante, todos los datos se integran con una mnima cantidad de
duplicidad. La base de datos no pertenece a un departamento, se
comparte por toda la organizacin. Adems, la base de datos no slo
contiene los datos de la organizacin, tambin almacena una
descripcin de dichos datos. Esta descripcin es lo que se denomina
metadatos, se almacena en el diccionario de datos o catlogo y es lo
que permite que exista independencia de datos lgica-fsica.
El modelo seguido con los sistemas de bases de datos, en donde se

separa la definicin de los datos de los programas de aplicacin, es muy
similar al modelo que se sigue en la actualidad para el desarrollo de
programas, en donde se da una definicin interna de un objeto y una
definicin externa separada. Los usuarios del objeto slo ven la
definicin externa y no se deben preocupar de cmo se define
internamente el objeto y cmo funciona. Una ventaja de este modelo,
conocido como abstraccin de datos, es que se puede cambiar la
definicin interna de un objeto sin afectar a sus usuarios ya que la
definicin externa no se ve alterada. Del mismo modo, los sistemas de
bases de datos separan la definicin de la estructura de los datos, de los
programas de aplicacin y almacenan esta definicin en la base de
datos. Si se aaden nuevas estructuras de datos o se modifican las ya
existentes, los programas de aplicacin no se ven afectados ya que no
dependen directamente de aquello que se ha modificado.
El sistema de gestin de la base de datos (SGBD) es una

aplicacin que permite a los usuarios definir, crear y mantener la base
de datos, y proporciona acceso controlado a la misma.
El SGBD es la aplicacin que interacciona con los usuarios de los

programas de aplicacin y la base de datos. En general, un SGBD
proporciona los siguientes servicios:
Permite la definicin de la base de datos mediante el lenguaje de

definicin de datos. Este lenguaje permite especificar la estructura
Base de Datos II 8
y el tipo de los datos, as como las restricciones sobre los datos.

Todo esto se almacenar en la base de datos.
Permite la insercin, actualizacin, eliminacin y consulta de datos

mediante el lenguaje de manejo de datos. El hecho de disponer de
un lenguaje para realizar consultas reduce el problema de los
sistemas de ficheros, en los que el usuario tiene que trabajar con
un conjunto fijo de consultas, o bien, dispone de un gran nmero
de programas de aplicacin costosos de gestionar.
Hay dos tipos de lenguajes de manejo de datos: los procedurales y

los no procedurales. Estos dos tipos se distinguen por el modo en que
acceden a los datos. Los lenguajes procedurales manipulan la base de
datos registro a registro, mientras que los no procedurales operan sobre
conjuntos de registros. En los lenguajes procedurales se especifica qu
operaciones se deben realizar para obtener los datos resultados,
mientras que en los lenguajes no procedurales se especifica qu datos
deben obtenerse sin decir cmo hacerlo. El lenguaje no procedural ms
utilizado es el SQL (Structured Query Language) que, de hecho, es un
estndar y es el lenguaje de los SGBD relacionales.
Proporciona un acceso controlado a la base de datos mediante:
o un sistema de seguridad, de modo que los usuarios no

autorizados no puedan acceder a la base de datos;
o un sistema de integridad que mantiene la integridad y la

consistencia de los datos;
o un sistema de control de concurrencia que permite el acceso

compartido a la base de datos;
o un sistema de control de recuperacin que restablece la

base de datos despus de que se produzca un fallo del
hardware o del software;
o un diccionario de datos o catlogo accesible por el usuario

que contiene la descripcin de los datos de la base de datos.
A diferencia de los sistemas de ficheros, el SGBD gestiona la estructura

fsica de los datos y su almacenamiento. Con esta funcionalidad, el
SGBD se convierte en una herramienta de gran utilidad. Sin embargo,
desde el punto de vista del usuario, se podra discutir que los SGBD han
hecho las cosas ms complicadas, ya que ahora los usuarios ven ms
datos de los que realmente quieren o necesitan, puesto que ven la base
de datos completa. Conscientes de este problema, los SGBD
Base de Datos II 9
proporcionan un mecanismo de vistas que permite que cada usuario

tenga su propia vista o visin de la base de datos. El lenguaje de
definicin de datos permite definir vistas como subconjuntos de la base
de datos.
Las vistas, adems de reducir la complejidad permitiendo que cada

usuario vea slo la parte de la base de datos que necesita, tienen otras
ventajas:
Las vistas proporcionan un nivel de seguridad, ya que permiten

excluir datos para que ciertos usuarios no los vean.
Las vistas proporcionan un mecanismo para que los usuarios vean

los datos en el formato que deseen.
Una vista representa una imagen consistente y permanente de la

base de datos, incluso si la base de datos cambia su estructura.
Todos los SGBD no presentan la misma funcionalidad, depende de cada

producto. En general, los grandes SGBD multiusuario ofrecen todas las
funciones que se acaban de citar y muchas ms. Los sistemas modernos
son conjuntos de programas extremadamente complejos y sofisticados,
con millones de lneas de cdigo y con una documentacin consistente
en varios volmenes. Lo que se pretende es proporcionar un sistema
que permita gestionar cualquier tipo de requisitos y que tenga un 100%
de fiabilidad ante cualquier fallo hardware o software. Los SGBD estn
en continua evolucin, tratando de satisfacer los requerimientos de todo
tipo de usuarios. Por ejemplo, muchas aplicaciones de hoy en da
necesitan almacenar imgenes, vdeo, sonido, etc. Para satisfacer a este
mercado, los SGBD deben cambiar. Conforme vaya pasando el tiempo
irn surgiendo nuevos requisitos, por lo que los SGBD nunca
permanecern estticos.
I.4. Los distintitos niveles de abstraccin de una

base de datos.
I.4.1. Abstraccin de la informacin.
Una base de datos es en esencia una coleccin de archivos
relacionados entre s, de la cual los usuarios pueden extraer informacin
sin considerar las fronteras de los archivos.
Existen diferentes niveles de abstraccin para simplificar la interaccin

de los usuarios con el sistema; Interno, conceptual y externo,
especficamente el de almacenamiento fsico, el del usuario y el del
programador.
Base de Datos II 10
Nivel fsico.
Es la representacin del nivel ms bajo de abstraccin, en ste se

describe en detalle la forma en como de almacenan los datos en los
dispositivos de almacenamiento(por ejemplo, mediante sealadores o
ndices para el acceso aleatorio a los datos).
Nivel conceptual.
El siguiente nivel ms alto de abstraccin, describe que datos son

almacenados realmente en la base de datos y las relaciones que existen
entre los mismos, describe la base de datos completa en trminos de su
estructura de diseo. El nivel conceptual de abstraccin lo usan los
administradores de bases de datos, quienes deben decidir qu
informacin se va a guardar en la base de datos.
Nivel de visin.
Nivel ms alto de abstraccin, es lo que el usuario final puede visualizar

del sistema terminado, describe slo una parte de la base de datos al
usuario acreditado para verla. El sistema puede proporcionar muchas
visiones para la misma base de datos.
I.5. Usuarios y administradores de la base de datos.

Administrador de Bases de Datos
Denominado por sus siglas como: DBA, Database Administrator.
Es la persona encargada y que tiene el control total sobre el sistema de

base de datos, sus funciones principales son:
Definicin de esquema
Es el esquema original de la base de datos se crea escribiendo un

conjunto de definiciones que son traducidas por el compilador de DDL a
un conjunto de tablas que son almacenadas permanentemente en el
diccionario de datos.
Definicin de la estructura de almacenamiento del mtodo de

acceso
Estructuras de almacenamiento y de acceso adecuados se crean

escribiendo un conjunto de definiciones que son traducidas por e
compilador del lenguaje de almacenamiento y definicin de datos.
Base de Datos II 11
Concesin de autorizacin para el acceso a los datos
Permite al administrador de la base de datos regular las partes de las

bases de datos que van a ser accedidas por varios usuarios.
Especificacin de lmitantes de integridad
Es una serie de restricciones que se encuentran almacenados en una

estructura especial del sistema que es consultada por el gestor de base
de datos cada vez que se realice una actualizacin al sistema.
Usuarios de las bases de datos.
Podemos definir a los usuarios como toda persona que tenga todo tipo
de contacto con el sistema de base de datos desde que este se disea,
elabora, termina y se usa.
Los usuarios que accesan una base de datos pueden clasificarse como:
Programadores de aplicaciones
Los profesionales en computacin que interactuan con el sistema por

medio de llamadas en DML (Lenguaje de Manipulacin de Datos), las
cuales estn incorporadas en un programa escrito en un lenguaje de
programacin (Por ejemplo, COBOL, PL/I, Pascal, C, etc.)
Usuarios sofisticados
Los usuarios sofisticados interactan con el sistema sin escribir

programas. En cambio escriben sus preguntas en un lenguaje de
consultas de base de datos.
Usuarios especializados
Algunos usuarios sofisticados escriben aplicaciones de base de datos

especializadas que no encajan en el marco tradicional de procesamiento
de datos.
Usuarios ingenuos
Los usuarios no sofisticados interactan con el sistema invocando a uno

de los programas de aplicacin permanentes que se han escrito
anteriormente en el sistema de base de datos, podemos mencionar al
usuario ingenuo como el usuario final que utiliza el sistema de base de
datos sin saber nada del diseo interno del mismo por ejemplo: un
cajero.
Base de Datos II 12
I.6. Componentes de los sistemas de bases de datos
I.6.1. Estructura general del sistema.

Un sistema de base de datos se encuentra dividido en mdulos cada uno
de los cuales controla una parte de la responsabilidad total de sistema.
En la mayora de los casos, el sistema operativo proporciona nicamente
los servicios ms bsicos y el sistema de la base de datos debe partir de
esa base y controlar adems el manejo correcto de los datos. As el
diseo de un sistema de base de datos debe incluir la interfaz entre el
sistema de base de datos y el sistema operativo.
Los componentes funcionales de un sistema de base de datos, son:
Gestor de archivos.
Gestiona la asignacin de espacio en la memoria del disco y de las
estructuras de datos usadas para representar informacin.
Manejador de base de datos.

Sirve de interfaz entre los datos y los programas de aplicacin.
Procesador de consultas.
Traduce las proposiciones en lenguajes de consulta a instrucciones de
bajo nivel. Adems convierte la solicitud del usuario en una forma ms
eficiente.
Compilador de DDL.
Convierte las proposiciones DDL en un conjunto de tablas que contienen
metadatos, estas se almacenan en el diccionario de datos.
Archivo de datos.
En l se encuentran almacenados fsicamente los datos de una
organizacin.
Diccionario de datos.
Contiene la informacin referente a la estructura de la base de datos.
ndices.
Permiten un rpido acceso a registros que contienen valores especficos.
Una forma grfica de representar los componentes antes mencionados y
la relacin que existe entre ellos sera la siguiente.
I.7. El modelo entidad-relacin

El modelo entidad-relacin es el modelo conceptual ms utilizado para el
diseo conceptual de bases de datos. Fue introducido por Peter Chen en
1976. El modelo entidad-relacin est formado por un conjunto de
Base de Datos II 13
conceptos que permiten describir la realidad mediante un conjunto de

representaciones grficas y lingsticas.
Figura 1: Conceptos del modelo entidad-relacin extendido.
Entidad
Cualquier tipo de objeto o concepto sobre el que se recoge informacin:
cosa, persona, concepto abstracto o suceso. Por ejemplo: coches, casas,
empleados, clientes, empresas, oficios, diseos de productos, conciertos,
excursiones, etc. Las entidades se representan grficamente mediante
rectngulos y su nombre aparece en el interior. Un nombre de entidad
slo puede aparecer una vez en el esquema conceptual.
Hay dos tipos de entidades: fuertes y dbiles. Una entidad dbil es una
entidad cuya existencia depende de la existencia de otra entidad. Una
entidad fuerte es una entidad que no es dbil.
Relacin (interrelacin)
Es una correspondencia o asociacin entre dos o ms entidades. Cada
relacin tiene un nombre que describe su funcin. Las relaciones se
representan grficamente mediante rombos y su nombre aparece en el
interior.
Base de Datos II 14
Las entidades que estn involucradas en una determinada relacin se

denominan entidades participantes. El nmero de participantes en una
relacin es lo que se denomina grado de la relacin. Por lo tanto, una
relacin en la que participan dos entidades es una relacin binaria; si
son tres las entidades participantes, la relacin es ternaria; etc.
Una relacin recursiva es una relacin donde la misma entidad

participa ms de una vez en la relacin con distintos papeles. El nombre
de estos papeles es importante para determinar la funcin de cada
participacin.
La cardinalidad con la que una entidad participa en una relacin

especifica el nmero mnimo y el nmero mximo de correspondencias
en las que puede tomar parte cada ocurrencia de dicha entidad. La
participacin de una entidad en una relacin es obligatoria (total) si la
existencia de cada una de sus ocurrencias requiere la existencia de, al
menos, una ocurrencia de la otra entidad participante. Si no, la
participacin es opcional (parcial). Las reglas que definen la cardinalidad
de las relaciones son las reglas de negocio.
A veces, surgen problemas cuando se est diseado un esquema

conceptual. Estos problemas, denominados trampas, suelen producirse
a causa de una mala interpretacin en el significado de alguna relacin,
por lo que es importante comprobar que el esquema conceptual carece
de dichas trampas. En general, para encontrar las trampas, hay que
asegurarse de que se entiende completamente el significado de cada
relacin. Si no se entienden las relaciones, se puede crear un esquema
que no represente fielmente la realidad.
Una de las trampas que pueden encontrarse ocurre cuando el esquema

representa una relacin entre entidades, pero el camino entre algunas
de sus ocurrencias es ambiguo. El modo de resolverla es reestructurando
el esquema para representar la asociacin entre las entidades
correctamente.
Otra de las trampas sucede cuando un esquema sugiere la existencia de

una relacin entre entidades, pero el camino entre una y otra no existe
para algunas de sus ocurrencias. En este caso, se produce una prdida
de informacin que se puede subsanar introduciendo la relacin que
sugera el esquema y que no estaba representada.
Atributo
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. Toda la informacin extensiva es portada
por los atributos.
Base de Datos II 15
Cada atributo tiene un conjunto de valores asociados denominado

dominio.
El dominio define todos los valores posibles que puede tomar un

atributo. Puede haber varios atributos definidos sobre un mismo
dominio.
Los atributos pueden ser simples o compuestos. Un atributo simple es

un atributo que tiene un solo componente, que no se puede dividir en
partes ms pequeas que tengan un significado propio. Un atributo
compuesto es un atributo con varios componentes, cada uno con un
significado por s mismo. Un grupo de atributos se representa mediante
un atributo compuesto cuando tienen afinidad en cuanto a su
significado, o en cuanto a su uso. Un atributo compuesto se representa
grficamente mediante un valo.
Los atributos tambin pueden clasificarse en monovalentes o

polivalentes. Un atributo monovalente es aquel que tiene un solo
valor para cada ocurrencia de la entidad o relacin a la que pertenece.
Un atributo polivalente es aquel que tiene varios valores para cada
ocurrencia de la entidad o relacin a la que pertenece. A estos atributos
tambin se les denomina multivaluados, y pueden tener un nmero
mximo y un nmero mnimo de valores. La cardinalidad de un
atributo indica el nmero mnimo y el nmero mximo de valores que
puede tomar para cada ocurrencia de la entidad o relacin a la que
pertenece. El valor por omisin es .
Por ltimo, los atributos pueden ser derivados. Un atributo derivado

es aquel que representa un valor que se puede obtener a partir del valor
de uno o varios atributos, que no necesariamente deben pertenecer a la
misma entidad o relacin.
Identificador
Un identificador de una entidad es un atributo o conjunto de atributos
que determina de modo nico cada ocurrencia de esa entidad. Un
identificador de una entidad debe cumplir dos condiciones:
1. No pueden existir dos ocurrencias de la entidad con el mismo valor

del identificador.
2. Si se omite cualquier atributo del identificador, la condicin

anterior deja de cumplirse.
Toda entidad tiene al menos un identificador y puede tener varios

identificadores alternativos. Las relaciones no tienen identificadores.
Base de Datos II 16
Jerarqua de generalizacin
Una entidad E es una generalizacin de un grupo de entidades E , E ,
... E , si cada ocurrencia de cada una de esas entidades es tambin una

ocurrencia de E. Todas las propiedades de la entidad genrica E son
heredadas por las subentidades.
Cada jerarqua es total o parcial, y exclusiva o superpuesta. Una

jerarqua es total si cada ocurrencia de la entidad genrica corresponde
al menos con una ocurrencia de alguna subentidad. Es parcial si existe
alguna ocurrencia de la entidad genrica que no corresponde con
ninguna ocurrencia de ninguna subentidad. Una jerarqua es exclusiva si
cada ocurrencia de la entidad genrica corresponde, como mucho, con
una ocurrencia de una sola de las subentidades. Es superpuesta si existe
alguna ocurrencia de la entidad genrica que corresponde a ocurrencias
de dos o ms subentidades diferentes.
Un subconjunto es un caso particular de generalizacin con una sola

entidad como subentidad. Un subconjunto siempre es una jerarqua
parcial y exclusiva.
I.7.1. CONJUNTO DE RELACIONES CON DERIVACIN MLTIPLE

Puede darse el caso de que una relacin sea binaria: es decir, que asocie
a mas de dos conjunto de entidades. En estos casos la nica variacin
para representar el modelo consiste en que se establecer
CARDINALIDAD para cada pareja de conjuntos de entidades.
En un almacn se lleva el control de los artculos que son vendidos y

facturados. El objetivo primordial adems de mantener la informacin
almacenada consiste en proceso de facturacin. Los datos que se
registran: RFC del cliente, nombre del cliente, domicilio, clave del
artculo, descripcin, costo unitario, numero de factura, fecha, cantidad
de artculos vendidos (de cada uno).
Base de Datos II 17
I.8. Diseo de un esquema de base datos.

Diseo de un esquema de bases de datos Entidad - Relacin.
Para un diseo de un esquema de base de datos hay cuatro fases:
Especificacin de requisitos del usuario.- Consiste en obtener las

necesidades de datos de los usuarios de la base de datos, esto es,
sonsacarle al usuario toda la informacin que se desea plasmar en la
base de datos. Esta es la fase que se dar en el examen.
Diseo conceptual (Entidad - Relacin).
Especificacin de requisitos funcionales.- Vamos a definir las

operaciones que se harn sobre la base de datos (operaciones
permitidas sobre la base de datos)
Especificacin de requisitos funcionales.- Primero se procede a

realizar el diseo lgico, que consiste en adaptar el diseo conceptual
Base de Datos II 18
al sistema de gestin de la base de datos, y a continuacin se realiza el

diseo fsico, que consiste en dar todas las caractersticas de
almacenamiento de la base de datos.
I.9. REDUCCIN DE DIAGRAMAS E-R A TABLAS.

Con el objeto de observar instancias de las bases de datos, los
diagramas E-R se convierten en tablas, Se obtiene una tabla por cada
conjunto de entidades o de relaciones.
Existen reglas bien definidas para la conversin de los elementos de un

diagrama E-R a tablas:
a) ENTIDADES FUERTES.- Se crea una tabla con una columna para

cada atributo del conjunto de entidades.
b) ENTIDADES DBILES.- Se crea una tabla que contiene una columna

para los atributos que forman la llave primaria de la entidad fuerte a la
que se encuentra subordinada.
c) RELACIN.- se crea una tabla que contiene una columna para cada
atributo descriptivo de la relacin y para cada atributo que conforma la
llave primaria de las entidades que estn relacionadas.
Convierta a tablas y muestre instancias donde pueda observarse la

CARDINALIDAD del diagrama E-R en el caso del vdeo club.
Base de Datos II 19
I.9.1. GENERALIZACIN Y ESPECIALIZACIN

Son procesos que tienen por objeto la fusin o descomposicin de
atributos que conforman entidades. La generalizacin persigue la
minimizaron de redundancia en la base de datos de tal manera que
puedan ocultarse las diferencias entre entidades formando as entidades
comunes.
Base de Datos II 20
La especializacin en el proceso inverso de la generalizacin; tiene por

objeto reducir el espacio de almacenamiento requerido por la base de
datos en el medio fsico. Trae como consecuencia una redundancia
necesaria, pero suprime el gasto de espacio en el medio secundario para
aquellas columnas que no almacenan informacin por entidades bien
determinadas.
I.9.2. AGREGACIN
Es una tcnica que permite representar a un bloque de entidades
relacionadas como si fueran un solo conjunto de entidades; permitiendo
as la relacin entre conjunto de relaciones.
I.10.El modelo relacional

El modelo relacional representa la segunda generacin de los SGBD. En
l, todos los datos estn estructurados a nivel lgico como tablas
formadas por filas y columnas, aunque a nivel fsico pueden tener una
estructura completamente distinta. Un punto fuerte del modelo
relacional es la sencillez de su estructura lgica. Pero detrs de esa
simple estructura hay un fundamento terico importante del que
carecen los SGBD de la primera generacin, lo que constituye otro punto
a su favor.
Dada la popularidad del modelo relacional, muchos sistemas de la

primera generacin se han modificado para proporcionar una interfaz de
usuario relacional, con independencia del modelo lgico que soportan
(de red o jerrquico). Por ejemplo, el sistema de red IDMS ha
evolucionado a IDMS/R e IDMS/SQL, ofreciendo una visin relacional de
los datos.
Base de Datos II 21
En los ltimos aos, se han propuesto algunas extensiones al modelo

relacional para capturar mejor el significado de los datos, para disponer
de los conceptos de la orientacin a objetos y para disponer de
capacidad deductiva.
El modelo relacional, como todo modelo de datos, tiene que ver con tres
aspectos de los datos:
Estructura de datos.
Integridad de datos.
Manejo de datos.
I.10.1. Relaciones
Definiciones informales
Una relacin es una tabla con columnas y filas. Un SGBD slo necesita
que el usuario pueda percibir la base de datos como un conjunto de
tablas. Esta percepcin slo se aplica a la estructura lgica de la base de
datos (en el nivel externo y conceptual de la arquitectura de tres niveles
ANSI-SPARC). No se aplica a la estructura fsica de la base de datos, que
se puede implementar con distintas estructuras de almacenamiento.
Un atributo es el nombre de una columna de una relacin. En el modelo

relacional, las relaciones se utilizan para almacenar informacin sobre
los objetos que se representan en la base de datos. Una relacin se
representa grficamente como una tabla bidimensional en la que las
filas corresponden a registros individuales y las columnas corresponden
a los campos o atributos de esos registros. Los atributos pueden
aparecer en la relacin en cualquier orden.
Por ejemplo, la informacin de las oficinas de la empresa inmobiliaria se

representa mediante la relacin OFICINA, que tiene columnas para los
atributos Onum (nmero de oficina), Calle, Area, Poblacin, Telfono y Fax. La
informacin sobre la plantilla se representa mediante la relacin
PLANTILLA, que tiene columnas para los atributos Enum (nmero de
empleado), Nombre, Apellido, Direccin, Telfono, Puesto, Fecha_nac,
Salario, DNI, Onum (nmero de la oficina a la que pertenece el
empleado). A continuacin se muestra una instancia de la relacin
OFICINA y una instancia de la relacin PLANTILLA. Como se puede
observar, cada columna contiene valores de un solo atributo. Por
ejemplo, la columna Onum slo contiene nmeros de oficinas que
existen.
Un dominio es el conjunto de valores legales de uno o varios atributos.

Los dominios constituyen una poderosa caracterstica del modelo
Base de Datos II 22
relacional. Cada atributo de una base de datos relacional se define sobre

un dominio, pudiendo haber varios atributos definidos sobre el mismo
dominio. La siguiente tabla muestra los dominios de los atributos de la
relacin OFICINA. Ntese que en esta relacin hay dos atributos que
estn definidos sobre el mismo dominio, Telfono y Fax.
Una tupla es una fila de una relacin. Los elementos de una relacin son
las tuplas o filas de la tabla. En la relacin OFICINA, cada tupla tiene seis
valores, uno para cada atributo. Las tuplas de una relacin no siguen
ningn orden.
El grado de una relacin es el nmero de atributos que contiene. La

relacin OFICINA es de grado seis porque tiene seis atributos. Esto
quiere decir que cada fila de la tabla es una tupla con seis valores. El
grado de una relacin no cambia con frecuencia.
La cardinalidad de una relacin es el nmero de tuplas que contiene. Ya

que en las relaciones se van insertando y borrando tuplas a menudo, la
cardinalidad de las mismas vara constantemente.
Una base de datos relacional es un conjunto de relaciones normalizadas.
Definiciones formales
Una relacin definida sobre un conjunto de dominios
consta de:
Cabecera: conjunto fijo de pares atributo:dominio
donde cada atributo corresponde a un nico dominio
y todos los son distintos, es decir, no hay dos

atributos que se llamen igual. El grado de la relacin es .
Cuerpo: conjunto variable de tuplas. Cada tupla es un conjunto de

pares atributo:valor:
con , donde es la cardinalidad de la relacin . En
cada par se tiene que .

Base de Datos II 23
La relacin OFICINA tiene la siguiente cabecera:

{ (Onum:NUM_OFICINA), (Calle:NOM_CALLE), (Area:NOM_AREA),
(Poblacin:NOM_POBLACION), (Telfono:NUM_TEL_FAX),
(Fax:NUM_TEL_FAX)}.
Siendo la siguiente una de sus tuplas:
{ (Onum:O5), (Calle:Enmedio,8), (Area:Centro),
(Poblacin:Castelln), (Telfono:964 201 240), (Fax:964 201 340)}.
Este conjunto de pares no est ordenado, por lo que esta tupla y la
siguiente, son la misma:
{ (Calle:Enmedio,8), (Fax:964 201 340), (Poblacin:Castelln),
(Onum:O5), (Telfono:964 201 240), (Area:Centro)}
Grficamente se suelen representar las relaciones mediante tablas. Los
nombres de las columnas corresponden a los nombres de los atributos y
las filas son cada una de las tuplas de la relacin. Los valores que
aparecen en cada una de las columnas pertenecen
I.10.2. Propiedades de las relaciones

Las relaciones tienen las siguientes caractersticas:
Cada relacin tiene un nombre y ste es distinto del nombre de

todas las dems.
Los valores de los atributos son atmicos: en cada tupla, cada

atributo toma un solo valor. Se dice que las relaciones estn
normalizadas.
No hay dos atributos que se llamen igual.
El orden de los atributos no importa: los atributos no estn

ordenados.
Cada tupla es distinta de las dems: no hay tuplas duplicadas.
El orden de las tuplas no importa: las tuplas no estn ordenadas
I.10.3. Tipos de relaciones

En un SGBD relacional pueden existir varios tipos de relaciones, aunque
no todos manejan todos los tipos.
Relaciones base. Son relaciones reales que tienen nombre y

forman parte directa de la base de datos almacenada (son
autnomas).
Base de Datos II 24
Vistas. Tambin denominadas relaciones virtuales, son relaciones

con nombre y derivadas: se representan mediante su definicin en
trminos de otras relaciones con nombre, no poseen datos
almacenados propios.
Instantneas. Son relaciones con nombre y derivadas. Pero a

diferencia de las vistas, son reales, no virtuales: estn
representadas no slo por su definicin en trminos de otras
relaciones con nombre, sino tambin por sus propios datos
almacenados. Son relaciones de slo de lectura y se refrescan
peridicamente.
Resultados de consultas. Son las relaciones resultantes de

alguna consulta especificada. Pueden o no tener nombre y no
persisten en la base de datos.
Resultados intermedios. Son las relaciones que contienen los

resultados de las subconsultas. Normalmente no tienen nombre y
tampoco persisten en la base de datos.
Resultados temporales. Son relaciones con nombre, similares a

las relaciones base o a las instantneas, pero la diferencia es que
se destruyen automticamente en algn momento apropiado.
I.10.4. Claves
Ya que en una relacin no hay tuplas repetidas, stas se pueden
distinguir unas de otras, es decir, se pueden identificar de modo nico.
La forma de identificarlas es mediante los valores de sus atributos.
Una superclave es un atributo o un conjunto de atributos que

identifican de modo nico las tuplas de una relacin.
Una clave candidata es una superclave en la que ninguno de sus

subconjuntos es una superclave de la relacin. El atributo o conjunto de
atributos de la relacin es una clave candidata para si y slo si
satisface las siguientes propiedades:
Unicidad: nunca hay dos tuplas en la relacin con el mismo

valor de .
Irreducibilidad (minimalidad): ningn subconjunto de tiene

la propiedad de unicidad, es decir, no se pueden eliminar
componentes de sin destruir la unicidad.
Cuando una clave candidata est formada por ms de un atributo, se

dice que es una clave compuesta. Una relacin puede tener varias
Base de Datos II 25
claves candidatas. Por ejemplo, en la relacin OFICINA, el atributo

Poblacin no es una clave candidata ya que puede haber varias oficinas
en una misma poblacin. Sin embargo, ya que la empresa asigna un
cdigo nico a cada oficina, el atributo Onum s es una clave candidata
de la relacin OFICINA. Tambin son claves candidatas de esta relacin
los atributos Telfono y Fax.
En la base de datos de la inmobiliaria hay una relacin denominada

VISITA que contiene informacin sobre las visitas que los clientes han
realizado a los inmuebles. Esta relacin contiene el nmero del cliente
Qnum, el nmero del inmueble Inum, la fecha de la visita Fecha y un
comentario opcional. Para un determinado nmero de cliente Qnum, se
pueden encontrar varias visitas a varios inmuebles. Del mismo modo,
dado un nmero de inmueble Inum, puede que haya varios clientes que
lo hayan visitado. Por lo tanto, el atributo Qnum no es una clave
candidata para la relacin VISITA, como tampoco lo es el atributo Inum.
Sin embargo, la combinacin de los dos atributos s identifica a una sola
tupla, por lo que los dos juntos son una clave candidata de VISITA. Si se
desea considerar la posibilidad de que un mismo cliente pueda visitar un
mismo inmueble en varias ocasiones, habra que incluir el atributo Fecha
para identificar las tuplas de modo nico (aunque ste no es el caso de
la empresa que nos ocupa).
Para identificar las claves candidatas de una relacin no hay que fijarse
en un estado o instancia de la base de datos. El hecho de que en un
momento dado no haya duplicados para un atributo o conjunto de
atributos, no garantiza que los duplicados no sean posibles. Sin
embargo, la presencia de duplicados en un estado de la base de datos s
es til para demostrar que cierta combinacin de atributos no es una
clave candidata. El nico modo de identificar las claves candidatas es
conociendo el significado real de los atributos, ya que esto permite saber
si es posible que aparezcan duplicados. Slo usando esta informacin
semntica se puede saber con certeza si un conjunto de atributos
forman una clave candidata. Por ejemplo, viendo la instancia anterior de
la relacin PLANTILLA se podra pensar que el atributo Apellido es una
clave candidata. Pero ya que este atributo es el apellido de un empleado
y es posible que haya dos empleados con el mismo apellido, el atributo
no es una clave candidata.
La clave primaria de un relacin es aquella clave candidata que se

escoge para identificar sus tuplas de modo nico. Ya que una relacin no
tiene tuplas duplicadas, siempre hay una clave candidata y, por lo tanto,
la relacin siempre tiene clave primaria. En el peor caso, la clave
primaria estar formada por todos los atributos de la relacin, pero
normalmente habr un pequeo subconjunto de los atributos que haga
esta funcin.
Base de Datos II 26
Las claves candidatas que no son escogidas como clave primaria son
denominadas claves alternativas. Por ejemplo, la clave primaria de la
relacin OFICINA es el atributo Onum, siendo Telfono y Fax dos claves
alternativas. En la relacin VISITA slo hay una clave candidata formada
por los atributos Qnum e Inum, por lo que esta clave candidata es la
clave primaria.
Una clave ajena es un atributo o un conjunto de atributos de una

relacin cuyos valores coinciden con los valores de la clave primaria de
alguna otra relacin (puede ser la misma). Las claves ajenas representan
relaciones entre datos. El atributo Onum de PLANTILLA relaciona a cada
empleado con la oficina a la que pertenece. Este atributo es una clave
ajena cuyos valores hacen referencia al atributo Onum, clave primaria
de OFICINA. Se dice que un valor de clave ajena representa una
referencia a la tupla que contiene el mismo valor en su clave primaria
( tupla referenciada).
I.10.5. Esquema de una base de datos relacional

Una base de datos relacional es un conjunto de relaciones normalizadas.
Para representar el esquema de una base de datos relacional se debe
dar el nombre de sus relaciones, los atributos de stas, los dominios
sobre los que se definen estos atributos, las claves primarias y las claves
ajenas.
El esquema de la base de datos de la empresa inmobiliaria es el

siguiente:
OFICINA (Onum, Calle, Area, Poblacin, Telfono, Fax)

(Enum, Nombre, Apellido, Direccin, Telfono, Puesto,
PLANTILLA
Fecha_nac,
Salario, DNI, Onum)
(Inum, Calle, Area, Poblacin, Tipo, Hab, Alquiler, Pnum,
INMUEBLE
Enum,
Onum)
INQUILINO (Qnum, Nombre, Apellido, Direccin, Telfono, Tipo_pref,
Alquiler_max)
PROPIETARI
(Pnum, Nombre, Apellido, Direccin, Telfono)
O
VISITA (Qnum, Inum, Fecha, Comentario)
En el esquema, los nombres de las relaciones aparecen seguidos de los

nombres de los atributos encerrados entre parntesis. Las claves
Base de Datos II 27
primarias son los atributos subrayados. Las claves ajenas se representan

mediante los siguientes diagramas referenciales.
Oficina a la que pertenece el

PLANTILLA OFICINA :
empleado.
INMUEBLE PROPIETARIO : Propietario del inmueble.
INMUEBLE PLANTILLA : Empleado encargado del inmueble.
Oficina a la que pertenece el
INMUEBLE OFICINA :
inmueble.
VISITA INQUILINO : Inquilino que ha visitado el inmueble.
VISITA INMUEBLE : Inmueble que ha sido visitado.
I.11.Diseo de esquemas relacionales de bases de

datos.
Uno de los retos en el diseo de la base de datos es el de obtener una
estructura estable y lgica tal que:
1. El sistema de base de datos no sufra de anomalas de

almacenamiento.
2. El modelo lgico pueda modificarse fcilmente para admitir

nuevos requerimientos.
Una base de datos implantada sobre un modelo bien diseado tiene

mayor esperanza de vida aun en un ambiente dinmico, que una base
de datos con un diseo pobre. En promedio, una base de datos
experimenta una reorganizacin general cada seis aos, dependiendo de
lo dinmico de los requerimientos de los usuarios. Una base de datos
bien diseada tendr un buen desempeo aunque aumente su tamao,
y ser lo suficientemente flexible para incorporar nuevos requerimientos
o caractersticas adicionales.
Existen diversos riesgos en el diseo de las bases de datos relacionales

que afecten la funcionalidad de la misma, los riesgos generalmente son
la redundancia de informacin y la inconsistencia de datos.
I.11.1. LA NORMALIZACION
La normalizacin es el proceso de simplificar la relacin entre los
campos de un registro.
Por medio de la normalizacin un conjunto de datos en un registro se
reemplaza por varios registros que son ms simples y predecibles y, por
Base de Datos II 28
lo tanto, ms manejables. La normalizacin se lleva a cabo por cuatro

razones:
Estructurar los datos de forma que se puedan representar las

relaciones pertinentes entre los datos.
Permitir la recuperacin sencilla de los datos en respuesta a las

solicitudes de consultas y reportes.
Simplificar el mantenimiento de los datos actualizndolos,

insertndolos y borrndolos.
Reducir la necesidad de reestructurar o reorganizar los datos

cuando surjan nuevas aplicaciones.
I.11.2. DEPENDENCIAS FUNCIONALES

Las dependencias funcionales nos permite expresar restricciones que no
pueden expresarse por medio de superclaves. Considrese el esquema
siguiente:
Esquema - prstamo = nombre - sucursal, numero - prstamo, nombre -

cliente, cantidad.
Ejemplo: si un prstamo se hace a ms de un cliente en este caso a

marido/mujer, entonces no esperaramos que el atributo numero -
prstamo fuera una superclave.
CASO PRCTICO PARA NORMALIZAR.

Un conjunto de proveedores distribuyen artculos en ciudades
especficas. Las ciudades se encuentran agrupadas por regiones, pero
un proveedor solo puede cubrir una ciudad. Cada proveedor es capaz de
distribuir artculos que estn numerados consecutivamente.
La siguiente tabla muestra la distribucin de los artculos que son

distribuidos por cada proveedor y las existencias actuales de estos.
Base de Datos II 29
PRIMERA FORMA NORMAL

Una relacin esta en primera forma normal si y solo si los dominios de
sus atributos solo contienen valores atmicos (no vas a dejar ningn
casillero vaco).
Base de Datos II 30
SEGUNDA FORMA NORMAL

Una relacin esta en segunda forma normal si y solo si esta en primera
forma normal y cada atributo no primo * es completamente dependiente
de la llave primaria.
*ATRIBUTO PRIMO: es aquel que forma parte de la llave primaria.
Base de Datos II 31
TERCERA FORMA NORMAL

Una relacin esta en tercera forma normal si y solo si esta en segunda
forma normal y todo atributo no primo es dependiente no
transitivamente de la llave primaria.
No se cumple la tercera forma normal porque hay transitividad de un

proveedor a regin.
Llave (PROV, ART)

Base de Datos II 32
Llave(PROV)
Se considera que un esquema que alcanza tercera forma normal es

eficiente. No obstante, se ha propuesto una mejora que permitir
obtener un modelo ms eficiente con la ventaja de que no depende de
formas normales anteriores (aunque se recomienda ampliamente
alcanzar tercera forma normal antes de su aplicacin).
Base de Datos II 33
BOYCE- CODD (FNBC)

Una relacin esta en FNBC si y solo si todas las dependencias
funcionales son completas y todos los atributos determinantes son llaves
candidatos.
Ejemplo:
Se desea el registro de alumnos; materias y profesores que la imparte.

supngase que un profesor imparte solamente una materia.
Base de Datos II 34
NOTAS:
* Una relacin que esta en FNBC estar siempre en 3FN; esta relacin no
es reciproca.
* La forma normal BOYCE-CODD (FNBC) optimiza casos en los que
existen varias llaves candidato traslapadas. (son aquellas que
comparten atributos.).
* Tericamente, es ms simple puesto que no requiere de formas

normales previas.
EJERCICIOS
MODELO ENTIDAD RELACION

1. Se desea desarrollar un nuevo sistema para manejar informacin
sobre una empresa privada transportadora. Para el diseo del modelo de
datos se obtuvo la siguiente informacin.
La empresa cuenta con una flota de camiones. De ellos se lleva una
ficha con los siguientes datos: marca, modelo, valor al que fue adquirido,
compaa donde est asegurado y kilometrajes recorridos (se actualiza
despus de cada viaje). Este ltimo dato se mantiene ya que la empresa
tiene por regla cambiar sus unidades antes de superar los 150.000 km.
Se lleva registro de los chferes: datos personales, nmero de carnet
de identidad, sueldo, antigedad, los camiones que esta autorizado a
manejar. Tambin se lleva un registro de los accidentes asociados a cada
chofer y camin, de ellos se registra la fecha, descripcin y costo de los
daos.
La actividad de la empresa consiste en transportar bultos desde un
lugar a otro del pas. Cada viaje tiene asignado un camin, un chofer y
varios bultos a trasladar. De cada viaje se quiere guardar la localidad
destino y las fechas de salida y llegada. De los bultos recibidos se
guardan los datos del remitente y del destinatario, valor por el que se
asegur el paquete y precio pagado por el traslado.
2. Hacer un modelo de base de datos para una empresa que se dedica

a la venta de autos 0 km. Las ventas se dividen en: ventas al contado
con entrega inmediata y ventas por plan. La informacin que la
empresa desea mantener involucra:
Automviles incluyendo #motor, marca, modelo y color.
Clientes incluyendo identificador, apellido y nombre, direccin y
telfono
Base de Datos II 35
Vendedores con los siguientes datos: nmero de vendedor, apellido y

nombre, cargo y fecha de ingreso.
En cuanto a las ventas al contado se tiene informacin del cliente,
vendedor y automvil afectado a la venta, as como nmero de venta,
precio definitivo y fecha en que realizo la operacin.
De las ventas por plan se guardan datos sobre nmero de suscripcin,
cliente que se suscribi, marca del automvil, valor de la cuota y fecha
de adjudicacin (si fue adjudicado). Adems para este tipo de ventas se
desea mantener informacin de los pagos de cada una de las cuotas:
fecha de vencimiento de la cuota y fecha de pago.
2.
Base de Datos II 36
Ejercicios Dependencias funcionales y Normalizacin
1. Un Aficionado a la msica decide automatizar la administracin de su

coleccin pues empieza a ser muy grande. Los datos a considerar son
los siguientes:
El ttulo del volumen (T) es nico.

Cada ttulo tiene un nico tipo de soporte (S) que es DVD o CD.
Varios ttulos pueden ser de un mismo cantante o grupo (CG),
con una ao (A) de edicin. Adems en un ttulo pueden intervenir
varios cantantes o grupos.
Tambin se conoce la estantera (E) donde est ubicado el ttulo
existiendo al menos una estantera por ao de edicin.
Adems, se conocen las canciones (C) de cada ttulo, no
existiendo en un ttulo dos canciones con el mismo nombre.
La duracin (D) de una cancin puede variar en los distintos
ttulos en los que se incluye, pudiendo ser o no interpretada por el
mismo cantante o grupo.
2. Escriba la siguiente forma normal en FNBC:

Base de Datos II 37
PEDIDO (numero_pedido, fecha_pedido, numero_proveedor,

nombre_proveedor, direccin_proveedor, numero_producto,
precio_producto, cantidad_producto)
Supuesto: En un mismo pedido puede haber ms de un producto.
II. LENGUAJES DE CONSULTAS

FORMALES
II.1. Los Lenguajes de Consulta a Bases de Datos

Relacionales
Los podemos dividir en dos tipos: Lenguajes Formales y Lenguajes
Comerciales. Los lenguajes formales estn basados en el lgebra
relacional o en el clculo relacional. Solamente se han descrito para
consulta a Bases de Datos (existen lenguajes comerciales que adems
de consulta permiten otras operaciones).
El lgebra relacional tiene procedimientos (procedimental), mientras que

los lenguajes basados en el clculo relacional son aprocedimentales.
Dentro del clculo relacional se distingue entre clculo relacional
orientado a tuplas y clculo relacional orientado a dominios.
Los lenguajes comerciales, en su mayora usan enfoques tanto

Base de Datos II 38
procedimentales como aprocedimentales, o lo que es lo mismo, no son

lenguajes puros como los formales. De esta manera hacen su sintaxis
ms amigable al usuario.
II.2. lgebra Relacional
A). Operaciones fundamentales:

Tiene cinco por medio de las cuales se puede realizar cualquier consulta.
Son las siguientes:
II.2.1. Seleccin ().

Es una operacin unaria (acta sobre una relacin nica). Sirve para
obtener determinadas tuplas de una relacin, basndose en que dichas
tuplas cumplan un predicado determinado P. Su sintaxis es la siguiente:
P (r), donde r es la relacin sobre la que se acta y P es el predicado
que debe cumplirse.
Si por ejemplo tenemos la relacin: estudiante = (NE, nombre, edad,

dccion) y queremos seleccionar al estudiante 2249 tendremos que
hacer:
(estudiante)
NE =2249
El predicado de seleccin admite los siguientes operadores relacionales:

< , , > , , = . Adems un predicado puede estar compuesto por
varias condiciones unidas por los conectivos u .
Ejemplo:
nombre = "Pepe" edad > 25 (estudiante)

De esta manera se seleccionaran todos los estudiantes llamados Pepe y
cuya edad supere los 25 aos.
II.2.2. Proyeccin ():

Es tambin una operacin unaria. Proyecta una nueva relacin con un
nuevo esquema en el cual aparezcan solamente los atributos que se
especifican en la operacin.
Sintaxis: A1 ,..., An (r). Donde A1 ,...., An es la lista de atributos y "r" la

relacin sobre la que se acta. Si, por ejemplo, queremos tener toda la
relacin de estudiantes, pero slo con el nombre haramos:
nombre (estudiante)
Base de Datos II 39
Si quisisemos obtener el nombre del estudiante 2249:
nombre ( NE = 2249 (estudiante))
II.2.3. Producto Cartesiano (r1 x r2):

Si el nmero de tuplas de r1 es n1, y el nmero de tuplas de r2 es n2, el
nmero de tuplas de la relacin obtenida ser n1n2.
Veamos un ejemplo: Supongamos que tenemos las siguientes relaciones:
Cliente = (nombre_cliente, ciudad, calle)
Sucursal = (nombre_sucursal, activo, ciudad)
Prestamo = (num_prestamo, nombre_sucursal, nombre_cliente,

importe)
Deposito = (num_cuenta, nombre_sucursal, nombre_cliente, saldo)
Si realizamos el producto cliente x prestamo, el esquema sera la

unin de los esquemas:
(cliente.nombre_cliente, ciudad, calle, num_prestamo,

nombre_sucursal, prestamo.nombre_cliente, importe)
Como tuplas obtenemos las posibles combinaciones de tuplas de cliente

con tuplas de prestamo.
Habr muchas tuplas de la nueva relacin en las que se cumplir que:
t[cliente.nombre_cliente] t[prestamo.nombre_cliente]
Por ello, normalmente la operacin de producto cartesiano va unida a

una seleccin que de entre todas las posibles combinaciones de tuplas
selecciona las que cumplen unas condiciones. Por ejemplo, queremos
localizar los clientes y las ciudades donde viven que tengan un
prstamo.
prestamo.nombre_cliente, ciudad (prestamo.nombre_cliente = cliente.nombre_cliente

(cliente x prestamo))
Base de Datos II 40
II.2.4. Unin de Conjuntos (r1 r2):
Acta sobre dos relaciones unindolas. El resultado es, por tanto, una
nueva relacin con el mismo esquema que las relaciones implicadas y
con un nmero de tuplas que es la unin de las tuplas de r 1 y r2 (los
elementos duplicados se desechan).
r1 y r2 deben tener el mismo esquema, es decir, los dominios de los

atributos i-simos de cada uno de los esquemas debe coincidir.
En el ejemplo que estamos considerando, no podramos hacer la unin

de cliente con prstamo, pero s sera posible hacer esto otro por
ejemplo
( nombre_cliente (cliente)) (nombre_cliente (prestamo))
Con la anterior operacin obtendramos los nombres de los clientes que

tienen prstamo o no. En la prctica esta sera una operacin intil,
puesto que se supone que todos los que tienen un prstamo en un
banco son automticamente clientes del banco. Veamos otra unin que
sera de mayor utilidad: si queremos conocer los clientes que tienen en
la sucursal 2 una cuenta, un prstamo, o ambas cosas, la operacin a
realizar sera:
( (nombre_sucursal = "2" (prestamo))) (

nombre_cliente
nombre_cliente(nombre_sucursal = "2"(deposito)))
II.2.5. Diferencia de Conjuntos (r1 - r2):

Es una operacin binaria que da como resultado una relacin con los
elementos que estn en r1, y no estn en r2. Lgicamente r1 y r2 deben
tener el mismo esquema.
Esta operacin se podra utilizar, si por ejemplo queremos saber el

nombre de los clientes que tienen un prstamo en la sucursal principal,
pero que no tienen cuenta en dicha sucursal:
(nombre_cliente (nombre_sucursal = "Principal" (prestamo))) - ( nombre_cliente

(nombre_sucursal = "Principal" (deposito)))
Con las cinco operaciones definidas (operaciones fundamentales) se

puede realizar cualquier consulta en lgebra relacional. Aun as, existen
Base de Datos II 41
otras operaciones (operaciones adicionales), que facilitan algunos tipos

de consulta frecuente, y que puede resultar muy tedioso el hacerlas
mediante las operaciones fundamentales.
B) Operaciones Adicionales:
II.2.6. Interseccin de Conjuntos (r1 r2):

Da como resultado una relacin que contiene los elementos comunes a
r1 y r2. Es adicional, ya que es equivalente a realizar r 1 - (r1 - r2).
Por ejemplo, podramos obtener los nombres de los clientes que tienen
depsito y prstamo al mismo tiempo en la sucursal 10.
( nombre_cliente (nombre_sucursal = "10" (prestamo))) (nombre_cliente (nombre_sucursal ="10" (deposito)))
II.2.7. Unin Join o Producto Theta (r1 P r2):

Es una forma de expresar un producto cartesiano que lleva implcita una
seleccin. p representa el predicado de la seleccin. De esta manera,
otra forma de conocer los nombres de los clientes que tienen prstamo,
cuenta o ambas cosas en la sucursal 10 sera:
(nombre_cliente (nombre_sucursal = "10" (prestamo))) prestamo.nombre_cliente =

deposito.nombre_cliente (nombre_cliente (nombre_sucursal = "10" (deposito)))
Otra forma de conseguir esto mismo sera:
prestamo.nombre_cliente (prestamo prestamo.nombre_cliente = deposito.nombre_cliente

deposito)
prestamo.nombre_sucursal = "10" deposito.nombre_sucursal = "10"
Podemos afirmar que:
r1 P r2 = P (r1 x r2)
II.2.8. Producto Natural (r1 x r2):

Mejora la operacin anterior, devolviendo directamente las tuplas que
tienen atributos comunes. En otras palabras, realiza la proyeccin sobre
la unin de los esquemas, es decir, elimina uno de los atributos comunes
a ambas relaciones y selecciona aquellas tuplas cuyos atributos
comunes coinciden en valor.
Base de Datos II 42
El siguiente ejemplo devuelve una relacin con los nombres de los

clientes que tienen prstamo, depsito o ambas cosas en la sucursal 10.
nombre_cliente (nombre_sucursal = "10" (prestamo deposito))
Dados r1(R1) y r2(R2) dos relaciones con sus respectivos esquemas, se

cumple la siguiente igualdad:
r1 r2 = R1 R2 (r1.A1 =r2.A1 ......... r1.An = r2.An (r1 x r2))
Al ser unin de esquemas, como los elementos de los esquemas son los
nombres de los atributos, si existe una columna comn a R 1 y R2 slo
aparecer una vez.
II.3. CALCULO RELACIONAL
II.3.1. CALCULO RELACIONAL DE TUPLAS

Es un lenguaje de consulta formal que permite expresar las consultas a
partir de frmulas bien formadas, donde las variables son interpretadas
como variantes sobre las tuplas de las tablas.
Fue presentada por Codd en 1972 y se deduce del clculo de predicados.
tomos:
1. Las variables estn asociadas a las tuplas de las tablas y se
denota como relacin (variable).
Ejemplo:
Modelo (M)
2. Los valores constantes estn asociados a los valores de los

dominios de los atributos y las funciones generadoras de los
mismos se denotan como variable.atributo
Ejemplo:
M.marca
3. Los predicados utilizados se construyen con los operadores de

comparacin {<, , >, ,=, }
Y constantes
Base de Datos II 43
Ejemplo:
M.marca Toyota
Una frmula bien formada (fbf) se define como:
1. Todo tomo es una frmula bien formada F
2. Si F1 y F2 son fbf, entonces F1 AND F2, F1 OR F2, NOT F1 o NOT

F2 son fbf.
3. F1 es una fbf
4. F1 es una fbf
Ejemplos de consultas segn el esquema relacional siguiente:
Producto (nroProd, nombrePro, cantidadExistencia, color)

Venta ( nroventa, fechaVen, nombreCliente, nroProVen,
cantVent )
Compras (nroCom, fechaCom, nombreProveedor, nroProCom,
cantCom )
1. Cul es el nombre y el color de cada producto en almacn?
Sol. { P.nombrePro, P.color / Producto(P) }
2. Cul es el nombre y la cantidad en existencia de cada

producto de color rojo en almacn?
Sol. {P.nombrePro, P.cantidadExistencia / Producto (P) P.color =

rojo}
3. Cul es el nombre del proveedor de cada producto en el

almacn?
Sol. { C.nombreProveedor, P.nombrePro / Producto (P) Compra

(C) P.nroPro=C.nroProCom }
4. Cules son los clientes que han comprado al menos un

producto de color verde?
Sol. { V.nombreCliente, P.nombrePro / P Ventas (V) Producto (P)

P.color =verde V.nroProven=P.nroPro}
Base de Datos II 44
5. Cules son los nombres de los productos comprados a

todos los proveedores y vendidos a por lo menos un
cliente?
Sol. { P.nombrePro, C.nombreProveedor / P A V Venta(V)
Producto(P) Compra(A) Compra (C) P.nroPro=V.nroProVen

P.nroPro=A.nroProCom A.nombreProveedor = C.nombreProveedor }
II.3.2. CALCULO RELACIONAL DE DOMINIOS
Es un lenguaje de consulta formal que permite expresar las consultas a

partir de frmulas bien formadas, donde cada variable se interpreta
como variante sobre el dominio del atributo de una relacin.
Se deduce del clculo de predicados tambin, pero:
1. Las variables estn asociadas a los dominios de los atributos y se

denota como relacin (at1:v1, at2:v2,)
Ejemplo:
ModeloAuto (modelo: m, marca: c)
2. Los predicados utilizados se construyen igual que para el clculo

relacional de tuplas
Ejemplos:
Sol. {N,C / Producto (nombrePro:N, color:C) }
2. Cul es el nombre y la cantidad en existencia de cada

producto de color rojo en almacn?
Sol. {N, C / Producto(nombrePro:N, cantidadExistencia:C,

color=rojo }

almacn?
Sol. { C, P / Producto(nroPro:PC, nombrePro:P)

Compra(NroProCom:PC, nombreProveedor:C)}
Base de Datos II 45
4. Cules son los clientes que han comprado al menos un

producto de color verde?
Sol. { V,P / NP venta(nombreCliente:V, nroProVen:NP)

Producto(nroProd:NP, nombreProd: P, color=verde)}
5. Cules son los nombres de los productos comprados a

todos los proveedores y vendidos a por lo menos un
cliente?
Sol. {P,PR / PR NP Venta(nroProVen:NP) Producto(nroPro:NP,

nombrePro:P) Compra(nroProCom:NP, nombreProveedor:PR)}
II.4. LENGUAJE QBE (Query By Example)
Presentado por Zloff en 1977 y comercializado desde 1980

Es un lenguaje grfico
La idea de su construccin es la formulacin de la consulta
mediante un ejemplo de la respuesta.
Las consultas se realizan invocando los esquemas de las tablas de
la consulta, las cuales sern desplegadas en forma grfica en la
pantalla.
Una vez obtenidas, se posiciona el ratn en la o las columnas deseadas

y se indica la operacin a realizar.
Las variables se indican con el smbolo de subrayado como

prefijo, ejemplo: _S, _3, _d5, o se subrayan, ejemplos: s, 3, d5.
Las constantes se colocan directamente en la columna deseada

precedidas por el operador de comparacin deseado, si no es =
Toda variable desplegable est cuantificada implcitamente por el

cuantificador existencial
Todas las operaciones deben tener como sufijo un punto.
Operaciones de QBE
OPERACI QBE
N
Base de Datos II 46
Desplegar P.
o
seleccion
ar
Cuantifica ALL.
dor
Universal
Contar CNT.
Promedio AVG.
Suma o SUM.
acumular
Calcular MIN.
el valor
mnimo
Calcular MAX.
el valor
mximo
Agrupar G.
tuplas
Ordenar AO.
Ascenden
Base de Datos II 47
temente
Ordenar DO.
descende
ntemente
Negacin
Lgica
Disyunci OR.
n lgica
Conjunci AND.
n lgica
Condiciones adicionales se expresan en una ventana aparte, en
algunas SGBD.
Las funciones CNT, AVG, SUM, MIN y MAX deben aplicarse a

variables precedidas con ALL.
Si no se desean eliminar las tuplas dobles en una proyeccin, se

coloca P.ALL._v
II.4.1. MANIPULACION DE DATOS EN QBE
Insercin de una nueva tupla: colocar I, debajo del nombre de

la tabla
Ejemplo: Insertar 10 pares de zapatos negros (producto nuevo)
Prod nroP nom canti color

ucto ro breP dadEx
ro istenc
ia
Base de Datos II 48
I. MAX. zapa 10 negr

ALL._ tos os
NP+I
Eliminacin de tuplas: colocar D. debajo del nombre de la tabla
Ejemplo, eliminar todos los productos de color gris.

ucto ro breP dadEx
ro istenc
ia
D. gris
Actualizacin de tuplas: colocar U. debajo del nombre de la
tabla
Ejemplo: sumar 100 a todos los productos de color verde

ucto ro breP dadEx
ro istenc
ia
U. _np _ce verd
e
_np _ce+1
00
Ejemplos de consultas
Base de Datos II 49

ucto ro breP dadEx
ro istenc
ia
P. P.
2. Cul es el nombre y la cantidad en existencia de cada producto
de color rojo en el almacn?

ucto ro breP dadEx
ro istenc
ia
P. P. rojo

almacen?
Sol.
En este caso se necesita realizar una reunin natural (join) entre
las dos tablas, ello se indica colocando la misma variable en las
columnas cuyos valores deben igualarse.
Base de Datos II 50

ucto ro breP dadEx
ro istenc
ia
_np P.
Co nroC fec nomb nro ca
mp om haC rePro Pro nt
ra om veedo Com Co
r m
P. _np
4. Cules son los clientes que han comprado al menos un producto
de color verde?

ucto ro breP dadEx
ro istenc
ia
_np P. verd
e
Ven nroV fec nomb nro ca
ta en haV reCli Pro nt
Base de Datos II 51
en ente Ven Ve
n
P. _np
5. Cules son los nombres de los productos comprados a todos los
proveedores y vendidos a por lo menos un cliente?

ucto ro breP dadEx
ro istenc
ia
_np P. verd
e
Co nroC fec nomb nro ca
mp om haC rePro Pro nt
ra om veedo Com Co
r m
ALL._p _np
r
Ven nroV fec nomb nro ca

ta en haV reCli Pro nt
en ente Ven Ve
Base de Datos II 52
n
P. _np
6. Desplegar los nombres de los productos de color verde ordenados
descendentemente por nombre de producto.
Prod nroP nom cantid color

ucto ro breP adExi
ro stenci
a
P.ALL. verd
DO._P e
PRACTICA ALGEBRA RELACIONAL

i. Dada la siguiente Base de Datos (Control de bancos):
Cliente = <nombre_cliente PK, ciudad, calle>

Sucursal = <nombre_sucursal PK, activo, ciudad>
Prstamo = <num_prestamo PK, nombre_sucursal FK,
nombre_cliente FK, importe>
Deposito = <num_cuenta PK, nombre_sucursal FK,
nombre_cliente FK, saldo>
Realice las siguientes consulta mediante el algebra relacional
1. Obtener el nombre de clientes y ciudades donde viven, que

cumplan con la condicin de tener un prstamo.
2. Obtener los nombres de los clientes que tienen, una cuenta,
un prstamo, o ambas cosas en la sucursal 2:
Base de Datos II 53
3. Obtener el nombre de los clientes que tienen un prstamo

en la sucursal principal, pero que no tienen cuenta en dicha
sucursal:
4. Obtener los nombres de los clientes que tienen depsito y
prstamo al mismo tiempo en la sucursal 10:
5. Obtener los nombres de los clientes que tienen prstamo,
cuenta, o ambas cosas en la sucursal 10 usando INNER
JOIN:
ii. Considere una base de datos que almacena los Accidentes

de Trnsito
COMPSEG (Compaa de Seguros) = <idSeg, Nom, Domi, Tel>

VEHI (Vehculos) = <Placa, Modelo, Tipo (Moto, Auto, Camioneta o
Camin), idSeg, Cm, CI>
MARCAS = <Cm, Descrip>
PERS (Personas) = <CI, Nom, Edad, Domi, Tel>
ACTA = <NroActa, Lugar, Fecha, hora>
INVO (Involucrados) = <NroActa, placa, CI, Conductor (si/no), dao
(sin dao, leve, grave, o fatal)>
1. Obtener el nombre de las compaas de Seguros que tienen

asegurados todos los tipos de vehculos.
2. Obtener todos los datos de los vehculos que no han tenido
accidentes fatales.
3. Obtener el nombre de las personas que no tienen asegurados
todos los vehculos en la misma compaa.
4. Obtener la placa de los autos involucrados en choques, en los que
viajaba solamente el conductor (es decir, no tena
acompaantes).
5. Obtener todos los datos de las personas que han chocado
manejando su propio vehculo.
PRCTICA CALCULO RELACIONAL

iii. Esquema de la base de datos:
Dpto(#dpto, presupDpto, jefeDpto)

Emp(#emp, #pro, telEmp)
Pro(#pro, #dpto, prePro)
Ofic(#ofi, #dpto, area)
Tlfs(#tel, #ofi)
Responda las siguientes consultas en clculo relacional de

tuplas, clculo relacional de dominios y QBE:
Base de Datos II 54
1. Cul es el nmero de telfono del empleado 1254, en que

proyecto y en que departamento trabaja?
2. Cul es el jefe del departamento 88 y cul es su nmero de
oficina?
3. Cules son los proyectos cuyo presupuesto es mayor que
10.000,00 y cules son sus empleados asignados?
4. Cules son las oficinas con rea menor a 24 y cules son sus
telfonos?
5. Cules son los empleados, proyectos, oficinas y telfonos del
departamento 56?
6. Cul es el rea promedio de las oficinas del departamento 44?
7. Calcular los presupuestos de los departamentos en dlares al
cambio de 6.3Bs/dlar
8. Inserte una nueva oficina para el departamento 28 con un rea de
12.
9. Acaba de terminarse el proyecto 14, elimnelo junto con todos sus
empleados
10. Acaba de ser recibida una donacin anual para la compaa, por
ello actualice los montos de los presupuestos de todos los
departamentos para incrementarse en 1.000,00
III. LENGUAJES DE CONSULTA

COMERCIALES
III.1. INTRODUCCION
SQL se ha convertido en el lenguaje de query relacional ms popular. El
nombre SQL es una abreviatura de Structured Query Language
(Lenguaje de Consulta Estructurado).
Base de Datos II 55
El lenguaje comercial de mayor influencia, SQL, usa una combinacin de

lgebra relacional y construcciones del clculo relaciona.
Aunque el lenguaje SQL se considere un lenguaje de consultas, contiene

muchas otras capacidades adems de la consulta en bases de datos.
Incluye caractersticas para definir la estructura de los datos, para la
modificacin de los datos en la base de datos y para la especificacin de
restricciones de seguridad.
III.2. LENGUAJES DE CONSULTA

La mayor parte de los sistemas de bases de datos relacionales ofrecen
lenguajes de consulta procedimental y no procedimental, entre estos
tenemos el SQL.
Los lenguajes de consulta formales (lenguajes puros) considerados as al

lgebra relacional y al clculo relacional, utilizan tcnicas fundamentales
para extraer datos de la base de datos.
III.3. LENGUAJE DE CONSULTA SQL
El SQL es una combinacin de construcciones del lgebra relacional y

del clculo relacional.
SQL nos permite realizar consultas a la base de datos.

SQL soporta funciones de definicin, control y gestin de la base
de datos.
SQL se clasifican segn su finalidad en tres sublenguajes:
o DDL -Lenguaje de definicin de datos

o DML -Lenguaje de manipulacin de datos
o DCL Lenguaje de control de datos
III.4. DDL (Data Description Language)
Lenguaje de definicin de datos incluye rdenes para definir, modificar o

borrar base de datos, tablas, as como relacionar las tablas entre si.
CREATE TABLE nombre_de_tabla ({nombre_de_columna tipo_de_dato

[unique]}....)
Ejemplo
create table ciudad
(
cod_ciudad NUMERIC,
Base de Datos II 56
Nombre VARCHAR(20)
)
III.5. DML (Data Manipulation Language )
Lenguaje de manipulacin de datos, permite recuperar los datos

almacenados en la base de datos. Incluye rdenes para actualizar la
base de datos aadiendo nuevos datos, suprimiendo datos antiguos o
modificando datos previamente almacenados.
Ejemplo
select p.nomb, p.pat
from participantes as p
where p.pat like Moral%
III.6. DCL (Data Control Language )
Lenguaje de control de datos, contiene elementos tiles para trabajar en

un entorno multiusuario, como ser: proteccin de los datos, la seguridad
de las tablas y el establecimiento de restricciones en el acceso.
Por ejemplo:
Para la asignacin de privilegios de acceso a los datos utilizamos
instrucciones como: GRANT/REVOKE
Para la gestin de transacciones usamos: COMMIT/ROLLBACK
III.7. Caractersticas del lenguaje DML
Una sentencia SQL es como una frase con la que decimos lo que
queremos obtener y de donde obtenerlo.
Todas las sentencias empiezan con un verbo (palabra reservada que

indica la accin a realizar), seguido del resto de clusulas, algunas
obligatorias y otras opcionales que completan la frase.
Todas las sentencias siguen una sintaxis.
III.8. Cmo se crea una sentencia SQL en SQLSERVER?
Abrir la zona de trabajo de tipo Query.

Base de Datos II 57
Si queremos realizar la consulta sobre un servidor con el cual todava

no hemos establecido conexin, seleccionando de la barra de mens
la opcin Nuevo > Consulta de motor de base de datos
Utilizaremos la sentencia CREATE DATABASE mnima:
Ejemplo.
CREATE DATABASE Ventas;
Al pulsar el botn Ejecutar se ejecuta la sentencia y aparece en la parte

inferior el resultado de la ejecucin, en la pestaa Mensajes:
Base de Datos II 58
III.8.1. Mensajes que emite al ejecutar una consulta
Si la ejecucin de la sentencia produce un error, el sistema nos

devolver el mensaje de error escrito en rojo en la pestaa Mensajes.
Podemos incluir en una misma consulta varias sentencias SQL, cuando
pulsamos Ejecutar se ejecutarn todas una detrs de otra. Si tenemos
varias consultas y slo queremos ejecutar una, la seleccionaremos antes
de ejecutarla.
III.9. CONSULTAS SIMPLES
Las consultas simples, estn basadas en una sola tabla.

SELECT, permite recuperar datos de una o varias tablas.
El resultado de la consulta es una tabla lgica, porque no se guarda en el
disco sino que est en memoria y cada vez que ejecutamos la consulta
se vuelve a calcular.
III.9.1. ESTRUCTURA BASICA

La estructura bsica de una expresin SQL consiste en tres clasulas:
Select, from y where.
La clusula select corresponde a la operacin proyeccin del

lgebra relacional. Se usa para listar los atributos deseados del
resultado de una consulta
La clusula from corresponde a la operacin producto cartesiano

del lgebra relacional. Lista las relaciones que deben ser
analizadas en la evaluacin de la expresin.
Base de Datos II 59
I.1.1. LA CLAUSULA SELECT
El resultado de una consulta SQL es, por supuesto, una relacin.
Ejemplo de consultas simples:

Obtener los cdigos de los proveedores de todas los proveedores en la
relacin compras
SELECT codProv
FROM Compras
La consulta anterior listara cada codProv una vez por cada tupla en la
que aparece en la relacin compras.
En aquellos casos donde se quiera forzar la eliminacin de duplicados,

se insertar la palabra clave DISTINCT despus de SELECT.
Ejemplo de una consulta utilizando DISTINCT

Obtener los cdigos de los proveedores de la relacin compras,
eliminando los duplicados
SELECT DISTINCT codProv

FROM compras
Ejemplo de una consulta utilizando ALL

Obtener los cdigos de los proveedores de la relacin compras, sin
eliminar los duplicados
SELECT ALL codProv

FROM compras
Ejemplo de una consulta utilizando *

El smbolo * se puede usar para denotar todos los atributos.
Obtener todos los datos de los proveedores.
SELECT *
FROM proveedores
Una clusula select puede contener tambin expresiones aritmticas

que contengan los operadores, +, -, * y / operando sobre constantes o
atributos de las tuplas.
Ejemplo de consulta con operadores aritmticos

Obtener el doble del precio de cada artculo.
Base de Datos II 60
SELECT descripcin, (precio*2)

FROM Artculo
La anterior consulta devolver una relacin donde el atributo precio est

multiplicado por 2.
I.1.2. LA CLAUSULA WHERE
Con la clusula FROM indicamos en qu tabla tiene que buscar la

informacin.
Alias de una tabla es un nombre de alias, es como un segundo

nombre que asignamos a la tabla
La clusula where corresponde al predicado seleccin del lgebra

relacional. Es un predicado que engloba a los atributos de las relaciones
que aparecen en la clusula from.
La clusula WHERE se emplea para especificar las filas que se desean

recuperar del origen de datos.
En el resultado de la consulta slo aparecern las filas que cumplan que

la condicin de bsqueda sea TRUE, los valores NULL no se incluyen.
La condicin de bsqueda puede ser una condicin simple o una

condicin compuesta por varias condiciones (predicados) unidas por
operadores AND y OR, no hay lmite en cuanto al nmero de predicados
que se pueden incluir.
Condiciones de Bsqueda Predicados
Una consulta tpica tiene la siguiente forma:
En SQL tenemos 7 tipos de predicados, condiciones bsicas de

bsqueda:
Comparacin estndar (Compara el valor de una expresin con el valor
de otra. Se pueden emplear = , <> , !=, < , <= , !<, > , >= ,!>)
Pertenencia a un intervalo (BETWEEN)

Pertenencia a un conjunto (IN)
Base de Datos II 61
Test de valor nulo (IS NULL).

Coincidencia con patrn (LIKE)
Si contiene (CONTAINS)
Comparacin estndar en el where
Sintaxis:
<expresion> {=|<>|!=|>|>=|!>|<|<=|!<} <expresion>
<expresion> Puede ser:
Un nombre de columna, una constante, una funcin, una variable,

una subconsulta escalar o cualquier combinacin de nombres
de columna, constantes y funciones conectados mediante uno o
varios operadores o una subconsulta.
A continuacin se ilustra con un ejemplo el uso de la clusula WHERE en

SQL.
Ejemplo de consulta usando where

Obtener las descripciones y precios de los artculos con precio mayor a
10.
SELECT descripcin, precio

FROM artculos
WHERE precio>10
SQL usa las conectivas lgicas AND, OR y NOT en la clausula WHERE.

Los operadores de las conectiva lgicas pueden ser expresiones que
contengan los operadores de comparacin >,<, , , <>, y =. SQL
permite usar los operadores de comparacin para comparacin para
comparar cadenas y expresiones aritmticas, as como tipos especiales,
tales como tipo fecha.
Ejemplo2 : Listar los participantes de gnero masculino
SELECT pat, mat, nomb, genero

FROM participantes
WHERE genero = M
III.10. CONDICIN DE BSQUEDA. TEST DE PERTENENCIA

BETWEEN
Sintaxis.
Base de Datos II 62
<expresion> [NOT] BETWEEN <expresion2> AND

<expresion3>
Examina si el valor de la expresin de test est en el rango

delimitado por los valores resultantes de expresion1 y expresion2.
Ejemplo: Mostrar los participantes nacidos entre el

30/01/1990 y el 20/09/2000.
SELECT pat, mat, nomb, fecha_nac

FROM participantes
WHERE fecha_nac BETWEEN 1990-01-30 AND 2000-09-20;
III.11. CONDICIN DE BSQUEDA: TEST DE PERTENENCIA

A UN CONJUNTO (IN)
Sintaxis
<expresion> IN ( <exp_valor> [ ,...n ] )

Examina si el valor de la expresin es uno de los valores incluidos en la
lista de valores indicados entre parntesis.
Ejemplo: Obtener los participantes que son arbitros:
SELECT cod_partici,pat, mat, nomb

FROM participantes
WHERE cod_partici IN (7,14,21,28,35);
III.12. CONDICIN DE BSQUEDA: TEST DE VALOR NULO

(IS NULL)
Sintaxis:
<expression> IS [NOT] NULL
Una condicin de bsqueda puede ser TRUE, FALSE o

NULL/UNKNOW, este ltimo caso se produce cuando algn campo
que interviene en la condicin tiene valor NULL.
El valor NULL no es en s un valor por eso no lo podemos utilizar en
una igualdad.
Ejemplo: Listar los participantes que no tienen la fecha de

nacimiento.
Base de Datos II 63
SELECT pat, mat, nomb, fecha_nac

FROM participantes
WHERE fecha_nac IS NULL;
III.13. CONDICIN DE BSQUEDA: TEST DE

CORRESPONDENCIA CON PATRN LIKE
Sintaxis:
Se utiliza cuando queremos comparar el valor de una columna con un

patrn en el que se utilice caracteres comodines.
<expression> [NOT] LIKE <patron> [ESCAPE 'car_escape']
Con expresin indicamos el valor a comparar (normalmente ser el

nombre de una columna) y patrn es la cadena que se busca. El
patrn es de tipo texto y tiene que escribirse entre comillas simples.
Dentro del patrn podemos utilizar los siguientes comodines:
% representa cualquier cadena de cero o ms caracteres.
Ejemplo: Lista de los participantes donde su nombre empiece An

SELECT pat, mat, nomb, telf
FROM participantes
WHERE nomb LIKE An%;
III.14. CONDICIONES DE BSQUEDA COMPUESTAS
Ejemplo: Lista de los participantes de gnero femenino, nacidos entre el

30/04/1980 al 21/09/2010, y el apellido paterno empiece con P o Q.
SELECT pat, mat, nomb, genero, fecha_nac

FROM participantes
WHERE genero = F AND fecha_nac BETWEEN 1980-04-30 and
2010-09-21 AND pat LIKE P% or pat LIKE Q%;
III.15. CONSULTAS MULTITABLA
Permiten obtener datos de diferentes tablas.
Para obtener datos de varias tablas combinamos las tablas mediante

alguna operacin basada en el lgebra relacional.
Base de Datos II 64
El lgebra relacional define una serie de operaciones cuyos operandos

son tablas y cuyo resultado es tambin una tabla.
Las operaciones de lgebra relacional implementadas en Transact-Sql

son:
La unin UNION
La diferencia EXCEPT
La interseccin INTERSECT
El producto cartesiano CROSS JOIN
La composicin interna INNER JOIN
La composicin externa LEFT JOIN, RIGHT JOIN Y FULL JOIN
III.16. UNIN, INTERSECCIN, EXCEPCIN
Estas operaciones calculan la unin, la interseccin y la diferencia de la

teora de conjuntos de las tuplas derivadas de dos subqueries.
En esta parte ampliaremos la clusula FROM y descubriremos nuevas

palabras reservadas (UNION, EXCEPT e INTERSECT) que corresponden a
operaciones relacionales.
Para obtener datos de varias tablas tenemos que combinar estas tablas
mediante alguna operacin basada en el lgebra relacional.
III.16.1. LA UNION DE TABLAS UNION

A continuacin mostraremos esta consulta mediante ejemplos:
Ejemplo 1. Obtener todos los proveedores nuevos y los antiguos
SELECT codigo, nombre, direccion, ciudad

FROM PROVEEDOR
UNION ALL
SELECT codigo, nombre, direccion,ciudad
FROM proveedorNuevo
Ejemplo 2. Obtener todos los artculos comprados y los que se

tienen en almacn, eliminando los duplicados
SELECT *
FROM articulo
UNION
SELECT *
FROM articuloscomprados
Base de Datos II 65
Ejemplo 3. Obtener todos los artculos comprados y los que se

tienen en almacn, eliminando los duplicados de aquellos cuyo precio es
menor a 10Bs
SELECT *
FROM articulo
WHERE precio<10
UNION
SELECT *
FROM articuloscomprados
where PRECIO <10
III.16.2. LA DIFERENCIA EXCEPT
Aparecen en la tabla resultante las filas de la primera consulta que no

aparecen en la segunda.
Ejemplo 1. Listar los productos que no han sido comprados.
SELECT *
FROM ARTICULOS
EXCEPT
SELECT *
FROM ARTICULOSCOMPRADOS
Listar los productos totalmente nuevos, que fueron comprados en un

stock mayor a 5.
SELECT *
where stock >5
EXCEPT
SELECT *
FROM ARTICULO
III.16.3. LA INTERSECCIN INTERSECT
Tiene una sintaxis parecida a las anteriores pero en el resultado de la

interseccin aparecen las filas que estn simultneamente en las dos
consultas.
Ejemplo 1. Listar los artculos que hay en almacn y que tambin

se han comprado.
SELECT *
FROM ARTICULO
INTERSECT
Base de Datos II 66
SELECT *
Ejemplo 2. Obtener el nombre y la ciudad de los proveedores que son

antiguos y tambin figuran en entre los proveedores nuevos
SELECT codigo, nombre

FROM PROVEEDOR
INTERSECT
SELECT codigo, nombre
FROM proveedorNuevo
III.17. EL PRODUCTO CARTESIANO CROSS JOIN
El producto cartesiano obtiene todas las posibles concatenaciones de

filas de la primera tabla con filas de la segunda tabla.
Se indica escribiendo en la clusula FROM los nombres de las tablas

separados por una coma o utilizando el operador CROSS JOIN.
Ejemplo 1. Obtener todos los artculos y proveedores
SELECT *
FROM ARTICULO, PROVEEDOR
-- ESTO ES LO MISMO
SELECT *
FROM ARTICULO CROSS JOIN PROVEEDOR
Ejemplo 2. Obtener todos los artculos y proveedores que estn

en ambas tablas
SELECT *
FROM ARTICULO CROSS JOIN PROVEEDOR
WHERE ARTICULO.codart = proveedor.codart
III.18. LA COMPOSICIN INTERNA INNER JOIN
Una composicin interna es aquella en la que los valores de las

columnas que se estn combinando se comparan mediante un operador
de comparacin.
Base de Datos II 67
Ejemplo 1. Obtener los cdigos de los artculos, su descripcin y los

nombres de los proveedores
SELECT a.codart, a.descripcion, p.nombre

FROM articulo as a INNER JOIN proveedor as p ON a.codart=p.codart
Ejemplo 2. Obtener los nombres de los proveedores, la descripcin del

artculo y precio de aquellos que proveen el artculo A04 y el precio est
entre 5 y 20
SELECT a.codart, a.descripcion, p.nombre, A.PRECIO

FROM articulo as a INNER JOIN proveedor as p ON a.codart=p.codart
WHERE (PRECIO BETWEEN 5 AND 20) AND (P.codart='A04')
III.19. ACTUALIZACION DE DATOS MEDIANTE INSERT,

UPDATE Y DELETE
Hasta ahora hemos trabajado con tablas que tenan datos y cuando nos
ha hecho falta hemos aadido nuevos datos o modificado algn dato
directamente desde el entorno de SSMS. Tenemos tres tipos de
instrucciones que estudiaremos:
INSERT para insertar nuevas filas
UPDATE para modificar campos
DELETE para eliminar ciertas filas
III.19.1. Insertar datos creando una nueva tabla
Una forma de insertar datos es crear una tabla que incluya los datos de
otra. Esta es la sentencia SELECT... INTO.
Sintaxis
SELECT ...
INTO nb_NuevaTabla
FROM ...
nb_NuevaTabla es el nombre de la tabla que se va a crear.

En la nueva tabla las columnas tendrn el mismo tipo y tamao que
las columnas del resultado de la SELECT.
Base de Datos II 68
Ejemplo 1. Crear una la tabla aux_jugadores e insertar en ella los

participantes donde el nombre empieza con la inicial de su nombre de
usted
SELECT cod_partici
INTO aux_jugadores
FROM participantes as p
WHERE p.nombrre like R%
III.19.2. INSERTAR EN UNA TABLA EXISTENTE INSERT

INTO
La insercin de nuevos datos en una tabla existente, se realiza con la

sentencia INSERT INTO.
Sintaxis:
INSERT [INTO] <destino> { [(lista_columnas)]

{VALUES ({DEFAULT|NULL|expresion}[ ,...n ]) |
tabla_derivada } }
|DEFAULT VALUES [;]
<destino> ::={ [nbBaseDatos.nbEsquema. |
nbEsquema.]nbTablaVista}
Insertar una fila de valores
Para insertar una fila de valores utilizamos la sintaxis:
INSERT [INTO] <destino> [(lista_columnas)] VALUES

({DEFAULT|NULL|expresion}[ ,...n ]) [;]
La palabra reservada INTO es opcional y no aade funcionalidad a

la instruccin.
Despus de indicar que queremos insertar, debemos indicar
dnde, mediante <destino>, que es el nombre de la tabla donde
queremos insertar.
Con la clusula VALUES indicamos entre parntesis los valores a insertar,

separados por comas.
Ejemplo. Insertar un registro en la tabla participantes los datos de su

docente
Base de Datos II 69
INSERT INTO participantes VALUES (3000, Roberta, Mallcu,

Morales,3097934,
Av. Villazon Nro. 1958, 73049047, 1970-06-07, Potosi, F, C)
III.19.3. Insercin de varias filas
Si los valores que queremos insertar los tenemos en otras tablas,

podemos insertar varias filas a la vez indicando una consulta que genere
las filas de valores a insertar. En este caso utilizamos la sintaxis:
INSERT [INTO] <destino> [(lista_columnas)] tabla_derivada

[;]
<destino> y lista_columnas funcionan igual que en el punto anterior.

Tabla_derivada es cualquier instruccin SELECT vlida que devuelva
filas con los datos que se van a cargar en el destino.
Ejemplo. Insertar los participantes que tienen la inicial de su paterno,

inicial de su materno en la tabla rbitros.
INSERT INTO arbitros

SELECT cod_partici
FROM participantes
WHERE p.appat LIKE M% AND p.apmat LIKE M%
III.20. UPDATE- MODIFICAR DATOS ALMACENADOS

La sentencia UPDATE modifica los valores de una o ms columnas en las
filas seleccionadas de una nica tabla.
UPDATE <destino>
SET {nbcolumna = {expresion | DEFAULT | NULL }} [,...n]
[FROM{ <origen> }] [ WHERE <condicion> ] [;]
Con <destino> indicamos la tabla que se va a actualizar.

La clusula SET especifica qu columnas van a modificarse y con qu
valor.
La expresin debe ser calculable basada en los valores de la fila
actualmente en actualizacin
Expresin tambin puede ser una subconsulta siempre y cuanto

devuelva un nico valor y cumpla las condiciones expuestas.
Base de Datos II 70
Ejemplo 1. Actualizamos el campo direccin de hotel Latino
UPDATE hotel SET dir = Av. Constitucin nro.1008

WHERE nomb_hotel = LATINO
Si lo que queremos es dejar el campo telef a nulo de la tabla hotel:
UPDATE hotel
SET telef = NULL;
Ejemplo 2. Si lo que queremos actualizar varias columnas, slo

tenemos que indicar las distintas asignaciones separadas por comas.
UPDATE clubes
SET dir = 0, telef = 0
WHERE nomb like A%;
III.21. ELIMINAR FILAS DELETE
La sentencia DELETE elimina filas de una tabla. La tabla se queda vaca.
DELETE [ TOP ( expression ) [ PERCENT ] ] [ FROM ] <destino>
[ FROM <origen>]
[ WHERE < condicion>] [; ]
- La palabra FROM (la primera) es opcional,slo sirve para introducir el

destino.
- <destino> es el nombre de la tabla de donde queremos eliminar las
filas.
La segunda clusula FROM sirve para indicar un origen que permita una
condicin de WHERE sobre una tabla diferente de destino.
La instruccin bsica sera:

Ejemplo 1.
DELETE oficinas;
Equivalente a:
DELETE
FROM oficinas;
Base de Datos II 71
Con esta instruccin eliminamos todas las filas de la tabla oficinas.

La clusula WHERE permite eliminar determinadas filas, segn una
condicin.
DELETE participantes
WHERE nomb = Juan;
Elimina las filas donde el nombre es Juan.
III.22. OPERADORES AGREGADOS
SQL proporciona operadores agregados (como son AVG, COUNT, SUM,

MIN, MAX) que toman el nombre de un atributo como argumento. El
valor del operador agregado se calcula sobre todos los valores de la
columna especficada en la tabla completa. Si se especifican grupos en
la Consulta, el clculo se hace slo sobre los valores de cada grupo
(vean la siguiente seccin).
Ejemplo Aggregates
Si queremos conocer el coste promedio de todos los artculos de la tabla

PART, utilizaremos la siguiente Consulta:
SELECT AVG(PRICE) AS AVG_PRICE

FROM PART;
El resultado es:
AVG_PRICE
-----------
14.5
Si queremos conocer cuantos artculos se recogen en la tabla PART,

utilizaremos la instruccin:
SELECT COUNT(PNO)
FROM PART;
y obtendremos:
COUNT
-------
4
III.22.1. AGREGACIN POR GRUPOS

Base de Datos II 72
SQL nos permite particionar las tuplas de una tabla en grupos. En estas
condiciones, los operadores agregados descritos antes pueden aplicarse
a los grupos (es decir, el valor del operador agregado no se calculan
sobre todos los valores de la columna especificada, sino sobre todos los
valores de un grupo). El operador agregado se calcula individualmente
para cada grupo).
El particionamiento de las tuplas en grupos se hace utilizando las

palabras clave GROUP BY seguidas de una lista de atributos que definen
los grupos. Si tenemos GROUP BY A1, &tdot;, Ak habremos particionado
la relacin en grupos, de tal modo que dos tuplas son del mismo grupo si
y slo si tienen el mismo valor en sus atributos A1, &tdot;, Ak.
Ejemplo Agregados
Si queremos conocer cuntos artculos han sido vendido por cada

proveedor formularemos la Consulta:
SELECT S.SNO, S.SNAME, COUNT(SE.PNO)

FROM SUPPLIER S, SELLS SE
WHERE S.SNO = SE.SNO
GROUP BY S.SNO, S.SNAME;
y obtendremos:
SNO | SNAME | COUNT
-----+-------+-------
1 | Smith | 2
2 | Jones | 1
3 | Adams | 2
4 | Blake | 3
Demos ahora una mirada a lo que est ocurriendo aqu. Primero, la join
de las tablas SUPPLIER y SELLS:
S.SNO | S.SNAME | SE.PNO
-------+---------+--------
1 | Smith | 1
1 | Smith | 2
2 | Jones | 4
3 | Adams | 1
3 | Adams | 3
4 | Blake | 2
4 | Blake | 3
4 | Blake | 4
Base de Datos II 73
Ahora particionamos las tuplas en grupos reuniendo todas las tuplas que
tiene el mismo atributo en S.SNO y S.SNAME:
S.SNO | S.SNAME | SE.PNO

-------+---------+--------
1 | Smith | 1
| 2
--------------------------
2 | Jones | 4
--------------------------
3 | Adams | 1
| 3
--------------------------
4 | Blake | 2
| 3
| 4
En nuestro ejemplo, obtenemos cuatro grupos y ahora podemos aplicar

el operador agregado COUNT para cada grupo, obteniendo el resultado
total de la Consulta dada anteriormente.
Ntese que para el resultado de una Consulta utilizando GROUP BY y

operadores agregados para dar sentido a los atributos agrupados,
debemos primero obtener la lista objetivo. Los dems atributos que no
aparecen en la clusula GROUP BY se seleccionarn utilizando una
funcin agregada. Por otro lado, usted no puede utilizar funciones
agregadas en atributos que aparecen en la clusula GROUP BY.
III.23. HAVING
La clusula HAVING trabaja muy similarmente a la clusula WHERE, y se

utiliza para considerar slo aquellos grupos que satisfagan la
cualificacin dada en la clusula HAVING. Las expresiones permitidas en
la clusula HAVING deben involucrar funcionen agregadas. Cada
expresin que utilice slo atributos planos deber recogerse en la
clusula WHERE. Por otro lado, toda expresin que involucre funciones
agregadas debe aparecer en la clusula HAVING.
Ejemplo Having
Si queremos slo los proveedores que venden ms de un artculo,

utilizaremos la Consulta:
SELECT S.SNO, S.SNAME, COUNT(SE.PNO)

FROM SUPPLIER S, SELLS SE
Base de Datos II 74
WHERE S.SNO = SE.SNO

GROUP BY S.SNO, S.SNAME
HAVING COUNT(SE.PNO) > 1;
y obtendremos:
SNO | SNAME | COUNT
-----+-------+-------
1 | Smith | 2
3 | Adams | 2
4 | Blake | 3
III.24. SUBCONSULTAS
En las clausulas WHERE y HAVING se permite el uso de subqueries

(subselects) en cualquier lugar donde se espere un valor. En este caso,
el valor debe derivar de la evaluacin previa de la subConsulta. El uso de
subqueries ampla el poder expresivo de SQL.
Ejemplo Subselect
Si queremos conocer los artculos que tienen mayor precio que el

artculo llamado 'Tornillos', utilizaremos la Consulta:
SELECT *
FROM PART
WHERE PRICE > (SELECT PRICE FROM PART
WHERE PNAME='Tornillos');
El resultado ser:
PNO | PNAME | PRICE
-----+-------------+--------
3 | Cerrojos | 15
4 | Levas | 25
Cuando revisamos la Consulta anterior, podemos ver la palabra clave

SELECT dos veces. La primera al principio de la Consulta - a la que nos
referiremos como la SELECT externa - y la segunda en la clusula
WHERE, donde empieza una Consulta anidada - nos referiremos a ella
como la SELECT interna. Para cada tupla de la SELECT externa, la
SELECT interna deber ser evaluada. Tras cada evaluacin, conoceremos
el precio de la tupla llamada 'Tornillos', y podremos chequear si el precio
de la tupla actual es mayor.
Si queremos conocer todos los proveedores que no venden ningn
artculo (por ejemplo, para poderlos eliminar de la base de datos),
utilizaremos:
Base de Datos II 75
SELECT *
FROM SUPPLIER S
WHERE NOT EXISTS
(SELECT * FROM SELLS SE
WHERE SE.SNO = S.SNO);
En nuestro ejemplo, obtendremos un resultado vaco, porque cada

proveedor vende al menos un artculo. Notese que utilizamos S.SNO de
la SELECT externa en la clausula WHERE de la SELECT interna. Como
hemos descrito antes, la subConsulta se evala para cada tupla de la
Consulta externa, es decir, el valor de S.SNO se toma siempre de la
tupla actual de la SELECT externa.
III.25. Tipos de Datos en SQL

A continuacin sigue una lista de algunos tipos de datos soportados por
SQL:
INTEGER: entero binario con signo de palabra completa (31 bits de

precisin).
SMALLINT: entero binario con signo de media palabra (15 bits de
precisin).
DECIMAL (p[,q]): nmero decimal con signo de p dgitos de
precisin, asumiendo q a la derecha para el punto decimal. (15
p qq 0). Si q se omite, se asume que vale 0.
FLOAT: numrico con signo de dobre palabra y coma flotante.
CHAR(n): cadena de caracteres de longitud fija, de longitud n.
VARCHAR(n): cadena de caracteres de longitud variable, de
longitud mxima n.
III.26. CREATE INDEX

Se utilizan los ndices para acelerar el acceso a una relacin. Si una
relacin R tiene un ndice en el atributo A podremos recuperar todas la
tuplas t que tienen t(A) = a en un tiempo aproximadamente proporcional
al nmero de tales tuplas t ms que en un tiempo proporcional al
tamao de R.
Para crear un ndice en SQL se utiliza el comando CREATE INDEX. La

sintaxis es:
CREATE INDEX index_name

ON table_name ( name_of_attribute );
Base de Datos II 76
Ejemplo Create Index

Para crear un ndice llamado I sobre el atributo SNAME de la relacin
SUPPLIER, utilizaremos la siguiente instruccin:
CREATE INDEX I
ON SUPPLIER (SNAME);
El ndice creado se mantiene automticamente. es decir, cada vez que

una nueva tupla se inserte en la relacin SUPPLIER, se adaptar el ndice
I. Ntese que el nico cambio que un usuario puede percibir cuando se
crea un ndice es un incremento en la velocidad.
III.27. CREATE VIEW
Se puede ver una vista como una tabla virtual, es decir, una tabla que
no existe fsicamente en la base de datos, pero aparece al usuario como
si existiese. Por contraste, cuando hablamos de una tabla base, hay
realmente una contraparte fsicamente almacenada para cada fila en la
tabla en algn sitio del almacenamiento fsico.
Las vistas no tiene datos almacenados propios, distinguibles y

fsicamente almacenados. En su lugar, el sistema almacena la definicin
de la vista (es decir, las reglas para acceder a las tablas base
fsicamente almacenadas para materializar la vista) en algn lugar de
los catlogos del sistema. Para una discusin de las diferentes tcnicas
para implementar vistas, refierase a SIM98.
En SQL se utiliza el comando CREATE VIEW para definir una vista. La

sintaxis es:
CREATE VIEW view_name
AS select_stmt
donde select_stmt es una instruccin select vlida, como se defini en

Select. Notese que select_stmt no se ejecuta cuando se crea la vista.
Simplemente es almacenada en los catalogos del sistema y se ejecuta
cada vez que se realiza una Consulta contra la vista.
Sea la siguiente definicin de una vista, utilizamos de nuevo las tablas

de la BD Ejemplo:
CREATE VIEW London_Suppliers

AS SELECT S.SNAME, P.PNAME
FROM SUPPLIER S, PART P, SELLS SE
WHERE S.SNO = SE.SNO AND
P.PNO = SE.PNO AND
S.CITY = 'London';
Base de Datos II 77
Ahora podemos utilizar esta relacin virtual London_Suppliers como si se

tratase de otra tabla base:
SELECT *
FROM London_Suppliers
WHERE P.PNAME = 'Tornillos';
Lo cual nos devolver la siguiente tabla:

SNAME | PNAME
-------+----------
Smith | Tornillos
Para calcular este resultado, el sistema de base de datos ha realizado

previamente un acceso oculto a las tablas de la base SUPPLIER, SELLS y
PART. Hace esto ejecutando la Consulta dada en la definicin de la vista
contra aquellas tablas base. Tras eso, las cualificaciones adicionales
(dadas en la Consulta contra la vista) se podrn aplicar para obtener la
tabla resultante.
III.28. DROP TABLE, DROP INDEX, DROP VIEW
Se utiliza el comando DROP TABLE para eliminar una tabla (incluyendo

todas las tuplas almacenadas en ella):
DROP TABLE table_name;
Para eliminar la tabla SUPPLIER, utilizaremos la instruccin:
DROP TABLE SUPPLIER;
Se utiliza el comando DROP INDEX para eliminar un ndice:
DROP INDEX index_name;
Finalmente, eliminaremos una vista dada utilizando el comando DROP

VIEW:
DROP VIEW view_name;
IV. SEGURIDAD E INTEGRIDAD

Base de Datos II 78
Seguridad e Integridad son dos conceptos que se utilizan

frecuentemente en el contexto de las Bases de Datos. Seguridad se
refiere a la proteccin de los datos contra una revelacin, alteracin o
destruccin no autorizada; integridad se refiere a la exactitud o
validez de los datos.
Seguridad implica asegurar que los usuarios estn autorizados para

llevar a cabo lo que tratan de hacer.
Integridad implica asegurar que lo que tratan de hacer es correcto.
IV.1. SEGURIDAD
La unidad de informacin para propsitos de seguridad puede ser desde

una Base de Datos o conjunto de tablas completos hasta un valor
especfico en una posicin especfica de fila y columna dentro de una
tabla especfica.
Un usuario dado tendr por lo regular diferentes derechos de acceso o

autorizaciones sobre diferentes objetos de informacin.
Por ejemplo para que un usuario pueda hacer un select , otro para hacer
select y update, etc.
El esquema de seguridad en SQL se basa en tres conceptos principales:
Los usuarios , cada vez que el DBMS recupera, inserta, suprime y

actualiza datos lo hace a cuenta de algn usuario.
Los objetos de la base de datos, son los elementos a los cuales se
aplica la proteccin de seguridad SQL.
Los privilegios son las acciones que un usuario tiene permitido
efectuar para un determinado objeto de la BD. Un usario diferente
puede tener un conjunto diferente de privilegios.
En el caso del SQL, el sistema tiene dos caractersticas ms o menos

independientes para el mantenimiento de la seguridad:
El mecanismo de las vistas, que puede servir para ocultar ciertos

datos confidenciales a ciertos usuarios no autorizados
El subsistema de autorizacin mediante el cual los usuarios con
derechos especficos pueden conceder de manera selectiva y
dinmica esos derechos a otros usuarios, y dess revocar esos
derechos.
Base de Datos II 79
IV.2. VISTAS Y SEGURIDAD
Una vista es una tabla virtual en la Base de Datos cuyo contenido est
definido por una consulta.
Las vistas son parte importante en SQL por varios razones:
Las vistas permiten acomodar el aspecto de una BD de modo que

diferentes usuarios la vean desde desde diferentes perspectivas.
Las vistas permiten restringir acceso a los datos, permitiendo que
usuarios slo vean ciertas filas o ciertas columnas de una tabla.
Las vistas simplifican el acceso a la BD mediante la presentacin de
la estructura de los datos almacenados de modo que sea ms natural
para cada usuario.
IV.2.1. Ventajas de las vistas

Seguridad
Simplicidad de consulta
Simplicidad estructurada
Aislamiento frente al cambio
Integridad de datos
IV.2.2. Desventajas de las vistas

Rendimiento
Restricciones de actualizacin
IV.2.3. Creacin de Vistas

La sentencia CREATE VIEW se utiliza para crear una vista. Para crear la
vista es necesiario tener permiso para acceder a todas las tablas
referenciadas en la consulta.
CREATE VIEW Nombre-de-vista ------------------- AS Consulta --- (Nombre

de columna)
Pueden existir :
Vistas Horizontales
Vistas verticales
Vistas agrupadas
Vistas compuestas
Base de Datos II 80
Actualizacin de Vistas
Bajo el estndar SQL una vista puede ser actualizada si la consulta que
la define satisface todas estas restricciones:
No debe especificar DISTINCT

La clusula FROM debe especificar solamente una tabla actualizable
Cada elemento de seleccin debe ser referencia a una columna
simple
La clusula WHERE no debe incluir subconsultas.
La consulta no debe incluir una clusula GROUP BY O HAVING
Si la vista satisface estas condiciones, es posible definir operaciones

INSERT, DELETE Y UPDATE.
Ejemplo 1: Para usuarios que solo se les permite tener acceso a los
registros completos de proveedores que son de La Paz:
CREATE VIEW ProveedoresLaPaz

AS select codP, NomP, ciudadP
From Proveedores
Where ciudad=La Paz
Ejemplo 2: Para los usuarios que solo pueden tener acceso a los datos
de los artculos pero no a sus precios unitarios
CREATE VIEW ArticulosD

AS select codA, NomA, Color
From Proveedores
Ejemplo 3: Para usuarios a los cuales se le permiten tener acceso a las

cantidades promedio enviadas por los proveedores, pero no cantidades
individuales
CREATE VIEW CP(codP, CantProm)

AS select codP, AVG(cant)
From suministros
Group by CodP
Base de Datos II 81
IV.3. INDENTIFICADORES DE USUARIO
Cada usuario de una Base de Datos basada en SQL tiene asignado un id-
usuario, un nombre breve que identifica al usuario dentro del del
software DBMS. El id-usuario se encuentra en el ncleo de la seguridad
SQL. Toda sentencia SQL ejecutada por DBMS se lleva a cuenta de un id-
usuario especfico. El id_usuario determina si la sentencia va ser
permitida o prohibida por el DBMS. En una BD de produccin los
id_usuarios son asignados por el administrador.
Grupos de usuarios
IV.4. CONSESIN DE PRIVILEGIOS ()
La sentencia GRANT se utiliza para conceder privilegios de seguridad

sobre objetos de la BD a usuarios especficos.
La sentencia REVOKE se utiliza para quitar los privilegios de seguridad

sobre objetos de la BD a usuarios especficos
EJEMPLOS:
GRANT SELECT ON TABLES PROVEEDORES TO PUBLIC;
GRANT ALL ON TABLE INSCRIPCION, ALUMNOS TO LETY,
MEDARDO, VICTOR;
GRANT UPDATE, DELETE ON TABLE CALIFICACIONES
TO GOYO;
REVOKE UPDATE, DELETE
ON TABLE CALIFICACIONES FROM INTRUSO;
REVOKE ALL ON TABLE CALIFICACIONES FROM GERARDO;
Tambin es posible que a un usuario se le conceda el permiso de
conceder permisos de acceso.
EJEMPLOS:
GRANT SELECT ON TABLE ALUMNOS TO PEDRO
WITH GRANT OPTION;
Del mismo modo se le puede revocar el permiso de conceder
permiso:
Base de Datos II 82
REVOKE SELECT ON TABLES FROM PEDRO;
IV.5. OTROS ASPECTOS DE SEGURIDAD
Es importante tener en mente que un SMBD no proporciona toda la

seguridad requerida, por lo cual es necesario establecer mecanismos de
control adicionales.
Uno de estos mecanismos es la realizacin de auditoras peridicas del

contenido de la base de datos.
Un mecanismo que incluso ya se soporta en diversos SMBD es el

encriptado, de forma tal que un usuario a pesar de lograr el acceso
formal a los archivos de una base de datos no pueda leerlos si no posee
la clave de encriptado/decriptado dependiendo del esquema de
encriptado seguido.
IV.6. INTEGRIDAD
El trmino de Integridad de datos se refiere a la correccin y

completitud de los datos en una Base de Datos. Cuando los contenidos
de una BD se modifican con sentencias INSERT, DELETE o UPDATE la
integridad de los datos almacenados puede perderse de muchas
maneras diferentes.
Pueden aadirse datos no vlidos a la BD, tales como una inscripcin

a una materia no existente.
Pueden modificarse datos existentes, tomando un valor incorrecto,
por ejemplo cuando se modifica la nota final (rango)
Los cambios a la BD pueden perderse debido a un error del sistema o
un fallo elctrico (transacciones )
Los cambios pueden ser aplicados parcialmente, como por ejemplo si
inscribe a un alumno a una materia sin verificar y actualizar el cupo
del curso.
Existen varios casos diferentes de restricciones de integridad de datos

que suelen encontrarse en las BD Relacionales como:
Datos requeridos (datos vlidos para algunas columnas, no NULL Ej:

Nombre, no Materno)
Chequeo de valides (dominio Ej. Rangos de nmeros)
Base de Datos II 83
Integridad de entidad (clave primaria, nico y distinto de NULL)

Integridad Referencial (DBMS, Disparadores, SP)
Reglas comerciales (De la Institucin Ej. Cupos, prerequisitos, pago de
cuotas)
Consistencia (operaciones de manera transaccional Ej.inscripcion:
insert alumnos, insert inscripcion, update cupos)
Nota.
Cuando se realiza un Insert se crea una pseudotabla denominada
inserted con la misma estructura de la tabla afectada.
Cuando se realiza un DELETE se crea una pseudotabla denominada
deleted con la misma estructura de la tabla afectada.
Cuando se realiza un UPDATE se crean ambas tablas (inserted y
deleted)
IV.7. QU ES UN DISPARADOR O TRIGGER?
Para cualquier evento que provoca un cambio en el contenido de una

tabla se puede especificar una accin asociada que el DBMS debera
efectuar automticamente. Los eventos que pueden disparar una
accin son el INSERT, UPDATE Y DELETE.
La accin disparada por un evento se especifica mediante una secuencia

de sentencias SQL, propias del lenguaje SQL del DBMS (Ej. T-SQL, i-SQL,
PL-SQL)
Ejemplo: Cuando se aade un nuevo registro a la tabla Inscripcin
Internamente se suceden dos eventos:

1. La insercion de un registro en Inscripcion
2. Actualizacin de nmero de inscritos (asignacin)
Nota.
Cuando se realiza un Insert se crea una pseudotabla denominada
inserted con la misma estructura de la tabla afectada.
Cuando se realiza un DELETE se crea una pseudotabla denominada
deleted con la misma estructura de la tabla afectada.
Cuando se realiza un UPDATE se crean ambas tablas (inserted y
deleted)
Base de Datos II 84
IV.7.1. ESTRUCTURA GENERAL DE UN DISPARADOR:
CREATE TRIGGER Nombre_del_Disparador

ON NombreTabla
FOR [INSERT][UPDATE][DELETED]
AS
Sentencias SQL
Ejemplo: Disear un Trigger que permita verificar las plazas y

actualizar automaticamente el valor del campo numero_inscritos en
caso de una inscripcion.
CREATE TRIGGER ActualizarPlazas

ON Inscripcion
FOR INSERT
AS
DECLARE @I SMALLINT,
@N SMALLINT
SELECT @N=a.plazas
FROM asignacion a, inserted t1
Where a.sigla_mat = t1.sigla_mat and
a.paralelo = t1.paralelo and
a.gestion = t1.gestion
SELECT @I=a.num_inscritos
FROM asignacion a, inserted t1
Where a.sigla_mat = t1.sigla_mat and
a.paralelo = t1.paralelo and
a.gestion = t1.gestion
IF ( @I < @N )
begin
UPDATE Asignacion
SET num_inscritos = num_inscritos+1
where Asignacion.sigla_mat in (select sigla_mat from inserted)
and Asignacion.paralelo in (select paralelo from inserted)
and Asignacion.gestion in (select gestion from inserted)
PRINT 'Registro satisfactorio'

end
ELSE
begin
Base de Datos II 85
PRINT 'NO HAY CUPO EN ESTE CURSO'

ROLLBACK
end
IV.7.2. DISPARADORES E INTEGRIDAD REFERENCIAL
Los disparadores proporcionan un modo alternativo de implementar las

restricciones de integridad referencial proporcionadas por claves
forneas y claves primarias. De hecho, el mecanismo disparador es ms
flexible que la integridad referencial estricta proporcionado por el
estndar ANSI/ISO.
Ejemplo: Realizar un Trigger verifique la existencia de un alumno

cuando se inscribe
CREATE TRIGGER AlumnoExistente

ON Inscripcion
FOR INSERT
AS
IF NOT EXISTS
(Select * FROM ALUMNOS a, inserted t1 WHERE
a.Cod_al=t1.Cod_al)
Begin
PRINT 'Alumno No Existente'
ROLLBACK
End
ELSE
PRINT 'Alumno correctamente inscrito'
IV.7.3. EL FUTURO DE LOS DISPARADORES
La principal ventaja de los disparadores es que las reglas comerciales

pueden almacenarse en las BD y ser forzadas consistentemente con
cada actualizacin en la BD.
Esto puede reducir sustancialmente la complejidad de los programas de
aplicacin (rutinas de front end, SP, etc) que accedan a la BD.
Base de Datos II 86
IV.7.4. LOS DISPARADORES TIENEN ALGUNAS DESVENTAJAS:
Complejidad de la BD: Cuando las reglas se trasladan al interior de la

BD, preparar la BD pasa a ser una tarea ms compleja (Ej. Para cada
tabla un triggers)
Reglas ocultas: Con las reglas ocultas en la BD programas que parecen

efectuar sencillas actualizaciones, pueden de hecho, generar una
cantidad enorme de actividad en la BD.
Base de Datos II 87
V. BASE DE DATOS ORIENTADA AL

OBJETO (OODBMS)
V.1. INTRODUCCIN
A los nuevos servicios de las empresas, le corresponden nuevas
funciones de aplicacin. Esas modificaciones de aplicacin deben poder
hacerse rpido, sin tener que reescribir todo.
Corra la segunda mitad de la dcada de los 80, cuando comienzan a

generalizarse en mltiples aplicaciones los sistemas de gestin de bases
de datos orientadas al objeto (OODBMS), los cuales toman las ventajas
del enfoque orientado al objeto, ya probados y los sistemas de gestin
de bases de datos, siendo su principal virtud el ofrecer un muy buen
desempeo en la gestin de datos complejos y multimediales.
Desde el punto de vista del desarrollador las ventajas estn dadas en

ganancias de productividad, dado su modelamiento ms simple que
facilita el desarrollo de aplicaciones. El modelamiento de aplicaciones es
mucho ms sencillo gracias al concepto de objetos complejos y el
modelo obtenido es fcilmente comprensible para el usuario. Este
modelo puede ser validado directamente por el cliente de la aplicacin.
El enfoque Orientado al Objeto favorece la reutilizacin, porque gracias a
la encapsulacin y la herencia, es fcil especializar un componente
existente para responder a las necesidades particulares de la aplicacin.
Desde el punto de vista del usuario final de los OODBMS, el mayor

aporte es la calidad en trminos de ergonoma, fiabilidad, evolucin y
desempeo. La mayor parte de los productos disponibles en el mercado,
son productos cerrados, difcilmente adaptables a las especificaciones
de la empresa: la ergonoma de la aplicacin es fija, las reglas de clculo
son difcilmente modificables, etc. la tecnologa objeto, gracias en
particular a la encapsulacin y la herencia, da productos desarrollos con
un OODBMS ms abierto y fcilmente adaptables. El usuario puede
obtener un costo menor de las modificaciones de sus procedimientos,
que van a integrar ms fcilmente su medio ambiente (entorno).
Un poco de historia
La primera aparicin del concepto data de 1984 con la proposicin de
David Maier y George Copeland de construir un DBMS desde Smalltalk,
Copeland et al. (1984).
Se pueden citar dos grandes proyectos desde 1985, el proyecto ORION
de MCC en Austn, Texas y en 1986 el proyecto Altair, en Rocquencowt,
Base de Datos II 88
Francia. En 1988, la primera generacin apareci, seguida por una

segunda generacin en 1990.
Despus de esta intensa actividad, pareciera necesario definir de una
manera precisa el concepto de OODBMS (Sistemas de Gestin de Bases
de Datos Orientadas al Objeto). En efecto, contrariamente al caso de los
sistemas relacionales que primero fueron definidos formalmente en el
artculo original de Codd, despus se generaron prototipos y finalmente
transformados en producto, no hubo un principio de especificacin
precisa de lo que deba ser un OODBMS.
En 1989, el paper "The Object-Oriented Database System Manifesto"

aunque con un enfoque demasiado limitado en temas de administracin,
Stonebraker et al. (1990), propone una definicin compuesta de tres
tipos de reglas que deben respetar un OODBMS:
Reglas Obligatorias: Las cuales el sistema debe imperativamente

seguir para merecer la calidad de OODBMS.
Reglas Facultativas: Lineamientos suplementarios del sistema, pero
que no son indispensables.
Reglas Abiertas: Propiedades alternativas del sistema que puede
ejercer.
El conjunto de reglas es rpidamente admitido por la comunidad
cientfica y comercial como un consenso mnimo.
V.2. EL ESTNDAR ODMG-93: UN ESTNDAR PARA BASES DE

DATOS ORIENTADAS AL OBJETO PURAS
Es el resultado de trabajos que duraron 18 meses por los 5 principales

distribuidores de OODBMS. Su objetivo fue asegurar la portabilidad de
las aplicaciones de un sistema a otro. En este objetivo son definidas tres
interfaz:
V.2.1. ODL (Lenguaje de Definicin de Objetos)

El lenguaje de definicin del objeto permite definir el modelo de datos.
Es compatible con IDL, el lenguaje del OMG (Grupo de Administracin de
Objetos). Permite la definicin de objetos complejos, de relacin entre
esos objetos y de mtodos asociados a dichos objetos.
V.2.2. OQL (Lenguaje de Consulta al Objeto)

El lenguaje de requerimientos permite consultar los objetos de
estructuras complejas, de enviar mensajes a objetos, efectuar join y
otras operaciones de tipo asociativo. Su sintaxis es del tipo SQL.
Base de Datos II 89
V.2.3. Conexin va C++ y Smalltalk.

Esta interfaz ("bindings", enlazamientos), especifica como se debe hacer
la programacin en C++ o Smalltalk de una aplicacin sobre una base
de datos que ha sido declarada en ODL. La conexin es basada sobre la
nocin de "puntero inteligente" que permite manejar los objetos
persistentes como objetos ordinarios va punteros persistentes.
V.3. DEFINIENDO LAS OODBMS

Un OODBMS ofrece toda la funcionalidad de un sistema de gestin de
bases de datos, al igual que todas las de un sistema objeto.
V.4. CONCEPTOS DBMS
La tecnologa de gestin de bases de datos (DBMS), naci a fines de los

aos 60. Las tecnologas de implementacin de esos sistemas han
evolucionado, su arquitectura ha emigrado hacia una arquitectura
Cliente/Servidor, pero los servicios ofrecidos (En particular a su nivel
fsico) son los mismos. La figura 1 muestra un DBMS tradicional
considerando sus aspectos ms caractersticos.
Un DBMS ofrece facilidades de almacenamiento, de acceso,

manipulacin y de compartimento de grandes volmenes de datos. Esos
datos pueden ser muy abultados, ellos no estn ni en memoria principal
ni en memoria virtual. Es el DBMS quien asegura la gestin de diferentes
niveles de jerarqua de memoria, el programador no hace la diferencia
entre un dato en memoria y un dato en disco. La gestin del disco
asegurada por el DBMS debe ser transparente y ofrece buenos
desempeos. Ella debe ofrecer mecanismos tales como gestin oculta
de indexacin, reagrupamiento de objetos sobre los discos (debe
proveer una forma adecuada de reagrupar los objetos de un nivel fsico,
a un nivel superior ), etc.
Figura 1: Composicin de un Objeto.

La parte esttica del objeto puede reagrupar informaciones
alfanumricas, grficas, textuales, sonoras, etc. Ella puede ser atmica
Base de Datos II 90
(los objetos atmicos son del tipo de base del sistema: enteros, reales,
caracteres, strings, booleanos) o compleja (constituida a partir de otros
objetos, atmicos o complejos).
La parte dinmica del objeto puede estar constituida de funciones de

archivos, clculos, de bsqueda de informacin, etc. Contrariamente a lo
que existe en la programacin clsica, las operaciones son subordinadas
a los objetos; el objeto no es solamente caracterizado por lo que es, sino
tambin por lo que hace, ocultando la estructura interna de un objeto y
la implementacin de las operaciones.
Cada objeto tiene una identidad propia (ver figura 2), independiente de
su valor. Podemos actualizar el valor de un objeto sin alterar su
identidad. El sistema maneja su identidad, atribuyendo a cada objeto un
identificador que asegura unicidad.
Figura 3: La identidad objeto.
La nocin de identidad de objeto guarda relacin con la composicin del

objeto, diferencindose de otros objetos.
Conceptos como la herencia permiten definir una clase (la clase define
una estructura y un comportamiento comn, a varios objetos) de objetos
a partir de una clase ya existente (herencia simple) o de varias otras
clases (herencia mltiple). La clase creada recupera no solamente su
estructura sino adems sus mtodos de su(s) clase(s) padre(s). La
herencia trae una descripcin compacta bien estructurada del esquema
de aplicacin. Es una tcnica de clasificacin de objetos que evita la
duplicacin de cdigo facilitando la reutilizacin de propiedades de
estructuras y comportamientos ya definidas.
Los objetos se comunican entre ellos por envo de mensajes, lo que se

quiere decir, es que transmiten rdenes a otros objetos. Cuando se
recibe un mensaje por un objeto, ste lo ejecuta. l puede crear nuevos
objetos y enviar nuevos mensajes.
Base de Datos II 91
Los mtodos asociados a clases diferentes, pueden tener el mismo

nombre: la eleccin del mtodo que sea efectivamente llamado es
aplazada hasta el momento de la ejecucin (enlazamiento dinmico),
dependiendo de la persistencia de la clase del objeto del cual el mtodo
es llamado en tiempo de ejecucin. Ese mecanismo de enlace dinmico
aumenta la independencia entre los mtodos y los objetos y permite
sumar nuevas clases sin modificar ni recompilar los programas
existentes, Por ejemplo, la aplicacin de gestin de pago maneja
diferentes tipos de contratos, cada uno con su mtodo de clculo de
sueldo, basta con crear una nueva subclase de la clase "contrato" con
un mtodo de clculo de sueldo correspondiente a ese algoritmo. Esos
nuevos contratos son entonces inmediatamente tomados en cuenta por
los programas existentes, sin modificacin particular del cdigo.
La herencia y el enlazamiento dinmico permiten alivianar los

programas y el trabajo del programador (por efecto de la reutilizacin)
cuando se activan los mdulos de la aplicacin.
Se hace notar que el modelamiento de objetos se puede realizar bajo

una forma grfica, pudiendo tener ciclos.
V.5. CONCEPTOS ESPECIFICOS DE OODBMS
La nocin de objetos complejos optimiza la representacin de las

estructuras complejas y acortando la distancia que separa el
modelamiento de un escenario del mundo real y su implementacin. Los
objetos complejos permiten as, un modelamiento ms intuitivo de datos
de una aplicacin, su presentacin en la base de datos est mas cerca
de la realidad. La estructura compleja de los objetos es manejada por
punteros lgicos. Esos punteros reemplazan la utilizacin de uniones
relacionales, e inducen as una ganancia de desempeo, particularmente
cuando la cantidad de datos es importante. La siguiente figura muestra
un esquema tpico de una OODBMS:
Base de Datos II 92
Figura 3: Una OODBMS tradicional, Manola (1994).
El concepto de identidad de objeto, tiene repercusiones particularmente

interesantes en el contexto de un DBMS. La distribucin de objetos
permite limitar la tabla de la base de datos. Permite una mejor gestin
de actualizacin, y es ms rpida, ya que tiene menos objetos que
modificar. Ofrece igualmente una gestin automtica de integridad
referencial (desaparicin de referencias a objetos destruidos), problema
crucial de las bases de datos.
Con las generaciones previas de DBMS, los desarrolladores tuvieron un

nivel bajo de productividad. Esto es en particular dado por un problema
de funcionalidad entre aquellas DBMS y los lenguajes de programacin
utilizados. En efecto, los tipos de datos de esas categoras de
herramientas son incompatibles, el programador debe asegurarse por si
mismo de la conversin de datos entre la base de datos y el lenguaje:
Esto impone el desarrollo suplementario que hay que realizar para
mantener la consistencia de la aplicacin en su ejecucin.
La falta de coincidencia entre lenguajes orientados a tablas, tales como

SQL, y los lenguajes comunes, significa que se necesita un lenguaje
separador para la manipulacin de datos (DML), existiendo
impedimentos de acoplar estilos declarativos y basados en
procedimientos entre los tipos de sistemas del lenguaje de aplicacin y
de bases de datos, dando lugar a una perdida de informacin en la
interfaz, y obstaculizando la comprobacin automtica de tipos.
Para solucionar este problema los OODBMS ofrecen el concepto de

completitud; que es la percepcin de escribir completamente una
aplicacin utilizando el DBMS como un nico lenguaje (tal como los
lenguajes estndar segn la norma ODMG; C++, Smalltalk o Java), sin
tener que recurrir a los recursos de los lenguajes externos. Este
concepto suprime el problema de funcionalidad, ya que los datos son
Base de Datos II 93
manipulados de la misma manera en la base de datos que por el

lenguaje de programacin. En efecto, es el mismo modelo de datos, que
es soportado por el lenguaje objeto de desarrollo de la aplicacin y por el
OODBMS. Los OODBMS ofrecen todo un lenguaje de programacin
completo integrando los accesos a las bases de datos.
V.6. CARACTERSTICAS DE LAS ODBMS

Un completo modelo de bases de datos, con rasgos tales como; la
manipulacin fija y el acceso de asociacin.
Un modelo orientado al objeto que respalda objetos complejos, identidad

del objeto, encapsulamiento, clases, caracteres, extensibilidad e
integridad computacional.
Un DDL (Data Definition languaje, define tipos de objetos, y adems el

usuario puede declarar procedimientos y variables asociadas con los
tipos de objetos) real con rasgos de manipulacin de esquemas.
La capacidad de almacenar y manipular tanto los datos (objetos) como

los metadatos (clases y mtodos) en el propio sistemas.
Un DML (Data Manipulation Languaje, por lo general contiene un

lenguaje de consultas y un componente de lenguaje de programacin ),
a travs de un lenguaje de consulta completo, declarativo.
Independencia de datos lgica y fsica (esto es, un DDL fsico y uno
lgico y la capacidad para modificar el esquema fsico sin cambiar la
aplicacin).
La capacidad de manipular cantidades de datos enormes.
La capacidad de desarrollar aplicaciones completas en un medio nico.
V.7. LOS DESEMPEOS

El problema de los desempeos es esencial para los DBMS. El mercado
de sistemas orientados al objeto se desarrolla porque esos sistemas
ofrecen desempeos mejorados con respecto a los sistemas
relacionales. Existen tres tipos de benchmarking ("pruebas de
rendimiento") que permiten medir estos sistemas.
Bechmarking 001, Rubenstein et al. (1987), Catell et al. (1992), est

orientado a aplicaciones que tienen por objetivo describir la aplicacin
en cuanto a su tipo de concepcin (refirindose a su forma de
generacin, formacin). Manipula los objetos complejos entre el servidor
y una estacin de trabajo.
Base de Datos II 94
Bechmarking de Hypermodel, fue hecho por un grupo de navegadores

de conceptos en sistemas. Se basa sobre la aplicacin del tipo hipertexto
y mide el tiempo de acceso a los objetos.
Bechmarking 007, Carey et al. (1993), hecho en 1992 para las
limitaciones del Bechmarking 001, abarcando un gran nmero de
operaciones, transacciones, requerimientos y el control de versiones. El
007 denota tres diferentes tamaos:
Pequeo: La base de datos en memoria principal.
Mediano: La base de datos est contenida en memoria virtual y una
parte en la memoria principal.
Grande: La base de datos est en memoria virtual.
Los OODBMS dominan en desempeo con respecto a los sistemas

relacionales sobre las aplicaciones manipulando objetos complejos. Esto
es por una sencilla razn; que los sistemas relacionales fueron hechos y
diseados para efectuar algunas operaciones simples (seleccin,
proyeccin, etc.), y los OODBMS tienen por finalidad manipular objetos
estructurados y complejos. En cuanto a una comparacin arquitectnica
entre el modelo relacional y el modelo objeto aplicado a DBMS, la figura
5 muestra su correspondiente composicin habitual.
V.8. LOS APORTES A LA TECNOLOGIA
Los OODBMS permiten llegar a nuevos dominios para los cuales las
bases de datos tradicionales son renuentes a ser aceptadas.
Su fuerte es en ambientes donde hay una necesidad de datos no

estndar, es decir, de aquellos que uno manipula textos estructurados o
no estructurados, imgenes, grficos, sonidos, videos, documentos o
programas. Se trata entonces de ambientes donde la estructura de los
datos es tan compleja que representarla en un modelo tradicional es
ineficaz.
Se trata de dominios o tipos de datos que al usarlos no permanecen fijos

desde el inicio y son variables en el tiempo.
Son dominios comunes, por ejemplo:

CAD
Gestin de datos tcnicos
Cartografa
Multimedia.
Sistemas distribuidos y cliente/servidor.
Bases de datos multimedia.
Correo por voz.
GIS
Base de Datos II 95
En todos estos dominios, la tecnologa de OODBMS aporta los

desempeos mejores y un desarrollo ms eficaz de aplicaciones.
Los OODBMS disminuyen los costos lgicos de desarrollo.
Esta baja de costos es obtenida en opinin de connotadas figuras ligadas

a DBMS (Por citar algunos: Atkinson et al., Bancilhon, Graham), por un
acortamiento del ciclo de anlisis, concepcin, codificacin, depuracin,
testeo, mantencin y evolucin. Mejoramiento obtenido por:
La reutilizacin del componente lgico.

La disminucin de cdigo.
La capacidad de modelamiento directo de informacin compleja.
La mejor integracin a los lenguajes de programacin.
Desarrollo rpido de prototipos de aplicaciones.
Utilizacin de medio ambiente grfico de desarrollo.
Utilizacin de herramientas de generacin de interfaz grfica de
realizacin.
Los OODBMS permiten producir aplicaciones grficas de mejor calidad.
Las aplicaciones son mejoradas en dos puntos esenciales:
Los desempeos en el caso de la manipulacin de datos complejos.
La calidad "industrial" de aplicaciones para la facilidad de mantencin,
su capacidad de crecimiento y posibilidad de ser personalizadas en
dominios especficos.
Los OODBMS permiten recuperar y mejorar las aplicaciones existentes.
Para los sistemas que disponen de una interfaz C++ estndar, el

mecanismo consiste en tomar una aplicacin existente en la cual la
persistencia es asegurada por un sistema de archivos que al migrarlos al
OODBMS se reemplaza el acceso a los archivos por el almacenamiento
en el OODBMS. As, el costo de migracin es mnimo y la aplicacin es
bastante mejorada. En efecto, resultando en:
Una simplificacin de cdigo (el acceso a los objetos de la base de datos
es inmediata y sin traduccin).
La capacidad de fiabilidad y compatibilidad de los datos.

Los Mercados
1. Aplicacin en Sistemas de informacin geogrficos.
Para los sistemas de informacin geogrficos o para toda aplicacin en
la cual hay una dimensin espacial o geogrfica (la cartografa de una
regin, la topologa de una zona o el plano de un edificio), los
desarrolladores de estas aplicaciones necesitan la tecnologa de objetos;
ella ofrece un mayor desarrollo y mejores desempeos.
2. Gestin de datos tcnicos.
Base de Datos II 96
Porque permiten almacenar los datos de naturaleza variada y de tipo

extensible, los OODBMS son elegibles como sistemas de
almacenamiento para este tipo de aplicaciones, que incluyen la gestin
de datos cientficos experimentales, la gestin de datos asistidos por
computador (CAD) y la documentacin tcnica.
3. Aplicaciones Multimedia.
Para toda aplicacin que manipula grficos, imgenes, animacin y voz,
los OODBMS son los primeros en la eleccin de los desarrolladores.
V.9. Orientado a objetos.
Una idea superficial del concepto Orientado a Objetos consiste en una

organizacin del software como un conjunto de objetos que contienen
tanto informacin en estructuras de datos como su comportamiento. La
informacin que tienen se organiza en atributos y el comportamiento en
operaciones.
Para comprender mejor el concepto se van a examinar las cuatro
principales caractersticas: Identidad, Clasificacin, Polimorfismo y
Herencia.
V.10. Identidad.
Identidad quiere decir que los datos estn organizados en entidades
discretas y distinguibles llamadas objetos. Cada objeto ha de poder
distinguirse por un puntero, un ndice en un array, un valor de un
atributo,...
Dos objetos que tengan la misma informacin no son indistinguibles, la
identidad los distingue.
C++: La implementacin de la identidad se realiza a travs del puntero
al objeto (this). Ejemplo:
int * p; p=new int;

...
{int a=*p; delete p; p=new int; *p=a;} // Cdigo vaco
...
El cdigo que aparece en el ejemplo, puede tener alguna influencia en
la funcionalidad del programa?
V.11. Clasificacin.
Los objetos con la misma estructura de datos (atributos) y el mismo
comportamiento (Operaciones) se aglutinan para formar una clase. Una
clase es una abstraccin que describe las propiedades de los objetos.
Una clase define un conjunto de objetos individuales. Se dice que cada
objeto es una instancia de una clase. Los objetos de la misma clase,
aparte de la identidad, solo se diferencian en el valor de los atributos,
comparten los nombres de los atributos, as como las operaciones.
Base de Datos II 97
Nada impide que un objeto pertenezca a ms de una clase. Ejemplo:

Clase Circulo Clase Grfico
Atributos Atributos
Centro Posicin
Radio Color
Operaciones Operaciones
Superficie Dibujar
Mover Mover
CambiarTamao
Como sera un objeto de ambas clases?

Qu pasa con la operacin mover?
Polimorfismo.
Significa que una misma operacin puede comportarse manera diferente
en diferentes clases. Con esto estamos diciendo que es el propio objeto
el que sabe como tiene que comportarte ante una determinada
operacin.
Podemos tener la clase fichero y la clase PiezaAjedrez, ambas pueden

tener la operacin mover pero cada una har tarea diferente, segn lo
que se espera de ella.
La implementacin concreta de una operacin para una clase se llama

mtodo.
Gracias al polimorfismo se puede invocar a un mtodo sin conocer
exactamente el objeto sobre el que se invoca. Si suponemos que
tenemos un conjunto de objetos y de entre ellos se selecciona uno, pero
no sabemos cual, si todos esos objetos tienen el mtodo mover, puedo
invocar dicha operacin y ,segn el objeto que sea, invocar al mtodo
adecuado.
Herencia.
Herencia es compartir atributos y operaciones entre clases utilizando
una estrategia jerrquica. Tanto los atributos como las operaciones que
se toman de otra clase se pueden redefinir. En trminos generales se
puede definir una clase que despus se puede ir refinando en sucesivas
subclases.
Cuando se dice que una clase A hereda de otra clase B, A tendr todos
los atributos y operaciones de B, adems podr tener otros atributos y
operaciones propias. Puede ocurrir que la clase A tenga operaciones o
atributos que se llamen igual que la clase B, este tipo de refinamiento de
las clases consiste en redefinir las acciones o atributos de la clase padre.
Realmente no se puede decir que en este caso se sustituyan, los
atributos y operaciones de B estn en A, pero dependiendo del gestor de
objetos, stos pueden quedar ocultos o inaccesibles.
Base de Datos II 98
Una clase puede heredar de varias clases, cuando esto ocurre tendr
todos los atributos y operaciones de todas las clases que hereda.
Puede ocurrir que dos clases tengan atributos u operaciones con el
mismo nombre, si una clase heredara de ambas habra ambigedad,
cuando me refiera a una operacin, cada gestor de objetos particular
puede deshacer la ambigedad de diferente manera.
Cuando un objeto es de una clase, y sta hereda de otras clases, ese
objeto es de todas las clases que hereda su clase.
Otras caractersticas.
Las caractersticas que se tratan en este punto no especficas de la
orientacin a objetos, pero si son muy importantes.
V.12. Abstraccin.
La abstraccin consiste en centrarse en los aspectos esenciales de una
entidad e ignorar sus propiedades accidentales. La abstraccin en la
orientacin a objetos se produce a travs de dos maneras:
Clasificacin: Permite englobar a muchas entidades particulares dando
una idea general y abstracta de todas ellas.
Herencia + Polimorfismo: Permite crear una clase original muy general
para que en sucesivos refinamientos se creen otras subclases ms
concretas. Con la primera clase nos hemos abstrado de lo comn e
importante de todas las subclases y con el polimorfismo podemos
mantener o refinar las operaciones iniciales.
V.13. Encapsulamiento.
La encapsulacin consiste en separar los aspectos externos del objeto, a
los cuales pueden acceder otros objetos, de los detalles internos de la
implementacin del mismo, que quedan ocultos para los dems.
Esto permite modificar la implementacin de un objeto, sabiendo seguro
que no influye en el resto de la aplicacin, lo que hay que hacer es
modificar solo la parte oculta, respetando la externa.
V.14. Combinacin datos y comportamiento.

Con un enfoque convencional por procedimientos, cuando tenemos un
conjunto de estructuras de datos, stos vienen asociados con otro
conjunto similar pero de procedimientos que permiten su manejo. Con
este enfoque se estn duplicando los elementos por que hay dos
conjuntos. Se ms adecuado crear un solo conjunto donde los elementos
del mismo sean pares de estructura de datos / procedimiento.
Ejemplo:
Gestor de bases de datos de informacin geogrfica (GIS):
Tratamiento convencional:
Se definen propiedades para zonas geogrficas.
Se definen como varan esas propiedades en el tiempo.
Combinando datos y comportamiento.

Base de Datos II 99
Se definen un elemento propiedad junto con la forma en que vara en el

tiempo.
Se aplica ese elemento sobre zonas geogrficas.
V.15. Compartir.
Una de las principales caractersticas de las tcnicas orientadas a
objetos es la capacidad que tienen para poder compartir, esto se realiza
en dos niveles:
A travs de la herencia se utiliza cdigo de manera natural y con el
polimorfismo se puede particularizar para cada clase.
La reutilizacin de cdigo se realiza de manera inmediata. Gracias al
encapsulamiento se puede utilizar cdigo sin tener en cuenta su
implementacin.
V.16. Objetos / Procedimientos.

Un diseo basado en objetos es ms estable que un diseo basado en
procedimientos, a lo largo de un proyecto pueden cambiar algunos
procedimientos o acciones, sin embargo los objetos que forman parten
del mismo rara vez cambian.
Ejemplo: Se quiere disear un software para analizar la vuelta a Espaa.
Habr objetos ciclistas, etapas, equipos,...
Si se quiere realizar el diseo del Tour de Francia, puede que haya que
cambiar valores de atributos e implementacin de mtodos, pero
seguirn los mismos objetos.
V.17. Sinergia.
Cuando los resultados de combinar una serie de elementos son mayores
de lo que se espera de esos elementos vistos individualmente, se dice
que se produce sinergia entre ellos. Esto ocurre con la identidad,
clasificacin, polimorfismo y herencia, al utilizarlas en conjunto forman
un estilo diferente de programacin (orientado a objetos).
V.18. Orientacin por objetos

La orientacin por objetos es un nuevo enfoque para el desarrollo de
sistemas programados, que permite la representacin del dominio de
una aplicacin en forma natural y directa, en trminos de los objetos que
intervienen en dicha aplicacin. Este enfoque atae tambin a las BD. La
figura 1 muestra una descomposicin de los objetos vs. la
descomposicin funcional y jerrquica. La representacin de tales
objetos se hace en forma abstracta definiendo su estructura y su
comportamiento.
Base de Datos II 100
Figura 1. Descomposicin funcional y de objetos.

Los conceptos de la orientacin por objetos se remontan a los aos 60
con la aparicin del lenguaje de simulacin llamado Simula67, donde los
objetos existen por s mismos conteniendo sus datos y sus operaciones,
y adems se comunican entre s por medio de mensajes. Tambin fue en
este lenguaje donde se introdujo la nocin de clase de objetos, que
describen la estructura y el comportamiento de todos los objetos que
pertenecen a la clase, la nocin de herencia entre las clases siguiendo
una jerarqua de las mismas, y por ltimo, la nocin de dos tipos de
igualdad: la igualdad en valores (shallow equality) y la identidad (deep
equality).
V.19. Un lenguaje de modelado unificado UML

Los mtodos estructurados y funcionales aparecieron primero, inspirados
directamente de la arquitectura de los computadores. Los mtodos OO
comienzan a emerger a inicios de los aos 80, ellos se articulan
alrededor de las nociones de clases y asociaciones (James Rumbaugh),
de divisiones en subsistemas (Grady Booch) y de la expresin de los
requerimientos a partir del estudio de la interaccin entre usuarios y
sistemas (los casos de uso de Ivar Jacobson).
A finales de 1994, Rumbaugh y Booch deciden unificar sus trabajos en
un mtodo nico, el mtodo unificado. El ao siguiente se une al grupo
Jacobson y fijan cuatro objetivos de trabajo:
Representar sistemas enteros siguiendo la OO

Establecer una conexin explcita entre los conceptos y los
elementos ejecutables
Tomar en cuenta los factores inherentes a los sistemas complejos y
crticos
Crear un lenguaje de modelado que pueda ser usado por humanos

y por mquinas
As, en octubre de 1995 aparece el mtodo unificado V0.8, luego en

junio 1996, la versin 0.9 y por ltimo, este mtodo se transforma el 17
de enero de 1997 en un lenguaje universal para el modelado de objetos
denominado UML 1.0 (The Unified Modeling Language for Object-
Oriented Development).
V.20. Conceptos bsicos de la OO y su representacin en UML
Los conceptos de la orientacin por objetos se basan en la manipulacin

de representaciones abstractas de los objetos plasmadas en su
definicin y su comportamiento. Un objeto se define entonces como la
representacin de algo que se describe mediante una estructura y un
comportamiento. La estructura de un objeto describe aquellas
caractersticas de inters presentes en el objeto y que sirven para
plasmar el estado de ese objeto, siendo el estado de un objeto el
conjunto de valores actuales almacenados en su estructura, que est
escondida. El comportamiento del objeto est representado por una
serie de operaciones, funciones o mtodos que modifican no el estado
del objeto, haciendo que ocurra un cambio de estado en el mismo, el
cual representa el comportamiento visible del objeto en la realidad. As,
el comportamiento del objeto est dado por sus cambios de estado. La
notacin UML para los objetos (un rectngulo con el nombre del objeto
subrayado), los enlaces que pueden existir entre ellos (una lnea
continua que conecta dos objetos) y la invocacin de sus operaciones
por medio del pase de mensajes (una flecha indicando la direccin y el
nombre del mensaje), en base al contenido de algunos de sus atributos.
Un objeto puede ser conocido y descrito por medio de sus propiedades o
atributos que son ilimitados. Un mensaje es el soporte de una relacin
de comunicacin que relaciona en forma dinmica los objetos separados
por el proceso de descomposicin. Los atributos se representan en UML
con sub-rectngulos conteniendo un valor subrayado, dentro del
rectngulo del objeto. Una nota, representada con un rectngulo con la
esquina doblada, indica una clarificacin o descripcin, en formato libre,
para facilitar la comprensin del diagrama. Una nota est ligada a los
objetos por medio de una lnea discontinua para indicar a que objeto
pertenece la nota.
Un objeto puede componerse de dos o ms objetos, conformando as un

objeto compuesto. Cada objeto tiene un nico identificador que es
asignado por el sistema, para aquellos sistemas que soportan la
identidad del objeto.
Los atributos son las propiedades relevantes de un objeto que

representa su estructura. Ellos pueden ser simples o monovaluados, en
el caso que ellos contengan un nico valor a la vez, y multivaluados
cuando pueden contener varios valores a la vez.
La existencia de un objeto es independiente de los valores de sus

atributos, as dos objetos son idnticos si ellos son el mismo objeto, es
decir sus identificadores son iguales (deep equality), o ellos son iguales
si tienen los mismos valores en sus atributos (shallow equality). En un
sistema o lenguaje que no soporta identidad del objeto, la
representacin grfica de los objetos es un rbol. En los sistemas que si
la soportan es un grafo, ya que los objetos compuestos pueden
compartir componentes.
Una operacin es una funcin asociada al objeto que efectua una accin
atmica sobre el mismo. Tal accin puede no modificar el estado del
objeto.
Figura 2. Objetos con enlaces, operaciones y pase de mensajes.

V.21. TIPOS ABSTRACTOS DE DATOS Y SU ESPECIFICACIN
Un tipo abstracto de dato (TAD) se basa en la separacin clara entre su

implantacin y el uso del TAD a travs de su interfase, que es la cara
visible del TAD. Ello implica que un TAD tiene una interfaz y puede tener
varias implantaciones. La definicin de un TAD se hace en dos partes: la
especificacin y la implementacin.
La especificacin por axiomas algebraicos para el tipo T se compone de:

una especificacin sintctica donde se definen los nombres, dominios y
rangos de las operaciones sobre T; y una especificacin semntica que
est compuesta del conjunto de axiomas en forma de ecuaciones, que
dicen como opera cada una de las operaciones especificadas sobre las
otras.
La implementacin se compone de: una representacin que especifica
como los valores del TAD sern almacenados en la memoria, es decir su
estructura de datos, y los algoritmos que especifican como ser usada y
manipulada la estructura de datos, es decir las operaciones del TAD.
El acceso al TAD es hecho a travs de su interfaz que es visible para los

usuarios de ella. La implementacin del TAD es invisible para el usuario
y es visible para el que desarrolla el TAD.
Como un ejemplo de esto se presenta aqu la especificacin del tipo

abstracto de dato: Pila. Tal especificacin ser hecha para una pila no
limitada.
Tipo de dato: Pila[elemento:tipoEle]

Especificacin sintctica:
creaPila() -> Pila, Crea la pila
Inserta un nuevo elemento en el
meterElePila(Pila,tipoEle) -> Pila,
tope
Elimina el elemento que est en el
sacarElePila(Pila) -> Pila,
tope
conTopePila(Pila) -> tipoEle \/Consulta el elemento que est en
{TipoEleNoDef}, el tope
vacaPila(Pila) -> Lgico, Verifica si la pila est vaca
destruyePila(Pila) -> . Destruye la pila
Especificacin semntica:
Declaracin: P: Pila, el: tipoEle;

sacarElePila(creaPila()) = creaPila()
conTopePila(creaPila()) = {TipoEleNoDef}
conTopePila(meterElePila(P,el)) = el
vacaPila(creaPila()) = Verdadero
vacaPila(meterElePila(P,el)) = Falso
Con la especificacin sintctica se pueden ver claramente cules son las

operaciones primitivas vlidas sobre la estructura y cules son los tipos
de datos que cada una regresa, luego que se ha efectuado la operacin.
Para mayor claridad, vase la operacin sacarElePila() que necesita para
operar la Pila, devolviendo la misma Pila pero disminuida en tamao por
un elemento, ya que ella suprime el elemento que est colocado en el
tope de la Pila. En esta especificacin se incluyen unicamente aquellas
operaciones que son bsicas para el TAD, es decir las operaciones que
sirven de base para construir cualquier otra operacin sobre el tipo. Por
ejemplo, en la mayora de las estructuras de datos es til tener una
operacin que vace o limpie la estructura, en el caso de la Pila, sera la
operacin vaciarPila(Pila)->Pila. Dicha operacin no aparece en la
especificacin del TAD Pila, pues ella puede ser construida invocando
varias veces la operacin sacarElePila(Pila) hasta que vacaPila(Pila) sea
verdadero. Por lo tanto, las operaciones que aparecen en una
implementacin cualquiera de un TAD no tienen por que ser iguales, en
nmero, a las de la especificacin del mismo.
Con la especificacin semntica se observa el efecto que tiene cada una
de las operaciones especificadas sobre las otras. Por ejemplo: Qu
sucede si se desea saber si la Pila est vaca, habindose recien creado?,
esto es vacaPila(creaPila()), el resultado es Verdadero, ya que aunque la
pila existe, ella ha sido recientemente creada y por ello, est vaca. En el
caso de conTopePila(creaPila()), el resultado es un valor especial
denominado TipoEleNoDef, esto es tipoElemento no definido, para
expresar que no puede regresarse elemento alguno, pues la pila est
vaca. Este valor especial para el debe estar definido en la
implementacin del tipo abstracto de dato.
Para llevar a la prctica esta especificacin debe escogerse una

representacin fsica para el tipo Pila, ella puede ser una de las
siguientes: la secuencial, donde los elementos de la Pila estn contigos
en memoria; o el enlazado, donde esos elementos estn esparcidos en
la memoria y encadenados mediante punteros al siguiente. Ambas
implantaciones, las hechas con las representaciones mencionadas,
deben tomar en cuenta que la memoria es finita, y por ello tal
especificacin es lo que es, una especificacin para un tipo abstracto de
dato. Ella diferir en algunos detalles de la implementacin realizada
basndose en ella.
V.22. Mecanismos de la abstraccin de datos

La clasificacin es la agrupacin de objetos con propiedades y
comportamiento similares dentro de una clase. Una clase es un objeto
que define la estructura y el comportamiento de un conjunto de objetos
que tienen el mismo patrn estructural y de comportamiento. Cada
objeto que pertenece a una clase es una instancia de ella. En UML, cada
clase se representa con un rectngulo dividido en tres compartimentos.
El primero indica el nombre de la clase, que debe permitir la
comprensin de lo que es la clase y NO lo que ella hace. El segundo
contiene los atributos expresados con su nombre, su tipo y un valor
inicial por omisin, en caso de ser necesario, y el tercero indica sus
operaciones expresadas con el nombre de la operacin, sus argumentos
entre parntesis, expresados como nombre del argumento, su tipo y su
valor por omisin, si es necesario; y por ltimo el tipo de resultado que
devuelve la operacin. Cada uno de los atributos y operaciones va
antecedido por un caracter que indica el tipo de acceso o la visibilidad
de dicho parmetro en la clase. Estos son: (+) para los pblicos, (#) para
los protegidos, (-) para los privados, (7) para los atributos calculados por
alguna operacin definida en la clase, y el parmetro subrayado para los
de la clase, lo que hace que existan atributos y operaciones de la clase y
no de las instancias de la clase. La figura 3 presenta la estructura de una
clase y un ejemplo.
El conjunto de todas las instancias de una clase es la extensin de la

clase. La instanciacin es el proceso de generacin o creacin de las
instancias de una clase. La definicin de una clase normalmente
contiene: su nombre, el nombre de sus superclases (clases de las que se
hereda), su interfaz, su estructura y su implementacin. En UML, la
interfaz de una clase se representa con un crculo pequeo enlazado a la
clase y sirve para describir el comportamiento visible de la clase. La
interfaz tambin puede representarse con una clase que lleve debajo de
su nombre el estereotipo <<interfaz>>. Las clases parametrizables son
modelos de clases que se corresponden con clases genricas como los
templates de C++. Ellas se representan en UML con la misma
representacin de una clase, pero lleva en la esquina superior derecha
del rectngulo, otro rectngulo ms pequeo en lneas entrecortadas. La
instanciacin de esta clase con el tipo deseado se materializa con una
flecha de lnea entrecortada orientada hacia la clase parametrizable. La
figura 4 muestra ambas representaciones. Existen tambin en UML las
clases utilitarias, ellas sirven para indicar aquellas clases de librera o
funciones agrupadas en libreras, por ejemplo las clases en C++ que
contienen solamente miembros estticos. Se indican con <<utilitaria>>.
Las clases abstractas no pueden ser instanciadas, ya que ellas no crean
objetos sino que sirven de especificacin general. Ellas se indican con la
palabra abstracta en itlicas.
Figura 4. Clases parametrizables y utilitarias en UML.

Las clases formarn una jerarqua denominada jerarqua de clases,
donde las clases superiores a una clase particular se denominan
superclases y a la clase particular se le llama subclase. La relacin entre
una superclase y una subclase se denomina ES-UN(A). La metaclase es
la clase que define todas las clases del sistema. La figura 5 presenta un
ejemplo de una jerarqua de clases en notacin grfica UML. Cada
rectngulo representa una clase de objetos. Sus divisiones indican:
primero, el nombre de la clase; a continuacin, la estructura de las
instancias de la clase; y por ltimo, las operaciones o mtodos que
tabajan sobre las instancias de la misma. La metaclase se indica con
<<metaclase>>.
Figura 5. Jerarqua de clases en UML.

La generalizacin es un proceso de abstraccin en el cual un conjunto de

clases existentes, que tienen atributos y operaciones comunes es
referido por una clase genrica a un nivel mayor de abstraccin. La
generalizacin corresponde a la relacin ES-UN(A) entre las clases. En la
figura 5 pudo haber habido una generalizacin, si las clases Empleado y
Estudiante fueron realizadas antes y una vez que se tuvieron, se decidi
crear una nueva clase genrica denominada Persona, para contener los
atributos y operaciones comunes a las clases ya implementadas, ya que
tanto Estudiante como Empleado son Personas.
La especializacin o particularizacin es el proceso inverso de la

generalizacin, ya que una subclase se crea a partir de una clase ya
existente. Este es el proceso que soportan la mayora de los sistemas
orientados por objetos. La figura 5 muestra un ejemplo de ello, si se crea
la clase Preparador como subclase de Estudiante y de Empleado. Una
clase puede tener varias superclases, denominndose una
generalizacin o especializacin mltiple. La figura 6 muestra esta
situacin para una alfombra voladora.
Las asociaciones representan relaciones estructurales entre las clases,

ellas se representan en UML con una lnea. Las asociaciones pueden ser
binarias, terciarias o de mayor aridad. Las asociaciones n-arias
generalmente se representan promoviendo la asociacin al rango de
clase y agregando una restriccin que expresa que las mltiples ramas
se instancian todas simultneamente, como se muestra en la figura 7.
Las asociaciones pueden llevar un nombre, en itlicas y que
normalmente se expresa en forma activa, i.e. trabaja para, o en forma
pasiva, i.e. es empleado por. En ambos casos se puede indicar el sentido
de lectura con < >. As tambin, se pueden expresar los roles al
extremo de las asociaciones y la multiplicidad de las mismas expresadas
como: 1: slo uno; 0..1: cero o uno; 0..*: de cero a muchos; 1..*: de uno
a muchos. Ellas tambin pueden llevar restricciones entre parntesis:
{ordenado}, {subconjunto}, {exclusivo}, etc. como lo muestra la figura
8. Tambin pueden existir subasociaciones o asociacin reflexiva, de una
clase con ella misma; y puede calificarse las asociaciones para
seleccionar un subconjunto de objetos que participan en la asociacin
por medio de una clave, simple o compuesta, que pertenece a la
asociacin y no a la clase. Estas situaciones se muestran en la figura .
Figura 6. Generalizacin exclusiva, inclusiva e incompleta en UML.
Figura 7. Asociacin ternaria en UML.
Figura 8. Roles de asociacin en UML.

Figura 9. Restricciones y claves de asociacin en UML.
La agregacin permite definir clases segn los criterios siguientes:
Una clase forma parte de otra

Los valores de los atributos de una clase se propagan en los valores de
los atributos de otra
Una accin sobre una clase implica una accin sobre otra
Los objetos de una clase estn subordinados a los objetos de otra
La figura 10 presenta un ejemplo de agregacin. La composicin es un
caso particular de la agregacin, ella se utiliza para indicar clases de
objetos compuestos, ya que coloca atributos en la clase que pertenecen
a otra clase. Ella representa la relacin ES-PARTE-DE entre una entidad
compuesta y sus entidades componentes. Ambas representan una
relacin no simtrica en la que una de las extremidades juega un rol
predominante en relacin a la otra, por lo cual slo lleva un rol. La figura
10 muestra el diagrama UML de una clase de objetos compuestos.
Figura 10. Agregacin y composicn en UML.
El protocolo o interfaz es el conjunto de operaciones o mtodos

declarados como posibles de invocar o activar por los otros objetos. Los
mensajes son la especificacin de un objeto junto con la invocacin de
uno de sus mtodos. Por lo general, el pase de mensajes tiene la forma
objetoDestino.nombreDelMtodo(listaDeArgumentos)
La encapsulacin es la propiedad que permite que los objetos sean

definidos en su estructura y su comportamiento, obligando al uso del
pase de mensajes o de la invocacin de sus mtodos, si se quiere

acceder al objeto.
La herencia es la propiedad que tienen las clases de heredar de sus

superclases estructura y/o comportamiento. La herencia estructural es
aquella donde se hereda la estructura y la herencia de comportamiento
cuando se heredan los mtodos. La herencia se puede tipificar como:
simple o mltiple. La herencia simple se da cuando la subclase hereda
solamente de una superclase, y es mltiple cuando hereda de varias
superclases. La herencia mltiple presenta problemas de ambigedad
cuando hay atributos o mtodos con el mismo nombre en varias de las
superclases. La solucin a dicho problema es la declaracin explcita de
cada uno de ellos junto con la superclase de la que se hereda.
En la figura 5 se puede ver un ejemplo de herencia simple, la subclase
Estudiante, y un ejemplo de herencia mltiple, la subclase Preparador.
Esta ltima debe explicitar la herencia de los atributos y mtodos de
Persona a travs de una de sus dos superclases, para evitar
ambigedades en el pase de mensajes.
Polimorfismo significa que se puede usar el mismo nombre para la

definicin de un mtodo en varias clases sin importar la relacin entre
las mismas. Ejemplo: el operador + para tipos numricos y para tipos
caracter. Para que el polimorfismo sea posible se utilizan los conceptos
de: reescritura y encadenamiento tardo o dinmico. La reescritura o
sobrecarga es la que permite nombrar cdigo diferente con el mismo
nombre para ms de una clase de objetos. El encadenamiento tardo
permite seleccionar el cdigo adecuado al objeto definido en la
invocacin del mtodo. Un ejemplo de ello se puede observar en la
figura donde el mtodo desplegar() se define para cada una de las
clases de dicha figura.
V.23. Notacin UML

Es una fusin de las notaciones de Booch, OMT, OOSE y otras. UML ha
sido concebida para ser simple, intuitiva, homognea, coherente,
genrica y para ser extensible y configurable por el usuario.
V.24. Elementos comunes

Los elementos son la base de UML, que pueden ser: de modelado y de
visualizacin, como lo muestra la figura 11. Los elementos se agrupan
en paquetes que contienen referencias a los elementos de modelado. Un
modelo es una abstraccin de un sistema representado por un rbol de
paquetes.
Figura 11. Metamodelo de UML.
V.25. Mecanismos comunes

Definen y aseguran la integridad conceptual de la notacin UML y se
componen de: los estereotipos, las etiquetas, las notas, las restricciones,
la relacin de dependencia y las dicotomas (tipo, instancia) y (tipo,
clase). Cada elemento de modelado posee una especificacin que
contiene la descripcin nica y detallada de todas las caractersticas del
elemento. Los estereotipos (clichs) especializan las clases del
metamodelo, las etiquetas extienden los atributos de las clases del
metamodelo y las restricciones extienden la semntica del metamodelo,
todos ellos permiten la extensin de UML. La figura 12 muestra los
mecanismos comunes.
Figura 12. Metamodelo de UML. Mecanismos comunes.

Los estereotipos facilitan la unificacin de conceptos cercanos como los
subsistemas y las categoras, permiten la extensin controlada de las
clases del metamodelo. Se representan con <<nombre del
estereotipo>>.
Etiqueta es un par (nombre, valor) que describe una propiedad de un
elementos de modelado, ella modifica la semntica del elemento que
califica.
Una nota es un comentario asignado a uno o varios elementos de
modelado.
Una restriccin es una relacin semntica cualquiera entre los elementos
de modelado, que se pueden expresar en lenguaje natural, en
pseudocdigo, con expresiones de navegacin o por expresiones
matemticas.
Una relacin de dependencia define una relacin de uso unidireccional
entre dos elementos de modelado, denominados fuente y blanco de la
relacin, respectivamente. Las notas y las restricciones pueden ser
fuente de una relacin de dependencia.
Numerosos elementos de modelado representan una dicotoma (tipo,
instancia) en la cual el tipo denota la esencia del elemento y la instancia
con sus valores corresponde a una manifestacin del tipo. La dicotoma
(tipo, clase) corresponde a la separacin entre la especificacin de un
elemento que es denotado por el tipo y la realizacin de esa
especificacin que est dada por la clase.
V.26. Tipos primitivos

Son los tipos elementales que no son elementos de modelado y no
poseen ni estereotipos, ni etiquetas ni restricciones. Ellos son:
Booleano: es un tipo enumerado con dos valores: Verdadero y falso.
Expresin: es una cadena de caracteres.
Lista: es un contenedor donde el contenido puede ser ordenado e
indizado.
Multiplicidad: es un conjunto no vaco de enteros positivos extendido con
*, que significa de multiplicidad ilimitada.
Nombre: es una cadena de caracteres que designa un elemento. Nombre
compuesto = nombre simple {'.' nombre compuesto}. Nombre calificado
con el paquete al que pertenece = paquete '::' nombre
Punto: es una tupla (x, y, z) que indica la posicin en el espacio, por
omisin z = 0.
Cadena: es una cadena de caracteres que tiene un nombre.
Tiempo: es una cadena que representa un tiempo absoluto o relativo.
No interpretado: es un blob, cuyo significado depende del dominio.
V.27. Paquetes
Permiten dividir un modelo y reagrupar y encapsular los elementos de
modelado y se representa con una carpeta con nombre, como lo
muestra la figura 13. Poseen una interfaz y una realizacin. Cada uno de
sus elementos posee un parmetro que indica si es o no visible al
exterior del paquete. Se recomienda que el grafo de paquetes sea un
grafo acclico.
V.28. Los diagramas de UML

Ellos permiten visualizar y manipular los elementos de modelado.
Normalmente son grafos donde los nodos y los arcos tienen diferentes
representaciones dependiendo del tipo de diagrama. Ellos muestran
todo o parte de las caractersticas de los elementos de modelado, segn
el nivel de detalle til en el contexto del diagrama. La lista de los
diagramas es la siguiente:
Diagrama de clases: representa la estructura esttica en trminos de
clases y asociaciones. Se realizan con las clases y sus asociaciones, que
pueden o no ir en paquetes. La figura 14 muestra un ejemplo.
Figura 14. Diagrama de clases en UML.

Diagrama de casos de uso: representa las funciones del sistema desde
el punto de vista del usuario. Un caso de uso es una secuencia de
acciones efectuadas por un actor del sistema, es decir, ellos permiten
definir los lmites del sistema y sus relaciones con el ambiente, haciendo
concreto el futuro sistema en una formalizacin cercana al usuario, as
no exista un sistema anterior. En UML se representan con una elipse
contenida por el sistema. La figura 15 presenta un ejemplo. Un actor
representa el rol jugado por una persona o cosa que interactua con el
sistema. La misma persona puede jugar varios roles y varias personas
pueden jugar el mismo rol. Hay cuatro grandes categoras de actores:
Principales: las personas que utilizan las funciones principales.
Secundarios: las personas que efectuan tareas administrativas o de
mantenimiento.
Externos: los dispositivos que forman parte del dominio de aplicacin y
que deben ser utilizados.
Otros sistemas: los sistemas con los que debe interactuar.
Figura 15. Casos de uso en UML.
Los actores se describen de forma clara y concisa en tres o cuatro lneas.

Los casos de uso se determinan observando y precisando, actor por
actor, las secuencias de interaccin (escenarios) desde el punto de vista
del usuario. Un escenario es un camino particular a travs de la
descripcin abstracta y general dada por el caso de uso. Un caso de uso
agrupa una familia de escenarios de uso segn un criterio funcional. Los
casos de uso se ven como clases cuyas instancias son los escenarios.
Las relaciones entre los casos de uso son: comunicacin, donde el actor
inicia la interaccin indicado con una flecha; utilizacin, donde una
instancia del caso de uso fuente utiliza el comportamiento del caso de
uso destino; y extensin, donde un caso de uso extiende el caso de uso
destino. En general, slo hay un actor por cada caso de uso y para su
realizacin es conveniente responder las preguntas siguientes: Cules
son las tareas del actor?, Cules datos o informacin el actor debe
crear, guardar, modificar, destruir o leer?, Debe el actor informar al
sistema de los cambios externos? y Debe el sistema informar al actor
las condiciones internas?. La descripcin se debe concentrar en lo que
DEBE HACERSE y NO en la manera de hacerlo. La descripcin de un caso
de uso contiene: su inicio (que evento lo dispara), su fin (que evento lo
para), la interaccin con los actores, el intercambio de informacin, la
cronologa y origen de las informaciones, las repeticiones de
comportamiento y las situaciones opcionales. Si un caso de uso es muy
complejo (por ejemplo ms de diez pginas) es posible dividirlo en casos
ms pequeos. El enfoque orientado por objetos materializa un caso de
uso por medio de la colaboracin entre los objetos. Los escenarios se
representan con los diagramas de interaccin.
Diagrama de estado-transicin: representa el comportamiento de una

clase en trmino de sus estados. La figura 16 muestra un ejemplo.
Diagrama de actividades: representa el comportamiento de una

operacin en trminos de sus acciones. La figura 17 presenta un
ejemplo.
Figura 16. Diagrama de estado-transicion en UML.

Figura 17. Diagrama de actividades en UML.
Diagrama de secuencias:
es una representacin temporal de los objetos y sus interacciones. La
figura 18 muestra un ejemplo.
Figura 18. Diagrama de secuencias en UML.
Diagrama de colaboracin:
es una representacin espacial de los objetos, sus enlaces y sus interacciones.
(junto con los de secuencias se denominan, diagramas de interaccin). La
figura 19 presenta un ejemplo.
Figura 19. Diagrama de colaboracion en UML.
Diagrama de objetos:
representan los objetos y sus relaciones, corresponden a diagramas de
colaboracin simplificados sin representacin de los envios de mensajes. La
figura 20 muestra un ejemplo.
Figura 20. Diagrama de objetos en UML.
Diagrama de componentes: representa las componentes fsicas de la

aplicacin.
Diagrama de despliegue: representa el despliegue de las componentes
sobre los dispositivos fsicos.
V.29. Metamodelo
Numerosos elementos de modelado presentan la dicotoma (esencia,
manifestacin) por la cual un tipo representa la esencia de una abstraccin y la
instancia es la manifestacin concreta, asimismo la dicotoma (especificacin,
realizacin) donde las clases y los tipos primitivos realizan los tipos. Un tipo
especifica un dominio de valores y un conjunto de operaciones aplicables a
esos valores. Una clase realiza un tipo. La figura 23 ilustra tales dicotomas. La
clase Tipo comprende las clases: tipo primitivo (entero o enumerado), clase
y caso de uso. La clase Clase comprende: clase activa que tiene un o varios
flujos de ejecucin; seal que es un evento con nombre; componente que es
un elemento reutilizable de componentes fsicas y nodo que es un dispositivo
fsico sobre el cual las componentes pueden ser desplegadas para su
ejecucin.
Figura 23. Metamodelo de las clases en UML.
UML define cinco relaciones, la ms general, la relacin de dependencia se

aplica de forma uniforme a todos los elementos de modelado. La asociacin y
la generalizacin conciernen a todos los tipos, en particular a las clases y a
los casos de uso. Las transiciones y los enlaces se aplican a ciertos
elementos de modelado del comportamiento. La figura 24 ilustra estas
relaciones. La asociacin representa una conexin semntica bidireccional
entre tipos, posee al menos dos roles, cada rol tiene los atributos siguientes:
Figura 24. Metamodelo de las relaciones en UML.
Multiplicidad: especifica el nmero de instancias que participan en

la relacin.
Navegabilidad: precisa si los enlaces, instancias de asociacin, son
navegables en la direccin del rol considerado.
Agregabilidad: especifica si las instancias del tipo asociado al rol
son el todo en una relacin (todo, partes). Slo uno de los roles puede
tener este atributo en verdadero. Si la multiplicidad del rol es 1,
significa que el todo posee las partes y por ello la destruccin del
todo implica la destruccin de las partes. Si la multiplicidad es mayor
que 1, varias instancias juegan el rol de todo y comparten las partes,
la destruccin de una de las instancias del todo no implica la
destruccin de las partes, slo la destruccin de todas las instancias
del todo implica la destruccin de las partes.
Cambiable: precisa si la semntica de la asociacin se mantiene
luego de que una instancia del tipo que participa en el rol es
reemplazada por otra.
Ordenada: se aplica si la multiplicidad es mayor que 1 y significa
que las instancias estn ordenadas.
La generalizacin especifica una relacin de clasificacin por la que una
instancia de un subtipo puede ser substituida por una instancia del
supertipo. Un supertipo puede tener varios subtipos y un subtipo puede
tener varios supertipos. Todo elemento generalizable posee los atributos
lgicos siguientes:
Abstracto: Si es verdadero indica que el elemento no puede ser
instanciado directamente.
Hoja: Si es verdadero indica que el elemento no puede tener
subtipos.
Raz: Si es verdadero indica que el elemento no puede tener
supertipos.
UML define tres elementos generalizables: stereotipo (no puede tener

subtipos), paquete (no puede tener supertipos) y tipo. La figura 25
muestra la relacin de generalizacin y de dependencia. La dependencia
es una relacin de uso unidireccional entre los elementos.
Figura 25. Metamodelo de las generalizaciones y dependencias en UML.
V.30. Ventajas y desventajas de la orientacin por objetos
Las ventajas de la programacin orientada por los objetos son las

siguientes:
La abstraccin de datos y el ocultamiento de la informacin
aumentan la confiabilidad y ayudan a separar la especificacin de
la implantacin.
El encadenamiento dinmico incrementa la flexibilidad.
La herencia junto con el encadenamiento tardo permite la
reusabilidad aumentando as la productividad.
Entre sus desventajas se encuentran:
El costo de tiempo de ejecucin del encadenamiento tardo puede
llegar a ser importante dependiendo de la aplicacin.
La implantacin con lenguajes orientados por objetos es ms
compleja que con los lenguajes convencionales.
El programador debe leer con frecuencia extensas libreras de
clases.
VI. BASE DE DATOS DISTRIBUIDAS
VI.1. INTRODUCCIN
La cantidad de innovaciones tecnolgicas que ha habido en los ltimos

aos ha promovido un cambio en la forma de observar a los sistemas de
informacin y, en general, a las aplicaciones computacionales. Existen
avances tecnolgicos que se realizan continuamente en circuitos,
dispositivos de almacenamiento, programas y metodologas. Sin
embargo, los cambios tecnolgicos van de la mano con la demanda de
los usuarios y programas para la explotacin exhaustiva de tales
dispositivos mejorados. Por tanto, existe un continuo desarrollo de
nuevos productos los cuales incorporan ideas nuevas desarrolladas por
compaas e instituciones acadmicas.
An cuando es posible que un usuario comn no perciba los desarrollos
relevantes de nuevos productos, para las aplicaciones existe una
demanda permanente por mayor funcionalidad, mayor nmero de
servicios, ms flexibilidad y mejor rendimiento. As, al disear un nuevo
sistema de informacin o al prolongar la vida de uno ya existente, se
debe buscar siempre formas para enlazar las soluciones ofrecidas por la
tecnologa disponible a las necesidades de las aplicaciones de los
usuarios.
Una rea en la cual las soluciones estn integrando tecnologa con
nuevas arquitecturas o formas de hacer las cosas es, sin lugar a dudas,
el rea de los sistemas distribuidos de informacin. Ellos se refieren al
manejo de datos almacenados en facilidades de cmputo localizadas en
muchos sitios ligados a travs de una red de comunicaciones. Un caso
especfico de estos sistemas distribuidos es lo que se conoce como
bases de datos distribuidas, tpico a estudiar en estas notas.
VI.2. MOTIVACION
Existen dos fuerzas que han impulsado la evolucin de los sistemas de
bases de datos. Por un lado los usuarios como parte de organizaciones
ms complejas han demandado una serie de capacidades que se han ido
incorporando en los sistemas de bases de datos (Figura 1.1). Un ejemplo
de esto es la necesidad de integrar informacin proveniente de fuentes
diversas. Por otro lado, la tecnologa ha hecho posible que algunas
facilidades inicialmente imaginadas solo en sueos se conviertan en
realidad. Por ejemplo, las transacciones en lnea que permite el sistema
bancario actual no hubiera sido posible sin el desarrollo de los equipos
de comunicacin. Los sistemas de cmputo distribuido son ejemplos
claros en donde presiones organizacionales se combinan con la
disponibilidad de nuevas tecnologas para hacer realidad tales

aplicaciones.
VI.3. LA PRESIN POR DATOS DISTRIBUIDOS
VI.3.1. LA PRESIN DE LOS USUARIOS

Las bases de datos grandes permiten organizar la informacin
relevantes a alguna parte de la operacin de una organizacin como por
ejemplo servicios de salud, corporaciones industriales o bancos. Casi
cualquier organizacin que ha incorporado sistemas de informacin para
su funcionamiento ha experimentado dos fases.
Figura 1.1. Fuerzas evolucionarias en los sistemas de bases de datos.
En la primera fase, se ha agrupando toda la informacin en un solo

lugar. La idea original era que todos los accesos a datos podran ser
integrados en un solo lugar usando herramientas de bases de datos
tales como lenguajes de descripcin de datos, lenguajes de
manipulacin de datos, mecanismos de acceso, verificadores de
restricciones y lenguajes de alto nivel. Para poder tener estos
mecanismos de almacenamiento y recuperacin de informacin, las
organizaciones hicieron fuertes inversiones en equipos computacionales
sofisticas y con grandes capacidades. Sin embargo, despus de
experimentar por un tiempo con este enfoque, muchas organizaciones
encontraron que el sistema completo era satisfactorio, en algn grado,
para un buen nmero de usuarios pero muy pocos obtenan un servicio
ptimo. Ms an, bajo este esquema centralizado los "propietarios" u
originadores de la informacin especfica perdieron el control sobre el
manejo de su informacin ya que sta no se almacenaba en sus lugares
de trabajo.
Algunos experimentos mostraron que el 90% de las operaciones de

entrada y salida de informacin eran "locales" (correspondientes al
departamento que las generaba) y solo el 10% de tales operaciones
involucraba informacin cruzada (informacin proveniente de ms de un
departamento). As, en la segunda fase se promovi la descentralizacin
de los sistemas de bases de datos corporativos. Entonces, se empezaron
a adquirir sistemas de software y hardware departamentales. Este
enfoque present grandes beneficios para el control de la seguridad de
la informacin y la disponibilidad de la misma. Permiti que los
esquemas de mantenimiento y planeacin de los sistemas de
informacin afectara en menor medida al funcionamiento general de la

organizacin.
Sin embargo, muy pronto empezaron a aparecer inconvenientes con

este enfoque. Se presentaron problemas de consistencia de la
informacin entre los sistemas locales y central y se hallaron dificultados
al transferir informacin de entre departamentos diferentes de una
corporacin.
De esta manera, en una tercera fase (la cual an no ha concluido) se ha

tratado de formalizar la descentralizacin de las bases de datos y de sus
funciones manteniendo la integridad de la informacin y quiz algn tipo
de control centralizado o distribuido.
VI.4. LA PRESIN DE LA TECNOLOGA

Existen buenas razones tcnicas para distribuir datos. La ms obvia es la
referente a la sobrecarga de los canales de entrada y salida a los discos
en donde se almacena finalmente la informacin. Es mucho mejor
distribuir los accesos a la informacin sobre diferentes canales que
concentrarlos en uno solo. Otra razn de peso es que las redes de
computadoras empezaron a trabajar a velocidades razonables abriendo
la puerta a la distribucin del trabajo y la informacin.
El hacer una descentralizacin de la informacin se justifica desde el
punto de vista tecnolgico por las siguientes razones:
Para permitir autonoma local y promover la evolucin de los
sistemas y los cambios en los requerimientos de usuario.
Para proveer una arquitectura de sistemas simple, flexible y
tolerante a fallas.
Para ofrecer buenos rendimientos.
Existen aplicaciones que nacieron distribuidas. Para ellas ha sido
necesario el uso de nuevas tecnologas para integrar sistemas de
informacin diferentes, de forma que, no se afecte de manera sustancial
el estilo de trabajo o de hacer las cosas de los usuarios.
Aunque la idea de distribucin de datos es bastante atractiva, su
realizacin conlleva la superacin de una serie de dificultades
tecnolgicas entre las que se pueden mencionar:
Asegurar que el acceso entre diferentes sitios o nodos y el
procesamiento de datos se realice de manera eficiente,
presumiblemente ptima.
Transformar datos e integrar diferentes tipos de procesamiento
entre nodos de un ambiente distribuido.
Distribuir datos en los nodos del ambiente distribuido de una
manera ptima.
Controlar el acceso a los datos disponibles en el ambiente

distribuido.
Soportar la recuperacin de errores de diferentes mdulos del
sistema de manera segura y eficiente.
Asegurar que los sistemas locales y globales permanezcan como
una imagen fiel del mundo real evitando la interferencia
destructiva que pueden ocasionar diferentes transacciones en el
sistema.
As tambin, la aplicacin de tcnicas de distribucin de informacin
requiere de superar algunas dificultades de ndole organizacional y
algunas otras relacionadas con los usuarios. Entre ellas se puede
mencionar:
El desarrollo de modelos para estimar la capacidad y el trfico
esperado en el sistema distribuido.
Soportar el diseo de sistemas de informacin distribuidos. Por
ejemplo, ayudar a decidir donde localizar algn dato particular o
donde es mejor ejecutar un programa de aplicacin.
Considerar la competencia que habr por el uso de los recursos
entre nodos diferentes.
Aun cuando las dificultades mencionadas son importantes, las ventajas
de la distribucin de informacin han promovido su aplicacin en
ambientes del presente y del futuro.
VI.5. HETEROGENEIDAD Y LA PRESIN PARA INTEGRAR DATOS

La descentralizacin de los sistemas de informacin y el advenimiento
de los sistemas distribuidos estn bien justificados. Sin embargo, existe
todava un argumento importante para el desarrollo de sistemas de
bases de datos distribuidas; ste se refiere a la integracin de
necesidades de procesamiento no locales en donde es necesario
intercambiar informacin proveniente de otras reas o departamentos.
La descentralizacin de la informacin promueve la heterogeneidad en
su manejo. La heterogeneidad se puede dar a muchos niveles, desde la
forma y significado de cada dato hasta el formato y el medio de
almacenamiento que se elige para guardarlo. La integracin de la
informacin es de importancia mayor para el funcionamiento de una
organizacin.
En resumen, en los sistemas de bases de datos distribuidas se persigue

la integracin de sistemas de bases de datos diversos no
necesariamente homogneos para dar a los usuarios una visin global
de la informacin disponible. Este proceso de integracin no implica la
centralizacin de la informacin, ms bien, con la ayuda de la tecnologa
de redes de computadoras disponible, la informacin se mantiene
distribuida (localizada en diversos lugares) y los sistemas de bases de
datos distribuidos permiten el acceso a ella como si estuviera localizada
en un solo lugar. La distribucin de la informacin permite, entre otras

cosas, tener accesos rpidos a la informacin, tener copias de la
informacin para accesos ms rpidos y para tener respaldo en caso de
fallas.
VI.6. COMPUTACIN DISTRIBUIDA
Los sistemas de bases de datos distribuidas son un caso particular de los

sistemas de cmputo distribuido en los cuales un conjunto de
elementos de procesamiento autnomos (no necesariamente
homogneos) se interconectan por una red de comunicaciones y
cooperan entre ellos para realizar sus tareas asignadas. Histricamente,
el cmputo distribuido se ha estudiado desde muchos puntos de vista.
As, es comn encontrar en la literatura un gran nmero de trminos que
se han usado para identificarlo. Entre los trminos ms comunes que se
utilizan para referirse al cmputo distribuido podemos encontrar:
funciones distribuidas, procesamiento distribuido de datos,
multiprocesadores, multicomputadoras, procesamiento satelital,
procesamiento tipo "backend", computadoras dedicadas y de propsito
especfico, sistemas de tiempo compartido, sistemas funcionalmente
modulares.
Existen muchas componentes a distribuir para realizar una tarea. En

computacin distribuida los elementos que se pueden distribuir son:
Control. Las actividades relacionadas con el manejo o
administracin del sistema.
Datos. La informacin que maneja el sistema.
Funciones. Las actividades que cada elemento del sistema realiza.
Procesamiento lgico. Las tareas especficas involucradas en una
actividad de procesamiento de informacin.
Figura 1.2. Motivacin de los sistemas de bases de datos distribuidos.

VI.7. SISTEMAS DE BASES DE DATOS DISTRIBUIDAS
Una base de datos distribuida (BDD) es un conjunto de mltiples

bases de datos lgicamente relacionadas las cuales se encuentran
distribuidas entre diferentes sitios interconectados por una red de
comunicaciones (ver Figura 1.2).
Un sistema de bases de datos distribuida (SBDD) es un sistema en
el cual mltiples sitios de bases de datos estn ligados por un sistema
de comunicaciones, de tal forma que, un usuario en cualquier sitio
puede accesar los datos en cualquier parte de la red exactamente como
si los datos estuvieran almacenados en su sitio propio.
Un sistema de manejo de bases de datos distribuidas (SMBDD) es
aquel que se encarga del manejo de la BDD y proporciona un
mecanismo de acceso que hace que la distribucin sea transparente a
los usuarios. El trmino transparente significa que la aplicacin
trabajara, desde un punto de vista lgico, como si un solo SMBD
ejecutado en una sola mquina, administrara esos datos.
Un sistema de base de datos distribuida (SBDD) es entonces el

resultado de la integracin de una base de datos distribuida con un
sistema para su manejo.
Dada la definicin anterior, es claro que algunos sistemas no se pueden
considerar como SBDD. Por ejemplo, un sistema de tiempo compartido
no incluye necesariamente un sistema de manejo de bases de datos y,
en caso de que lo haga, ste es controlado y administrado por una sola
computadora.
Un sistema de multiprocesamiento puede administrar una base de datos
pero lo hace usualmente a travs de un solo sistema de manejo de base
de datos; los procesadores se utilizan para distribuir la carga de trabajo
del sistema completo o incluso del propio SMBD pero actuando sobre
una sola base de datos. Finalmente, una base de datos la cual reside en
un solo sitio de una red de computadoras y que es accesada por todos
los nodos de la red no es una base de datos distribuida (Figura 1.3). Este
caso se trata de una base de datos cuyo control y administracin esta
centralizada en un solo nodo pero se permite el acceso a ella a travs de
la red de computadoras.
El medio ambiente tpico de un SMBDD consiste de un conjunto de sitios
o nodos los cuales tiene un sistema de procesamiento de datos
completo que incluye una base de datos local, un sistema de manejo de
bases de datos y facilidades de comunicaciones. Si los diferentes sitios
pueden estar geogrficamente dispersos, entonces, ellos estn
interconectados por una red de tipo WAN. Por otro lado, si los sitios
estn localizados en diferentes edificios o departamentos de una misma
organizacin pero geogrficamente en la misma ubicacin, entonces,
estn conectados por una red local (LAN) (Figura 1.4).
Figura 1.3. Un sistema centralizado sobre una red.
Figura 1.4. Un medio ambiente distribuido para bases de datos.
VI.8. Ambientes con mltiples procesadores

Desde el punto de vista de las bases de datos, conceptualmente existen
tres tipos de ambientes que se integran con mltiples procesadores:
Arquitecturas de memoria compartida. Consisten de diversos
procesadores los cuales accesan una misma memoria y un misma
unidad de almacenamiento (uno o varios discos). Algunos ejemplos de
este tipo son las computadoras Sequent Encore y los mainframes
IBM4090 y Bull DPS8 (Figura 1.5).
Figura 1.5. Arquitectura de memoria compartida.

Arquitecturas de disco compartido. Consiste de diversos procesadores
cada uno de ellos con su memoria local pero compartiendo una misma
unidad de almacenamiento (uno o varios discos). Ejemplos de estas
arquitecturas son los cluster de Digital, y los modelos IMS/VS Data
Sharing de IBM (Figura 1.6).
Figura 1.6. Arquitectura de disco compartido.

Arquitecturas nada compartido. Consiste de diversos procesadores cada
uno con su propia memoria y su propia unidad de almacenamiento. Aqu
se tienen los clusters de estaciones de trabajo, la computadoras Intel
Paragon, NCR 3600 y 3700 e IBM SP2 (Figura 1.7).
Figura 1.7. Arquitectura nada compartido.
VI.9. Aplicaciones
Los ambientes en los que se encuentra con mayor frecuencia el uso de
las bases de datos distribuidas son:
Cualquier organizacin que tiene una estructura descentralizada.
Casos tpicos de lo anterior son: organismos gubernamentales y/o de
servicio pblico.
La industria de la manufactura, particularmente, aquella con plantas
mltiples. Por ejemplo, la industria automotriz.
Aplicaciones de control y comando militar.

Lneas de transportacin area.
Cadenas hoteleras.
Servicios bancarios y financieros.
VI.10. Ventajas
Los SMBDD tienen mltiples ventajas. En primer lugar los datos son
localizados en lugar ms cercano, por tanto, el acceso es ms rpido, el
procesamiento es rpido debido a que varios nodos intervienen en el
procesamiento de una carga de trabajo, nuevos nodos se pueden
agregar fcil y rpidamente. La comunicacin entre nodos se mejora, los
costos de operacin se reducen, son amigables al usuario, la
probabilidad de que una falla en un solo nodo afecte al sistema es baja y
existe una autonoma e independencia entre los nodos.
Las razones por las que compaas y negocios migran hacia bases de
datos distribuidas incluyen razones organizacionales y econmicas, para
obtener una interconexin confiable y flexible con las bases de datos
existente, y por un crecimiento futuro. El enfoque distribuido de las
bases de datos se adapta ms naturalmente a la estructura de las
organizaciones. Adems, la necesidad de desarrollar una aplicacin
global (que incluya a toda la organizacin), se resuelva fcilmente con
bases de datos distribuidas. Si una organizacin crece por medio de la
creacin de unidades o departamentos nuevos, entonces, el enfoque de
bases de datos distribuidas permite un crecimiento suave.
Los datos se pueden colocar fsicamente en el lugar donde se accesan

ms frecuentemente, haciendo que los usuarios tengan control local de
los datos con los que interactan. Esto resulta en una autonoma local
de datos permitiendo a los usuarios aplicar polticas locales respecto del
tipo de accesos a sus datos.
Mediante la replicacin de informacin, las bases de datos distribuidas

pueden presentar cierto grado de tolerancia a fallas haciendo que el
funcionamiento del sistema no dependa de un solo lugar como en el
caso de las bases de datos centralizadas.
VI.11. Desventajas
La principal desventaja se refiere al control y manejo de los datos. Dado
que stos residen en muchos nodos diferentes y se pueden consultar por
nodos diversos de la red, la probabilidad de violaciones de seguridad es
creciente si no se toman las precauciones debidas.
La habilidad para asegurar la integridad de la informacin en presencia
de fallas no predecibles tanto de componentes de hardware como de
software es compleja. La integridad se refiere a la consistencia, validez y

exactitud de la informacin.
Dado que los datos pueden estar replicados, el control de concurrencia y
los mecanismos de recuperacin son mucho ms complejos que en un
sistema centralizado.
1.5 Aspectos importantes de los SMBD distribuidos
Existen varios factores relacionados a la construccin de bases de datos
distribuidas que no se presentan en bases de datos centralizadas. Entre
los ms importantes se encuentran los siguientes:
Diseo de la base de datos distribuida. En el diseo de bases de

datos distribuidas se debe considerar el problema de como distribuir la
informacin entre diferentes sitios. Existen razones organizacionales las
cuales determinan en gran medida lo anterior. Sin embargo, cuando se
busca eficiencia en el acceso a la informacin, se deben abordar dos
problemas relacionados. Primero, como fragmentar la informacin.
Segundo, como asignar cada fragmento entre los diferentes sitios de la
red. En el diseo de la BDD tambin es importante considerar si la
informacin est replicada, es decir, si existen copias mltiples del
mismo dato y, en este caso, como mantener la consistencia de la
informacin. Finalmente, una parte importante en el diseo de una BDD
se refiere al manejo del directorio. Si existen nicamente usuarios
globales, se debe manejar un solo directorio global. Sin embargo, si
existen tambin usuarios locales, el directorio combina informacin local
con informacin global.
Procesamiento de consultas. El procesamiento de consultas es de
suma importancia en bases de datos centralizadas. Sin embargo, en
BDD ste adquiere una relevancia mayor. El objetivo es convertir
transacciones de usuario en instrucciones para manipulacin de datos.
No obstante, el orden en que se realizan las transacciones afecta
grandemente la velocidad de respuesta del sistema. As, el
procesamiento de consultas presenta un problema de optimizacin en el
cual se determina el orden en el cual se hace la menor cantidad de
operaciones. Este problema de optimizacin es NP-difcil, por lo que en
tiempos razonables solo se pueden obtener soluciones aproximadas. En
BDD se tiene que considerar el procesamiento local de una consulta
junto con el costo de transmisin de informacin al lugar en donde se
solicit la consulta.
Control de concurrencia. El control de concurrencia es la actividad de
coordinar accesos concurrentes a la base de datos. El control de
concurrencia permite a los usuarios accesar la base de datos en una
forma multiprogramada mientras se preserva la ilusin de que cada
usuario est utilizndola solo en un sistema dedicado. El control de
concurrencia asegura que transacciones mltiples sometidas por
usuarios diferentes no interfieran unas con otras de forma que se
produzcan resultados incorrectos. En BDD el control de concurrencia es
an ms complejo que en sistemas centralizados. Los algoritmos ms

utilizados son variaciones de aquellos usados en sistemas centralizados:
candados de dos fases, ordenamiento por estampas de tiempo,
ordenamiento por estampas de tiempo mltiples y control de
concurrencia optimista. Un aspecto interesante del control de
concurrencia es el manejo de interbloqueos. El sistema no debe permitir
que dos o ms transacciones se bloqueen entre ellas.
Confiabilidad. En cualquier sistema de bases de datos, centralizado o
distribuido, se debe ofrecer garantas de que la informacin es confiable.
As cada consulta o actualizacin de la informacin se realiza mediante
transacciones, las cuales tienen un inicio y fin. En sistemas distribuidos,
el manejo de la atomicidad y durabilidad de las transacciones es an
ms complejo, ya que una sola transaccin puede involucrar dos o ms
sitios de la red. As, el control de recuperacin en sistemas distribuidos
debe asegurar que el conjunto de agentes que participan en una
transaccin realicen todos un compromiso (commit) al unsono o todos al
mismo tiempo restablezcan la informacin anterior (roll-back).
En la Figura 1.8 se presenta un diagrama con las relaciones entre los
aspectos relevantes sobre las BDD.
Figura 1.8. Factores importantes en BDD.

Estado del Arte
Aun cuando los beneficios del uso de BDD son claramente perceptibles,
en la actualidad muchos de los desarrollos se encuentran nicamente en
sistemas experimentales (de investigacin). A continuacin se discute el
estado actual de las bases de datos comerciales respecto de cuatro
logros potenciales asequibles en BDD.
Manejo transparente de datos distribuidos, fragmentados y
replicados. Comercialmente an no se soporta la replicacin de
informacin. La fragmentacin utilizada es nicamente de tipo horizontal
(sta se discute en el captulo 3). La distribucin de informacin no se
realiza an con la transparencia requerida. Por ejemplo, el usuario debe
indicar la localizacin de un objeto y el acceso a los datos es mediante

sesiones remotas a bases de datos locales. La mayora de los sistemas
comerciales utilizan el modelo mltiples clientes-un solo servidor.
Mejoramiento de la confiabilidad y disponibilidad de la
informacin mediante transacciones distribuidas. Algunos
sistemas como Ingres, NonStop SQL y Oracle V 7.x ofrecen el soporte de
transacciones distribuidas. En Sybase, por ejemplo, es posible tener
transacciones distribuidas pero stas deber ser implementadas en las
aplicaciones mediante primitivas dadas. Respecto del soporte para
replicacin de informacin o no se ofrece o se hace a travs de la regla
une-lee-todos-escriben.
Mejoramiento de la eficiencia. Una mayor eficiencia es una de las
grandes promesas de los SMBDD. Existen varias partes en donde sto se
puede lograr. En primer lugar, la ubicacin de los datos a lugares
prximos a donde se usan puede mejorar la eficiencia en el acceso a la
informacin. Sin embargo, para lograrlo es necesario tener un buen
soporte para fragmentacin y replicacin de informacin. Otro punto en
donde se puede incrementar la eficiencia es mediante la explotacin del
paralelismo entre operaciones. Especialmente en el caso de varias
consultas independientes, stas se pueden procesar por sitios
diferentes. Ms an, el procesamiento de una sola consulta puede
involucrar varios sitios y as procesarse de manera ms rpida. Sin
embargo, la explotacin del paralelismo requiere que se tenga tanta
informacin requerida por cada aplicacin en el sitio donde la aplicacin
se utiliza, lo cual conducira a una replicacin completa, esto es, tener
toda la informacin en cada sitio de la red. El manejo de rplicas es
complicado dado que las actualizaciones a este tipo de datos involucran
a todos los sitios teniendo copias del dato. Los sistemas comerciales
ofrecen nicamente aproximaciones a este requisito. Por ejemplo, en los
bancos se destina usualmente el horario de oficina para hacer lecturas y
las horas no hbiles para hacer actualizaciones. Otra estrategia es tener
dos bases de datos, una para consultas y otra para actualizaciones.
Mejor escalabilidad de las BD. El tener sistemas escalables de
manera fcil y econmica se ha logrado por el desarrollo de la tecnologa
de microprocesadores y estaciones de trabajo. Sin embargo, respecto de
la escalabilidad, la comunicacin de la informacin tiene un costo el cual
no se ha estudiado con suficiente profundidad.
VI.12. ARQUITECTURA DE BASE DE DATOS DISTRIBUIDA
En el presente captulo se mostrar la arquitectura general de un

sistema de bases de datos distribuida, se introducir el concepto de
fragmentacin de datos relacionado con el nivel de transparencia de
distribucin que un SBDD debe ofrecer. Se dar una descripcin acerca

de las componentes de las bases de datos distribuidas.
La arquitectura define la estructura de un sistema. Al definir la
arquitectura se deben identificar las componentes de un sistema, las
funciones que realiza cada una de las componentes y las interrelaciones
e interacciones entre cada componente.
VI.13. NIVELES DE TRANSPARENCIA EN SBDD

El prposito de establecer una arquitectura de un sistema de bases de
datos distribuidas es ofrecer un nivel de transparencia adecuado para el
manejo de la informacin. La transparencia se puede entender como la
separacin de la semntica de alto nivel de un sistema de las aspectos
de bajo nivel relacionados a la implementacin del mismo. Un nivel de
transparencia adecuado permite ocultar los detalles de implementacin
a las capas de alto nivel de un sistema y a otros usuarios.
En sistemas de bases de datos distribuidos el propsito fundamental de
la transparencia es proporcionar independencia de datos en el ambiente
distribuido. Se pueden encontrar diferentes aspectos relacionados con la
transparencia. Por ejemplo, puede existir transparencia en el manejo de
la red de comunicacin, transparencia en el manejo de copias repetidas
o transparencia en la distribucin o fragmentacin de la informacin.
La independencia de datos es la inmunidad de las aplicaciones de
usuario a los cambios en la definicin y/u organizacin de los datos y
viceversa. La independencia de datos se puede dar en dos aspectos:
lgica y fsica.
Independencia lgica de datos. Se refiere a la inmunidad de las
aplicaciones de usuario a los cambios en la estructura lgica de la base
de datos. Esto permite que un cambio en la definicin de un esquema no
debe afectar a las aplicaciones d eusuario. Por ejemplo, el agregar un
nuevo atributo a una relacin, la creacin de una nueva relacin, el
reordenamiento lgico de algunos atributos.
Independencia fsica de datos. Se refiere al ocultamiento de los
detalles sobre las estructuras de almacenamiento a las aplicaciones de
usuario. Esto es, la descripcin fsica de datos puede cambiar sin afectar
a las aplicaciones de usuario. Por ejemplo, los datos pueden ser movidos
de un disco a otro, o la organizacin de los datos puede cambiar.
La transparencia al nivel de red se refiere a que los datos en un
SBDD se accesan sobre una red de computadoras, sin embargo, las
aplicaciones no deben notar su existencia. La transparencia al nivel de
red conlleva a dos cosas:
Transparencia sobre la localizacin de datos. Esto es, el comando
que se usa es independiente de la ubicacin de los datos en la red y del
lugar en donde la operacin se lleve a cabo. Por ejemplo, en Unix existen
dos comandos para hacer una copia de archivo. Cp se utiliza para copias
locales y rcp se utiliza para copias remotas. En este caso no existe

transparencia sobre la localizacin.
Transparencia sobre el esquema de nombramiento. Lo anterior se
logra proporcionando un nombre nico a cada objeto en el sistema
distribuido. As, no se debe mezclar la informacin de la localizacin con
en el nombre de un objeto.
La transparencia sobre replicacin de datos se refiere a que si
existen rplicas de objetos de la base de datos, su existencia debe ser
controlada por el sistema no por el usuario. Se debe tener en cuenta que
al cuando el usuario se encarga de manejar las rplicas en un sistema, el
trabajo de ste es mnimo por lo que se puede obtener una eficiencia
mayor. Sin embargo, el usuario puede olvidarse de mantener la
consistencia de las rplicas teniendo as datos diferentes.
La transparencia a nivel de fragmentacin de datos permite que
cuando los objetos de la bases de datos estn fragmentados, el sistema
tiene que manejar la conversin de consultas de usuario definidas sobre
relaciones globales a consultas definidas sobre fragmentos. As tambin,
ser necesario mezclar las respuestas a consultas fragmentadas para
obtener una sola respuesta a una consulta global. El acceso a una base
de datos distribuida debe hacerse en forma transparente.
Ejemplo 2.1. Como un ejemplo se utilizar a lo largo de estas notas una
base de datos que modela una compaa de ingeniera. Las entidades a
ser modeladas son ingenieros y proyectos. Para cada ingeniero, se desea
conocer su nmero de empleado (ENO), su nombre (ENOMBRE), el
puesto ocupado en compaa (TITULO), el salario (SAL), la identifiacin
de los nombres de proyectos en los cuales est trabajando (JNO), la
responsabilidad que tiene dentro del proyecto (RESP) y la duracin de su
responsabilidad en meses (DUR). Similarmente, para cada proyecto se
desea conocer el nmero de proyecto (JNO), el nombre del proyecto
(JNOMBRE), el presupuesto asignado al proyecto (PRESUPUESTO) y el
lugar en donde se desarrolla el proyecto (LUGAR).
Un ingeniero puede participar en ms de un proyecto pero su salario
corresponde nicamente al puesto que ocupa en la compaa. As,
despus de aplicar normalizacin se obtienen las relaciones E para
ingenieros, J para proyectos, S para los salarios asignados a los
puestos y G para los ingenieros asignados a cada proyecto. Un ejemplo
de las instancias para cada relacin se presenta en la Figura 2.1.
E
EN ENOMBRE TITULO
O
E1 Juan Rodrguez Ingeniero
Elctrico
E2 Miguel Analista de
Snchez Sistemas
E3 Armando Ingeniero
Legarreta Mecnico
E4 Beatriz Programador
Molleda
E5 Jorge Analista de
Castaeda Sistemas
E6 Luis Chvez Ingeniero
Elctrico
E7 Roberto Dvila Ingeniero
Mecnico
E8 Julia Jimnez Analista de
Sistemas
G
EN JNO PUESTO DUR
O
E1 J1 Administrad 12
or
E2 J1 Analista 24
E2 J2 Analista 6
E3 J3 Consultor 10
E3 J4 Ingeniero 48
E4 J2 Programado 18
r
or
or
E7 J3 Ingeniero 36
E7 J5 Ingeniero 23
or
J
JNO JNOMBRE PRESUPUE LUGAR
STO
J1 Instrumenta 150000 Monterre
cin y
J2 Desarrollo 135000 Mxico
de bases de
datos
J3 CAD/CAM 250000 Puebla
J4 Mantenimien 310000 Mxico
to
J5 CAD/CAM 500000 Monterre
y
S
TITULO SALARI
O
Ingeniero 40000
Elctrico
Analista de 34000
Sistemas
Ingeniero 27000
Mecnico
Programador 24000
Figura 2.1. Bases de datos de una empresa con cuatro relaciones.
Si se quisiera obtener todos los empleados y sus salarios en la

corporacin quienes han trabajado ms de 12 meses se hara la consulta
siguiente en SQL:
SELECT ENOMBRE, SALARIO
FROM E, G, S
WHERE JORNADA > 12 AND
E.ENO = G.ENO AND
E.TILE = S.TITLE
Se debe tener en cuenta que en cada sitio de la corporacin puede
haber esquemas diferentes o repetidos. Por ejemplo, en la Figura 2.2 se
presentan esquemas diferentes para el manejo de proyectos, empleados
y puestos en cada sitio de la bases de datos del Ejemplo 2.1.
Figura 2.2. Diferentes sitios de un corporacin.

En resumen, la transparencia tiene como punto central la independencia

de datos. Los diferentes niveles de transparencia se puede organizar en
capas como se muestra en la Figura 2.3. En el primer nivel se soporta la
transparencia de red. En el segundo nivel se permite la transparencia de
replicacin de datos. En el tercer nivel se permite la transparencia de la
fragmentacin. Finalmente, en el ltimo nivel se permite la
transparencia de acceso (por medio de lenguaje de manipulacin de
datos).
La responsabilidad sobre el manejo de transparencia debe estar

compartida tanto por el sistema operativo, el sistema de manejo de
bases de datos y el lenguaje de acceso a la base de datos distribuida.
Entre estos tres mdulos se deben resolver los aspectos sobre el
procesamiento distribuido de consultas y sobre el manejo de nombres de
objetos distribuidos.
Figura 2.3. Organizacin en capas de los niveles de transparencia.
ARQUITECTURA DE UN SISTEMA DE BASES DE DATOS

DISTRIBUIDAS
La mayora de los sistemas de manejo de bases de datos disponibles

actualmente estn basadas en la arquitectura ANSI-SPARC la cual divide
a un sistema en tres niveles: interno, conceptual y externo, como se
puede apreciar en la Figura 2.4.
La vista conceptual, conocida tambin como vista lgica global,
representa la visin de la comunidad de usuarios de los datos en la base
de datos. No toma en cuenta la forma en que las aplicaciones
individuales observan los datos o como stos son almacenados. La vista
conceptual est basada en el esquema conceptual y su construccin se
hace en la primera fase del diseo de una base de datos.
Los usuarios, incluyendo a los programadores de aplicaciones, observan
los datos a travs de un esquema externo definido a nivel externo. La
vista externa proporciona una ventana a la vista conceptual lo cual

permite a los usuarios observar nicamente los datos de inters y los
asla de otros datos en la base de datos. Puede existir cualquier nmero
de vistas externas y ellos pueden ser completamente independientes o
traslaparse entre s.
El esquema conceptual se mapea a un esquema interno a nivel interno,
el cual es el nivel de descripcin ms bajo de los datos en una base de
datos. Este proporciona una interfaz al sistema de archivos del sistema
operativo el cual es el responsable del acceso a la base de datos. El nivel
interno tiene que ver con la especificacin de qu elementos sern
indexados, qu tcnica de organizacin de archivos utilizar y como los
datos se agrupan en el disco mediante "clusters" para mejorar su
acceso.
En las Figuras 2.5, 2.6 y 2.7 se presenta la definicin de los esquemas
conceptual, interno y externo para las relaciones de la Figura 2.1.
Figura 2.4. Arquitectura ANSI/SPARC de una base de datos.
Figura 2.5. Vista conceptual de las relaciones E, S, J y G.

Figura 2.6. Definicin de una vista interna a partir de la relacin S.
Figura 2.7. Dos ejemplos de vistas externas.
Desafortunadamente, no existe un equivalente de una arquitectura

estndar para sistemas de manejo de bases de datos distribuidas. La
tecnologa y prototipos de SMBDD se han desarrollado ms o menos en
forma independiente uno de otro y cada sistema ha adoptado su propia
arquitectura.
Para definir un esquema de estandarizacin en bases de datos
distribuidas se debe definir un modelo de referencia el cual sera un
marco de trabajo conceptual cuyo propsito es dividir el trabajo de
estandarizacin en piezas manejables y mostrar a un nivel general como
esas piezas se relacionan unas con otras. Para definir ese modelo de
referencia se puede seguir uno de los siguientes tres enfoques:
Basado en componentes. Se definen las componentes del sistema
junto con las relaciones entre ellas. As, un SMBD consiste de un nmero
de componentes, cada uno de los cuales proporciona alguna
funcionalidad.
Basado en funciones. Se identifican las diferentes clases de usuarios
junto con la funcionalidad que el sistema ofrecer para cada clase. La
especificacin del sistema en esta categora tpicamente determina una
estructura jerrquica para las clases de usuarios. La ventaja de este
enfoque funcional es la claridad con la cual se especifican los objetivos
del sistema. Sin embargo, este enfoque no proporciona una forma de

alcanzar los objetivos.
Basado en datos. Se identifican los diferentes tipos de descripcin de
datos y se especifica un marco de trabajo arquitectural el cual define las
unidades funcionales que realizarn y/o usarn los datos de acuerdo con
las diferentes vistas. La ventaja de este enfoque es la importancia que
asigna al manejo de datos. Este es un enfoque significativo para los
SMBD dado que su propsito principal es manejar datos. Sin embargo, la
desventaja de este enfoque es que es prcticamente imposible
especificar un modelo arquitectural sin especificar los modelos para
cada una de sus unidades funcionales. Este es el enfoque seguido por el
modelo ANSI/SPARC.
Figura 2.8. Dimensiones a considerar al integrar mltiples bases de

datos.
VI.14. ALTERNATIVAS PARA LA IMPLEMENTACION DE SMBD

En la Figura 2.8 se presentan las diferentes dimensiones (factores) que
se deben considerar para la implementacin de un sistema manejador
de base de datos. Las dimensiones son tres:
Distribucin. Determina si las componentes del sistema estn
localizadas en la misma computadora o no.
Heterogeneidad. La heterogeneidad se puede presentar a varios
niveles: hardware, sistema de comunicaciones, sistema operativo o
SMBD. Para el caso de SMBD heterogneos sta se puede presentar
debido al modelo de datos, al lenguaje de consultas o a los algoritmos
para manejo de transacciones.
Autonoma. La autonoma se puede presentar a diferentes niveles:
Autonoma de diseo. La habilidad de un componente del SMBD para

decidir cuestiones relacionadas a su propio diseo.
Autonoma de comunicacin. La habilidad de un componente del
SMBD para decidir como y cuando comunicarse con otros SMBD.
Autonoma de ejecucin. La habilidad de un componente del SMBD
para ejecutar operaciones locales de la manera que l quiera.
Figura 2.9. Arquitectura de un SMBDD homogneo.
Desde el punto de vista funcional y de organizacin de datos, los

sistemas de datos distribuidos estn divididos en dos clases separadas,
basados en dos filosofa totalmente diferentes y diseados para
satisfacer necesidades diferentes:
Sistemas de manejo de bases de datos distribuidos homogneos
Sistemas de manejo de bases de datos distribuidos heterogneos
Un SMBDD homogneo tiene mltiples colecciones de datos; integra

mltiples recursos de datos como se muestra en la Figura 2.9. Los
sistemas homogneos se parecen a un sistema centralizado, pero en
lugar de almacenar todos los datos en un solo lugar, los datos se
distribuyen en varios sitios comunicados por la red. No existen usuarios
locales y todos ellos accesan la base de datos a travs de una interfaz
global. El esquema global es la unin de toda las descripciones de datos
locales y las vistas de los usuarios se definen sobre el esquema global.
Para manejar los aspectos de la distribucin, se deben agregar dos
niveles a la arquitectura estndar ANSI-SPARC, como se muestra en la
Figura 2.10. El esquema de fragmentacin describe la forma en que
las relaciones globales se dividen entre las bases de datos locales. La
Figura 2.11 presenta el ejemplo de una relacin, R, la cual se divide en
cinco fragmentos. El esquema de asignamiento especifica el lugar en
el cual cada fragmento es almacenado. De aqu, los fragmentos pueden

migrar de un sitio a otro en respuesta a cambios en los patrones de
acceso.
Figura 2.10. Arquitectura de los esquemas de un SMBDD homogneo.
Figura 2.11. Fragmentacin de una relacin global.

Figura 2.12. Arquitectura de un sistema multi-bases de datos.
La clase de sistemas heterogneos es aquella caracterizada por

manejar diferentes SMBD en los nodos locales. Una subclase importante
dentro de esta clase es la de los sistemas de manejo multi-bases de
datos. Un sistema multi-bases de datos (Smulti-BD) tiene mltiples
SMBDs, que pueden ser de tipos diferentes, y mltiples bases de datos
existentes. La integracin de todos ellos se realiza mediante
subsistemas de software. La arquitectura general de tales sistemas se
presenta en la Figura 2.12. En contraste con los sistemas homogneos,
existen usuarios locales y globales. Los usuarios locales accesan sus
bases de datos locales sin verse afectados por la presencia del Smulti-
BD.
En algunas ocasiones es importante caracterizar a los sistemas de bases

de datos distribuidas por la forma en que se organizan sus
componentes. En la Figura 2.13 se presenta la arquitectura basada en
componentes de un SMBD distribuido. Consiste de dos partes
fundamentales, el procesador de usuario y el procesador de datos. El
procesador de usuario se encarga de procesar las solicitudes del usuario,
por tanto, utiliza el esquema externo del usuario y el esquema
conceptual global. As tambin, utiliza un diccionario de datos global.
El procesador de usuario consiste de cuatro partes: un manejador de la
interfaz con el usuario, un controlador semntico de datos, un
optimizador global de consultas y un supervisor de la ejecucin global. El
procesador de datos existe en cada nodo de la base de datos distribuida.
Utiliza un esquema local conceptual y un esquema local interno. El
procesador de datos consiste de tres partes: un procesador de consultas
locales, un manejador de recuperacin de fallas locales y un procesador
de soporte para tiempo de ejecucin.
Figura 2.13. Arquitectura basada en componentes de un SMBD

distribuido.
En la Figura 2.14, se presenta la arquitectura basada en componentes de

un sistema multi-bases de datos. Consiste un sistema de manejo de
bases datos para usuarios globales y de sistemas de manejo de bases
de datos para usuarios locales. Las solicitudes globales pasan al
procesador global el cual consiste de un procesador de transacciones,
una interfaz de usuario, un procesador de consultas, un optimizador de
consultas, un esquema y un administrador de recuperacin de fallas,
todos ellos actuando de manera global.
En cada sitio existe un SMBD completo el cual consiste de la interfaz con

el usuario, el procesador y optimizador de consultas, el manejador de
transacciones, el despachador de operaciones, el manejador de
recuperacin de fallas y el sistema de soporte para tiempo de ejecucin,
todos ellos actuando de manera local. Para comunicar el sistema global
con los sistemas locales se define una interfaz comn entre
componentes mediante la cual, las operaciones globales se convierten
en una o varias acciones locales.
.
Figura 2.14. Arquitectura basada en componentes de un sistema multi-

bases de datos.
Figura 2.15. Manejo del directorio de datos en bases de datos

distribuidas.
VII. DATAWAREHOUSE
El mundo de los Decision Suport Systems en adelante DSS ha creado

varias arquitecturas de informacin. La ms notable de las estructuras
DSS es el Data warehouse. El Data warehouse contiene datos
histricos que son comunes en toda la organizacin, la informacin
puede estar sumarizada y/o detallada.
Los datos que alimentan los sistemas de Data warehouse los

proporcionan los sistemas operacionales, tambin denominados
sistemas de ejecucin de procesos de negocios. El Data warehouse
casi siempre es un sistema de datos guardados fsicamente en
estructuras separadas, los datos son transformados a partir de los datos
proporcionados por los sistemas operacionales.
El potencial de la explotacin de los datos (Data Mining) puede realzarse
si de manera apropiada los datos son recolectados y guardados en un
almacn o depsito de datos (Data warehouse). Un almacn de datos
o Data warehouse es un sistema de gestin de bases de datos
relacional diseado especficamente para ofrecer las necesidades de los
sistemas de anlisis de la informacin. Se trata de una nueva tcnica
que posibilita la extraccin de datos de los sistemas operacionales.
Tambin facilita la integracin y homogeneizacin de los datos de toda la
empresa. En otras palabras el almacn de datos provee datos que ya
han sido transformados y sumarizados, por lo tanto crea el entorno
apropiado para un uso ms eficiente de las herramientas DSS y EIS.
VII.1.PROCESOS EN EL DISEO DE UN DATAWAREHOUSE

La primera fase en el diseo de un sistema de almacn de datos
consiste en aislar el actual sistema de informacin operacional, para
preservar la seguridad y la integridad de las aplicaciones de misin
crticas de OLTP. La base de datos resultante o almacn de datos puede
consumir cientos de gigabytes o incluso de terabytes de espacio en
disco. Existen tcnicas para guardar y obtener grandes cantidades de
informacin. Empresas con volmenes de informacin enormes pueden
requerir el uso de sistemas de procesamiento en paralelo para as
obtener el ancho de banda suficiente.
VII.2.Los datos se transforman y incluyen en el almacn de
datos segn un modelo preestablecido
Los procesos de transformacin y movimiento de los datos pueden
ejecutarse en cualquier momento cada vez que se necesite actualizar el
almacn de datos mediante funciones especiales. La informacin que
describe el modelo y la definicin de los elementos de datos fuente se

llama metadatos. Los metadatos son las unidades de informacin
mnimas que manejarn los usuarios del almacn de datos y como
mnimo incluirn:
La estructura de los datos.
Los algoritmos usados en los procesoso de suma y acumulacin.
El mapeado del sistema de informacin del entorno operacional al
sistema de informacin del almacn de datos.
La limpieza de los datos en el sistema de informacin del entorno
operacional es uno de los aspectos ms importantes, consiste en
eliminar parte de los datos operacionales, tales como informacin de
transacciones de bajo nivel, los cuales por su elevado volumen inciden
negativamente en los tiempos de ejecucin de las consultas. Los datos
que a nivel operacional ya no son operativos deberan extraerse de las
fuentes de produccin a intervalos regulares eliminndolos del sistema
de informacin operacional y traspasndolos al almacn de datos o
Data warehouse.
VII.3.SISTEMAS DE DATA WAREHOUSE Y OLTP

Una base de datos para soportar procesos transaccionales en lnea
(OLTP), puede no ser adecuada para el Data warehouse ya que ha sido
diseada para maximizar la capacidad transaccional de sus datos y
tipicamente tiene cientos de tablas la gran mayora normalizadas. Su
diseo tambin ha sido condicionado por los procesos operacionales que
deber soportar para la ptima actualizacin de sus datos, normalmente
muchas de sus tablas en constantes y continuos cambios. Los sistemas
Data warehouse estn orientados a procesos de consultas en
contraposicin con los procesos transaccionales.
OLTP Data Warehouse
Ejecuta operaciones Consultas y anlisis para la
Propsi
transaccionales obtencin de informacin
to
diariamente
Estruct Sistemas de bases de Normalmente sistemas de
ura datos relacionales bases de datos relacionales
Muchas de sus tablas pueden
Modelo no estar normalizadas se
de Normalizado admite redundancia en los
datos datos. Bases de datos
multidimensionales.
Acceso SQL SQL ms extensiones
especiales dependientes de las
herramientas de explotacin de
datos (Data Mining)
No obstante, el SQL estndar

puede ser suficiente en manos
de personal experto.
Los datos estn orientados al
Los datos estn orientados
Tipo de anlisis de los negocios.
a la gestin de los
datos Transforman los datos en
negocios
informacin para su anlisis.
Los datos cambian Datos histricos con
constantemente, vistos referencias temporales no
globalmente en procesos sujetos a modificaciones.
de reporting sofisticados
pueden perder
Perdura consistencia, o bien, para
bilidad no perder consistencia
deben imponerse
mecanismos de bloqueo
de datos con un elevado
consumo de recursos
globales del sistema.
VII.4.CARACTERISTICAS
De acuerdo con Bill Inmon, autor de Building the Data warehouse
Construyendo el almacn de datos, ampliamante reconocido como el
gur creador del concepto data warehousing, existen generalmente
cuatro caractersticas que describen un almacen de datos:
orientado al sujeto: Los datos se organizan de acuerdo al sujeto en vez

de la aplicacin, por ejemplo, una compaia de seguros usando un
almacn de datos podra organizar sus datos por cliente, premios, y
reclamaciones, en lugar de por diferentes productos (automviles, vida,
etc.). Los datos organizados por sujetos contienen solo la informacin
necesaria para los procesos de soporte para la toma de decisiones.
integrados: Cuando los datos residen en muchas aplicaciones separados
por los distintos entornos operacionales, la descodificacin de los datos
es a menudo inconsistente. Por ejemplo, en una aplicacin, la palabra
gender podra codificarse como "m" y "f" en otra como "0" y "1". cuando
los datos fluyen de un entorno operacional a un entorno de almacen de
datos o de Data warehouse, ellos asumen una codificacin
consistente, por ejemplo gender siempre se transformara a "m" y "f".
variacin-temporal: El almacen de datos contiene un lugar para
guardar datos con una antiguedad de 5 a diez aos, o incluso ms
antiguos, para poder ser usados en comparaciones, tendencias y
previsiones. Estos datos no se modificarn.
no son inestables: Los datos no sern modificados o cambiados de

ninguna manera una vez ellos han sido introducidos en el almacn de
datos, solamente podrn ser cargados, leidos y/o accedidos.
VII.5.BENEFICIOS
Optimizacin
Las estructuras de datos operacionales estn orientadas a una
explotacin mediante procesos transaccionales en lnea (OLTP), las
caractersticas de sus tablas y registros.
Datos versus informacin
El Data warehouse con las herramientas adecuadas nos permitir
obtener o realizar anlisis, reporting, extraccin y exploracin de los
datos para, en suma, transformar los datos en informacin til para
nuestra organizacin.
Beneficios econmicos
Normalmente los beneficios econmicos que podemos obtener de un
Data warehouse no tienen la inmediatez de los que pueden obtenerse
mediante un efeciente sistema de informacin operacional, por lo
general mediante los Data warehouse o Almacenes de datos hemos de
esperar el ahorro de gastos motivados por los cambios que puedan
sugerirse en la gestin de nuestra empresa en el medio y largo plazo.
VII.6.Conclusin
Las Data Warehouse representan una tecnologa innovadora y un

mercado en pleno desarrollo.
Data Warehousing y Data Mining son dos procesos que permiten la
Gestin del Conocimiento. El Conociemnto, convertido ahora en el ms
importante factor de produccin, es un recurso clave para cualquier
compaa que quiera sobrevivir y medrar en el competitivo y global
entorno empresarial de hoy en da. Es importante sealar que este tipo
de proyectos en constante evolucin de la empresa. Por tanto, se podra
decir que nunca tiene fin, que siempre son susceptibles al cambio. "El
Data Warehousing no es un destino, sino un viaje"
VII.7.INTRODUCCION AL CONCEPTO DATA WAREHOUSING
Data warehousing es el centro de la arquitectura para los sistemas de

informacin en la dcada de los '90. Soporta el procesamiento
informtico al proveer una plataforma slida, a partir de los datos
histricos para hacer el anlisis. Facilita la integracin de sistemas de
aplicacin no integrados. Organiza y almacena los datos que se
necesitan para el procesamiento analtico, informtico sobre una amplia

perspectiva de tiempo.
Un Data Warehouse o Depsito de Datos es una coleccin de datos

orientado a temas, integrado, no voltil, de tiempo variante, que se usa
para el soporte del proceso de toma de decisiones gerenciales.
Se puede caracterizar un data warehouse haciendo un contraste de

cmo los datos de un negocio almacenados en un data warehouse,
difieren de los datos operacionales usados por las aplicaciones de
produccin.
Base de Datos
Data Warehouse
Operacional
Datos del negocio para
Datos Operacionales
Informacin
Orientado a la aplicacin Orientado al sujeto
Actual Actual + histrico
Detallada Detallada + ms resumida
Cambia continuamente Estable
Diferentes tipos de informacin

El ingreso de datos en el data warehouse viene desde el ambiente
operacional en casi todos los casos. El data warehouse es siempre un
almacn de datos transformados y separados fsicamente de la
aplicacin donde se encontraron los datos en el ambiente operacional.
VII.8.SISTEMAS DE INFORMACION
En las metodologas anteriores, publicadas por el Instituto Nacional de
Estadstica e Informtica - INEI y con el fin de proporcionar una visin
ms clara, los sistemas de informacin se han dividido de acuerdo al
siguiente esquema:
Sistemas Estratgicos, orientados a soportar la toma de decisiones,

facilitan la labor de la direccin, proporcionndole un soporte bsico, en
forma de mejor informacin, para la toma de decisiones. Se caracterizan
porque son sistemas sin carga peridica de trabajo, es decir, su
utilizacin no es predecible, al contrario de los casos anteriores, cuya
utilizacin es peridica.
Destacan entre estos sistemas: los Sistemas de Informacin Gerencial
(MIS), Sistemas de Informacin Ejecutivos (EIS), Sistemas de Informacin
Georeferencial (GIS), Sistemas de Simulacin de Negocios (BIS y que en
la prctica son sistemas expertos o de Inteligencia Artificial - AI).
Sistemas Tcticos, diseados para soportar las actividades de

coordinacin de actividades y manejo de documentacin, definidos para
facilitar consultas sobre informacin almacenada en el sistema,
proporcionar informes y, en resumen, facilitar la gestin independiente
de la informacin por parte de los niveles intermedios de la
organizacin.
Destacan entre ellos: los Sistemas Ofimticos (OA), Sistemas de
Transmisin de Mensajera (E-mail y Fax Server), coordinacin y control
de tareas (Work Flow) y tratamiento de documentos (Imagen, Trmite y
Bases de Datos Documentarios).
Sistemas Tcnico-Operativos, que cubren el ncleo de operaciones
tradicionales de captura masiva de datos (Data Entry) y servicios
bsicos de tratamiento de datos, con tareas predefinidas (contabilidad,
facturacin, almacn, presupuesto, personal y otros sistemas
administrativos). Estos sistemas estn evolucionando con la irrupcin de
censores, autmatas, sistemas multimedia, bases de datos relacionales
ms avanzadas y data warehousing.
Sistemas Interinstitucionales, este ltimo nivel de sistemas de
informacin recin est surgiendo, es consecuencia del desarrollo
organizacional orientado a un mercado de carcter global, el cual obliga
a pensar e implementar estructuras de comunicacin ms estrechas
entre la organizacin y el mercado (Empresa Extendida, Organizacin
Inteligente e Integracin Organizacional), todo sto a partir de la
generalizacin de las redes informticas de alcance nacional y global
(INTERNET), que se convierten en vehculo de comunicacin entre la

organizacin y el mercado, no importa dnde est la organizacin
(INTRANET), el mercado de la institucin (EXTRANET) y el mercado (Red
Global).
Sin embargo, la tecnologa data warehousing basa sus conceptos y
diferencias entre dos tipos fundamentales de sistemas de informacin en
todas las organizaciones: los sistemas tcnico-operacionales y los
sistemas de soporte de decisiones. Este ltimo es la base de un data
warehouse.
VII.9.Sistemas tcnico-operacionales
Como indica su nombre, son los sistemas que ayudan a manejar la
empresa con sus operaciones cotidianas. Estos son los sistemas que
operan sobre el "backbone" (columna vertebral) de cualquier empresa o
institucin, entre las que se tiene sistemas de ingreso de rdenes,
inventario, fabricacin, planilla y contabilidad, entre otros.
Debido a su volumen e importancia en la organizacin, los sistemas
operacionales siempre han sido las primeras partes de la empresa a ser
computarizados. A travs de los aos, estos sistemas operacionales se
han extendido, revisado, mejorado y mantenido al punto que hoy, ellos
son completamente integrados en la organizacin.
Desde luego, la mayora de las organizaciones grandes de todo el
mundo, actualmente no podran operar sin sus sistemas operacionales y
los datos que estos sistemas mantienen.
VII.10. Sistemas de Soporte de Decisiones

Por otra parte, hay otras funciones dentro de la empresa que tienen que
ver con el planeamiento, previsin y administracin de la organizacin.
Estas funciones son tambin crticas para la supervivencia de la
organizacin, especialmente en nuestro mundo de rpidos cambios.
Las funciones como "planificacin de marketing", "planeamiento de
ingeniera" y "anlisis financiero", requieren, adems, de sistemas de
informacin que los soporte. Pero estas funciones son diferentes de las
operacionales y los tipos de sistemas y la informacin requerida son
tambin diferentes. Las funciones basadas en el conocimiento son los
sistemas de soporte de decisiones.
Estos sistemas estn relacionados con el anlisis de los datos y la toma
de decisiones, frecuentemente, decisiones importantes sobre cmo
operar la empresa, ahora y en el futuro. Estos sistemas no slo tienen
un enfoque diferente al de los operacionales, sino que, por lo general,
tienen un alcance diferente.
Mientras las necesidades de los datos operacionales se enfocan
normalmente hacia una sola rea, los datos para el soporte de
decisiones, con frecuencia, toma un nmero de reas diferentes y
necesita cantidades grandes de datos operacionales relacionadas.
Son estos sistemas sobre los se basa la tecnologa data warehousing.
VII.11. CARACTERISTICAS DE UN DATA WAREHOUSE
Entre las principales se tiene:

Orientado al tema
Integrado
De tiempo variante
No voltil
Orientado a Temas
Una primera caracterstica del data warehouse es que la informacin se
clasifica en base a los aspectos que son de inters para la empresa.
Siendo as, los datos tomados estn en contraste con los clsicos
procesos orientados a las aplicaciones. En la Figura N 1 se muestra el
contraste entre los dos tipos de orientaciones.
El ambiente operacional se disea alrededor de las aplicaciones y

funciones tales como prstamos, ahorros, tarjeta bancaria y depsitos
para una institucin financiera. Por ejemplo, una aplicacin de ingreso
de rdenes puede accesar a los datos sobre clientes, productos y
cuentas. La base de datos combina estos elementos en una estructura
que acomoda las necesidades de la aplicacin.
En el ambiente data warehousing se organiza alrededor de sujetos tales

como cliente, vendedor, producto y actividad. Por ejemplo, para un
fabricante, stos pueden ser clientes, productos, proveedores y
vendedores. Para una universidad pueden ser estudiantes, clases y
profesores. Para un hospital pueden ser pacientes, personal mdico,
medicamentos, etc.
La alineacin alrededor de las reas de los temas afecta el diseo y la

implementacin de los datos encontrados en el data warehouse. Las
principales reas de los temas influyen en la parte ms importante de la
estructura clave.
Las aplicaciones estn relacionadas con el diseo de la base de datos y
del proceso. En data warehousing se enfoca el modelamiento de datos y
el diseo de la base de datos. El diseo del proceso (en su forma clsica)
no es separado de este ambiente.
Las diferencias entre la orientacin de procesos y funciones de las
aplicaciones y la orientacin a temas, radican en el contenido de la data
a nivel detallado. En el data warehouse se excluye la informacin que no
ser usada por el proceso de sistemas de soporte de decisiones,
mientras que la informacin de las orientadas a las aplicaciones,
contiene datos para satisfacer de inmediato los requerimientos
funcionales y de proceso, que pueden ser usados o no por el analista de
soporte de decisiones.
Otra diferencia importante est en la interrelacin de la informacin. Los
datos operacionales mantienen una relacin continua entre dos o ms
tablas basadas en una regla comercial que est vigente. Las del data
warehouse miden un espectro de tiempo y las relaciones encontradas en
el data warehouse son muchas. Muchas de las reglas comerciales (y sus
correspondientes relaciones de datos) se representan en el data
warehouse, entre dos o ms tablas.
Integracin
El aspecto ms importante del ambiente data warehousing es que la
informacin encontrada al interior est siempre integrada.
La integracin de datos se muestra de muchas maneras: en
convenciones de nombres consistentes, en la medida uniforme de
variables, en la codificacin de estructuras consistentes, en atributos
fsicos de los datos consistentes, fuentes mltiples y otros.
El contraste de la integracin encontrada en el data warehouse con la
carencia de integracin del ambiente de aplicaciones, se muestran en la
Figura N 2, con diferencias bien marcadas.
A travs de los aos, los diseadores de las diferentes aplicaciones han
tomado sus propias decisiones sobre cmo se debera construir una
aplicacin. Los estilos y diseos personalizados se muestran de muchas
maneras.
Se diferencian en la codificacin, en las estructuras claves, en sus

caractersticas fsicas, en las convenciones de nombramiento y otros. La
capacidad colectiva de muchos de los diseadores de aplicaciones, para
crear aplicaciones inconsistentes, es fabulosa. La Figura N 2
mencionada, muestra algunas de las diferencias ms importantes en las
formas en que se disean las aplicaciones.
Codificacin. Los diseadores de aplicaciones codifican el campo

GENERO en varias formas. Un diseador representa GENERO como una
"M" y una "F", otros como un "1" y un "0", otros como una "X" y una "Y"
e inclusive, como "masculino" y "femenino".
No importa mucho cmo el GENERO llega al data warehouse.
Probablemente "M" y "F" sean tan buenas como cualquier otra
representacin. Lo importante es que sea de cualquier fuente de donde
venga, el GENERO debe llegar al data warehouse en un estado integrado
uniforme.
Por lo tanto, cuando el GENERO se carga en el data warehouse desde
una aplicacin, donde ha sido representado en formato "M" y "F", los
datos deben convertirse al formato del data warehouse.
Medida de atributos. Los diseadores de aplicaciones miden las

unidades de medida de las tuberas en una variedad de formas. Un
diseador almacena los datos de tuberas en centmetros, otros en
pulgadas, otros en millones de pies cbicos por segundo y otros en
yardas.
Al dar medidas a los atributos, la transformacin traduce las diversas

unidades de medida usadas en las diferentes bases de datos para
transformarlas en una medida estndar comn.
Cualquiera que sea la fuente, cuando la informacin de la tubera llegue

al data warehouse necesitar ser medida de la misma manera.
Convenciones de Nombramiento.- El mismo elemento es

frecuentemente referido por nombres diferentes en las diversas
aplicaciones. El proceso de transformacin asegura que se use
preferentemente el nombre de usuario.
Fuentes Mltiples.- El mismo elemento puede derivarse desde fuentes
mltiples. En este caso, el proceso de transformacin debe asegurar que
la fuente apropiada sea usada, documentada y movida al depsito.
Tal como se muestra en la figura, los puntos de integracin afectan casi
todos los aspectos de diseo - las caractersticas fsicas de los datos, la
disyuntiva de tener ms de una de fuente de datos, el problema de
estndares de denominacin inconsistentes, formatos de fecha
inconsistentes y otros.
Cualquiera que sea la forma del diseo, el resultado es el mismo - la
informacin necesita ser almacenada en el data warehouse en un
modelo globalmente aceptable y singular, aun cuando los sistemas
operacionales subyacentes almacenen los datos de manera diferente.
Cuando el analista de sistema de soporte de decisiones observe el data
warehouse, su enfoque deber estar en el uso de los datos que se
encuentre en el depsito, antes que preguntarse sobre la confiabilidad o
consistencia de los datos.
VII.12. De Tiempo Variante
Toda la informacin del data warehouse es requerida en algn momento.

Esta caracterstica bsica de los datos en un depsito, es muy diferente
de la informacin encontrada en el ambiente operacional. En stos, la
informacin se requiere al momento de accesar. En otras palabras, en el
ambiente operacional, cuando usted accesa a una unidad de
informacin, usted espera que los valores requeridos se obtengan a
partir del momento de acceso.
Como la informacin en el data warehouse es solicitada en cualquier
momento (es decir, no "ahora mismo"), los datos encontrados en el
depsito se llaman de "tiempo variante".
Los datos histricos son de poco uso en el procesamiento operacional.
La informacin del depsito por el contraste, debe incluir los datos
histricos para usarse en la identificacin y evaluacin de tendencias.
(Ver Figura N 3).
El tiempo variante se muestra de varias maneras:
1 La ms simple es que la informacin representa los datos sobre un

horizonte largo de tiempo - desde cinco a diez aos. El horizonte de
tiempo representado para el ambiente operacional es mucho ms corto -
desde valores actuales hasta sesenta a noventa das.
Las aplicaciones que tienen un buen rendimiento y estn disponibles
para el procesamiento de transacciones, deben llevar una cantidad
mnima de datos si tienen cualquier grado de flexibilidad. Por ello, las
aplicaciones operacionales tienen un corto horizonte de tiempo, debido
al diseo de aplicaciones rgidas.
2 La segunda manera en la que se muestra el tiempo variante en el
data warehouse est en la estructura clave. Cada estructura clave en el
data warehouse contiene, implcita o explcitamente, un elemento de
tiempo como da, semana, mes, etc.
El elemento de tiempo est casi siempre al pie de la clave concatenada,
encontrada en el data warehouse. En ocasiones, el elemento de tiempo
existir implcitamente, como el caso en que un archivo completo se
duplica al final del mes, o al cuarto.
3 La tercera manera en que aparece el tiempo variante es cuando la
informacin del data warehouse, una vez registrada correctamente, no
puede ser actualizada. La informacin del data warehouse es, para todos
los propsitos prcticos, una serie larga de "snapshots" (vistas
instantneas).
Por supuesto, si los snapshots de los datos se han tomado
incorrectamente, entonces pueden ser cambiados. Asumiendo que los
snapshots se han tomado adecuadamente, ellos no son alterados una
vez hechos. En algunos casos puede ser no tico, e incluso ilegal, alterar
los snapshots en el data warehouse. Los datos operacionales, siendo
requeridos a partir del momento de acceso, pueden actualizarse de
acuerdo a la necesidad.
VII.13. No Voltil
La informacin es til slo cuando es estable. Los datos operacionales
cambian sobre una base momento a momento. La perspectiva ms
grande, esencial para el anlisis y la toma de decisiones, requiere una
base de datos estable.
En la Figura N 4 se muestra que la actualizacin (insertar, borrar y
modificar), se hace regularmente en el ambiente operacional sobre una
base de registro por registro. Pero la manipulacin bsica de los datos
que ocurre en el data warehouse es mucho ms simple. Hay dos nicos
tipos de operaciones: la carga inicial de datos y el acceso a los mismos.
No hay actualizacin de datos (en el sentido general de actualizacin) en
el depsito, como una parte normal de procesamiento.
Hay algunas consecuencias muy importantes de esta diferencia bsica,

entre el procesamiento operacional y del data warehouse. En el nivel de
diseo, la necesidad de ser precavido para actualizar las anomalas no
es un factor en el data warehouse, ya que no se hace la actualizacin de
datos. Esto significa que en el nivel fsico de diseo, se pueden tomar
libertades para optimizar el acceso a los datos, particularmente al usar
la normalizacin y denormalizacin fsica.
Otra consecuencia de la simplicidad de la operacin del data warehouse

est en la tecnologa subyacente, utilizada para correr los datos en el
depsito. Teniendo que soportar la actualizacin de registro por registro
en modo on-line (como es frecuente en el caso del procesamiento
operacional) requiere que la tecnologa tenga un fundamento muy
complejo debajo de una fachada de simplicidad.
La tecnologa permite realizar backup y recuperacin, transacciones e

integridad de los datos y la deteccin y solucin al estancamiento que es
ms complejo. En el data warehouse no es necesario el procesamiento.
La fuente de casi toda la informacin del data warehouse es el ambiente

operacional. A simple vista, se puede pensar que hay redundancia
masiva de datos entre los dos ambientes. Desde luego, la primera
impresin de muchas personas se centra en la gran redundancia de
datos, entre el ambiente operacional y el ambiente de data warehouse.
Dicho razonamiento es superficial y demuestra una carencia de
entendimiento con respecto a qu ocurre en el data warehouse. De
hecho, hay una mnima redundancia de datos entre ambos ambientes.
Se debe considerar lo siguiente:
Los datos se filtran cuando pasan desde el ambiente operacional al de

depsito. Existe mucha data que nunca sale del ambiente operacional.
Slo los datos que realmente se necesitan ingresarn al ambiente de
data warehouse.
El horizonte de tiempo de los datos es muy diferente de un ambiente al

otro. La informacin en el ambiente operacional es ms reciente con
respecto a la del data warehouse. Desde la perspectiva de los horizontes
de tiempo nicos, hay poca superposicin entre los ambientes
operacional y de data warehouse.
El data warehouse contiene un resumen de la informacin que no se

encuentra en el ambiente operacional.
Los datos experimentan una transformacin fundamental cuando pasa al

data warehouse. La mayor parte de los datos se alteran
significativamente al ser seleccionados y movidos al data warehouse.
Dicho de otra manera, la mayora de los datos se alteran fsica y
radicalmente cuando se mueven al depsito. No es la misma data que
reside en el ambiente operacional desde el punto de vista de
integracin.
En vista de estos factores, la redundancia de datos entre los dos
ambientes es una ocurrencia rara, que resulta en menos de 1%.
VII.14. ESTRUCTURA DEL DATA WAREHOUSE
Los data warehouses tienen una estructura distinta. Hay niveles

diferentes de esquematizacin y detalle que delimitan el data
warehouse. La estructura de un data warehouse se muestra en la Figura
N 5.
En la figura, se muestran los diferentes componentes del data
warehouse y son:
Detalle de datos actuales

Detalle de datos antiguos
Datos ligeramente resumidos
Datos completamente resumidos
Meta data
Detalle de datos actuales.- En gran parte, el inters ms importante
radica en el detalle de los datos actuales, debido a que:
Refleja las ocurrencias ms recientes, las cuales son de gran inters
Es voluminoso, ya que se almacena al ms bajo nivel de granularidad.
Casi siempre se almacena en disco, el cual es de fcil acceso, aunque su
administracin sea costosa y compleja.
Detalle de datos antiguos.- La data antigua es aquella que se
almacena sobre alguna forma de almacenamiento masivo. No es
frecuentemente accesada y se almacena a un nivel de detalle,
consistente con los datos detallados actuales. Mientras no sea prioritario
el almacenamiento en un medio de almacenaje alterno, a causa del gran
volumen de datos unido al acceso no frecuente de los mismos, es poco
usual utilizar el disco como medio de almacenamiento.
Datos ligeramente resumidos.- La data ligeramente resumida es
aquella que proviene desde un bajo nivel de detalle encontrado al nivel
de detalle actual. Este nivel del data warehouse casi siempre se
almacena en disco. Los puntos en los que se basa el diseador para
construirlo son:
Que la unidad de tiempo se encuentre sobre la esquematizacin hecha.
Qu contenidos (atributos) tendr la data ligeramente resumida.
Datos completamente resumidos.- El siguiente nivel de datos
encontrado en el data warehouse es el de los datos completamente
resumidos
A veces se encuentra en el ambiente de data warehouse y en otros,

fuera del lmite de la tecnologa que ampara al data warehouse. (De
todos modos, los datos completamente resumidos son parte del data
warehouse sin considerar donde se alojan los datos fsicamente.)
Metadata.- El componente final del data warehouse es el de la

metadata. De muchas maneras la metadata se sita en una dimensin
diferente al de otros datos del data warehouse, debido a que su
contenido no es tomado directamente desde el ambiente operacional.
La metadata juega un rol especial y muy importante en el data
warehouse y es usada como:
Un directorio para ayudar al analista a ubicar los contenidos del data
warehouse.
Una gua para el mapping de datos de cmo se transforma, del ambiente
operacional al de data warehouse.
Una gua de los algoritmos usados para la esquematizacin entre el

detalle de datos actual, con los datos ligeramente resumidos y stos,
con los datos completamente resumidos, etc.
. Estos datos son compactos y fcilmente
La metadata juega un papel mucho ms importante en un ambiente

data warehousing que en un operacional clsico.
A fin de recordar los diferentes niveles de los datos encontrados en el
data warehouse, considere el ejemplo mostrado en la Figura N 6.
El detalle de ventas antiguas son las que se encuentran antes de 1992.
Todos los detalles de ventas desde 1982 (o cuando el diseador inici la
coleccin de los archivos) son almacenados en el nivel de detalle de
datos ms antiguo.
El detalle actual contiene informacin desde 1992 a 1993 (suponiendo
que 1993 es el ao actual). En general, el detalle de ventas no se ubica
en el nivel de detalle actual hasta que haya pasado, por lo menos,
veinticuatro horas desde que la informacin de ventas llegue a estar
disponible en el ambiente operacional.
accesibles.
En otras palabras, habra un retraso de tiempo de por lo menos

veinticuatro horas, entre el tiempo en que en el ambiente operacional se
haya hecho un nuevo ingreso de la venta y el momento cuando la
informacin de la venta haya ingresado al data warehouse.
El detalle de las ventas son resumidas semanalmente por lnea de
subproducto y por regin, para producir un almacenamiento de datos
ligeramente resumidos.
El detalle de ventas semanal es adicionalmente resumido en forma
mensual, segn una gama de lneas, para producir los datos
completamente resumidos.
La metadata contiene (al menos):

La estructura de los datos
Los algoritmos usados para la esquematizacin
El mapping desde el ambiente operacional al data warehouse
La informacin adicional que no se esquematiza es almacenada en el

data warehouse. En muchas ocasiones, all se har el anlisis y se
producir un tipo u otro de resumen. El nico tipo de esquematizacin
que se almacena permanentemente en el data warehouse, es el de los
datos que son usados frecuentemente. En otras palabras, si un analista
produce un resumen que tiene una probabilidad muy baja de ser usado
nuevamente, entonces la esquematizacin no es almacenada en el data
warehouse.
VII.15. ARQUITECTURA DE UN DATA WAREHOUSE
Una de las razones por las que el desarrollo de un data warehouse crece
rpidamente, es que realmente es una tecnologa muy entendible. De
hecho, data warehousing puede representar mejor la estructura amplia
de una empresa para administrar los datos informacionales dentro de la
organizacin. A fin de comprender cmo se relacionan todos los
componentes involucrados en una estrategia data warehousing, es
esencial tener una Arquitectura Data Warehouse.
ARQUITECTURA DE UN DATA WAREHOUSE

Elementos constituyentes de una Arquitectura Data Warehouse
Una Arquitectura Data Warehouse (Data Warehouse Architecture - DWA)

es una forma de representar la estructura total de datos, comunicacin,
procesamiento y presentacin, que existe para los usuarios finales que
disponen de una computadora dentro de la empresa.
La arquitectura se constituye de un nmero de partes interconectadas:
Base de datos operacional / Nivel de base de datos externo
Nivel de acceso a la informacin
Nivel de acceso a los datos
Nivel de directorio de datos (Metadata)
Nivel de gestin de proceso
Nivel de mensaje de la aplicacin
Nivel de data warehouse
Nivel de organizacin de datos
Base de datos operacional / Nivel de base de datos externo

Los sistemas operacionales procesan datos para apoyar las necesidades
operacionales crticas. Para hacer eso, se han creado las bases de datos
operacionales histricas que proveen una estructura de procesamiento
eficiente, para un nmero relativamente pequeo de transacciones
comerciales bien definidas.
Sin embargo, a causa del enfoque limitado de los sistemas
operacionales, las bases de datos diseadas para soportar estos
sistemas, tienen dificultad al accesar a los datos para otra gestin o
propsitos informticos.
Esta dificultad en accesar a los datos operacionales es amplificada por el
hecho que muchos de estos sistemas tienen de 10 a 15 aos de
antigedad. El tiempo de algunos de estos sistemas significa que la
tecnologa de acceso a los datos disponible para obtener los datos

operacionales, es as mismo antigua.
Ciertamente, la meta del data warehousing es liberar la informacin que
es almacenada en bases de datos operacionales y combinarla con la
informacin desde otra fuente de datos, generalmente externa.
Cada vez ms, las organizaciones grandes adquieren datos adicionales
desde bases de datos externas. Esta informacin incluye tendencias
demogrficas, economtricas, adquisitivas y competitivas (que pueden
ser proporcionadas por Instituciones Oficiales - INEI). Internet o tambin
llamada "information superhighway" (supercarretera de la informacin)
provee el acceso a ms recursos de datos todos los das.
Nivel de acceso a la informacin

El nivel de acceso a la informacin de la arquitectura data warehouse, es
el nivel del que el usuario final se encarga directamente. En particular,
representa las herramientas que el usuario final normalmente usa da a
da. Por ejemplo: Excel, Lotus 1-2-3, Focus, Access, SAS, etc.
Este nivel tambin incluye el hardware y software involucrados en
mostrar informacin en pantalla y emitir reportes de impresin, hojas de
clculo, grficos y diagramas para el anlisis y presentacin. Hace dos
dcadas que el nivel de acceso a la informacin se ha expandido
enormemente, especialmente a los usuarios finales quienes se han
volcado a las PCs monousuarias y las PCs en redes.
Actualmente, existen herramientas ms y ms sofisticadas para
manipular, analizar y presentar los datos, sin embargo, hay problemas
significativos al tratar de convertir los datos tal como han sido
recolectados y que se encuentran contenidos en los sistemas
operacionales en informacin fcil y transparente para las herramientas
de los usuarios finales. Una de las claves para esto es encontrar un
lenguaje de datos comn que puede usarse a travs de toda la empresa.
Nivel de acceso a los datos

El nivel de acceso a los datos de la arquitectura data warehouse est
involucrado con el nivel de acceso a la informacin para conversar en el
nivel operacional. En la red mundial de hoy, el lenguaje de datos comn
que ha surgido es SQL. Originalmente, SQL fue desarrollado por IBM
como un lenguaje de consulta, pero en los ltimos veinte aos ha
llegado a ser el estndar para el intercambio de datos.
Uno de los adelantos claves de los ltimos aos ha sido el desarrollo de
una serie de "filtros" de acceso a datos, tales como EDA/SQL para
accesar a casi todo los Sistemas de Gestin de Base de Datos (Data
Base Management Systems - DBMSs) y sistemas de archivos de datos,
relacionales o no. Estos filtros permiten a las herramientas de acceso a
la informacin, accesar tambin a la data almacenada en sistemas de
gestin de base de datos que tienen veinte aos de antigedad.
El nivel de acceso a los datos no solamente conecta DBMSs diferentes y

sistemas de archivos sobre el mismo hardware, sino tambin a los
fabricantes y protocolos de red. Una de las claves de una estrategia data
warehousing es proveer a los usuarios finales con "acceso a datos
universales".
El acceso a los datos universales significa que, tericamente por lo
menos, los usuarios finales sin tener en cuenta la herramienta de acceso
a la informacin o ubicacin, deberan ser capaces de accesar a
cualquier o todos los datos en la empresa que es necesaria para ellos,
para hacer su trabajo.
El nivel de acceso a los datos entonces es responsable de la interfase
entre las herramientas de acceso a la informacin y las bases de datos
operacionales. En algunos casos, esto es todo lo que un usuario final
necesita. Sin embargo, en general, las organizaciones desarrollan un
plan mucho ms sofisticado para el soporte del data warehousing.
Nivel de Directorio de Datos (Metadata)

A fin de proveer el acceso a los datos universales, es absolutamente
necesario mantener alguna forma de directorio de datos o repositorio de
la informacin metadata. La metadata es la informacin alrededor de los
datos dentro de la empresa.
Las descripciones de registro en un programa COBOL son metadata.
Tambin lo son las sentencias DIMENSION en un programa FORTRAN o
las sentencias a crear en SQL.
A fin de tener un depsito totalmente funcional, es necesario tener una
variedad de metadata disponibles, informacin sobre las vistas de datos
de los usuarios finales e informacin sobre las bases de datos
operacionales. Idealmente, los usuarios finales deberan de accesar a los
datos desde el data warehouse (o desde las bases de datos
operacionales), sin tener que conocer dnde residen los datos o la forma
en que se han almacenados.
Nivel de Gestin de Procesos

El nivel de gestin de procesos tiene que ver con la programacin de
diversas tareas que deben realizarse para construir y mantener el data
warehouse y la informacin del directorio de datos. Este nivel puede
depender del alto nivel de control de trabajo para muchos procesos
(procedimientos) que deben ocurrir para mantener el data warehouse
actualizado.
Nivel de Mensaje de la Aplicacin

El nivel de mensaje de la aplicacin tiene que ver con el transporte de
informacin alrededor de la red de la empresa. El mensaje de aplicacin
se refiere tambin como "subproducto", pero puede involucrar slo
protocolos de red. Puede usarse por ejemplo, para aislar aplicaciones
operacionales o estratgicas a partir del formato de datos exacto,
recolectar transacciones o los mensajes y entregarlos a una ubicacin

segura en un tiempo seguro.
Nivel Data Warehouse (Fsico)

En el data warehouse (ncleo) es donde ocurre la data actual, usada
principalmente para usos estratgicos. En algunos casos, uno puede
pensar del data warehouse simplemente como una vista lgica o virtual
de datos. En muchos ejemplos, el data warehouse puede no involucrar
almacenamiento de datos.
En un data warehouse fsico, copias, en algunos casos, muchas copias
de datos operacionales y/o externos, son almacenados realmente en una
forma que es fcil de accesar y es altamente flexible. Cada vez ms, los
data warehouses son almacenados sobre plataformas cliente/servidor,
pero por lo general se almacenan sobre mainframes.
Nivel de Organizacin de Datos

El componente final de la arquitectura data warehouse es la
organizacin de los datos. Se llama tambin gestin de copia o rplica,
pero de hecho, incluye todos los procesos necesarios como seleccionar,
editar, resumir, combinar y cargar datos en el depsito y accesar a la
informacin desde bases de datos operacionales y/o externas.
La organizacin de datos involucra con frecuencia una programacin
compleja, pero cada vez ms, estn crendose las herramientas data
warehousing para ayudar en este proceso. Involucra tambin programas
de anlisis de calidad de datos y filtros que identifican modelos y
estructura de datos dentro de la data operacional existente.
Operaciones en un Data Warehouse
En la Figura N 8 se muestra algunos de los tipos de operaciones que se

efectan dentro de un ambiente data warehousing.
a) Sistemas Operacionales
Los datos administrados por los sistemas de aplicacin operacionales
son la fuente principal de datos para el data warehouse.
Las bases de datos operacionales se organizan como archivos indexados
(UFAS, VSAM), bases de datos de redes/jerrquicas (I-D-S/II, IMS, IDMS) o
sistemas de base de datos relacionales (DB2, Oracle, Informix, etc.).
Segn las encuestas, aproximadamente del 70% a 80% de las bases de
datos de las empresas se organizan usando DBMSs no relacional.
b) Extraccin, Transformacin y Carga de los Datos
Se requieren herramientas de gestin de datos para extraer datos desde
bases de datos y/o archivos operacionales, luego es necesario manipular
o transformar los datos antes de cargar los resultados en el data
warehouse.
Tomar los datos desde varias bases de datos operacionales y
transformarlos en datos requeridos para el depsito, se refiere a la
transformacin o a la integracin de datos. Las bases de datos
operacionales, diseadas para el soporte de varias aplicaciones de
produccin, frecuentemente difieren en el formato.
Los mismos elementos de datos, si son usados por aplicaciones
diferentes o administrados por diferentes software DBMS, pueden
definirse al usar nombres de elementos inconsistentes, que tienen
formatos inconsistentes y/o ser codificados de manera diferente. Todas
estas inconsistencias deben resolverse antes que los elementos de datos
sean almacenados en el data warehouse.
c) Metadata
Otro paso necesario es crear la metadata. La metadata (es decir, datos

acerca de datos) describe los contenidos del data warehouse. La
metadata consiste de definiciones de los elementos de datos en el
depsito, sistema(s) del (os) elemento(s) fuente. Como la data, se
integra y transforma antes de ser almacenada en informacin similar.
d) Acceso de usuario final

Los usuarios accesan al data warehouse por medio de herramientas de
productividad basadas en GUI (Graphical User Interface - Interfase
grfica de usuario). Pueden proveerse a los usuarios del data warehouse
muchos de estos tipos de herramientas.
Estos pueden incluir software de consultas, generadores de reportes,
procesamiento analtico en lnea, herramientas data/visual mining, etc.,
dependiendo de los tipos de usuarios y sus requerimientos particulares.
Sin embargo, una sola herramienta no satisface todos los
requerimientos, por lo que es necesaria la integracin de una serie de
herramientas.
e) Plataforma del data warehouse

La plataforma para el data warehouse es casi siempre un servidor de
base de datos relacional. Cuando se manipulan volmenes muy grandes
de datos puede requerirse una configuracin en bloque de servidores
UNIX con multiprocesador simtrico (SMP) o un servidor con procesador
paralelo masivo (MPP) especializado.
Los extractos de la data integrada/transformada se cargan en el data
warehouse. Uno de los ms populares RDBMSs disponibles para data
warehousing sobre la plataforma UNIX (SMP y MPP) generalmente es
Teradata. La eleccin de la plataforma es crtica. El depsito crecer y
hay que comprender los requerimientos despus de 3 o 5 aos.
Muchas de las organizaciones quieran o no escogen una plataforma por
diversas razones: el Sistema X es nuestro sistema elegido o el Sistema Y
est ya disponible sobre un sistema UNIX que nosotros ya tenemos. Uno
de los errores ms grandes que las organizaciones cometen al
seleccionar la plataforma, es que ellos presumen que el sistema
(hardware y/o DBMS) escalar con los datos.
El sistema de depsito ejecuta las consultas que se pasa a los datos por
el software de acceso a los datos del usuario. Aunque un usuario
visualiza las consultas desde el punto de vista de un GUI, las consultas
tpicamente se formulan como pedidos SQL, porque SQL es un lenguaje
universal y el estndar de hecho para el acceso a datos.
f) Datos Externos
Dependiendo de la aplicacin, el alcance del data warehouse puede
extenderse por la capacidad de accesar a la data externa. Por ejemplo,
los datos accesibles por medio de servicios de computadora en lnea
(tales como CompuServe y America On Line) y/o va Internet, pueden
estar disponibles a los usuarios del data warehouse.
Evolucin del Depsito

Construir un data warehouse es una tarea grande. No es recomendable
emprender el desarrollo del data warehouse de la empresa como un
proyecto cualquiera. Ms bien, se recomienda que los requerimientos de
una serie de fases se desarrollen e implementen en modelos
consecutivos que permitan un proceso de implementacin ms gradual
e iterativo.
No existe ninguna organizacin que haya triunfado en el desarrollo del
data warehouse de la empresa, en un slo paso. Muchas, sin embargo, lo
han logrado luego de un desarrollo paso a paso. Los pasos previos
evolucionan conjuntamente con la materia que est siendo agregada.
Los datos en el data warehouse no son voltiles y es un repositorio de
datos de slo lectura (en general). Sin embargo, pueden aadirse
nuevos elementos sobre una base regular para que el contenido siga la
evolucin de los datos en la base de datos fuente, tanto en los
contenidos como en el tiempo.
Uno de los desafos de mantener un data warehouse, es idear mtodos
para identificar datos nuevos o modificados en las bases de datos
operacionales. Algunas maneras para identificar estos datos incluyen
insertar fecha/tiempo en los registros de base de datos y entonces crear
copias de registros actualizados y copiar informacin de los registros de
transaccin y/o base de datos diarias.
Estos elementos de datos nuevos y/o modificados son extrados,
integrados, transformados y agregados al data warehouse en pasos
peridicos programados. Como se aaden las nuevas ocurrencias de
datos, los datos antiguos son eliminados. Por ejemplo, si los detalles de
un sujeto particular se mantienen por 5 aos, como se agreg la ltima
semana, la semana anterior es eliminada.
BIBLIOGRAFIA
AO
AUTOR OBRA LUGAR EDITORIAL
DE
EDIC.
1999
Korth, Henry Fundamentos de Base ESPAA MC GRAW HILL

de datos
Sistemas de base de
Date, J. C. Datos
Hawryszkiewycz Anlisis y Diseo de

Bases de Datos
Groff, James &
Aplique SQL
Weinber, Paul
ANEXOS
PRACTICA
EJERCICIOS A RESOLVER
MODELO ER - ALGEBRA RELACIONAL
Para cada uno de los ejercicios siguientes, debe realizar:

Modelo Entidad Relaicin

Anlisis de Tablas Esqueleto
Modelo Relacional
Normalizacin (1FN, 2FN y 3FN)
Aplicar Algebra Relacional para dar respuesta a las consultas (antes de
generarlas, verifique que su diseo no tenga errores).
NOTA. El trabajo debe ser realizado por los estudiantes que en el segundo
parcial obtuvieron una nota menor al 50% en su examen, de forma personal.
En papel segn el formato fijado en clases.
EJERCICIO NRO. 1
Realizar el diseo de una Base de Datos para la Asignacin y Control de Aulas
La Universidad Salesiana de Bolivia cuenta con diferentes predios tanto en la
zona: central, vino tinto y 1ro. de Mayo, se deben tomar en cuenta las
consideraciones siguientes:
Existes tres tipos de ambientes: Laboratorios, Aula de Clase terica, Oficinas.

Cada una de ellas es usadas para las clases correspondientes a cada carrera.
Cada aula tiene una capacidad limitada.
Al inicio de cada semestre el director de cada carrera realiza la asignacin
correspondiente de las aulas.
Cada aula puede ser usada por diferentes carreras, las veces que sea as
necesario siempre y cuando no haya ningn tipo de cruces de horario en las
asignaciones realizadas.
Existen ambientes que no son asignados a un carrera especfica, sino que son
compartidos por varias carreras.
La asignacin de aulas es realizada tanto a docente como auxiliares de
ctedra.
Cada jefe de carrera desea conocer:
Listado de aulas libres y ocupadas.
Listado de aulas por tipo.
Listado de aulas con una capacidad X.
Listado de asignaciones por da (Por ejemplo: Qu aulas estn ocupadas un dia
X).
Listado de asignaciones realizadas por aula
Listado de aulas asignadas por docente.
Listado de aulas asignadas por semestre.
Listado general de aulas
Listado general de docentes y auxiliares
Listado de asignaciones por semestre
Listado de asignaciones de aulas por carrera
Listado de asignaciones de aulas por materia
Una vez finalizado el semestre se planifica otras nuevas asignaciones para la
gestin prxima, archivando las anteriores correspondiente al semestre
anterior.
EJERCICIO NRO. 2
Disear la Base de Datos Gua Turstica, haciendo uso del lenguaje de
consulta Algebra Relacional genere las consultas siguientes:
Listado de Guas ordenados por Paterno

Listado de Centros Tursticos por tipo: Iglesias, Museos, Lugares de distraccin,
etc.
Listado de Servicios prestados ordenados por fechas, con el detalle de nombres
tanto de guas como de turistas.
Listado de circuitos asignados a turistas.
Listado de Servicio prestado durante el mes de febrero y Junio.
Listado de Lugares tursticos agrupados por Circuitos.
Listado de lugares tursticos por circuito al que corresponde.
Listado de precios por circuito con el detalle de los lugares tursticos.
PRACTICA
ALGEBRA RELACIONAL
Tomando el Diseo de la Base de Datos para el Control de Inscripciones y

Notas, realizada en clases habindola normalizado se toman los siguientes
atributos:
MODELO RELACIONAL FINAL
MATERIA (Sigla, Nombre_Mat, Carga_H, Semestre, Cod_Carr)

CARRERA (Cod_Carr, Nom, Grado, Modalidad, Duracin)
ESTUDIANTE(RU, CI, Nom, Dir, Fono, Fecha_Egr, Fecha_Ingr, ..)
DOCENTE (Cod_Doc, CI, Nom, Dir, Fono,)
PROFESION (Nro_Prof, Cod_Doc, Profesin, Grado)
DICTA (Id_Dicta, Cod_Mat, Cod_Doc, Gestin,Paralelo, ..)
HORARIO (Nro_H, Id_Dicta, Dia, Hora, Obs)
NOTA (Nro_R, Id_Dicta, RU, P1, P2, P3, EF, OBS)
INSCRIPCION (Nro_Ins, RU, Cod_Mat, Fecha_Ins, ..)
INTRODUCIONEDO DATOS DE PRUEBA
CARRERA (CA)
Cod_Carr Nombre_Carr Grado Mencin Modalidad Duracin
IDS Ingeniera de Licenciat Ingenier Semestra 5 aos

Sistemas ura o en l
Sistema
s
CED Ciencias de la Licenciat Semestra 5 aos

Educacin ura l
CONT Contadura Licenciat Contado Semestra 5 aos

Pblica ura r l
DER Derecho Licenciat Abogado Semestra 5 aos

ura l
MATERIA(MA)
Cod_Mat Nombre_Mat Carga_H Semestre Cod_Carr
SIS-111 Introduccin a 1ro. IDS

la
programacin
SIS-221 Programacin 4to. IDS

III
SIS-311 Algoritmos 5to. IDS

Avanzados
SIS-312 Base de Datos 5to. IDS

II
SIS-313 Anlisis y 5to. IDS

Diseo de
Sistemas I
MAT-314 Anlisis 5to. IDS

Numrico
SIS-315 Hardware y 5to. IDS

Arquitectura
de
Computadora
CSO-112 Sociologa 1ro. CED

General
HIS-123 Historia de 1ro. CED

Educacin
Uniersal
PSI-122 Fundamentos 2do. CED

de la
Psicologa de
la Educacin
CON-121 Contabilidad 2do. CONT

Intermedia
ADM-112 Administracin 1ro. CONT

I
DER-111 Introduccin al 1ro. DER

Derecho
DER-211 Derecho Penal 3ro. DER

I
DER-321 Medicina Legal 6to. DER
ESTUDIANTE (ES)
RU CI Pat Mat Nom Dir Fono Fecha_Egr Fecha_Ing
AAA-110180 1111111-LP Ana Ali Arce Z. Villa Dolores 2833456 12/12/1997 15/01/2000
C.4 Nro.34
BBB-181085 222222-CB Burgos Bello Boris Z. Villa Ftima 2224750 10/12/2001 10/01/2002
C.5 Nro. 56
CCC-160386 333333-OR Castro Calle Carlyn Z. Tejada Sorzano 2221567 14/12/2002 20/01/2003
346 Nro.45
DDD-200384 444444-STC Daza Dolz Dennis Z. Cementerio 2474523 10/12/2003 18/01/2004

Nro. 45
EEE-170885 555555-LP Elio Eguez Erlan Z. Av. 6 de Agosto 2312357 08/12/2003 25/01/2004
Nro. 345
DOCENTE (DO)
Cod_Doc CI_#PAS Pat Mat Nom Dir Fono Nacionalidad
D0001 7777777-LP Vedia Daza Irene Z. Villa Ftima C.34 2456732 Boliviana
Nro. 45
D0010 8888888-CB Mollinedo Laura Carmen Z. Rio Seco Plan 34 28647891 Boliviana
Nro. 56
D0015 999999-OR Quisbert Vilela Jos Z. Tejada Sorzano C.4 2488956 Boliviano
Nro. 120
D0100 234567 Jestick Buitriago Frank Z. Calacoto C.12 Nro. 21122355 Argentino
24
D0205 456773 Homero Baados Prez Z. Obrajes C. 5 nro. 45 2104567 Brasilero

D0300 1010101-LP Luna Tellez Marco Z. Cuidad Saltlite C.3 2813456 Boliviano
Nro. 56
D0305 1212122-OR Rocha Vera Jess Z. Av. 16 de julio C. 34 2840934 Boliviano

Nro. 56
PROFESION (PRO)
Nro_Prof Cod_Doc Profesin Grado
100 D0001 Informtica Licenciatura
102 D0010 Informtica Maestra
120 D0015 Abogado Licenciatura
121 D0100 Abogado Licenciatura
122 D0100 Psiclogo Licenciatura
123 D0100 Historiador Tcnico Superior
130 D0205 Ing. en Sistemas Licenciatura
131 D0205 Estadstico Licenciatura
140 D0300 Contador Pblico Maestra
141 D0300 Abogado Egresado
150 D0305 Educador Lienciatura
CASO ESPECIAL: En el que una misma Materia,

es dictada por el mismo Docente, en la misma
Gestin y en Paralelos diferentes.
DICTA (DIC)
Id_Dicta Cod_Mat Cod_Doc Gestin Paralelo
20 SIS - 111 D0010 II 2003 A1
21 SIS - 111 D0010 II 2003 B2
22 SIS - 111 D0010 II 2003 C1
29 SIS 111 D0010 I 2004 A1
30 SIS 311 D0205 I 2004 A1
35 SIS 312 D0010 I 2004 B2
50 SIS 313 D0205 I 2004 C1
55 DER 111 D0100 I 2004 B1
70 DER 211 D0100 I 2004 C1
80 CON 121 D0300 I 2004 A1
90 ADM 112 D0300 I 2004 C1
100 DER 321 D0300 I 2004 A1
150 PSI 122 D0305 I 2004 C1
160 HIS 123 D0300 I 2004 B2
180 CSO 112 D0300 I 2004 C2
190 SIS 111 D0205 II 2004 B2
HORARIO
Nro_H Id_Dicta Dia Hora
10 20 Lunes 7:30 9:00
11 20 Mircoles 7:30 9:00
12 21 Martes 9:00 11:00
13 21 Jueves 11:00 12:15
20 22 Mircoles 9:15 10:45
21 22 Viernes 7:30 9:00
25 30 Lunes 18:30 20:00
26 30 Mircoles 20:00 21:45
30 35 Lunes 18:00 20:00
31 35 Viernes 18:00 20:00
100 50 Martes 9:15 10:45
101 50 Jueves 9:15 10:45
110 55 Mircoles 20:00 21:45
111 55 Jueves 18:30 21:45
CASO ESPECIAL: En el que al mismo

Estudiante, le corresponden tres materias
dictadas en 3 gestiones diferentes por dos
docentes (ya que en dos ocasiones cursa con el
mismo docente y no aprueba la materia).
NOTA (NO)
Nro_R Id_Dicta RU P1 P2 P3 EF OBS
10 20 AAA-110180 10 NSP NSP NSP ABANDONO
40 29 AAA-110180 10 10 5 5 REPROBADO
40 190 AAA-110180 20 10 15 15 APROBADO
50 30 BBB-110180 10 10 10 25 APROBADO
51 35 BBB-110180 15 15 14 20 APROBADO
52 50 BBB-181085 20 20 20 10 APROBADO
60 55 CCC-160386 13 14 15 20 APROBADO
61 70 CCC-160386 11 11 20 20 APROBADO
70 80 DDD-200384 12 12 2 15 REPROBADO
71 90 DDD-200384 10 3 4 2 REPROBADO
100 150 EEE-170885 4 NSP NSP NSP ABANDONO
101 160 EEE-170885 NSP NSP NSP NSP APROBADO
Donde NSP = No Se Present
INSCRIPCION (INS)
Nro_Ins RU Cod_Mat Fecha_Ins
200 AAA-110180 SIS-111 15/06/200

3
250 BBB-181085 SIS-311 16/01/200

251 BBB-181085 SIS-312 16/01/200

4
252 BBB-181085 SIS-313 16/01/200

4
300 CCC-160386 DER-111 08/01/200

4
400 DDD-200384 CON-121 12/01/200

4
401 DDD-200384 ADM-112 20/01/200

4
502 EEE-170885 PSI-122 25/01/200

4
600 AAA-110180 SIS-111 10/01/200

4
1200 AAA-110180 SIS-111 15/06/200

4
APLICANDO ALGEBRA RELACIONAL
Se pide generar las siguientes consultas:
1. Listado del Pensum de Materias

2. Listado de Estudiantes de la Carrera de Ingeniera de Sistemas
3. Listado de Actas de Notas de la Materia: SIS-311 Docente: Lic.
Carmen Mollinbedo Laura Paralelo: A1 Gestin: II 2003.
4. Listado de Asignaciones de Materias realizadas durante la
gestin I 2004
5. Listado de Asignaciones de Materias realizadas durante la
gestin I 2004 en las Carreras de Derecho e Ingeniera de
Sistemas.
6. Horarios de Clase Correspondientes a los dias Lunes y Mircoles

de la Carrera Ingeniera de Sistemas del Quinto Semestre
(Maana, tarde y Noche).
7. Listado de Inscritos durante la gestin I 2004
8. Listado de Docentes con Profesin Abogado
9. Listado de Docentes con profesin Abogado y Contador
10. Listado de los mejores Estudiantes de Ingeniera de Sistemas
11. Listado de estudiantes que nunca reprobaron ni abandonaron
materias
12. Listado de estudiantes que nunca reprobaron ni abandonaron
materias en la carrera de Derecho.
13. Listado de Estudiantes que reprobaron materias ms de una
vez
14. Listado de Materias aprobadas por un determinado estudiante
15. Listado de Materias reprobadas por un determinado
estudiante
16. Listado de Materias abandonadas por un determinado
estudiante
17. Listado de Docentes de la Carrera de Ingeniera de Sistemas
18. Listado de Listado de Paralelos dictados correspondientes a la
Materia: Introduccin a la Programacin
19. Listado de Estudiantes que no corresponden a las carreras:
Ingeniera de Sistemas ni Contadura Pblica
20. Materias aprobadas por un estudiante determinado durante la
gestin I-2004-03-04

Katya

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Katya

Încărcat de

Drepturi de autor:

Formate disponibile

Base de Datos II 1

UNIVERSIDAD SALESIANA DE BOLIVIA

CARRERA INGENIERA DE SISTEMAS

Lic. Katya Maricela Prez Martnez

2.2.2. Proyeccin ():...............................................................................................36

2.3. CALCULO RELACIONAL...................................................................................39

3.16.1. LA UNION DE TABLAS UNION.................................................................56

Un objetivo principal de un sistema de base de datos es proporcionar

I.2. Objetivos de los sistemas de bases de datos.

I.2.1. Redundancia e inconsistencia de datos.

I.2.2. Dificultad para tener acceso a los datos.

diseo del sistema, no existe ninguna aplicacin de consulta que

I.2.3. Aislamiento de los datos.

I.2.4. Anomalas del acceso concurrente.

I.2.5. Problemas de seguridad.

I.2.6. Problemas de integridad.

I.3. Sistemas de bases de datos

La definicin de los datos se encuentra codificada dentro de los

No hay control sobre el acceso y la manipulacin de los datos ms all

Para trabajar de un modo ms efectivo, surgieron las bases de datos y

Una base de datos es un conjunto de datos almacenados entre los que

La base de datos es un gran almacn de datos que se define una sola

El modelo seguido con los sistemas de bases de datos, en donde se

El sistema de gestin de la base de datos (SGBD) es una

El SGBD es la aplicacin que interacciona con los usuarios de los

Permite la definicin de la base de datos mediante el lenguaje de

y el tipo de los datos, as como las restricciones sobre los datos.

Permite la insercin, actualizacin, eliminacin y consulta de datos

Hay dos tipos de lenguajes de manejo de datos: los procedurales y

Proporciona un acceso controlado a la base de datos mediante:

o un sistema de seguridad, de modo que los usuarios no

o un sistema de integridad que mantiene la integridad y la

o un sistema de control de concurrencia que permite el acceso

o un sistema de control de recuperacin que restablece la

o un diccionario de datos o catlogo accesible por el usuario

A diferencia de los sistemas de ficheros, el SGBD gestiona la estructura

proporcionan un mecanismo de vistas que permite que cada usuario

Las vistas, adems de reducir la complejidad permitiendo que cada

Las vistas proporcionan un nivel de seguridad, ya que permiten

Las vistas proporcionan un mecanismo para que los usuarios vean

Una vista representa una imagen consistente y permanente de la

Todos los SGBD no presentan la misma funcionalidad, depende de cada

I.4. Los distintitos niveles de abstraccin de una

Existen diferentes niveles de abstraccin para simplificar la interaccin

Es la representacin del nivel ms bajo de abstraccin, en ste se

El siguiente nivel ms alto de abstraccin, describe que datos son

Nivel ms alto de abstraccin, es lo que el usuario final puede visualizar

I.5. Usuarios y administradores de la base de datos.

Denominado por sus siglas como: DBA, Database Administrator.

Es la persona encargada y que tiene el control total sobre el sistema de

Es el esquema original de la base de datos se crea escribiendo un

Definicin de la estructura de almacenamiento del mtodo de

Estructuras de almacenamiento y de acceso adecuados se crean

Concesin de autorizacin para el acceso a los datos

Permite al administrador de la base de datos regular las partes de las

Especificacin de lmitantes de integridad

Es una serie de restricciones que se encuentran almacenados en una

Usuarios de las bases de datos.

Los profesionales en computacin que interactuan con el sistema por

Los usuarios sofisticados interactan con el sistema sin escribir

Algunos usuarios sofisticados escriben aplicaciones de base de datos

Los usuarios no sofisticados interactan con el sistema invocando a uno

I.6. Componentes de los sistemas de bases de datos