Grado

‘I
1
S.E.P.
D.G.I.T.
S.E.I.T.
CENTRO NACIONAL DE INVESTIGACION
Y DESARROLLO TECNOLOGICO
cenidet
“EXTENSIÓN AL LENGUAJE SQL
PARA EL MANEJO DE
DOMINIOS COMPUESTOS”
T
E
coMo
QUE
OBTENER
EL
S
I
REQUrslTo
DE
GRADO
S
:
CENTRO DE p.,FORMAC,O,.
MAESTRO EN CIENCIAS
E N
C I E N C I A S
C O M P U T AC I O N AL E S
P
R
E
S
E
N
T
A
JOSÉ ANTONIO MARTÍNEZ FLORES
CUERNAVACA,MOR
DICIEMBRE DE 1996
CENlDET
SEP r
SW
SISIEhIA NACIONAL D I 5 INS !I I’UI‘OS ’I’ECNOLOGICOS
1;
Centro Nacional
I
de Investigación yI Desarrollo Tecnológico
ACADEMIA DE LA MAES’I‘RIA EN CIENCIAS
DE LA COMPUTACION
Cueniavaca Mor., a 1O de Diciembre de 1996
I
t
Dr. Juan Manuel Rica170 Castillo
Director del CENIDET
Presente,
At’n: Dr. José Ruiz Ascencio
Jefe del Dpto. de Computación
I grato comunicarle, que coiifoniie a los liiieaniientos establecidos para .la
Nos es
.obtención del grado de niaesiría de este centro, y después de haber sometido a revisión
académica el trabajo de tesis denominado:
I
“Extensión al Lenguaje SQL para el Manejo
de Dominios Conipuestos”
que presenlo el Ing. José Antonio Martíiicz I:loi.cs. y Iiabiciido ciiiiiplido con todas las
correcciones ‘que le fueron indicadas, .acordamos no tener objeción para que se le conceda la
autorización de impresión de la tesis, así como de lijar la fe& del examen correspondiente.
Sin más por el momento, qucdaiiios de usted.
I
A t c n t a ni e n t e
Comisión de revisiói
Director de tesis
cenide
I1
1.
,
.
hl):irt;iito 1’0st;il
Iiilri’ior liiici-rindo 1’:iIiiiir;i SIN C.P. 62490
5-164,C.P. 62050. Ciiriri;iraca Mor., Rl<xicn
Ids. (73) IX-77-41 y 12-76-13, Ear. 12-24-34,
k@P
SlSl ERlA N A C IONhL DE INS11 lU1OS IECNOLOGICOS
Centro vacional de Investigación y Desarrollo Tecnológico
Ciieniavaca M o r , a I6 de diciembre de 1996
Iiig. José Aiitoiiio Martiiiez Flores
Candidato al h.ado de Macstro
ai Cieiicias de la Coiiiputacióii
PRESENTE
Despdés de Iiaber sometido a revisión acadéiiiica, y de Iiaber coiiíiniiado las sugereiicias
indicadas por"eIjuiado
1 ' _ de su trabajo de tesis dciioiiiiiiado:
"Extensión nl Lenguaje SQL para el Rlaiiejo de üoiiiinios Coiiipuestos"
me es grato jcointuiicarle, que coiiforiiie a los liiieaiiiieiitos establecidos para la obteiicióii del
grado de maestiía de este centro, se le coiicedc la autorimcióii respective para quc proceda coil la
iinpresióii de su tesis.
Siii más por el iiioiiieiito, rec.iba mis felicitaciones por el téniiiiio de sil tralxijo de tesis,
deseándole éxito en el exainai coi-i-espoiidieiite.
'I
Ateiitaiiieiite
1)
c.c.p. M.C. Wilbeitli Alcocer I<.
c.c.p. lug. David CIihez Agiiilar
Siildii cccióii Ac:idéiiiic:i
Dpto dc Seilicios Escolates
..
liilcrior 1iiirin:ido P:iliiiii.1 S/N C.P. 62490
Iixr1:idii Piis1;il 5-164. C.P. 6?050. Ciierrinvacn Mor.. México
Ti.ls. (73) 18-77-41 y 12-76-13. Fax. 12-24-34 :
. . ...,
....,.
DEDICATORIA
A Dios Padre, de corazón, por mostrarnos
su infinito amor a iravés de su
amado hijo, Jesucristo.
Con cariño y respeto a mispadres,
por darme a la vida y los
medios para andarla.
A mis abuelos Beto y Gricy y hermanas Grin,
Geny, Sandra, Gaby, Are& y Gryspor
su inapreciable compañía.
A mis tíos yprimos, por impulzarme
con su apoyo y confianza.
'
Y en general, a todos mis amigos
por brindarme su amistad
idivino tesoro !
I/
AGRADECIMIENTOS
A mis padres, hemanos y abuelos por cuanto han contribuido en mí crecimiento, tanto
material como espiritual, mil y un gracias.
Agradezco de manera muy especial a mi tíos: Felipa, Miguel, Valenth, Beto por sus
sabios y útiles consejos; y a m i s primos Andrés, Lalo, Toño por su apoyo y afecto.
Gracias doy a la mstitución que me permitió realizar m i s estudios de maestria, al Centro
Nacional de dvestigación y Desarrollo Tecnológico.
Gracias al Instituto de Investigaciones Eléctricas, en especial al Departamento de
Sistemas de Información las facilidades brindadas para el desarrollo de mi tesis de maestría.
Reconozco y agradezco el apoyo económico brindado por CONACYT en mis estudios
demaestna. '!
Le estoy profimdamente agradecido a mi a&wr de tesis, Dr. Rodolfo A. Pazos Rangel,
por su apoyo, orientación y tiempo dedicado para la culminación de este trabajo de tesis.
Expreso mi agradecimiento al M. C . Joaquín Pérez Ortega y M. C. Andrés Rodríguez
por su apoyo, hugerencias y buenos consejos.
,I
Agradezco a mis maestros del CENIDET por su apoyo y por haberme transmitido sus
experiencias y sabios conocimientos.
Agradezco ai jefe del Depto. de Ciencias Computacionaiei Dr. José Ruíz Ascencio, por
su apoyo brindado.
A mis revisores de tesis por sus comentarios, criticas y por su valiosa cooperación en
la revisión de este trabajo.
A mis compañeros y amigos de generación Anastacio A,, Carlos V., Claudia, Claudia
H, Fo~tino,Hugo I., Javier S., Ma. Ya-,
Miguel A. y Paula A. por su amistad y compañía.
..
A m i s amigos de hgeniena de software Alicia, E d , Hugo y Lety por los!'gratos
momentos compartidos.
A mis amigos de CENIDET Victor, Juan Gabriel, Juan de 'Dios, Leopoldo, Elsa, Ariel,
Laura Edith, Cecí y Ver0 por apreciable compañía.
TABLA DE CONTENIDO
LISTA DE TABLAS Y FIGURAS ...............
......................................................................
1v
CAPíTULO 1
INTRODUCCIÓN .............
.............................
......................................
...........................
...........................................................
1.3.Beneficios .,..
...........................
..................................................
.........................................................
1.4.Estado del Arte en SMBDDRs.........
.
1.5. Urganizacion
de la tesis ........................................................................
1
1
3
4
. I
CAPÍTULO 2
CONCEPTOS SOBRE DOMINIOS ............................................................................................
..................................................................................
2.1.El Estándar SQL ..................
......................................................
2.2. Tipos de datos en el estánd
. 2.3. Definición de dominios .......
................................................................................
......................................................
2.3.1. Definición de d
2.3.2. Definición de
2.4. Razones para el uso de dominios _.._.
2.5. Uso de dominios en tab1
9
9
10
11
I1
CAPíTULO 3
PLANTEAMIENTO Y ANÁLISIS DEL PROBLEMA
3.1. Antecedentes del proyecto ...............
3.1.1. SiMBaDD
3.1.2.Tipos deDatos del SiMBaDD
3.2. Alcance delatesis..
3.3. Lenguaje de Definición de Datos .....
...............
3.3.1.1.Dificultades aResolver enlacreación dedominios
simples
......
3.3.1.2.Dificultades aResolver en lacreación de dominios
................20
..........................................................................
3.3.5.Dificultades aResoIver en la mantenimiento de dominios .._
3.3.6. Dificultades a Resolver en la declaración de variables
3.4. Lenguaje de Manipulación de Datos .
3.4.1. Dificultades a Resolver en 1
i
20
,
3.4.3.Dificultades a Resolver en la instrucciónUPDATE........................................ 25
3.4.4. Dificultadesa Resolver en la'instrucciónDELETE ......................................... 26
CAPíTULO 4
METODOLOGÍA DE SOLUCI~N...............................................................
4.;. Alternativas para la implementación de dominios compuestos ...........
4.2. Gramática para la definición de dominios ............................................
4.2.1. Gramática para la definición de dominios simples ..........................................
4.2.1.1,CREATEDOMAIN........................................................................
4.2.1.2, ALTER DOMAW...........................................................................
4.2.1.3.DROPDOMAIN.............................................................................
4.2.2. Gramática para la definición de dominios compuestos...................................
4.2.2.1, CREATE COMF'OUNDDOMAIN................................................
4.2.2.2,DROP COMPOUNDDOMAIN.
4.3. Gramática para la definición de tablas e índices ........
4.3.1. CREATE TABLE ............
4.3.2. CREATE INDEX .............
4.4. Diccionario de Datos
4.4.1. Actualizaci
as .........................................................
4.4.2. Estructura de,losdiccionarios de dominios .....................................................
4.5. InstrucciónBEGIN DECLARE SECTION......................................................................
.,
4.6. Instruccion INSERT..........................................................................................................
.,
4.7. Instruccion
SELECT.........................................................................................................
.,
4.8. Instruccion
UPDATE .......................................................................................................
4.9. Instrucción DELETE .............................................
28
29
30
32
32
32
40
40
43
44
44
46
CAPÍTULO 5
IMPLEMENTACIÓN.
5.1. Transporte del SiMBaDDdel ambiente D
5.1.1. Motivos
.......................................
,:
5.1.2. Cambios realizados
5.2. Implementación del Diccionari
......................................................................
5.2.1. Actualización del DicciOnaio de Archivos Distribuidos (DAD) ....................
5.2.2. Anexión del archivo de dominios en el DAD
5.3.implementación de dominios..................................
5.3.1.Creación de dominios simples .........................................................................
5.3.2. Creación de dominios compuestos ..................................................................
5.4. Creación de tablas e índices ..
5.4.1. Creación de tablas
5.4.2.Representación d
5.4.2.1.Dominios simples en una tab1
5.4.2.2. Domini
..
5.4.3. Creacion
de indices ..........................................................................................
5.5. Instrucción DROP
.......
........................................................................
5.5.1.Borrado deDominios .......................................................................................
I
.
ii
..47
48
48
49
49
S4
54
54
5.5.1.1.Borrado de dominios simples
5.5.1.2.Borrado de dominios compuestos
5.6. Instrucción INSERT...........................................
.............................................................
.............................................................
............................................................................
60
CAPÍTULO 6
PRUEBAS DE FUNCIONALIDAD ........................................................
6.i. Objetivo de las pruebas .............................................................
6.2. Descripción del ambiente de pruebas ...............................................................................
...............................................................
6.3. Presentación de las pruebas
6.3.1,Contenido inicial de la base de datos de prueba .............................................
6.3.2.Programas de prueba
......
..............................................
62
.62
63
66
CAPÍTULO 7
/I
C0MEN;TARIOS FINALES .....................................................................
7.1. Conclusiones ...................................................
7.2. Posibles extensiones ........................................
7.3. Observaciones ................................................................................
ANEXOS
ANEXO A
GRAMÁaCADEL LENGUAJE SQL SOPORTADAPORELSiMñaDD
..98
ANEXO B
PROCEDIMIENTOS Y FüNCI.ONJZSIMPLEMENTADOSPARA EL MANEJO DE
DOMINIOS ........................................................................................................................
ANEXO C
LISTA DE ERRORES
,103
,105
REFERENCIAS.......................................................................
.......
....106
11
I
BiBLIOGRAFiA...................................................................................................................................
...
Ill
1o9
LISTA DE TABLAS Y FIGURAS
# TablalFig
.
Descripción
Pag
.
Tabla 2.1
Representación de una Relación en Forma de Tabla .............................................
14
Tabla 4.1
Representación de PtoGeo en TRegTabla. Campo por Elemento.........................
28
Tabla 4.2
Representación de PtoGeo TRegTabla. Campo por Dominio Compuesto............ 28
Tabla 4.3
Representación de Dominios Simples en la Estructura TregDom.........................
Tabla 4.4
Representación de Dominios Compuestos en la Estructura TregDomC................
43
Tabla 5.1
Representación de la Tabla Temper en TRegTabla..............................................
52
Tabla 5.2
Estructura Física de la Tabla Temper ..................................................................
52
Tabla 5.3
Búsqueda de un Elemento de una Columna Compuesta en TregTabla.................53
Tabla 6.1
Datos del archivo Temper.Dat.............................................................................
64
Tabla 6.2
Datos
del archivo Contam.Dat............................................................................
/I
64
Tabla 6.3
Datos del archivo Altura.Dat ................................................................................ 65
Tabla 6.4
Datos del Archivo de Dominios Simples..............................................................
65
Tabla 6.5
Datos del Archivo de Dominios Compuestos.......................................................
66
Figura 2.1
Representación de la Relación Jugador ................................................................
15
Figura 3.1
Arquitectura del Manejador de Archivos.............................................................
17
Figura 3.2
Diagrama a Bloques del Precompilador...............................................................
19
Figura 3.3
Presentación gafica de un Ciclo.........................................................................
21
Figura 5.1
Lista de Cláusulas para Ejecución del SELECT...................................................
57
42
'I
N
En este capítulo se muestra el objetivo y los beneficios obtenidos en el desarrollo del presente
trabajo de tesis, además del estado del arte en Sistemas Manejadores de Bases de Datos Relacionales
(SMBDRs) y se dkscribe a grandes rasgos como está organizada la tesis.
1.1. Evolución de las Bases de Datos
Cuando el manejo de bases de datos se p o p u l d durante los setentas y los ochentas emergió
un puñado de modelos de datos. Cada uno de estos primeros modelos de datos tenían ventajas y
desventajas que jugaron papeles impoitantes en el desarrollo del modelo de datos relacional.
En muchos sentidos el modelo de datos relacional representó un intento de simpliñcar los
modelos de datos anteriores. Antes de la mtroducción de los sistemas manejadores de bases de datos,
todos los datos perfnanentemente almacenados en un sistema informática, se almacenaban en archivos
mdividuales. Un sistema admmistrador de archivos, generalmente proporcionado por el fabricante del
computador como parte del sistema operativo, llevaba el control de los nombres y ubicaciones de los
archivos; básicamente no tenía un modelo de datos, no sabía nada acerca de los contenidos internos
de los archivos. El conocimiento acerca del contenido de un archivo (sus datos y estructura) estaba
incorporado a los programas de aplicación que utilizaban el archivo; si la estructura de los datos
cambiaba (por ejemplo, ai añadir un nuevo campo), todos los programas que accesaban el archivo
tenían que ser modificados.
Los problemas de mantener grandes sistemas basados en archivos condujo, a finales de los
sesentas, al desarrollo de los sistemas manejadores de bases de datos.
Primeramente se desarrolló el modelo de datos jerárquico M G 9 3 a l FOR93al. En este
modelo cada registro de la base de datos representa una pieza específica. Los registros tenían enlaces
(relaciones) padredijo.
1
CAPíTULO 1
I'
I"IRODUCCI6N
I/
La remPerdCión de 10s datos en una base de datos jerárquica requiere navegar a través de los
registros, moviéndose hacia arriba, hacia abajo y hacia los lados de un registro cada
unode los
sistemas manejadores de bases de datos jerárquicas más popdares fue el Infomation Management
System (ms)de b M FZIB3bl FOR93b] [DAT93b], introducido primeramente en 1968. Las
ventajas del IMS y'su modelo jerárquico son las.siguientes:
,,ez.
I/
-
Estructura simple.
Organizació'n padrefijo
I1
Rapidez.
La estructura sencilla de una base de datosjerárquicos se convertía en una desventaja cuando
los datos tenían una estructura más compleja; la estructura de este tipo de datos simplementeno se
ajustaría a la jerarqha estricta de IMS, por lo cual se desarrolló un nuevo modelo de datos en red
para manejar estructuras complejas. El modelo de datos en red extendía el modelo jerárquico
permitiendo que un registro participara en múltiples enlaces padrehijo. En 1971 la Conferencia sobre
Lenguajes de Sistemas de Datos publicó un estándar oficial para bases de datos en red, que se hizo
conocido como el mbdelo CODASYL w G 9 3 c l [KOR93c] [DAT93b] [GR092a].
I/
Una vez más el programador tenía que recorrer la base de datos registro a registro,
especiiicando esta ve4 qué relación recorrer además de indicar la dirección. Las bases de datos de red
tenían vanas ventajas:
1)
-
-
Flexibilidad. 11
Normalización.
Rapidez.
Las desventajas de los modelos jerárquicos y de red condujo a un intenso interés en el nuevo
modelo de datos relacional cuando fue presentado por primera vez por el Dr. Codd en 1970
m @ 3 d ] FOR93dl [DATgSa]. El modelo relacional era un intento de simplificar la estructura de
las bases de datos. E l h n a b a las estructuras explícitas padrehijo de la base de datos y en su lugar
representaba todos lob datos en la base de datos como simples tablas (relaciones) fia/columna de
,I
valores de datos.
Una de las prinkipales diferencias entre el modelo relacional y los modelos de datos prbitkos
es que los punteros expiícitos, tales como los enlaces padrehijo de una base de datos jerárquica,
están prohibidos en las bases de datos relacionales. Obviamente esos enlaces siguen existiendo en una
base de datos relacional. Tal enlace padrefijo está representada por valores de datos comunes
almacenados en las dod'tablas. Todos los enlaces de una base de datos relacional están representados
de este modo, lo que permite recuperar de la base de datos, datos relacionados manipulando estos
enlaces de un modo sqciilo y directo [GRO92b].
Las relaciones poseen ciertas propiedades, todas ellas consecuencia inmediata de la definición
de relación que en el Capítulo 2 se dará en detalle.
I/
2
.,
CAPíTllLO 1
-
INTRODUCCI~N
'1
No existen'hplas repetidas.
Las tuplas no están ordenadas (de arriba hacia abajo).
Los atnbuths no están ordenados (de izquierda a derecha).
Todos los valores de los atributos son atómicos.
Con respecto a la cuarta propiedad, una forma más precisa de expresarla es: "todos los
valores de los atributos simples son atómicos", es decir, contienen sólo valores atómicos. (Aún si
existen atributos compuestos, éstos no son sino una simple concatenación de atributos simples; por
ejemplo, las fechas y horas). Las relaciones construidas con base en lo anterior se denominan
normalizadas, o bied'se dice que están enprimeraform normal. En otras palabras, la primera forma
normal implica sencjllamente la amencia de grupos repetitivos.
La razón de insistir en la normalización de todas las relaciones es la siguiente: En esencia una
relación normalizada es una estructura más simple, desde el punto de vista matemático, que una no
normalizada. En conkecuencia se logra sencillez, es decir, sencillez en la estructura de los datos, lo
cual conduce a su vez a simplificaciones correspondientes en todos los aspectos del sistema
'I
y en menor número) PAT93cl.
(operadores más sencillos
1.2. Objetivo
I/
El objetivo de esta tesis es diseñar e implementar en un Sistema Administrador de Bases de
Datos Distribuidas (SABDD) la definición y manipulación de dominios simples y compuestos, y usar
éstos en la definición be las tablas en lugar de usar tipos de datos básicos como se hace actualmente
en los SABDDs Relajando esta limitación se puede lograr el manejo de dominios compuestos en las
columnas, y con el prksente trabajo de tesis se pretende demostrar la factibilidad de manejar dominios
compuestos en el mopelo relaciona1 sin afectar el lenguaje de manipulación de datos.
Dadas las ventajas que ofrecen la deñnición y manipulación de dominios, se han agregado a
un prototipo experimental denominado SiMBaDD [SOS95] (estema manejador de bases de datos
distribuidas), nuevaslmtiuas que permiten el manejo de dominios, en particular las extensiones al
Lenguaje de Definición de Datos (LDD) de Stmctured Query Language (SQL) que permiten la
I
definición de dominios compuestos en Bases de Datos Distribuidas (BDDs) y su manejo por parte
del Lenguaje de Manipulación de Datos (LMD).
1
Cabe aclarar que este proyecto es parte de una larga sene de trabajos realizados en el Instituto
de Investigaciones Eléktricas (DE)y el Centro Nacional de Investigación y Desarrollo Tecnológico
(CENIDET) en el área de bases de datos distribuidas, que tienen por objeto estudiar problemas y
desarrollar tecnologd relacionados con manejadores de bases de datos distribuidas
3
7
CAPiiULO 1
1.3. Beneficios
II
INTRODUCCIÓN
II
11
Los principales beneficios que se pueden obtener con el uso de dominios en u11 Sistema
Manejador de Bases de Datos Relacionales (SMBDR) son los siguientes.
-
Definir nuevos tipos de datos a partir de los básicos (Char, Integer, Long&, y Date), con lo
cual el usuario podrá contar con un mayor número de tipos.
I1
-
Proporcionar mayor legibilidad en el desarrollo del código, ya que el programador podrá
crear y manejar los tipos deñnidos adecuadamente a su aplicación.
-
Ayudar a detectar errores en la comparación de columnas que tengan dominios diferentes
-
Usar en fo&a normal tipos de datos estructurados (dominios compuestos) sin afectar al
lenguaje de manipulación de datos del manejador.
11
-
Tener en el caso de los dominios compuestos un nivel más de abstracción con el manejo de
'I
registros, en forma análoga a los lenguajes C y Pascal.
I/
1.4. Estado del Arte en SMBDRs
En 1990 apareció una nueva obra de Codd [DAT95b], en la que presenta la segunda versión
del modelo relacion&(RMN2), ampliando y profundizando en ciertos conceptos como los dominios,
restricciones de integidad, catálogo, vistas, etcétera, proponiendo un mejor tratamiento de los
valores nulos (a los que denomina murcus "marks") y de sus operaciones asociadas, y estudiando
otros temas, como los relativos a la administración, autorización, distribución, y protección de datos.
Todo elio organizado en las 333 características (agrupadas en 18 clases) que, s e w él, habría de
tener un sistema para ser considerado como relacional, versión 2 N G 9 3 e l .
Cabe hacer mención que gran parte de los SMBDRs comerciales (sistemas manejadores de
bases de datos relacionales) hoy en día no ofrecen el manejo de dominios [ m 9 2 ] pOC94]
[DAT95c], hay otros hue manejan dominios simples (como RDB PIG911 y Microsoft SQL Sewer
QvlIC87a]), pero ninguno considera el uso de dominios compuestos debido a las dificultades técnicas
iiivolucradas FOR93el PAT95dI.
A continuación se describen los principales sistemas manejadores de bases de datos
distriiuidas relacionales que permiten el nianejo de dominios simples y que se encuentran actualmente
en el mercado. Además de describir un protonpo.
4
I1
INGRES
11
Ingres wG93flha sido uno de los mayores competidores de Oracle en el mercado de las
Vax y de Unk,y d lenguaje Query Language (QUEL) fue uno de los más fuertes competidores de
SQL como el lenguaje estándar relacional. Ingres soporta la creación de tipos de dato del usuario y
tiene la más fuerte mtegridad en dominios que cualquier otro manejador de bases de datos relaciona1
pAT95eI. Ingres ofiece dos versiones de SQL IngresíSQL, el cual es compatible con el nivel 1 del
ANSI, y el Open SQL, un subconjunto que puede ser usado con el ingredGateway para consulta a
sistemas no relacionales Ingres.
II
PROGRESS m & 3 g ]
Los dommioi pueden deñnirse como caracteres, enteros, reales, booleanos, fechas, o vectores
de una columna. La longitud y demás características (ámbito de los dígitos aceptables como por
ejemplo la obligatoriedad de introducir todos los dígitoo, un determinado dígito en una posición
determinada, mayúsculas, etc.) se definen en la metabase. Se dispone del valor nulo (desconocido)
para cualquiera de ekos tipos. Los datos se almacenan en longitud variable.
I/
Se definen los dominios directamente en la metabase, y su especiñcación es dinámica; es decir
pueden variarse enlcualquier momento (con la salvedad de que los datos existentes queden
coherentes con la restricción introducida). La integridad de dominio incluye la desautorización del
valor nulo, y la comprobación del cumplimiento de una fórmula @.e., se puede controlar cada digto
introducido comprobando que figure en mayúsculas, minúsculas, figure en una lista de digitos
permitidos, ...). En lo que a fechas se refiere, sólo se permite la introducción de los dígitos que
corresponden a los días existentes. Un dominio puede deñnirse como sensible a la distinción entre
mayúsculas y minúsculas, o no.
Microsoft/SYBASE SQL Server
I/
Sybase w C 8 7 b l es un sistema de gestión de bases de datos relacionales por lo que soporta
plenamente el concepio de relación. Para garantizar la integridad de los datos, Sybase soporta la idea
de dominio como conjunto de valores relacionados de forma lógica que pueden tomar las columnas.
El servidor proporciona mecanismos para garantizar que cualquier valor que se pretenda dar a una
columna definida sobre un determinado dominio, esté en el conjunto de valores permitidos.
11
En el nivel más básico el servidor asegura la integridad, comprobando que el valor que se
'I
introduce para una columna es del tipo correcto. Para definir dodinios más especXcos, Sybase
permite al usuario crear reglas que pueden asociarse directamente a una o varias columnas de una o
.I
vanas tablas en una o varias bases de datos, o bien a un tipo de dato creado por el usuario; de esta
forma se consigue que los dominios soporten algo de semántica.
11
I/
5
I1
11
CAPíTULO I
INTROD UCCI6N
'1
Este concepto de regla se utiliza también para introducir en la base de datos determinadas
restricciones de &ario, tales como, por ejemplo, que la edad de un empleado no sea inferior a
dieciséis años. Para soportar esta restricción se asociaría una regla a la columna edad de la tabla
empleados o se crearía un tipo de datos edad al que se le asociaría la regla.
i
CA-DATACOM I/
Una restrichón en CA-DATACOM N G 9 3 h l son los dominios, éstos aseguran que en
operaciones de mantenimiento, únicamente se pueden incluir rangos de valores preseleccionados y
válidos en los renglhes de cualquier tabla.
.
I/
Las facilidades de integración de dominio se aplican a todas las tablas de una base de datos,
hayan sido creadas en el ambiente nativo de Datacom o vía SQL.
6
CA-IDMSIDB
I/
CA-IDMSDB N G 9 3 i l almacena las reglas de integridad en un diccionario centralizado
'I
desde donde son compartidospor las aplicaciones, sin necesidad de repetirlas en cada programa. Esto
se traduce en reducción del desarrollo y de los costos de mantenimiento, así como en mejora del
rendimiento, control y fiabilidad. La integridad referencial se define en CA-IDMSDB a nivel del
diccionario para establecer relaciones entre tablas. Estas relaciones se refuerzan siguiendo la
coiivención ANSI.
,I
La integridad de dominio impone restricciones sobre columnas o campos. Estas reglas se
4
almacenan también en el diccionario y permiten especificar un dominio de valores válidos para un
campo.
11
I/
Prototipo Mariposa WAR961
i
El prototipo Mariposa ha sido desarrollado por la Universidad de Berkeley, California en
Estados Unidos, el chal se basa en el modelo Relacional. Este prototipo ofiece el uso de dominios
simples y en cierta forma, la de los dominios compuestos. Es decir, el prototipo Mariposa al crear
una estructura compuesta, la define como un objeto al incluirle métodos.
ii
Estándar SQL
I
ps
Últimamente,
-pos de trabajo de ANSI X3H2 y el ISO/IEC han elaborado una nueva
versión del SQL (SQL/92) [IS0921 que incrementa substakialmente la capacidad semántica del
esquema relacional, se,añaden nuevos operadores, se mejora el tratamiento de errores, proporciona
borrados y actualizaciones en cascada, y se incluyen normas para el SQL intercalado.
I/
I/
6
CAPíTVLO I
.I
INTRODUCCIbN
I/
En la actualidad también se están elaborando nuevas propuestas N c 9 3 j l [GRO92c]
m 0 9 6 1 Para extender el SQL (el llamado SQL3) dotándolo, además de una mayor capacidad
semántica, de cieitos principios del paradigma de orientación de objetos. Se pretende incluir en el
lenguaje, tipos ide dato definidos por el usuario, disparadores, jerarquías de
generalizaciódespeciaiización,llamadas a procedimientos externos, etc.
I/
Por Ú l h o , cabe destacar que en próximas versiones del lenguaje SQL (como la denominada
SQL3) se están definiendo más elementos a ñu de soportar directamente la herencia por medio de
las denominadas subtablas píiG93jl.
/I
En conclusión se ve claramente que el estándar SQL a evolucionado, desde la definición,
manejo y protecciód de datos hasta normas para instrucciones intercaladas, conforme las bases de
datos relacionales se han ido popularizando las necesidades de los usuarios se han vuelto más
I/
sofisticadas;debido a lo anterior no es exagerado proponer la inclusión de dominios compuestos en
el estándar SQL.
,
I/
1.5. Organización de la Tesis
11
El contenido de la presente tesis está organizado de la forma siguiente.
I/
En el Capítulo 2 aparecen algunos conceptos sobre dominios, los beneficios que proporcionan
y su inclusión en el estándar SQL, así como también los tipos de dato que se consideran en este
estándar Además en este capítulo se ejemplifica el uso de dominios en la creación de relaciones
11
En el Capítulo 3 se presentan los antecedentes de la tesis, su alcance y se proporciona un
planteamiento del ptoblema a resolver para la definición y manipulación de dominios simples del
estándar SQL En este capítulo se describen también los problemas a solucionar para el uso de los
dominios compuestob (propuestos para el estándar SQL).
En el Capítulo 4 se mencionan las posibles soluciones conceptuales y se determina la
factiiilidad de solución. En este capítulo se descriien algunas de las estructuras y métodos empleados
para la solución del problema así como la gramática propuesta para la definición y borrado de
dominios compuestos.
I1
En el Capítulo 5 se explican con detalle los algoritmos que permiten la definición de dominios
11
simples y compuestos, así como su manipulación en un sistema manejador de bases de datos
distribuidas experimental.
I
En el CapítUio 6 se presentan las pruebas efectuadas al sistema manejador de bases de datos
4
distribuidas experimental con las que se demuestra la equivalencia semántica de las instrucciones
SQL-Pascal, para el uso de dominios (simples y compuestos).
I/
1
7
I1
8
En este capítulo se describen algunos de los conceptos sobre dominios y su inclusión en el
estándar SQL (SQL2), y los beneficios que proporcionan, así como también los tipos de datos que
proporciona el estándar SQL. También se muestra el uso de los dominios en la creación de relaciones.
2.1. El Estándar SQL
t
En 1970, E.7. Codd, en ese entonces miembro del San Jose Research Laboratory de iBM
(ahora el Almaden Research Center), publicó un artículo, un clásico en nuestros días, titulado: "A
Relational Model of Data for Large Shared Data Banks" pAT93d], en el cual menciona u0 conjunto
de principios abstrdkos para la administración de bases de datos: el llamado modelo relacional.
Posteriormente se presentaron investigaciones las cuales implementaban prototipos de una variedad
de lenguajes relacio~ales.Uno de estos lenguajes en particular fue el SEQUEL, definido por D.D.
Chamberlin y otros mvectigadores del Research Laboratory de ISM (en 1974). Una versión revisada
del SEQUEL, llamada SEQUELR, se deñnió en 1976-77 (el nombre fue cambiado a SQL
(Stnictured Query Languaje, Lenguaje de Consulta Esiruchrrado por razones legales). Este lenguaje
fue implementado en'hprototipo llamado System R, el cual se convertiría en un sistema comercial
muy popular @lAT89].
Posteriormente otros vendedores también anunciaron productos basados en SQL. Estos
anunciosincluianproductos enteramente nuevos tales como DG/SQL (1984) y SYBASE (1986), y
además interfaces para productos establecidos tales como iNGRES (1981, 1985) e iDM (1982,
1985). En 1992 había más de 100 productos en el mercado que soportaban algún dialecto de SQL,
corriendo desde computadoras personales hasta las grandes computadoras. SQL se convirtió en el
esfandar de facto en,el mundo de bases de datos relacionales.
Además, SQL es también ahora un estándar oficial. El estándar original (publicado por el
American National Standards Instmite (ANSI) en 1986, y por la International Standards Organization
9
/I
CAPfTULO 2
CONCEPTOS SOBRE DOMINIOS
11
American National Standards Institute (ANSI) en 1986, y por la International Standards Organization
(ISO) en 1987, c o m h e n t e conocido como SQLí86) fue extendido en 1989 para incluir una
característica de mejora en la integridad. A esta versión extendida frecuentemente se le llama
informalmente como "SQLí89". IBM ha publicado su propio estándar de SQL intercalado, el
Systems Application Architecture Database Interface (SAA-SQL) [GRO92c]. El comité de IS0 y
ANSI ha estado trabajando por varios años para definir una versión revisada (y expandida) del
estándar on@ conocido informalmente como "SQL2" (más recientemente "SQL/92") que vino a
ratificar el estándar Internahonal S t d r d ISO/IEC 9075:1992, Database Languaje SQL (Estándar
Internacional ISO/IEC 9075: 1992, Lenguaje de Bases de Datos SQL") [ISO92], a h a l e s de 1992
Sus principales ventajas son las siguientes.
I1
-
-
Reducir el costo de aprendizaje.
Portabilidadb longevidad en las aplicaciones
Comunicación intersistemas.
Manejo de dominios
Las características y beneficios de SQL que le han permitido tener éxito son las siguientes
[GR092d]:
I/
Su independencia de los vendedores.
Su portabiiidad a través de sistemas informáticos.
Los estándares SQL.
El apoyo de IBM.
Su fundamento relacional.
Su estructura de alto nivel (no procedimental).
Las consultas interactivas ad hoc.
Su acceso a la base de datos mediante programas.
Las vistas múltiples de datos.
El ser un lenguaje de bases de datos.
Su definición dinámica de datos.
La arquitectura
cliente/servidor.
I
I1
2.2. Tipos de Datos en el Estándar SQL
El estándar SQL d e h e distintos tipos de datos definidos por los siguientes palabras clave:
-
-
CHARACTER
CHARACTER VARYING
I/
BIT
BIT VARYING
NUMERIC "
DECIMAL
INTEGER '/
10
CAP~TULOz
CONCEPTOS SOBRE DOMINIOS
11
SMALLrn
FLOAT
REAL
I/
DOUBLE PRECISION
DATE
,I
TIME
TIMESTAMP
INTERVAT!
1
Cada tipo de dato tiene asociado un descriptor de tipo de dato. El contenido de un descriptor
de tipo de dato está ldetenninado por el tipo de dato específico que éste describe. Un descriptor de
tipo de dato incluye un identiíicador del tipo de dato y toda la información necesaria para caracterizar
una ocurrencia de ese tipo de dato.
1
2.3. Definición de Dominios
11
En el estándar de SQL existe el concepto de dominio (siempre se sobreentiende que los
dominios son simples si no se indica de manera explícita lo contrario), y sirve para crear tipos de
t
básicos, poniéndoles restricciones (valores permitidos) PAT93eI. En este
datos adicionales a los
aspecto se parecen a algunos lenguajes de programación con la diferencia de que en éstos los datos
se pueden agrupar en 11registros. Para subsanar esta deficiencia en esta tesis se están proponiendo los
dominios compuestos para el estándar de SQL.
I/
2.3.1. Definición deiDominios Simples
Un dominio es el conjunto devalores escalares permitidos para un atributo, todos del mismo
tipo, donde los valores escalares representan la menor unidad semántica de información en el sentido
de que son atómicos lpAT93eI [ISO92].
Un dominio está descrito por un descriptor de dominio Un descriptor de dominio incluye los
,I
siguientes componentes
-
-
El nombre del dominio
El descriptor del tipo de dato del dominio
El <nombre de la colección> de la <cJáusula de colección>, si la hay del dominio
El valor de la <opción por omisión>, si la hay de el dominio
El descriptor de restricción del dominio de la restricción del dominio, si la tiene.
'I
A continuación se presenta un ejemplo en donde se deñne un dominio para ilustrar lo dicho
11
Supongamos que deseamos crear un dominio Grado. Esto se puede lograr con la siguiente
instmcción
CAPíTULO 2
CONCEPTOS SOBRE DOMINIOS
I1
Ejemplo 2.1
I
CREATE DOMAIN Grado INTEGER
CHECK(Grado >= O AND Grado <= 179);
I/
Una vez creado el dominio simple Grado, el rango de valores que permitiria (cláusula de
restricción del dominio) serían valores de tipo entero iguales o mayores a O y menores o iguales a
179, acorde a su cláusula de restricción que restringe los valores reales que puede tomar un grado.
La definición del dominio se almacena en el DAD (diccionario de datos, descrito en la Sección 4 4)
I1
para ser usada posteriormente.
I/
Análogamente se puede crear el dominio Minuto que permita como valores válidos a enteros
mayores o iguales que O y menores o iguales que 59 por medio de la siguiente instrucción:
I/
Ejemplo 2.2
'/ CREATE DOMAIN Minuto INTEGER
CHECK(Minut0 >= O AND Minuto <= 59);
I/
2.3.2. Definición de Dominios Compuestos
1)
Informalmente un dominio compuesto es una combinación de dominios, cuyos elementos a
'1
su vez son simples o compuestos dependiendo de la naturaleza del dominio sobre el cual se definen.
A un dominio compuesto (tipo compuesto) matemáticamente se le denomina producto
curtesiano de sus tipos contribuyentes. Esto surge del hecho de que el conjunto de valores defuido
por este tipo compuesto consta de todas las posibles combinaciones de valores, tomadas de cada
conjunto definido por cada tipo constituyente. Así, el número de dichas combinaciones, también
llamadas n-adas, es el ,producto del número de elementos de cada conjunto constituyente [wJR87].
En términos generales, un tipo compuesto T con componentes de los tipos T1, T2, ..., Tn se
deñne como sigue: I/
TYPE T =
RECORD s1 : T,;
S, : T,;
...
s, : T,;
END
card(T) = card(T,) * card(T,)
* ___ * card(T,)
a1
A continuación se muestran dos ejemplos en donde se definen dominios compuestos para
ilustrar este concepton
12
CAPhJLO 2
Ejemplo 2.3
CONCEPTOS SOBRE DOMINIOS
'1
11
CREATE COMPOUND DOMAIN Latitud
(Grado
Grado,
Minuto
Minuto);
I/
I/
en donde la primera aparición de la palabra Grado define el nombre del primer elemento de Latitud,
y la segunda aparición se refiere al tipo de dato del elemento (que en este caso es el dominio simple
Grado); algo similar ocurre con la palabra Minuto,
Ejemplo 2.4
I
I
CREATE COMPOUND DOMALN Longitud
(Grado
Grado,
Minuto
Minuto);
,I
La creación de un dominio compuesto PtoGeo, constituído por los elementos Latitud y
Longitud, se puede hacer por medio de la siguiente instrucción (propuesta del SQL extendido):
Ejemplo 2.5
I1
,/
CREATE COMPOUND DOMAIN PtoGeo
(Latitud
Latitud,
Longitud
Longitud);
I/
2.4. Razones para el Uso de Dominios
'I
El uso de dominios nos permite la creación de tipos definidos por el usuario, permitiéndonos
I)
con ello, contar con los tipos adecuados a la aplicación con lo cual se logra tener tipos nemotécnicos.
Esto permite una mayor legibilidad en el desarrollo de código, así como la detección oportuna de
errores lógicos al comparar columnas definidas con el mismo tipo base pero con diferente dominio.
También permite determinar los tipos de operaciones que se pueden ejecutar con los datos; por
ejemplo, no se pueden! aplicar funciones, tales como SUM, a columnas deíinidas en base a un dominio
compuesto. Una gran ventaja de los dominios es que restringen los valores a insertar (al deñnir una
columna en base a un'dominio), delegando al manejador la responsabilidad de validar los valores a
almacenar en la base de datos, con lo cual se logra eliminar la redundancia de la veriíicación en cada
programa de aplicacion cada vez que se haga referencia a una determinada columna.
Además existe la ventaja de que los dominios compuestos se pueden introducir a SQL de
manera natural sin "afectar la sintaxis del lenguaje de manipulación de datos (LMD) como
posteriormente se mostrará y de tener un nivel más de abstracción con el manejo de tipos
11
compuestos, en forma análoga a los lenguajes C y Pascal.
13
CAP~VLO2
CONCEPTOS SOBRE DOMINIOS
1
2.5. Uso de Dominios en Tablas
SQL se ha fstablecido claramente como el lenguaje de bases de datos relacional estándar
Unas de la partes más importantes de este lenguaje son las siguientes:
-
Lenguaje dL definición de datos (LDD). El SQL LDD incluye instrucciones para d e h i r
esquemas de relación (tabla), eliminar relaciones, crear índices, y modificar esquemas de
relación. '1
-
Lenguaje delmanipulación de datos. El SQL LMD incluye un lenguaje de consultas basado
en el álgebra relacional y el cálculo relacional de tuplas. También incluye instrucciones para
insertar, suprimir y modificar tuplas de la base de datos KOR93el.
La relación es el elemento básico del modelo relacional, y se puede representar como una
tabla (ver Tabla Z.l)."En ella podemos distinguir un conjunto de columnas, denominadas atributos,
que representan propiedades de la misma y que están caracterizadas por un nombre, y un conjunto
de filas llamadas tuplas, que son las ocurrencias de la relación. El número de filas de una relación
se denomina cardinalidad, mientras que el número de columnas es el grado. Existen también
dominios de donde lbs atributos toman sus valores. En la Figura 2.1 se representa la relación Jugador
en donde aparecen los distintos elementos del modelo relacional.
I/
AtributoI 1
Atributo 2
.......
Atributo n
**** ***
*******
*******
*******
Tupla 1
1)
*******
*******
*******
*******
Tupla 2
*******
*** *** *
*******
Tupla n
. ,I
*******
I1
'I
Un esquema de relación denotado por R(A,:D,, A2:D,, ..., A,,:Dn) es un conjunto den pares
atributo-dominio subyacente { (A,:D,) }, donde n es el grado del esquema de relación. El esquema
es la parte deñniiona $ estática de la relación, que se corresponde con la cabecera cuando la relación
se percibe como una tabla (al conjunto A de atributos sobre los que se define la relación se le suele
denominar contexto de la misma).
i/
!I
14
CAPíTULO 2
CONCEPTOS SOBRE DOMINIOS
I /
-
b
Gad"
Figura 2.1. Representación de la Relación Jugador.
Una ocurrenda de relación (llamada a veces simplemente relación) denotada por r(R) es un
conjunto de m tuplas { t,, t2, ...,t. } donde cada tupla es un conjunto de n pares atributo-valor {
I
( 4 V J }, donde V, es el valor j del dominio D, asociado al atributo 4;el número de tuplas m es la
cardinalidad. La relación r(R) es por tanto, el conjunto de tuplas que, en un instante determinado,
satisfacen el correhondiente esquema de relación R aunque el esquema de relación es relativamente- invariante, su extensión vana en el transcurso del tiempo.
I
A continuaciónveremos cómo deíinir una tabla usando dominios. Con los dominios definidos
en las secciones anteriores podremos crear la tabla Temper con las columnas RoGeo de tipo PtoGeo,
Ciudad de !+o Ciudad (dominio simple) y Temper de tipo real. Esto se puede lograr con la siguiente
expresión del SQL estándar:
I/
Ejemplo 2.6
'I CREATE TABLE Temper
(PtoGeo
Ciudad
Temper
1)
PtoGeo,
Ciudad
Float);
li
Tanto los atributos compuestos como los dominios compuestos pueden ser tratados, si así
lo precisa el usuario y m o piezas monoiíticas de información, es decir, como valores atómicos. LO
que permite mantener en cierta forma la restricción de atomicidad del modelo relacional.
15
I/
3
CAPITULO
3
EL
PROBLE,MA
En este capítulo se presenta una descripción detallada de los problemas más importantes que
involucran la dehicion y manipulación de dominios, en el Lenguaje de Definición de Datos (LDD)
y el Lenguaje de M@pulaciÓn de Datos (LMD) del estándar de SQL para los cuales en capítulos
subsecuentes se dará la metodologia de solución, así como su hplementación.
Además se presentan los antecedentes previos a esta tesis con el ñn de ubicar este trabajo
dentro de la infraeshuctura de "software" ya existente, así como el alcance del mismo.
3.1. Antecedentes del Proyecto
3.1.1. SiMBaDD
En el Instituto de Investigaciones Eléctricas (IIE)se encuentra en desarrollo un Sistema
Manejador de Bases de Datos astribuidas (SiMBaDD) experimental [SOSSS]. El SiMBaDD tiene
las siguientes caractensticas:
*
Soporta el modelo relaciona1
*
Utiliza la red Windows for Workgroups Ver. 3.11 WC931.
*
U t d el sistema operativo Microsoft Windows versión 3.11 [MIC93]
*
La red está constituida por tres computadoras personales AT.
*
La forma como opera el SiMBaDD, es a través de aplicaciones escritas en Turbo
16
CAP~TULO3
PLANTEAMIENTO Y ANALISISDEL PROBLEMA
I1
Pascal [PAS911 con SQL intercalado
*
11
Las instrucciones de SQL para el lenguaje de definición de datos son CREATE
TABLE, CREATE INDEX, DROP TABLE y DROP INDEX; y para el lenguaje de
manipulación de datos son INSERT, SELECT, UPDATE, DELETE, y la
manipulación de cursores.
.I
El primer trabajo relacionado con bases de datos distribuidas (BDDs) [GUZ90] desarrollado
en el departamento de Sistemas de Información del IIE consistió en el desarrollo de un paquete de
rutinas que permiten el acceso a los archivos de una BDD por medio de programas escritos en Turbo
Pascal. Estas primitivas permiten el acceso concurrente y transparente a las bases de datos
distriiuidas.Lo ante* quiere decir que un programa en Pascal que hace uso de estas rutinas, puede
accesar los archivos desde cualquier máquina de la BDD, sin necesidad de especificar en qué
computadora de la red residen dichos archivos (a ésto se le conoce como transparencia de
localización). Las d i n a s fueron escritas en lenguaje ensamblador y en Turbo Pascal, para trabajar
con el sistema operativo DOS versión 3.3 WCSS]. El paquete esta constituido por dos niveles de
programas (Figura 3! 1) PER881.
SERVICIOS DEACCESOAARCHNOS Y
REGISTROS EN FORMITRANSPARENT
I
I
il
I
SERVICIOS DE ACCESO AARCHNOS Y
REGISTROS DESDE TURBO PASCAL
I
"EL1
SERVICIOS DEACCESOAARCHNOS Y
NIVEL O
I/
Figura 3.1. Arquitectura del Manejador de Archivos.
11
Para facilitar la implementación del paquete, se consideró conveniente desarrollar un gnipo
/I
de rutinas (nivel 1) que permiten abrir y cerrar archivos, así como leer, escribir, reseivar, y liberar
registros en cualquier computadora de la red. Estos servicios se ofrecen como funciones del sistema
operativo (denominadas interrupciones), las cuales pueden ser invocadas por medio de lenguaje
ensamblador.
El nivel 2 ofr&e los servicios de transparencia de localización como un conjunto de nitinas
cuya característica es gue permite a los programas de aplicación accesar información de un archivo
cualquiera de una BDD, sin necesidad de indicar en qué computadora o disco se encuentra el archivo.
Esto se logra ?or medio del Diccionario de Archivos Distribuidos (DAD). El DAD contiene
entre otras cosas, una lista de los nombres de los archivos que constituyen la BDD junto con la
localización de cada archivo ( o sea, la máquina donde se encuentra cada archivo) y la descripción del
I/
registro.
1)
17
!I
CAPíTULO 3
PLANTEAMIENTO Y ANALISISDEL PROBLEM
1)
El segundo trabajo [ARE921 desarrollado en el IIE consistió en un precompilador del
11
lenguaje SQL,el cual
facilita el uso del manejador de archivos (descrito anteriormente), por parte
de cualquier desarrollador de aplicaciones que conozca de bases de datos. Este precompilador está
basado en el estándar del SQL [ISO89], el cual consta de (1) un lenguaje de de6nición de datos
(LDD) que permite la creación, definición y eliminación de las tablas de una base de datos, y (2) un
lenguaje de manipuiación de datos (LMD) que sirve para manipular las tablas con operaciones tales
como insertar, borrar o consultar renglones de las tablas. De esta manera, los desarrolladores
familiarizados con SQL pueden d e h i r y manipular una BDD sin necesidad de conocer las rutinas y
los argumentos del manejador de archivos.
I/
El precompddor está constituido por un reconocedor de mshicciones de SQL y un traductor
(el cual consiste a su vez de un analizador y generador de código).
I(
El reconocedor de mshicciones de SQL tiene la función de buscar en el programa fuente de
SQL intercalado en Turbo Pascal y reconocer cuándo se inicia una instrucción de SQL.
I1
El analizador se encarga de identificar los elementos del lenguaje SQL agrupándolos en
I
construccioneslógicas, y consta de tres partes:
I .-
El analizado: léxico que se encarga de leer las instrucciones en SQL del programa fuente
(carácter por carácter) para reconocer los elementos mínimos del lenguaje llamados unidades
léxicas (tokens).
I/
2-
3.-
El analizador sintáctico que verifica que la secuencia de las unidades léxicas sean legales de
/I
acuerdo a las reglas sintácticas especificadaspor la gramática independiente de contexto del
lenguaje SQL.
I/
El analizador semántico que se encarga de verificar que las instrucciones tengan una
semántica o significado correcto
11
El generador de código produce código en Turbo Pascal para DOS que es semánticamente
equivalente a la instdcción de SQL analizada. El código generado incluye llamados a los seMcios
del manejador de archivos descrito anteriormente.
tt
Todas estas partes actúan en un solo paso de la siguiente manera: cuando se detecta el
símbolo "$", que indica el inicio de una instrucción de SQL,el precompilador transfiere el control
al analizador sintácticd (ver Figura 3.2), éste utiliza un esquema de traducción dirigido por sintaxis,
el cual está basado en la idea de que las reglas de producción de la gramática del lenguaje SQL se
usen para dirigir el tipo de procesamiento que se va a efectuar en las construcciones de lenguaje.
De esta forma, para cada regla de producción, el analizador sintáctico puede llamar al análisis
semántico apropiado"y.la rutina de generación de código para generar código Turbo Pascal para
DOS.
i/
18
CAPíTULO 3
II
PLANTEAMIENTO Y A N h S I S DEL PROBLEMA
II
1;
Figura 3.2. Diagrama a Bloques del Precompiiador.
/
3.1.2. Tipos de Datos del SiMBaDD
Antes del desarrollo de está tesis el SiMBaDD solamente contenía los principales tipos de
datos básicos del SQL, que son los siguientes:
li
CHAR
SMALLINT,I
INTEGER
DECIMAL I/
SMALLFLOAT
FLOAT
I/
NUMERIC
SERIAL
DATE
I/
3.2. Alcance de la Tesis
El alcance de ia tesis comprende tanto la deijnición y manipulación de dominios simples como
compuestos, así comomtambién el uso de estos en el LMD y LDD del SQL estándar, cumpliendo con
las siguientes caracteksticas:
Definu dominios con restricciones.
Definir y mdpular dominios compuestos.
19
I1
CAP ~ U L O3
PLANTEAMIENTO YANALISIS DEL PROBLEMA
-
Crear columnas en términos de dominios previamente definidos.
-
Veriiicar que se evite comparar columnas definidas sobre dominios diferentes
I/
-
Deñnir sobre un dominio compuesto las operaciones de comparación válidas (=, <>, >, <, >=
11
y ").
-
Eliminar d o k o s simples y compuestos.
Las herramientas utilizadas para realizar el trabajo son las siguientes:
I/
-
Turbo Pascal para Windows versión 1.5 [pAS91].
11
-
Red local de computadoras con el sistema operativo multiusuario Microsoft Windows for
Workgroupsyer. 3.1 1 [MIC93].
I1
3.3. Lenguaje de Defimición de Datos
3.3.1. Dificultades
Resolver en la Creación de Dominios
Como se ha 'hencionado, en el IIE existe un prototipo de SMBDD, que no considera el
manejo de dominios, con lo cual se presentan d~cultadespara la definición de éstos, las cuales se
describen en las siguientes secciones.
3.3.1.1. Dificultades a Resolver en la Creación de Dominios Simples
/I
Uno de los inconvenientes para la definición y uso de dominios simples, es que el
precompilador no reconoce la instrucción para su definición y uso, así como tampoco tiene previsto
r
dónde guardar la infdmación que se genere. Esto crea dos problemas:
1
-
Modificar el pkecompilador en la parte del analizador léxico, sintáctico y semántico, para que
reconozca las instrucciones de definición y manipulación de dominios.
1
2.'
Modificar el Diccionario de Archivos Distribuidos (DAD), para que permita almacenar la
información de los dominios y pueda ser recuperada posteriormente.
3.3.1.2. Dificultades a Resolver en la Creación de Dominios Compuestos
Por principio de cuentas, el estándar SQL no incluye una sintaxis que p d a defuiir dominios
compuestos, por lo cual se tiene que defuiir una gramática para tal efecto.
'1
20
I/
CAPfTlJLO 3
PLANTEAMIENTO Y ANALISIS DEL PROBLEMA
I;
Con respecto a la creación y uso de dominios en el precompilador, éste presenta los mismos
inconvenientes que11en la creación de los dominios simples,
Otra de las dificultades en la creación de los dominios compuestos, es que se pueden presentar
ciclos en su creación. Esto es, que el elemento de un dominio compuesto (x), sea otro dominio
compuesto (y) y éste o un elemento propio referencie a x (io tenga como elemento) o un elemento
de los elementos dey lo haga.
1
Por ejemplo, supongamos que existen el dominio compuesto DATOS con los elementos
Clave
Nombre
I1
I/
y el dominio compuesto CLAVE con los elementos:
Numero
Elemento
11
I1
Eiitonces, se presenta un problema al tratar de crear el dominio compuesto ELEMENTO con 10s
elementos
Nombre
Datos
/
I/
El elemento DATOS del dominio compuesto ELEMENTO a crear, es un dominio compuesto
que tiene como elemento propio a CLAVE, y éste a su vez contiene a ELEMENTO; lo cual, como
se podrá observar crea un ciclo (ver Figura 3.3). Esto trae como consecuencia que al tratar de
eliminar un dominio involucrado, el manejador no lo permitiría ya que para ésto, el dominio no
tendría que estar referido, y si lo está, es porque se hace uso de él y por lo tanto es necesario
I/
mantenerlo para poder accesar sus datos.
11
D#lUrnci
‘I
I/
Figura 3.3. Presentación grafica de un Ciclo.
21
CAPíTULO 3
/I
PLANTEAMIENTO Y AN&SIS
DEL PROBLEMA
3.3.2. Dificultades1 a Resolver en la Defmición de Tablas
Para crear tablas que permitan definir sus columnas con dominios simples y compuestos, hay
1)
que mdicarle al precompilador que las columnas pueden aceptar nuevos tipos de datos Además para
una columna deñnida sobre un dominio compuesto, se necesita asignar el espacio necesario para cada
uno de sus elementos Otro inconveniente con el manejo de los dominios compuestos en columnas
definidas en términos de éstos, es la manipulación de los NULOS, ya que queda ambigua la definición
delvalor nulo en ella @orqueal mdicarle que permita nulos la columna antes mencionada no se sabe
'1
si será sobre todos sus
elementos o sólo sobre algunos), aparte de que actualmente el uso del valor
NULO no ésta bien definido
I/
Por ejemplo, supongamos que la columna Edad con Nombre igual a JOSE de la Figura 2 2
tiene un valor nulo, ninguna de las siguientes comparaciones resulta verdadera.
I1
Edad> 25
Edad <= 25
Edad= 25
Edad025
I/
Esto se debe 'a que las expresiones escalares de cálculo, en las cuales uno de los operandos
es nulo, dan nulo como resultado, y las de comparación, en las cuales uno de los comparandos es
nulo, dan como resultado el valor lógico desconocido PAT93fl.
1)
&o punto a considerar en la creación de tablas, es que no estaba previsto el almacenamiento
de la información relativa al manejo de dominios, lo cual involucra un cambio en la estructura del
DAD, así como la generación del código necesario para realizar tal actividad
Con lo antes kicho al crear la tabla Temper del siguiente ejemplo:
Ejemplo 3.1
II
CREATE TABLE Temper
(PtoGeo
PtoGeo NOT NULL,
Ciudad
Ciudad DEFAULT 'Cuernavaca',
Temper
Temper);
I'
!
la columna compuesta F'toGeo de ésta no deberá permitir valores nulos debido a la cláusula NOT
NULL, el valor por omisión de la columna Ciudad será Cuemavaca, y por Último, la columna
I
Temper podrá aceptar valores nulos ya que no tiene tal restricción.
Se ha dete-do
que una columna definida en base a un dominio compuesto no permita una
cláusula DEFAULT; ya que para asignarle un valor este debe corresponder con el tipo de dato de
la columna, io cual se podrá violar al tener más de un tipo de dato en una c o b a compuesta.
II
I/
22
CAPfTLEO 3
PLANTEAMIENTO Y ANALIS
DEL PROBLEMA
,I
3.3.3. Dificultades a Resolver en la Definición de Índices
11
Primeramente para poder crear índices con columnas deñuidas en base a dominios, tanto
simples como compuestos, bay que indicarle al precompilador que reconozca los nuevos tipos de
datos. Cuando se d e h e un índice en base a una columna deñuida sobre un dominio compuesto, la
creación del mdice debe tomar todos los elementos que integran la columna y no sólo uno como se
bacía anteriormente.I
/I
3.3.4. Dificultades a Resolver en el Borrado de Dominios
Para borrar I& dominio, este no debe ser referido tanto en la definición de una tabla como por
otro dominio (en este caso un dominio compuesto), ya que la existencia de tal hecho, nos indica que
el dominio que se quiere borrar se está utilizando. Por lo tanto sus datos están siendo utilizados y no
se deberá permitir eliminarlo.
1
3.3.5. Dificultades a Resolver en el Mantenimiento de Dominios
I1
Así como se puede crear un dominio en cualquier momento con CREATE DOMAIN,
también se podrá alterar un dominio ya existente, por ejemplo cambiar o eliminar su cláusula
DEFAULT, cambiar o eliminar su cláusula de redcción. Para tal efecto primeramente se tendrá que
indicar el dominio a modificar y validar que exista, posteriormente se deberá verificar que los
cambios a realizar edén permitidos o acordes al dominio @or ejemplo en el caso de incluir el valor
por DEFAULT, que este sea del mismo tipo base que el del dominio), y por Último se necesitará
guardar los cambios realizados
i
3.3.6. Dificultades a Resolver en la Declaración de Variables
Para poder &cenar en forma temporal los valores que se generen durante la manipulación
de las columnas compuestas, deberán existir variables anfitrionas que correspondan al mismo tipo
de dato que las columfias; por lo tanto la mstnicción BEGIN DECLARE SECTION deberá permitir
la deñnición de estas variables. Para tal efecto, bay que indicarle al precompilador que acepte los
nuevos tipos de datos, así como también que se genere el código necesario para postenomente
generar dichas variables
Ai contar con revos tipos de datos para las variables anfitrionas, el DAD debe soportar tales
estructuras y relaciom éstas con las estructuras utilizadas por la cláusula INTO como la instrucción
FETCY en donde las variables anfitrionas son referidas.
!I
23
CAPkULO 3
PLANTEAMIENTO Y ANALISIS
DEL PROBLEMA
I/
3.4. Lenguaje de Manipulación de Datos
3.4.1. Dificultades'h Resolver en la Instrucción INSERT
Para realizar la inserción de un renglón a una tabla específica, se deben proporcionar 10s
valores correspondientes a cada columna de la tabla. Por ejemplo si se desea insertar un nuevo
renglón a la tabla Temper con la siguiente instrucción de SQL
1
Ejemplo 3.2
INSERT INTO TEMPER
'1 VALUES (:PtoGeo, "Mexico", 24);
cada valor específicado debe ser mapeado a su correspondiente campo del registro que representa
a la tabla y llevado :un contenedor (buffer) de memoria.
En el caso de ique la tabla tenga cuando menos una columna o más en donde su tipo de dato
esté definido en base a un dominio, es necesario garantizar la integidad de los datos que se
almacenen en la tabla. Si una columna está definida sobre un dominio compuesto, la verificación de
I
sus valores será elemento por elemento, hasta completar la totalidad de sus elementos, incluyendo
los elementos de sus elementos compuestos; en caso contrario sólo se verificará si el valor a insertar
para tal columna satisface la condición de restricción'del dominio simple sobre la que está definida
I/
Si el valor a insertar es NULL y el campo de la tabla está deñnido en base a un dominio
compuecto, el problema estriba en declarar nulo el campo compuesto como tal o cada elemento que
lo compone Tomemos por ejemplo la misma tabla Temper
I/
Ejemplo 3.3
1
I/
INSERT INTO TEMPER
VALUES (NULL, "Mexico", 24);
¿cómo poder indicarle que el primer valor a insertar en la tabla Temper corresponde a una columna
compuesta?.
I/
3.4.2. Dificultades a IResolver en la Instrucción SELECT
La instrucción que se encarga de realizar la recuperación (selección) de información de la
BDD es el SELECT! Esta instrucción designa una tabla virtual cuyos renglones serán accesibles
dentro de un programa de aplicación mediante el mecanismo de los cursores.
'I
Si por ejemplo, se quiere consultar la tabla Temper, y saber qué Ciudad tiene una temperatura
mayor que 2 5 ; se somete a un proceso de selección el cual regresa un conjunto de renglones que
cumplan la condición ITemper > 25.
I/
24
:!
CAPfTlEO 3
P.MVTEAMIEhT0 Y ANASIS
DEL PROBLEMA
I
para poder utilizar campos definidos sobre dominios en la cláusula WHERE, primeramente
hay que imih& alpreconrpilador, en SU parte del analizador sintáctico y semhtico, que permita los
m~evos@OS de datos. En el caso de que se utilice una columna compuesta 0 al& elemento de ésta,
la comparación entre los datos de la columna compuesta y la variable anfitriona definida en base a
un dominio compuesto para que sea compatible con la columna, debe realizarse en forma
transparente para el programador, y sea el manejador quien tenga que llevar el control en la
comparación (elemento por elemento), a la vez de verificar si el operador relaciona1 en uso está
I/
permitido para el dominio compuesto.
Ejemplo 3.4
I/
SELECT
INTO
FROM
WHERE
I/
PtoGeo.Longitud
:PtoGeo.Longitud
Temper
PtoGeo.Latitud = :PtoGeo.Latitud;
I)
al seleccionarla columna compuesta F'toGeo.Longitud de la tabla Temper implícitamente se definen
todos SUS elementos (PtoGeo.Longhd.Grado y RoGeo.Longhd.Mnuto)para lo cual el manejador
deberá percatarse de la situación a la vez de verificar que las variables anñtrionas donde se
almacenará la información que cumpla la cláusula WHERE sean compatibles, es decir estén definidas
sobre el mismo tipo $e dato.
Otro de los problemas que ocasiona el manejo de columnas compuestas ocurre en la cláusula
WTO, ya que al seleicionar una columna de estas características se le tiene que reservar el espacio
necesario para poder :almacenarlos valores obtenidos en la cláusula de selección; y como se podrá
observar, el tamaño'ta asignar es variable (dependiendo del número y tipo de los elementos del
dominio compuesto). Algo parecido sucede con la instrucción FETCH.
li
Como Pascal no tiene un mecanismo para manejar conjuntos de renglones como un solo
objdo, entonces se debe utilizar el mecanismo de cursores. Un cursor es un mecanismo de SQL cuyo
propósito es recorrerle1 conjunto de renglones que se obtiene de una operación de selección, uno a
la vez. Antes de recorrer el cursor, es necesario mantenerlo en estado abierto para lo cual se usa la
mshicción OPEN. La instrucción FETCH se usa para recuperar información de un cursor en estado
abieao; esta instrucción se ejecuta hasta que se terminan los renglones de la tabla virtual. Una vez
finalizado el recorrido se debe usar la instrucción CLOSE para cerrar el cursor.
il
3.4.3. Duicultades a Resolver en la Instrucción UPDATE
I/
La instrucción UPDATE presenta los mismos problemas que los de la cláusula SELECT al
momento de asignar el espacio requerido en la cláusula SET en el caso de modificar una columna
deíinida en base a & dominio compuesto, a semejanza con la cláusula INTO de la instrucción
SELECT. Por ejemplo, si se desea actualizar la tabla Temper con la siguiente instrucción:
/I
I1
25
I/
CAP h V L O 3
Ejemplo 3.5
PLANTEAMIENTO Y A N A ~ I S I SDEL PROBLEMA
11
:I
UPDATE Temper
SET
PtoGeo = :PtoGeo
WHERE Ciudad ='Cuernavaca';
/I
Al tratar de msertar los nuevos valores presenta los mismos problemas que en la instrucción
INSERT. Además Presenta el mismo inconveniente en la cláusula WHERE, en donde hay que
indicarle al precomigador que permita los nuevos tipos de datos (dominios).
I)
3.4.4. Dificultades a Resolver en la Instrucción DELETE
1
Para suprimir renglones de una tabla es necesario ejecutar una instrucción DELETE de SQL.
Por ejemplo, consideremosla siguiente instrucción de borrado sobre la tabla Temper:
I/
Ejemplo 3.6
1
DELETE FROM Temper
WHERE Ciudad = 'Tampico';
El problemal'es el mismo que se presenta en las instrucciones SELECT y UPDATE en la
cláusula WHERE, para identificar los renglones que cumplan la condición.
I1
Para eliminar un renglón de una tabla, solamente se necesita cambiar a uno el valor del campo
oculto Alta, lo cual borra el registro lógicamente. Cuando existen indices relacionados a la tabla,
éstos se deben a&,
lo que implica que también se debe eliminar del índice el valor de la clave
asociada con el registro a eliminar de la tabla.
26
i!
4
CAPITULO
En este capíttilo se desaiben las estructuras y métodos utilizados para definir y manipular los
dominios simples y dominios compuestos, así como la gramática propuesta para definir y borrar los
dominios compuestos. También se presenta la sohción para usar los dominios en cada una de las
instrucciones del lenbaje SQL soportadas por SiMBaDD.
Para explicar,cada una de las instrucciones, se presenta un ejemplo. En el se incluyen los
aspectos más sobresalientes de la instrucción.
4.1. Alternativas para la Implemeotaeión de Dominios Compuestos
Para poder utilizar columnas definidas en términos de dominios compuestos en forma normal
en el lenguaje de manipulación de datos (LMD), se analizaron dos posibles soluciones, que se
describen a continuackón.
Para cada elemento del dominio compuesto a usar, se utilizaría un campo de la estructura
TRegTabla del dicciondo de datos, la cual se demiirá m á s adelante . El uso de un campo por cada
elemento, es con el fin de utilizar la estructura ya existente, dado que cada elemento del dominio
compuesto es como si'fuera una columna normal Esto tiene la ventaja de que evita tener que cambiar
tanto las estructuras base que se tienen, así como también el de tener toda la información de la
columna compuesta en una cola estructura. Por ejemplo, para guardar la columna PtoGeo de la tabla
Temper deñnida sobre el dominio compuesto PtoGeo, la estructura de TRegTabla quedaría de la
forma que se muestra en la Tabla 4.1.
En cuanto al almacenamiento de los valores nulos se propuso manejarlos de igual forma, es
decir un campo para cada elemento de la columna compuesta y otro para la columna del valor NULL,
con lo cual el usuario podrá operar los valores NüLL tanto en forma individual (por cada elemento)
como grupa1 (por columna compuesta).
27
CAPíTuLO 4
METODOLOGh DE SOLUCidN
I1
PtoGeo
PtoGeo
I/ Latitud
PtoGeo
Grado
RoGeo
Minuto
PtoGeo
Longitud
PtoGeo
PtoGeo
Grado
Minuto
,) Tabla 4.1. Representación de PtoGeo en TRegTabla,
Campo por Elemento.
La otra opdión, es la de usar un campo de TRegTabla por cada dominio compuesto,
quedando la información a utilizar para la manipulación de los datos de la columna en el archivo de
los dominios compuestos, y sería como se muestra en la Tabla 4.2.
PtoGeo
Tabla 4.2. Representación de PtoGeo TRegTabla,
Campo por Dominio Compuesto.
I/
Esta Ú l h a opción tiene la desventaja de que, al momento de manipnlar los datos de la tabla,
se tiene que ir a buscar la información concerniente a los dominios, a su estructura correspondiente.
Esto implica abrir otra archivo y realizar la búsqueda de los elementos del dominio compuesto para
conocer entre otros datos, la posición del elemento dentro del registro de la tabla, su tipo base,
tamaño, y si está dado de alta, lo que propicia realizar más operaciones y por consiguiente un mayor
tiempo de respuesta. En caso de que se quisiera tener toda ésta información en la estmctura de
TRegTabla, se tendría que cambiar completamente su estructura así como también otras estructuras
auxiliares y efectuar un cambio si no completo por lo menos en la gran mayoría de los
procedimientos y funciones del SiMBaDD que permiten generar el código equivalente a las
instrucciones de SQL. La ventaja de esta opción es la de tener todos los elementos del dominio
compuesto en un solo campo.
I/
'I
Debido a los inconvenientes de la Última opción se eligió la primera: para cada elemento del
dominio compuesto usar un campo de la estructura TRegTabla.
I/
4.2. Gramática paraI/ la Definición de Dominios
4.2.1. Gramática para la Defmición de Dominios Simples
I/
El SQL estándar (SQL92) soporta la definición de dominios simples. La gramática está
basada en la notación Backus-Naur-Form (BNF), y se implementó en el analizador sintáctico y
semántico delpreco&ilador del SiMBaDD, el cual usa el método de traducción dirigido porsintaxis
[ARE92].
La gramática para el uso de los dominios se muestra a continuación:
11
28
/
CAPiTULO 4
METODOLOGh DE SOLUCIdN
I/
4.2.1.1. CREATE DO-
La sintaxis de la gramática para la definición de dominios simples es la siguiente:
- Defmición de un Dominio Simple
II
Función.- Permite definir un dominio simple.
I1
<Instrucción de definición de dominio simple>::=
CREATE DOMAIN <Identificador> [AS] q i p o de dato>
[<Cláusula default>]
[<Restricción de dominio>];
11
-Tipo de Dato
¡
Función.- EspeciGca un tipo de dato.
i
q i p o de dato>::=
CHAR [(<Valor numérico>)] I
NUMERIC [(<Valor numérico> [,<Valor numérico>])]
DECIMAL [(<Valor numérico> [,<Valor numérico>])]
INTEGER 1 'I
SMALLFLOAT I
FLOAT
1
I
I
I/
- Cláusula
Default
'I
Función.- Especfica un valor por omisión para una definición de columna.
<Cláusula default>::= DEFAULT <Valor por omisión>
!I
- Valor por Omisión
Función.- Especifica un valor para la cláusula default.
<Valor por omisión>::= <Literal>
¡I
- Restricción
.
I NULL
de Dominio
Función.- Especifica el conjunto de valores permitidos para el dominio.
4
29
II
CAPfTVLO 4
METODOLOGfA DE SOLUCIdN
I/
<Restricción de dominio>::= CHECK (<Condición de restricción>)
I/
- Condición de Restricción
I/
Función.- Permite definir los valores que contendrá una columna o dominio.
11
<Condición de restricción>::=
<Término booleano> I <Término booleano> AND <Condición de restricción> I
<Término booleano> OR <Condición de restricción>
Con la gramática antes expuesta (lo cual da solución al punto 3.3.1.1), se puede crear el
dominio Gradocon la siguiente instrucción:
Ejemplo 4.1
,I
CREATE DOMAIN Grado INTEGER
DEFAULT 1
CHECK(Grado >= O AND Grado <= 179);
Una vez creado el dominio simple Grado, el rango de valores que permitiría senan valores
de tipo entero iguaiek o mayores a O y menores o iguales a 179 acorde a su cláusula de restricción
que restringe los postiles valores que puede tomar un grado (en un punto geográfico); y el valor por
omisión del dominio sería 1.
I(
4.2.1.2. ALTER DOMAIN
A continuación
se presenta la gramática de la instrucción para modificar un dominio shple
,I
(lo cual da solución ai punto 3.3.5).
I
II
-Modificación de Definición de Dominio
il
Función.- Permite modificar la definición de un dominio.
<InstrucciÓnlde modificación de dominio>::=
ALTER DOMAIN <Ideutificador> <Acción de modificación de dominio>;
- Acción
de Modificación de Dominio
Función.- Permite especificar la acción de modificación de un dominio
I/
ME TO DO LOG^ DE S O L U C I ~ N
CAPfTULO 4
<Acción de'modifcación de dominio>::=
<Adición de la cláusula default> I
<Eliminacioh de la cláusula default> I
<Adición de la definición de restricción del dominio> I
<Eliminación de la definición de restriccióu del dominio>
I/
- Adición de la Cláusula Default
Función.- h a d e la cláusula default a un dominio.
<Adición de la cláusula defaulV::= SET <Cláusula default>
I
-Eliminación de la Cláusula Default
'1
Función.- Elimina la cláusula default de un dominio.
I/
<Eliminación de la cláusula default>::= DROP DEFAULT
I/
- Adición de la Cláusula de Restricción
/I
Función.- Añade la cláusula de restricción a un dominio.
I/
<Adición de la definición de restricción del dominio>::=
ADD <Restricción de dominio>
.I
- Eliminación de la Cláusula de Restricción
Función.- Elimina la cláusula de restricción de un dominio
<Eliminación de la definición de restricción del dominio>::=
DROP CONSTRAINT <Identificador>
Para ejempqcar el uso de la instrucción ALTER DOMAIN, supongamos que se desea
e l i a r la cláusula DEFAULT del dominio Grado. Esto se puede hacer con la siguiente instncción:
Ejemplo 4.2
1
ALTER DOMAJN Grado DROP DEFAULT;
31
/I
/I
CAPfTULO 4
METODOLOGIÁ DE SOLUCi6N
\
4.2.1.3.DROP DOMAIN
La sintaxis de la instrucción para dar de baja un dominio simple es la siguiente
I
- Eliminación de un Dominio
1
Función.- Pamite eliminar un dominio
<Instrucción de eliminación de dominio>::= DROP DOMAIN <Identihador>,
Lo sintaxis ahtes expuesta permite dar solución al punto 3 3.4
4.2.2. Gramática para
la Defmición de Dominios Compuestos
II
Ya que en e! estándar de SQL no se incluye una sintaxis que permita definir dominios
compuestos, se desarrolló una extensión a la norma del SQL, especificamente al LDD para deñnir
dominios compuestos
La gramática está basada en la notación Backus-Naur-Form (BNF), y se implementó con el
analizador sintáctico y semántico del precompilador del SiMBaDD, el cual como ya se ha
mencionado, usa el método de traducción dirigido por sintaxis.
Las extensiohes realizadas tuvieron como objetivo permitir la creación de dominios
compuestos, para operar con éstos (tipos de datos) en forma normal También fue necesaiio
implementar la instruhción que permite borrar los dominios compuestos.
4.2.2.1.CREATE COMPOUND DOMAIN
En esta sección se presenta la sintaxis de la gramática para la definición de dominios
compuestos, que da solución alpunto 3.3.1.2.
- Definición de un Dominio Compuesto
Función.- Pefmite definir un dominio compuesto.
I(
<Instrucción de defmición de dominio compuesto>::=
CREATE COiyíPOUND DOMAIN <Identiñcador>
(<Elemento de dominio compuesto>
[(,<Elemento de dominio compuesto>) ...I
[<Cláusula de operadores permitidos>]);
32
I1
I/
I/
I/
METODOLOGh DE SOLUCl6N
CAPÍTULO 4
,I
- Elemento de Dominio Compuesto
I/
Función.- Especifica un elemento del dominio compuesto
I/
<Elemento lde dominio compuesto>::=
<Identificador de elemento> <Identificador de dominio>
I/
I/
- Identificador de Elemento
I/
Función.- Especifica un elemento del dominio compuesto
1
<Identificador de elemento>::= <Identificador>
I/
- Identificador de Dominio
Función.- Especifica el tipo de dato de un dominio simple o un dominio compuesto
<Identificad& de dominio>::=
<Identificador de dominio simple>
I <Identificador de dominio compuesto>
- Cláusula de Operabores Permitidos
I/
Función.- Especifica los operadores relacionales permitidos.
I/
<Cláusula de operadores permitidos>::=
OPERATORS (<Lista de operadores permitidos>)
I/
- Lista de Operadores Permitidos
t
Función.- Permite definir los operadores relacionales permitidos
I/
<Lista de operadores permitidos>::=
<Operador de comparación>
[{,<Operador de comparación>}...I
Con la gramática extendida se puede crear un dominio compuesto PtoGeo que tenga como
elementos Latitud y Longitud, los que serían a su vez otros dominios compuestos. Suponiendo que
éstos ya estuvieran creados, la instrucción para crear F’toGeo sería la siguiente:
CAP~TULO4
Ejemplo 4.3
METODOLOGiA DE SOLUCl6N
/I
CREATE COMPOUND DOMAIN PtoGeo
(Latitud
Latitud,
Longitud
Longitud);
4.2.2.2.DROP
1
COMPOUND DOMAIN
La instmcción para dar de baja un dominio compuesto, se da a continuación:
- Eliminación de un Dominio Compuesto
I1
Función.- Permite eliminar un dominio compuesto.
<Instrucción de eliminación de dominio compuesto>::=
DROP COMPOUND DOMAIN <Identi€tcador>;
Para born4 un dominio compuesto, con la gramática extendida que se tiene, se usana la
siguiente instrucción (que da solución ai punto 3.3.4):
Ejemplo 4.4
DROP COMPOUND DOMAIN PtoGeo;
(
I(
4.3. Gramática para la Definición de Tablas e hdices
4.3.1. CREATE TABLE
La instrucción para crear una tabla se da a continuación:
-Definición de Tabla
Función.- Permite defiuir una tabla base.
<Definición de tabla>::=
CREATE ThBLE <Identificador>
<Lista de elementos de tabla>;
-Lista de Elementos de Tabla
Función.- Define los elementos de una tabla.
1
34
I
I!
CAPiTULO 4
ME TO DO LOG^ DE S O L U C ~ ~ N
I
<Lista de elementos de tabla>::= (<Elemento de tabla> [{,<Elemento de tabla>}...])
- Elemento de Tabla
/I
Función.- Define una columna o una restricción de una tabla.
<Elemento de tabla>::=
<DefiniCiÓn de columna>
I <Definición de restricción de tabla>
Y
- DefmiciÓn de Columna
Función.- Define una columna de una tabla.
II
<Definición de columna>::=
<Identificador de columna> {<Tipo de dato> I <Identificador de dominio>}
[<Cláudla default>]
[<Definikión de restricción de columna>]
- Definición deI/Restricción de Columna
Función.- Especifica restricciones a una columna.
1
<Restricción de columna>::=
[<Definición de nombre de restricción>]
<Restricción de columna>
/I
- Restricción de Columna
I1
Función.- Especifica restricciones de unicidad, referencia1 y veriñcación a una columna.
<Restricción de columna>::= NOT NULL I
[<Espe&caciÓn de unicidad>] I
<Especificación referemial> I
<Verificación de la definición de restricción>
I/
-Especificación de Unicidad
il
Función.- Especifica valores únicos para una columna.
i/
35
CAP~TULO4
‘1
METODOLOG~A
DE S O L U C I ~ N
<Especificación de unicidad>::= UNIQUE I PRIMARY KEY
I1
- Definición de Restricción de Tabla
Función.- Especifica una restricción de integridad.
It
<Restri¿ciÓn de tabla>::=
<Definición de restricción de unicidad> 1
<Definición de restricción referemial> I
<Verificación de la definición de restricción>
1
-Definición de Restricción de Unicidad
Función.- Especifica valores únicos para una o varias columnas.
11
<Restricción de unicidad>::=
<Especificación de unicidad> (<Lista de columnas de unicidad>)
I
- Lista de Columnas
de Unicidad
Función.- Establece los identificadores de columnas que contendrán valores únicos.
<Lista be columnas de unicidad>::= <Identificador> [{ ,<Identificador>}...]
- Definición de Restricción Referencial
Funciób.- Especifica los identificadores de columnas que referencian a otras en otra tabla.
<Restricción referential>::=
FOREING KEY (<Columnas referidaQ) *Especificación
referemial>
- Especificación Referencial
Función.- Especifica valores únicos para una o varias columnas.
II
<Especificación referential>::= REFERENCES <Columnas y tabla referidae
36
METODOLDG~
DE SOLUCldN
CAP~TULO4
I
- Columnas Referidas
Función.- Establece los identificadores de columnas que referenciaran a otras
I1
<Columnas referidas>::= <Lista de columnas referida9
- Columnas y Tabla Referidas
Función.- Especifica la tabla y los identificadores de columnas que son referidas
<Columnas y tabla referidas>::=
<Identificador de tabla> [(<Lista de columnas referidas>)]
- Lista de Columnas Referidas
Función.- Establece los identificadores de columnas referidas
<Lista de columnas referidas>::= <Identiñcador> [{,<Iden&cador>}
m
i
...I
- Verificación de la Defuición de Restricción
1
Función.- Especifica una condición para una tabla.
<Verificación de la defmición de restricción>::= CHECK (<Condición de restricción>)
li
Por ejemplo, la tabla Temper con los campos PtoGeo definido sobre u11 dominio compuesto,
Ciudad y Temper ambos deíinidos sobre dominios simples se puede crear con la siguiente instmcción
(que da solución alpunto 3.3.2):
I1
Ejemplo 4.5
I!
CREATE TABLE Temper
(PtoGeo
PtoGeo,
Ciudad
Ciudad,
Temper
Temper);
37
ME TO DO LOG^^ DE ~ O L ü C l b N
CAPfTULO 4
u
4.3.2.CREATE INDEX
La instrucción para crear un índice a una tabla es
II
- Definición de índice
Función.- Permite definir un índice a una tabla
I1
<DefmiciÓn de índice>::=
CREATE W Q U E ] INDEX <Identiñcador> ON <Identiñcador de Tabla>
(<Identiñcador de columna> [{,<Identiñcador de columna>}.. .] );
I)
Por ejemplo, para crearle un índice a la tabla Temper del Ejemplo 3.1, seria con la siguiente
instrucción (que da solución alpunto 3.3.3):
Ejemplo 4.6
'
CREATE INDEX TernLong ON
Temper (PtoGeo.Longitud);
4.4. Diccionario de Datos
El diccionario de archivos distribuidos (DAD) constituye una de las estructuras mas
importantes qde usa el sistema manejador de bases de datos distribuidas (SiMBaDD). El DAD
contiene hformación acerca de las tablas y de los dominios de la BDD. Esta información es utilizada
por los programas de aplicación y gracias a ella se logra la transparencia de localización y la
manipulación de dominios.
'I
Anteriormente la estructura con la que contaba el DAD, proporcionaba toda la información
referente a la estructura y características de las tablas y a la localización de éstas.
11
La estructura
del diccionario de tablas es la signiente:
TRegTabla=RECORD
NombreT:
íTipoT:
ActivaT:
LongT:
TotalCols:
ITotalIndsT:
PrimKey:
ColsT:
IndsT:
END; ''
STRING[ 121;
CHAR;
BOOLEAN;
INTEGER,
1..MaxCols;
O..MaxIndices;
ARRAY[l ...MaxCols] OF BYTE;
ARRAY[l ...MaxCols] OF TColumna;
ARRAY[l ...Maxindices] OF TIndice;
38
I
I
ME TO DO LOG^ D E S O L U C I ~ N
CAPITULO
4
donde
NombreT
Es el nombre de la tabla con la extensión “.BDI”.
TipoT
Es el tipo de tabla la cual puede ser “B” si se trata de una tabla base o una “V“ si se
trata de una vista.
ActivaT
Indica si la tabla está dada de alta en el archivo o no.
LongT
jontiene la longitud de la tabla en bytes, dependiendo del número y tipo de dato de
las columnas de la misma.
TotalColsT
Número de columnas que tiene definida una tabla.
‘I
TotalIndsT
Número de índices que tiene definidos una tabla.
PrimKey
Indica si la tabla tiene definida alguna llave primaria
ColsT
Arreglo que contiene para cada elemento, la información para cada una de las
columnas de la tabla.
LodT
p e g l o que contiene para cada elemento, la información para cada uno de los índices
de la tabla.
A conhnación se describen los tipos de registro asociados (TColumna y Tindice) que se usan
en TRegTabla. 11
TColumna=RECORD
NombreC:
STRlNG[12];
TipoC:
TipoColumna;
hctivac:
BOOLEAN;
LongC:
INTEGER,
DesplazaC: INTEGER;
NuloC:
BOOLEAN;
END;
‘I
NombreC
Contiene el nombre de la columna
TipoC
Contiene el tipo de dato de la columna: integer, longint, real, o string.
ActivaC
Indica si la columna ésta dada de alta en la tabla o no.
LongC
IContiene la longitud de la columna en bytes, dependiendo del tipo de dato de la
misma.
39
‘I
..
I/
ME TO DO LOG^^ DE SoLUCIdN
CA PfTULO 4
DesplazaC
Posición donde se encuentra la columna a partir del inicio del contenedor para
thsferencia entre variables anfirionas y disco.
NdoC
indica si la columna acepta valores nulos
TIndice=pCOm
NombreInd:
ActiVoI:
LongLlaveInd:
TotalColsInd:
ColsInd:
END;
STRiNq 121;
BOOLEAN;
INTEGER;
l..MaxCols;
ARRAY[l..MaxCols] OF BYTE;
NombreInd
Nombre del archivo asociado con el índice con extensión ".IDX".
Activo1
Indica si el índice ésta dado de alta en la tabla o no.
LongLlaveInd 'I
Contiene la longitud en bytes de la iiave del índice
TotalColsInd
Número de columnas que participan en el índice.
I!
Colsind
Contiene los números de las columnas sobre las que está definido el índice.
4.4.1. Actualización del Diccionario de Tablas
11
Alinicio de la tesis, como se contaba para la definición de columnas sólo con los tipos base
(integer, longint, real, o string) que proporcionaba el SiMBaDD, el campo TipoC de TColumna, que
guarda el tipo de dato de la columna, era de tipo byte. Este campo fue cambiado a integer, lo cual
nos permite un'bayor rango de valores a utilizar (de -32,768 a 32767).
El tener tipos de datos definidos por el usuario, obliga a tener un recipiente más allá del rango
de O a 255 (que proporciona el tipo byte), para poder almacenar el tipo de dato.
I/
4.4.2. Estructura de los Diccionarios de Dominios
Para usar los dominios simples como compuestos en el prototipo se necesitó crear dos
archivos: el a r h v o para guardar la información generada al crear un dominio simple y el archivo
que almacenaría la información proporcionada del dominio compuesto a crear.
La razón de crear dos archivos se debió a que guardarían información diferente. Por ejemplo,
para el dominio!simple básicamente se necesita guardar su nombre, número de dominio simple, tipo
40
I/
ME TO DO LOG^ DE SOLUCl6N
CAPfTULO 4
base y su restricción (valores permitidos); mientras que para el dominio compuesto los datos a
guardar son su !ombre, número de dominio compuesto, número de elementos, un arreglo que
contenga cierta información de sus elementos y operadores permitidos. Por lo tanto, necesitaban
diferente recipiente para almacenar tal información. A continuación se describen ambos archivos.
La estructura asociada con los registros del diccionario de dominios simples es la siguiente:
'1
TRegDom=RECORD
NombreD:
TipoD:
TipoB:
ActivoD:
RestriccionD:
RestPosíD:
END;
/I
STRING[8];
INTEGER,
INTEGER,
BOOLEAN;
STRING,
STRING;
donde
NombreD
Es el nombre del dominio simple.
I/
TipoD
Indica el número de dominio simple.
TipoB
Tipo base del dominio simple: integer, longht, real, o string
I1
ActivoD
Indica si el dominio simple está dado de alta en el archivo.
RestriccionD Contiene la condición de restricción del dominio simple.
1
RestPosíD
Contiene la cláusula de restricción en la forma posfija.
11
La estructura
asociada con los registros del diccionario de dominios compuestos es la
1
siguiente:
TRegDomC=RECORD
NombreDC:
hpoDC:
NumDoms:
ActivoDC:
Doms:
'I
,OpersPerm:
END;
STRING[8];
..
INTEGER;
INTEGER;
BOOLEAN;
ARRAY[l..MaxDoms] OF DatDom;
ARRAY[l..ó] OF BYTE;
donde
41
'I
CAPíTULO 4
METODOLOGíA DE SOLUCIbN
Es el nombre del dominio compuesto.
NombreDC
TipoDC
"
Indica el número del dominio compuesto.
Indica el número de elementos del dominio compuesto.
NumDoms
ActivoDC
,I
Indica si el dominio compuesto está dado de alta en el archivo.
Arreglo que contiene para cada campo, la información para cada uno de los
elementos del dominio compuesto.
Doms
1
OpersPerm
Arreglo que contiene íos operadores permitidos para las operaciones sobre las
columnas definidas en términos de él.
A continuación se describe el tipo de registro asociado DatDom que se usa en TRegDomC:
I/
DatDom=FWCORD
NombreD:
STRING[8];
TipoD:
INTEGER,
END; 1
donde
NombreD
Contiene el nombre del elemento.
TipoD
Contiene el @ o de dato del elemento (base, dominio simple o dominio compuesto).
'1
La fo$a como quedaría representada la información de los dominios simples una vez
creados, sena como se muestra en la Tabla 4.3.
Nombre$
TipoD
TipoB
ActivoD
RestriccionD
RestPosfD
GRADO
11
INTEGER(3)
G-OrO-
GRADO o >E
GRADO 179 <-AND
MINUTO
12
INTEGER(3)
M m > - O
ANDMmVm<-39
n l m m o >=
-no''
CIUDAD 9, o
GRADO <- 179
M m w m 5 9 0 m
!
CIUDAD
13
CHAR(20) (1)
TRUE
Tabla'(4.3.Representación de Dominios Simples en la Estructura TRegDom.
42
METODOLOGíA DE SOLUCIbN
CAPÍTULO 4
Tabla 4.4. Representación de Dominios Compuestos en la Estructura TRegDomC.
i/
La representación de la información de los dominios compuestos una vez creados sena como
se muestra en la Tabla 4.4.
4.5. Instrucción BEGIN DECLARE SECTION
Con la instrucción BEGIN DECLARE SECTION se le indica al precompilador que se crearán
variables aníitrihas que nos permitan transfeiir datos a/desde las columnas de las tablas.
La actualización de la rutina que se tenía para realizar el reconocimiento de las variables
anfitnonas (que :;da solución al punto 3.3.6), fue para que permitiera el uso de tipos definidos por el
usuario (dominios). Concretamente, si el identiñcador del tipo de dato de la variable no es un tipo
base, debe verificar si es un dominio simple o un dominio compuesto. Por ejemplo, para tener como
variables aníitrionas a PtoGeo (deñnida en base a un dominio compuesto), Ciudad y Temper
(definidas sobre:sus respectivos dominios simples) para manejar los datos de la tabla Temper, seria
de la siguiente forma:
Ejemplo 4.7
11
BEGIN DECLARE SECTION
PtoGeo: PtoGeo;
Ciudad: Ciudad;
Temper: Temper;
END DECLARE SECTION
Para realizar la búsqueda de dominios se utiliza el DAD, especificamente el diccionario de dominios
(descrito en la Sección 4.4.2) en donde se localiza la información referente a elios.
II
Con las variables d o n a s antes descritas se contará con los recipientes apropiados al tener
el mismo tipo de dato que las columnas de la tabla Temper; siendo ésto necesario para guardar la
información de,la cláusula INTO o de la instrucción FETCH.
43
METODOLOG& DE SOLUCl6N
CAPfTULO 4
1
4.6. Instrucción INSERT
Cuando se inserta un registro a una tabla, primeramente se debe venñcar si existe cuando
menos una c o l d h a definida en base a un dominio; si es así, el valor de la columna a insertar se
t
deberá comparar con la condición de restricción del dominio, para saber si la cumple. Si todo esta
bien, el registro se inserta en la tabla.
En el caso de insertar valores nulos en columnas compuestas de manera explícita, se deberán
'I
indicar todos los elementos que contiene dicha columna. Por ejemplo, supongamos que se inserte un
renglón en la tabla Temper donde PtoGeo se desconozca y sólo se tenga como datos de entrada el
nombre de la ciudad y su temperatura, la instrucción para insertar la tupla será la siguiente:
Ejemplo 4.8
INSERT INTO TEMPER (PtoGeo, Ciudad, Temper)
VALUES (NUU, NULL, NULL, NULL,"Mexico", 24);
en donde se ddica explícitamente que los valores de los elementos PtoGeo.Latitud.Grado,
PtoGeo.Latitud.Minuto, PtoGeo.Longitud.Grado y PtoGeo.Longitud.Mo son nulos. Otra
altemativa permite especificar una lista de las columnas que contendrán los datos suministrados y por
ende las demás, al no estar incluídas en la lista, tomarán el valor nulo (si es que la columna lo
permite), teuiendo los mismos resultados que la instrucción anterior (lo que permite dar solución al
punto 3.4.1). En este caso la instrucción será
Ejemplo 4.9
'I
INSERT INTO TEMPER (Ciudad, Temper)
VALUES ("Mexico", 24);
Cuando ,seinserte un renglón omitiendo el valor de una columna, el manejador veriiica si en
su declaración (de la columna) tiene la cláusula DEFAULT; en caso afirmativo reemplazará el valor
omitido por el del default; en caso contrario tomará el del dominio si es que lo tiene defuiido.
4.7. Instrucción SELECT
La instrucción SELECT se encarga de recuperar un conjunto de renglones o un renglón de
una tabla. Cuando se desea recuperar varios renglones de una tabla (o que se pudieran generar), se
utiliza la instrucción BEGIN DECLARE CURSOR En el caso de que se quiera recuperar un solo
renglón se uti& la mstnicción SELECT, cuando se sabe que con la condición de búsqueda (cláusula
WHERE) sólo se obtendrá un renglón. Por ejemplo, al buscar un elemento sobre una columna a la
cual se le ha deñnido un mdice Sm duplicados o tenga una llave primaria, el resultado de tal operación
siempre será de que encuentre solo un renglón o ninguno.
I/
!!
44
ME TO DO LOG^ DE SOLUCi6N
CAPíTUU) 4
'1
En caso de que en una operación de consulta se desee que aparezcan una o mas columnas
compuestas, el precompilador deberá tomar automáticamente todos los elementos que pertenezcan
a estas columnas, definidas en base a un dominio compuesto, de tal manera que el LMD quede
intacto, y pueda)trabajarse de una manera normal. Opcionalmente el programador podrá indicar
explícitamente los elementos de una columna compuesta.
Por ejemplo, si tenemos la siguiente consulta,
1
Ejemplo 4.10
1
SELECT
FROM
WHERE
PtoGeo.Latitud
Temper
Ciudad ='Mexico';
generará como lpiida un registro con dos campos: Grado y Minuto que son los elementos del
dominio compuesto Latitud. El mismo resultado se puede conseguir con la siguiente consulta:
Ejemplo 4.11
I1
SELECT
FROM
WHERE
PtoGeo.Latitud.Grado, PTOGEO.LATITUD.MINUTO
Temper
Ciudad ='Mexico';
,I
donde se indica explícitamente los elementos deseados de una columna compuesta.
Algo pTecido sucede con la cláusula WHERE, ya que al incluir en la condición de búsqueda
una columna definida en base a un dominio compuesto, es como si eligiera cada uno de los elementos
de la columna compuesta Por ejemplo,
Ejemplo 4.12
'1
SELECT
FROM
WHERE
Ciudad
Temper
PuntoGeo.Longitud = :PtoGeo.Longitud;
I/
sena equivalente a la siguiente instrucción:
Ejemplo 4.13
I/
SELECT
FROM
WHERE
Ciudad
Temper
PtoGeo.Longitud.Grado = :PtoGeo.Longitud.Grado
AND PtoGeo.Lougitud.Minuto = :PtoGeo.Longitud.Minuto;
45
ME TO DO LOG^ DE S O L U C I ~ N
CAPfTULO 4
'1
En el caso de la instrucción BEGIN DECLARE CURSOR, se debe utilizar junto con ia
instrucción FETCY la cual permite leer renglón por renglón del archivo temporal que se genera con
tal instrucción. La forma de solucionar este problema es la misma que se utiliza en las cláusulas
SELECT y WHERE.
Para saber si el(1os) operador(es) relacional(es) que contiene(n) la condición de búsqueda,
en la cual intervienen columnas compuestas, es(s) válido(s), se deberá consultar si el dominio
compuesto lo(s) hermite, y es en el DAD donde se tiene tal información (con lo cual se da solución
alpunto 3.4.2).
1
4.8. Instrucción UPDATE
Para modiíicar los datos de una tabla se utiliza la instrucción UPDATE, con la cual se
actualizan los renglones que cumplan la condición de búsqueda. Los nuevos valores se tratan igual
que en la mstru&ón INSERT, esto es, si algún campo está definido en base a un dominio, se verifica
que cumpla su condición de restricción (con lo cual se da solución al punto 3.4.3). Con la cláusula
WHERE, sucede lo mismo que en la instrucción SELECT .
II
4.9. Instrucción DELETE
La inst&cción DELETE tiene como función suprimir los renglones de una tabla que
satisfagan la cláusula de selección. La sintaxis se mostró en la Sección 3.4.4. El cambio realizado
para permitir el uso de dominios en la cláusula WHERE, es el mismo que en las instrucciones
SELECT y UPDATE.
II
El borrado de un renglón es lógico; es decir, se cambia solamente el indicador de activo a
falso. Cuando se hace el borrado del rengión esnecesario actualizar ei(1os) índice(s) de la tabla. Esta
actualización se logra borrando del índice la clave relacionada con el renglón borrado de la tabla (10
que permite da? solución al punto 3.4.4).
46
En este capítuio se muestran de manera detallada algunos de los procedimientos y funciones
más importantes desarrollados para la definición y manipulación de dominios. Así como también para
su uso en cada h a de las instmcciones del lenguaje SQL soportadas por el SiMBaDD.
Para la explicación de cada una de las instrucciones se presenta un ejemplo tratando de
abarcar en él los aspectos más sobresalientes de la instrucción.
5.1. Transporte del SiMBaDD del Ambiente DOS a Windows
5.1.1. Motivos
La razón principal para el cambio de plataforma del SiMBaDD del sistema operativo MSDOS al sistema operativo Microsoft Windows fue la necesidad de utilizar una mayor cantidad de
i
memoria. El desarrollo del presente trabajo repercutiría en un aumento en las necesidades de las
variables globales del prototipo, lo cual provocaría que éste no funcionara, debido a que la versión
anterior del prototipo trabajaba en el b i t e de la memoria.
5.1.2. Cambios Realizados
Para que funcionara el prototipo para el sistema operativo MS-DOS en el sistema operativo
Microsoft Windows, primeramente se pasaron las variables locales de tipo DateTime a TDateTime
así como también FileRec y Registers a TFileRec y TRegisters respectivamente, ya que son los tipos
correspondientes en el entomo Windows. Lo mismo sucedió con las unidades Cri y DOS reconocidas
bajo el ambieFte MS-DOS, las cuales fueron cambiadas por WinCrt y WinDOS. Las funciones
TextColor, Sound, Delay, Window, TextBackGround, Newwindow, LowVideo ya no heron
utilizadas bajo el ambiente Windows.
47
I/
IMPLEMENTACI~N
CAP~TULO5
Uno de los cambios importantes fue pasar ciertas variables globales estáticas a hamicas.
Esto repercutió'len el manejo de las mismas en el prototipo, lo que condujo a cambiar las
instrucciones en las cuales se hace referencia.
La unidades SQL, DDL y Ger-Cod del prototipo se subdívidieron para una mejor ejecución
1)
al estar las rutinas mejor reagrupadas, es decir, colocando en un solo módulo las rutinas para cierto
trabajo en específico, lo cual facilita su ejecución al cargarse (en memoria) sólo las rutinas que se
utilizaran en ese momento. Además los atributos por omisión de un segmento de código son
MOVEABLE, PIELOAD, DISCARDABLE, los cuales se cambiaron con la directiva al compilador
{%CMOVEABLE, DEMANLOAD, DISCARDABLE} para un mejor aprovechamiento de la
memoria y por consecuencia del desempeño.
I1
5.2. Implementación del Diccionario de Datos
El DADjuega un papel muy importante dentro de los SMBDDs. Con respecto al SiMBaDD,
el DAD prove&. facilidades de directorio a un nivel más orientado al usuario que los sistemas
manejadores de archivos, y aíslan al usuario de lo intrincado del almacenamiento fisico. El DAD
contiene información acerca de las tablas y de los dominios de la BDD. Los programas de aplicación
usan esta información y gracias a ello se logra la transparencia de localización. La estructura del
DAD puede en/ontrarse en las Secciones 4.4 y 4.4.2.
5.2.1. Actualización del Diccionario de Archivos Distribuidos (DAD)
I1
Como se comentó en el capítulo anterior, la modificación del DAD se efectuó en el campo
TipoC de la estructura de TRegTabla, que permite saber el tipo de dato de una columna para
detenninada tabla. Para tal efecto se cambió de tipo byte a integer la declaración de tal campo.
I1
Para asignarle el tipo de dato a una columna, sólo se contaba anteriormente en el SiMBaDD
con los tipos base (integer, longht, real, o string), lo cual permitía definir a TipoC de tipo byte; esto
con el fin de reducir al mínimo el tamaño asignado a las variables usadas por el prototipo. Pero, al
1)
incluir los tipos definidos por el usuario (los dominios), el rango que soporta el tipo byte, no era
suficiente para incluir tales tipos.
5.2.2. Anexiónldel Archivo de Dominios en el DAD
Se anexaron los archivos TRegDom y TRegDomC (descritos en la Sección 4.4.2), para llevar
el control de los dominios simples y compuestos respectivamente. La forma como se maneja el DAD
es la siguiente: m
1.-
Por cada máquina de la red se tiene una parte del DAD, cada parte está compuesta por tres
archivos: TRegTabla, TRegDom y TRegDomC.
'I
48
IMPLEMENTACI~N
CAPíTULO 5
!I
2.-
Por cada tabla que paticipa en la base de datos, se utiliza un registro del archivo TRegTabla
para almacenar la definición de la tabla y la localización de ésta.
3-
Por cada1 dominio definido, simple o compuesto, se emplea un registro de TRegDom O
TRegDomC, dependiendo del caso, para almacenar la definición del dominio y su
localización.
I1
1
Una vez dado de alta un dominio en el DAD, se puede hacer uso de él por nombre, pero para
facilitar su manipulación, internamente se obtiene del DAD su número (tipo) correspondiente.
:!
5.3. Implemen&ción de Dominios
5.3.1. Creación de Dominios Simples
I/
Si se crea un dominio, digamos el del Ejemplo 2.1, es necesario realizar una búsqueda del
dominio en el DAD para verificar que no exista, tanto en el archivo de dominios simples como en el
archivo de los dominios compuestos; ya que la definición de un dominio debe ser única, para evitar
ambigüedades en su tipo. Después de verificar que no exista el dominio, se procede a almacenar su
deñnición en el DAD.
En primer lugar se le asigna al campo TipoD el valor del mismo campo del primer registro
del archivo TdegDom, el cual lleva el número (tipo de dato) del siguiente dominio a insertar
Posteriormente se almacenan otros datos del registro como el nombre del dominio, el tipo base del
dominio simple, el valor por omisión si se requiere, la longitud del dominio, el estado del dominio
(activo), y la cláusula de restricción del dominio simple tanto en la forma iniija como posfija
I1
Después de registrar la información en el DAD en el nodo local, se actualiza el campo TipoD
del primer registro del archivo en uso, incrementándolo en 1, para que posteriormente al dar de alta
un nuevo dominio simple, se tenga su tipo (número) correcto.
I1
5.3.2. Creación de Dominios Compuestos
'1
Para crear
un dominio compuesto (considérese el del Ejemplo 4.1)primeramente se verifica
que no exista en el DAD, de la misma manera que en la creación de dominios simples, con lo cual
la búsqueda incluye ambos archivos de dominios (simples y compuestos). Después de verificar que
no exista el dominio compuesto, se procede a almacenar los datos de su definición en el DAD.
I/
Posteriormente se verifica que la inserción del dominio compuesto no genere un ciclo, y por
consecuencia los problemas mencionados en la Sección 3.3.1.2, por io tanto, si la inserción de tal
dominio compuesto provoca un ciclo se despliega su respectivo mensaje de error. Una vez que se ha
verificado esto,'!y no existe error se le asigna al campo TipoDC el valor del mismo campo del primer
registro del archivo TRegDomC del DAD, el cual iieva el número (tipo de dato) del siguiente
8!
49
IMPLEMENTACIÓN
CAP~TULO5
il
dominio a insertar. Después se almacena el resto de los datos del registro como el nombre del
dominio compuesto, los elementos con que cuenta, y los operadores relacionales que podrán usarse
con él.
I1
Después de que se registró la información en el DAD en el nodo local, siempre y cuando no
se presente un error, se actualiza el campo TipoDC del primer registro del archivo en uso,
incrementándoloen 1, para que posteriormente al dar de alta un nuevo dominio compuesto, se tenga
su tipo (númeroj correcto.
5.4. Creación de Tablas e hdices
I!
5.4.1. Creación de Tablas
En la Sección 4.3.1 se deñnió la sintaxispara crear una tabla. Cuando se ejecuta la instrucción
CREATE TABLE, se almacena en un registro del DAD la definición de la tabla.
11
Como se mencionó en la Sección 3.1.1, el SiMBaDD usa un precompilador que genera
código en Pascal semánticamente equivalente a la instrucción SQL. Considérese la instrucción del
Ejemplo 3.1; para generar su código en Pascal, es necesario realizar el análisis sintáctico y semántico
de ésta.
I1
El encargado de realizar dicho análisis es el procedimiento CreaTabla. A continuación se
muestra el código equivalente en Pascal de la instrucción que permite deíinir una tabla, en este caso
la tabla Tempe? del ejemplo antes mencionado.
1
Uses SQL,
2
3
-SQL-NTABLA,
4
5
-SQL-SET-TAE~LA("TEMPER","B",~,o),
-SQL SET~COLuMNA(l,"PTOGEO,lOO3,16,O,FALSE,FALSE,FALSE,""),
6
-SQL~SET-COLUMNA(2,"PTOGEO
LATiTüD",I 001,O,,O,FALSE,FALSE,FALSE,""),
7
-SQL-SET-COLUMNA(3,"PTOGEOGRADO,iO,4,O,FALSE,F~SE,FALSE,""),
8
-SQL-SET-COLUMNA(4,'PTOGEO
9
10
11
12
13
14
-SQL-SET-NODO("L0C
AL"),
MINUTO",l1,4,O,FALSE,FALSE,FALSE,""),
SQL-SET-COLWA(5,"PTOGEO LONGiTüD",1002,0,0,FALSE,FALSE,FALSE,""),
-SQL-SET-COLUMNA(6,"PTOGEOGRADO",I
0,4,O,FALSE,FALSE,FALSE,""),
-SQL-SET-COLUMNA(7,"PTOGEOMíMJTO",I
1,4,0,FALSE,FALSE,FALSE,""),
-SQL SET~COLUMNA(S,"NOMBRE",13,30,0,FALSE,FALSE,FALSE,""),
SQL~SET-COLUMNA(9,"TE~ER,l4,4,0,FALSE,FALSE,FASE,""),
CREA-TABLA,
~
~
De la línea 2 a la 13 son llamados a procedimientos que se encuentran en el módulo principal
SQL. Estos proedimientos se encargan de llenar la estructura de datos a almacenar en el DAD. Las
líneas 5 , 6 y 9 indican que el tipo de dato de la columna es compuesto; por lo tanto, su información
sólo será almacenada en la estructura del DAD para ser usada posteriormente, pero no ocupará
!/
50
'I
IMPLEMENTACI~N
CAPfTULO 5
espacio en la tabla, ya que sólo las columnas definidas con los tipos base o dominios simples
(incluyendo los hementos de un dominio compuesto), son recipientespara guardar los datos en la
tabla.
Para que permitiera el uso de tipos definidos por el usuario, fue necesario modificar el
procedimiento CreaTabla, en la parte del análisis sintáctico y semhtico, quedando actualmente de
t
la siguiente forma (cabe aclarar que el siguiente seudocódigo es una versión simplificada):
FUNCTION CreaTabla( Nodo STRING[80], W TRegTabla)
q:=qz
REPITE
SI NO Token-Leido ENTONCES Get-Token
DE LO CONTRARIO Token-Leido :=FALSO
CON LAESTRUCTURA W HACER
EN CASO DE QUE Q SEA
q2: SI T(ldent&ador) ENTONCES
NombreT=LexVal
il
{Token-Leido bandera para leer sig. token}
(Si T regresa un identiticador de Tabla)
(LexVal variable global arrojada por Get-Token)
q:=q3
DE LO CONTRARIO Error0
q3: SI T@IZQ)ENTONCES q:=q4
DE LO CONTRARIO Error()
q4: SI TOdentificador) ENTONCES
SI NoCoKMaxCols ENTONCES
SI NO YaExisteCol(LexVal,W,NoCol)
Inc(NoCo1)
(Si T regresa un identiticador de Columna}
{Si aún se le pueden añadir columnas a la tabla}
{Ver Anexo B}
(Contador del número de columna a insertar en la tabla}
q:=q5
DE LO CONTRARIO Error0
DE LO CONTRARIO Error()
DE LO CONTñARiO Error0
q5: CON LA ESTRUCTüRA ColsT[NoCol] HACER
Tipo(TipdC,NoCol)
SI TipoC>=IOOO ENTONCES
ColocaDomsEnTab(W,NoCol)
DE LO CONTRARIO SI TiuoC>9 ENTONCES
SI D o d e f a u l t ENTONCES ValDefaultC:=DomValDef
'I
q15: SI T(1dentificador) ENTONCES
SI ColCorrectaUniq(LexVa1,NoCol) ENTONCES
(Ver Anexo B}
{Si es una columna compuesta}
(Ver Anexo B}
(Si es una columna con dominio simple}
{Ver Anexo B}
{Si T regresa un identificador de llave primaria}
{Ver Anexo B}
CON LA ESTRUCTURA ColsT[NoCol] HACER
SI ?ipoC<lOOO ENTONCES q:=q16
{Si el tipo de dato de la col. no es un dom. comp.}
DE LO CONTRARIO ObteuElemDomC(W)
{Ver Anexo B}
SI NO YaExisteCol(LexVal,W,NoCol,PosCol)ENTONCES
(Ver Anexo B}
SI NO ExistColUniqíposCol) ENTONCES ColsPrimKey:=PosCol
{Ver Anexo B}
DE LO CONTRARIO Error0
DE LO CONTRARIO Error0
DE LO'bONTRARIO Error()
DE LO CONTRARIO Error0
q19 SI es PyC ENTONCES q:=q20
(PyC: Constante que representa al punto y coma}
DE LO CONTRARIO Error0
HASTA (Q = 20):
51
Y!.
'I
IMPLEMENTA C I ~ N
CAPfTULO 5
'1
Las modificaciones principales del procedimiento antes demito fuerón en la opción q5 y q15.
En 95 se extendió el rango de valores válidos para la definición del tipo de dato de una columna ya
que anteriormente sólo aceptaba los tipos base (del 1 al 9), con lo cual el tipo de dato que puede
tomar una columna es el de un dominio simple o compuesto. En q15 el cambio fue para que
t
permitiera definir como llave primaria a una columna defmida en base a un dominio compuesto.
5.4.2. Representación de Dominios en la Tabla
I
5.4.2.1. Dominios Simples en una Tabla
Una columna definida en base a un dominio simple no presenta grandes cambios en la forma
de almacenarse en la estructura de TRegTabla del DAD. Este caso se da cuando el campo TipoC de
TRegTabla tieni'un valor mayor que 10, ya que un valor menor (ver Sección 3.1.2) indica que el tipo
definido para esta columna es un tipo base, En este caso la forma de proceder a su almacenamiento
es similar a la del tipo base.
I1
5.4.2.2. Dominios Compuestos en una Tabla
Al definir una columna en términos de un dominio compuesto, el SiMBaDD guarda la
información relativa a ésta en la estructura de TRegTabla del DAD de la siguiente forma: para cada
elemento del daminio compuesto usa un campo de ColsT de TRegTabla (una de las opciones que
se comentó en la Sección 4.1), y para crear la tabla fisica toma en cuenta sólo los elementos
(dominios) simples, ya que únicamente éstos son los que reciben datos al aimacenarse información
en la tabla, siendo los demás campos de la columna compuesta, elementos auxiliares para su manejo
11
Por ejemplo, una vez ejecutado el código descrito en la Sección 5.4.1, la representación de
la columna compuesta PtoGeo en la estructura TRegTabla, quedaría como en la Tabla 5.1, y la tabla
Temper físicamente tendría los elementos que se muestran en la Tabla 5.2.
PtoGeo
I
PtoGeo.
Latitud
I
PtoGeo.
Grado
I
PtoGeo.
Minuto
I
PtocW.
Longitud
PtoGeo.
Grado
PtoGeo.
Minuto
Nombre
PtOGeo.
PtoGeo.
PtoGeo.
PtoGeo.
Grado
Minuto
Grado
Minuto
19
26
99
08
Mexico
25
20
07
98
4
Pachuca
23
81
52
Nombre
Temper
Temper
IMPLEMENTA CI6N
CAPÍTULQ 5
1
Al almacenarse en TRegTabla cada elemento del dominio compuesto, sólo se concatena el
nombre de la columna compuesta con el del elemento que se vaya proporcionando del dominio
wmpuesto referido, en cadauno de los campos de ColsT de TRegTabla. Por ejemplo, en el caso de
la c o l m a Ptodo de la tabla Temper, se almacenaría primeramente PtoGeo, el cual esta formado
por otros dos “dominios compuestos (Latitud y Longitud), y por lo tanto se almacenaría
PtoGeo.Latmid. Este dominio compuesto cuenta a su vez con dos elementos (Grado y Minuto), por
lo que se registraían F’toGeo.Grado y PtoGeo.Minuto (omitiendo Laiitud en ambos). Posteriormente
continuaría con PtoGeo.Longitud, el cual también tiene dos elementos (Grado y Minuto), y por IO
tanto se alma&
PtoGeo.Grado, finalizando conF’toGeo.Minuto. Cabe aclarar que si el elemento
de un dominio compuesto, por ejemplo Latitud es a su vez otro dominio compuesto se procede en
forma recursiva.
‘1 debe diferenciar cada uno de los elementos de la columna compuesta, esto con
El SiMBbD
la ayuda de la estructura TRegTabla, que cuenta con la información de cada uno de los elementos
de la columna. Por ejemplo debe diferenciar PtoGeo Latitud Grado de PtoGeo.Longitud.Grado, que
en este caso se almacenan con el mismo nombre (PtoGeo.Grado) por lo antes descrito, ya que el
guardar toda laI/ ruta del elemento, propicia el desperdicio de espacio. Pues bien, en el caso de
F’toGeo Longitud.Gado de Temper, primeramente se busca el registro de TRegTabla que contiene
la información de la tabla Temper; posteriormente con la ayuda de TRegTabla, la función que lo
busca se coloca en F’toGeo.Longitud del arreglo ColsT (Tabla 5.3.a) del registro seleccionado en
TRegTabla, pa?a postenormente continuar con la búsqueda del siguiente elemento, en este caso
PtoGeo.Grado (Tabla 5 3.b). En el caso de cualquier otro dominio compuesto, se procedería de la
misma forma, lo cual garantka que encuentre el elemento correcto. De otra forma, si se inicia su
búsqueda desde el principio de la estructura de TRegTabla podrá darse el caso de encontrar un
1)
elemento equivocado
(Tabla 5.3.c).
IPbGea I
FoGeO.
Latitud
I
Ptoceo.
Grado
I
PtOGea.
Minuto
I
PtoGeo.
Longitud
I
PtoGea’
Grado
I
Minuto
I
Nombre ITemper
t
lPtoCm I
lptoGea I
PtoGea.
Latitud
I
PtoGea.
Grado
I
Ptoh.
Minuto
I
PtoGea.
Longitud
ptoceo.
I
PtoGea.
Grado
1
PtOGeo.
Minuto
I
PtOGea.
Longitud
Latitud
I
PtoGeo.
Grado
PtoGea.
Minuto
Nombre
Teinper
PtoGea.
Grado
Ptoceo.
Minuto
Nombre
Temper
(4
Tabla 5.3. Búsqueda de un Elemento de una Columna Compuesta en TRegTabla.
53
IMPLEMENTACIdN
CAPhULO 5
11
5.4.3. Creación de Índices
En la Sección 4.3.2 se definió la sintaxis para crear una índice. Cuando se ejecuta la
instrucción C E k T E INDEX, se almacena en un registro del DAD la descripción del índice.
Al momento de crear unmdice se presentan dos casos: 1) que la tabla no tenga renglones (se
encuentre vacía) y 2) que la tabla tenga renglones (datos). Para crear un índice en la tabla Temper,
sobre el elemento compuesto PtoGeo.Latitud, mediante la siguiente instrucción:
t
Ejemplo 5.1
/I
CREATE INDEX TemLat ON
Temper (PtoGeo.Latitud);
el precompilador verifica si la columna sobre la que se creará el índice es compuesta; de ser así, la
generación de código para tal inshucción queda idéntica a como si fuera sobre una columna definida
sobre un d o d o simple o un tipo base. En tales circunstancias el cambio realizado en la función
Create-Indice fue en el reconocimiento de los tipos definidos por el usuario, además del
reconocimiento de los elementos de una columna compuesta.
I
Al ejecutarse la función Create-Index, se crea el índice y primeramente se verifica si la tabla
contiene renglones. Si el número de renglones es mayor que cero, se debe realizar un vaciado de los
valores que forman la clave al índice. Si un elemento que forme la clave del índice, es una columna
(I
o elemento compuesto,
éste es sustituido por todos los elementos simples (en base al párrafo
anterior) de la columna o elemento compuesto que forman la clave del índice. En caso de que se
encuentre una Il'ave repetida y el índice no acepte duplicados, es necesario destruir el indice creado
como también su definición del DAD,
I1
5.5. Instrucción DROP
I/
La instrucción DROP nos permite eliminar lógica y físicamente una tabla, un índice, un
dominio simple o un dominio compuesto.
I
5.5.1. Borrado de Dominios
5.5.1.1. Borrado de Dominios Simples
11
La instrucción
DROP DOMAIN se encarga de elimmar lógicamente un dominio simple del
diccionario de archivos distribuidos.
Cuando se le mdica al manejador que se desea borrar un dominio simple, éste debe verificar
I/
que no se encuentre
referido, tanto por un dominio compuesto como por una columna de una tabla.
ii
54
IMPLEMEhTACIdN
CAP~TULO5
Después de haberse verificado que no existe referencia a él, se procede a cambiar a cero el
valor del campo $culto AltaD, lo cual borra lógicamente el registro del dominio simple del DAD. En
caso de que e& en ese momento en uso (referido), no se deberá borrar para no perder su
información y provocar una incongruencia en los datos.
1
5.5.1.2. Borrado de Dominios Compuestos
Con la instrucción DROP COMPOUND DOMAIN podemos eliminar un dominio compuesto,
siendo la baja en forma lógica del diccionario de dominios.
1
Cuando el manejador detecta que se desea borrar un dominio compuesto, debe realizar una
búsqueda del dominio para verificar que no se encuentre referido, tanto por otro dominio compuesto
como por alguna columna de una tabla.
1
Después de haberse verificado que no existe referencia a él, se procede a cambiar a cero el
valor del campo oculto AltaDC, con lo cual se logra borrar lógicamente el registro del dominio
compuesto del diccionario de dominios. Si el dominio compuesto está en ese momento en uso
(referido), para /Ino perder su información no se deberá borrar.
5.6. Instrucción INSERT
1
Al msertar un renglón a una tabla, siuna columna está definida en base a un dominio, el valor
de ésta se verifica con la condición de restricción en fobna posíija del dominio en cuestión (la cual
se encuentra almacenada en el DAD).
Para riklizar la verificación de un valor contra la condición de restricción de un dominio
simple, se ejecuta la función EvaiDatEnDom. Si la función regresa un valor verdadero, sigmíica que
el valor de la columna satisface la cláusula de restricción. Esta verificación se realiza para todas las
columnas deñnidas sobre algún dominio. En caso de que todas las verificaciones resulten positivas,
se inserta el r d b ó n en la tabla usando la función AddRec (para una explicación del procedimiento
ver referencia PERSS]). En caso de que la función EvalDatEnDom retorne un valor falso, se le
asigna a la variable global SQLCODE (que guarda el estado de la operación realizada) el valor de
9 y el renglón no se inserta
/I
En caso de que la tabla tenga índices que no aceptan duplicados, es necesario buscar en el
mdice la clave correspondiente al valor a insertar. Para realizar la búsqueda de la clave en el índice,
el procedimiento INSERT usa la función TuplaCumpleRequisitos, la cual se encarga de verificar si
en el índice no existen claves repetidas.
/I
55
IMPLEMEhTACl6N
CAPíTULO 5
0
5.7. Instrucción SELECT
Cuando se realiza la consulta de un renglón, se tiene la opción de referirse a una columna
compuesta como'Iya se comentó en la Sección 4.7, regresándonos los valores de todos los elementos
de la columna. En el ejemplo que se describe a continuación, se desea obtener la Longitud de
Pachuca de la tabla Temper (Tabla 5.2).
Ejemplo 5.2
'I
SELECT
FROM
WHERE
PtoGeo.Longitud
Temper
Ciudad ='Pachuca';
Para poder ejecutar la instrucción anterior, primeramente es necesario procesar el programa
con el precompilador del manejador. El código equivalente en Turbo Pascal que genera el
precompilador es el siguiente:
1
2
3
4
5
6
I
8
9
IO
11
12
13
14
USES SQL,
BEGIN
-SET-DEFAULT -TQNAME,
-SETLONG-REGTQUERY( 1S ) ,
-I)MTOPSTATS('SELECT AW),
-' MTOPCC('TEMPER PTOGEO LONGITUD,l,O,l 3,8,1002,FALSE'),
-MTOPSTATS('WHERE
-MTOPPRED(I),
./ MTOPC('TE~ER.CIUDAD,13,21,31
,TRUE');
'! MTOPORCJ);
-MTOPVi(CIUDAD,l,FALSE);
-MTOPSTATSCFROMTEMPER '7:
; EXEC-SELECT;
END. ;I
I),
De la línea 4 a la 12 ,los valores enviados como parametros a los procedimientos son los
elementos de la estructura de datos TPointerStackStatus (que se describirá posteriormente).
I1
El procedimiento -MTOPSTATS recibe como entrada una cadena, la cual indica el nombre
de la cláusula de la instrucción que se ejecutará. Para la cláusula FROM se indica(n) la(s) tabla(s)
sobre la(s) cual(es) se trabajará. En el caso de la cláusula SELECT se indica@) ia(s) columna(s) que
se seleccionará'(n)para ser accesada(s).
Los procedimientos M T O P C y -MTOPCC reciben como entrada los datos de la columna
solicitada CMTOPCC se utiliza para las columnas compuestas), ya sea para la cláusula SELECT
(línea 5 ) o paik la cláusula WHERE (línea 9). Estos procedimientos se llaman tantas veces como
columnas aparezcan en las cláusulas SELECT y WHERE
!I
56
IMPLEMEh'TACIÓN
CAPÍTuu> 5
I1
Para el ejemplo anterior, los elementos que se introducirían en la estructura de datos son las
cláusulas SELECT, WHERE y FROM, indicadas en la líneas 5,7 y 12 del código equivalente. Cada
elemento de la lista StackStatutos apunta a se vez a otra lista denominada PrimaryNodo, para
t
almacenar las columnas, variables, constantes, y operadores de cada cláusula. Una vez ejecutada la
linea 12, la lista quedaria como lo muestra la Figura 5.1.
Al ejecutar
la línea 13, el manejador procede a consultar los renglones de la tabla Temper
I/
como se describe a continuación.
Primeramente se tiene que saber sobre qué tabla se trabajará, y esto lo sabemos por medio
de la linea 12 del código. Posteriormente, consultando el DAD, se obtiene la información de la
estructura de la'1 tabla (su tipo, si está activa, tamaño, si tiene índices definidos, columnas con que
cuenta, etc.).
Figura 5.1. Lista de Cláusulas para Ejecución del SELECT.
Después se procede a seleccionar los renglones que catisfagan la cláusula WHERE de la lista.
Para tal efecto, el renglón que se lee se introduce a un contenedor de memoria donde se le aplica la
operación de la lista correspondiente a la cláusula WHERE. En esta parte de la estructura se
encuentran la Aondición de selección en la forma posfija, el desplazamiento de la columna que
participa en la selección dentro del contenedor, y los operadores lógicos y relacionales de la
condición. Si el renglón satisface la condición de selección, se procede a guardar su número de
registro en un archivo temporal.
,I
Para recuperar los valores mdicados en la cláusula SELECT de los renglones que satisficieron
la cláusula WHERE, se procede a recuperarlos del archivo temporal auxiliándose del elemento
SELECT de la lista Stackstatus (ver Figura 5 . I), que tiene la lista de las columnas solicitadas.
11
6 del código se sabe que es una columna compuesta, y del contenedor de memoria
Gracias a la Imea
(para esto ya se han subido a memoria las columnas del renglón indicado en el archivo auxiliar) se
transfieren los valores a las variables anfitrionas respectivas.
A contkuación se describe la estructura de datos empleada para la selección de renglones.
La parte principal consiste de una lista de cláusulas denominadas StackStatutos, cuyos elementos
'
57
IMPLEMENTACl6N
CAP~TULO
5
I1
sirven para almacenar la cláusula de la instrucción que se ejecuta. Cabe hacer mención que la
esúuctura de la lista mostrada a continuación tiene algunas diferencias con la de versiones anteriores
(del SiMBaDD)para permitir el uso de los dominios compuestos.
1
TPointerStackStatutos=StackStatutos;
StackStatutos = RECORD
qlausula:
STRING;
Headpl:
PointerPrimaryList ;
SigClaus:
TPointerStackStatus;
END;
donde
Clausula
Contiene el tipo de operación a realizar y puede ser INSERT, SELECT, UPDATE,
DELETE, WHERE, o FROM.
Headpl
Es un apuntador a la estructura PointerPrimaryList que se describirá enseguida.
SigClaus
Es un apuntador al siguiente elemento de la lista TPointerStackStatus.
11
Cada uno de los elementos de la lista Stackstatus apunta a su vez a otra lista denominada
PrimaryNodo, cuyos elementos se usan para almacenar las columnas, constantes y operadores de
cada cláusula. Su estructura es la que sigue:
I1
PohterPnmaryList = "PrimaryNodo;
PrimaqNodo = RECORD
ItemP:
TPrimay;
Si@:
PomterPrimaryList;
END;
donde
/I
ltemP
Variable del tipo estructura TPrimary (que se describe a continuación) donde se
especiñca si la siguiente operación a re&r dentro de la lista es un predicado, el tipo
I1
de predicado (IN,BETWEEN, ESCALAR), el valor de comparación, la columna que
participa en la evaluación, etc.
SigP
Es un apuntador al siguiente elemento de la lista PointerPrimaryList
11
El registro TPrimary tiene la siguiente estructura:
!I
58
1
IMPLEMENTA CZ6N
CAPíTULO 5
'i
TPrimary = RECORD
ClaseP:
TPrimaryClase;
NuloP:
BOOLEAN;
DesdeP:
INTEGER;
NombreP:
STRING[12];
LongP: .
BYTE;
CASE TipoP: BYTE OF
1: (CharP:
STRING);
2: (IntP:
INTEGER);
3: (LintP:
LONGINT);
4: (Reap:
REAL);
!i 9: (DateP:
LONGINT);
O: (DatRegP: RECORD
NumDCP: INTEGER;
InicDCP: INTEGER,
PerNDCP: BOOLEAN;
II
END);
10: (OperadorP:
CHAR);
20: (OperRelP:
BYTE);
j 30: (OperLogP: CHAR);
40: (PredicadoP:
BYTE);
END;
/I
donde
ClaseP
NdoP
DesdeP
NombreP
LongP
I\
Contiene la clase de operación a realizar que se describe en el conjunto
TPrimayClase.
1;
fhntiene el valor TRUE si la columna acepta valores nulos, de lo contrario contiene
el valor FALSE.
Contiene la posición inicial de la columna dentro del contenedor de memoria
I1Contiene el nombre de la columna que se evalúa.
Contiene la longitud de la columna que se evalúa
I
TipoP
Registro de tipo variable que indica el tipo de operador lógico que interviene en la
operación o bien indica el tipo de dato que se está evaluando.
TPrimayClase
'Esun conjunto que contiene los siguientes datos (Predicado, Espcol, Espvar, Oprlog,
Oprel), los cuales se usan para determinar el tipo de operación a realizar.
IMPLEMENTACI6N
CAPh'ULQ 5
'1
5.8. Instrucción UPDATE
'
A través de la instrucción UPDATE se modifican los datos de una tabla, permitiéndonos
actualizar los redglones que cumplan la condición de búsqueda. Con la cláusula SET se indica qué
columnas participan en la actualización; pudiendo referirse a una columna compuesta o a al&
elemento de ésta. Con esto su valor es verificado automáticamente para saber si cumple la condición
de restricción del dominio simple con el que se definió el elemento, lo mismo ocurre al referirse a una
columna deñnida en base a un dominio compuesto. Los nuevos valores se tratan igual que en la
instrucción INSERT.
La cláusula WHERE en la instrucción UPDATE, para que permita el uso de dominios, se
implementó de ia misma manera que en la instrucción SELECT.
5.9. Instrucción DELETE
Por medio de la instrucción DELETE se suprimen renglones de una tabla que cumplan una
condición de selección. E1 boriado de estos renglones es en forma lógica, lo cual se logra cambiando
a uno el valor del campo oculto AItaC. Cuando se realiza el borrado de un renglón en una tabla que
tiene indice(s), éste (éstos) se debe@) actualizar, borrando del (de los) índice(s) el valor de la clave
asociada con el renglón eliminado de la tabla.
Para quk permitiera el uso de dominios, la cláusula WHERE en la instrucción DELETE se
bnplementó de la misma forma que en las instrucciones SELECT y UPDATE.
I!
60
6
CAPITULO
En este capítulo se presentan las pruebas realizadas al SiMBaDD para respaldar los resultados
obtenidos con el desarrollo de esta tesis. Las pruebas consisten en ejecutar una serie de programas
en Turbo Pascal con instrucciones de SQL mtercaladas y verificar que el resultado de cada ejecución
sea equivalente a la semántica de las instrucciones del programa fuente, así como también el de
comprobar el buen funcionamiento de la extensión en la definición y manipulación de los dominios
compuestos. Por razones de espacio se presentan en este capítulo sólo aquellas pruebas que se
consideran más representativas, sin embargo para hacer una prueba exhaustiva del sistema se
desarrollaron aproximadamente 75. Todas las pruebas realizadas presentaron resultados exitosos.
6.1. Objetivo de las Pruebas
't
Los principales objetivos de estas pruebas son los siguientes:
Veriñcar que las acciones semánticas efectuadas por el programa que resulten de la
precodpilación, sean eqnivalentes a las instmcciones del lenguaje SQL intercalado en el
lenguaje anfitrión.
Verificar que los programas ejecutables en el caso de crear, modificar, y borrar dominios
simples y/o compuestos cumplan su cometido.
Verificar que los programas ejecutables para el caso de crear tablas con columnas definidas
en términos de dominios (simples como compuestos) realicen su cometido.
Verificar que los programas ejecutables solo comparen columnas definidas en base al mismo
dominio; además en el caso de los dominios compuestos verifique que el (los) operador(es)
relacional(es) a utilizar en la comparación sea(n) váiido(s) para éste.
61
1
!I
PRUEBAS DE FUNCIONALDAD
CAPíTULO 6
e)
f)
Venñcar que los programas ejecutables con instrucciones del LMD (inserción, selección,
aaai;a&ón, Y borrado de renglones) que hacen uso de dominios CUmPlm satisfactoriamente
su encomienda.
Que detecte los mores si los hay, ya sea en precompilación o en ejecución de los programas
I/
de prueba.
Para conseguir el punto a), se implementó otra serie de programas en Turbo Pascal con
instrucciones de SQL intercalados en el lenguaje anfitrión.
I/
Para lograr el punto b), se implementó otra serie de programas con instrucciones de SQL
adecuadas a cada acción (inserción, cambio, y borrado de dominios).
Para conseguir el punto c), se verificó que la instrucción del estándar SQL CREATE TABLE
utilizada en los programas de entrada, especificara en la definición de las columnas, aparte de los
tipos base del SQL, también a los tipos definidos por el usuario (los dominios).
Ji
Para logkar el punto d), se verificó que,las instrucciones de SQL utilizadas en los programas
fuente, incluyeran comparaciones con columnas definidas en términos de dominios diferentes, así
como también programas en donde se utilizaran operadores relacionales no válidos para columnas
definidas sobre ]determinado dominio compuesto.
Para lograr el punto e), se verificó que las instrucciones de SQL utilizadas en los programas
fuente, utilizaran dominios (simples y principalmente los compuestos) de una forma nomal.
I/
Para lograr el punto f), también se implementó una serie de programas con instrucciones de
SQL para cada caso @recompilacióny ejecución), similar a los puntos a y b.
I1
6.2. Descripción del Ambiente de Pruebas
Las pruebas se realizaron en un ambiente completamente nuevo en relación a las pruebas de
trabajos antenores; es decir, la nueva plataforma del SiMBaDD está constituida por tres
computadoras'AT, las cuales están conectadas a través de Microsoft Windows para Trabajo en
&pos, y cada máquina utiliza el sistema operativo Microsoft Windows Ver. 3.11.
6.3. Presentaciód de las Pruebas
Los datos iniciales del los archivos Temper.Dat y Aitura.Dat de la base de datos para estas
pruebas, se obdvieron de algunos folletos y reportes del EVEGI (Instituto Nacional de Estadística,
Geográfica e Informática) y los del archivo Contam.Dat fueron ficticios.
62
1
CAPfTULO 6
PRUEBAS DE FUNCIONALJDAD
6.3.1. Contenido Inicial de la Base de Datos de Prueba
81
A continuación se presentan los archivos con los valores iniciales de la base de datos de
prueba (Tabla 6.1, 6.2. y 6.3). Es oportuno aclarar que algunos de dichos valores cambiaron
conforme se realizaban las pruebas; cabe hacer mención que en otras pruebas se manejaron más de
500 registros en"cada una de las tablas, obteniéndose en cada una de eiias resultados positivos.
63
PRUEBAS DE F U N C l O N D t W
CAPíTULO 6
I1
PtoGeo.
Latitud.
Grado'
19
19
I
18
++-++
Longitud. Longitud. Nombre
Minuto
Latitud.
Citlaltepetl
55
99
20
Cuernavaca
La Nieve
19
I/
20
17
Temper
59
'
I
98
44
Pachuca
94
33
Minatitlan
I
25
20
Queretaro
20
Salamanca
22
Tampiw
I
24
19
Veracniz
I
24
19
26
101
20
Acapulco
23
I
Tabla 6.1. Datos del archivo Temper.Dat.
PtoGeo.
Latitud.
Longitnd.
Longitud.
Nombre
Contam
Minuto
Mexico
25
99
Cuernavaca
50
101
Monclova
3
101
Moreiia
10
Pachuca
40
I Oueretaro
80
97
Tampico
70
25
102
Tancitaro
7
59
92
Viiiahermosa
5
55
54
42
I
I
I
20
23
22
17
17
1
56
Tabla 6.2. Datos del archivo Contam.Dat.
64
I/
CAPITULO 6
PRUEBAS DE FUNCIONALJDD
11
1
18
55
99
15
Cuemavaca
1480
19
11
98
38
Iztaccihuatl
5220
19
1
I
27
22
101
17
I
97
25
I LaNieve
52
Tampico
I
I
3440
10
6.4.
INombreD
GRADO
MINUTO
11
I1
TEMPER
ALTURA
CONTAM
I TipoD I TipoB
li
12
ActivoD
iNTEGER (3)
iNTEGER(3)
13
INTEGER(3)
14
INTEGER(3)
15
INTEGER(3)
RestnccionD
RestPosiD
I GRADO <- 179
TRUE
TRUE
179 <-AND
mmo+
MINUTOrOANLI
MIMITO <- 69
I
TEMPERS-1AND
TEMPER <- 49
ALTURA Q 5700
m r r n 60 <-
I
dNn
I
TEMPER12TEMPER 49 C- AND
AlXURA 5700 <-Ah'D
CONTAM400 <-AND
CmDAD
16
-00)
(1)
Tabla 6.4. Datos del Archivo de Dominios Simples.
La información de los dominios compuestosque se msertaron en la BD de pruebas se muestra
enla Tabla 6.5.
65
ir
CAPíTULO 6
NombreDC
PRUEBAS DE FUNCIONALDALI
TipoDC
#Doms
LATITUD
1001
2
TRUE
11.12
=, o
LONGiTUD
1002
2
TRUE
11,12
=, o
1003
2
TRUE
1001,1002
=, o
81
FTOGEO
',I
Doms
AetivoDC
1
!I
66
OpersPerm
I/
CAPfTULO 6
PRUEBAS DE FUNCIONALDAD
PRUEBA1.EP
1
'1
Prueba
r
Crear los dominios simples Grado y
Minuto.
20-Mayo-96
Objetivo:
Fecha:
USES
SQL;
NO.
1
,
BEGIN
$ CREATE DOMAIN Grado INTEGER
CHECK (Grado >= O AND Grado < = 179);
$ CREATE DOMAIN Minuto INTEGER
DEFAULT O
CHECK (Minuto >= O AND Minuto <= 59);
ENE.
I<
!I
Se ejecutó en: 0.35Segundos.
67
.-
/I
CAPfrULO 6
PRUEBA2.EP
PRUEBAS DE FUNCIONALDAü
I(
Prueba No. 2
Objetivo :
,
Fecha :
USES
I/
Crear los dominios compuestos Latitud
y Longitud.
20-Mayo-96
SQL;
BEGIN
!I
$
CREATE COMPOUND DOMAIN Latitud
(Grado,
Minuto,
OPERATORS (=, < > ) ) ;
$
CREATE COMPOUND DOMAIN Longitud
(Grado,
Minut o,
OPERATORS (=, < > ) ) ;
Se ejecutó en: 0.37Segundos
68
CAPfTLLO 6
I1
PRUEBAS DE FUNCIONALDAD
1
I
PRUEBA3. EP
(
I1
Objetivo:
Fecha:
P r u e b a No. 3
C r e a r e l dominio compuesto C o o r G e o g .
,,
20-Mayo-96
1
!
USES
BEGIN
SQL;
i
$ CREATE,,COMPOUND DOMAIN C o o r G e o g
(Latitud,
Longitud);
I/
END.
Se ejecutó en: 0.25 Segundos.
69
CAPfTULO 6
PRUEBAS D E FUNCiONAiDAD
11
.
PRUEBA4 EP
Prueba N o . 4
Objetivo :
"
Fecha:
'
USES
SQL;
Crear los dominios Nombre, Altura,
Temper y Contam.
2O -Mayo- 96
li
BEGIN
$
CREATE DOMAIN Ciudad CHAR(30)
DEFAULT ' '
CHECK (Ciudad <>' I ) ;
$
CREATE DOMAIN Altura INTEGER
DEFAULTo
CHECK (Altura >= O AND Altura <= 9000);
$
CREATE DOMAIN Temper INTEGER
DEFAULT O
CHECK (Temper >= O AND Temper <= 55);
$
CREATE DOMAIN Contam INTEGER
DEFAULT O
CHECK (Contam >= O AND Contam <= 400);
ENE.
Se ejecutó en: 0.55Segundos.
I!
li
70
!EO6
CA
-
E FUNCIONALDA
,I
PRUEBA5.EP
1
P r u e b a No. 5
Objetivo:
Fecha:
Añadir al dominio Grado la cláusula
default.
20-Mayo-96
,I
I,
I/
USES SQL;
ll
BEGIN
$ ALTER DOM+IN Grado SET 1;
ENE.
Se ejecutó en: 0.22 Segundos.
'0
71
I!
PRUEBAS DE FUNCIONALDAD
CAPíTULO 6
PRüEBA6.EP
11
(
Prueba No. 6
Objetivo: ,
Propósito:
’
Fecha :
Crear las tablas Altura, Temper y Contam.
Verificar que los nuevos tipos de datos (dominios)
puedan utilizarse en la creación
de una tabla.
20-Mayo-Y6
1
USES
SQL;
I1
BEGIN
$
CRFATE TABLE Altura
( PtoGeo CoorGeog NOT NULL,
Ciydad
Ciudad,
Altura Altura) ;
$
CRFATE TABLE Temper
( PtoGeo CoorGeog NOT NULL,
Ciudad Ciudad,
Temper Temper,
PRIMARY KEY (PtoGeo.Longitud));
$
CREATE TABLE Contam
( PtoGeo
CoorGeog NOT NULL,
Ciudad
Ciudad,
&tam
Contam,
PRIMARY KEY (PtoGeo.Longitud.Minuto));
END.
I
1
Se ejecutó en: 1.28 Minutos.
I1
i:
72
11
PRUEBAS DE FUNCIONALlDAD
CAPíTULO 6
'
PRuEBA7. EP
I
1
P r u e b a No. I
.
Insertar los valores de los renglones
de la tabla Temper. Los datos se leen
del archivo de tipo DatTem.Dat.
Comprobar que se permita referir para insertarse
elementos compuestos de una
columna compuesta.
20-Mayo-96
Objetivo:
,!
Propósito:
Fecha :
I
USES
SQL, SQLDAT, DOMDAT, WINCRT;
BEGIN DECLARE SECTION
PtoGeo',
: CoorGeog;
Ciudad
: Ciudad;
Temper
: Temper;
END DECLARE ,SECTION;
$
I1
PROCEDURE Alta-Tem;
VAR
F
: FILE OF RegTemper;
Dat
: RegTemper;
BEGIN
ASSIGN (F!" DatTem.Dat ) ;
RESET (F);
WHILE NOT EOF(F) DO BEGIN
READ (F,Dat);
PtoGeo
:=Dat.PtoGeo;
:=Dat.Ciudad;
Ciudad
Temper
:=Dat.Temper;
!I
$
INSERT INTO Temper
VXUES(:PtoGeo.Latitud, :PtoGeo.Longitud, :Ciudad, :Temper);
il
IF SQLCODE
= O THEN WRITE('<<Registro insertado>>')
ELSE WRITE('<<Registro No dado de Alta>>');
END;
CLOSE (F);
END;
,
BEGIN
Alta-Tem
END.
Se ejecutó en: 3.07 Minutos.
13
PRUEBAS DE FUNCIONALIDAD
CAPfTULO 6
PRüEBA8.EP
II
t
Objetivo:
I,
Propósito:
II
Fecha :
Prueba No. 8
insertar los valores de los renglones
de la tabla
del archivo
Validar que
referirse a
20-Mayo-96
Altura. Los datos s e leen
de tipo DatAlt.Dat.
para insertar se permita
una columna compuesta.
II
USES
$
SQL, SQLDAT, DOMDAT, WINCRT;
BEGIN DECLARE SECTION
PtoGeo'l
: CoorGeog;
Ciudad
: Ciudad;
Altura
: Altura;
END DECLARE SECTION;
PROCEDURE Alta-Alt;
VAR
F
: FILE OF RegAltura;
Dat
: RegAltura;
BEGIN
ASSIGN (F?'DatAlt.Dat' ) ;
RESET (F);
WHILE NOT EOF(F) DO BEGIN
READ(F,Dat);
:=Dat.PtoGeo;
PtoGeA
:=Dat.Ciudad;
Ciudad
Altura
:=Dat.Altura;
'I
$ INSERT INTO Altura
VALUES ( :PtoGeo, :Ciudad, :Altura);
I/
IF SQLCODE = O THEN WRITE('<<Registro insertado>>')
ELSE WRITE('<<Registro No dado de Alta>>');
END;
CLOSE (F)'!
END;
BEGIN
Aita Alt'
ENE.
~
!i
Se ejecutó en: 3.13 Minutos.
:!
74
PRUEBAS DE F U N C I O N m A D
CAPmLO6
1
PRUEBA9.EP
(
Objetivo :
II
Propósito:
I1
Fecha :
Prueba No. 9
Insertar l o s valores de l o s renglones
de la tabla Contam. Los datos se leen
del archivo de tipo DatCont.Dat.
Verificar que para insertar se pueda
referir en el orden que se quiera los
elementos de una columna compuesta.
20-Mayo-96
I1
USES
$
SQL, SQLDAT, DOMDAT, WINCRT;
BEGIN DECL!ARE SECTION
PtoGeo
: CoorGeog;
Ciudad
: Ciudad;
Contarn,
: Contam;
END DECLARE SECTION;
PROCEDURE
Alta-Cont;
VAR
F
: FILE OF Regcontam;
Dat
: Regcontam;
BEGIN
I
ASSIGN(F,'DatCont.Dat');
RESET IF) ;
WHILE NOT EOF(F) DO BEGIN
READIF,Dat);
PtoGeo :=Dat.PtoGeo;
Ciudad :=Dat.Ciudad;
Contám :=Dat.Contam;
~~~
INSERT INTO Contam (PtoGeo.Longitud, PtoGeo.Latitud,
Ciudad.
I.
. Cont am i
V d U E S ( : PtoGeo.Longitud, :PtoGeo .Latitud, :Ciudad, :Contam);
IF SQLCODE = O THEN WRITE('<<Registro insertado>>')
ELSE WRITE('<<Registro No dado de Alta>>');
$
END:
11
CLOSE (F);
END;
Ii
BEGIN
Alta-Cont
END.
Se ejecutó en: 3.15 Minutos
15
I/
PRUEBAS DE FUNCIONALWAD
CAPkULO 6
.
PRUEBA10 EP "
I
"
Objetivo :
Fecha:
USES
Prueba No. 10
Crear un índice sobre una columna
definida en base a un dominio compuesto.
20-Mayo-96
I!
SQL;
BEGIN
$ CREATE INDEX Altura
ON Altura(PtoGeo.Longitud);
END.
Se ejecutó en: 0.51 Segundos.
1)
76
PRUEBAS DE FUNClONALlDAD
CAPfTULO 6
ll
PRUEBA11 .EP
I-
Prueba No. ll
Objetivo :
1
Fecha :
Obtener la temperatura promedio de
las localidades de una latitud dada
en la tabla Temper.
20-Mayo-96
il
USES
$
SQL, SQLDAT, DOMDAT, WINCRT;
BEGIN DECLARE SECTION
Promed'l
: Temper;
PtoGeo
: CoorGeog;
END DECLARE SECTION;
BEGIN
WRITE('Latitud de Temper I ) ;
WRITE('=================== 1
WRITE(:Pto.Geo.Lat. (G)... :
;READLN(PtoGeo.Latitud.Grado) ;
WRITE(t'Pto.Geo.Lat. (M). . .: ' ;READLN(PtoGeo.Latitud.Minuto);
$
SELECT
INT,O
FROM
WHERE
AVG '(PtoGeo.Longitud.Grado)
:Promed
Temper
PtoGeo.Latitud.Grado = :PtoGeo.Latitud.Grado;
WRITELN('Resultad0 de la Prueba No. 11');
WRITEL~N:
IF SQLCODE = O THEN
WRITELN('Temperatura promedio :',Premed);
END.
!I
1)
CAPíTULO 6
PRUEBAS DE FUNCIONALIDALI
Latitud de Temper
,I
_-_________-_--__-______________-____
Pto.Geo.Lat.(G). . . : 19
Pto.Geo.Lat. (M). . .: 26
Resultado de'lla Prueba No. 11
Temperatura promedio :22
I!
Se ejecutó en: 14 Segundos
!I
I
78
PRUEBAS DE FUNCIONALDAD
CAPf7VLO 6
I!
PRUEBA12 .EP
1
!:
Objetivo :
Propósito:
'I
Fecha :
P r u e b a No. 12
Obtener los datos completos de l a
tabla Temper
Verificar que la cláusula FETCH
permita el uso de registros como
variables anfitrionas.
20-Mayo-96
~
I/
USES
$
SQL, SQLDAT, DOMDAT, WINCRT;
BEGIN DECEARE SECTION
: CoorGeog;
PtoGeo'!
Ciudad
: Ciudad;
Temper
: Temper;
END D E C T E SECTION;
PROCEDURE Cons-Tem;
BEGIN
WRITELN('$esultado de la prueba NO. 12 I ) ;
WRITELN('============================= ')'WRITELN;
$
$
DECLARE
SELECT ii
FROM
CURSOR tcl FOR
*
Temper;
OPEN tcl;
REPEAT
$ FETCH Tcl INTO
:PtoGeo, :Ciudad, :Temper;
I!
IF SQLCODE = O THEN BEGIN
WRITELN('Pt0. Geo. Lat. (G)..: ',PtoGeo.Latitud.Grado);
WRITELN ( ' Pto . Geo. Lat. (M). . : ' ,PtoGeo.Latitud..Minuto);
WRITELN('Pt0. Geo. Lon. (G). .: ',PtoGeo.Longitud.Grado);
WRITELN('Pt0. Geo. Lon. (M)..: ',PtoGeo.Longitud.Minuto);
WRITELN('Ciudad .............. : ',Ciudad);
WRITELN('Temper ................ ., ,Temper);
END;
UNTIL SQLCODE <> O;
$ CLOSE tcl;
END;
II
BEGIN
Cons-Tem
END.
I1
79
PRUEBAS DE FUNCIONALlDm
CAPíTULO 6
Resultado de 1 la prueba No. 12
.............................
Pto. Geo. Lat. (GI..: 19
Pto. Geo. Lat. (M). . : 2
Pto. Geo. Lon. (G).. : 97
Pto. Geo. Lon. (M).. : 16
Ciudad .............. : Citlaltepetl
Temper .......[........: 11
Ciudad .............. : Mexico
Ciudad . . . . . . . . . . . . . . : Cuernavaca
Ciudad ..... l. . . . . . . . . La Nieve
Ciudad . . . . . . . . . . . . . . : Pachuca
il
Ciudad . . . . . . . . . . . . . . : Minatitlan
I1
Ciudad ..............
: Queretaro
Ciudad . . . . . . . . . . . . . . : Salamanca
!I
Ciudad .............. : Tampico
!I
Ciudad .............. : Veracruz
Ciudad . . . . .(... . . . . . . : Acapulco
Temper
: 23
Ciudad . . . . . . . . . . . . . . : Al
I1
Ciudad ...............: A9
Temper .............. : 9
:I
Se ejecutó en: 2.54 Minutos.
1
80
PRUEBAS DE FUNCIONALIDAD
CAPíTULO 6
11
PRuEBA13.EP
(
!!
Fecha:
USES
$
Prueba No. 13
Obtener los distintos grados de las
latitudes de Temper
20-Mayo-96
Objetivo :
SQL, SQLDAT, DOMDAT, WINCRT;
BEGIN D E C ~ E
SECTION
PtoGeo :CoorGeog;
END DECLARE SECTION;
I1
PROCEDURE ConsDist-Tem;
BEGIN
WRITELN('Resu1tado de la prueba No. 13
WRITELN('=============================
$
DECLARE
SELECT
FROM
.;
$
OPEN tcl;
REPEAT
$
I ) ;
1 )
'WRITEL"
CURSOR tcl FOR
DISTINCT Temper.PtoGeo.Latitud.Grado
Temper;
1,
FETCH tcl INTO
:PtoGeo.Latitud.Grado;
I/
IF SQLCODE = O THEN
WRITELN('Pt0. Geo. Lat. (G)..: ',PtoGeo.Latitud.Grado);
UNTIL SQLCODE <>o;
$ CLOSE tcl;
END;
!I
BEGIN
ConsDist-Tern
ENE.
81
I!
CAPirULO6
PRUEBAS DE FUNCIONALDAD
11
R e s u l t a d o de l a prueba N o .
13
.............................
. 'I
P t o . Geo. L a F .
.:
( G ) . .:
Pto. Geo. L a t .
(G).
P t o . Geo. L a t .
(G)..:
P t o . Geo. L a t .
(G).
.:
P t o . Geo. L a t .
(G).
.: 1
P t o . Geo. L a t .
ii
(GI.
19
18
.: 20
17
22
It
P t o . Geo. L a t .
(G)
..:
2
(G)
..:
g
3
P t o . Geo. L a t .
1
Se ejecutó en: 35 Segundos
li
82
PRUEBAS DE F U N C I O N D A D
'1
CAPfTULO6
PRUEBA14.EP
'I
i
P r u e b a No. 14
Objetivo :
Propósito:
I1
Fecha:
USES
$
Obtener los datos completos de Temper
y de Altura para cada par de puntos
geográficos que coincidan en su columna
Latitud en Temper y en Altura
Verificar que la cláusula WHERE permita
el uso de columnas compuestas.
20-Mayo-96
SQL, SQLDAT, DOMDAT, WINCRT;
BEGIN DECLARE SECTION
PtoGeo
: CoorGeog;
Ciudad,;
: Ciudad;
Temper'
: Temper;
PtoGeoA
: CoorGeog;
CiudadA
: Ciudad;
Altura.;
: Altura;
END DECLARE SECTION;
PROCEDURE Join-T e a t ;
BEGIN
I
WRITELN('Resultad0 de la prueba No. 14
WRITELN('=============================
$
$
DECLARE CURSOR tcl FOR
SELECT
*
FROM
Temper, Altura
WHERE
Temper.PtoGeo.Latitud
=
I ) ;
I ) ;
WRITEL"
Altura.PtoGeo.Latitud;
OPEN tcl;
REPEAT
$ FETCH tcl INTO
:PtoGbo,
:Ciudad, :Temper,
:PtoGeoA, :CiudadA, :Altura;
= O THEN BEGIN
WRIFELN('Pt0. Geo.Lat. (G).: ',PtoGeo.Latitud.Grado)
WRITELN('Pt0. Geo.Lat.(M).: ',PtoGeo.Latitud.Minuto :
WRITELN('Pt0. Geo.Lon.(G).: ',PtoGeo.Longitud.Grado ;
WRITELN('Pt0. Geo.Lon. (MI.: ',PtoGeo.Longitud.Minut
WRIFELN('Ciudad . . . . . . . . . . . : ',Ciudad);
WRITELN('Temper ........... : ',Temper);
WRI,TELN('PtO. Geo.Lat. (G).: ',PtoGeoA.Latitud.Grado);
WRITELN('Pt0. Geo.Lat. (M). : ',PtoGeoA.Latitud.Minuto);
WRI.,TELN('Pto.Geo.Lon.(G). : ',PtoGeoA.Longitud.Grado);
WRI~TELN('Pto.Geo.Lon.(M)..: ',PtoGeoA.Longitud.Minuto);
WRITELN('Ciudad ........... : ',CiudadA)i
WRITELN('A1tura ........... : ',Altura);
END:
I F SQLCODE
j ) ;
I!
83
fi
1
CAPÍTLLO 6
U N T I L SQLCODE
$ CLOSE t c l ;
I/
END;
PRUEBAS DE FUNCIONAUDALl
<>
O;
BEGIN
J o i n-T e m A i t
It
END.
Se ejecutó en: Más de 3 horas (se detuvo manualmente).
:i
/I
!I
84
I
CAPfTULO 6
PRUEBAS DE FUNCIONALIDAD
I1
PRUEBA15.EP
I
II
(
Prueba No. 15
Objetivo:
i!
Fecha:
Obtener la longitud de una ciudad
en la tabla Temper.
20-Mayo-96
1
1
USES
SQL, SQLDAT, DOMDAT, WINCRT;
$ BEGIN DECI!$RE SECTION
PtoGeo
: CoorGeog;
Ciudad
: Ciudad;
END DECLqE SECTION;
PROCEDURE ConsNomTem;
BEGIN
WRITE('Ciudad. . . . . . . . . . . . . .
$ SELECT
INTO ,i
FROM
WHERE
:
I ) ;
READLNíCiudad);
PtoGeo.Longitud
:PtoGeo.Longitud
Temper
Ciudad = :Ciudad;
WRITELN( !Resultado de la prueba No. 15 1 ) ;
WRITELN(l=============================
I ) ;
WITELN;
IF SQLCODE = O THEN BEGIN
WRITELN('Pt0. Geo. Long. (Gral . : ' ,PtoGeo.Longitud.Grado);
WRITELNí'Pto. Geo. Long.(Min) . : ',PtoGeo.Longitud.Minuto);
END
END;
I1
BEGIN
ConsNomTem
END.
85
il
1
CAPiTULO 6
Ciudad . . . . . . : . . . . . . .
PRUEBAS DE FUNCIONALDALI
:
Cuernavaca
Resultado de la prueba No. 15
.............................
I/
Pto. Geo. Long. (Gra).: 99
Pto. Geo. Long. (Min). : 15
ii
Se ejecutó en: 8 Segundos.
r
86
PRUEBAS DE FUNCIONALDAD
CAPPULO 6
':
PRUEBAl6.EP
(
I!
O b jetivo :
Propósito:
i/
Fecha:
Prueba No. 1 6
Obtener la longitud de los puntos geográficos
en Temper cuya longitud coincida con la
longitud de los puntos geográficos en Altura,
tales que la latitud es éstos coincida con la
latitud de l o s puntos geográficos en Contam,
tales que la latitud de éstos sean igual a una
latitud dada.
Verificar que en l o s select anidados se puedan
referir columnas compuestas.
2O -Mayo-96
I
USES
$
SQL, SQLDAT, DOMDAT, WINCRT;
BEGIN D E C F E SECTION
PtoGeo
: CoorGeog;
END DECLARE SECTION;
PROCEDURE ConsNomTem;
BEGIN
WRITELN('Datos de Contam I ) ;
WRITELN('=============== 1 ) ;
WRITE('Pt6. Geo.Lat.(Gra).:
WRITE('Pt0. Geo.Lat.(Min).:
$
I ) ;
I ) ;
READ(PtoGeo.Latitud.Grado);
READ(PtoGeo.Latitud.Minuto);
SELECT,.PtoGeo.Longitud
INTO
:PtoGeo.Longitud
FROM
Temper
WHERE PtoGeo.Longitud IN
(SELECT PtoGeo.Longitud
IIFROM Aitura
'WHERE PtoGeo.Latitud IN
(SELECT PtoGeo.Latitud
FROM
Contam
II
WHERE PtoGeo.Latitud
=
:PtoGeo.Latitud));
WRITELN('Resultad0 de la Prueba No. 16');
wRITELN(I============================= I )
!
.
WRITELN.
IF SQLCODE = O THEN BEGIN
WRITELN('Pt0. Geo. Long.(Gra).: ',PtoGeo.Longitud.Grado);
WRITELN('Pt0. Geo. Long.(Min).: ',PtoGeo.Longitud.Minuto);
END
II
END;
BEGIN
ConsNomT&m
END.
87
il
)
CAPfTULO6
PRUEBAS DE FUNCIONAL ID^
Datos de Contam
________-______
_-_____________
iI
P t o . Geo. Long. ( G r a ) . : 19
Pto. Geo. Long. ( M i n ) . : 4 2
Se ejecutó en: 2.3f Minutos
I!
88
PRUEBAS DE FUNCIONALDAD
:i
CAPíTlJLO 6
PRUEBA17.EP
t
Objetivo: ,,
il
Propósito : .
Fecha :
USES
!I
Prueba No. 17
Obtener los datos completos de la tabla Temper
para cada punto geográfico cuya longitud no
coincida con la longitud de cualquier punto
geográfico en Altura, tal que la latitud de
este Último sea igual a una latitud dada.
Verificar que en la cláusula WHERE se pueda
comparar una columna compuesta contra un
registro.
20-Mayo-96
SQL, SQLDAT, DOMDAT, WINCRT;
!!
$
BEGIN DECLARE SECTION
PtoGeo
:CoorGeog;
Ciudad
:Ciudad;
Temperi
:Temper;
END DECLARE SECTION;
PROCEDURE SeiAnid-TemAlt;
BEGIN
1
WRITELN('Dat0s de Altura I ) ;
WRITELN(Is============== 1 ) .
WRITE('Pt0. Geo. Lat.(Gra).: ');READ(PtoGeo.Latitud.Grado);
WRITE('Pt8. Geo. Lat.(Min).: ');READ(PtoGeo.Latitud.Minuto);
$
DECLARE CURSOR tcl FOR
SELECT *
FROM
Temper
WHERE
PtoGeo.Longitud NOT IN
(SELECT PtoGeo.Longitud
FROM Altura
IlWHERE PtoGeo.Latitud = :PtoGeo.Latitud);
$
OPEN tcl;
REPEAT 11
$ FETCH tcl INTO
:PtoGeo,
:Ciudad, :Temper;
IF SQFCODE = O THEN BEGIN
WRITELN('Pt0. Geo.Lat. (G). : ',PtoGeo.Latitud.Grado);
WRITELN('Pt0. Geo.Lat.(M).: ',PtoGeo.Latitud.Minuto);
WRITELN('Pt0. Geo.Lon.(G).: ',PtoGeo.Longitud.Grado);
WRIFELN('Pt0. Geo.Lon. (M). :
PtoGeo.Longitud.Minuto);
WRI!TELN('Ciudad ........... : ',Ciudad);
WRITELN('Temper ........... : ',Temper);
END ;
I ,
UNTIL SQLCODE <> O;
$ CLOSE tc1;
END;
89
PRUEBAS DE FUNCIONALDAD
CAPíTULO 6
I!
BEGIN
SeiAnid-T e a t
ENE.
Se ejecuto en: 5.30Minutos
I,
90
PRUEBAS DE FUNCIONALDAD
CAPfrULO 6
il
PRUEBA1 8 . EP
,
{
Prueba No. 18
Eliminar los renglones de la tabla Temper
dada una ciudad.
20-Mayo-96
Objetivo :
Fecha :
't
USES
$
SQL, SQLDAT, DOMDAT, WINCRT;
BEGIN D E C F E SECTION
PtoGeo
: CoorGeog;
Ciudad
: Ciudad;
END DECLARE SECTION;
.
.
il
PROCEDURE ConsNomTem;
BEGIN
WRITE('Ciudad .............. :
$
I ) ;
READLN(Ciudad);
I(
DELETE
Temper
Ciudad
FROM
WHERE
=
:Ciudad;
.I
WRITELN('Resu1tado de la Prueba no. 18');
WRITELN; WRITELN;
IF SQLCODE = O THEN
WRITELN('Registr0 Borrado');
END;
BEGIN
ConsNomTem
END.
1
Se ejecutó en: 4.53 Minutos.
['
91
PRUEBAS DE FUNCIONALJDm
CAPÍTULO 6
II
PRUEBA1 9.EP
I
Objetivo :
propósito:^^
Fecha:
USES
$
P r u e b a No. 19
Actualizar para cierta ciudad de la tabla
Temper l o s datos del punto geográfico en
su campo Latitud.
Verificar que la cláusula SET permita el uso
de columnas compuestas.
20-Mayo-96
SQL, SQLDAT, DOMDAT, WINCRT;
BEGIN DECLARE SECTION
PtoGeo'j
: CoorGeog;
Ciudad
: Ciudad;
Tempex
: Temper;
END DECLARE SECTION;
PROCEDURE ACtuaiiza-Tem;
BEGIN
WRITELN('Actua1ización en la tabla Temper ' 1 ;
WRITELN('================================
t ) .
!I
, WRITELN;
WRITE('Ciudad de la Cd. ........ : I ) ; READLN(Ciudad);
SELECT
INTO
$
il
FROM
WHERE
*
:PtoGeo.Latitud,
:PtoGeo.Longitud,
:Ciudad,:Temper
Temper
Ciudad =:Ciudad;
il
IF SQLCODE = O THEN BEGIN
WRITELN('Va1ores Actuales
');
WRITELN('================
1 ) ;
WRITELN]('Pto. Geo. Lat. (G). .: ',PtoGeo.Latitud.Grado);
WRITELN'('Pt0. Geo. Lat. (M). . : I , PtoGeo.Latitud.Minuto);
WRITELN('Pt0. Geo. 'Lon.(G)..: ',PtoGeo.Longitud.Grado);
WRITELNJ'Pto. Geo. Lon.(M)..: ',PtoGeo.Longitud.Minuto);
WRITELNi('Ciudad ............. : ',Ciudad);
WRITELN'('Temper............. : ',Temper);
WRITELN.('Introduce l o s Nuevos Valores I ) ;
WRITELN('============================ 7 ) .
WRITE('pt0. Geo.Lat.(G).: ');READLN(PtoGeo.Latitud.Grado);
WRITE('Pto.Geo.Lat.(M).: ');READLN(PtoGeo.Latitud.Minuto);
$
UPDATE
SET 11
WHERE¡
Temper
PtoGeo.Latitud = :PtoGeo.Latitud
Ciudad = :Ciudad;
IF SQLCODE = O THEN WRITELN('<<Registro Actualizado>>')
ELSE WRITELN('<<Registro No Actualizado>>');
END
;I
ELSE WRITELN('Registr0 No Encontrado.');
92
PRUEBAS DE F U N C I O N A L D ~
CAPfTULO 6
11
END;
BEGIN
ActualizaLTem;
END.
i,
Se ejecutó en: 12 Segundos.
93
7
CAPITULO
COMENTARIOS FINALES
En este capítulo se dan a conocer las conclusiones obtenidas en el desarrollo de esta tesis,
algunas observaciones, además de hacer mención de posibles trabajos futuros relacionados con el
desarroUo de la'presente tesis.
7.1. Conclusiones
Las definicionesbásicas del modelo relaciona1 exigen que los valores que pueden tomar los
atributos sean atómicos, lo cual implica que los datos compuestos están prohibidos. Una de las
razones por la que se introdujo tal restricción fue para simplificar el lenguaje de manipulación de
datos (LMD). La propuesta fundamental de esta tesis es que esa exigencia es demasiado estricta
El desarrollo de este proyecto tuvo como propósito demostrar la factibilidad de manejar
dominios compuestos en el modelo relacional sin afectar el LMD. El relajamiento de tal exigencia
consiste en permitir más de un elemento, pudiéndose manejar como una unidad (registro), aunque el
número de elementos de un atributo compuesto no puede ser variable. En consecuencia, se ha
propuesto extender el estándar SQL para el manejo de los dominios compuestos.
Desde hace tiempo los promotores de las bases de datos orientadas a objetos expresan como
ventaja el uso de tipos definidos por el usuario, especificamente el de los tipos complejos con respeto
a los sistemas de bases de datos relacionales (ya que el estándar de SQL indica explícitamente que
los valores deben ser atómicos). Relajando esta limitación se puede lograr el manejo de dominios
compuestos en las columnas, y con el presente trabajo de tesis se pretende demostrar la viabilidad de
manejar dominios compuestos en el modelo relacional sin necesidad de complicar el LMD.
A continuación se presenta en resumen cuáles fueron los logros obtenidos durante el
desarrollo del presente trabajo:
94
COMENTARIOS FINALES
CAPíTUl.0 7
11
Definición de nuevos tipos de datos por parte del usuario. Se elimina la limitante de
contar sólo con los tipos base (Char, Integer, L o n e t , y Date), con lo cual al usuario se le
permite disponer de un mayor número de tipos.
Mayor legibilidad en el desarrollo del código. El programador al tener las variables
nemónicas (creadas específicamente a su aplicación) podrá contar con una mayor claridad en
su código. Además de contar con las restricciones de los valores a insertar (ai defbir una
columna[enbase a un dominio).
Verificación de tipos más estricta. Este módulo evita la comparación de columnas que no
t
tengan sentido o ilógicas. Por ejemplo, si dos columnas toman sus valores del mismo
dominio, es probable que tengan sentido las comparaciones donde participen estas columnas
porque se comparan cosas similares. En cambio, si las dos columnas obtienen sus valores de
1
diferentes dominios, las comparaciones entre estas columnas sin duda carecerán de sentido.
,I
Manejo de tipos de datos estructurados. Se logra brindar las ventajas que ofrece el uso de
registros (dominios compuestos) similar a los lenguajes C y Pascai, sin afectar el LMD, con
el beneficio adicional de poder indicar qué operadores relacionales son aplicables a un
'I
dominio compuesto en particular.
11
Logro de un mayor nivel de abstracción en el manejo de datos. Con el manejo de los
dominios compuestos se logra tener un nivel más de abstracción en forma análoga a los
regishos en el caso de los lenguajes C y Pascal.
I/
Los puntos antes mencionados encierran a grandes rasgos las aportaciones obtenidas con el
desarrollo de este proyecto. La explicación detallada de los problemas involucrados, las soluciones
propuestas y su implementación se explican en los capítulos 3 , 4 y 5 de esta tesis respectivamente.
'I
7.2. Posibles Extensiones
Actualmente el uso de dominios nos permite contar con tipos deíjnidos por el usuario, tanto
tipos simples 11como tipos estructurados (registros); sin embargo, quedaría por desarrollar los
siguientes puntos:
Definición y manejo de matrices y arreglos en el estándar SQL Debido a que los arregios
y matrices tienen un nivel de abstracción aún mayor que el de los registros, facilitan aun más
el manejo de datos, principalmente en el área ingenied. Tomando en cuenta los argumentos
expuestbs para el manejo de los dominios compuestos, es de prever que la incorporación de
tipos de datos arreglo y matriz traería beneficios similares a los de los dominios.
95
'1
COMENTARIOS FINALES
CAPÍTUU) 7
1
Creación de fuociones que utilicen dominios simples y compuestos. Este proyecto podrá
beneficiar enormemente el manejo de los dominios compuestos y ser de gran.ayuda en
operaciodes que no se pueden realizar mediante las instrucciones existentes del estándar SQL,
y tal beneficio no implica alejarse de los preceptos del modelo relaciona]; algo similar a los
drspmadores se puede considerar lo anterior. Un ejemplo de esto sería obtener de un punto
geográfdo X (dato compuesto) el punto mas cercano a él.
Comparación en un orden especifico de elementos del dominio compuesto. Debido a que
'I
se tengan que compara en un orden específico los componentes de un dominio
en ocasiones
compuesto, es necesario tener una cláusula que nos permita indicarlo. Por ejemplo, sea Fecha
una c o l y a definida en base a un dominio compuesto con los elementos Dia, Mes y Año
(como dominios simples), definidos en el mismo orden; para realizar una comparación
correcta, el orden de los elementos de la columna Fecha debería ser Año, Mes y Dia.
Generakión de código para la instrucción BEGIN DECLARE SECTION para los
dominios compuestos. Actualmente se añade en forma manual el código correspondiente
a los dominios compuestos que se invocan en la instrucción BEGIN DECLARE SECTION
en la unihad predeñnida CodDomCTPU. La solución propuesta es la de modificar la rutina
que genera el código para tal mstrucción. Para esto se tendrá que ir desplazando el código ya
generado para poder insertar el nuevo código, ya que los elementos del dominio compuesto
al ser referidos, ya deben existir.
Operadores relacionales para dominios simples. Ya que el estándar SQL2 no considera
que los dominios simples tengan restricciones en los operadores de comparación (y por ende
las reuniones, uniones, ...), se propone incluirlas; ya que algunas comparaciones no siempre
tienen sentido. Por ejemplo, en el dominio SEXO con valores válidos Masculino y Femenino,
es eviddnte que las únicas operaciones aplicables a este dominio son "igual a" y "diferente
de"; "menor que" no tiene sentido.
'I
Algoritmos para determinar si el conjunto de un dominio es cerrado. Ya que los
dominios deben contener un numero finito de valores, es necesario realizar un método que
sea capaz de determinar cuando existe el conjunto cerrado, lo cual se logra en base a
comparhciones de las cláusulas de restricción, estos algoritmos son de gran importancia ya
que evitan problemas de validar correctamente los datos.
7.3. Observaciones
En esti'tesis se han presentado los resultados de un proyecto relacionado con el desarrollo
de un mecanismo que permite proporcionar el manejo de dominios en el SiMBaDD.
Con la incorporación de los dominios compuestos en el SiMBaDD, el LMD puede trabajar
de la forma normal, es decir, realizar las mismas instrucciones del estándar SQL con la ventaja de
poder manejar datos complejos, sin la necesidad de extender la sintaxis existente.
I1
96
.,
CAPfTLEO 7
COMENTARIOS FINALES
Se nota actualmente que hay gran interés en facilitar el manejo de datos complejos, y por tal
razón han surgidc! nuevas metodologías, una de éstas es la de Bases de Datos Orientada a Objetos.
Como se mencionó anteriormente, uno de los resultados de esta tesis es demostrar que el modelo
relacionai se puede extender para obtener el beneficio que ofiecen los dominios compuestos.
11
Las principales características faitantes para incluir este trabajo en un sistema comercial son
las siguientes: 11
-
-
Pruebas exhaustivas
Normas he codificación y diseño
Documentación detallada
'I
Por Último,
conviene destacar que actualmente ningún SMBDR comercial incorpora el
manejo de los dominios compuestos.
i!
97
ANEXO
A
GRAMATICA DEL
LENGUAJE
SOPORTADA POR EL SiMBaDD
SOL
!
Utilimmos la notación propuesta en I S 0 (1991), que es una extensión de la Forma BackusNaur (BNF) para especificar las cláusulas mas importantes del lenguaje SQL implementadas en el
SiMBaDD, donde se usan las siguientes convenciones:
<>
..[3
{1
I
...
Represekta los símbolos no terminales del lenguaje.
Es el operador de deñnición.
Indica elementos opcionales.
Agrupa elementos en una fórmula.
Indica una alternativa.
Indica &petición.
- Especificación de Valor
Función.- Especifica uno o más valores.
<Especificación de valor>::= <Especificación de variable> I <Literal>
- Especificación de Objeto
Función.- Especifica una o más variables.
<Especificación de objeto>::= <Especificación de variable>
- Especificación de Variable
Función.- Especifica una variable anñtriona.
98
I1
<Especificación de variable>::= a o m b r e de variable intercalada' [<Variable indicadora>]
ri
- Variable Indicadora
Función.- Especifica una variable.
I/
<Variable indicadora>::= [INDICATOR I :] <Nombre de variable intercalada>
-Nombre de Variable intercalada
Función.- Especifica una variable valida en Pascal.
<Nombré de variable intercalada>::= Es cualquier identifcador de variable válido en
Pascal
- Especificacid de Columna
Función.- Refiere una columna con nombre.
I¡
<Especificación de columna>::= [<Nombre de tabla>.] a o m b r e de columna>
- Especificación de Función de Conjunto
Función.- Refiere una columna con nombre
<Espechcación de función de conjunto>::= COUNT(*) I <Función de conjunto>
-Función de conjunto
FunciÓ&- Especifica las funciones de agregación
<Función de conjunto>::= { AVG I MAX I MiN I S U M )
- Expresión Escalar
Función.- Especifica un valor.
<Expresión esealar>::=
<Tédino>
I <Expresión escalar> + <Término>
1 <Expresión escalar> - <Término>
I1
- Término
Funcióp- Especifica un término.
-=Término>::=
<Factor>
1 <Término> * <Factor>
1 <Término> / <Factor>
II
- Factor
Función.- Especifica un valor primario.
11
99
I
<Factor>*'=
,y [+ I -1 <Primario>
- Primario
Funcit5n.L Establece un valor primario, el cual puede estar negado O no.
<Primario>::=
<Especificación de valor>
1 <Especificación de columna>
1 <Especificación de función de conjunto>
1 (<Expr&(siÓnescala&)
- Término Booleano
'I
FunciónJktablece
un predicado de comparación, el cual puede estar negado o no estarlo.
q é r m i h o booleano>::=
<Factor booleano>
1 <Término booleano> AND <Factor booleano>
11
- Factor Booleano
Función.- Establece un factor de comparación, el cual puede estar negado o no estarlo.
I/
<Factor booleano>::= [NOT] <Primario booleano>
I1
- Primario Booleano
Función.Establece un predicado de comparación, el cual puede estar negado o no estarlo
!I
<Primario booleano>::= <Predicado> I (<Condición de búsqueda>)
- Predicado
Función.- Establece un predicado de comparación el cual puede estar negado o no
1
<Predicado>::=
<Predicado de comparación>
I <Prediyado between>
I <Predicado in>
1 <Predicado &e>
I <Predicado null>
I <Predicado exists>
- Predicado de Comparación
Función.- Especifica una comparación de dos valores
I
<Predicado de comparación>::=
<Identificador> <Operador de comparación> <Especificación de valor>
II
li
100
'I
- Especificación de Valor
Función.- Permite delink valores numéricos o alfanuméricos.
i!
<Especificación de valor>::= <Valor numérico> I <Cadena de caracteres>
- Predicado Between
Función:- Especifica una comparación de rango.
<Predicado between>::=
<Expresión escalar> [NOT] BETWEEN
<Expresión escalar> AND <Expresión escalar>
I
I1
- Predicado IN
Función.- Especifica una comparación cuantificada.
n
<Predicado IN>::=
<Expresión escalar> BOT] IN (<Subconsulta> I a i s t a de valores IN>)
II
- Lista de Valores I N
Función.- Establece un conjunto de valores válidos.
n
<Lista de valores IN>::=<Especificación de valor> {, <Especificación de valor>} ..
- Predicado L
h
Función.- Especifica una comparación de "correspondencia patrón".
1
<Predicado LIKE>::=
<Especificación de columna> WOT] LIKE <Cadena de caracteres>
11
- Predicado NULL
Función.- Especifica una prueba para un valor nulo.
I
<Predicado N I J L k : = <Especificación de columna> IS [NOT] NLnL
- Predicado EXISTS
Función.- Especifica una prueba para un conjunto vacío
<Predicado EXISTS>::= EXISTS <subconsulta>
- Literal
Función.- Establece valores numéricos o alfanuméricos.
<Literal>::= <Valor numérico> I <Cadena de caracteres>
- Valor Numérico
Función.- Establece un conjunto de dígitos.
II
101
1
<valor numérico>::= <Di&>
I <Valor m m e n C O >
<figto>
- Cadena de Caiacteres
Función.- Establece un conjunto de caracteres alfanuméricos
<Cadena'I de caracteres>::=
<Letra>
1 <Letra>11 <Cadena de caractere@
I <agito> <Cadena de caracteres>
- Ideotificador 1
Función.- Establece un conjunto de caracteres alfanuméricos
<IdentiFicador>::=
<Letra>
1 <Letra> <Identiíicador>
1 <Letra> <Digto>
1 <Letra> <Dígito> <Identificador>
- Letra
I
Función.- Establece un conjunto de letras mayúsculas y/o minúsculas.
1
<Letra>::= %Letra mayúscula> I <Letra minúscula>
-Relación de Símbolos Terminales
<Letra mayúscula>::=
AIBI~IDIEIFIGIHIIIJIKILIMINIÑIOIPIQIRISITIUIVIWIX
Z
<Letra 'hinúscuia>::=
a I b I c I d I e l f 1 g l h I i l j I k1lI m l n l ñ l o I P
I
Ir1 S I t l u l v IwI x l y I z
<Dígit&::= O 1 1 I 2 I 3 1 4 I 5 I 6 I 7 I 8 I 9
<Operador de comparación>::=
I/
I I < I > 1 <= I >=
O =
102
PROCEDIMYIEFUNCIONES
NTOS
Ip
MPLE'
DOMINIos
En este anexo se describen brevemente los procedimientos y funciones mencionados en el
pseudocódigo del Capítulo 5 . Además se menciona el uso de algunas variables globales, con el
propósito de tener una mejor comprensión del funcionamiento de dicho pseudocódigo.
Funciones.
CreaTabla(Nodo, W). Recibe como parámetro de entrada el nombre de la computadora
donde desea crear la tabla en la variable Nodo y la estructura de la tabla en W. Su función
es crear una tabla en el nodo especificado.
4
DomDefault. Regresa un valor verdadero si el dominio permite la cláusula default, de lo
contrado regresa un valor falso.
YaExisteCol(LexVa1, W, NoCol). Realiza una búsqueda de la columna (recibida como
parámet~oen LexVal) en la estructura de una tabla (recibida en W); esta función regresa un
valor v&dadero si encontró la columna, además de su posición en la estructura en la variable
de salida NoCol, de lo contrario regresa un valor falso.
ExistColUniq(PosCol)Esta función regresa un valor verdadero si ya se encuentra deñnida
como h Q U E ?
la columna referida por el parámetro de entrada PosCol.
103
,
!I
-
Tipo(TipoC, NoCol). Regresa un valor verdadero si el tipo especificado por la variable
I
TipoC para la columna referida por la variable NoCol es válido, de lo contrario regresa un
valor falso.
-
TQd). Retorna un valor verdadero si el parámetro de entrada Id es un identiíicador (tabla,
column~'Idominiossimple, dominios compuesto, índice), de no ser así retorna un valor falso.
Procedimientos.'I
-
-
-
ColocaDomsEnTab(W, NoCol). Este procedimiento se encarga de guardar los elementos
del dominio compuesto (apuntado por la variable global AptDomC) en la estructura de la
tabla W (en el DAD), retornando la posición del Último elemento almacenado en tal
estructura a traves del parámetro NoCol.
Get-TokenEste procedimiento se encarga de leer las unidades léxicas de manera secuencial
del programa fuente.
ObtenElemDomCí,Id).Re~esaen el parámetro de salida Id el identificador leído de manera
secuencia1del programa fuente, diferenciándose del procedimiento Get-Token en que éste
contind si después de un identificador sigue un punto.
I/
Variables Globales
-
LexVal '
-
AptDomC
Apuntador global que apunta al dominio compuesto activo (en uso).
-
SQLCODE
Variable que almacena el estado en que finalización una instrucción (exito,
error, valor(es) no encontrado(s)).
-
E
Variable que indica el tipo de error si lo hay (Ciclo en un dominio compuesto,
Id. duplicado, etc.).
11
Variable que toma su valor en el procedimiento Get-Token y contiene un
lexema.
104
ANEXO
LISTA ';DEERRORES
c
En este anexo se descriien los tipos de errores utilizados para mostrar los mensajes de error
en la implementación de los dominios, cabe hacer mención que la variable S se utiliza como
parámetro.
No. de Error
177
178
179
180
181
182
183
184
Tipo de Error
IDENTIFICADOR DE DOMINIO DUPLICADO
ID DE RESTRICCIÓN DEL DOMINO U AL ID. DEL DOMINIO
ELEMENTO DEL DOMINIO COMPUESTO DUPLICADO
ELEMENTO DEL DOMINIO COMPUESTO = AL.ID.DE DOMINIO
DOMdIO INEXISTENTE + S
CICLO E N +S
VALOR DEFAULT NO PERMITIDO EN COL. DEF SOBRE DOM COMP
l N C O h C T 0 INCLUIR COL. DEF. SOBRE DC EN ELEMS. DEL SELECT LIST
105
REFERENCIAS
1 ~ ~ 9 3 DE
4 MIGUEL, ADORACION MMARIO G. PIATTINI, Concepción y Diseño
deBases de Datos delModelo E/R al Modelo Relacional., Madrid, España:
Addison-Wesley Iberoamericana, c1993, pp. 406 - 410.
i/
[KOR93a]
KORTH, HENRY F. M ABRAHAM SILBERSCHATZ,Fundamentos de Bases
de Datos., Madrid, España: McGraw-Hill Interamencana, 2a Edición, ~1993,
pp.
643 - 678.
w ~ 9 3 b i -,
I/
[KOR93b]
pp. 400 - 401.
-,pp. 670 - 672.
I1
[DAT93a]
~
~
9
DATE, C. J., Una Introducción a los sistemas de Bases de Datos. U S A AddisonWesley,
5a. Edición, c1993, pp. 739 - 771.
I/
3-, ~ pp.1239 - 281.
11
[KOR93C]
-,p. 23.
[DAT93b]
1 , 7 7 6 - 813.
[GR092a]
GROFF,
JAMES R. M PAUL N.WEINBEG, Aplique SQL., McGraw-W
1
hteramencana, Marzo 1992, pp. 47 - 49.
~
~
9
BOR93dl
3-, 4 pp. 425 - 431.
-, p. 101 - 102.
II
P A T 9 5a]
DATE, C. J., An Introduction to Database Systems. USA Addison-Wesley, 6a
Edición, Marzo 1995, pp. 89 - 100, 139 - 174.
I/
[GR092b]
I
-,pp.55-57.
I/
PAT93cI
-,pp. 258 - 259.
[SOS95]
SOSA, VICTOR J., "Arquitectura Cliente Servidor en un Manejador de Bases
de Datos Relacionai". Cuemavaca, Mor.: Centro Nai. de Investigación y
Desarrollo Tecnológico, 1994, pp. 19 - 27, (Tesis de Maestría).
'I
[DAT95b]
-,pp. 79 - 103.
II
~
~
9
3 -4,p. 429.
106
Info-,
INFORMIX-STAR Versión 5.O for the UNIX Operatingsystem, Junio
1992 (Folleto Técnico).
I/
&OC94]
KOCW G., Oracle 7 manual de referencia, Osbome-McGraw W, c1994, pp.
94196.
pAT95cI
-',
DIG911
DIGITAL EQUIPMENT CORPORATION, VAxRdb/bWS SQL Reference
Manual,Manual de Referencia, Maynard Massachusetts, USA, Diciembre 1991
wIC87al
MICROSOFT CORPORATION, Microsoft SQL Server, The Sybase SQL Server
database for PC network: An overview of technology for tomorrow Workgroup.,
Boletín Microsoft, c1987.
&OR93e]
-,pp. 455 - 473
PAT95 d]
- pp. 246-252
wIG93fl
-,i pp. 879 - 891.
pp. 85 - 86.
I )
DAT95eI
/I
2,
pp. 133,423 - 435,
FnW3gI
-,pp. 929 - 936.
wCS7bI
NIG93hl
-,pp. 847 - 861.
NG93il
-,pp. 873 - 878.
[Is0921
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (BO),'
"Database Languaje SQL", Documento ISO/IEC 9075: 1992 (E).
FnG93jl
7 p.
,
492.
[GRO92c]
-, pp. 28 - 29.
~ 0 9 6 1
1
KROENKE. DAVID M M K. DOLAN. Procesamiento de Bases de Datos,
Funhmentos, Diseño e Instrumentación., 5a. Edición, Mexico: Prentice Hall,
c1:996,p. 271.
-,p. 492,
-, pp. 262 - 264,315.
107
'1
PAT891
Date, C. J., A Guide to then SQL Standard., 2a. Edición, Addison-Wesley, c1989,
11
pp. 1- 3.
[GRO92d]
-',pp.
PAT93eI
-, ,'pp. 244 - 252.
LWIR871
WJRTH, N., Algorihos y Estructuras de Datos., 2a. Edición, Prentice Hall,
c1987, p. 36.
7 - 11.
MCROSOFT CORPORATION,Microso$ Windowsfor Workgroups, Versión
3.11, c1992. (Manual Técnico).
[PAS911
11
BORL,AND INTERNATIONAL, TURBO PASCALfor Windows, Programme 'r,
Versión 1.5, c1991 (Manual Técnico).
I/
[GUZ90]
GUZMAN, S. R, Desarrollo de un Lenguaje de Manipulación de Datos para un
Manejador de Datos Distribuida (BDD), Puebla, h e . : Esc. de Ciencias FísicoMatemáticas, Universidad Autónoma de Puebla, 1990. (Tesis Profesional).
!I
MICROSOFT CORPORATION,Disk Operating System (DOS), Versión 3.3.
c1986. (Manual Técnico).
li
PEREZ, J. O., Algoritmo para elMantenzmiento del Diccionario de Datos de una
Base de Datos Distribuida Experimental, Cuemavaca, Mor.: Instituto
Tecnológico y de Estudios Supenores de Monterrey, 1988. (Tesis de Maestría).
'I
Arellano, V.M., Precompilador del Lenguaje de Manipulación de Datos Basado
en SQL para un Manejador de Bases de Datos Distribuida Experimental,
duernavaca, Mor.: Centro Nal. de Investigación y Desarrollo Tecnológico, 1992.
(Tesis de Maestría).
II
[IS0891
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION(ISO),
"Database Languaje SQL WithIntegrity Enhacement", Documento ISO/EC
9075:1989 (E).
pAT93fl
-,p. 140.
108
1
BIBLIOGRAFÍA
~
~
9
V. M., Precompilador del Lenguaje de Manipulación de Datos Basado
2 Arellano,
1
en‘!SQLpara un Manejador de Bases de Datos Distribuida Experimental,
Cuemavaca, Mor.: Centro Nal. de Investigación y Desarrollo Tecnológico, 1992.
(Tesis de Maestría).
PAT891
Date, C. J., A Guide to then SQL Standard., 2a. Edición, Addison-Wesley, c1989.
PAT931
DATE, C. J., Una Introducción a los sistemas de Bases de Datos. USA: AddisonWesley, 5a. Edición, c1993.
PAT951
DATE, C. J., An Introduction to Database Systems. USA Addison-Wesley, 6a.
E&ciÓn, Marzo 1995.
PIG911
DIGITAL EQUIPMENT CORPORATION, VAX Rdb/WS SQL Reference
Manual,Manual de Referencia, Maynard Massachusetts, U S 4 Diciembre 1991.
11
!I
[GRO92]
GROFF, JAMES R M PAUL N.WEINBEG, Aplique SQL., McGraw-W
Interamencana, Marzo 1992.
[GUZ90]
GUZMAN, S. R, Desarrollo de un Lenguaje de Manipulación de Datos para un
Munejador de Datos Distribuida (BDD), Puebla, h e . : Esc. de Ciencias FísicoMatemáticas, Universidad Autónoma de Puebla, 1990. (Tesis Profesional).
~ 9 2 1
Informix, INFOMIX-STAR Versión 5. O for the UNIX OperatingSystem, Junio
1992 (Folleto Técnico).
[IS0891
WTERNATIONAL. ORGANIZATIONFOR STANDARDIZATION (ISO),’
”DatabaseLanguaje SQL With integriq Enhacement”, Documento ISO/IEC
9075:1989 (E).
!I
[NO921
INTERNATIONAL. ORGANIZATIONFOR STANDARDIZATION (ISO),
“DatabaseLunguaje SQL“, Documento ISOíiEC 9075: 1992 (E).
[KOC94]
KOCH, G., Oracle 7 manual de referencia, Osbome-McGraw W, cl994.
[KOR93]
KORTH, HENRY F. M ABRAHAM SKBERSCHATZ, Fundamentos de Buses
de Datos., Madrid, España: McGraw-W interamencana, 2a Edición, c1993.
~ 0 9 6 1
KROENKE. DAVID M M K. DOLAN. Procesamiento de Buses de Datos,
hndamentos, Diseño e Instrumentación., 5a. Edición, Mexico: Rentice Hail,
c1996.
I1
109
MICROSOFT CORPORATION, Disk Operating System (DOS), Versión 3.3.
c1986. (Manual Técnico).
I1
MICROSOFT CORPORATION, Microsoft SQL Server, The Sybase SQL Server
database for PC network An overview of technology for tomorrow Workgroup.,
Boletín Microsoft, ~ 1 9 8 7 .
dCROSOFT CORPORATION,Microsoft wmi"indavfor Workgroups, Versión
3.i!, c1992. (Manual Técnico).
D i ,MIGüEL, ADORACION Tyl MARIO G. PIATTiNI, Concepcióny Diseño
de Bases de Datos del Modelo E/R al Modelo Reiacional., Madrid, España:
Addison-Wesley Iberoamericana, cl993.
BORLAND INTERNATIONAL,, TURBO PASCAL for Windows, Programme'r,
Versión 1.5, c1991 (Manual Técnico).
'I
PEREZ, J. O , Algoritmo para el Mantenimiento del Diccronarro de Datos de una
Base de Datos Distribuida Experrmental, Cuemavaca, Mor.: Instituto
Tedológico y de Estudios Superiores de Monterrey, 1988. (Tesis de Maestría)
I/
S O S L VICTOR. J., "Arquitectura Cliente Servidor en un Manejador de Bases
de D4tos Relacional" Cuemavaca, Mor : Centro Nal. de Investigación y
Desarrollo Tecnológico, 1995, (Tesis de Maestría).
WiRTH, N., Algorihm y Estructuras de Datos., 2a. Edición, Prentice Hall,
~1987;.