Download dossier base de datos ii - ingrese usuario y clave

UNIVERSIDAD SALESIANA
DE BOLIVIA
INGENIERIA DE SISTEMAS
DOSSIER
BASE DE DATOS II
Docente: Lic. Oscar F. Aguilar Gemio
I - 2012
1
INDICE
Presentacion……………………………………………………………………….…………3
1. Tema 1 Lenguajes de consulta formales ………………………….….…...4
1.1. El modelo relacional……………………………………………………………….……. 4
1.2. Operaciones en el Modelo de Datos Relacional ………………………………….………5
1.3. Algebra relacional………………………………………………………………….……..5
1.4. Operadores Relacionales …………………………………………………….………….. 6
1.5. Union……………………………………………………………………………….……. 6
1.6. Intersección …………………………………………………………………….…….…...7
1.7. Diferencia ………………………………………………………………………..…….….7
1.8. Producto Cartesiano ……………………………………………………….………….….8
1.9. Selección …………………………………………………………………………….……9
1.10. Proyección………………………………………………………………………….…….10
1.11. División ………………………………………………………………………….………11
1.12. Operadores No básicos ………………………………………………………….……….12
1.13. Ejercicios de álgebra relacional ………………………………………………………….12
1.14. Limitaciones del álgebra relacional …………………………………………………..….12
2. Tema 2 Lenguajes de consulta comerciales………….…………………. 14
2.1. Introducción………………………………………………………………………………14
2.2. El Modelo de Datos Relacional…………………………………………………………..14
2.3. El Lenguaje SQL………………………………………………………………………….15
2.4. Select ……………………………………………………………………………………..15
2.5. Joins ………………………………………………………………………………………16
2.6. Operadores Agregados…………………………………………………………………….17
2.7. Agregación por Grupos …………………………………………………………………...17
2.8. Having …………………………………………………………………………………….19
2.9. SubConsultas……………………………………………………………………………...19
2.10. Unión, Intersección, Excepción …………………………………………………………..20
2.11. Lenguaje de Definición de Datos …………………………………………………………21
2.12. Create Table ………………………………………………………………………………21
2.13. Tipos de Datos en SQL …………………………………………………………………...21
2.14. Create Index ………………………………………………………………………………21
2.15. Create View ………………………………………………………………………………22
2.16. Drop Table, Drop Index, Drop View …………………………………………………….22
2.17. Actualización de Datos …………………………………………………………………..23
2.18. Insert Into ………………………………………………………………………………...23
2.19. Update ……………………………………………………………………………………23
2.20. Delete …………………………………………………………………………………….23
3. Tema 3 Seguridad e integridad ……………………………..……………….24
3.1. SEGURIDAD ……………………………………………………………………………24
3.2. Vistas y Seguridad ……………………………………………………………………….24
3.3. Ventajas de las vistas …………………………………………………………………….25
3.4. Creación de Vistas ……………………………………………………………………….25
3.5. Actualización de Vistas ………………………………………………………………….25
3.6. Indentificadores de usuario ………………………………………………………………26
3.7. Consesión y Retiro de Privilegios………………………………………………………...26
3.8. INTEGRIDAD……………………………………………………………………………27
3.9. Qué es un Disparador o Trigger…………………………………………………………..27
3.10. Estructura General de un Disparador……………………………………………………..28
3.11. Disparadores e integridad referencial…………………………………………………….29
2
3.12. El futuro de los disparadores……………………………………………………………..29
4. Tema 4 Base de datos orientados a objetos………………………..…….30
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
4.7.
4.8.
Sistema administrador de base de datos orientada al objeto (OODBMS)……………….30
El estándar ODMG-93 ………………………………………………………….……….31
Definiendo las oodbms…………………………………………………………………..31
Conceptos especificos de oodbms……………………………………………………….33
Características de las odbms……………………………………………………………..34
Características de las odbms……………………………………………………………..35
Los aportes a la tecnología……………………………………………………………….36
Los mercados……………………………………………………………………………..36
4.9. EL MODELO DE OBJETOS…………………………………………………...37
4.10. Objetos y clases…………………………………………………………………………..37
4.11. Diagrama de objetos……………………………………………………………………...37
4.12. Atributos………………………………………………………………………………….38
4.13. Operaciones y Métodos…………………………………………………………………..38
4.14. Enlaces y Asociaciones…………………………………………………………………..39
4.15. Multiplicidad……………………………………………………………………………..39
4.16. Modelando una asociación como una clase………………………………………………40
4.17. Roles……………………………………………………………………………………...40
4.18. Ordenación…………………………………………………………………………….....41
4.19. Cualificadotes…………………………………………………………………………….41
4.20. Agregación……………………………………………………………………………….42
4.21. Propagación de las Operaciones………………………………………………………….43
4.22. Generalización y Herencia………………………………………………………………43
4.23. Clases abstractas………………………………………………………………………….45
4.24. Herencia Múltiple………………………………………………………………………...46
4.25. Claves Candidatas………………………………………………………………………..48
4.26. Restricciones……………………………………………………………………………..49
4.27. Modelo De Datos vs. Modelo De Objetos…………………………………………...…..50
4.28. Consejos prácticos……………………………………………………………………….50
Bibliografía ………………………………………………………………………………….51
Glosario …………………………………………………………………………………….....51
3
DOSSIER
BASE DE DATOS II
Presentación
La gestión de bases de de datos ha evolucionado desde una aplicación informática especializada hasta una
parte esencial de un entorno informático moderno. Como tal, el conocimiento acerca de sistemas de bases de
datos se ha convertido en una parte esencial en la formación en Informática.
El propósito de este Dossier es presentar los conceptos fundamentales de la administración, diseño, consulta,
seguridad e integridad de Bases de Datos.
El dossier esta orientado a un segundo curso en Bases de Datos para el nivel superior de la Carrera de
Ingeniería de Sistemas.
En este Dossier se asume que se dispone de conocimientos básicos de Base de Datos, estructura de Datos,
organización de computadoras y manejadores de Base de datos. Los conceptos se presentan usando
descripciones intuitivas, muchas de las cuales están basadas en el ejemplo propuesto de una empresa de
distribución de Suministros a proyectos.
El Dossier esta organizado en cuatro temas:
Tema1 Lenguajes de Consulta Formales
El Tema 1 presenta los lenguajes formales de consulta, utilizados para obtener información de una Base de
Datos. Se centra específicamente en el lenguaje Álgebra Relacional del modelo de Datos Relacional.
También se hace referencia al lenguaje Calculo Relacional de Tuplas y Dominios.
Tema 2 Lenguaje de Consulta Comercial - SQL
El Tema 2 se centra en el lenguaje relacional orientado al usuario de mayor influencia SQL (Structured Query
Language) Lenguaje Estructurado de Consulta. En este capitulo se describe la manipulación de datos:
consultas, actualizaciones, inserciones y borrados.
Tema 3 Seguridad e Integridad
El Tema 3 presenta la integridad referencial y la seguridad de las Bases de Datos. Este capitulo describe uso
de vistas, asignación y retiro de privilegios en SQL para la seguridad. También introduce los conceptos de
manejo Procedimientos Almacenados y Disparadores como mecanismos de Integridad.
Tema 4 Base de Datos Orientado a Objetos
El Tema 4 trata las bases de datos de Objetos. En el se introduce los conceptos de programación Orientada a
Objetos y se muestra como estos conceptos constituyen la base para un modelo de datos.
4
Tema 1
LENGUAJES DE CONSULTA FORMALES
El Modelo Relacional
El modelo relacional consta de tres partes:
 Estructura de datos relacional.
 Reglas de Integridad referencial y de entidad.
 Parte manipulativa de los datos, que consta de:
 Álgebra Relacional.
 Cálculo Relacional
 SQL
Ejemplo: Para un sistema de proveedores (S), Partes (P) y la relación de Envíos (SP) se tienen las siguientes
tablas:
S#
S1
S2
S3
S4
S5
P#
P1
P2
P3
P4
P5
SNAME STATUS
Smith
20
Jones
10
Blake
30
Clark
20
Adams
30
Tabla 1: Tabla S
PNAME
Nut
Bolt
Screw
Screw
Cam
CITY
London
Par�
Par�
London
Athens
COLOR WEIGHT
Red
12
Green
17
Blue
17
Red
14
Blue
12
Tabla 2: Tabla P
S# P# QTY
S1 P1 300
S1 P2 200
S1 P3 400
S1 P4 200
S1 P5 100
S1 P6 100
S2 P1 300
S2 P2 400
S3 P2 200
S4 P2 200
S4 P4 300
S4 P5 400
Tabla 3: Tabla SP
5
CITY
London
Par�
Rome
London
Par�
Operaciones en el Modelo de Datos Relacional
Los datos pueden almacenarse utilizando un modelo de datos relacional, pero no conocemos qué podemos
hacer con todas estas tablas para recuperar algo desde esa base de datos todavía. Por ejemplo, alguien podría
preguntar por los nombre de todos los proveedores que vendan el artículo 'tornillo'. Hay dos formas diferentes
de notaciones para expresar las operaciones entre relaciones.


El Algebra Relacional es una notación algebraica, en la cual las consultas se expresan aplicando
operadores especializados a las relaciones.
El Cálculo Relacional es una notación lógica, donde las consultas se expresan formulando algunas
restricciones lógicas que las tuplas de la respuesta deben satisfacer.
ALGEBRA RELACIONAL
Grupos de Operadores del Algebra Relacional
a. Tradicionales de Conjuntos




UNION (UNION)
INTERSECCION (INTERSECT)
DIFERENCIA (MINUS)
PRODUCTO CARTESIANO (TIMES)
b. Operadores Especiales de Relaciones




SELECCION (WHERE)
PROYECCION ([ ])
JUNTURA (JOIN)
DIVISION (DIVIDED BY)
c. Nuevos Operadores Relacionales
Adicionalmente se han definido algunas extensiones al Algebra relacional entre ellas, se contemplan los
siguientes operadores:






DIFERENCIAL
INTEGRAL
MAXIMO
MINIMO
CUENTA
SUMA
6
Operadores Relacionales
Unión
La unión de dos relaciones A y B que deben ser compatibles con respecto a la unión es el conjunto de tuplas
que pertenecen a la relación A, a la relación B o a ambas relaciones, y se designa por:
A UNION B
Compatibilidad a la Unión
Dos relaciones son compatibles a la unión si tienen el mismo número de atributos(es decir son del mismo
grado), y deben existir atributos equivalentes dentro de las dos relaciones, es decir:
El atributo 1 de la relación debe estar definido en el mismo dominio del atributo 1 de la relación, el atributo 2
de la relación debe estar definido en el mismo dominio del atributo 2 de la relación, y as�ucesivamente.
Gráficamente se verá como se ilustra en la figura 1.
Figura 1: Representación gráfica de la unión de dos tablas
v.g. si tenemos la base de datos de personas solteras y casadas segun se ilustra en las tablas 4, 5 y 6.
#EMP
E25
E30
E15
SUELDO
10
20
40
Tabla 4: Tabla de Casados
EMP#
E70
E60
SAL
30
40
E85
90
Tabla 5: Tabla de Solteros
7
EMP#
E25
E30
E15
E70
E60
E85
SAL
10
20
40
30
40
90
Tabla 6: Tabla de Todos
CASADOS UNION SOLTEROS = TODOS
SOLTEROS UNION TODOS = TODOS
El resultado de la unión conserva los nombres de los atributos de la primer relación
Intersección
La intersección de dos relaciones A y B que deben ser compatibles a la unión es el conjunto de tuplos que
pertenecen a la relación y a la relación. Gráficamente esto se verá como se ilustra en la figura 2.
Figura 2: Intersección de dos tablas
Con respecto a la base de datos presentada anteriormente tenemos:
CASADOS MINUS TODOS = VACIO
TODOS MINUS CASADOS = SOLTEROS
Diferencia
La diferencia de dos relaciones A y B que deben ser compatibles a la unió es el conjunto de tuplos que
pertenecen a la relación y no a la relación. La representación gráfica es ilustrada en la figura 3.
Representación gráfica de la diferencia de tablas
8
Figura 3 Representación gráfica de la diferencia de tablas
Con respecto a la base de datos presentada anteriormente tenemos:
CASADOS MINUS TODOS = VACIO
TODOS MINUS CASADOS = SOLTEROS
Producto Cartesiano
El producto cartesiano de dos relaciones A y B (A TIMES B) es el conjunto de tuplos que resultan de la
concatenación de un tuplo de A con un tuplo de B.
v.g. CASADOS TIMES SOLTEROS da como resultado la tabla 7
#EMP
E25
E25
E25
E30
E30
E30
E15
E15
E15
SUELDO
10
10
10
20
20
20
40
40
40
EMP#
E70
E60
E85
E70
E60
E85
E70
E60
E85
SAL
30
40
90
30
40
90
30
40
90
Tabla 7: Tabla Resultante del Producto Cartesiano
Lo anterior puede ser visto gráficamente según se ilustra en la figura 4
9
Figura 4: Representación gráfica del producto cartesiano
De este modo el producto cartesiano de una relación de grado G1 y con cardinalidad C1 por una relación de
grado G2 y con cardinalidad C2 produce una relación de grado G1+G2 y con cardinalidad C1*C2.
NOTA: Para poder realizar el producto cartesiano de una relación consigo misma es necesario que definamos
un ALIAS y conservar la UNICIDAD de los nombres de los atributos. v.g.
DEFINE ALIAS XS FOR R
R TIMES XS
NOTA:
De los cuatro operadores anteriores solo la diferencia no es conmutativo.
Selección
La selección de una relación es un subconjunto horizontal de una relación en este subconjunto aparecen los
tuplos que cumplen alguna condición especificada, gráficamente esto se ve en la figura 5.
Figura 3.5: Representación gráfica de la selección de registros de una tabla
NOTA IMPORTANTE:
Las siguiente operaciones son equivalentes:
R WHERE C1 AND C2 = (R WHERE C1) INTERSECT (R WHERE C2)
R WHERE C1 OR C2 = (R WHERE C1) UNION (R WHERE C2)
R WHERE NOT C1 = R MINUS ( R WHERE C1)
Proyección
La proyección de una relación es un subconjunto vertical con la eliminación de duplicados. Esto se ilustra en
la tabla 8.
10
*
*
*
*
*
*
*
*
*
*
*
*
*
*
Tabla 8: Tabla Indicando la Proyección
La forma de definir la proyección es encerrando entre paréntesis cuadrados y separados por comas los
campos que se desean proyectar:
(S TIMES P) [STATUS, P.CITY]
Join
Es equivalente a un producto cartesiano, seguido de una selección de los tuplos que tengan en los atributos
''equivalentes'' el mismo valor, y finalmente una proyección para eliminar los atributos duplicados.
Una forma de definirlo será
A JOIN B = (( A TIMES B)
WHERE A.Ci = B.Ci AND ....A.Cj = B.Cj)
[A.A1, ...A.An,B.B1,...B.Bm]
El JOIN que se manejará conocido como EQUIJOIN IN NATURAL en el que la condición de la selección es
por igualdad, además se han definido otros tipos de JOIN cuando la condición involucrada no es por
igualdad.
Dadas las tablas 1 y 2 se obtiene lo indicado en la tabla 9
S#
S1
S1
S1
S2
S2
S3
S3
S4
S4
S4
SNAME
Smith
Smith
Smith
Jones
Jones
Blake
Blake
Clark
Clark
Clark
STATUS
20
20
20
10
10
30
30
20
20
20
CITY
London
London
London
París
París
París
París
London
London
London
P#
P1
P4
P6
P2
P5
P2
P5
P1
P4
P6
PNAME
Nut
Screw
Cog
Bolt
Cam
Bolt
Cam
Nut
Screw
Cog
Tabla 9: Tabla Resultante S JOIN P
11
COLOR
Red
Red
Red
Green
Blue
Green
Blue
Red
Red
Red
WEIGHT
12
14
19
17
12
17
12
12
14
19
División
La división de una relación de grado m+n entre una relación de grado n, produce una relación de grado m.
Además para poderse realizar la división se debe cumplir que el (m+i ) cómo atributo de la relación este
definido en el mismo dominio que el iésimo atributo de la relación.
Los tuplos resultantes en la relación (Cociente) son aquellos atributos m tales que aparezcan combinados en
A con todos los valores de B.
Por ejemplo. Si tenemos las tablas: 10, 11, 12
S#
S1
S1
S1
S1
S1
S1
S2
S2
S3
S4
S4
S4
P#
P1
P2
P3
P4
P5
P6
P1
P2
P2
P2
P4
P5
P#
P1
Tabla 11: Tabla Y
P#
P2
P4
Tabla 12: Tabla Z
Tabla 10: Tabla X
P#
P1
P2
P3
P4
P5
P6
Tabla 13: X DIVIDED BY Y=
S#
S1
S2
Tabla 14: X Divided by Z
S#
S1
Tabla 15: X Divided by W
12
NOTAS:
Respecto a la división es importante tener presente que:
RESIDUO = DIVIDENDO MINUS (COCIENTE TIMES DIVISOR)
DIVIDENDO = ((COCIENTE TIMES DIVISOR) UNION RESIDUO)
Si consideramos que el dividendo consta de atributos X,Y y el dividendo consta de atributos Y, una forma de
calcular la división será
COCIENTE= DIVIDENDO[X]
MINUS
((DIVIDENDO[X] TIMES DIVISOR) MINUS DIVIDENDO)[X]
Operadores No básicos
De los 8 operadores vistos solo 5 de ellos son básicos puesto que los otros tres pueden ser definidos en
función de los básicos. Los operadores no básicos son:
 JOIN Cuya definición la fue dada.
 DIVISION Cuya definición la fue dada.
 INTERSECCION Que equivale a: A MINUS (A MINUS B)
Ejercicios de álgebra relacional
Ejercicio 1
Respecto a la base de datos de partes(P), proveedores(S) y pedidos(SP), obtenga las consultas en ALGEBRA
RELACIONAL:
1.- Obtener los nombres de los proveedores que suministran todas las partes.
((SP[S#,P#] DIVIDEDBY P[P#]) JOIN S)[SNAME]
2.- Obtener los números de proveedor que suministran al menos una parte que sea suministrada por un
proveedor que suministra alguna parte de color rojo (RED).
((((P WHERE COLOR='RED')[P#] JOIN SP)[S#] JOIN SP)[P#] JOIN SP)[S#]
3.- Obtener las parejas de Nombre de Proveedor y Nombre de Parte tales que el proveedor y la parte tengan la
misma ciudad.
(S JOIN P)[SNAME,PNAME]
4.- Obtener los números de proveedor que suministran al menos las partes que son suministradas por 'S2'.
SP[S#,P#] DIVIDEDBY (SP WHERE S#='S2')[P#]
5.- Obtener los pedidos en los que el proveedor sea de 'LONDON' y la parte sea de 'PARIS'.
((S TIMES P TIMES SP) WHERE S.S#=SP.S# AND
P.P#=SP.P# AND
(P.CITY='PARIS' OR S.CITY='LONDON')
)[SP.S#,SP.P#,QTY]
13
Limitaciones del álgebra relacional
La principal limitación del álgebra relacional reside en que no es posible contestar, por lo menos en forma
directa, a preguntas que involucren:

Obtener la suma de atributos.

Contar el número de tuplos que cumplan una condición

Obtener los tuplos que tengan el valor mínimo respecto a algunos) atributo(s).

Obtener los tuplos que tengan el valor máximo respecto a algunos) atributo(s).

Obtener algún(os) atributo(s) si aparecen exactamente n veces.

Obtener algún(os) atributo(s) si aparecen mas de n veces.

Obtener algún(os) atributo(s) si aparecen menos de n veces.

Obtener algún(os) atributo(s) si aparecen por lo menos n veces.
14
Tema 2
LENGUAJES DE CONSULTA COMERCIALES
Introducción
SQL se ha convetido en el lenguaje de query relacional más popular. El nombre "SQL" es una abreviatura de
Structured Query Language (Lenguaje de query estructurado). En 1974 Donald Chamberlain y otros
definieron el lenguaje SEQUEL (Structured English Query Language) en IBM Research. Este lenguaje fue
implementado inicialmente en un prototipo de IBM llamado SEQUEL-XRM en 1974-75. En 1976-77 se
definió una revisión de SEQUEL llamada SEQUEL/2 y el nombre se cambió a SQL en consecuencia.
IBM desarrolló un nuevo prototipo llamado System R en 1977. System R implementó un amplio subconjunto
de SEQUEL/2 (now SQL) y un número de cambios que se le hicieron a (now SQL) durante el proyecto.
System R se instaló en un número de puestos de usuario, tanto internos a IBM como en algunos clientes
seleccionados. Gracias al éxito y aceptación de System R en aquellos puestos de usuario, IBM inició el
desarrollo de productos comerciales que implementaban el lenguaje SQL basado en la tecnología System R.
Durante los años siguientes, IBM y bastantes otros vendedores anunciaron productos SQL tales como
SQL/DS (IBM), DB2 (IBM), ORACLE (Oracle Corp.), y SYBASE (Sybase Inc.).
SQL es también un estandar oficial hoy. En 1982, la American National Standards Institute (ANSI) encargó a
su Comité de Bases de Datos X3H2 el desarrollo de una propuesta de lenguaje relacional estandar. Esta
propuesta fue ratificada en 1986 y consistía básicamente en el dialecto de IBM de SQL. En 1987, este
estandar ANSI fue también aceptado por la Organización Internacional de Estandarización (ISO). Esta
versión estandar original de SQL recibió informalmente el nombre de "SQL/86". En 1989, el estandar
original fue extendido, y recibió el nuevo nombre, también informal, de "SQL/89". También en 1989 se
desarrolló un estandar relacionado llamado Database Language Embedded SQL (ESQL).
Los comités ISO y ANSI han estado trabajando durante muchos años en la definición de una versión muy
expandida del estandar original, llamado informalmente SQL2 o SQL/92. Esta versión se convitió en un
estandar ratificado durante 1992 - "International Standard ISO/IEC 9075:1992, Database Language SQL" -.
SQL/92 es la versión a la que normalmente la gente se refiere cuando habla de "es SQL estandar".
El Modelo de Datos Relacional
Como mencionamos antes, SQL es un lenguaje relacional. Esto quiere decir que se basa en el modelo de
datos relacional publicado inicialmente por E.F.Codd en 1970.
Una base de datos relacional es una base de datos que se percibe por los usuarios como una colección de
tablas (y nada más que tablas). Una tabla consiste en filas y columnas, cada fila representa un registro, y cada
columna representa un atributo del registro contenido en la tabla.
La Base de Datos de Proveedores y Artículos muestra un ejemplo de base de datos consistente en tres tablas.
 SUPPLIER es una tabla que recoge el número (SNO), el nombre (SNAME) y la ciudad (CITY) de un
proveedor.
 PART es una tabla que almacena el número (PNO) el nombre (PNAME) y el precio (PRICE) de un
artículo.
 SELLS almacena información sobre qué artículo (PNO) es vendido por qué proveedor (SNO). Esto
sirve en un sentido para conectar las dos tablas entre ellas.
Ejemplo. La Base de Datos de Proveedores y Artículos
PART
PNO | PNAME
| PRICE
-----+-------------+--------1 | Tornillos |
10
2 | Tuercas
|
8
3 | Cerrojos
|
15
4 | Levas
|
25
15
SUPPLIER
SNO | SNAME | CITY
-----+---------+-------1 | Smith | London
2 | Jones | Paris
3 | Adams | Vienna
4 | Blake | Rome
SELLS
SNO | PNO
-----+----1 | 1
1 | 2
2 | 4
3 | 1
3 | 3
4 | 2
4 | 3
4 | 4
Las tablas PART y SUPPLIER se pueden ver como entidades y SELLS se puede ver como una relación entre
un artículo particular y un proveedor particular.
El Lenguaje SQL
Como en el caso de los más modernos lenguajes relacionales, SQL está basado en el cálculo relacional de
tuplas. Como resultado, toda query formulada utilizando el cálculo relacional de tuplas ( o su equivalente, el
álgebra relacional) se pude formular también utilizando SQL. Hay, sin embargo, capacidades que van más
allá del cálculo o del álgebra relaciona. Aquí tenemos una lista de algunas carácteristicas proporcionadas por
SQL que no forman parte del álgebra y del cálculo relacionales:
 Comandos para inserción, borrado o modificación de datos.
 Capacidades aritméticas: En SQL es posible incluir operaciones aritméticas así como comparaciones,
por ejemplo A < B + 3. Notese que ni + ni otros operadores aritméticos aparecían en el algebra
relacional ni en cálculo relacional.
 Asignación y comandos de impresión: es posible imprimir una relación construida por una query y
asignar una relacion calculada a un nombre de relación.
 Funciones agregadas: Operaciones tales como promedio (average), suma (sum), máximo (max), etc.
se pueden aplicar a las columnas de una relación para obtener una cantidad única.
Select
El comando más usado en SQL es la instrucción SELECT, que se utiliza para recuperar datos. La sintaxis es:
SELECT [ALL|DISTINCT]
{ * | expr_1 [AS c_alias_1] [, ...
[, expr_k [AS c_alias_k]]]}
FROM table_name_1 [t_alias_1]
[, ... [, table_name_n [t_alias_n]]]
[WHERE condition]
[GROUP BY name_of_attr_i
[,... [, name_of_attr_j]] [HAVING condition]]
[{UNION [ALL] | INTERSECT | EXCEPT} SELECT ...]
[ORDER BY name_of_attr_i [ASC|DESC]
[, ... [, name_of_attr_j [ASC|DESC]]]];
Select sencillas
Aquí tenemos algunos ejemplos sencillos utilizando la instrucción SELECT:
Ejemplo 2-4. Consulta sencilla con cualificación
Para recuperar todas las tuplas de la tabla PART donde el atributo PRICE es mayor que 10, formularemos la
siguiente Consulta:
SELECT * FROM PART
WHERE PRICE > 10;
y obtenemos la siguiente tabla:
16
PNO | PNAME
| PRICE
-----+-------------+-------3 | Cerrojos
|
15
4 | Levas
|
25
Utilizando "*" en la instrucción SELECT solicitaremos todos los atributos de la tabla. Si queremos recuperar
sólo los atributos PNAME y PRICE de la tabla PART utilizaremos la instrucción:
SELECT PNAME, PRICE
FROM PART
WHERE PRICE > 10;
En este caso el resultado es:
PNAME
| PRICE
------------+-------Cerrojos
|
15
Levas
|
25
Notese que la SELECT SQL corresponde a la "projección" en álgebra relaciona, no a la "selección" .
Las cualificaciones en la clásula WHERE pueden también conectarse lógimente utilizando las palabras claves
OR, AND, y NOT:
SELECT PNAME, PRICE
FROM PART
WHERE PNAME = 'Cerrojos' AND
(PRICE = 0 OR PRICE < 15);
dará como resultado:
PNAME
| PRICE
------------+-------Cerrojos
|
15
Las operaciones aritméticas se pueden utilizar en la lista de objetivos y en la clausula WHERE. Por ejemplo,
si queremos conocer cuanto cuestan si tomamos dos piezas de un artículo, podríamos utilizar la siguiente
Consulta:
SELECT PNAME, PRICE * 2 AS DOUBLE
FROM PART
WHERE PRICE * 2 < 50;
dará como resultado:
PNAME
| DOUBLE
------------+--------Tornillos |
20
Tuercas
|
16
Cerrojos
|
30
Notese que la palabra DOBLE tras la palabra clave AS es el nuevo título de la segunda columna. Esta técnica
puede utilizarse para cada elemento de la lista objetivo para asignar un nuevo título a la columna resultante.
Este nuevo título recibe el calificativo de "un alias". El alias no puede utilizarse en todo el resto de la
Consulta.
Joins (Cruces)
El siguiente ejemplo muestra como las joins (cruces) se realizan en SQL.
17
Para cruzar tres tablas SUPPLIER, PART y SELLS a través de sus atributos comunes, formularemos la
siguiente instrucción:
SELECT S.SNAME, P.PNAME
FROM SUPPLIER S, PART P, SELLS SE
WHERE S.SNO = SE.SNO AND
P.PNO = SE.PNO;
y obtendremos la siguiente tabla como resultado:
SNAME | PNAME
-------+------Smith | Tornillos
Smith | Tuercas
Jones | Levas
Adams | Tornillos
Adams | Cerrojos
Blake | Tuercas
Blake | Cerrojos
Blake | Levas
En la clausula FROM hemos introducido un alias al nombre para cada relación porque hay atributos con
nombre común (SNO y PNO) en las relaciones. Ahora podemos distinguir entre los atributos con nombre
común simplificando la adicción de un prefijo al nombre del atributo con el nombre del alias seguido de un
punto. Primero el producto cartesiano: SUPPLIER × PART × SELLS Ahora seleccionamos únicamente
aquellas tuplas que satisfagan las condiciones dadas en la claúsula WHERE (es decir, los atributos con
nombre común deben ser iguales). Finalmente eliminamos las columnas repetidas (S.SNAME, P.PNAME).
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 específicada en la tabla completa. Si se especifican grupos en la Consulta, el cálculo se hace sólo
sobre los valores de cada grupo (vean la siguiente sección).
Ejemplo.
Si queremos conocer el coste promedio de todos los artículos 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 artículos se recogen en la tabla PART, utilizaremos la instrucción:
SELECT COUNT(PNO)
FROM PART;
y obtendremos:
COUNT
------4
Agregación por Grupos
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
18
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
relación en grupos, de tal modo que dos tuplas son del mismo grupo si y sólo si tienen el mismo valor en sus
atributos A1, &tdot;, Ak.
Ejemplo.
Si queremos conocer cuántos artículso 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
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.
Notese 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 demás atributos que no aparecen en
19
la clausula GROUP BY se seleccionarán utilizando una función agregada. Por otro lado, usted no puede
utilizar funciones agregadas en atributos que aparecen en la clausula GROUP BY.
Having
La clausula HAVING trabaja muy similarmente a la clausula WHERE, y se utiliza para considerar sólo
aquellos grupos que satisfagan la cualificación dada en la clausula HAVING. Las expresiones permitidas en
la clausula HAVING deben involucrar funcionen agregadas. Cada expresión que utilice sólo atributos planos
deberá recogerse en la clausula WHERE. Por otro lado, toda expresión que involucre funciones agregadas
debe aparecer en la clausula HAVING.
Ejemplo 2-7. Having
Si queremos sólo los proveedores que venden más de un artículo, utilizaremos 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
HAVING COUNT(SE.PNO) > 1;
y obtendremos:
SNO | SNAME | COUNT
-----+-------+------1 | Smith |
2
3 | Adams |
2
4 | Blake |
3
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 evaluación previa de la subConsulta. El uso de
subqueries amplía el poder expresivo de SQL.
Ejemplo 2-8. Subselect
Si queremos conocer los artículos que tienen mayor precio que el artículo 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 clausula
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 evaluación, 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 ningún artículo (por ejemplo, para poderlos
eliminar de la base de datos), utilizaremos:
20
SELECT *
FROM SUPPLIER S
WHERE NOT EXISTS
(SELECT * FROM SELLS SE
WHERE SE.SNO = S.SNO);
En nuestro ejemplo, obtendremos un resultado vacío, porque cada proveedor vende al menos un artículo.
Notese que utilizamos S.SNO de la SELECT externa en la clausula WHERE de la SELECT interna. Como
hemos descrito antes, la subConsulta se evalúa 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.
Unión, Intersección, Excepción
Estas operaciones calculan la unión, la intersección y la diferencia de la teoría de conjuntos de las tuplas
derivadas de dos subqueries.
Ejemplo 2-9. Union, Intersect, Except
La siguiente Consulta es un ejemplo de UNION:
SELECT S.SNO,
FROM SUPPLIER
WHERE S.SNAME
UNION
SELECT S.SNO,
FROM SUPPLIER
WHERE S.SNAME
S.SNAME, S.CITY
S
= 'Jones'
S.SNAME, S.CITY
S
= 'Adams';
Dará el resultado:
SNO | SNAME | CITY
-----+-------+-------2 | Jones | Paris
3 | Adams | Vienna
Aquí tenemos un ejemplo para INTERSECT:
SELECT S.SNO,
FROM SUPPLIER
WHERE S.SNO >
INTERSECT
SELECT S.SNO,
FROM SUPPLIER
WHERE S.SNO >
S.SNAME, S.CITY
S
1
S.SNAME, S.CITY
S
2;
que dará como resultado:
SNO | SNAME | CITY
-----+-------+-------2 | Jones | Paris
La única tupla devuelta por ambas partes de la Consulta es la única que tiene $SNO=2$.
Finalmente, un ejemplo de EXCEPT:
SELECT S.SNO,
FROM SUPPLIER
WHERE S.SNO >
EXCEPT
SELECT S.SNO,
FROM SUPPLIER
WHERE S.SNO >
S.SNAME, S.CITY
S
1
S.SNAME, S.CITY
S
3;
que dará como resultado:
21
SNO | SNAME | CITY
-----+-------+-------2 | Jones | Paris
3 | Adams | Vienna
Lenguaje de Definición de Datos
Hay incluidos en el lenguaje SQL un conjunto de comandos utilizados para definición de datos.
Create Table
El comando fundamental para definir datos es el que crea una nueva relación (una nueva tabla). La sintaxis
del comando CREATE TABLE es:
CREATE TABLE table_name
(name_of_attr_1 type_of_attr_1
[, name_of_attr_2 type_of_attr_2
[, ...]]);
Ejemplo 2-10. Creación de una tabla
Para crear las tablas definidas en La Base de Datos de Proveedores y Artículos se utilizaron las siguientes
instrucciónes de SQL:
CREATE TABLE SUPPLIER
(SNO
INTEGER,
SNAME VARCHAR(20),
CITY VARCHAR(20));
CREATE TABLE PART
(PNO
INTEGER,
PNAME VARCHAR(20),
PRICE DECIMAL(4 , 2));
CREATE TABLE SELLS
(SNO INTEGER,
PNO INTEGER);
Tipos de Datos en SQL
A continuación sigue una lista de algunos tipos de datos soportados por SQL:
 INTEGER: entero binario con signo de palabra completa (31 bits de precisión).
 SMALLINT: entero binario con signo de media palabra (15 bits de precisión).
 DECIMAL (p[,q]): número decimal con signo de p dígitos de precisión, asumiendo q a la derecha
para el punto decimal. (15 ≥ p ≥ qq ≥ 0). Si q se omite, se asume que vale 0.
 FLOAT: numérico 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 máxima n.
Create Index
Se utilizan los índices para acelerar el acceso a una relación. Si una relación 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
número de tales tuplas t más que en un tiempo proporcional al tamaño 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 );
Ejemplo 2-11. Create Index
Para crear un índice llamado I sobre el atributo SNAME de la relación SUPPLIER, utilizaremos la siguiente
instrucción:
22
CREATE INDEX I
ON SUPPLIER (SNAME);
El indice creado se mantiene automáticamente. es decir, cada vez que una nueva tupla se inserte en la relación
SUPPLIER, se adaptará el índice I. Notese que el único cambio que un usuario puede percibir cuando se crea
un índice es un incremento en la velocidad.
Create View
Se puede ver una vista como una tabla virtual, es decir, una tabla que no existe físicamente en la base de
datos, pero aparece al usuario como si existiese. Por contraste, cuando hablamos de una tabla base, hay
realmente una contraparte físicamente almacenada para cada fila en la tabla en algún sitio del
almacenamiento físico.
Las vistas no tiene datos almacenados propios, distinguibles y físicamente almacenados. En su lugar, el
sistema almacena la definición de la vista (es decir, las reglas para acceder a las tablas base físicamente
almacenadas para materializar la vista) en algún lugar de los catálogos del sistema. Para una discusión de las
diferentes técnicas 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 instrucción select válida, 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 definicón 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';
Ahora podemos utilizar esta relación 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 definición de la vista
contra aquellas tablas base. Tras eso, las qualificaciones adicionales (dadas en la Consulta contra la vista) se
podrán aplicar para obtener la tabla resultante.
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;
23
Para eliminar la tabla SUPPLIER, utilizaremos la instrucción:
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;
Actualización de Datos
Insert Into
Una vez que se crea una tabla puede ser llenada con tuplas utilizando el comando INSERT INTO. La sintaxis
es:
INSERT INTO table_name (name_of_attr_1 [, name_of_attr_2 [,...]])
VALUES (val_attr_1 [, val_attr_2 [, ...]]);
Para insertar la primera tupla en la relación utilizamos la siguiente instrucción:
INSERT INTO SUPPLIER (SNO, SNAME, CITY)
VALUES (1, 'Smith', 'London');
Para insertar la primera tupla en la relación SELLS, utilizamos:
INSERT INTO SELLS (SNO, PNO)
VALUES (1, 1);
Update
Para cambiar uno o más valores de atributos de tuplas en una relación, se utiliza el comando UPDATE. La
sintaxis es:
UPDATE table_name
SET name_of_attr_1 = value_1
[, ... [, name_of_attr_k = value_k]]
WHERE condition;
Para cambiar el valor del atributo PRICE en el artículo 'Tornillos' de la relación PART, utilizamos:
UPDATE PART
SET PRICE = 15
WHERE PNAME = 'Tornillos';
El nuevo valor del atributo PRICE de la tupla cuyo nombre es 'Tornillos' es ahora 15.
Delete
Para borrar una tupla de una tabla particular, utilizamos el comando DELETE FROM. La sintaxis es:
DELETE FROM table_name
WHERE condition;
Para borrar el proveedor llamado 'Smith' de la tabla SUPPLIER, utilizamos la siguiente instrucción:
DELETE FROM SUPPLIER
WHERE SNAME = 'Smith';
24
Tema 3
SEGURIDAD E INTEGRIDAD
Seguridad e Integridad son dos conceptos que se utilizan frecuentemente en el contexto de las Bases de
Datos. Seguridad se refiere a la protección de los datos contra una revelación, alteración o destrucción no
autorizada; integridad se refiere a la exactitud o validez de los datos.
Seguridad implica asegurar que los usuarios están autorizados para llevar a cabo lo que tratan de hacer.
Integridad implica asegurar que lo que tratan de hacer es correcto.
SEGURIDAD
La unidad de información para propósitos de seguridad puede ser desde una Base de Datos o conjunto de
tablas completos hasta un valor específico en una posición específica de fila y columna dentro de una tabla
específica.
Un usuario dado tendrá por lo regular diferentes derechos de acceso o autorizaciones sobre diferentes
objetos de información.
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
algún usuario.
 Los objetos de la base de datos, son los elementos a los cuales se aplica la protección 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 características más 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 autorización mediante el cual los usuarios con derechos específicos pueden conceder
de manera selectiva y dinámica esos derechos a otros usuarios, y desùés revocar esos derechos.
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 sólo vean ciertas filas o ciertas
columnas de una tabla.
 Las vistas simplifican el acceso a la BD mediante la presentación de la estructura de los datos
almacenados de modo que sea más natural para cada usuario.
25
Ventajas de las vistas
 Seguridad
 Simplicidad de consulta
 Simplicidad estructurada
 Aislamiento frente al cambio
 Integridad de datos
Desventajas de las vistas
 Rendimiento
 Restricciones de actualización
Creación 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
Actualización de Vistas
Bajo el estándar SQL una vista puede ser actualizada si la consulta que la define satisface todas estas
restricciones:
 No debe especificar DISTINCT
 La cláusual FROM debe especificar solamente una tabla actualizable
 Cada elemento de selección debe ser referencia a una columna simple
 La clásula WHERE no debe incluir subconsultas.
 La consulta no debe incluir una cláusula 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 artículos pero no a sus precios
unitarios
CREATE VIEW ArticulosD
AS select codA, NomA, Color
From Proveedores
26
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
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 núcleo de la seguridad
SQL. Toda sentencia SQL ejecutada por DBMS se lleva a cuenta de un id-usuario específico. El id_usuario
determina si la sentencia va ser permitida o prohibida por el DBMS. En una BD de producción los
id_usuarios son asignados por el administrador.
Consesión y Retiro de Privilegios
La sentencia GRANT se utiliza para conceder privilegios de seguridad sobre objetos de la BD a usuarios
específicos
La sentencia REVOKE se utiliza para quitar los privilegios de seguridad sobre objetos de la BD a usuarios
específicos
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;
También 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:
REVOKE SELECT ON TABLES FROM PEDRO;
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 realización de auditorías periódicas del contenido de la base de datos.
27
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.
INTEGRIDAD
El término de Integridad de datos se refiere a la corrección 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 añadirse datos no válidos a la BD, tales como una inscripcion 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 eléctrico (transacciones )
Los cambios pueden ser aplicados parcialmente, como por ejemplo si inscribe a un alumno a una materia
sin verficar y actualizar el cupo del curso.
Existen varios casos diferentes de restricciones de integrida de datos que suelen encontrarse en las
BDRelacionales como:






Datos requeridos (datos válidos para algunas columnas, no NULL Ej: Nombre, no Materno)
Chequeo de valides (dominio Ej. Rangos de números)
Integridad de entidad (clave primaria, único y distinto de NULL)
Integridad Referencial (DBMS, Disparadores, SP)
Reglas comerciales (De la Institución 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)
Qué es un Disparador o Trigger?
Para cualquier evento que provoca un cambio en el contenido de una tabla se puede especificar una acción
asociada que el DBMS debería efectuar automáticamente. Los eventos que pueden disparar una acción son
el INSERT, UPDATE Y DELETE.
La acción 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 añade un nuevo registro a la tabla Inscripción
Internamente se suceden dos eventos:
1. La insercion de un registro en Inscripcion
2. Actualización de número de inscritos (asignación)
28
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)
Estructura General de un Disparador:
CREATE TRIGGER Nombre_del_Disparador
ON NombreTabla
FOR [INSERT][UPDATE][DELETED]
AS
Sentencias SQL
Ejemplo: Diseñar 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
29
PRINT 'NO HAY CUPO EN ESTE CURSO'
ROLLBACK
end
Disparadores e integridad referencial
Los disparadores proporcionan un modo alternativo de implementar las restricciones de integridad referencial
proporcionadas por claves foráneas y claves primarias. De hecho, el mecanismo disparador es más flexible
que la integridad referencial estricta proporcionado por el estándar 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'
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 actualización en la BD.
Esto puede reducir sustancialmente la complejidad de los programas de aplicación (rutinas de front end, SP,
etc) que accedan a la BD.
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 más 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.
30
Tema 4
BASE DE DATOS ORIENTADOS A OBJETOS
SISTEMA ADMINISTRADOR DE BASE DE DATOS ORIENTADA AL OBJETO
(OODBMS)
A los nuevos servicios de las empresas, le corresponden nuevas funciones de aplicación. Esas modificaciones
de aplicación deben poder hacerse rápido, sin tener que reescribir todo.
Corría la segunda mitad de la década de los 80’, cuando comienzan a generalizarse en múltiples aplicaciones
los sistemas de gestión de bases de datos orientadas al objeto (OODBMS), los cuales toman las ventajas del
enfoque orientado al objeto, ya probados y los sistemas de gestión de bases de datos, siendo su principal
virtud el ofrecer un muy buen desempeño en la gestión de datos complejos y multimediales.
Desde el punto de vista del desarrollador las ventajas están dadas en ganancias de productividad, dado su
modelamiento más simple que facilita el desarrollo de aplicaciones. El modelamiento de aplicaciones es
mucho más sencillo gracias al concepto de objetos complejos y el modelo obtenido es fácilmente
comprensible para el usuario. Este modelo puede ser validado directamente por el cliente de la aplicación. El
enfoque Orientado al Objeto favorece la reutilización, porque gracias a la encapsulación y la herencia, es fácil
especializar un componente existente para responder a las necesidades particulares de la aplicación.
Desde el punto de vista del usuario final de los OODBMS, el mayor aporte es la calidad en términos de
ergonomía, fiabilidad, evolución y desempeño. La mayor parte de los productos disponibles en el mercado,
son productos cerrados, difícilmente adaptables a las especificaciones de la empresa: la ergonomía de la
aplicación es fija, las reglas de cálculo son difícilmente modificables, etc. la tecnología objeto, gracias en
particular a la encapsulación y la herencia, da productos desarrollos con un OODBMS más abierto y
fácilmente adaptables. El usuario puede obtener un costo menor de las modificaciones de sus procedimientos,
que van a integrar más fácilmente su medio ambiente (entorno).
Un poco de historia
La primera aparición del concepto data de 1984 con la proposición 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 Austín, Texas y en 1986
el proyecto Altair, en Rocquencowt, Francia. En 1988, la primera generación apareció, seguida por una
segunda generación en 1990.
Después de esta intensa actividad, pareciera necesario definir de una manera precisa el concepto de
OODBMS (Sistemas de Gestión de Bases de Datos Orientadas al Objeto). En efecto, contrariamente al caso
de los sistemas relacionales que primero fueron definidos formalmente en el artículo original de Codd,
después se generaron prototipos y finalmente transformados en producto, no hubo un principio de
especificación precisa de lo que debía ser un OODBMS.
En 1989, el paper "The Object-Oriented Database System Manifesto" aunque con un enfoque demasiado
limitado en temas de administración, Stonebraker et al. (1990), propone una definición 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 rápidamente admitido por la comunidad científica y comercial como un consenso
mínimo.
A principios de la década de los 90’, la comercialización efectiva de sistemas progresó rápidamente y fueron
desarrolladas varias aplicaciones.
En 1992, los principales distribuidores se juntan para definir un estándar que asegure la portabilidad de las
aplicaciones de un sistema a otro, y en Octubre de 1993 es publicado el estándar del ODMG (Grupo de
Administración de Bases de Datos Orientadas al Objeto), Catell et al. (1993). Se cuenta con una tecnología
31
madura y adaptada al mercado, una oferta rica y diversificada, una demanda para este tipo de producto y un
estándar realista (ODMG-93 es un estándar para bases de datos al objeto puras, en contraste con el estándar
SQL3 nacido para bases de datos relaciones extendidas basadas en objetos, siendo ésta compatible con el
modelo relacional clásico).
EL ESTÁNDAR ODMG-93: UN ESTÁNDAR 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:
1) ODL (Lenguaje de Definición de Objetos)
El lenguaje de definición del objeto permite definir el modelo de datos. Es compatible con IDL, el lenguaje
del OMG (Grupo de Administración de Objetos). Permite la definición de objetos complejos, de relación
entre esos objetos y de métodos asociados a dichos objetos.
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.
3) Conexión vía C++ y Smalltalk.
Esta interfaz ("bindings", enlazamientos), especifica como se debe hacer la programación en C++ o Smalltalk
de una aplicación sobre una base de datos que ha sido declarada en ODL. La conexión es basada sobre la
noción de "puntero inteligente" que permite manejar los objetos persistentes como objetos ordinarios vía
punteros persistentes.
DEFINIENDO LAS OODBMS
Un OODBMS ofrece todas la funcionalidad de un sistema de gestión de bases de datos, al igual que todas las
de un sistema objeto.
Conceptos DBMS
La tecnología de gestión de bases de datos (DBMS), nació a fines de los años 60. Las tecnologías de
implementación de esos sistemas han evolucionado, su arquitectura ha emigrado hacia una arquitectura
Cliente/Servidor, pero los servicios ofrecidos (En particular a su nivel físico) son los mismos. La figura 1
muestra un DBMS tradicional considerando sus aspectos más característicos.
Un DBMS ofrece facilidades de almacenamiento, de acceso, manipulación y de compartimento de grandes
volúmenes de datos. Esos datos pueden ser muy abultados, ellos no están ni en memoria principal ni en
memoria virtual. Es el DBMS quien asegura la gestión de diferentes niveles de jerarquía de memoria, el
programador no hace la diferencia entre un dato en memoria y un dato en disco. La gestión del disco
asegurada por el DBMS debe ser transparente y ofrece buenos desempeños. Ella debe ofrecer mecanismos
tales como gestión oculta de indexación, reagrupamiento de objetos sobre los discos (debe proveer una forma
adecuada de reagrupar los objetos de un nivel físico, a un nivel superior ), etc.
32
Figura 2: Composición de un Objeto.
La parte estática del objeto puede reagrupar informaciones alfanuméricas, gráficas, textuales, sonoras, etc.
Ella puede ser atómica (los objetos atómicos son del tipo de base del sistema: enteros, reales, caracteres,
strings, booleanos) o compleja (constituida a partir de otros objetos, atómicos o complejos).
La parte dinámica del objeto puede estar constituida de funciones de archivos, cálculos, de búsqueda de
información, etc. Contrariamente a lo que existe en la programación clásica, las operaciones son subordinadas
a los objetos; el objeto no es solamente caracterizado por lo que es, sino también por lo que hace, ocultando la
estructura interna de un objeto y la implementación de las operaciones.
Cada objeto tiene una identidad propia (ver figura 3), 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 noción de identidad de objeto guarda relación con la composición del objeto, diferenciándose de otros
objetos.
Conceptos como la herencia permiten definir una clase (la clase define una estructura y un comportamiento
común, a varios objetos) de objetos a partir de una clase ya existente (herencia simple) o de varias otras clases
(herencia múltiple). La clase creada recupera no solamente su estructura sino además sus métodos de su(s)
clase(s) padre(s). La herencia trae una descripción compacta bien estructurada del esquema de aplicación. Es
una técnica de clasificación de objetos que evita la duplicación de código facilitando la reutilización de
propiedades de estructuras y comportamientos ya definidas.
Los objetos se comunican entre ellos por envío 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.
33
Los métodos asociados a clases diferentes, pueden tener el mismo nombre: la elección del método que sea
efectivamente llamado es aplazada hasta el momento de la ejecución (enlazamiento dinámico), dependiendo
de la persistencia de la clase del objeto del cual el método es llamado en tiempo de ejecución. Ese mecanismo
de enlace dinámico aumenta la independencia entre los métodos y los objetos y permite sumar nuevas clases
sin modificar ni recompilar los programas existentes, Por ejemplo, la aplicación de gestión de pago maneja
diferentes tipos de contratos, cada uno con su método de cálculo de sueldo, basta con crear una nueva
subclase de la clase "contrato" con un método de cálculo de sueldo correspondiente a ese algoritmo. Esos
nuevos contratos son entonces inmediatamente tomados en cuenta por los programas existentes, sin
modificación particular del código.
La herencia y el enlazamiento dinámico permiten alivianar los programas y el trabajo del programador (por
efecto de la reutilización) cuando se activan los módulos de la aplicación.
Se hace notar que el modelamiento de objetos se puede realizar bajo una forma gráfica, pudiendo tener ciclos.
CONCEPTOS ESPECIFICOS DE OODBMS
La noción de objetos complejos optimiza la representación de las estructuras complejas y acortando la
distancia que separa el modelamiento de un escenario del mundo real y su implementación. Los objetos
complejos permiten así, un modelamiento más intuitivo de datos de una aplicación, su presentación en la base
de datos está mas cerca de la realidad. La estructura compleja de los objetos es manejada por punteros
lógicos. Esos punteros reemplazan la utilización de uniones relacionales, e inducen así una ganancia de
desempeño, particularmente cuando la cantidad de datos es importante. La siguiente figura muestra un
esquema típico de una OODBMS:
Figura 4: Una OODBMS tradicional, Manola (1994).
El concepto de identidad de objeto, tiene repercusiones particularmente interesantes en el contexto de un
DBMS. La distribución de objetos permite limitar la tabla de la base de datos. Permite una mejor gestión de
actualización, y es más rápida, ya que tiene menos objetos que modificar. Ofrece igualmente una gestión
automática de integridad referencial (desaparición 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 programación
34
utilizados. En efecto, los tipos de datos de esas categorías de herramientas son incompatibles, el programador
debe asegurarse por si mismo de la conversión 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 aplicación en su ejecución.
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 manipulación de datos (DML), existiendo
impedimentos de acoplar estilos declarativos y basados en procedimientos entre los tipos de sistemas del
lenguaje de aplicación y de bases de datos, dando lugar a una perdida de información en la interfaz, y
obstaculizando la comprobación automática de tipos.
Para solucionar este problema los OODBMS ofrecen el concepto de completitud; que es la percepción de
escribir completamente una aplicación utilizando el DBMS como un único lenguaje (tal como los lenguajes
estándar según 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 manipulados de la misma
manera en la base de datos que por el lenguaje de programación. En efecto, es el mismo modelo de datos, que
es soportado por el lenguaje objeto de desarrollo de la aplicación y por el OODBMS. Los OODBMS ofrecen
todo un lenguaje de programación completo integrando los accesos a las bases de datos.
CARACTERÍSTICAS DE LAS ODBMS
Un completo modelo de bases de datos, con rasgos tales como; la manipulación fija y el acceso de asociación.
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 además el usuario puede declarar
procedimientos y variables asociadas con los tipos de objetos) real con rasgos de manipulación de esquemas.
La capacidad de almacenar y manipular tanto los datos (objetos) como los metadatos (clases y métodos) en el
propio sistemas.
Un DML (Data Manipulation Languaje, por lo general contiene un lenguaje de consultas y un componente de
lenguaje de programación ), a través de un lenguaje de consulta completo, declarativo.
Independencia de datos lógica y física (esto es, un DDL físico y uno lógico y la capacidad para modificar el
esquema físico sin cambiar la aplicación).
La capacidad de manipular cantidades de datos enormes.
La capacidad de desarrollar aplicaciones completas en un medio único.
LOS DESEMPEÑOS
El problema de los desempeños es esencial para los DBMS. El mercado de sistemas orientados al objeto se
desarrolla porque esos sistemas ofrecen desempeños 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 aplicación en cuanto a su tipo de concepción (refiriéndose a su forma
de generación, formación). Manipula los objetos complejos entre el servidor y una estación de
trabajo.
 Bechmarking de Hypermodel, fue hecho por un grupo de navegadores de conceptos en sistemas. Se
basa sobre la aplicación 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 número de operaciones, transacciones, requerimientos y el control de versiones. El
007 denota tres diferentes tamaños:
 Pequeño: 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 desempeño con respecto a los sistemas relacionales sobre las aplicaciones
manipulando objetos complejos. Esto es por una sencilla razón; que los sistemas relacionales fueron hechos y
diseñados para efectuar algunas operaciones simples (selección, proyección, etc.), y los OODBMS tienen por
35
finalidad manipular objetos estructurados y complejos. En cuanto a una comparación arquitectónica entre el
modelo relacional y el modelo objeto aplicado a DBMS, la figura 5 muestra su correspondiente composición
habitual.
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 estándar, es decir, de aquellos que uno
manipula textos estructurados o no estructurados, imágenes, gráficos, 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
 Gestión de datos técnicos
 Cartografía
 Multimedia.
 Sistemas distribuidos y cliente/servidor.
 Bases de datos multimedia.
 Correo por voz.
 GIS
En todos estos dominios, la tecnología de OODBMS aporta los desempeños mejores y un desarrollo más
eficaz de aplicaciones.
Los OODBMS disminuyen los costos lógicos de desarrollo.
Esta baja de costos es obtenida en opinión de connotadas figuras ligadas a DBMS (Por citar algunos:
Atkinson et al., Bancilhon, Graham), por un acortamiento del ciclo de análisis, concepción, codificación,
depuración, testeo, mantención y evolución. Mejoramiento obtenido por:
 La reutilización del componente lógico.
 La disminución de código.
 La capacidad de modelamiento directo de información compleja.
 La mejor integración a los lenguajes de programación.
 Desarrollo rápido de prototipos de aplicaciones.
 Utilización de medio ambiente gráfico de desarrollo.
 Utilización de herramientas de generación de interfaz gráfica de realización.
Los OODBMS permiten producir aplicaciones gráficas de mejor calidad.
Las aplicaciones son mejoradas en dos puntos esenciales:
 Los desempeños en el caso de la manipulación de datos complejos.
 La calidad "industrial" de aplicaciones para la facilidad de mantención, su capacidad de crecimiento y
posibilidad de ser personalizadas en dominios específicos.
Los OODBMS permiten recuperar y mejorar las aplicaciones existentes.
Para los sistemas que disponen de una interfaz C++ estándar, el mecanismo consiste en tomar una aplicación
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 migración es
mínimo y la aplicación es bastante mejorada. En efecto, resultando en:
 Una simplificación de código (el acceso a los objetos de la base de datos es inmediata y sin
traducción).
 La capacidad de fiabilidad y compatibilidad de los datos.
Los Mercados
1. Aplicación en Sistemas de información geográficos.
36
Para los sistemas de información geográficos o para toda aplicación en la cual hay una dimensión espacial o
geográfica (la cartografía de una región, la topología de una zona o el plano de un edificio), los
desarrolladores de estas aplicaciones necesitan la tecnología de objetos; ella ofrece un mayor desarrollo y
mejores desempeños.
2. Gestión de datos técnicos.
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 gestión de datos científicos
experimentales, la gestión de datos asistidos por computador (CAD) y la documentación técnica.
3. Aplicaciones Multimedia.
Para toda aplicación que manipula gráficos, imágenes, animación y voz, los OODBMS son los primeros en la
elección de los desarrolladores.
EL MODELO DE OBJETOS.
Introducción
Modelo de Objetos: captura la estructura estática del sistema, mostrando:
- objetos
- relaciones entre objetos
- atributos
- operaciones
Es el más importante, puesto que el sistema se construye alrededor de los objetos.
Objetos y clases.
Objeto:
− Concepto, abstracción o cosa con fronteras definidas y significado para nuestro problema.
− Permite una mejor comprensión del mundo y proporciona la base para una implementación sobre el
ordenador.
− No existe una representación exacta.
− Todos los objetos tienen una identidad y son distinguibles.
Clase:
− Describe grupos de objetos con propiedades (atributos) similares, comportamiento (operaciones)
comunes, relaciones con otros objetos y semántica común.
− Cada objeto sabe cuál es su clase, ya que es una instancia de la misma.
− Elemento esencial para la abstracción y generalización.
Diagrama de objetos.
Notación gráfica para modelar los objetos, clases y sus relaciones.
Dos clase de diagramas:
o de clases
o de objetos (instancias)
Diagrama de clases:
o Esquema, patrón o plantilla para describir muchos casos posibles de datos. Describe clases de
objetos.
Diagrama de objetos:
o Describe cómo se relacionan un grupo particular de objetos entre sí.
37
Notación de clases y objetos.
Atributos.
Los atributos presentan las siguientes características:
− Valor de un dato dentro de un objeto.
− Cada atributo tiene un valor para cada objeto.
− El nombre de un atributo es único dentro de una clase.
− Debería ser un dato ‘puro’, no un objeto (no tiene identidad): si un objeto necesita otro objeto habrá
que modelarlo como asociación.
− Además del nombre podemos especificar el Tipo y el Valor por defecto.
− Los identificadores de objetos explícitos no se necesitan en el Modelo de Objetos.
Notación de atributos.
Operaciones y Métodos.
Función o transformación que se aplica ‘a’ o ‘por’ los objetos en una clase.
Tienen un objeto destino como argumento implícito (el objeto actual).
Polimorfismo: la misma operación puede aplicarse a clases diferentes dentro de una jerarquía de herencia.
Método:
Implementación de una operación para una clase. Las operaciones con métodos en varias clases
deben compartir la misma signatura (tipos de sus argumentos y valor que devuelven).
Notación de Operaciones y Métodos.
Animal Manifero
Pais
Años
Nombre
Peso
Nombre
Cantidad_Habitantes
Actualizar( )
Poblacion( )
Imprimir( )
Actualizar( )
Diagnostico( )
Imprimir( )
Notación para las clases.
38
● Enlaces y Asociaciones.
• Enlace: conexión física o conceptual entre objetos.
• Asociación: grupo de enlaces con la misma estructura y semántica común.
• Sentido de una asociación:
Inherentemente son bidireccionales.
Directa (forward) e inversa (inverse).
• Implementación común en los lenguajes de programación mediante punteros o referencias, aunque en la
fase de modelización no es recomendable esta práctica.
• Las asociaciones pueden ser binarias, ternarias o de órdenes superiores.
• Los nombres de las asociaciones son opcionales en la notación (se escriben en cursiva).
Ejemplo de Enlace y Asociación:
● Multiplicidad.
• Especifica cuántos objetos de una clase pueden relacionarse con un único objeto de una clase asociada.
• Se especifica mediante:
- un subconjunto (posiblemente infinito) de enteros no negativos: 0..n,
- bien uno o varios intervalos no conexos: 1..4, 7.
• No debemos preocuparnos de ajustar la multiplicidad demasiado pronto en nuestro Modelo de Objetos.
• En los Diagramas de Objetos la multiplicidad se especifica mediante símbolos especiales en los extremos de
las líneas de las asociaciones.
● Atributos de los enlaces.
39
• Propiedades de los enlaces de una asociación.
-
Opcionales en los enlaces uno-a-uno y uno-a-muchos.
Obligatorios en los enlaces muchos-a-muchos.
● Modelando una asociación como una clase.
• Además de los atributos de un enlace, permite añadir un nombre y operaciones.
• Son útiles cuando:
- Los enlaces pueden participar en asociaciones con otros objetos.
- Los enlaces están sujetos a operaciones.
● Roles.
• Rol: uno de los extremos de una asociación.
• Nombre de Rol: nombre que identifica de forma única el final de una asociación. Atributo derivado cuyo
valor es un conjunto de objetos relacionados. Deben ser únicos en las asociaciones de una clase.
• Suelen aparecer como ‘nombres’ en los enunciados de los problemas.
• En relaciones n-arias: un rol en cada extremo.
• Proporcionan una forma de ver las asociaciones como recorrido desde un objeto hacia otro conjunto de
objetos.
• Su uso es opcional. A veces resulta más claro su uso que los nombres de las asociaciones.
• Necesarios en las relaciones entre objetos de la misma clase, o cuando existe más de una asociación entre el
mismo par de clases.
40
● Ordenación.
• Se utiliza en la parte ‘muchos’ de una asociación en la que los objetos deben estar ordenados.
● Cualificadores.
• Asociación cualificada: relaciona dos clases mediante un cualificador. Puede considerarse como un tipo de
asociación ternaria.
• Cualificador: atributo especial que puede reducir la multiplicidad de una asociación.
• Pueden utilizarse en asociaciones uno a muchos o muchos a muchos.
• Distinguen conjuntos de objetos en el extremo "muchos" de la asociación.
• Mejora la semántica y aumenta la visibilidad de caminos de navegación.
• Se representa mediante un cuadro en el extremo más próximo a la clase a la que cualifica.
Ejemplo:
directorio + nombre de archivo.
• Notación de cualificación:
1) Un directorio contiene más de un archivo.
El nombre del directorio más el nombre del archivo en el directorio, identifican de forma única al
archivo,
2) otro ejemplo realizando ahora agrupamientos.
41
● Agregación.
•
•
•
•
Relación ‘parte-todo’ o ‘parte-de’: el ensamblaje se relaciona con sus componentes.
Verifica las propiedades transitiva y antisimétrica. También es común la agregación recursiva.
En caso de duda, utilizar una asociación ordinaria.
Preguntas útiles para identificar agregaciones:
- ¿Se puede utilizar la frase ‘parte de’?
- ¿Se propagan algunas operaciones del ‘todo’ a las ‘partes’ de forma automática?
- ¿Se propagan algunos valores de los atributos del ‘todo’ a alguna o todas de las ‘partes’?
- ¿Existe una asimetría intrínseca en la asociación, por la cual un objeto está subordinado a otro (la
eliminación del ‘todo’ implica la de las ’partes’)?
• Notación de agregación:
> Agregados fijos: estructura fija, con el número y tipos de subpartes predefinidos.
> Agregados variables: tienen un número finito de niveles, pero el número de partes varía.
> Agregados Recursivos.
Agregados recursivos: contienen, directa o indirectamente, un caso de la misma clase.
42
● Propagación de las Operaciones.
• Aplicación automática de una operación a una red de objetos cuando se aplica la operación a un objeto
inicial.
• La propagación de una operación a las partes es un buen indicador de agregación.
●Generalización y Herencia.
• Generalización: relación entre una clase (superclase) y una o más versiones refinadas de ella (subclases).
• Relación "es-un".
• Las subclases ‘heredan’ las características, atributos y operaciones de su superclase.
• Una instancia de una subclase es una instancia de sus clases antecesoras o ascendientes.
• Distinción entre generalización y herencia:
- Generación: relación entre clases.
- Herencia: mecanismo para compartir características.
• Ascendientes y descendientes: generalización en múltiples niveles.
• Discriminador: atributo de tipo enumerado, que indica la propiedad del objeto que se está abstrayendo para
una relación de generalización. Solo debería discriminarse una propiedad a la vez. Ejemplo: Fichero:
Contenido: de texto, binario, de datos.
Acceso: secuencial, directo, indexado.
Carácter: ejecutable, no ejecutable.
43
• Generalización como extensión y restricción:
- una instancia de una clase es una instancia de todas sus clases ascendientes y no puede omitir o suprimir
un atributo de sus ascendientes.
- una subclase puede añadir nuevas características: extensión.
- una subclase puede redefinir una característica de sus ascendientes: restricción.
Por ejemplo: limitar los valores en un rango menor (círculo es una elipse de a = b)
• Agregación vs. Generalización.
- La agregación relaciona instancias (relación ‘y’).
- La generalización relaciona clases (relación ‘o’).
• Notación de generalización y herencia.
● Redefinición (override).
• Una subclase ‘reemplaza’ una característica de su superclase definiendo una característica con el mismo
nombre.
• Motivos para redefinir:
- Especificar un comportamiento que dependa de la subclase.
- Aplicar de forma más rigurosa las especificaciones de una característica.
- Mejorar el rendimiento.
• No se debe reemplazar la signatura de una característica. Debe preservar:
- Tipos de los atributos.
- Número y tipos de argumentos de funciones.
- Tipo del valor devuelto por una operación.
• Redefinir operaciones por:
44
- Extensión.
- Restricción.
- Optimización.
- Conveniencia.
• Reglas prácticas:
- Todas las operaciones de consulta y actualización se heredan por todas las subclases.
- Las operaciones de actualización que modifiquen atributos o asociaciones restringidas, deben mantener
la misma restricción.
- Las operaciones heredadas se pueden refinar añadiendo un nuevo comportamiento.
● Clases abstractas.
• Las clases abstractas sirven para definir un comportamiento y/o estructura común a un conjunto de
subclases.
• Una clase abstracta no es instanciable (no existen objetos de esa clase). Sin embargo, sus subclases pueden
ser clases concretas (que sí son instanciables).
• Organizan características comunes de varias clases (a).
• Pueden definir el protocolo para una operación sin proporcionar un método correspondiente (operación
abstracta). Una clase concreta no puede contener operaciones abstractas.
• La naturaleza abstracta de una clase es siempre provisional.
45
● Herencia Múltiple.
• Permite a una clase tener más de una superclase, y heredar las características de todos sus padres.
• Las principales ventajas son:
- Una mayor potencia a la hora de definir nuevas clases.
- Oportunidades adicionales de reutilización.
- Acercamiento a la forma natural de pensar.
Ejemplo: (El triángulo relleno, significa que las clases no son disjuntas).
46
• La desventaja se encuentra en los problemas de implementación (por ejemplo, la herencia repetida de
C++).
• Clase vínculo (join): clase con más de un padre.
• Herencia múltiple accidental.
Ejemplo:
Un instructor es inherentemente Profesor y Alumno, ¿cómo modelar un Profesor de una Universidad
que recibe clases en otra?
• Resolución de Herencia múltiple:
● Características De Clase.
 Las clases pueden ser consideradas también como Metaobjetos.
 Atributos de clase:
− Describen un valor común para todos los objetos de la clase.
− Permiten almacenar información que puede usarse como valor por defecto en la instanciación.
− Permiten almacenar información sobre las instancias de la clase.
 Operaciones de clase:
− Operación que tiene lugar sobre atributos de la clase.
47
− Se invoca sobre la clase y no sobre una instancia concreta.
Ejemplo: new en C++, en la declaración del objeto se llama al constructor de la clase
Ejemplo de características de clase.
● Claves Candidatas.
 Una clave candidata es un conjunto mínimo de atributos que identifican un objeto o enlace.
 El identificador de objeto (OID) es siempre una clave candidata.
 Es un concepto lógico muy utilizado en el mundo de los SGBDR.
 Se denotan en los diagramas de clases mediante corchetes.
48
● Restricciones.
 Es una relación funcional entre entidades (clase, objeto, atributo, enlace o asociación) dentro del
Modelo de Objetos que limita los valores que la entidad puede tomar.
 Restricciones sobre enlaces:
 Restricciones generales.
− Se expresan mediante lenguaje natural o ecuaciones.
− Se denota mediante una línea de puntos entre las clases implicadas y con la descripción entre
llaves.
 Objetos, enlaces y atributos derivados.
− Un objeto derivado se define como una función de uno o más objetos.
− Es redundante, pero se introduce en el Modelo para facilitar la comprensión.
− También existen enlaces y atributos derivados.
49
● Modelo De Datos vs. Modelo De Objetos.
 Una BD se desarrolla mediante un Modelo de Datos.
1) Se construye el Modelo de Datos sobre el dominio de la aplicación.
2) Se transforma del Modelo de Datos en un Diseño de la BD mediante la aplicación de una serie de
transformaciones estándar (normalización).
 Un Sistema de Objetos se construye modelando mediante técnicas diferentes, pues las técnicas del Modelo
de Datos son bastante limitadas para soportar el Modelo de Objetos.
● Consejos prácticos.
• No comenzar construyendo diagramas de clases; primero, es necesario comprender el problema.
• Intentar mantener el Modelo sencillo.
• Seleccionar con cuidado los nombres.
• No introducir punteros o referencias a otros objetos como atributos.
• Intentar evitar asociaciones n- arias.
• No intentar establecer el grado de multiplicidad perfecto al principio.
• No introducir atributos de enlace dentro de la clase.
• Utilizar asociaciones cualificadas donde sea posible.
• Intentar evitar generalizaciones profundamente anidadas.
• Intentar asociaciones uno a uno.
• No se sorprenda si su modelo requiere una revisión.
• Documentar siempre los Modelos de Objetos.
50
Bibliografía
KORTH, HENRY, “Fundamentos de bases de datos”, España, McGRAW-HILL, 1999
DATE, J.C., “Sistemas de bases de datos”, España, ADDISON-WESLEY, 1995
HAWRYSZKIEWYCZ, “Análisis y Diseño de Bases de Datos”, , ,
JAMES MARTIN, “Organización de Bases de Datos”, México, PRENTICE HALL, 1998
GROFF, JAMES & WEINBER, PAUL, “Aplique SQL”, , ,
JOYANES AGUILAR, LUIS, ”Programación orientada a objetos”, España,
McGRAW-HILL, 1998
BOOCH, GRADY, “Diseño orientado a objetos con aplicaciones “, España,
McGRAW-HILL, 1991
RUMBAUGH, J. ; BLAHA, M., “Modelado y diseño orientado a objetos, España, PRENTICE HALL, 1995
Glosario
BDOO:
Bases de Datos Orientadas a Objetos
BDR:
Bases de Datos por Relación
BLOB:
Objetos Binarios de Gran Tamaño
BDOO94:
Bases de Datos orientados a Objetos 94
CAD:
Diseño Asistido por Computadora
CAE:
Ingeniería Apoyada por computadora
CORBA:
(Common Object Request Broker Arquitecture)
LDD ó DDL:
Lenguaje de definición de Datos
LMD ó DML:
Lenguaje de Manejo de Datos
OO:
Orientación a Objetos
51
ODL:
Estándar de Definición de Lenguaje de Datos
OMG:
Grupo Manejador de Objetos
OML:
Lenguaje de Manipulación de Datos
ODMG:
Gestión Manejadora de datos Objeto
OQL:
Equivalente al SQL(Lenguaje de Consulta)
SQL:
Lenguaje de Consulta Estructurado
SGBD:
Sistema de Gestión de Bases de Datos
SGBDOO:
Sistema de Gestión de Bases de Datos Orientada a Objeto
SO:
Sistema Operativo
Base de datos distribuida (BDD)
conjunto de múltiples bases de datos lógicamente relacionadas las cuales se encuentran distribuidas entre
diferentes sitios interconectados por una red de comunicaciones
Sistema de bases de datos distribuida (SBDD)
Un sistema en el cual múltiples sitios de bases de datos están 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.
Sistema de manejo de bases de datos distribuidas (SMBDD)
Aquel que se encarga del manejo de la BDD y proporciona un mecanismo de acceso que hace que la
distribución sea transparente a los usuarios. El término transparente significa que la aplicación trabajaría,
desde un punto de vista lógico, como si un solo SMBD ejecutado en una sola máquina, administrara esos
datos.
Sistema de base de datos distribuida (SBDD)
El resultado de la integración de una base de datos distribuida con un sistema para su manejo.
52