y desarrollo tecnologico cenidet
TRANSCRIPT
S.E.P. s.JE.I.T. D.G.I.T.
CENTRO NACIONAL DE INVESTIGACION
Y DESARROLLO TECNOLOGICO
cenidet PRECOMPILADOR DEL .LENGUAJE DE MANIPULACION DE DATOS BASADO EN SOL PARA UN MANEJADOR DE BASES
DE DATOS DISTRIBUIDAS EXPERIMENTAL
T E S I S OUE PARA OBTENER EL GRADO DE
MAESTRO EN CIENCIAS DE LA COMPUTACION P R E S E N T A :
VICTOR MANUEL ARELLAND MONTES
-P CENTRO DE INFORMACIM
C E N I D E T <
CUERNAVACA, MOR. MAYO DE 1992
Centro Nacional de Investigación y Desarrollo Tecnológico
ACADEMIA DE LA MAESTRIA EN CIENCIAS DE LA COMPUTACION
Cuernavaca, Mor., a 7 de Abr i l de 1992
DI-. Juan Manuel Ricaño C a s t i l l o Di rec tor d e l CENIOET P r e s e n t e .
A t -n . : Ing. Reyes Hernández Diaz J e f e d e l Depto. de Computación.
Por e s t e conducto, hacemos de su conocimiento que, deepués de - haber sometido a r e v i s i 6 n e l t r a b a j o de tesis t i t u l a d o :
"PRE(XKP1LADOR DEL LñNWAJB DE MAh'IPULACION DE DATOS BASADO EN SQL PARA UN M A N E J D R DE PASES DE DATOS DISTRIBUIDAS KXPERItfENTAL"
Desarrol lado por e l L . I . VICPOR MANUEL ARELLANO MONTES y habiendo cumplido con todas las co r r ecc iones que se l e ind icaron . estamos de acuerdo en sue se l e conceda l a au- - t o r i z a c i ó n de impresibn de l a tesis, grado.
S in o t r o p a r t i c u l a r , quedamos de u s t e d .
A t e n t a m e n
n Comisión Revisora
y l a fecha de esamen de
t e
Y mm:, , I I . 1
M.C. Ortega
av icenc io F. Rodrígues M.C.
Interior Internado Paimira S/N C.P 62490 Apartado Postal 5-164, C.P. 62050 Cuernavaca, Mor. México
Tels.: (73) 18 77 41 y (73) 12 76 13 cen¡det/
Centro Nacional de Investigación y Desarrollo Tecnológico
DIRECCION SUBDIRECCION ACAVEMICA OF. No.0030/92
Cuernavaca, Mor., a 10 de abr i l de 1992.
L i c . V i c t o r Manuel Arel . lano Montes Candida to a l Grado d e Maestro e n C i e n c i a s de l a computación P r e s e n t e .
Después de h a b e r somet ido a r e v i s i ó n s u t r a b a j o de tesis t i t u l a d o :
"PRGCOMPILADOR EN SQL PARA UN MANRJADOR DE BASES DE DATOS DISPRIBUIDAS EXPERIMENTAL"
DEL LKNGUAJE DE MANIPULACION DR DATOS BASADO
Y habiendo cumplido con t o d a s las ind i . cac iones yue e l Ju rado Revisor de T e e i s l e h i z o , se l e comunica que s e ' l e concede a u t o r i z a c i ó n para que proceda a l.a impres ión de l a m i s m a . iccxno r e q u i s i t o para la o b t e n c i ó n d e l g rado .
- - - m Interior Internado Palmira S i N C.P. 62490 Apariado Posial5-164. C.P. 62050 Cuernavaca, Mor. México
Tels.: (73) 18 77 41 y (73) 12 76 13 Ü L
iGraclas Senor Jesris!
A m i madre: ai lnspiracltm y m i gran orgu l lo . . .
A a13 adorables y entraiíables SoBrInos Erika y Arturo.
A nil Querida esmsa Irma y a nuestro amado y esperado hi jo , con todo m i amor...
AGRADECIMIENTOS
Agradezco a mis hermanos Cecilia y Julio; y a mi sobrina Sandra, todo cuanto hicieron y contribuyeron para que llegara al final de mis estudios de maestría.
Agradezco de manera muy especial y con todo respeto, a mi querida culada Luisa por su infinita paciencia y por su gran apoyo.
Expreso mi más sincero agradecimiento ai CENIDET por darme la oportunidad de cursar mi maestría en computación; en especial a todos mis profesores por sus conocimientos.
Reconozco y agradezco el apoyo económico brindado por el CüNACYT para mis estudios y tesis de maestría.
Gracias al Instituto de Investigaciones Eléctricas por las facilidades dadas para la realización de este trabajo de tesis.
Agradezco a todo el personal del Departamento de Sistemas de Información del IIB por su apreciable apoyo; en especial a m i s compañeros de tesis por hacer mi estancia más agradable.
Agradezco a mi asesor de tesis, el M.C. Joaquín Pérez Ortega, su apoyo, orientación y tiempo dedicado para la realización de este trabajo.
Expreso mi agradecimiento al Dr. Rodolfo Pazos Range1 por su incondicional apoyo e interés para este trabajo; por sus apreciables consejos y por sus valiosos conocimientos aportados.
Agradezco de manera muy en especial a mi amiga Eva Palacios Salazar por su incondicional ayuda, apoyo y confianza brindada. Este trabajo de tesis, así como los correspondientes estudios de maestría, se deben en gran parte al apoyo brindado por ella: Gracias por tu confianza y amistad.
TABLA DE CONTENIDO
CAPTITULO 1
INTRODUCCION' ................................................ 1
1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11 1.12
Importancia de las bases de datos distribuidas (BDDs) . 2 Antecedentes de las BDDs y concepto ................... 2 Motivaciones de las bases de datos centralizadas ...... 2 Motivaciones de las bases de datos distribuidas ....... 2 Problemática de las bases de datos distribuidas ....... 3 Beneficios de las bases de datos distribuidas ......... 3 Bases de datos distribuidas y el modelo relacional .... 4 El lenguaje SQL ....................................... 4 Antecedentes de la tesis .............................. 5 Objetivos ............................................. 6 Alcances .............................................. 6 Organizaci6n de la tesis .............................. 7
CAPITULO 2
CONCEPTOS SOBRE BASES DE DATOS DISTRIBUIDAS. BASES DE DATOS RELACIONALES Y COMPILADORES ........................... 8
2.1 2.2 2.3 2.4 2.5 2.6
2.7 2.8
Bases de datos distribuidas ........................... 8 Motivaciones para el desarrollo de BDDs ............... 8 Sistema administrador de bases de datos distribuidas .. 10 Problemática en el desarrollo de BDDs ................. 11 Estado del arte en BDDs ............................... 11 Ventajas del proyecto de tesis versus productos comerciales ........................................... 13 Las BDDs y el modelo relacional ....................... 14 El modelo relacional y las bases de datos relacionales 14
2.8.1 Dominios .......................................... 16 2.8.2 Relaciones ........................................ 16 2.8.3 Propiedades de las relaciones ..................... 16 2.0.4 Definición de base de datos relacional ............ 17 2.8.5 Regias de integridad del modelo relaciona1 ........ 17
2.8.5.1 Llaves primarias .............................. 17 2.8.5.2 Llaves extranjeras ............................ 18 2.8.5.3 Las dos reglas de integridad .................. 19
2.8.6 El algebra relacional ............................. 19
2.9 El lenguaje SQL ....................................... 21
1
u-
2.10 Traductores. compiladores y precompiladores ........... 22
2.10.1 Modelo básico de un compilador ................... 22
CAPITULO 3
PLANTEAMIENTO Y ANALISIS DEL PROBLEMA ....................... 24
3.1 Planteamiento general del problema ..................... 24 3.2 Antecedentes del proyecto ............................. 25
de datos distribuidas .............................. 26 El precompilador del lenguaje de definición de datos .............................................. 30
3.3 El proceso de análisis ................................ 32
3.3.1 El problema del análisis léxico y sintáctico ...... 32 3.3.2 El problema del código equivalente ................ 36
3.3.2.1 Objetos en SQL ................................ 36 3.3.2.2 Tipos de datos en SQL y Pascal ................ 39 3.3.2.3 Las tablas como archivos en Pascal ............ 40
3.2.1 Las primitivas del sistema administrador de bases
3.2.2
3.3.2.4 Operaciones en SQL ............................ 42
3.3.2.4.1 La cláusula CREATE TABLE .................. 43 3.3.2.4.2 El estatuto INSERT ........................ 45 3.3.2.4.3 El estatuto SELECT ........................ 52
3.3.2.4.3.1 Los cursores en SQL ................... 54 3.3.2.4.3.2 La palabra reservada SELECT ........... 55 3.3.2.4.3.3 Expresión de una tabla ................ 57
3.3.2.3.3.3.1 La cláusula FROM .................. 57 3.3.2.3.3.3.2 La cláusula WHERE ................. 58
3.3.2.3.3.3.2.1 Condición de búsqueda ......... 50 3.3.2.4.3.4 Los cursores en Pascal ................ 62 3.3.2.4.3.5 Pascal y las especificacione de
consulta ............................... 68
3.3.2.4.3.5.1 La cláusula FROM en Pascal ........ 71 3.3.2.4.3.5.2 La cláusula WHERE en Pascal ....... 72 3.3.2.4.3.5.3 Pascal y el SELECT ................ 72
3.3.2.4.4 El estatuto UPDATE ........................ 74 3.3.2.4.5 El estatuto DELETE ........................ 75
ii
3.3.3 El problema de la unicidad de renglones ........... 76 3.3.4 El problema de la implementación de índices ....... 79 3.3.5 El problema del valor por omisión ................. 81
CAPITULO 4
DISEÑO DEL PRECOMPILADOR .................................... 82
4.1 El diccionario de archivos distribuidos (DAD) ......... 82 4.2 Algoritmo general de precompilación ................... 85 4.3 La traducción y evaluación de expresiones escalares ... 90 4.4 Traducci6n de las condiciones de búsqueda ............. 94
4.4.1 El predicado de comparación ....................... 95
4.4.1.1 Predicado de comparación de la forma El top . de commparación> E2 ................... 95
4.4.1.2 Predicado de comparación de l a forma El top . de comparación> <subconsulta> ......... 91
4.5 Evaluación de una condición de búsqueda ............... 98 4.6 Traducción y evaluación de una
<especificación de consulta> .......................... 98
CAPITULO 5
PRUEBAS AL PRECOMPILADOR DEL LMD ............................ 101
5.1 Objetivos de las pruebas ............................... 101 5.2 Condiciones de las pruebas ............................. 102 5.3 Presentación de las pruebas ............................ 102
CAPITULO 6
CONCLUSIONES ................................................ 136
6.1 Posibles extensiones ................................... 137 6.2 Beneficios ............................. 2 ............... 138 ANEXO A
GRAMATICA DEL LENGUAJE SQL SOPORTADA POR EL PRECOMPILADOR DEL LENGUAJE DE MANIPULACION DE DATOS ......... 140 A - 1 Elementos comunes ...................................... 140
iii
A-2 <literal> .............................................. 140
A-5 <tipo de dato> ......................................... 142 A-6 tespecificación de valor> y tespecificación objeto> .... 142 A-? tespecificación de columna> ............................ 143 A-0 <especificación de función de conjunto> ................ 143 A-9 <expresión escalar> .................................... 143 A-10 <predicado> ............................................ 144 A-11 <predicado de comparación> ............................. 144 A-12 <predicado betweem .................................... 145 A-13 <predicado in> ......................................... 145 A-14 <predicado like> ....................................... 145 A-15 <predicado null> ....................................... 145 A-16 <predicado exist> ...................................... 146 A-17 <condición de búsqueda> ................................ 146 A-18 <expresión de tabla> ................................... 146 A-19 <cláusula from> ........................................ 146 A-20 <cláusula where> ....................................... 147 A-21 <subconsulta> .......................................... 147 A-22 <especificación de consulta> ........................... 147 A-23 <definición de tabla> .................................. 147 A-24 <definición de columna> ................................ 148 A-25 <cláusula default> ..................................... 148 A-26 <definición de restricción de tabla> ................... 148 A-21 <definición de restricción de unicidad> ................ 149 A-28 <estatuto close> ....................................... 149 A-29 <declaración de cursor> ................................ 149 A-30 <estatuto delete> ...................................... 149 A-31 <estatuto fetch> ....................................... 150 A-32 <estatuto insert> ...................................... 150 A-33 <estatuto open> ........................................ 150 A-34 <estatuto select> ...................................... 150 A-35 <estatuto update> ...................................... 151 A-36 Elementos de un programa en Pascal con SQL inmerso 151
A-3 <token> ................................................ 141 A-4 Nombres ................................................ 142
.....
ANEXO B
PRIMITIVAS DEL SISTEMA ADMINISTRADOR DE BASES DE DATOS DISTRIBUIDAS 153 ................................................
....... ~ - 1 Primitivas para la apertura y cierre de archivos 153
B-1.2 Cierrra2 153 .............................................. B-1.1 Abre2 153 ...........................................
B-2 Lectura. escritura. modificación y borrado de registros .............................................. 154
............................................... ........................................... B-2.1 Lee2 154 B-2.2 Escribe2 154
iv
8-2.3 Modifica2 .......................................... 155 B-2.4 Borra2 .............................................. 155
B-3 Reservación y liberación de registros .................. 155 B-3.2 LibReg2 ............................................ 156
B-4 Borrado y creación de archivos ......................... 156
B-4.1 BorraArch2 ........................................... 156 B-4.2 CreaArch2 .......................................... 156
8-3.1 ResReg2 ............................................ 155
ANEXO C
EXTENSIONES A LA NORMA DE SQL ............................... 158
C-1 <especificación de nodo> ............................... 158 C-2 <tipo de dato fecha> ................................... 159 C-3 <literal fecha> ........................................ 159 C-4 Variables anfitrionas para el tipo de dato Date ........ 160 C-5 testatuto drop table> .................................. 161 C-6 <estatuto create index> ................................ 161 C-7 testatuto drop index> .................................. 162 C-8 <estatuto lock table> .................................. 162 C-9 testatuto unlock table> ................................ 163
BIBLIOGRAFIA Y REFERENCIAS .................................. 164
V
LISTA DE FIGURAS
Figura
2.1
2.2
2.3
2.4
2.5
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
Título
ELEMENTOS DE UNA TABLA.
ELEMENTOS DE UNA RELACION.
OPERADORES DE CONJUNTO TRADICIONALES.
OPERADORES RELACIONALES ESPECIALES.
COMPONENTES DE UN COMPILADOR.
BASE DE DATOS DISTRIBUIDA S, P, SP.
Página
15
15
20
21
23
26
DISTRIBUCION DEL DICCIONARIO DE ARCHIVOS DISTRIBUIDOS (DAD).
ESTRUCTURA DEL DAD.
ESTRUCTURA DEL PRECOMPILADOR DEL LDD.
PROCESO DE PRECOMPILACION Y GENERACION DE CODIGO EJECUTABLE.
DIAGRAMA DE ESTRUCTURA GENERAL PARA UNA PROPOSICION
ESTRUCTURA DE DATOS PARA EL TEXTO PASCAL GENERADO.
ESTRUCTURA DE LAS TABLAS S, P Y SP DE LA BDD DE LA FIGURA 3.1.
DESCRIPCION DE LA TABLA S DE LA BDD DE LA FIGURA 3.1.
ARCHIVO DE TIPO.
TIPO DE REGISTRO (SIN PARTE VARIANTE).
vi
28
29
31
33
33
35
31
38
40
41
3.12
3.13
3.14
3.15
3.16
3-17,
3.18
3.19
3.20
3.21
3.22
3.23
3.24
3.25
3.26
3.27
3.28
3.29
3.30
3.31
3.32
REPRESENTACION DE UNA TABLA MEDIANTE UN ARCHIVO DE TIPO.
TIPO DE REGISTRO ASOCIADO A LA TABLA S.
CREACION DE UNA TABLA DESDE PASCAL.
PROGRAMA EN PASCAL Y SQL PARA AGREGAR UN RENGLON A LA TABLA S.
DESCRIPCION DE LA TABLA Q.
FORMULACION EN SQL PARA LA CONSULTA: NUMERO DE PROVEEDOR Y NOMBRE PARA AQUELLOS PROVEEDORES QUE ESTAN LOCALIZADOS EN 'LONDRES! ( 1 .
EJEMPLO DEL ESTATUTO SELECT EN MODO INTERCALADO.
EJEMPLO DEL USO DE CURSORES EN PASCAL.
SINTAXIS DEL ESTATUTO SELECT.
EJEMPLO DE UNA SUBCONSULTA.
PRODUCTO CARTESIANO DE LAS TABLAS S Y P.
CODIGO EN PASCAL Y PSEUDOCODIGO PARA LA CONSULTA DE LA FIGURA 3.19.
CONSULTA PARA OBTENER LOS NUMEROS DE PROVEEDORES QUE SUMINISTRAN LA PARTE ' p l ' .
"OBTENER EL
CONSULTA PARA OBTENER LOS NUMEROS DE PROVEEDORES QUE SUMINISTRAN LA PARTE ' p l ' MEDIANTE SUBCONSULTAS.
PRODUCTO CARTESIANO PARA DOS TABLAS CUALESQUIERA A Y B.
EJEMPLO DEL ESTATUTO UPDATE.
RESULTADO DEL PROGRAMA DE LA FIGURA 3-27.
EJEMPLO DEL ESTATUTO DELETE.
RESULTADO DEL PROGRAMA DE LA FIGURA 3-29.
EJEMPLO DE ESPECIFICACION DE LA RESTRICCION DE UNICIDAD.
ELEMENTOS DE UNA PAGINA DE UN ARBOL B.
v i l
41
43
44
48
50
52
53
55
56
56
58
64
69
70
71
74
74
75
76
77
80
3 . 3 3 EJEMPLO DE UN ARBOL E. 80
3 . 3 4 EJEMPLO DE DEFINICION DE UNA COLUMNA CON UN VALOR POR OMISION. 81
4.1 AUTOMATA PARA RECONOCER LA SINTAXIS DEL ESTATUTO INSERT. 86
4 . 2 PROGRAMA EN SQL Y PASCAL PARA ADICIONAR UN RENGLON A LA TABLA S. 88
ESTATUTO INSERT. 90
4.4 PROGRAMA QUE MUESTRA EL USO DE FUNCIONES. 91
4 . 3 ESTRUCTURA DE UN NODO DE LA LISTA DEL VALUES EN UN
viii
CAPITULO 1
INTRODUCCION
Los principales problemas que se abordaron en esta tesis son:
a) El desarrollo de un precompilador el cual tiene como entrada un programa fuente escrito en Pascal con estatutos de SQL intercalados y produce como salida otro programa en Pascal semánticamente equivalente al de entrada. Este programa actuará sobre una base de datos distribuida establecida sobre una red local de computadoras, tomando en cuenta la transparencia de localización y el acceso concurrente a los datos. Las tablas de la base de datos no podrán fragmentarse ni horizontal, ni verticalmente; y tampoco podrán existir en forma redundante en la base de datos.
b) En la implementación de los estatutos del lenguaje de manipulación de datos se abordaron los siguientes problemas:
1) La implementación de un valor por omisión para una columna cuando un renglón es insertado en una tabla.
2 ) La implementacíon física de índices para soportar la especificaci6n de restricción de unicidad para una tabla.
3 ) La implementación del diccionario de datos para manejar la información completa referente a una tabla (columnas, indices, valores por omisión, etcbtera).
1
1.1 Importancia de las bases de datos distribuidas (BDDs) -.-.
La tecnología de bases de datos distribuidas es uno de los desarrollos más recientes e importantes en el área de sistemas de bases de datos. Actualmente se cree que la tecnología de bases de datos distribuidas impactará el procesamiento de datos de la misma manera en que los sistemas de bases de datos centralizadas lo hicieron en la década de los 80s [l]. Existen opiniones por parte de expertos en esta área de que en los siguientes diez años los manejadores de bases de datos centralizadas (MBDC) se moverán hacia manejadores de bases de datos distribuidas (MBDD) [ 2 ] . El intenso interés en este tema tanto de parte de la comunidad investigadora como del mercado comercial respalda esta opinión [ 3 ] .
1.2 Antecedentes de las BDDs y concepto
Las BDDs se han desarrollado debido a la disponibilidad en años recientes de dos tecnologías: bases de datos y redes de comunicaciones para computadoras.
De una manera general, se puede decir que una base de datos distribuida (BDD) es aquélla en la cual sus archivos se encuentran repartidos en diferentes computadoras de una red pero que se presentan al usuario como si estuvieran en una sola computadora, es decir, el usuario tiene una vista centralizada de los datos.
1.3 Motivaciones de las bases de datos centralizadas
Una de las motivaciones principales detrás del uso de los sistemas de bases de datos, es el deseo de integrar los datos operacionales de una empresa y suministrar un acceso controlado y centralizado a estos datos. L o s sistemas de bases de datos centralizadas (SBDC), en la década de los 80s, suministraron este control centralizado y diferentes manejadores comerciales fueron usados ampliamente [ 4 ] . En general, los modelos jerárquico y de red fueron en esa época los modelos usados en bases de datos [ 5 ] . El modelo relaciona1 empezó, a finales de los 7 0 s , a ganar gran aceptación convirtiéndose a la fecha en el modelo más usado [6].
1.4 Motivaciones de las bases de datos distribuidas
Una vez que las organizaciones empezaron a estar concientes de las grandes ventajas de la integración de sus datos en bases de datos, comenzaron a sentir el impacto de algunos de los problemas causados por tener una base de datos centralizada para una organización compuesta de diversas unidades operando en diferentes sitios. En algunas organizaciones con unidades dispersas geográficamente y mfiltiples computadoras interconectadas por medio de una red de comunicaciones, el tiempo de respuesta de los
2
programas que usaban la BDC, como resultado de tener acceso a un sitio central para extraer y/o introducir datos, result6 que era muy lento. Además del incremento en los tiempos de respuesta al usar líneas de comunicaciones para transmitir datos y consultas de, y a un sitio central, existía el problema relacionado con la autonomía y privacidad de los diferentes sitios de la organización distribuida geográficamente.
1.5 Problemática de las bases de datos distribuidas
Para resolver algunos de estos problemas, se vi6 la necesidad de tener en cada sitio una parte de la base de datos de la organizaci6n. De esta manera, los datos para aplicaciones locales estaban disponibles en el sitio donde se originaran y cada sitio podía entonces tener control y autonomía sobre sus datos. De este esquema, como se puede observar, surgieron diiicultades cuando los datos en múltiples sitios tenían que ser accesados por aplicaciones que se ejecutaban en diferentes sitios. Las aplicaciones tenían que estar conscientes de d6nde y en cuál base de datos se localizaba una dato particular y tenían que asegurarse de que, si existían copias del mismo dato en múltiples sitios, todas las copias fueran actualizadas apropiadamente cada vez que una copia fuese modificada. Otra de las dificultades que surgi6 fue la del control del acceso a un mismo tiempo, a un mismo dato por diferentes aplicaciones que se ejecutaban en diferentes sitios.
Claramente, lo que se necesitaba era un sistema administrador de bases de datos distribuidas (SABDD) que considerara la existencia de las múltiples bases de datos y que soportara el acceso transparente a l o s datos distribuidos, es decir, que las aplicaciones pudieran accesar cualquier dato de cualquier base de datos sin tomar en cuenta en qué sitio estuviera el dato. Además, el SABDD tendría que considerar la existencia de múltiples copias y hacer la existencia de estas copias transparente a los programas de aplicación. En cualquier momento que se hiciera un cambio a un dato, el sistema automáticamente aseguraría que todas las copias del dato fueran actualizadas.
1.6 Beneficios de las bases de datos distribuidas
Algunas de las organizaciones o empresas que pueden beneficiarse con el uso de BDDs, son aquéllas que se encuentran distribuidas geográficamente y en las cuales se requiere efectuar alguna clase de procesamiento de datos global que involucre la participación de los diferentes sitios de la organización y que además se preserve la autonomía de cada lugar en cuanto a sus datos locales. Entre éstas se encuentran empresas del sector eléctrico, bancario, petrolero; aerolíneas, empresas telefónicas, etcétera.
3
Otro tipo de organizaciones que pueden obtener utilidad de las BDDs son aquéllas que desean implementar un sistema de información muy grande. En este caso, en lugar de usar una máquina con enormes capacidades de procesamiento y almacenamiento, por ejemplo, una "mainframe", puede resultar conveniente dividir el sistema en varios subsistemas más o menos independientes y repartirlos en varias máquinas interconectadas.
Con el reconocimiento de la necesidad de sistemas de BDDs, vino la identificación de los problemas que tienen que ser resueltos para implementar tales sistemas. Estos problemas están relacionados principalemente con técnicas para suministrar transparencia de localización, transparencia de redundancia, transparencia de fragmentación y transparencia de concurrencia entre otros.
1.7 Bases de datos distribuidas y el modelo relacional
Una de las tendencias significativas en BDDs ha sido la adopción del modelo relacional para su implementación. Su facilidad de uso, independencia de datos y fuerte sustento matemático, son algunas de las razones para esta tendencia. Además, la orientación a conjuntos del modelo contribuye ar la ejecución eficiente de consultas distribuidas [ 7 ] .
1.8 El lenguaje SQL
De la misma manera en que el modelo relacional se ha convertido en el modelo para implementar las BDDs, SQL (Structured Query Language) ha sido adoptado como el lenguaje más utilizado para operar con bases de datos relacionales, de hecho se ha convertido en un estándar internacional [ e ] debido, entre otras cosas, a que los accesos a una base de datos se realizan de una manera amigable al usuario, no procedimental y orientada a conjuntos. Además, debido también a su soporte de independencia de datos, resulta apropiado para el desarrollo de BDDs.
La función del lenguaje SQL es soportar la definición y manipulación de datos en una base de datos relacional. Una base de datos relacional es aquélla que es percibida por el usuario como una colección de tablas, las cuales están compuestas de renglones y columnas. El lenguaje SQL consta principalmente de dos lenguajes: un lenguaje de definición de datos (LDD) que permite la creaci6n y definicíon de tablas y un lenguaje de manipulación de datos (LMD) que permite realizar operaciones sobre las tablas tales como inserción, supresión. modificación y consultas de renglones de las tablas.
SQL puede utilizarse en dos formas. La primera es de una manera interactiva, es decir, el usuario por medio del teclado
4
introduce una expresión de SQL directamente al sistema que maneja SQL y éste realiza la operación; la segunda consiste en tener estatutos de SQL intercalados en otro lenguaje, denominado lenguaje anfitrión, P.e. COBOL, C, PASCAL o PL/1. Para usar SQL en esta última forma, es necesario contar con un proceso de precompilación el cual consiste en tomar el programa fuente escrito en el lenguaje anfitrión con los estatutos de SQL intercalados y traducirlo a otro programa fuente que conste únicamente de estatutos en el lenguaje anfitrión. Este segundo programa entonces podría ser directamente compilable por el compilador del lenguaje anfitrión y generar un programa ejecutable que fuese semánticamente equivalente al primer programa fuente con los estatutos de SQL.
1.9 Antecedentes de la tesis
Anticipándose a las necesidades que se pr-ven en el futuro, el Instituto de Investigaciones Eléctricas (IIE) realiza investigación y desarrollo en el área de BDDs con el fin de ofrecer esta tecnología al sector eléctrico en el momento en que lo necesite. Esta tesis es parte de los trabajos realizados por el IIE y tiene como propósito facilitar el desarrollo de aplicaciones para la explotación de una BDD que soporta el modelo relaciona1 en una red local de PCs. Estos desarrollos han sido realizados en Turbo Pascal versiones 4 y posteriores, la red IBM PC Network, y el sistema operativo DOS.
Cronológicamente, el primer trabajo realizado por el IIE consistió en desarrollar un conjunto de primitivas de un sistema manejador de bases de datos distribuidas [9, io], las cuales proporcionan acceso transparente y concurrente a los archivos de la BDD y además pueden ser llamadas desde Turbo Pascal. De esta manera, los archivos de la base de datos pueden ser accesados simultáneamente por dos o más procesos que se ejecuten en diferentes PCs de la red. El acceso transparente permite que una aplicación accese los archivos de la base de datos sin necesidad de conocer en qué computadora de la red se encuentran.
Las primitivas anteriores podían ser usadas desde Turbo Pascal por cualquier desarrollador de aplicaciones que deseara operar sobre la base de datos, sin embargo, requería estar familiarizado con los nombres y argumentos de las mismas. El segundo trabajo realizado por el IIE [ i l l tuvo como objetivo facilitar el uso de estas rutinas a cualquier desarrollador de aplicaciones que quisiera operar sobre la BDD sin necesidad de estar familiarizado con las rutinas. ~l trabajo consistió en desarrollar un lenguaje de definición de datos (LDD) basado en SQL el cual podía estar intercalado en un programa en Pascal. Para ésto se desarrolló un precompilador que toma como entrada un programa fuente en Pascal y CQL, y produce un programa con instrucciones de Pascal exclusivamente. De esta manera, l o s usuarios podían definir tablas y realizar ciertas operaciones sobre las mismas a través del
5
.
lenguaje SQL intercalado en Pascal.
Esta tesis tiene como propósito facilitar aún más la explotaci6n de la base de datos distribuida mediante programas escritos también en Turbo Pascal con SQL intercalado. Las facilidades consisten en que el desarrollador podrá hacer uso casi completo del lenguaje de manipulación de datos (LMD) de SQL basado en la Norma Internacional de SQL [12]. De esta forma el desarrollador cuenta con un conjunto de proposiciones de SQL más amplio, más poderoso y con un nivel no procedimental más alto.
1.10 Objetivos
Los objetivos de esta tesis son los siguientes:
a) Desarrollar el precompilador del lenguaje de manipulación de datos basado en SQL, el cual podrá intercalarse en el lenguaje de Turbo Pascal.
equivalentes a las proposiciones de SQL que permitan el acceso transparente y concurrente a la BDD.
C) Ampliar la cláusula de "CREATE TABLE" para manejar valores por omisión para las columnas de una tabla cuando se inserta un reng16n.
d) Ampliar la cláusula "CREATE TABLE" para manejar la restricci6n
e) Implementar el manejo de índices para mejorar los tiempos de acceso a una tabla cuando se trate de insertar un renglón para . una tabla que tiene declarada una restriccion de unicidad.
b) Generar proposiciones en Turbo Pascal semánticamente
' de unicidad.
1.11 Alcances
a) La forma en se utilizará el lenguaje de manipulación de datos de SQL será de una manera intercalada en lenguaje nirbo Pascal versión 6.0.
b) El conjunto de proposiciones del lenguaje de manipulaci6n de datos de SQL está basado en la Norma Internacional de SQL [ 121. Este conjunto de proposiciones se encuentra en el Anexo A de esta tesis.
c) La base de datos sobre la que se operará es una BDD en una red de computadoras personales.
d) En este trabajo no se considera el manejo de transacciones ni vistas, las cuales se encuentran especificadas en la Norma de
6
SQL . e) El código que genera el precompilador con respecto a las
consultas no considera técnicas o estrategias de optimización de acceso.
f) En este trabajo no se considera el manejo de la regla de integridad referencial. la cual se encuentra especificada en la Norma de SQL.
g) En este trabajo no se consideran las referencias externas a una columna, las cuales se especifican en la Norma de SQL.
h) En este trabajo, en una especfficaci6n de consulta, no se consideran las cláusulas GROUP BY y HAVING TO, las cuales se especifican en la Norma de SQL.
1.12 Organización de la tesis
En el segundo capítulo se hace una introducción a los conceptos sobre la tecnología de bases de datos, bases de datos distribuidas, el modelo relacional, el lenguaje SQL y sobre compiladores.
En el tercer capítulo se realiza el análisis de los objetivos y se determina la factibilidad de solución.
En el cuarto capítulo se presenta el diseño del precompilador y se explican los principales algoritmos y estructuras de datos utilizadas por el precompilador y por los programas que resultan del proceso de precompilación.
Las pruebas efectuadas al precompilador con las que se demuestra la transparencia de localización del código generado por el precompilador así como el uso de las proposiciones del lenguaje de manipulación de datos de SQL, se presentan en el quinto capítulo.
Por último, en el sexto capítulo se describen los beneficios obtenidos con esta tesis, las posibles extensiones al trabajo y las conclusiones del mismo.
CAPITULO 2
CONCEPTOS SOBRE BASES DE DATOS DISTRIBUIDAS, BASES DE DATOS RELACIONALES Y COtiPILADORES
En este capítulo se describen algunos de los conceptos sobre bases de datos distribuidas; la teoría de bases de datos relacionales; el lenguaje SQL y conceptos sobre compiladores. El objetivo es familiarizar al lector con los términos manejados a lo largo de la tesis y el carácter de l o s mismos es meramente introductorio. El lector interesado en cuestiones detalladas y más profundas puede consultar la vasta literatura que existe sobre cada tema. Las referencias a algunas de estas fuentes pueden encontrarse al final de esta tesis.
2.1 Bases de datos distribuidas
Las bases de datos distribuidas (BDDs) se han desarrollado debido a la disponibilidad en anos recientes de dos tecnologías: bases de datos y redes de computadoras.
"Una base de datos distribuida es una colección de datos los cuales están distribuidos sobre las diferentes computadoras de una red. Cada sitio de la red tiene capacidad de procesamiento autónomo y puede realizar aplicaciones locales. Cada sitio también participa en la ejecución de al menos una aplicación global, la cual requiere accesar datos de muchos sitios por medio de un subsistema de comunicaciones" [ 131.
2 . 2 Motivaciones para el desarrollo de BDDs
han motivado el desarrollo de BDDs. A continuación se presentan las razones más importantes que
a) Razones económicas y organizacionales.
Actualmente existen muchas organizaciones que son
E
descentralizadas, tanto privadas como estatales. En general, cada sitio de estas organizaciones tiene características autónomas y se encuentran dispersos geográficamente. A la vez, estos sitios como parte integral de un todo, generan información que sirve para tomar decisiones con un carácter global. Las BDDs se ajustan de manera más natural a este tipo de organizaciones. Si existe alguna aplicación global que requiere una fuerte interacción de datos remotos, resulta más económico, desde el punto de vista de costos de transmisión, si esa aplicaci6n se particiona haciendo el procesamiento localmente en cada sitio.
b) Interconexión de bases de datos existentes.
Las BDDs son la solución natural cuando en una organización con varias bases de datos ya existentes, surge la necesidad de una aplicación global. En este caso, la BDD se crea partiendo de esas bases de datos existentes (diseno bottom-up). Este proceso puede requerir un cierto grado de reestructuración local: sin embargo, el esfuezo requerido es mucho menor que la necesidad para la creación de una base de datos centralizada completamente nueva.
c) Crecimiento incremental.
Si una organización crece adicionando nuevas unidades organizacionales relativamente autónomas, el enfoque de BDDs soporta un crecimiento incremental más suave con un grado mínimo de impacto sobre unidades ya existentes.
d) Consideraciones de rendimiento.
La existencia de varios procesadores autónomos trae como consecuencia un incremento en el rendimiento a través de un alto grado de paralelismo, reduciendo de esta manera algunos inconvenientes técnicos como el excesivo tráfico en los sistemas de comunicación.
e) Cuestiones de confiabilidad y disponibilidad.
En BDDs, el tener cierto grado de redundancia puede resultar conveniente. Primero, la localidad de las aplicaciones puede incrementarse si los datos se duplican en todos los sitios donde las aplicaciones los necesiten, y segundo, la disponibilidad del sistema puede incrementarse debido a que si un sitio falla, éste no detiene la ejecución de las aplicaciones en otros sitios.
9
2.3 Sistema administrador de-bases de datos distribuidas
Un sistema administrador de bases de datos distribuidas (SABDD) es el software que permite el manejo o administración de la base de datos distribuida y tiene como objetivo principal hacer la distribución transparente a los usuarios, es decir, crear la ilusión de que todos los archivos de la base de datos se encuentran en la computadora donde está trabajando el usuario. Para que una BDD se comporte de esta manera, debe Doseer transuarencia de localizació~, transparencia de fragmentakión y transparencia de redundancia.
La transparencia de localización es aquella característica que permite a los usuarios accesar la información de un archivo cualquiera de la base de datos sin necesidad de indicar en qué computadora se encuentra el archivo.
La transparencia de fragmentación es aquella característica que permite a los usuarios accesar la información de un archivo fragmentado como si todos los registros del archivo estuvieran en una misma computadora. Es decir, cuando existe transparencia de fragmentación, el sistema crea la ilusión de que los archivos no están fragmentados.
La fragmentación de un archivo es particularmente útil cuando:
a) El archivo es tan grande que no cabe en el disco de una computadora.
b) La información del archivo pertenece a varias dependencias de una empresa que desean controlar separadamente su información.
La transparencia de redundancia es aquella característica que permite a los usuarios accecar la información de un archivo con múltiples copias, como si el archivo fuera único. Es decir, cuando existe transparencia de redundancia, los usuarios no necesitan manipular separadamente cada copia de un archivo redundante, ya que el sistema crea la ilusión de que el archivo es 6nico.
Las anteriores características son consideradas como las esenciales que una BDD debe poseer. Sin embargo, existen Otras nueve, de acuerdo a C. J Date [14], que una BDD debe poseer para ser considerada idealmente como base de datos distribuida. A continuación se numeran brevemente las nueve regias.
Regia 1: Autonomía local. Los datos locales son manejados independientemente de otros sitios.
Regia 2: No dependencia de un sitio central. Ningún sitio de la red es más necesario que cualquiera de los demás.
Regla 3 : Operación continua. Ninguna actividad planeada debe requerir interrumpir el funcionamiento del sistema.
10
Regia 4 :
Regla 5:
Regia 6 :
Regla I :
Regia 8 :
Regia 9:
procesamiento de consultas distribuidas. Las consultas a la BDD deberían optimizarse en cuanto a las rutas de acceso y tiempos de respuesta.
Manejo de transacciones distribuidas. Las transacciones que actualizan múltiples sitios deberán ejecutarse como si fueran transacciones seriales (control de concurrencia) y deberán dejar la BDD en un estado congruente si ocurriese una falla (control de recuperación). Una transacción es una unidad atómica de ejecución, es decir, es una secuencia de operaciones las cuales se realizan en su totalidad o no se realiza ninguna.
Independencia de hardware. Las BDDs deberán ser capaces de ejecutarse sobre diferentes clases de hardware, con todas las máquinas participando de igual manera.
Independencia del sistemas operativo. Las BDDs deberán ser capaces de correr bajo diferentes clases de sistemas operativos.
Independencia de la red. Las BDDs deberán ser capaces de correr con diferentes clases de redes.
Independencia de bases de datos. Las BDDs deberán ser capaces de trabajar con diferentes clases de bases de datos, suministrando las mismas interfaces.
2 .4 Problemática en el desarrollo de BDDs
De las características de una BDD listadas en 2 . 3 , se desprende que el desarrollo de una BDD es una tarea sumamente compleja. A pesar de la tecnología existente para bases de datos centralizadas, las BDDs presentan caracteristicas adicionales que las hacen más difíciles de implementar. Los principales problemas están relacionados con el manejo de la transparencia de los datos; el manejo de la redundancia de los datos (control de concurrencia y actualización); el manejo de los fragmentos de los archivos y la optimización de consultas.
2 . 5 Estado del arte en BDDs
A pesar del enorme interés de la comunidad investigadora y de las compaílíac comerciales, no existe actualmente un producto experimental o comercial que cumpla con todas las caracteristicas que un sistemas manejador de bases de datos distribuidas debe poseer [15, 161 y ésto se debe precisamente a la enorme dificultad técnica originada por los problemas mencionados antes.
11
Sin embargo, existen algunos productos comerciales como INGRES/STAR de Relational’ Technology Inc.; S Q L * S T ~ de Oracle COrp.; DB2 versión 2 Release 2 de IBM; Nonstop SQL de Tandem; los cuales of recen principalmente el manejo de transparencia de localización, algunas facilidades para el control de concurrencia y manejo de transacciones. Cabe seflalar que ninguno de estos productos ofrece un nivel suficiente de transparencia, especialemente de fragmentación y de redundancia. La tecnologia de bases de datos distribuidas está todavía inmadura. LOS productos comerciales actuales sólo implementan una porción de los requerimientos funcionales contenidos en las doce reglas mencionadas anteriormente [17].
Muchos proyectos de investigación han tenido como su principal meta el desarrollo de sistemas prototipos. Estos prototipos han contribuido al mej or entendimiento de los problemas más importantes de las bases de datos distribuidas y a la solución de algunos de ellos. A continuación se presenta de una manera resumida, una descripción de algunos de los más importantes de estos prototipos.
SDD-1 (Sistema para Bases de Datos Distribuidas) es un SABDD relacional que se diseñó e implement6 en la Corporación de Computadoras de América (CCA) [le]. SSD-1 fue uno de los primeros SABDD que se diseñaron. SDD-1 se diseñó entre 1976 y 1978, y se implement6 por el aflo de 1979 sobre computadoras DEC-10 y DEC-20. SDD-1 soporta el modelo de datos relacional. Relaciones globales pueden fragmentarse en dos pasos, primero horizontalmente y después en forma vertical; los fragmentos se pueden almacenar en forma redundante. La manipulación de las relaciones se realiza mediante Datalanguage, un lenguaje procedimental de alto nivel disponible sobre Datacomputers.
system R* es un prototipo que se está desarrollando e implementando en los Laboratorios de Investigací6n de IBM en San Jose, California [19]. La meta del proyecto R* es construir una base de datos distribuida compuesta de sitios cooperantes pero autónomos. R* es la extensión natural hacia ambientes distribuidos del prototipo System R, un sistema manejador de bases de datos relaciona1 el cual está ahora disponible comercialmente como el producto SQL/DS de IBM. LOS datos en R* se almacenan en relaciones. R* soporta transparencia de localización pero no Soporta transparencia de fragmentación ni de redundancia. R* usa SQL como lenguaje para definición y manipulación de datos y puede usarlo de manera intercalada en PL/l.
D M (Distributed Data Manager) es un sistema distribuido prototipo que soporta el modelo de datos funcional DAPLEX [ 201. DDM se está desarrollando en la Corporación de Computadoras de América (CCA), sobre máquinas DEC VA^ que corren VMS. DDM permite consultas intercaladas en Ada. Dado que DDM es el primer sistema de bases de datos en utilizar Ada y debido a que su investigación está siendo patrocinada por el Departamento de Defensa de Estados Unidos, DDM
12
.
ha ganado un enorme interés en su desarrollo. DDM permite fragmentación horizontal.
DiStributed-INGRES es un sistema que se desarrolla en la Universidad de California en Berkeley {Zl], como una versión distribuida del sistema de bases de datos relacional INGRES. Distributed-INGRES se diseR6 para operar en redes locales o en redes geográficas; y suministra a los usuarios un esquema global relacional con transparencia de localización. Distributed-INGRES soporta transparencia de fragmentación horizontal, pero no vertical. Distributed-INGRES soporta el lenguaje de datos QUEL y puede intercarlarse en lenguaje C.
porel es un sistema de bases de datos distribuidas desarrollado en la Universidad de Stuttgart en Alemania, sobre una red de minicomputadoras [ZZ]. Cada minicomputadora soporta un SABD relacional denominado máquina de base relacional (RDM) desarrollado también en el proyecto de Porel. Debido a que la transportabilidad fue uno de los principales objetivos en el desarrollo de este proyecto, Pascal se selccionó como el lenguaje de implementación. Además, a través de Pascal con RDBL (un lenguaje de bases de datos relacional similar a SQL) los usuarios de Porel pueden operar sobre la base de datos distribuida. RDBL puede utilizarse también en modo interactivo. Porel suministra transparencia de localización y fragmentación.
Es fácil darse cuenta que el esfuerzo realizado por resolver las dificultades de las bases de datos distribuidas, será recompensado con la liberación de sistemas distribuidos que vendrán a mejorar el desempeiio de los sistemas de información de muchas organizaciones, principalmente las descentralizadas y esparcidas geográficamente.
2.6 Ventajas del proyecto de tesis versus productos comerciales
A continuación se presentan las ventajas que este proyecto de tesis tiene comparado con productos comerciales actuales. Es importante seflalar que el marco de comparación está limitado al ambiente DOS y a aspectos distribuidos:
a) Actualmente ningún producto comercial permite la explotación de una base de datos distribuida mediante Pascal y SQL y
b) Ningún producto comercial ofrece la especificación de estatutos de SQL para operar sobre una base de datos distribuida en forma transparente.
.4 z 0 d 3 r
9 " ii u f.
13
2.7 Las BDDs y el modelo relaciona1
Como se mencionó en 1.7, una de las tendencias más significativas en BBDs ha sido la adopción del modelo relacional para su implementación. Su facilidad de uso, independencia de datos y fuerte sustento matemático, son algunas de las razones para esta tendencia. Además, la orientación a conjuntos del modelo contribuye a la ejecución eficiente de consultas distribuidas.
2 . 8 El modelo relacional y las bases de datos relacionales
En 1970, E. F. Codd, en ese tiempo miembro de los Laboratorios de Investigación de IBM en San Jose, California, public6 un artículo ahora clásico: "Un Modelo Relaciona1 de Datos para Bancos de Datos Compartidos Grandes" [23]. En ese artículo, Codd, declaró y estableció un conjunto de principios abstractos para manejo de bases de datos: el llamado modelo relacional. Todo el campo de la tecnología de bases de datos relacionales tiene sus orígenes en ese artículo. Las ideas de Codd condujeron a un gran número de actividades de investigación y experimentación en universidades, laboratorios de investigación industriales y establecimientos similares. Estas actividades condujeron a su vez a los numerosos productos relacionales disponibles ahora en el mercado.
Una base de datos relaciona1 (BDR) , de una manera informal, es una base de datos la cual es percibida por el usuario como una colección de tablas y las operaciones que se realizan sobre estas tablas producen nuevas tablas. Una tabla consiste de una matriz compuesta de un número fijo de columnas y de un número (variante en el tiempo) de renglones. Cada renglón consiste de un conjunto de valores simples (atómicos), un valor para cada una de las columnas de la tabla denominado valor de esa columna. La Figura 2.1 muestra un ejemplo de una tabla denominada S.
Al número de columnas en una tabla se le denomina grado de la tabla. Al número de renglones de una tabla en un momento dado se le denomina cardinalidad de la tabla.
Los términos de tabla, renglón y columnas son términos que se usan comúnmente (debido a su facilidad de manejo y percepci6n) en el campo de bases de datos relacionales. Sin embargo, estos conceptos se derivan de términos matemáticamente más formales y que pertenecen al modelo relacional. En el modelo relaciona1 se manejan los siguientes términos: relaci6n (tabla), tupla (renglón), atributo (columna) y valor de atributo (valor de columna). La Figura 2 .2 muestra la terminología formal para la tabla de la Figura 2.1.
14
Jones Renglone'i
Tabla
Ualores de oolunnas
FIGURA 2.1 ELEHEHTOS DE unn TABLA.
'. Llave primaria 'i I
Smith Relación { Jones
- Valores de atr ibutos
+ Rtributos
Tuples
FlGURR 2.2 ELEHEITOS DE UYR RELRCIOW.
A continuación se dan algunos conceptos sobre los objetos del modelo relacional, los cuales constituyen la primera de tres partes que constituyen al modelo relacional.
15
- 2.8.1 Dominios
Un dominio es el conjunto de valores atómicos posibles, todos del mismo tipo, que un atributo puede tomar. Por atómico se entiende que estos valores son simples y que no se pueden descomponer en otros valores.
2.8.2 Relaciones
Una relación sobre los dominios Di, D2, ..., Dn (no necesariamente distintos) consiste de un encabezado y un cuerpo.
El encabezado consiste de un conjunto fijo de atributos Al, A2, . . . , An, tal que cada atributo AI corresponde a exactamente uno de los dominios subyacentes Di (i= 1, 2 , ..., n).
El cuerpo consiste de un conjunto variante con el tiempo de tuplas, donde cada tupla a su vez consiste de un conjunto de pares atributo-valor (AI-Vi) (I= 1, 2, ..., n), un par por cada atributo Ai en el encabezado. Para cualquier par atributo-valor dado (Ai- Vi), Vi es un valor del único dominio Di que está asociado con el atributo Ai.
Al número de atributos de una relación se le denomina grado de la relación. una relación de grado uno se llama unaria, una relación de grado dos se llama binaria, ..., y una relación de grado n se llama n-aria. De la misma manera, al número de tuplas de una relación se le denomina cardinalidad de la relación.
2.8.3 Propiedades de las relaciones
Las relaciones poseen ciertas propiedades importantes, todas ellas consecuencia de la definición de relación dada en 2.6.2. Estas propiedades son las siguientes:
a) No hay tuplas duplicadas. Esta propiedad es consecuencia de que el cuerpo de la relación es un conjunto matemático (conjunto de tuplas), y los conjuntos en matemáticas por definición, no incluyen elementos duplicados.
b) Las tuplas no tienen un orden. Esta propiedad se deriva también del hecho de que el cuerpo de.la relación es un conjunto matemático y los elementos de un conjunto no tienen un orden específico.
c) LOS atributos no tienen un orden. Esta propiedad es consecuencia de que el encabezado de la relación es también un conjunto matemático (un conjunto de atributos) y los conjuntos como ya se dijo, no tienen un orden en sus elementos. LOS atributos en una relación son referenciados por su nombre no
16
por su posición en la relación, sin embargo, por cuestiones de implementaci6n y práctica algún grado de orden es deseable (veáse el Capítulo 3 ) .
d) Todos los valores de atributos son atómicos. Esta propiedad es consecuencia del hecho de que todos los dominios subyacentes son a su vez simples, es decir, contienen valores atómicos solamente. Esta propiedad se puede establecer más formalmente como sigue: En cada posición renglbn-columna (intersecci6n) siempre existe exactamente un valor, no un conjunto de valores. Una relaci6n que satisface esta condición se dice que es normalizada. 1 F
2.8.4 Definición de base de datos relacional
Con los elementos definidos anteriormente, se está en posición de establecer formalmente lo que es una base de datos relacional. "Una BDR es una base de datos que es percibida por el usuario como una colección de relaciones normalizadas de diferentes grados y variantes con el tiempo". Por "variante con el tiempo" se entiende, desde luego, que el conjunto de tuplas en una relación dada, cambia con el tiempo.
2 . 8 . 5 Regias de integridad del modelo relacional
La segunda parte del modelo relacional consiste de dos reglas de integridad generales denominadas regla de integridad entidad y regla de integridad referencial. Estas dos reglas tienen que ver respectivamente con los conceptos de llave primaria y llave extranjera.
2.8.5.1 Llaves primarias
* Una llave primaria es realmente un caso especial de un concepto más general denominado llave candidata. Una llave candidata es básicamente un identificador único. Por definición cada relación tiene al menos una llave candidata, en la práctica la mayoría de las relaciones tienen exactamente una, pero es posible que algunas tengan dos o más.
Sea R una relación con atributos Al, A2, . . . , An. El conjunto de los atributos X = (Ai, Aj, ..., Ak) de R se dice que es una llave candidata de R si y solamente si, satisface las dos siguientes propiedades independientes del tiempo:
1) Unicidad: En cualquier momento dado, dos tuplas de R no tendrán el mismo valor para Ai, el mismo valor para Aj, ..., y el mismo valor para Ak.
17
- . 2) Minimalidad: Ninguno de los atributo Ai, A j , . . . , Ak puede ser
descartado de K sin destruir la propiedad de unicidad.
Las llaves primarias son importantes porque ellas suministran el íinico mecanismo de direccionamiento individual en el modelo relacional. es decir, representan la íinlca forma garantizada del sistema de apuntar a alguna tupla individualmente vía la combinación (R,k), donde R es el nombre de la relación que contiene a la tupla y K es el valor de la llave primaria en esa tupla.
2.8.5.2 Llaves extranjeras
Supóngase que se tienen dos tablas que pertenecen a una base de datos de una empresa: Una tabla que se denomina Departamentos y otra tabla que se denomina Empleados. La estructura de estas tablas es la siguiente:
Tabla Departamentos:
ClaveDep NombreDep PresupuestoDez DepA21 Recursos Humanos 900 DepC42 Finanzas 8000 DepD5 6 Relaciones Públicas 100
Tabla Empleados
ClaveEmE Nombr eEmp CiaveDep Cateqoría E1290 Smith DeDC42 F E4560 Clark DepDs 6 B E2000 Jones DepC42 B
La tabla Empleados tiene una columna (CiaveDep) que indica la clave del departamento al que pertenece cada empleado. Esta columna a su vez es llave primaria de la tabla Departamentos. Por cada valor de la columna ClaveDep en la tabla Empleados, debe existir Otro valor igual en la columna CiaveDep de la tabla Departamentos. No puede haber un empleado que pertenezca a un departamento que no exista. La columna ClaveDep en la tabla Empleados es un ejemplo de lo que se denomina llave extranjera.
Una llave extranjera es un atributo (o una combinacibn de atributos) en una relación R2 cuyos valores son requeridos para corresponder a aquellos valores de una llave primaria de alguna relación R1 (R1 y R2 son no necesariamente distintas).
18
2.8.5.3 Las dos reglas de integridad
Las dos reglas de integridad del modelo relacional son las
1) Regla de integridad entidad: Ningún atributo que participe en la llave primaria de una relaci6n puede aceptar valores nulos. Un valor nulo es un valor que se define para ser diferente de todos los demás valores reales del dominio aplicable del atributo. Los valores nulos sirven para denotar ausencia de información (véase el Capítulo 3).
2) Regia de integridad referencial: Si una relación R2 incluye una llave extranjera FK que corresponde a la llave primaria PK de alguna relación R1, entonces, cada valor de FK en R2 debe (a) ser igual al valor de PK en alguna tupla de R1 o (b) ser completamente nulo (es decir, caca valor de atributo participando en ese valor de FK debe ser nulo). R1 y R2 no son necesariamente distintos.
siguientes:
2.8.6 El algebra relacional
La tercera parte y iiltima del modelo relacional (parte manipulativa) la constituye lo que se denomina álgebra relacional. El álgebra relacional consiste de un conjunto de operadores que operan sobre relaciones y se deriva de la teoría de conjuntos (las relaciones corresponden a conjuntos). Cada operador toma una o dos relaciones como operandos y produce una relación resultado, la cual a su vez puede ser un operando para otro operador. Estas operaciones permiten los procesos de consulta y actualización de una BDR. En esta parte se presenta conceptualmente en qué consiste cada uno sin hacer referencia a ninguna notación. Codd [23] originalmente definió 8 de tales operadores, dos grupos de 4 cada uno :
1) Los operadores de conjunto tradicionales: unión, intersección, diferencia y producto cartesiano.
2) Los operadores relacionales especiales: selección, juntura, proyección y división.
Los dos grupos de operadores se muestran simbólicamente en las
a) Selección: Extrae tuplas específicas de una relación
b) Proyección: Extrae atributos específicos de una relación
c) Producto: A partir de dos relaciones especificadas, construye
Figuras 2.3 y 2.4 respectivamente, y consisten~en lo siguiente:
específica.
específica.
19
una relación que consiste de todos los posibles pares concatenados de tuplas, una tupla de cada una de las relaciones especificadas.
d) Unión: Construye una relación consistente de todas las tuplas que aparecen en cada una o en ambas de las dos relaciones especificadas.
e) Intersección: Construye una relación consistente de todas las tuplas que aparecen en ambas de las relaciones especificadas.
f) Diferencia: Construye una relación que consiste de todas las tuplas que aparecen en la primera y no en la segunda de las dos relaciones especificadas.
g) Reunión: A partir de dos relaciones especificadas, construye una relación que consiste de todos los posibles pares concatenados de tuplas, una tupla de cada una de las dos relaciones especificadas, tal que en cada par de las dos tuplas se satisfaga alguna condition especifica.
h) Division: El operador de división divide una relación A de grado m+n entre otra relación B de grado n, y produce una relación C de grado m. Considérese los primeros m atributos de A como un solo atributo compuesto X, y sus últimos n atributos como otro atributo compuesto Y. La relación A puede pensarse como un conjunto de pares de valores ( x , y ) . Similarmente, la relación B puede pensarse como un conjunto de valores y . El resultado de dividir A entre B es una relación C que consiste de un atributo x, tal que cada valor de x en C.X aparece como un valor de A.X y cada tupla del Producto de C y B aparece en A.
I I R B / Produoto\
A Unión Diferencia <ti-B> Int*rseocidn
m
FIGURA e.3 OPERADORES OE COHJUNTO TRROICIOWRLES.
20
I Se I eocidn
\ y Reunión <natura i > t
I L I a3
I FIEURR 2.q IJPERRDORES RELRCiORALES ESPECIALES.
2.9 El lenguaje SQL
un aspecto particular de las actividades de inves 6n realizadas a raíz del artículo de Codd sobre el modelo relacional ( 2 . 6 ) , fue el diseflo e implantación de prototipos de una gran variedad de lenguajes relacionales. Un lenguaje relacional es un lenguaje que realiza, en alguna forma sintáctica concreta, algunas o todas las características del modelo relacional abstracto. Muchos de tales lenguajes fueron creados a principios y mitades de los 70s. Uno de tales lenguajes en particular, fue el "Lenguaje de Consulta en Inglés Estructurado" (SEQUEL), definido por D. D. Chamberlin y otros en el Laboratorio de Investigación de IBM en San Jose, California (1974) e implementado por primera vez en un prototipo de IBM llamado SEQUEL XRM (1974-1975).
Parcialmente, como resultado de la experiencia con SEQUEL-XRM, se definió una versión revisada de SEQUEL-XRM/2 en 1976-77 (el nombre fue cambiado subsecuentemente a SQL por razones legales). El trabajo comenzó sobre otro prototipo más ambicioso de IBM llamado System R. Gracias en parte ai éxito del prototipo System R, otros vendedores comenzaron a construir sus propios productos basados en SQL teniendo gran aceptación en la industria tanto en ambientes de "mainframes" como de microcomputadoras.
SQL se ha convertido en el estándar internacional oficial para el manejo de BDRs por IS0 (International Organization for Standardization). El lenguaje SQL consiste de un conjunto de servicios para la definición y manipulación de datos en una BDR.
21
La versión original de SQL fue orientada para uso interactivo. Sin embargo, más tarde se agregaron algunos servicios para permitir la invocación de operaciones de SQL desde un lenguaje de programación de aplicación tal como COBOL, PL1 o Pascal. El estándar o la norma de SQL I121 se concentra casi exclusivamente sobre estos últimos servicios, supuestamente debido a que la estandarizacion es mucho más importante por portabilidad de programas que por sus interfaces interactivas.
LOS aspectos gramaticales y semánticos del SQL se tratan en esta tesis en los Capítulos 3 y 4 .
2.10 Traductores, compiladores y precompiladores
Un traductor es un programa que toma como entrada un programa fuente y produce como salida un programa objeto. El programa fuente se escribe en un lenguaje fuente y el programa objeto pertenece a algún lenguaje objeto.
Si el lenguaje fuente a traducir es lenguaje ensamblador y el programa objeto es lenguaje máquina, el traductor se llama ensamblador.
Si el lenguaje fuente a traducir es un lenguaje de alto nivel como Pascal o COBOL y el programa objeto es lenguaje máquina o lenguaje ensamblador, el traductor se llama cornpilador.
Si el lenguaje fuente a traducir es un lenguaje de alto nivel y el programa objeto es también un lenguaje de alto nivel, entonces el traductor se llama precompilador.
El precompilador desarrollado en esta tesis toma como entrada un programa fuente escrito en Turbo Pascal y SQL y produce como salida un programa objeto en Turbo Pascal. Para realizar esta función, el precompilador debe expandir el programa fuente con respecto a los estatutos de SQL, es decir, que para estos estatutos debe producir estatutos en Pascal semánticamente equivalentes. El precompilador entonces debe primero realizar el proceso de análisis de la sintaxis de los estatutos de SQL y luego su análisis cemántico. Si este proceso es correcto entonces se realiza el proceso de generación de código. Puesto que estas funciones son las mismas que realiza un compilador (con su respectivo programa fuente), resulta conveniente revisar las funciones y modelo de un compilador para implementar el precompilador.
2.10.1 Modelo de un compilador
Un compilador debe realizar dos tareas principales: el análisis de un programa fuente y la síntesis de su correspondiente programa objeto. La tarea de análisis trata con la descomposición
del programa fuente en sus partes básicas. Usando estas partes, la tarea de síntesis construye los módulos del programa objeto equivalente. La realización de estas tareas se realiza más fácilmente construyendo y manteniendo varias tablas. En la Figura 2 . 5 se muestra la estructura básica de un compilador.
Rnallrador ecaint iao
Tnmns
I I FiWRR 2.5 COMPOHEHTES DE UH COMPILROOR.
El programa fuente (véase Figura 2 . 5 ) es la entrada al analizador léxico ( o scanner) cuyo propósito es separar el texto de entrada en unidades o tokens tales como constantes, nombres de variables, palabras reservadas y operadores. Algunos analizadores léxicos colocan las constantes, etiquetas y nombres de variables en tablas apropiadas. Un elemento de estas tablas para una variable, por ejemplo, puede contener su nombre, su tipo y la línea en la cual está declarada. El analizador léxico suministra tokens al analizador sintáctico ( o parser), el cual, tiene como función verificar que la secuencia de estos elementos sea legal de acuerdo a las reglas sintácticas dadas en la especificación del lenguaje. Esto es, el analizador sintáctico determina 13 estructura global del programa fuente. El analizador semántico tiene como función determinar el significado del programa fuente y generalmente lo hace en base a la estructura generada por el analizador sintáctico (árboles sintácticos). La salida del analizador semántico se transfiere finalmente al generador de codigo, realizándose de esta manera la parte de síntesis. Algunos compiladores realizan otro paso adicional para optimizar el código generado. Esta función es realizada por el optimizador de código.
23
CAPITUM 3
PLANTEAMIENTO Y ANALISIS DEL PROBLEMA
3.1 Planteamiento general del problema
El objetivo principal de esta tesis es el de facilitar el desarrollo de aplicaciones para la explotación de una base de datos distribuida (BDD) experimental que se desarrolla en el Instituto de Investigaciones Eléctricas (IIE). La BDD experimental tiene las siguientes características:
a) Soporta el modelo relacional.
b) Utiliza la red IBM PC Network.
c) Utiliza el sistema operativo MS-DOS versión 3 . 3 .
d) La red está constituida por 3 computadoras personales: 2 computadoras modelo XT y 1 computadora modelo AT.
e) La forma en que se opera con la BDD es a través de aplicaciones escritas principalmente en lenguaje Turbo Pascal, versiones 4 y posteriores, con el lenguaje de definición de datos (LDD) de SQL intercalado en esas aplicaciones; y el lenguaje ensamblador.
f) El sistema manejador de la BDD ofrece a los programas de aplicación acceso transparente y concurrente mediante el uso de primitivas del sistema.
Para facilitar el desarrollo de aplicaciones que exploten la BDD experimental, esta tesis tiene como objetivo desarrollar un precompilador en lenguaje Turbo Pascal versión 6.0 que tendrá como funciones específicas las siguientes:
1) Tomar como entrada un programa fuente P1 escrito en lenguaje Turbo Pascal versión 6. O con proposiciones intercaladas de l o s
24
lenguajes de manipulación de datos (LMD) y de definición de datos (LDD) de SQL, conforme a la Norma Internacional de SQL [I21 *
Estas proposiciones están especificadas en el Anexo A de esta tesis.
2) Producir como salida un programa fuente P2, el cual consistirá de proposiciones en el lenguaje Turbo Pascal versión 6.0. Este programa será directamente compilable por el compilador de Turbo Pascal versión 6.0 para generar un programa ejecutable El, el cual será semánticamente equivalente al programa P1 del inciso anterior.
3 ) El código generado por el precompilador con respecto a las proposiciones de SQL intercaladas en el programa PI, deberá considerar los accesos a la BDD de una manera transparente y concurrente. Para ésto deberá utilizar las primitivas que ofrece el sistema manejador de BDD 19, 101.
4 ) El c6digo generado por el precompilador deberá considerar la unicidad de datos cuando se intente insertar un renglón a una tabla de la BDD cuando esta tabla haya sido definida con una o varias cláusulas de unicidad.
5) Implementar el manejo de índices para reducir los tiempos de respuesta cuando se intente insertar un renglón a una tabla que tenga definida la cláusula de unicidad.
6) Implementar el manejo de l o s valores por omisión que debe tomar una columna o columnas al momento de insertar un renglón en una tabla que ha sido definida con columnas a las que se les especifica un valor por omisión.
3.2 Antecedentes del proyecto
Antes de exponer el análisis del problema, se presenta a continuación una descripción breve de los trabajos que han s i d o desarrollados por el IIE en materia de BDDs, con el objeto de situar en ellos el presente trabajo. Asimismo, se muestra la infraestructura de software que se tenla antes de este trabajo con el prop6sito de conocer los procedimientos, funciones y en general los servicios de esa infraestructura, con el €in de facilitar el análisis, el diseño y la implementación del precompilador.
Durante la exposición de los antecedentes de este trabajo, as1 como durante el análisis, se hace constante referencia a una BDD con el objeto de presentar algunos ejemplos de las cuestiones que se tratan en cada punto. Esta BDD está formada por tres tablas: PROVEEDORES, PARTES y ENVIOS. La forma en que están distribuidas se muestra en la Figura 3.1. Por cuestiones prácticas, l o s nombres de
25
estas tablas serán manejados respectivamente como las tablas S, P y SP. Estas tablas son tomadas para efectos de ejemplificación de la referencia [ 2 4 ] .
S
lml SP pJ
Red de comunicrcione~
FIGURR 3 . 1 BASE DE DRTOS O lSTRlBUlDR C, P . SP.
a
3.2.1 Las primitivas del sistema administrador de bases de datos distribuidas.
El primer trabajo desarrollado por el IIE consistió en el desarrollo de un paquete de rutinas (las primitivas del SABDD) que permiten el acceso a los archivos de una BDD por medio de programas escritos en Turbo Pascal [ 9 , 101. Estas primitivas permiten el acceso transparente y concurrente a la base de datos distribuida. Lo anterior quiere decir que un programa en Pascal que hace uso de estas rutinas, puede accesar los archivos de cualquier máquina de la BDD, sin necesidad de especificar en qué computadora de la red residen dichos archivos (transparencia de localizaci6n) y que además, dos aplicaciones ejecutándose en diferentes máquinas, pueden accesar simultáneamente un archivo cualquiera de la BDD.
Las rutinas fueron escritas en lenguaje ensamblador y en lenguaje Turbo Pascal y como ya se dijo, pueden ser usadas por programas escritos en Turbo Pascal. A continuación, como ejemplo. se presentan dos de las rutinas para mostrar los parámetros que deben pasarse a cada una. El lector interesado en la descripción detallada de todas la rutinas puede referirse al Anexo B.
26
Ejemplo 3.2.1.1
Nombre d e l a ru t ina : Abre2. Funcion : Abre un archivo de l a BDD en forma
transparente. Forma de l lamarse desde Pascal :
Abre2(entidad, uso, permiso, es tado) ;
donde :
entidad es e l nombre d e l archivo. uso
permiso es e l uso d e l archivo que permite e l programa
estado
es el uso d e l archivo que desea e l programa invocador ( l e c tu r a , e s c r i t u r a y t o t a l ) .
invocador a o t ro s programas (ninguno, l e c tu r a , e s c r i t u r a y t o t a l ) . indica si l a operación fue exi tosa o no.
Ejemplo 3.2.1.2
Nombre d e l a ru t ina : Lee2. Funcion: Lee un r eg i s t ro de un archivo de l a BDD en forma
transparente. Forma d e l lamarse desde Pascal:
Leez(entidad, numreg, r eg i s t ro , e s tado) ;
donde :
entidad es e l nombre d e l archivo. numreg es e l número de r eg i s t ro que se desea leer. registro es una var iable t i p o apuntador que contiene l a
dirección d e l a var iable donde s e r á l e ída l a información d e l r eg i s t ro .
Como puede observarse en los dos ejemplos an te r io res , en ningún momento se especi f ica e l nombre de l a máquina que contiene e l archivo que se quiere a b r i r (en el primer ejemplo) y d e l cual se desea leer un r eg i s t ro (en e l segundo ejemplo). D e forma s imi lar a l a an t e r i o r , e l SABBD of rece ru t inas para cerrar un archivo; para escribir, modificar o borrar r eg i s t ros ; para reservar o l i b e r a r r eg i s t ro s y desde luego, para crear archivos. Aunque e s t a ru t ina , lógicamente, sí requiere espec i f i ca r en qué nodo d e l a r ed r e s id i r á e l archivo:
27
Nombre de la rutina : CreaArch2. Funcion de la rutina : Crear un archivo en la BDD. Forma de llamarse desde Pascal: CreaArch2(nodo, entidad, longreg, estado).
donde:
nodo
entidad es el nombre del archivo que se desea crear. longreg es la longitud que deben tener los registros
estado
es el nombre de la computadora donde se desea crear el archivo.
del archivo. indica si la operación fue exitosa o no.
Para lograrla transparencia de localización que ofrecen estas rutinas se hizo uso de un diccionario de archivos distribuidos (DAD) y de un algoritmo para manejarlo. El DAD se encontraba dividido en un número de fragmentos según el número de computadoras de la red (Figura 3.2). Cada uno de estos fragmentos ,en una máquina, contenía la información de los archivos que residían en esa msquina. La Figura 3.3 muestra en detalle la estructura de cada uno de los fragmentos del DAD.
Fragmenta del Fragmenta del ORO de BETR DAD de CRHA Fragnenta del
DRD da ALFA
R R R
-- Red de oonunioaoiones
FIGURA 3.2 DlSTRlüUClOY DEL OlCClDHAAlO DE ARCHIVOS DlSTRlBUiDOS <DAD>.
I 1
28
n w m tOr(PtrrAooRn PROUEEOORES RLFR
EHUIOS mtm PFIRTES BETA
Cada uno de los fragmentos del DAD se manejaba por medio de un archivo denominado ARCH N. Además de este archivo, en cada máquina se manejaba otro archiyo, denominado NODO, el cual contenía los
Cuando se deseaba crear un archivo en una computadora en la BDD desde otra computadora (por ejemplo, el archivo PARTES desde ALFA en la máquina BETA) se hacía por medio de la rutina CreaArch2, y el algoritmo para manejo del DAD funcionaba, a grandes rasgos, de la siguiente manera: primero se verificaba que no existiera otro archivo con el mismo nombre (PARTES) en alguno de los fragmentos del DAD. Si ésto ocurría, se regresaba un código de error; si no existía, entonces se daba de alta en el fragmento del DAD (Arch N) de ia máquina BETA y después se creaba fisicamente en la misma computadora BETA.
De la misma manera, bajo este mismo esquema del manejo del DAD se ejecutaban las demás rutinas del SABDD, obviamente, con las consideraciones propias de cada una para efectuarse de una manera optima y eficiente. Por ejemplo, cuando se leía el registro de un archivo usando Lee2 (descrita previamente), es fácil imaginarse que se podría realizar el acceso transparente, buscando a través del DAD, el nombre del archivo (un argumento de la rutina) del cual se quería leer el registro. Después de encontrado el Nodo donde f
residiera ( s i es que el archivo existía), entonces se procedería a leer la información de ese archivo. Si ésto se efectuaba una sola vez estaría perfecto, pero ¿Qué pasa cuando se e s t h realizando lecturas constantes a ese mismo archivo? Sin embargo existe una manera más eficiente de lograr ésto. El lector interesado en los detalles del algoritmo de transparencia de localización puede consultar la referencias [9, 101.
nombres de las computadores dadas de alta en la red. J
29
LOHGITUO
8e
e8 8 8
3.2-2 Pr-anpilador del lenguaje de definición de datos
Las primitivas del sistema descritas anteriormente, pueden ser usadas desde Turbo Pascal por cualquier desarrollador de aplicaciones que desee realizar operaciones sobre la BDD, sin embargo, requiere estar familiarizado con los nombres y argumentos de las mismas.
El segundo trabajo realizado por el IIE tuvo como objetivo facilitar el uso de estas rutinas a cualquier desarrollador de aplicaciones que quisiera operar sobre la BBD sin necesidad de estar familiarizado con las rutinas. El trabajo consistió en agregar un lenguaje de definición de datos (LDD) basado en SQL, el cual podía estar intercalado en un programa en Turbo Pascal. Para lograr este objetivo se desarrolló un precompilador que tomaba como entrada un programa fuente escrito en Pascal con proposiciones del LDD y algunas proposiciones del lenguaje de manipulación de datos (LMD) de SQL intercaladas, y producía como salida un programa escrito sólamente en Pascal [ll]. Este segundo programa podía ser entonces compilable directamente por el compilador de Pascal y producir un programa ejecutable que era semánticamente equivalente ai programa de entrada al precompilador. El código generado por el precompilador consideraba el acceso transparente y concurrente a la BDD haciendo uso de las primitivas del SABD.
A continuación se describen brevemente las principales características técnicas de este precompilador.
1) El precompilador fue desarrollado en lenguaje Turbo Pascal
2) El sublenguaje de datos utilizado es SQL. De este sublenguaje se implement6 la parte del lenguaje de definición de datos (LDD) y parte del lenguaje de manipulación de datos.
i
versión 4.0.
3) El lenguaje anfitrión es Turbo Pascal.
4) El lenguaje objeto es Turbo Pascal.
5) El código generado por el precompilador hace uso de las primitivas del sistema para realizar el acceso transparente ,y concurrente a la BDD descrita en 3.1.
6) Como puede observarse en la Figura 3.3, el tipo de datos que manejaban los archivos de la BDD antes de este trabajo, eran sólo de tipo string. Siendo ésto inaceptable para aplicaciones que involucren otros tipos de datos (entero, real, booleano), este trabajo amplió el DAD para manejar esta situación. Además, como en SQL pueden definirse diferentes tipos de datos para la definición de columnas de una tabla, la ampliación de la estructura del DAD era indispensable.
30
7 ) El proceso general efectuado por el precompilador que se realizó en dicho trabajo es el siguiente:
A. El programa fuente se ofrece como entrada ai precompilador, el cual reconoce cuando se inicia el texto de una proposición de SQL. (Esto se hace anteponiendo a cada proposición de SQL el carácter $ ) .
B. Cuando se reconoce el inicio de texto del estatuto de SQL, se pasa el control al traductor y éste efectúa las siguientes fases para ese estatuto (Figura 3 . 4 ) :
1. Análisis léxico. 2 . Análisis sintáctico. 3 . Análisis semántico. 4 . Generación de c6digo.
-
4 , Reconocedor de Inicio de Proposición SQL
I
ANALISIS SINTESIS'
Sintact ico Semántica Anaifzador
J i i . FfCURR 3.q ESTRUCTURR DEL PRECíK(PILRD0R DEL LOO.
partir de diagrarnas de transición e interacciona como una "I 8) El precompilador utiliza un analizador .léxico construído
rutina con el analizador sintáctico. El analizador sintáctico+- utiliza el método recursivo descendente de la clase "top- down". Para el análisis semántico y la generación de código se usa la técnica "dirigida por sintaxis" y se utilizan acciones sernánticas que son llamadas en el momento adecuado para generar el código en Turbo Pascal equivalente a la proposición de SQL traducida.
31
9) Al momento de la traducción, además de las tablas usuales en un compilador, empleadas para guardar, por ejemplo, nombres de variables, el precompilador utiliza el DAD, el cual contiene información sobre los objetos de la base de datos como lo es la información de los nombres y tipos de las columnas de cada tabla.
10) En dicho trabajo, los aspectos semánticos más importantes entre los estatutos de SQL a traducir y el código generado en Pascal son los relacionados con los objetos que se manejan en ambos: En SQL se manipulan tablas, renglones y columnas. En Pascal se manejan archivos de un tipo de registro, registros y campos respectivamente. Lo anterior significa que el SABDD ofrece a nivel conceptual de la base de datos una colección de tablas, formadas por renglones y columnas, haciendo un mapeo al nivel interno de estos objetos como archivos, registros y campos.
3 . 3 El proceso de analisis
A continuaci6n se procede a estudiar los objetivos del precompilador del LMD (3.1), el cual representa el problema principal de esta tesis, a fin de determinar la factibilidad del mismo y proponer las soluciones que sirvan de base para el diseno del programa que se pretende implementar para resolver el problema.
3.3.1 El problema del análisis léxico y sintáctico
El objetivo principal del precompilador es generar código en Pascal para cada proposición de SQL que se tenga intercalada en el programa fuente, el cual se da como entrada al precompilador. Este código deberá ser semánticamente equivalente a los estatutos de SQL. Es decir que el programa fuente (el cual es la entrada del precompilador! es una especificación de alguna operación sobre la BDD y el programa objeto (la salida del precompilador) debe ser otra especificación de la misma operación (véase la Figura 3.5).
Como puede verse, el problema de este precompilador es semejante al problema del segundo trabajo desarrollado por el IIE (3.2.2) excepto que ese precompilador toma proposiciones del lenguaje de definición de datos de SQL/ Como ya se mencionó, el precompilador del LMD que se desarrolla en esta tesis tiene como propósito brindar al desarrollador de aplicaciones que opera con la BBD un conjunto mayor de facilidades consistente en contar con un lenguaje SQL más completo y más poderoso.
Como se sabe por experiencia, las operaciones que más se realizan sobre una base de datos en general, consisten en altas, bajas, cambios y sobre todo en consultas a los datos, más que la creación de tablas o archivos. SQL proporciona un conjunto de
32
proposiciones para realizar esas operaciones: INSERT, DELETE, UPDATE y SELECT respectivamente. La implementación de estos estatutos, especialmente el estatuto SELECT con la mayoría de sus opciones incluyendo subconsultas a cualquier nivel, son el 1 principal problema a resolver en esta tesis. -
SPL Turbo Pasca I
Parcal
SPL I n t e r c a l a d o
con
P r o s r a n a e j e c u t a b l e
a C a p 1 l a d o r
de Turbo
P a i i c a I
FICURR 3.6 PROCESO DE PRECDHPILRCIDH Y CENERRCIOK DE CODICO EJECUTRELE.
El precompilador descrito en 3.2.2, por cada estatuto de SQL realiza un proceso de análisis (análisis léxico, sintáctico y semántico) y un proceso de síntexis (generación de código) (véase Figura 3.6).
PRECOHPILROOR
,A'... CREATE TABLE P
I FICURA 3.6 OIRCRRMR DE ESTRUCTURA CEUERRL PRRR UWR PROPOSICIOH.
I
33
Como se observa en la Figura 3.6, la estructura del módulo de análisis sintáctico interactúa con tres submódulos: el de análisis léxico, el de análisis semántico y el de generación de código. El analizador sintáctico, para reconocer una estructura sintáctica, solicita tokens al analizador léxico al mismo tiempo que realiza su análisis. Asimismo, cuando estas estructuras sintácticas correctas se van reconociendo, el analizador sintáctico hace llamadas a las rutinas semánticas las cuales verifican el significado correcto de la expresión y al mismo tiempo se va generando código Pascal equivalente a cada expresión de SQL reconocida.
La implementación del analizador sintáctico se hizo mediante diagramas de transición. Hay dos funciones y un procedimiento de este analizador, los cuales son frecuentemente utilizados por el analizador sintáctico y debido a esta frecuencia se considera importante describirlos:
1) Procedimiento GET-TOKEN: esta rutina obtiene tokens del programa fuente.
2 ) Función R(Argument0): esta rutina regresa un valor de verdadero si el token más reciente que se ha leido (mediante GET-TOKEN) es la palabra reservada especificada por el valor de Argumento, de otra manera regresa el valor de falso.
3 ) Función T(Argument0): esta rutina regresa un valor de verdadero o falso o dependiendo si el valor de Argumento es o no un determinado token (P.e. identificador, paréntesis derecho, coma, etcétera).
Para impleinentar el analizador sintáctico se desarrollaron funciones en Pascal para cada elemento no terminal de la gramática. Cada función regresa un valor numérico que indica el estado de terminación de la misma: un valor menor que cero indica que la función terminó sin éxito.
Las rutinas semánticas fueron desarrolladas como rutinas en
1
3 i Pascal que verifican la validez de las estructuras sintácticas.
La generación de código se efectúa cada vez que se reconoce una estructura sintáctica y semánticamente correcta. Se creó una rutina llamada GEN COD la cual, con los argumentos adecuados, va generando el código en Pascal. El formato de esta rutina es el siguiente:
GENCOD(AP, TEXTO, L, C)
en donde:
AP es un apuntador a una estructura de datos dinámica de tipo cola en la que se va insertando el texto TEXTO (Figura 3 . 7 ) .
34
L es una bandera que indica si se desea generar un avance de línea cuando se escriba el texto al archivo de salida (programa objeto).
C es una bandera que indica si el texto deberá escribirse entre comillas cuando se escriba al archivo de salida y
TEXTO es un fragmento de texto de alguna instrucción en Pascal que se escribe al archivo de salida.
Le generación de código se efectúa recorriendo la lista desde la cabeza.
tador^ or^ TEXTO L C
I FICURR 3.7 ESTRUCTURA DE ORTOS PRRR EL TEXTO PRSCAL CEHERROO.
Considerando el alto nivel estructurado que tiene el precompilador del LDD así como la estructura de software del proyecto, es lógico considerar que estos aspectos se pueden aprovechar para la implementación del precompilador del LMD, tomando en cuenta desde luego, las especificaciones del mismo. El precompilador del LMD puede entonces efectuar el proceso de traducción de los estatutos de manipulación de datos de SQL utilizando algunas rutinas y servicios del software descrito. La estructura del precompilador a desarrollar de hecho, tiene la misma estructura del anterior. Las diferencias entre uno y otro pueden a primera vista, considerarse minimas, sin embargo, como se citó anteriormente, las proposiciones de manipulación de SQL constituyen un subconjunto mayor y más complejo que el subconjunto de las proposiciones de definición de datos.
Lo anterior no significa que el LMD sea mejor que el LDD y por ende, tampoco significa que el precompilador del LMD sea mejor que el precompilador del LDD. Significa en cambio, que el número de acciones sintácticas y sobre todo semánticas a realizar por ei DreCOmDiladOr del LMD. será mayor y más complejo; y que para
35
específicamente el analizador léxico y la forma en que se genera el código a través de la rutina GEN-COD.
3.3.2 El problema del código equivalente
Como se vi6 en 3.3.1, el problema principal del precompilador del LMD es el de buscar la equivalencia en Pascal a las proposiciones del LMD de SQL, es decir, la implementación de las acciones semánticas y generación -de código. De las cláusulas del LMD, el estatuto SELECT representa, debido a la diversidad de sus formas, la dificultad principal para lograr su equivalencia en Pascal.
Para resolver el problema de la equivalencia del estatuto SELECT así como para los demás estatutos del LMD, es importante analizar algunos de los aspectos relacionados con los objetos que se manejan en SQL así como las operaciones que se realizan sobre los mismos con el fin de buscar una equivalencia en Pascal para esos objetos y para esas operaciones.
3.3.2.1 Objetos en SQL
Como se mencionó en 2 . 7 , SQL es un lenguaje para soportar la definición y manipulación de datos en una base de datos relaciona1 (BDR). Una BDR, de una manera simple, es uns. base de datos que es percibida por el usuario como una colección de tablas, donde una tabla es una colección no ordenada de renglones ("relación" es sólo un término matemático para una tabla). La frase "percibida por el usuario" es importante: Las ideas del modelo relacional, el cual es el modelo que soporta las BDRs, se aplican a los niveles externo y conceptual del sistema, no al nivel interno. En el nivel interno, el sistema es libre de usar las estructuras de datos que desee, con la condición de que sea capaz de representar esas estructuras como tablas en los niveles más altos.
Un ejemplo de una BDR y que además es distribuida, se muestra en la Figura 3.1. El detalle de cada tabla de esta BDD se presenta en la Figura 3.8.
Nótese que cada tabla en esa BD puede ser concebida, en términos tradicionales de Pascal, como un archivo, con los renglones representando registros y las columnas campos. Resulta lógico pensar entonces que una tabla puede manejarse como un archivo en Pascal, de hecho, el SABDD utiliza un archivo para representar una tabla. Sin embargo, para justificar y decidir si esta equivalencia es adecuada, es necesario precisar las características de las tablas en cuanto a la norma de SQL y ver si con un archivo en Pascal se pueden representar esas características y además ver si las mismas operaciones que se realizan sobre las tabla pueden realizarse también sobre los archivos.
36
S q w g ~ s I f u ! ! ¿ U x S P a ! ! 2 ~ m L Y 61 Smith eE London E 1 P l SE8 si? Jones 1E Parir s i pe ens u3 Blake 3E Par is SI pa w n c'I Clark PE London S l PY e m E5 R & m 38 Rthens r l ps W E
61 pe 1nE se p i 38s se pe 988 p m P J . m € P . B m w u 63 pe ens
P1 H u t Red l e London z: $ i:: 69 PS W E PZ Bold Crean 17 Par le
~3 Soreu Blue 17 Rome PY Sorer Red 19 London PS tan Blue re Par is P6 Coi Red 19 London
~ U R R 3.8 ESTRUCTURA DL Lns i m n s s, r v SP DE i n BDD DE Ln Ficunn a.1.
En SQL se manejan los siguientes objetos: tablas, renglones, columnas y valores principalmente, los cuales se describen conforme a la Norma de SQL a continuación, junto con algunos conceptos:
Un conjunto es una colección no ordenada de objetos distintos.
Un multi-conjunto es una colección no ordenada de objetos que no son necesariamente distintos.
Una secuencia es una colección ordenada de objetos que no son necesariamente distintos.
La cardinalidad de una colección es el número de objetos de esa colección. A menos que se especifique de otra forma, cualquier colección puede ser vacia.
Un tipo de dato es un conjunto de valores representables.
Un valor es primitivo en el sentido de que no tiene una subdivisit5n lógica. un valor es un valor nulo o un valor no nulo.
Un valor nulo es un'valor especial que es distinto de todos los valores no nulos'de un tipo de dato (un valor nulo está orientado a significar "ausencia de información", es decir, un valor que es "desconocido").
Un valor no nulo puede ser un número o una cadena de caracteres, los cuales no son comparables.
Una cadena de caracteres es una secuencia de caracteres. Una
37
cadena de caracteres tiene una longitud, la cual es un entero positivo que especifica el número de caracteres en la secuencia.
un número es un valor númerico exacto o un valor númerico aproximado.
una columna es un multi-conjunto de valores que pueden variar sobre el tiempo. Todos los valores de la misma columna son del mismo tipo de dato. Un valor de una columna es la unidad m8s pequeña de dato que puede ser seleccionado de una tabla y es la unidad más pequeña de dato que puede ser actualizada.
Una columna tiene una descripción y una posición ordinal dentro de una tabla. La descripción de una columna incluye su tipb de dato y una indicación de si la columna está restringida a contener Únicamente valores no nulos. La descripción de una column6 también incluye su nombre.
Una tabla es un multiconjunto de renglones. Un reng16n es una secuencia no vacía de valores. Cada renglón de la misma tabla tiene la misma cardinalidad y contiene un valor para cada una de las columnas de la tabla. El i-ésimo valor en cada renglón de una tabla es el valor de la i-ésima columna de esa tabla. El renglón es la unidad más pequeña de datos que puede ser insertada en una tabla y borrada de una tabla.
El grado de una tabla es el número de columnas de esa tabla. En cualquier momento, el grado de una tabla es el mismo que la cardinalidad de cada uno de sus renglones y la cardinalidad de la tabla es la misma que la cardinalidad de cada una de sus columnas.
Una tabla tiene una descripción. La descripción incluye una decripción de cada una de sus columas así como el nombre de la tabla. La Figura 3.9 muestra la descripción en detalle de la tabla S de la Figura 3.8.
~~~ ~
Create Table S ( SNO Char(5) Not Null Primary Key, SName Char ( 2 0 ) , Status Integer, City Char(20)):
FIGURA 3.9 DESCRIPCION DE LA TABLA S DE LA BDD DE LA FIGURA 3.1.
38
3.3.2 2 .T ipos de datos en SQL y Pascal
de los siguientes tipos de datos: En SQL los valores de una columna pueden estar asociados a uno
-(n) una cadena de caracteres de longitud n. NUMWIC(p,e) un tipo de dato niunerico exacto con precisión
y escala especificadas por I p y e respectivamente.
DECIMAL(p,e) un tipo de dato numérico exacto con escala especificada por e y con una precisión igual o mayor que la especificada por p.
INTEGER un tipo de dato numérico exacto con escala O y precisión definida por el implementador.
SMALLINT un tipo de dato numérico exacto con escala o y una ~recísión definida DOK el ImDiementador.
c
.
la cia1 debe ser menor-que la p;ecisión del tiD0 INTEGER. -L - ~~
FLOAT ( p ) un tipo de dato numérico aproximado con una precisión binaria igual o mayor que el valor especificado por p.
REAL un tipo de dato numérico aproximado con una precisión definida por el implementador.
DOUBLE PRECISION un tipo de dato numérico con precisión definida por el implementador que es mayor que la precisión del tipo REAL.
La Norma de SQL especifica que la compatibilidad de los tipos de datos de SQL con los tipos de datos en Pascal estándar cuando SQL está inmerso en Pascal es la siguiente:
Tipo de dato en SQL Tipo de dato en Pascal
-(n) PACKED ARRAY[n] OF CHAR INTEGER INTEGER FLOAT REAL
Los demás tipos de datos de SQL (listados anteriormente) no tienen equivalencia en Pascal. Como en Turbo Pascal el tipo de dato PACKED no t 4 m e efecto, el tipo de dato equivalente para PACKED ARRAY[n] OF CHAR es el tipo de dato STRING[n]. En Turbo Pascal el tipo de dato'INTEGER tiene una precisión de 16 bits y el rango de 32760 a 32767. A fin de tener una mayor compatibilidad de tipos de SQL y Pascalb se utiliza el tipo INTEGER de Pascal para el tipo SMALLINT de SQL y el tipo LONGINT de Pascal(e1 cual tiene una
39
precisidn de 32 bits) para el tipo INTEGER de SQL. Otras extensiones en cuanto a tipos se describen en el Anexo C de esta tesis. Con estas consideraciones se tiene la siguiente equivalencia de tipos de SQL y Turbo Pascal.
Tipo de dato Tipo de dato No. de bytes ea SQL ea Turbo Pascal ocupados
STRING[ n] INTEGEZI
n+i 2 4 6
3.3.2.3 Las tablas cano archivos en Pascal
Una tabla en Pascal se puede representar mediante una variable de tipo archivo de la clase archivo de tipo (Typed File) [ 2 5 ] . En Pascal un archivo de tipo consiste de una secuencia lineal de componentes o registros. Cada uno de estos componentes tiene asociado el tipo de componente (o tipo de registro) del archivo (a los registros también se les denomina ocurrencias del tipo de registro del archivo). Cada componente tiene un nimero de componente. El primer componente de un archivo se elige para ser el componente cero (véase la Figura 3.10).
ri = conpomntc o r w l s t r o i del archivo.
n = t o t a l de oomponcntes del archlro.
FICURR a l e nncwuo DE TIPO.
Un tlpo de registro comprende un conjunto de componentes o campos que pueden ser de diferentes tipos. La declaración de un tipo de registro especifica el tipo de. cada campo y el identificador que nombra al campo. Nótese que el término campo se utiliza como componente de un tipo de registro, no como componente de un registro. Los componentes de un registro se denominan valores de campo (véase la Figura 3.11)
40
01 E o a w o i del tipo de resictro.
. . n = t o t a l de oanpos
. ' del t i l o de rsslctro . . -1 ::: FJ noabre del o a m p ~
t ipo de o a w o
01 Di? 03 . . . C?
nmn s.11 TIPO DL nEtisim CSIW PRRTE. utininum. ,. r
I .
m Pascal, un tipo de registro (en cuanto a la definici4n de sus campos), puede tener una parte fija y/o una parte variable,'Un archivo de tipo de registro con una parte variable ¡io necesariamente contiene los mismos componentes para cada uno de 10s registros de ese archivo, es decir, la cardinalidad de LOS registros en el archivo puede variar. Como lo que se pretende es asociar un registro con un rengl6n de una tabla (los renglones en una tabla siempre tienen la misma cardinalidad) se debe descartar la opción de la parte variable en un tipo de registro. En cambio, si se utiliza sólo la parte fija de un tipo de registro para Un registro, se tiene siempre el mismo número de componentes pars todos los registros. Además, el tipo de dato de cada uno de las campos en un tipo de registro debe ser simple.
Con las definiciones anteriores y algunas consideraciones se está ya en condiciones de establecer una correspondecia entre 10s objetos de SQL y Pascal: Si se colocan los registros de la FigUX<r 3.10 en forma apilada (este arreglo es desde luego lógico) y sobre ellos colocamos su tipo de registro asociado se puede observar l a equivalencia entre tablas y archivos; renglones y registros; y entre columnas y campos (Figura 3.12).
F]::: nombre del O ~ R P O
t ipo d s oanpo
41
Para lograr una mejor correspondencia entre los archivos de Pascal y las tablas de SQL, es necesario considerar algunos aspectos :
1. Los renglones en una tabla no tienen un orden específico (de arriba a abajo). Los registros en un archivo tienen un orden dentro del archivo. Este orden obedece a su posici6n física en el archivo y no a un orden lógico. por lo tanto resulta irrelevante el orden físico de los registros.
2. LOS valores que una columna puede tener, como se describió antes, pueden ser valores nulos o valores no-nulos. Un valor nulo es un valor especial dependiente del tipo que es diferente de todos los valores no-nulos de ese tipo. En Pascal este concepto no es aplicable. Si por ejemplo, se declara una variable V1 para ser del tipo INTEGER, los valores que puede tomar están en el rango de -32767 a 32768 (estos valores serian valores no-nulos) . El valor nulo para la variable Vi no se puede representar por medio de uno de los valores del rango de enteros porque cualquier valor que se elija sigue siendo un valor no-nulo válido para esa variable y además porque ningún valor que se elija es distinto a todos los valores del rango (simplemente porque el rango incluye ese valor).
Adicionalmente a lo anterior, el valor nulo está orientado a significar ausencia de información o un valor que no se conoce. A s í es que cualquier valor que se elija (en el caso de la variable V1 anterior) representa un valor conocido.
El manejo del valor nulo para un campo CO en Pascal se puede resolver especificando para ese campo, aparte de su nombre y el tipo de dato, un campo adicional COA de tipo booleano que contendrá el valor de verdadero cuando el valor de Cü sea el valor nulo y contendrá falso cuando el valor de CO sea un valor no-nulo y desde luego este valor no-nulo será el que contenga el valor de CO. Cuando una columna sea definida para contener valores no-nulos, entonces la definición del campo COA no es necesaria. Obviamente, el campo adicional COA debe ser transparente al usuario de la BDD.
La Figura 3.13 muestra la equivalencia de la tabla S (SQL) mediante la definición de un registro en Turbo Pascal.
3.3.2.4 Operaciones en SQL
una vez establecida la equivalencia entre los objetos de SQL y Pascal, se procede ahora a determinar la correspondencia entre las operaciones de ambos lenguajes. SQL contiene, como ya se dijo. un lenguaje de manipulación de datos que sirve para operar sobre las tablas de una BDR. Las operaciones que se pueden realizar cuando SQL está inmerso en Pascal, así como el estatuto que se
42
emplea 'para. el.lo son:,
Estatuto
INSERT DELETE UPDATE SELECT
FETCH
OPEN CLOSE
Función
Crea nuevos renglones en una tabla. Borra renglones de una tabla. Cambia renglones de una tabla. Recupera valores de un renglón especifico de una tabla. Posiciona un cursor sobre el siguiente reng16n de una tabla y recupera valores de esa tabla (el uso de cursores será explicado más adelante). Abre un cursor. Cierra un cursor.
Para establecer la equivalencia de cada una de estas operaciones de SQL con Pascal, se proceder6 primero a explicar la forma en que se crea un tabla en la BDD mediante el estatuto CREATE TABJE de SQL.
Type S R e g - = record. . - Sno : String[5]: - .SName : String[20]; - SName Null : Boolean; - c t a tug, .: LongInt; - Status - Null : Boolean; - City : String[.20] ; City - Null : Boolean; ' ,
ens;
1 FIGURA 3.13 TIPO DE REGISTRO, ASOCIADO A LA TABLA S.
3.3.2.4.1 La cláusula mEATE TABLE
Para crear una tabla' desde Pascal, cuyas columnas sblo podian ser de tipo caracter (Figura 3.3). se utilizaba la primitiva CreaArch2 del SABDD (descrita en 3.2.1). Después, como se describió en 3.2.2, se utilizó SQL para crear una tabla desde Pascal. Como SQL permite establecer diferentes tipos de datos para las columnas de una tabla, se hizo necesario ampliar la estructura del DAD. Cada una de las descripciones para una tabla se guar.da en un registro del archivo Arch - N. E l tipo de registro de Arch-N contiene, entre
43
otras cosas, el nombre de la tabla, longitud en bytes p&a el tipo de registro del archivo asociado a la tabla e información para cada una de las columnas de la tabla (nombre, tipo, indicación de si acepta valores nulos). El archivo Arch N donde se guarda el registro de descripción de una tabla está daao por la partb'IN NODO (extensión hecha al estándar de CQL) de la cláusula (IREATE TABLE. Cuando no se especifica en qué nodo se quiere crear la tabla, se supone que es en el nodo local (nodo donde se ejecuta el programa). La Figura 3.14 muestra un ejemplo para crear una tabla (denominada EMPLEADOSI en el nodo Beta desde un proqrama en Pascal con SQL intercaLado . - . -
. .
Uses SOL; Begin
$Create Table hpleados ( Clave - Emp Char(5). Edad SmallInt , Depart Char(5)) In 'Beta';
End.
FIGURA 3.14 CREACION DE UNA TABLA DESDE PASCAL.
i,
..
El precompilador del LDD debe generar código en Pascal para la cláusula CREATE TABLE que haga uso de la primitiva CreaArch2, la cual fue modificada para ampliar la descripción de las tablas. La forma de llamar a esta primitiva desde Pascal es ahora la siguiente:
CreaArch2(Nodo, VarTipoRegArch - N, Estado) donde:
Nodo
VarTipoRegArch-N
Estado
es el nombre de la computadora donde se desea crear el archivo.
es una variable de tipo registro para el archivo Arch N. Esta variable, as€ como la descrlpcidn de su tipo de registro, se encuentran en la unidad SQL (línea 1 de la Figura 3.14) y son globales.
es una variable que regresa un .valor igual a cero si la operación fue exitosa y un valor negativo si no.
. %
44
La rutina CreaArch2 y la variable Estado también son globales
El código generado por el precompilador para el programa de la
y se encuentran definidas en la unidad SQL.
Figura 3.14 consiste en algo como lo siguiente:
uses sql; begin - SQLTABLA.Nombre:='Empieados'; - SQLTABLA.Columna[l].NombreC:='CLAVE - EMP'; - SQLTABLA.Columna[l].Tipo:=Caracter;
- SQLTABLA.Columna[3].NombreC:='DEPARTi;
CrearArchZ('Beta', - SQLTABLA,Estado); end.
3.3 .2 .4 .2 El estatuto INSERT
El estatuto INSERT se utiliza para crear nuevos renglones en una tabla. Por ejemplo, un programa en Pascal con SQL intercalado para adicionar renglones a las tablas S y P de la Figura 3.8 es el siguiente:
Ejemplo 3.3.2.4.2.1
1 program ejemplo 332421;
3 $begin declare section 4 Color : String[iS]; 5 Ciudad : String[ZO]; 6 Indicador : Integer; 7 end declare section; ü begin ( programa ) 9 Ciudad:='Montreai';
2 uses sql;
10 $Insert into S (SNo, City, Status) 11 values ( ' ~ 6 ' ; :Ciudad, NULL); -~ 12 Indicador:=-1; 13 Color:='Blue'; 14 $Insert into P ('p7', 'Keyboard', :Color:Indicador, 15 20, 'Berlin'); 16 end. ( programa )
45
En el ejemplo anterior se crea un nuevo renglón para la tabla S (línea 10). Este nuevo renglón contiene los siguientes valores:
SNo SName Status City columnas : - Valores : s6 <valor Nulo) <valor Nulo> Montreal
En la línea 14 se crea un nuevo renglón para la tabla P cuyos valores son los siguientes:
columnas: PNo PName Color weisht City Valores : p7 Keyboard <valor Nulo> 20 Berlin --
Como puede notarse, en el primer estatuto INSERT (línea lo), se especifica la lista de las columnas a las que se desea dar un valor, después, mediante la cláusula VALUES se especifica ei valor para esas columnas. Cada valor en la lista de VALUES corresponde a cada columna especificada en la lista de columnas. Cuando no se especifica el nombre de una columna en la lista de columnas (SName, en el caso de la línea lo), se supone que el valor por omisión que toma, es el valor nulo (a menos que esa columna tenga definido un valor por omisión en la declaración de su tabla o que la columna no acepte el valor nulo, como se verá más adelante).
Cuando no se especifica la lista de columnas en una cláusula INSERT (segundo INSERT en la línea 14), se supone que cada uno de los valores en la cláusula VALUES corresponde a cada una de las columnas de la tabla de acuerdo al orden en que fueron definidas en
Los valores que una columna puede tomar como ya se mencionó, son de dos tipos: valores nulos y valores no-nulos. Existen dos formas de asignación para cada uno de estos valores, las cuales se describen a continuacibn:
la cláusula CREATE TABLE.
1 Mediante literales o NULL.
1.1 Asignación de valores no nulos a columnas mediante literales.
Ejemplo: Insert into S (SNo,Status) values ('s7',20).
1.2 Asignación del valor nulo mediante la palabra reservada NULL.
Ejemplo: Insert into S (City) values (NULL).
46 ,
2 Mediante especificaciones de variables.
Otra forma de asignar valores no-nulos a una columna es por medio de una especificación de variable, la cual consiste de una variable anfitriona y opcionalmente una variable indicadora, la cual consiste a la vez, del símbolo if:ii (o la palabra reservada INDICATOR) y el nombre de una variable anfitriona.
Las variables anfitrionas son variables del lenguaje anfitrión (en este caso Pascal) y sirven para comunicar valores entre SQL y Pascal. Toda variable anfitriona debe declararse en la sección de begin declare section (línea 3 del ejemplo 3 . 3 . 2 . 4 . 2 ) . Esta sección es parte del lenguaje SQL cuando está intercalado.
Por ejemplo, cuando se desea asignar un valor no-nulo por medio de una variable anfltriona, se hace de la siguiente manera:
Ciudad:='New Pork'; $ Insert into S (City) values (:Ciudad):
donde Ciudad es una variable anfitriona declarada previamente an la seccián begin declare section. El valor de la columna City será el que tenga la variable Ciudad, en est% caso 'New York' . mando une especificación de variable contiene una variable indicadora y a l valor de esa variable indicadora e$ negativo, entonces el valor asigando a la columna es el valor nulo. Por ejemplo :
C1udad:m'Montscal; Itaaicaaos := -1; $In@ert into 8 (city) values (:Ciudad:Indlcador);
El valor que tome la columna City, en eete caso, 861 el valor nulo. Cuma0 R B UBR una varlsbla índicedora, &eta debe m r deelarada en 1s eeccidn begin declaro eectlan y debe t~er da tipo zateges,
c%anáo unta asgeeiflceciéri ds variable contien0 una vaelable indicedore y e$ valor de w a variable indicadora BB p o ~ i t i v ~ , entonces sfl ve%oc aaignedo a l a columna es el valor de 18 primere veis.iiabla ianfftriona a@ le eepecifisecfbn dlor V R E ~ B ~ L ~ . Por ejempbe:
Ciudad:mlKensasl; IndLeedor:a1; $Ensost i n t o $(City) values (:Ciudad:Xndicador);
47
En este caso, el valor asignado a la columna City es Kansas.
Una especificación de variable o una literal constituyen 10 que en la Norma de SQL se denomina una <especificacion de valor>, la cual tiene como función especificar un valor que no es seleccionado de una tabla, es decir, no es un valor que se tome de alguna columna.
La Figura 3.15 muestra otro ejemplo de un programa en Pascal y SQL para agregar un renglón a la tabla S.
1 2 3 4 5 6 7 8
I
Uses SQL; $Begin Deciare Section
Nombre: String(201; End Deciare Section; Begin (progrma)
End.
Nombre:='Sax'; $Insert Into S('s7', :Nombre, 50, 'Montreal');
1 FIGURA 3.15 PROGRAMA EN PASCAL Y SQL PARA AGREGAR UN RENGLON A LA TABLA S.
El código que debe generar el precompilador del LMD debe hacer USO de la primitiva Escribe2 para crear un nuevo registro en un archivo de una manera transparente en cuanto a la localización de la tabla:
Escribe2 (Entidad, ApReg, Estado);
donde :
Entidad es el nombre del archivo de la BDD en el cual se quiere escribir el registro.
APReg es una variable tipo apuntador que apunta a una variable global que contiene la información que se desea grabar.
Estado es una variable que regresa un valor de O si la operación fue exitosa, de otra manera regresa un valor negativo.
4 8
Existen dos formas de lograr la equivalencia entre ei estatuto INSERT de SQL y el código en Pascal:
1
2
Mediante generación de variables del tipo de registro asociado a la tabla en la que se quiere adicionar un nuevo renglón.
Mediante la utilización de un buffer común.
A continuación se describe cada una de estas formas con el fin de ver las ventajas y las desventajas de cada una a fin de seleccionar la mejor.
1 De acuerdo a la equivalencia de objetos establecida en 3.3.2.3, resulta lógico pensar que el precompilador podría generar una variable tipo registro para la tabla en la cual se quiere insertar el renglón. ~l código generado consjstiría básicamente en asignar los valores que se especifican en VALUES a los campos de la variable tipo registro y después llamar a la rutina Escribe2. Por ejemplo, el c6digo en Pascal para el programa de la Figura 3.15 podría parecerse a lo siguiente:
uses sql; var - Regs = record - sNo : String[5]: - SName : String[20]; - SNameNuio : Boolean;
- status : LongInt; i StatúsNulo_: Boolean:
.I .. .. end : Nombre : String[20];
begin Nombre:='LeWiS': with Regs do begin
SNo : = ' S T ' ; - SName :E Nombre: - SNameNulo:=False: Status - := 50: - StatusNUlO : = Fa1 .. ..
.se;
end. ~
Este esquema tiene la ventaja de asignar directamente valores a la variable tipo registro. Sin embargo, tiene siguientes inconvenientes:
los los
49
a) Se debe-generar al menos una variable tipo registro por cada tabla diferente sobre la que se quiere operar.
b) Como la variable apuntador de la rutina Escribe2 debe apuntar a una variable global, se requiere expandir el archivo de entrada en dos partes: una donde se encuentra la proposición $INSERT y otra en la sección de definición de variables para incluir la variable tipo registro.
2 La otra forma de generar código para el estatuto INSERT consiste en usar una variable tipo buffer, la cual consiste de un arreglo de bytes (de hecho, una variable tipo registro en Turbo Pascal contiene la dirección a un grupo consecutivo de bytes designado a contener la información de cada uno de los campos del registro). En lugar de generar una variable tipo registro para cada tabla, se utiliza sólamente una variable, la cual puede ser declarada en la unidad de SQL como global. El código generado consistiría de asignar cada valor de las columnas de la cláusula INSERT a su posición respectiva en el buffer. Por ejemplo, el siguiente programa crea un nuevo renglón para la tabla Q de la Figura 3.16.
Ejemplo 3.3.2.4.2.2.
uses sql; $begin declare section
Nombre : String[5]; end declare section; begin { programa principal 1
end. { programa principal 1
Nombre:='Adams'; $Insert Into Q (1500,:Nombre);
Create Table Q ( No Control SmallInt Not Null, Nombre Char (5) ) ;
FIGURA 3.16 DESCRIPCION DE LA TABLA Q.
El código generado para el programa de la Figura 3.16, utilizando el esquema de un buffer común, consistiría en algo como lo siguiente:
50
. . . . , ,
i . .. , . . . .. . . I
uses sql; , Var . .'
begin ( programa principal ) - .
, \ . Nombre : St'ring[S]; I
Nombre:='Adams'; - SQLEntero :=1500; ( variable tipo INTEGER declarada en
move(-SQLENTERO, SQLBUFFER[l], 2 ) ; move(Nombre, SQLBUFFERI31, lenght(Nombre)+l);.i.,.. .SQLBUFFER[9]:=0; (valor, nulo de. la columna'. Nombre =
, . 1.a unidad SQL:') . . . .
. a : . . . . False),
. . SQLPOINTER : ,=@SOLBUFFER; - .. , - . . EscribeZ(Q, _SQLPOINTER, Estado).; I . ..
. - .~ . , end. '
. "La forma en que se "llena'; 'el bu,ffer~ (SQLBUFFER) es mediante la instrucción MOVE de Turbo Pascal., La .posición en el .buf.fer a partir de la cual se coloca el valor para una columna,,depende.de la posición de la columna cuando se declara la tabla así como'del número de bytes que ocupa de acuerdo al tipo de dato de la columna. Por ejemplo, la columna NO CONTROL en la declaración de la tabla Q, es de tipo SMALLINT, el cual equivale al tipo INTEGER. de Pascal (3.3.2.2). Como ésta es la primera columna de la tabla, se supone que comienza en la posicion 1 del buffer y como los enteros se representan con 2 bytes (posiciones 1 y 2) la siguiente columna
. . . . , . . , .* ? ' " .
5 ) . . . . ,
debe comenzar en la posición,3. . .
Esta forma de generar código equivalente para la cláusula INSERT tiene l a desventaja de que no es directa la forma de asignar valores a los campos del registro (considerando al buffer como una variable tipo registro) que se va a insertar. Otra desventaja es que el tamaño del buffer debe ser lo suficientemente grande como para poder almacenar todos los'valores de algún tipo de registro con un tamaño grande.
Las ventajas de esta forma son las siguientes:
a) Sólo se utiliza un buffer en el caso de que existan varias tablas sobre las que se desee insertar renglones. De la otra forma se debe generar una variable tipo registro por cada tabla, las cuales, como son globales, ocupan demasiado espacio en memoria que puede ser mayor al espacio asignado al buffer.
I
b) No límita al programador de aplicaciones en cuanto a
c) El archivo de entrada al precompilador sólo se expande en
los identificadores para variables que puede usar.
el lugar donde se encuentra la cláusula INSERT.
Como puede verse, la segunda forma de generar código para la Cl6USUla INSERT tiene mayores ventajas que la primera, por lo tanto, ésta será la forma que se utilizará para generar código.
3.3.2.4.3 El estatuto SELECX
El estatuto SELECT tiene como función recuperar valores de un reng16n específico de una tabla. El uso del estatuto SELECT constituye lo que en términos de SQL y BDRs se denomina realizar una consulta (QUERY en Inglés). Es importante señalar que este estatuto, cuando se usa desde un lenguaje anfitrión (como lo especifica el estándar de SQL), difiere de cuando se usa de manera interactiva. Por ejemplo, la Figura 3.17 muestra el uso del estatuto SELECT de una manera interactiva. En este caso, el resultado de aplicar el SELECT consiste de una tabla de grado 2 y cardinalidad 2, la cual se mostraría directamente en la pantalla de la terminal donde se ejecuta la consulta:
sl Smith s4 Clark
Select SNo, SName From S Where City = 'London';
FIGURA 3.17 FORMULACION EN SQL PARA LA CONSULTA: "OBTENER EL NUMERO DE PROVEEDOR Y NOMBRE PARA AQUELLOS PROVEEDORES QUE ESTAN LOCALIZADOS EN 'LONDRES' ".
Si realizamos la consulta de la Figura 3.17 (tal como está formulada) en forma intercalada en Pascal, la tabla resultado también se mostraría en la pantalla. Si se quisieran manipular los valores de cada uno de los renglones de esa tabla para efectuar alguna clase especial de procesamiento con. ellos, por ejemplo, realizar alguna gráfica, desplegarlos en pantalla no necesariamente en forma de tabla o guardarlos en un archivo de texto, etcétera, se estaría limitado a la forma en que se presentan en pantalla.
En general, el objetivo de tener SQL intercalado en un lenguaje como pascal es precisamente hacer uso de las características de Pascal que no se encuentran en SQL (P.e. manejo de memoria dinámica, proposiciones de control, etc.) y a la vez,
52
poder utilizar las características no orientadas a procedimientos de un lenguaje como SQL.
Como se estableció anteriormente, la forma de enlazar los objetos y operaciones de SQL con Pascal y viceversa, es por medio de variables anfitrionas. A s í por ejemplo, el estatuto SELECT cuando se usa de manera intercalada, tiene una parte ( I N T O ) que permite guardar los valores de un Único renglón especifico en variables anfitrionas. La Figura 3.18 muestra un ejemplo del uso del estatuto SELECT en modo intercalado.
Uses SQL; $Begin Declare Section NoProv : String[5]: Estado : LongInt;
End Deciare Section; begin $Select SNo, Status + 10 Into :NoProv, :Estado From S where City='London';
end.
FIGURA 3.18 EJEMPLO DEL ESTATUTO SELECT EN MODO INTERCALADO.
En este ejemplo, los valores del Único renglón de la tabla tabla derivada o tabla resultante (s5 y 4 0 ) , se guardan en las variables anfitrionas 'pNoProv" y "Estado" respectivamente. El grado de la tabla derivada está determinado por el número de elementos que aparecen después del SELECT. En el ejemplo de la Figura 3.18 se tienen dos elementos: SNo y Status + 10 ( cada elemento es separado por comas y en general cada elemento es una expresión escalar que puede o no incluir una referencia a alguna columna de alguna tabla que intervenga en la parte FROM). El tipo de dato de la i-ésima columna de la tabla derivada se determina por el tipo de dato del i-ésimo elemento en la lista del SELECT y debe ser compatible con el tipo de dato del i-ésimo elemento de la cláusula INTO. La cardinalidad de la lista del SELECT debe ser igual a la cardinalidad de la lista INTO.
Cuando la tabla que resulta de aplicar una cláusula SELECT (modo intercalado) tiene una cardinalidad igual a 1, a una variable denominada SQLCODE se le asigna un valor igual a cero (condicibn de éxito). Cuando la cardinalidad es igual a O, SQLCODE adquiere un valor de +loo y cuando la cardinalidad es mayor que 1 (más de un renglón) se tiene una condición ilegal y el valor de la variable SQLCODE adquiere un valor negativo.
5 3
La variable SQLCODE se utiliza como parámetro entre las operaciones de SQL y el lenguaje anfitrión. Cuando el lenguaje anfitrión es PASCAL, esta variable es de tipo INTEGER. Después de ejecutar un estatuto de SQL, esta variable regresa un valor dependiendo de la condición de terminación del estatuto. Esta variable puede ser accesada como una variable anfitriona. En el caso del código generado por el precompilador, esta variable es global y se encuentra definida en la unidad SQL.
Si se realiza la consulta de la Figura 3.17 de una manera intercalada, no habría en Pascal una manera de asignar todos los valores de cada una de las columnas de la tabla resultado a una variable anfitriona en la cláusula INTO. La razón de ésto es que los lenguajes como Pascal no están equipados para manejar conjuntos (consistentes de múltiples registros) como si fueran operandos simples. Por lo tanto, es necesario tener en SQL, un mecanismo para manipular o accesar un renglón a la vez de una tabla derivada, y los CURSORES suministran este mecanismo.
3.3.2.4.3.1 L o s cursores en SQL
Un CURSOR es un objeto de SQL que está asociado (vía una declaración apropiada) con una operacion SELECT específica (más exactamente con una especificación de consulta) y consiste esencialmente de un tipo de apuntador que puede ser usado para recorrer uno por uno el conjunto de renglones de la tabla que resulta de aplicar esa operación SELECT. Para accesar los renglones correspondientes a ese SELECT, se debe realizar lo siguiente:
1) Abrir el cursor (OPEN "Nombre de Cursor") lo cual causa que el SELECT sea ejecutado y por consiguiente ese cursor identifique el conjunto correspondiente de renglones de la tabla resultado.
2 ) Usar la proposición FETCH repetidamente sobre el cursor abierto (hasta que lógicamente no haya más renglones), lo cual, sobre cada ejecución coloca el cursor en el siguiente renglón de la tabla resultado y recupera los valores de ese renglón (colocando estos valores en variables anfitrionas).
3 ) Cerrar el cursor mediante la proposición CLOSE cuando todos los renglones hayan sido procesados.
La Figura 3.19 muestra un ejemplo de un programa en Pascal con SQL intercalado para el uso de cursores. En la línea 6 de este programa se declara el cursor especificando su nombre y la especificación de consulta que identifica (lineas 7 , 8 y 9). En la línea 10 se abre el cursor y con ésto se genere la tabla resultado. De la linea 11 a la 14 se procede a recuperar cada uno de los renglones mediante el uso de un ciclo y la proposición FETCH.
54
.-
Cuando el cursor haya finalizado el recorrido a través de los renalones v se intente aplicar un FETCH, el c6digo de error SQLCODE - - - - a - ~~
se vuelve igual a + l o o . -
1 2 3 4 5 6 7
9 10 11 12 13 14 15 16
a
Uses SQL; $Begin Deciare Section
NoProv : String[5]; End Deciare Section;
begin $Deciare Cursor CurEjemp for Select SNo From S Where City <> 'Athens'; $Open Cursor CurEjemp; repeat
until SQLCODEOO; $Close CurEjemp;
$Fetch CurEjemp into :NoProv; i f SQLCODE = O then writeln(NoProv);
end.
FIGURk 3.19 EJEMPLO DEL USO DE CURSORES EN PASCAL.
3.3.2.4.3.2 La palabra reservada SELECT
Es importante antes de continuar, especificar el uso de la palabra SELECT en SQL cuando se usa de manera intercalada para evitar ambigüedades. La palabra reservada SELECT tiene tres funciones en SQL. La primera es cuando se usa como estatuto para recuperar los valores de un renglbn específico de una tabla ( <estatuto select> ) . En este caso, se especifica el conjunto de variables anfitrionas en las cuales se guardarán los valores del renglón de la tabla resultante. El programa de la Figura 3.18 es un ejemplo del uso del SELECT para este caso y la Figura 3.20 muestra la sintaxis correspondiente.
55
<estatuto select>::= SELECT [ALLIDISTINCT] dista del select> INTO dista objeto del select> texpresión de tabla>
FIGURA 3.20 SINTAXIS DEL ESTATUTO SELECT
La segunda función de la palabra reservada SELECT es cuando se usa como parte de una tespecificación de consulta>. Una tespecificación de consulta> especifica una tabla derivada del resultado de una <expresión de tabla> (una expresión de tabla consiste .básicamente de una parte FROM y otra opcional WHERE). Una tespecificaci6n de consulta> se usa para especificar la tabla resultante a la que va a estar asociado un CURSOR. La Figura 3.19 en la línea I muestra un ejemplo del uso de la palabra SELECT como parte de una <especificación de consulta>.
La tercera función de la palabra reservada SELECT es cuando se usa en una <subconsulta> o <subquery>. Una <subconsulta> tiene como función especificar un multiconjunto de valores derivados del resultado de una texpresión de tabla>. Una <subconsulta> es similar a una <especificación de consulta> excepto que esta Última especifica una tabla resultante que puede ser de cualquier grado y en cambio, una <subconsulta> especifica una tabla resultante de un grado máximo igual a uno. Las <subconsulta>s se usan en los predicados <predicado de comparación>, <predicado IN> y <predicado exist>, como parte de una condición de búsqueda de una cláusula WHERE. La Figura 3.21 muestra un ejemplo de una subconsulta (líneas
1 Uses SQL; 2 begin 3 $Declare Cursor Ejemplo for 4 Select SNo 5 From S 6 where SNo in I (Select SNo 0 From SP 9 where PNo='pl'; 10 end.
FIGURA 3.21 EJEMPLO DE UNA SUBCONSULTA
56
3.3.2.4.3.3 Expresión de una tabla
Una <expresión de tabla) tiene como función especificar una
<expresión de tabla>::=
tabla. La sintaxis de esta cláusula es la siguiente:
<cláusula from> [<cláusula where>]
Si la <cláusula where> es omitida entonces la tabla especificada por una <expresi6n de tabla> es el resultado de la <cláusula from>. De otra manera, la tcláusula where> es aplicada a la tabla que resulta de la <cláusula from>.
3.3.2.4.3.3.1. La cláusula PRüM
Una <cláusula from> especifica una tabla derivada de uno o más
<cláusula from>::=
donde <nombre de tabla> es un identífícador para una tabla.
nombre de tablas. La sintaxis es la siguiente:
tnombre de tabla> [(,<nombre de tabla>)]
Si la <cláusula from> contiene un solo <nombre de tabla> entonces el resultado de una <cláusula from> es la tabla identificada por ese tnombre de tabla>.
Si la <cláusula from> contiene más de un tnombre de tabla> entonces el resultado de la <cláusula from> es el producto cartesiano extendido de las tablas identificadas por aquellos <nombre de tablas>s. El producto cartesiano R es el multiconjunto de todos.los renglones I tal que r es la concatenaci6n d e un renglón de cada una de las tablas identificadas en el orden en el cual son identificadas. La cardinalidad de R es el producto de L a s .cardlnaPídades de las tablas identificadas. La posición ordinal. de una columna en R es n+s, donde n es la posici6n ordinal de esa columna en la tabla T de la cual es derivada y s es la suma de los grados de la tablas identificadas antes de T en la tcláusula from>.
Por ejemplo, si en una <cláusula from> se tienen los nombres de tablas S y ~ P [las tablas d e la BDD d e la Figura 3 . 8 ) , entonces e P resuitado~de esta <cláusula from> es el proeucto cartes-ano de
~~ las tablas S y P, el se muestra en la Figura 3.22.
SNO s1 Sl Sl Sl Sl s1 s2
- SNAME STATUS SBith 20 Smith 20 Smith 20 Smith 20 Smith 20 Smith 20 Jones 10
S. CITY London London London London London London P a r i s
PNO pl P2 P3 P4 P5 P6 P l
PNAME Nut Bol t Screw Screw Cam
Nut cog
COLOR Red Green Blue Red Blue Red Red
WEIGHT 1 2 17 1 7 14 12 19 12
P. CITY London P a r i s Rome London P a r i s London London
30 Athens p6 cog Red 1 9 London
FIGURA 3.22 PRODUCTO CARTESIANO DE LAS TABLAS S Y P.
3.3.2.4.3.3.2. La c l á u s u l a WIBRE
La <c láusu la where> t iene como función e s p e c i f i c a r una t a b l a der ivada por l a a p l i c a c i ó n de una <condición d e búsqueda> a l r e s u l t a d o d e l a a n t e r i o r <c láusu la from> en una <expresión de t a b l a > .
Supóngase que R es e l r e s u l t a d o d e una < c l á u s u l a from> y que l a <condición de búsqueda> se a p l i c a a cada renglón de R. E l r e s u l t a d o de l a <c láusu la where> es una t a b l a c o n s i s t e n t e de aque l los renglones de R para l o s c u a l e s e l r e s u l t a d o d e l a <condición de búsqueda> es verdadero.
3.3.2.4.3.3.2.1 Condición d e búsqueda
Una <condición d e búsqueda> t iene como función e s p e c i f i c a r una condición que es "verdadero", " f a l s o " o "desconocido" que depende d e l r e s u l t a d o d e a p l i c a r operadores booleanos a condiciones e s p e c í f i c a s . La s i n t a x i s es l a siguiente:
<condición d e búsqueda>::=
<término booleano>::= < f a c t o r booleano>
< f a c t o r booleano>::= [NOT] <primario booleano> <pr imar io booleano>::= <predicado>
<término booleano> ( OR <término booleano> )
( AND < f a c t o r booleano> ]
58
Como puede verse en la especificación de sintaxis, una <condición de bfisqueda> es básicamente una colección de <predicado>s combinados usando los operadores booleanos AND, OR y NOT.
Un <predicado> especifica una condición que puede ser evaluada a un valor de verdad de "verdadero", "falso" o "desconocido". Un predicado puede ser cualquiera de los siguientes:
<predicado>::= <predicado de comparación>
I cpredicado between> I <predicado in> 1 cpredicado like> I <predicado null> I <predicado exist>
A continuación se da una descripción junto con algunos ejemplos del <predicado de comparación>. Los demás predicados están especificados en el Anexo A.
Un <predicado de comparaci6n> tiene dos formatos diferentes.
<predicado de comparación>::=
~l primero es el siguiente:
<expresión escalar> top-comparación> <expresión escalar>
donde <op-comparación> es cualquiera de los operadores de comparación =, e>, <, >, <= o >=. Si el predicado de comparación aparece en el contexto de una <cláusula where>, entonces L a s <expresiones escalares> no deben incluir refererencias a ninguna función (las funciones están especificadas en el Anexo A ) .
Ejemplo 3.3.2.4.3.1
Select SNo, SNombre from S where City='London' or Status=lO;
En este ejemplo primero se seleccionan aquellos renglones de %a tabla s en los cuaLes el valor para l a columna CITY sea igual a LONDON o el valor para l a columna status sea 10. La tabla derívada de e s t a operacl6n es:
59
CITY - SNO SNAME STATUS sl Smith 20 London -- s2 Jones 10 Paris s4 Clark 20 London
Después a esta tabla derivada se aplica la cláusula SELECT, seleccionando las columnas SNO y SName. La tabla derivada final es la siguiente:
SNO SNAME -- sl Smith s 2 Jones s4 Clark
El otro formato de un <predicado de comparación> es el
<predicado de comparación>::=
siguiente:
<expresión escalar> top-comparación> <subconsulta>
El siguiente ejemplo muestra una formulación en SQL para resolver la consulta "seleccionar los números de proveedores para aquellos proveedores que estén localizados en la misma ciudad de la parte pl.
1 Select SNo 2 From S 3 Where City = 4 (Select City 5 From P 6 Where PNo='pl');
En este ejemplo, primero se seleccionan aquellos renglones de la tabla S que cumplan con la condición del Where (línea 3 ) . Esta condición involucra comparar la columna CITY de cada uno de los renglones de S con el resultado de una subconsulta (líneas 4 a 6). Para poder efectuar la subconsulta a su vez, primero se aplica la cláusula WHERE (línea 6) a todos'los renglones de P que tengan en la columna PNo el valor de pl. Esto produce .la siguiente tabla derivada:
PNO PNAME COLOR WEIGHT CITY plNut Red 12 London
60
El siguiente paso para resolver la subconsulta es aplicar la cláusula SELECT (línea 4 ) a la tabla anterior produciendo la siguiete tabla:
CITY - London
Esta tabla es el resultado de la subconsulta y se usa ahora para aplicar la condición de búsqueda del WHERE de la línea ( 3 ) a todos los renglones de la tabla S, seleccionando aquellos renglones que tengan en la columna City el valor de London. Lo anterior produce la siguiente tabla:
SNO SNAME STATUS CITY s1 Smith 20 London s4 Clark 20 London
--
El último paso a realizar consiste en aplicar la cláusula SELECT (línea 1) a la tabla anterior. La tabla resultado final es la siguiente:
SNO Sl s4
En los ejemplos anteriores se ha aplicado algún operador de comparaci6n a valores que son no-nulos y se determina si un renglón cumple alguna condicidn de búsqueda para una cláusula WHERE. Cuando se aplica un <predicado de comparación> y el resultado de alguna <expresión escalar> es desconocido, entonces el resultado de aplicar el predicado es desconocido. Por ejemplo, supóngase que para la tabla S el valor de la columna CITY del renglón del proveedor sl fuera el valor nulo en lugar de London. si se realizara la siguiente consulta "obtener los números de proveedores que están localizados en London" obtendríamos la siguiente tabla:
SNO s4 -
Partiendo de la sintaxis de <predicado>:
<predicado de comparación>::= texpresi6n escalar> top-comparación>
(texpresi6n escalar> I <subconsulta>) 6 1
1) Sea X el resultado de la primera <expresión escalar> y sea Y el resultado de la <subconsulta> o la segunda <expresión escalar>. La cardinalidad del resultado de la <subconsulta> no será mayor de uno.
2 ) Si X o Y es el valor nulo o si el resultado de la <subconsulta> es vacío, entonces "X <op-comparación> Y" es desconocido.
3 ) Si X y Y son valores no nulos, entonces "X <op-comparación> Y" es verdadero o falso dependiendo de x, top-comparación> y de Y.
De la misma manera, debido a que un <predicado> puede evaluar una condición a un valor de verdad de "verdadero", "falso" o "desconocido", la aplicación de los operadores Booleanos NOT a los <predicado>s está definida por las simientes - - - verdad :
T F F F ? ? ?
AND, OR y tablas de
3 . 3 . 2 . 4 . 3 . 4 Los cursores en Pascal
Una vez presentado el panorama de la cláusula SELECT y CURSORES, a continuación se presenta una forma de lograr su equivalencia en Pascal. Primero se trata el SELECT como parte de una definición de cursor, es decir, como una <especificación de consulta>. Después se trata como cláusula con su parte INTO.
I Un CURSOR C está asociado, vía una declaración apropiada, con 1 una <especificación de consulta>. Cüando se abre el cursor (OPEN C), ocasiona que su <especificación de consulta> sea aplicada, ) produciendo una tabla derivada T, la cual va a estar identificada con el CURSOR C. Cada renglón r de l a tabla derivada T es accesado 7 por medio de una proposición FETCH. Los valores de cada renglón r se asignan a variables anfitrionas que aparecen declarados en la proposición FETCH. Cuando se ha efectuado el recorrido de todos los renglones r o antes, se cierra el CURSOR C mediante la proposición CLOSE C. Esto causa que los renglones de T no puedan ser accesados ya mediante FETCH. Si se quiere volver a accesar los renglones de T, se debe abrir de nuevo el cursor.
I I ,
6 2
Desde un punto de vista de Pascal, se puede pensar en una tabla T (producida por una <especificación de consulta> de un cursor) como un archivo de tipo (al que denominaremos FT). El tipo de registro de este archivo FT estaría determinado por el tipo de dato de cada uno de los elementos de la lista del SELECT de la <especificación de consulta> del cursor C. El archivo FT puede estar asociado con un nombre físico de archivo que sería el nombre del cursor (Assign(FT,Nombre de Cursor)). La cláusula OPEN C, puede ser equivalente a abrir el archivo FT (Open(FT)). Esto implica que la tabla T haya sido obtenida previamente, es decir que el archivo FT haya sido creado previamente.
De este esquema puede observarse que habría una diferencia entre la proposición OPEN de SQL y la proposición Open de Pascal. La tabla T en SQL se produce hasta el momento de abrir el CURSOR C, no en el momento de declarar el CURSOR, en cambio, en Pascal el archivo FT sería creado al momento de declarar el cursor. Esto desde el punto de vista del autor de esta tesis tiene mayores beneficios. Por ejemplo, en SQL cada vez que se desea accesar los renglones de una tabla T es necesario abrir el cursor Correspondiente, lo que causa que se aplique la tespecificación de consulta>. En Pascal la <especificación de consulta> s610 se aplica al momento de declarar el cursor.
La cláusula FETCH CURSOR INTO V1, V2, . . . ,VN de SQL sería equivalente en Pascal a realizar las siguientes operaciones:
READ(FT, REG); Vl:=REG.Campol; V2:=REG.Campo2: .. .. VN:=REG.CampoN;
donde REG sería una variable del tipo de registro asociado al archivo FT.
La cláusula CLOSE CURSOR de SQL sería equivalente a la
La Figura 3 . 2 3 muestra un ejemplo en Pascal y pseudocódigo de
proposicíon Close(FT) de Pascal.
una equivalencia al programa en SQL y Pascal de la Figura 3.19.
6.3
Uses SQL; Type
TRegFT = record SNO : ~tring[~];
ena ; Var
NoProv : String [SI (variable anfitriona) FT : File of TRegFT; RegFT : TRegFT;
begin Assign(FT,'CurEjemp' ) ; rewrite(FT); (obtener la tabla derivada
close(FT) ; {OPEN CURSOR CUREJEMP:)
reset(FT); repeat
e ir guardando el resultado en FT)
Assign(FT, 'CurEjemp' ) ;
read(FT,RegFT); NoProv:=RegFT. - SNo;
until SQLCODE C> O; (CLOSE CURSOR CUREJEMP:) close(FT);
end.
FIGURA 3.23 CODIGO EN PASCAL Y PSEUDOCODIGO PARA LA CONSULTA DE LA FIGURA 3.19.
Para lograr el código equivalente de la Figura 3.19, es necesario generar variables de un tipo de registro para cada archivo FT asociado con un cursor. Este tipo de problema es similar al que ocurre en la cláusula INSERT ( 3 . 3 . 2 . 4 . 2 ) y puede evitarse utilizando tambien una variable tipo Buffer. El problema que se presenta ahora es cómo manejar el archivo FT (el cual representa una tabla derivada T).
Una solución es tratar este archivo como una tabla cualquiera de la BDD. Sin embargo, este enfoque tiene las siguientes desventajas:
1) Cada vez que se declarara un CURSOR C en un programa P1, se crearla un archivo FT con nombre C en la BDD y ésto ocasionarla escribir la descripción de este archivo en el DAD de la máquina donde se ejecutara el programa P1 (Archivo Arch - N).
64
2 ) Cuando terminara la ejecución del programa P1 se tendría que dar de baja-la descripción de C en Arc-, debido a que otro, programa que se ejecutara en esa máquina (lógicamente después ~
de Pi), podría declarar un cursor con el mismo nombre del cursor del programa PI y no necesariamente estaría asociado a la misma <especificación de consulta>.
Otra alternativa para manejar el archivo FT es tratarlo como un archivo de tipo, pero sin declarar en el código generado, el tipo de registro asociado con ese archivo. Lo anterior aunque puede parecer ilógico, es posible mediante el uso de archivos sin tipo de Turbo Pascal (untyped files) ( 2 6 1 .
Los archivos sin tipo son canales de EntradaBalida de bajo nivel usados principalmente para acceso directo a cualquier archivo en disco independientemente del tipo y estructura del archivo. Un archivo sin tipo se declara con la palabra 'File" y nada más, por ejemplo :
Var Archivo : File;
Para archivos sin tipo, los procedimientos RESET y REWRITE permiten un parámetro extra para especificar el tamaño de registro que se usa en las transferencias de datos.
Por razones históricas, el tamaño de registro por omisibn es 128 bytes. El tamaño de registro preferido es 1 porque ese es el tínico valor que correctamente refleja el tamaAo exacto de cualquier archivo (los registros incompletos no son posibles cuando el tamaflo es 1).
Excepto para WRITE Y READ, todos los procedimientos y funciones estándares de l o s archivos de tipo están permitidos para los archivos sin tipo. En vez do READ y WRXTE, se usan dos procedimientos (Llamados BLOCKREAD y BLOCKWRITE) para transferencia de datos a alta velocidad. Las sintaxis de estos procedimientos son :
BlockRead(var f:file; var buf; count:word [ ; var result: word I ) ;
BlockWrite(var f:Eile; var buf: count:word [ ; var result: word I ) ;
donde: . . .. ". .. . . . ..
f : variable archivo sin tipo buf : cualquier variable count result : variable tipo word
: es una expresi6n de tipo word
65
.,., . .
. ,
' f
BlockRead lee count o menos registros del archivo f en memoria, comenzando en el primer byte ocupado por buf. El tamaño de registro del archivo f se determina cuando se abre el archivo. ~l número real de registros completos leídos (menor o igual que count) se regresa en el parámetro opcional result.
Blockwrite escribe count o menos registros al archivo f de memoria, comenzando en el primer byte ocupado por buf. El tamaño de registro del archivo f se determina cuando se abre el archivo. El número real de registros completos escritos (menor o igual que count) se regresa en el parámetro opcional result.
Con estos procedimientos de Pascal es posible manejar el archivo FT (tabla derivada de aplicar una tespecificación de consulta>) sin declarar su tipo de registro. Lo único que se necesita es determinar el tamaño de registro para FT, el cual puede ser determinado como ya se dijo, en base al tipo de dato de cada uno de los elementos de la lista del SELECT de la tespecificación de consulta>. Por ejemplo, supóngase que se tiene la siguiente formulación de SQL:
Ejemplo 3.3.2.4.3.2
11 Deciare Cursor C1 For 21 Select SNo, Status 31 From S 41 Where City = ‘London’;
El c6digo en Pascal equivalente (s610 referente a la tabla derivada T ) sería mas o menos el siguiente.
Ejemplo 3.3.2.4.3.3
var cl : File;
begin Assign(c1, *cl.dat*); rewrite(cl.10); { código equivalente para obtener la tabla resultado e ir guardándola en cl 1 ciose(c1);
end.
Como puede observarse en este &digo, el tamaño de registro del archivo c1 es de 10. Esto se debe a la suma en bytes de los tipos de datos de cada elemento en la lista SELECT (linea 2 del ejemplo 3.3.4.3.2). El primer tipo de dato (equivalente en Pascal) es un string de longitud 3 (más un byte para guardar la longitud del string) y el segundo es de tipo LongInt ( 4 bytes). Los otros 2 bytes corresponden a la posibilad de valores nulos para cada
66
. ..
elemento.
y éste
e s t r u c t u r a dinámica en l a c u a l cada elemento guarde l a desc r ipc ión de un c u r s o r . La e s t r u c t u r a d e cada nodo puede ser l a s i g u i e n t e :
de consu l t a> inc luye alguna l a misma forma d i r e c t a . Por
s e r í a l a secuencia d e l a Figiira 3 . 2 5 .
3 ) A?!%ar l a c l á u s u l a SELECT ( l í n e a 5 ) sobre l a l a t a b l a T1 para obtener l a t a b l a T2. donde :
6 ) Finalmente, se a l i c a l ~ ~ ~ ~ ~ s U I a e s Z c u e n l t r i l í ? , ~ ~ e ~ f . o ~ ~ ~ , u r t '"%ado, y un va o r d e 3 para obtener l a tat!!%&%& gso contrario.
* Mediante e s t a e s t r u c t u r a es pos ib le c o n t r o l a r e l es tado y l a s
operaciones d e un c u r s o r . Cuando se dec la ra un curso r mediante SQL, en Pasca l , a p a r t e de obtener e l archivo FT, se da d e a l t a un nodo d e l t i p o de l a e s t r u c t u r a a n t e r i o r . Cuando se abre por primera vez un curso r , se accesa e l nodo correspondiente a ese cursor y se as igna un v a l o r de verdadero a l campo CursorAbierto. Si se i n t e n t a
69 .67
abrir el cursor otra vez se verifica si no ha sido abierto previamente. Lo mismo sucede cuando se cierra un cursor. Cuando se aplica la cláusula FETCH sobre un cursor, se determina primero si el cursor ha sido abierto y después si el recorrido de los registros del archivo FT no se ha efectuado totalmente. Esto se hace comparando el campo ApuntadorC con el campo TotaiRegC. Si no se han recorrido totalmente los registros, entonces se efectúa una proposición BlockRead a la variable tipo buffer descrita en ( 3 . 3 . 2 . 4 . 2 ) y después se incrementa en una unidad la variable ApuntadorC. El número de registros del archivo FT se determina con la función FileSize de Pascal (TotaiRegC := FiieSize(FCur)). Además, esta estructura permite manejar de manera dinámica las variables tipo archivo sin tipo relacionadas con un cursor, evitando declararlas en el código generado.
Esta estructura, así como los procedimientos para abrir y cerrar cursores se encuentran en la Unidad SQL.
3.3.2.4.3.5
Hasta este punto, se ha analizado la forma en que podría manejarse la tabla derivada de aplicar una <expresión de consulta> asociada con una declaración de cursor, sin embargo, no se ha especificado cómo obtener esa tabla derivada, es decir, no se ha analizado la forma de generar el código equivalente para una <expresión de consulta>.
Actualmente existen varios enfoques en la literatura especializada de cómo resolver una consulta mediante algoritmos de optimización de consultas. Estos algoritmos tienen la finalidad de establecer los pasos necesarios mínimos para obtener la respuesta y están basados en operaciones algebraicas.
El método que se utiliza en este trabajo es una forma directa, la cual consiste en obtener el resultado de tuna especificación de consulta> aplicando en una secuencia inversa de declaración, cada uno de l a s partes (estatutos) qye conforman esa <especificación de consulta>. Esta forma constituye la manera más lógica de cómo resolver una consulta en papel. Por ejemplo, el siguiente algoritmo muestra cómo seria la secuencia de pasos para resolver la consulta de la Figura 3 . 2 4 .
1) Realizar el producto cartesiano de las tablas S y SP para
2 ) Aplicar la cláusula WHERE a cada uno de los renglones de T1 para obtener la tabla derivada T2.
3 ) Aplicar la cláusula SELECT sobre la tabla T2 para obtener la tabla derivada final T3 (resultado).
Pascal y las especificaciones de consulta
obtener la tabla derivada T1. t
68
$Deciare Cursor Ejem f o r Select S.SNO From S, SP Where S.SNo = SP.SNo And SP.PNo = ' p i ' ;
FIGURA 3 .24 CONSULTA PARA OBTENER LOS NUMEROS DE PROVEEDORES QUE SUMINISTRAN LA PARTE ' P i ' .
Cuando una <espec i f i cac ión d e con-;ulta> inc luye alguna <subconsul ta>, é s t a puede r e s o l v e r s e d e l a misma forma d i r e c t a . Por ejemplo, l a s i g u i e n t e Figura muestra como s e r í a l a secuencia de pasos para r e so lve r l a consul ta de l a Figura 3 .25 .
1) Apl icar l a c l á u s u l a FROM SP ( l í n e a 6 ) . En e s t a caso l a t a b l a der ivada es l a misma t a b l a SP.
2 ) Apl icar l a c l á u s u l a WHERE ( l í n e a 7 ) a acada uno de l o s renglones d e SP para obtener l a t a b l a T 1 .
3 ) Aplicar l a c l áusu la SELECT ( l í n e a 5 ) sobre l a l a t a b l a T 1
4 ) Apl icar l a c l áusu la FROM S ( l í n e a 3 ) . En este caso l a t a b l a
5 ) Apl icar l a c l áusu la WHERE ( l í n e a 4 ) a cada uno de los renglones d e l a t a b l a S. Esto involucra a p l i c a r un predicado de l a forma cexpresion e s c a l a r > I n <subconsul ta>, l o c u a l s ignif ica que para cada uno de l o s renglones d e l a t a b l a S en s u columna SNo se v e r i f i c a s i su v a l o r corresponde a algún v a l o r d e alguna de l a s columnas d e l a t a b l a T2. Los renglones que cumplan con e s t a condición cons t i tuyen l a t a b l a derivada T3.
6 ) Finalmente, se a p l i c a l a c láusu la SELECT ( l í n e a 2 ) sobre T3 para obtener l a t a b l a f i n a l TP.
para obtener l a t a b l a T2 .
der ivada es l a misma t a b l a S.
69
1 2 3 4 5 6 7
FIGURA 3.25 CONSULTA PARA OBTENER LOS NUMEROS DE PROVEEDORES QUE SUMINISTRAN LA PARTE 'pl' MEDIANTE SUBCONSULTAS.
$Declare Cursor Ejemp for Select SNo From S Where SNO in
3 (select SP.SNO I From SP '2 Where PNo = tpli); \,
Para generar el cbdigo correspondiente a una tespecificaci6n de consulta> de la forma:
SELECT 1 FROM 1 WHERE 1
(SELECT 2 FROM 2 WHERE 2
(SELECT N FROM N WHERE N)); ,
el precompilador debe producir una salida de la forma:
FROM N WHERE N SELECT N FROM 2 WHERE 2 SELECT 2 FROM 1 WHERE 1 SELECT 1
Una vez determinada la forma de aplicar los estatutos de una <especificación de consulta> para lograr el código equivalente, queda por resolver precisamente cómo lograr la equivalencia de cada una de las partes de una <especificación de consulta>.
70
3.3.2.4.3.5.1 La cláusula FROM en Pascal
El primero de los estatutos a realizar en una <especificación de consulta> (de acuerdo a la forma de resolverlos en el código) es el estatuto FROM. El estatuto FROM tiene como función (3.3.2.4.3.3.1) especificar una tabla derivada (a la cual denominaremos TFROM) de uno o más <nombre de tablax.
Cuando una tcláusula from> tiene un sólo <nombre de tabla>, no es necesario crear la tabla TFROM. Lo iinico que se hace es considerar la tabla especificada por ese <nombre de tabla> como la tabla TFROM. El problema viene cuando se especifica más de una tabla. En este caso, la tabla TFROM se obtiene realizando el producto cartesiano de las tablas especificadas. Para crear el producto cartesiano se utiliza un archivo sin tipo cuyo tamaño de registro es igual a la suma de los tamaioc de registro de cada tabla especificada. Se emplea tambi&n el esquema de buffer y N ciclos anidados dependiendo del número de tablas especificadas. Por ejemplo, la Figura 3.26 muestra el algoritmo para realizar el producto cartesiano de dos tablas cualesquiera A y B.
I
LRA:= (Longitud de registro de A ) LRB:= (Longitud de registro de B} NA:= [Número de renglones de A) NB:- (Número de renglones de B) Assign(F,'ProdCart'); rewrite(F,NAtNB); for i:=l to NA do begin LeeZ(A,Bufferl[l], Edo); for j :=1 to NB do begin LeeZ(B,BuffeZ[l], Edo); Move(Buffer2[1], Bufferl[CRA+l], LRB ; BlockWrite(F, Buffer1,l);
end ; end ;
FIGURA 3.26 PRODUCTO CARTESIANO PARA POS TABLAS CUALES- QUIERA A Y B.
Como después de ejecutar una tcláusula from>, l a siguiente cláusula puede o no ser una <cláusula where>, es necesarip establecer un mecanismo para determinar l a tabla sobre l a que va a efectuarse el SELECT. Este mecanismo puede establecerse medianta
71
una variable de tipo booleano (la cual denominaremos HUBOWHERE) a la que se le asignaría el valor FALSE despues de ejecutar un FROM para indicar que el siguiente SELECT se va a efectuar sobre la tabla derivada del FROM. Si la cláusula después del FROM es un WHERE, entonces a la variable HUBOWHERE se le asigna un valor de verdadero.
3.3.2 .4 .3 .5 .2 La cláusula WHERE en Pascal
El segundo estatuto a realizar en una <especificación de consulta> es la cláusula opcional tcláasula where> (siempre y cuando se especifique). Como se estableció en 3 . 3 . 2 . 4 . 3 . 3 . 2 , la <cláusula where> tiene como función especificar una tabla derivada por la aplicación de una <condición de búsqueda> al resultado de la anterior <cláusula from> (en este caso la tabla TFROM).
En Pascal, la tabla producida especificada por la tcláusula where> (la cual denominaremos "ERE) se obteniene de la siguiente forma: para cada uno de l o s archivos de la tabla TFROM se aplica la <condici6n de búsqueda> del WHERE. Si esta <condición de búsqueda> genera un valor de verdadero, no es necesario escribir el registro completo de TFROM en TWHERE. En vez de ello, sólo es necesario escribir el número de ese registro que cumple con la <condición de búsqueda>. La tabla TWHERE se maneja como un archivo de un tipo de registro de un solo campo, el cual es de tipo "LongInt". La variable de este tipo de archivo puede ser declarada en la unidad SQL.
La parte de la tcláusula where> que falta por resolver es precisamente la relacionada con los elementos de esta cláusula: predicados y operadores booleanos. Además, en SQL el resultado de aplicar una <condid611 de búsqueda> genera un valor de verdad de "verdadero", "Falso" o "desconocido". En Pascal, el resultado de aplicar una expresión booleana produce uno de dos valores: "verdadero' o "falso". El valor de verdad "desconocido" no es soportado por Pascal para expresiones booleanas. Por lo tanto, es necesario implementar un mecanismo para manejar este valor. El método empleado para implementar el manejo del valor de verdad "desconocido" así como la forma de generar cbdigo para los predicados y los operadores booleanos se describen en el Capítulo 4 .
3.3.2.4.3.5.3 Pascal y el SELECT
El siguiente estatuto a realizar en una <especificación de consulta> es el SELECT. Este estatuto tiene dos formas de efectuarse dependiendo de que si es o no parte de una <subconsulta>. si lo es, el resultado de aplicarlo es una tabla derivada que se utiliza para los predicados de comparación, IN y EXIST de la anterior tcláusula where> aplicada. Si no es parte de
1 2
una <subconsulta>, entonces el resultado de aplicarlo es la tabla derivada final FT ( 3 . 3 . 2 . 4 . 3 . 4 ) .
Independientemente del lugar en que aparezca, el SELECT se efectúa de la siguiente manera: Si la variable HUBOWHERE contiene un valor de "verdadero", entonces para cada uno de los registros del archivo TFROM cuyo número de registro aparezca en el archivo TWHERE se aplica el SELECT. Esto produce un valor para cada uno de los elementos de la lista del SELECT. Estos valores a su vez constituyen un registro RS, el cual es grabado en el archivo correspondiente:
1) Si el SELECT que se aplica es parte de una <subconsulta>, entonces el registro RS se graba siempre en un archivo (al cual denominaremos TSUBQUERY). El archivo TSUBQUERY es un archivo sin tipo y se crea cada vez que se aplica un SELECT de una <subconsulta>. 'La longitud de su registro depende del único elemento del SELECT.
2) Si el SELECT no es parte de una <subconsulta>, entonces el registro RS es grabado en el archivo FT ( 3 . 3 . 2 . 4 . 3 . 4 ) .
Si la variable HUBOWHERE contiene un valor de "falso", entonces el SELECT se aplica a todos los registros del archivo TFROM .
Hasta este punto, se ha mostrado la forma de producir el código equivalente para un estatuto SELECT que aparece como parte de una declaración de un cursor. La otra forma del SELECT es cuando se aplica para obtener valores de un renglón específico de una tabla. La sintaxis es la siguiente:
<estatuto select>::= SELECT <lista del select> INTO <lista objeto del select> <expresión de tabla>
Como puede observarse, la sintaxis es similar a la de una <especificación de consulta>, excepto por la parte del INTO. Para un <estatuto select> la secuencia de pasos para aplicarlo, son los mismos que para una tespecificacidn de consulta>. La única diferencia estriba en el iiltimo paso: En lugar de grabar el registro RS en el archivo FT, sus valores se guardan en las variables anfitrionas especificadas en la parte INTO (siempre y cuando el resultado de aplicar el último <select> produzca un único renglón).
7 3
3 . 3 . 2 . 4 . 4 El estatuto UPDATE
El <estatuto update> tiene como funcibn actualizar renglones de un tabla que cumplan con una condición de búsqueda. La sintaxis es la siguiente:
<estatuto update>::= UPDATE <nombre tabla> SET <cláusula set> ((,<cláusula set>)l (WHERE <condiclbn de búsqueda>{
<cláusula set>::=<nombre de columna> = (texpresibn escalar> I NULL]
La Figura 3 . 2 7 muestra un programa en Pascal y SQL para actualizar los renglones de la tabla S, duplicando el valor de la columnas Status para los proveedores en London.
I
Uses SQL; begin $Update S Set Status = Status * 2 Where City = 'London';
end.
FIGURA 3 . 2 1 EJEMPLO DEL ESTATUTO UPDATE.
La Figura 3 . 2 8 muestra el resultado del programa de la Figura 3 . 2 7 .
SNO SNAME STATUS S.CITY -- si Smith 4 0 London s 2 Jones 10 Paris s3 Blake 30 Paris s4 Clark 40 London S 5 Adarns 30 Athens
FIGURA 3 . 2 8 RESULTADO DEL PROGRAMA DE LA FIGURA 3 . 2 7
7 4
Como puede observarse, la sintaxis de esta estatuto es similar a la sintaxis de un <estatuto select,. Si tomamos la parte de UPDATE como la parte FROM de una <especificación de Consulta> e invertimos el orden de las partes UPDATE <nombre de tabla> y SET, entonces tendríamos una equivalencia de la siguiente manera:
SET tcláusula set> FROM tnombre de tabla> IWHERE <condición de búsqueda>I
La parte FROM y WHERE constituyen una <expresión de tabla> con la diferencia de que el número de tnombre de tablax para la tcláusula FROM> es sólo una. Por lo tanto, para obtener el código equivalente en pascal puede aplicarse la misma metodología que para una <especificación de consulta>. La Única diferencia estriba en el Último paso: En lugar de grabar el registro RS en el archivo FT (este archivo no es necesario), primero se cambian sus valore conforme a lo establecido en la <claúsula set> y después se graba en la misma tabla especificada por UPDATE.
3.3 .2 .4 .5 EL estatuto DELETE
El <estatuto delete> tiene como función suprimir los renglones de un tabla que cumplan con una condici6n de búsqueda. La sintaxis es la siguiente:
<estatuto delete>::= DELETE FROM tnombre tabla> [WHERE <condición de búsqueda>I
La Figura 3.29 muestra un programa en Pascal y SQL para suprimir los renglones de la tabla S para aquellos proveedores que están localizados en Paris.
Uses SQL: begin
end.
Delete From S Where City = 'Paris';
I FIGURA 3.29 EJEMPLO DEL ESTATUTO DELETE.
La Figura 3.30 muestra el resultado del programa de la Figura 3.29.
- SNO SNAME STATUS S.CITY s1 Smith 40 London s4 Clark 40 London s5 Adams 30 Athens
FIGURA 3.30 RESULTADO DEL PROGRAMA DE LA FIGURA 3.29
Como puede observarse, la sintaxis de este estatuto es similar a la sintaxis de una <especificación de consulta>.' Por lo tanto, para generar el código equivalente en Pascal de esta cláusula puede aplicarse la misma metodología que para una tespecificación de consulta>. La Única diferencia estriba en el Último paso: En lugar de grabar el registro RS en el archivo FT (este archivo no es necesario), se borra este registro RS de la misma tabla especificada por DELETE.
3 . 3 . 3
En CQL üna tabla puede tener especificada una o más restricciones de unicidad, cada una de las cuales se establece sobre una o más columnas de esa tabla. Una tabla que tiene definida una restrlccibn de unicidad sobre üna columna ( o combinación de colümhas)~,- está restringida a que en ningún momento, dos renglones de esa t.abla tengan el mismo valor sobre esa columna ( o combinación de columnas).
La sintaxis de una definición de tabla es la siguiente:
<definición de tabla>::=
El problema de la unicidad de renglones
CREATE TABLE <nombre de tabla> ( <elemento de tabla> [(,<elemento de tabla>)...])
telemento de tabla>: : = <definición de columna> [<definición d e restricción de tabla>
<definición de columna>::= ¿nombre de columna> ¿tipo de dato> [<cláusula default>] [<restricción de columna>]
- I c .,, . . .I
<restricción de columna>::= NOT NULL [<especificaci6n de unicidad>]
<definición de restricción de tabla>::= <definición de restricción de unicidad>
<definición de restricción de unicidad>::= <especificacibn de unicidad> (<lista de columnas de unicidad>)
<especificación de unicidad>::=
<lista de columnas de unicidad>::=
UNIQUE 1 PRIMARY KEY
<nombre de columna> [(,<nombre de columna>)..]
Como puede verse en la sintaxis de la definición de una tabla, una <especificación de unicidad, puede declarse de dos maneras: una cuando se especifica una <restricción de columna> y otra cuando se establece una <definición de restricción de tabla>. En esta Última forma se puede especificar una lista de columnas sobre las que se define la tespecificacibn de unicidad> y en la primera sólo se establece la unicidad sobre una columna. La Figura 3.8 muestra un ejemplo de una especificación de unicidad para la tabla S. En este ejemplo, la tabla S está restringida a que en ningún momento dado, dos renglones tendrán el mismo valor para la columna SNo. Otro ejemplo de especificación de unicidad se muestra en la Figura 3.31. En este ejemplo, la tabla ENVIOS tiene definida una restriccibn de unicidad sobre las columnas SNo y PNo.
Create Table Envios( SNo : Char(S), PNo : Char(S), Cantidad : Integer, Unique (SNO, PNO)):
FIGURA 3.31 EJEMPLO üE ESPECIFICACION DE LA REBTRICCXQN DE UNICIDAD.
~~~ ~ . ~~
Para poder manejar el concepto de restricción de unicidad, ea CABDD debe tener un mecanismo para saber sobre cuáles coluninaa de una tabla se ha definido una <espeficación de unicidad>. Este
7 1
- mecanismo se implementa a través del DAD, definiendo para cada <especificación de unicidad> un tipo de registro como el siguiente:
Tunicidad = record NOColS : l..MaxCols: SobreCols : array [l..MaxCols] of byte;
end ;
donde :
NoCois número de columnas sobre las que está definida la tespecificación de unicidad>.
SobreCols arreglo que contiene los números de columnas (conforme al orden especificado en la definición de la tabla) sobre las que está definida la <especificación de unicidad>.
Una restricci6n de unicidad para una tabla se verifica antes de la ejecución de algún estatuto de inserción o actualización para esa tabla. Sin embargo, para este proyecto se acordó realizar la verificación sólo antes de la ejecución del estatuto <insert>. En el caso del estatuto <update> se ha restringido a no aceptar cambios para aquellas columnas que participen en alguna <especificación de unicidad>.
El código generado por el precompilador para el estatuto <insert> debe por lo tanto, verificar la restricción de unicidad (si la tabla tiene alguna definida). Esto se puede lograr si antes de insertar un renglón RO en la tabla T se realiza lo siguiente para cada <especificación de unicidad> (Tunicidad en el DAD) :
1) Para cada renglon RF de la tabla T se toman los valores de las columnas sobre las que está definida la tespeficación de unicidad> y se comparan con los correspondientes valores de las columnas del renglón RO (las columnas sobre las que está definida la <especificación de unicidad>. Sitodos los valores son los mismos, entonces se ha violado la restricción de unicidad y por lo tanto se genera una condición de error. S i alguno de los valores es diferente, entonces se pasa al siguiente paso.
2 ) si no hay más renglones en la tabla, entonces el renglón RO se inserta en la tabla T (en caso de que no haya más <especificación de unicidad>s definidas); en caso contrario, se realiza el paso 1 para el siguiente renglón RF.
Como puede observarse, este algoritmo requiere realizar una búsqueda secuencia1 a traves de la tabla T por cada renglón RO a
78
insertar. Es claro que para mejorar el rendimiento del sistema en cuanto a la inserción, se requiere otra forma de verificar la restriccion de unicidad. El manejo de índices puede proporcionar esta forma no sólo para la operación de insertar, sino también para las operaciones de borrado y consulta.
Por cada <especificación de unicidad> se puede definir un archivo de índices. El valor de la llave estaría formado por la <lista de columnas de unicidad>. De esta manera, cuando se intentara insertar un renglón RO, se buscaría por la llave en los archivos de índices correspondientes. Si no existe en ninguno de estos archivos, entonces se puede insertar el renglón RO y después actualizar los archivos de índices.
3.3.4 El problema de la implementacián de índices
En la literatura de bases de datos y teoría de archivos, se pueden encontrar diferentes técnicas y algoritmos para el manejo de archivos de índices. La diferencia entre cada una radica principalmente en la estructura de datos que se utiliza para implementarlos. Cada estructura tiene diferentes características de rendimiento; algunas son buenas para algunas aplicaciones y otras son buenas para otras. No hay una sola estructura que sea óptima para todas las aplicaciones. Sin embargo, los "árboles B" o alguna variación de ellos parecen proporcionar el mejor rendimiento. Por esta razón, la mayoría de los sistemas relacionales usan "árboles B" como su principal forma de estructura de almacenamiento [ 271 . En base a ésto y a que los algoritmos para su implementaci6n son tratados ampliamente en numerosas fuentes de información (por ejemplo [ 2 8 ] , [ 2 9 ] ) , se seleccionaron los "árboles B" para manejar los archivos de índices.
Cada archivo de índices debe, al igual que una tabla de la BDD, ser accesado de forma transparente. Por lo tanto, el código generado por el precompilador debe hacer uso de las primitivas del SABDD para accesar estos archivos. Cada archivo de índices definido para una tabla T, debe tener una descripción, la cual Consiste básicamente en las columnas de T que participan en la llave del índice, así como el tamafío de la llave y la longitud de registro del archivo. Esta descripción se maneja como la de una tabla por medio del DAD.
Un "árbol B" está organizado en páginas. Cada página contiene un conjunto de elementos, los cuales están formados por tres partes: una llave (correspondiente a un registro del archivo sobre el que se define el Indice), el número d e l registro asociado con la llave y un apuntador a una página que contiene valores de llaves mayores que la del elemento, pero menores que l a llave del siguiente elemento de la página anterior. Cada página P tiene además un apuntador a una página P o que contiene valores de llaves mayores que cualquier llave de la página P (véase Figuras 3 . 3 2 y
7 9
3 . 3 3 ) . Para mayores detalles de la organización de los "árboles B" y los algoritmos para manejarlos, el lector puede consultar las referencias [ 2 8 ] y [ 2 9 ] .
Cada archivo de índices está formado por registros. Cada uno de estos registros tiene asociado un tipo de registro que corresponde a la descripción de cada página del "árbol B". Como se dijo anteriormente, un archivo de Indices es considerado como una tabla para el SABDD y por lo tanto, las rutinas y técnicas utilizadas para una tabla son también empleadas para manejar un archivo de Indices.
a) Elemento de una página de un árbol B.
ti Apun t. iltim, elen. último elemento
u61 ido. posible
El en[ Con tadorl
b> Estructura de una gágina de un arbol E.
FIGURA 3.32 ELEMINXIS DE U N 4 PAGlNA DE UN ARBOL E.
Página Raíz 1 R
Pks. Externas u Hojas
FIQIRA 3.33 EJEWLO DE UH ARBDL 8 .
EO
3 . 3 . 5
Cuando se def inen l as columnas de una t a b l a (véase l a s i n t a x i s de l a d e f i n i c i ó n de una tabla en 3 . 3 . 2 . 4 . 6 ) , se puede opcionalmente e s p e c i f i c a r un v a l o r por omisión para cada una. Esto se hace mediante l a <c láusu la d e f a u l t > cuya s i n t a x i s es l a s igu ien te :
E l problema d e l v a l o r por omisión
t c l a ú s u l a de fau l t> : := DEFAULT ( < i i t e r a i > ( N U L L )
La Figura 3.34 muestra un ejemplo d e l uso de l a <cláusula de fau l t> . En este ejemplo, l a columna Ci ty de l a tabla Proveedores t i e n e d e f i n i d o un v a l o r por omisión que es 'London'. Cuando se agrega un renglón a l a t a b l a Proveedores y en e l < e s t a t u t o i n s e r t > no se especifica un va lo r para esa columna, entonces e l va lo r de esa columna s e r á 'London'.
Crea te Table Proveedores
SName Char ( 2 0 ) , Status I n t e g e r ,
( SNO Char(5) Not Null Unique,
FIGURA 3 . 3 4 EJEMPLO DE DEFINICION DE UNA COLUMNA CON UN VALOR POR OMISION.
Como puede v e r s e en l a s i n t a x i s de l a c l á u s u l a , e l va lo r por omisión que puede e s p e c i f i c a r s e para una columna, es el va lo r nulo o una l i t e r a l . E l manejo d e este va lo r por omisión es re la t ivamente f á c i l mediante e l DAD. Dentro de l a descr ipc ión de cada una de l a s columnas, se puede i n c l u i r un campo para i n d i c a r si e s a columna t i e n e o no d e f i n i d o un va lo r por omisión; o t r o campo para i n d i c a r si se t r a t a o no de l v a l o r nulo ( e n caso de t e n e r de f in ido un va lo r por omisión) y otro campo según el t i p o de d a t o de l a columna para guardar e l valor por omisi6n ( e n caso de t e n e r de f in ido un va lor por omisión y que ese valor no sea e l va lor nulo).
81
CAPITULO 4
DISEÑO DEL PRECOMPIuuxlR
En este capítulo se describe el diagrama de estructura del precompilador del lenguaje de manipulación de datos, la estructura del diccionario de archivos distribuidos (DAD), así como las estructuras de datos más importantes involucradas en el proceso de precompilaci6n y en el proceso de ejecución del programa resultante de la precompilacibn.
4.1 El diccionario de archivos distribuidos (DAD)
El diccionario de archivos distribuidos (DAD) constituye uno de los objetos más importantes del SABDD. El DAD contiene la información acerca de las tablas y archivos de índices de la BDD. Esta información es utilizada por los programas de aplicación, así como por el precompilador en el proceso de traducción. La forma en que se maneja el DAD en este proyecto es la misma que como se manejaba en 3.2.1 y 3.2.2:
1) Por cada máquina de la red se tiene un fragmento del DAD. Cada uno de estos fragmentos en una máquina contiene la descripción de las tablas que residen físicamente en esa 1 máquina (Figura 3.2). I
2 ) Cada fragmento se maneja a través de un archivo de tipo denominado Arch-N. Por cada tabla que reside en una máquina, se utiliza un registro del archivo Arch-N de esa máquina para almacenar la descripci6n de esa tabla.
3 ) El tipo de registro asociado con un archivo Arch-N es el si gui en te :
02
J RegArch-N = record
NombreT : string[12]; TipoT : TipoTabia; AltaT : Boolean: LongRenglonT : Integer; Llaveprimaria : Boolean; ColsEnLiave : Array[l..MaxCols] of Byte: TotaíColsT : i..MaxCols; TotaíIndsT ColsT IndsT
end ;
donde :
NombreT
TipoT
AitaT
LongRenglonT
Llaveprimaria
ColsEnLiave
TotalCoisT
TotalIndsT ColsT
IndsT
:. o..MaxIndices; : Array[l..MaxCols] of TColumna; : Array[i..MaxIndices] of TIndice
ES el nombre de la tabla y archivo asociado a la tabla con extensión .BDl. Es el tipo de la tabla el cual puede ser T (si se trata de una tabla) o I (si se trata de un archivo de índices (3.3.2.4.7)).
Indica si la tabla está dada de alta en el archivo (valor de verdadero). Indica la longitud en bytes de cada uno de los renglones de la tabla. Indica si la tabla tiene definida alguna llave primaria. Contiene los números de las columnas que participan en la llave primaria. Indica el número de columnas que tiene definida la tabla. Indica el número de índices de la tabla. Arreglo que contiene por cada elemento, la información para cada una de las columnas de la tabla. El tipo de registro TColumna se describe más adelante. Arreglo que contiene por cada elemento, la información para cada uno de los índices de la tabla. El tipo de registro TIndice se describe más adelante.
A continuación se describen los tipos de registros TCoiumna y TIndice.
TColumna = record Nom b r eC : String[l8]; TipOC : TipoCoiumnas; Longc : Integer; DesplazC : Integer:
83
NUlOC : Boolean; ValorOmision : Boolean; VaiOmiEsNuio : Boolean: ValOmiNoNulo : String[30]
end ;
donde:
NombreC TipOC
LongC
DesplazaC
NuioC
ValorOmision
ValOmiEsNulo
ValOmiNoNulo
Contiene el nombre de la columna. Contiene el tipo de la columna: Integer, LongInt, Real o String[n] (3.3.2.2). Contiene la longitud de la columna en bytes, dependiendo del tipo de dato de la misma (3.3.2.2). Posición en que se encuentra la columna a partir del inicio del buffer (3.3.2.4.2). Indica si la columna acepta valores nulos (verdadero) o no (falso). Indica si la columna tiene definido un valor por omisión (verdadero). Contiene un valor de veradero en caso de que la columna acepte un valor por omisión nulo. Contiene el valor por omisión para la columna en caso de que la columna tenga definido un valor por omisión y ese valor no sea el valor nulo.
TIndice = record NombreInd : String[12]; LongLlaveInd : Integer; TotalColsInd : l..MaxCois: ColsInd : Array[ 1. .MaxCols] of Byte
end ;
donde :
Nombre I nd
LongLlaveInd
TotalColsInd
colsrnd
Es el nombre del archivo asociado al índice con extensión .IDn, donde n es un número consecutivo de acuerdo al número de índice definido en la tabla. Por cada cada cláusula de unicidad se ocupa un archivo de índices (3.3.2.4.7). Contiene la lonqitud en bytes de la llave del - ~
índice. Contiene el número de columnas sobre las que está definido el índice. Contiene los números de las columnas sobre las que está definido el índice.
84
.
s . .. .. 'I
4.2 Algoritmo general de precompilación
A continuación se describe el proceso general efectuado por el precompilador del LMD para traducir el programa fuente de entrada (Pascal y SQL) al programa objeto de salida (Pascal). Este proceso se describe mediante Pascal y pseudocódigo.
program Precompilador; Const Ok = O; (Estado correcto) Var . .
FE, (archivo de entrada) FS : Text; (archivo de salida) E : Integer; (condicion de error)
begin Assign(FE,'ArchEntr.Ep'); Assign(FS,'ArchEntr.Pas'); reset(FE); rewrite(FS); E:=Ok; while (not eof(FE)) and (E=OK) do begin while (not eof(FE)) and (GetChar(Ch))<>'S') do write(FS,Ch); if Ch='$* then begin ApIniCiOTeXtO:=Nil; Get Token; if E( Begin) then E:=BEGINDECLARE else if R(Create) then E:=CREATETABLE else if R( Declare) then E:=DECLARECURSOR else if R(Se1ect) then E:=CELECP else if R( Insert) then E:=INSERT else if R(-Open) then E:=OPEN else if R(C1ose) then E:=CLOSE else if R( Fetch) then E:=FETCH else if R(Update) then E:=UPDATE else if R( Delete) then E:=DELETE else E:=ErForNo( 100, 'Estatuto no conocido' ) ; if E=Ok then GeneraCodigo;
end ; end ; if E=Ok then writeln(IN0 hubo errores.'); Ciose(FS); Ciose(FEl);
end. (programa)
De este algoritmo, se puede observar le forma en qua se hace la traducción del programe fuente. Una vez que en 01 programa do entrada se encuentra el inicio de texto de un estatuto de SQL ( e ) , se determina de qué estatuto se trate y despues se efeietQa el proceso de traducción de este estatuto. La variable E ea una variable global y sirve para controlar ei estado de exito del proceso de precompilación. Mientras esta variable contenga el valor de Ok, el proceso es correcto. Antes de efectuar la traducción de
85
un estatuto se inicializa la lista que va a contener el texto La traducción de cada estatuto
de SQL se implementa mediante una función de tipo entero. si la traducción del estatuto fue exitosa, entonces la función asociada a ese estatuto regresa un valor de O (Ok) y entonces se procede a generar el código equivalente en Pascal. Esto se hace recorriendo los nodos de la lista que contiene el texto equivalente y escribiendo al archivo de salida el texto de cada nodo. si durante el proceso de traducción ocurre algún error, ya sea de sintaxis o semántico, entonces la variable E toma el valor asociado al tipo de error y el proceso se detiene, mostrando en pantalla el mensaje correspondiente al error.
El código generado por el precompilador respecto a los estatutos de SQL consiste básicamente en llamadas a procedimientos que se encuentran en la unidad de SQL (esta unidad debe declarse en el programa fuente a traducir).
1 equivalente del estatuto (3.3.1).
i i
La Figura 3.5 muestra el diagrama de estructura para cada estatuto de SQL a traducir. Como puede observarse, el módulo principal lo constituye el del analizador sintáctico. Este módulo dirige el proceso de traducción y generacibn de código. Al momento en que se va realizando el análisis sintáctico, se van solicitando tokens al analizador léxico, asimismo, conforme se va reconociendo la sintaxis correcta del estatuto, el analizador sintáctico hace llamadas a las rutinas semánticas las cuales verifican el significado correcto de la expresión y al mismo tiempo también se va escribiendo en la lista que contiene el código a generar.
El módulo del analizador sintáctico para cada estatuto, se implementa a través de un autómata. Por cada uno de los estados del autómata se verifica un elemento de la expresión sintáctica del 4 estatuto de SQL. Como ejemplo, la Figura 4.1 muestra el autómata 1 para reconocer la sintaxis del estatuto INSERT.
URLUES
I .. ..
FlCURR ’4.1 AUTOMRTR PRRR RECOHOCER LR SIHTRXIS DEL ESTflTUlú IHSERI
86
A continuación se presenta la forma en que se impiementa en Pascal la traducción del estatuto INSERT basándose en el autdmata de la Figura 4.1.
Function INSERT : Integer; Type
Estados=(qO, ql, 92, 93, 94, q5. 96, q7 , ..., qli); Var
: Estados; : Integer;
Q E TablaIns : TRegArch-N;
begin Q:=ql; E:=OK; repeat Get-Token; case Q of ql : if R( Into) then Q:=q2
92 : if T(1dentificador) then begin eise-E:=Error0(102,' INTO');
BuscaArchivo2(LexVal,Tabla,Estado); if Estado = O then Q:=q3; else E:=-1; end else E:=(102,'Identificador de tabla.');
. . q4 : if T(1dentificador) then begin
(Buscar si la columna está definida en la tabla TablaIns. Si está definida entonces Q:=q5 y si no E:=Error(llS,' Columna no definida'))
end else E:=Error(lO2,' Identificador de col.'); ..
q10: if T(PyC) then Q:=qll else E:=Error0(102,';'); end: (case)
until. (i=qiij or (E<>Ok); INSERT:=E;^R
end; (Function)
La rutina BuscaArchivo2 (estado 92) es otra primitiva del SABDD y tiene como función buscar la descripción de la tabla en la BDD especificada en el primer parámetro y regresar esa descripción en la variable utilizada como segundo parámetro.
Lexval es una variable tipo string que se utiliza para almacenar el valor del token que se obtiene después de llamar a la rutina Get-Token.
07
En el algoritmo para el estatuto INSERT se puede observar la importancia del DAD en el proceso de traducción. La Figura 4 . 2 muestra un ejemplo del estatuto INSERT. Para este ejemplo, de acuerdo a la Figura 4 . 1 , en el estado 9 4 , se necesita verificar si las columnas SNo y Status en la lista del INSERT (linea 3 ) están definidas en la tabla. Después en el estado 98 se necesita verificar si los valores asignados a esas columnas mediante la lista del VALUES ( ' ~ 7 ' y 3 0 ) son del mismo tipo que los correspondientes tipos de las columnas SNo y Status. Esta información se obtiene del DAD.
I 1 Uses SQL; 2 begin 3 $INSERT INTO S (SNo, Status) 4 VALUES ( ' s 7 ' , 3 0 ) ; 5 end.
FIGURA 4 . 2 PROGRAMA EN SQL Y PASCAL PARA ADICIONAR UN RENGLON A LA TABLA S.
Durante el proceso de traducción para cada uno de los estatutos de SQL, se emplean diferentes estructuras aparte del DAD. Estas estructuras tienen la función de mantener los símbolos que se definen en el programa y de facilitar la traducción. Por ejemplo, en el estatuto INSERT se emplea una estructura dinámica para mantener la descripción de cada uno de los elementos de la lista del VALUES que se van analizando. Cada uno de los nodos de esta estructura dinámica se muestra en la Figura 4 . 3 .
Cuando se verifica la sintaxis para un elemento de la lista del VALUES, se crea un nodo del tipo NodoListaValues (Figura 4 . 3 ) . Por ejemplo, para el elemento 30 del VALUES de ia Figura 4 . 2 (linea 4 ) el cual está relacionado con la columna STATUS, se crea un elemento con los siguientes valores:
TipoDatoCol:=EnteroLargo;
DesplazCol : = 2 8 ;
Tipovalor :=Literal; VaiorEiem :='30';
Long c o 1 :=4;
NuloCol :=True;
Con esta información se puede entonces llamar a la rutina que guarda el texto a generar ( 3 . 3 . 1 ) . Por ejemplo, para el nodo
88
anterior algunas de las llamadas a GEN-COD son las siguientes:
GEN COD(' MUEVE-A-BUF-LITERAL-LONGINT(',FALSE,FALSE); GEN:COD(*~O~ + ' 2 8 ' + 'TRUE' + ' ) ; I , FALSE, TRUE);
Cuando se regresa de la función INSERT y el valor de E es Ok, entonces se hace el llamado a la rutina GeneraCodigo, la cual recorre la lista del TEXTO a generar y escribe en el archivo de salida FS. Para las anteriores llamadas a GEN-COD, el texto generado por el precompilador consistiría en una llamada a un procedimiento de la unidad SQL:
- MUEVE - - A BUF - LITERAL_LONGINT(30,28,TRUE); El c6digo de esta rutina consiste en los siguiente:
- MUEVE-A-BUF-LITERAL-LONGINT(Valor:LongInt;Desplaz:Integer begin
Nu1oC:Booiean);
Move(Valor,SQLBUFFER[Despiaz],4);
if NuioC then SQLBUFFER[Despiaz+S]:=o;
{ Si la columna acepta el valor nulo entonces colocar False en su campo nulo )
end :
89
ApListaVaiues = ^NodoListaValues; . NodoListaValues = record TipoDatoCol : Byte; LongCol : Byte DespiazCoi : Integer; NuioCoi Tipovalor VaiorElem SigElem
donde
TipoDatoCol
LongCol
DespiazCol
NuloCol
Tipovalor
ValorEiem
: Boolean; : (NULL, Literal, Variable); : String; : ApListaVaiues;
Es el tipo de dato de la columna a la cual se va a asignar el elemento de la lista del VALUES. Contiene la longitud en bytes de la columna (de acuerdo a TipoDatoCol) a la cual se va asignar el elemento del VALUES. Es el desplazamiento de la columna dentro del registro (buffer) asociado a la tabla que la contiene. Indica si la columna a la que se le va a asignar el elemento del VALUES acepta o no valores nulos. Indica si el elemento del VALUES a asignar a la columna es un valor nulo o un valor no nulo. En este último caso el valor no nulo puede ser de dos tipos: literal o variable. Contiene el valor a insertar en la columna correspondinte.
FIGURA 4 . 3 ESTRUCTURA DE UN NODO DE LA LISTA DEL VALUES EN UN ESTATUTO INSERT.
4 . 3 La traducción y evaluación de expresiones escalares
Una <expresión escalar> en SQL es básicamente una expresión aritmética que involucra una colección de <primario>s, donde un <primario> es cualquiera de los siguientes:
una <especificación de valor> (3.3.2.4.2) o una referencia a una columna o una <especificación de función de conjunto> o una <expresión escalar> entre paréntesis.
90
i Una tesp. de función de conjunto> opera sobre los valores de una columna de una tabla derivada (3.3.2.4.3) y puede ser cualquiera de las siguientes:
COUNT MIN MAX AVG SUM
regresa el número de elementos de una columna. regresa el valor más pequefío de una columna. regresa el valor más grande de una columna. regresa el promedio de los valores de una columna. regresa la suma de los elementos de una columna.
La Figura 4 . 4 muestra un programa en Pascal y SQL para el uso de las especificaciones de funciones de conjunto. El resultado de este programa produce la siguiente tabla:
Athens 220 10
~ ~~ ~~
uses sql; $begin declare section
CiudadMin : String[20]; StatusPorDos : LongInt; StatusMin : LongInt;
end declare section; begin $select Min(City), Sum(Statuc) * 2, Min(Status1 from S into :CiudadMin, :StatusPorDos, :StatusMin>.-,
I if SQLCODE=O then begin writeln('Resu1tado de la consu1ta:'i: writeln (CiudadMin, StatusPorDos, StátusMin) : l end
end.
FIGURA 4 . 4 PROGRAMA QUE MUESTRA EL USO DE FUNCIONES.
El análisis de una expresión aritmética así como el procedimiento para evaluarla constituyen una de las partes más importantes de todo compilador o intérprete. Diferentes técnicas y algoritmos se han escrito para realizar esta tarea y éstos pueden encontrarse en la literatura sobre teoría de compiladores e intérpretes.
Una de las técnicas más utilizadas para la evaluación de expresiones aritméticas es convertir la expresión original a
91
' notación postfija o polaca. El precompilador desarrollado en esta tesis utiliza esta técnica para evaluar expresiones. LOS algoritmos para realizar esta técnica están descritos ampliamente en varios textos, como se dijo anteriormente. Las referencias [30, 311 son ejemplos de fuentes donde se pueden encontrar dichos algoritmos.
Una vez convertida la expresión original a su forma en postfijo, se utiliza una pila para evaluar la expresión. Por ejemplo, supóngase que se tiene la siguiente expresión aritmética:
(3+4) * 5
O l a forma en postfijo de esta expresión es la siguiente:
3 4 + 5 *
Para evaluar una expresión en notación postfija se utiliza una pila para ir guardando cada operando de la expresión y cuando se alcanza un operador, entonces se sacan dos operandos del tope de la pila realizando con ellos la operación indicada por.el operando y el resultado se guarda de nuevo en la pila. La secuencia de pasos para evaluar ( 2 ) es la siguiente:
3
Colocar el operando 3 en la pila. Colocar el operando 2 en la pila. Sacar los operandos 2 y 3 de la pila y realizar con ellos la operación indicada por el operador ( + ) . En este caso se realiza una suma entre ellos que da como resultado un valor igual a 7. Colocar el resultado del paso 3 en la pila. Colocar el operando 5 en la pila. Sacar los operandos 5 y 7 de la pila y realizar con ellos operación indicada por el operador ( * ) . En este caso se realiza una operación de multiplicación entre ellos que da como resultado un valor de 35. Colocar el resultado del paso 6 (35) en la pila.
El resultado de la evaluación de una expresión en postfijo se ~ ~~
deja en el único elemento de la pila.
Los diferentes tipos de operandos (<primario>s) de una expresión escalar en SQL, así como los tipos de valores que puede tomar cada uno (valor nulo o valor no nulo), constituyen la diferencia con una expresión aritmética.
La forma en que se manejó este problema en este precompilador /es la siguiente:
92
J 1) La expresión escalar El se traduce a una expresión en notación
postifija EP. Cada elemento de EP se representa mediante un nodo de una lista ligada LL.
2) La estructura de cada nodo de LL tiene la siguiente información:
a) El tipo de elemento del que se trata. miede ser un operador o un operando. Si se trata de un operador se debe tener un campo para indicar de qué operador se trata (+, -, *, / ) . Si se trata de un operando se debe tener un campo para indicar de qué tipo de operando se trata (<literal>, <esp. de variable>, <columna>, <funcibn>).
b) Si se trata de un elemento tipo operando, se debe tener un campo para indicar su tipo de dato (Integer, LongInt, Real o String[n]).
c) Dependiendo del tipo de operando se deden tener campos para describir la información de cada uno. Por ejemplo, para las literales se debe tener su valor; para las columnas se debe tener su desplazamiento en el buffer (3.3.2.4.2); para las funciones se debe tener de gu4 funci6n se trata, etcetera.
3) Para evaluar una expresión EP se utiliza un pila P. Cada J elemento de P tiene la siguiente estructura:
TNodoPiia = record VaiorNulo : Boolean; (Indica si elemento es el valor nulo
case TipoDato of 1 : (Cadena : record (Tipo de dato String)
o no)
PointerCtring : Pointer: LongCadena : Byte;
end) ; 2 : (Entero : Integer); 3 : (EntLargo :, LongInt); 4 : (DReai : Real) ;
J end :
4) La evaluación de EP se realiza recorriendo cada uno de los elementos de LL. Cuando se trata de un operando, Bste se guarda en P1 observando si se trata del valor nulo o no y del tipo de dato del operando y su valor. Cuando se trata de un operador se sacan los dos elementos que se encuentren en al tope de la pila y se realiza entre ellos la operaci6n indicada por el operador siempre y cuando los dos valores sean no nulos y el resultado se guarda en P. Cuando alguno de los operandos es el valor nulo, entonces el resultado, independientemente del tipo de OperadOF, es el valor nulo y este valor nulo se guarda en P.
93
4.4. Traducción de las condiciones de búsqueda
como se estableció en 3.3.2.4.3.3.2.1 una <condición de búsqueda> es básicamente una colección de <predicado>s combinados usando los operadores booleanos AND, OR y NOT.
La sintaxis de una <condición de búsqueda> es muy parecida a la sintaxis de una expresión escalar con algunas diferencias: En lugar de los operadores aritméticos +, -, * y /, se emplean los operadores lógicos AND, OR y NOT. En lugar de los <primario>s en una expresión escalar, se utilizan los <primarios booleanos>, los cuales son <predicado>s. Desde luego, a diferencia de las expresiones escalares que producen un valor, las condiciones de búsqueda producen un valor de verdad de "verdadero", "falso" o "desconocido" .
De lo anterior se desprende que una <condición de búsqueda> puede ser traducida como una <expresión escalar>. Por ejemplo, una <condición de búsqueda> como la siguiente:
Predicado1 or Predicado2 and Predicado3
puede traducirse a una <condición de búsqueda> en notación postf i j a :
Predicadol Predicado2 Predicado3 and or
Un <predicado> puede compararse con una expresión relaciona1 la cual evalúa una condición que puede tomar dos valores de verdad: "verdadero" y "falso". A diferencia de ésta, los <predicado>s pueden evaluar una condición a tres valores de verdad ( 3.3.2.4.3.3.2.1 ) . Aparte de los valores de "falso" y "verdadero", un <predicado> puede producir un valor de verdad de "desconocido'.
Para manejar estos tres valores de verdad, se utiliza una pila booleana PB cuyos elementos tienen la siguiente estructura:
ValoresDeVerdad = (Verdadero, Falso, Desconocido); Type
ApNodoPilaBoolena =^NodoPilaBooleana;
NodoPilaBooleana = record
end ;
La forma de traducir y evaluar un <predicado> depende del tipo de predicado que se tenga. A continuación se describe la forma de
Valorverdad : ValoresDeVerdad; S igNodo : ApNodoPilaBooleana;
94
traducir y evaluar un <predicado de comparación>. Los demás predicados pueden traducirce en forma similar.
4.4.1 El predicado de comparaci6n
Como se explicó en 3.3.2.4.3.3.2.1 un <predicado de comparación> tiene dos formas:
1) El top. de comparación> E2
donde
El y E2 son expresiones escalares y <op. de comparación> es un operador de comparación ( =, >, <, >=, <= o <>).
2) El top. de comparación> <subconsulta>.
donde el resultado de efectuar la <subconsulta>, en este caso, debe regresar una tabla de grado 1 y cardinalidad 1.
4.4.1.1 Predicado de comparación de la forma El <op. de comparación> E2
Para traducir un predicado de esta primera forma se realiza lo
a) La <expresión escalar> El se traduce a una expresión en notación postfija EP. Esta expresión EP se maneja como una lista ligada LL, igual que en 4.2.
b) El top. de comparación> se incorpora a la lista ligada LL. Esto requiere aumentar el tipo de <primario> para cada nodo de LL .
c) La <expresión escalar> E2 se traduce a una expresión en notación postfija EP. Esta expresión EP se adiciona a la lista ligada LL.
d) Al principio de la lista ligada LL se adiciona otro nodo. Este nodo tiene como tipo <primario>, el valor de "pred. comp. forma 1".
siguiente:
Supóngase por ejemplo que se tiene el siguiente predicado de
(3) Status * 2 = 100
comparación en una condición de búsqueda:
9 5
La información (parte) de los nodos de la lista ligada LL que contiene la expresión ( 3 ) en notación postfija es la siguiente:
Para evaluar un predicado de comparación de esta forma, se toma el primer elemento de la lista ligada LL y se determina de qué tipo de nodo se trata. En este caso, el nodo tiene indicado que se trata de un predicado de comparación de la forma 1. Est0 significa que el resto de LL se va a tratar de la siguiente manera:
a) Evaluar la expresión El (como se indicó en 4 . 3 ) . Esto se hace recorriendo la lista hasta que el tipo de nodo sea un operador de comparación.
b) El resultado de El se guarda en una variable v1 del tipo TNodoPila ( 4 . 3 ) .
c) Guardar el operador de comparación en una variable Top que es de tipo Tipooperador ( =, >, <, >=, <=, <>) y pasar al siguiente nodo de LL.
d) Evaluar la expresión E2 (como se indicó en 4 . 3 ) . Esto se hace recorriendo la lista hasta que el tipo de nodo sea un indicador de fin de expresión escalar (este tipo de nodo se adiciona al final de E2).
e) El resultado de E2 se guarda en una variable V2 del tipo
f) Se efectúa la comparación de V1 y V2 conforme a las regias establecidas en 3 . 3 . 2 . 4 . 3 . 3 . 2 . 1 . El tipo de comparación que se realiza depende de la variable TOP.
g) El resultado del inciso f ) se guarda en una variable tiPo NodoPilaBooleana ( 4 . 2 ) .
i TNodoPila ( 4 . 3 ) .
96
4.4.1.2 predicado de comparación de la forma El <op. de comparación> <subconsulta>
Para traducir un predicado de esta segunda forma se realiza 10
a) La <expresión escalar, El se traduce a una expresión en notación postfija EP. Esta expresión EP se maneja como una lista ligada LL, igual que en el inciso a) de 4.4.1.1.
b) El top. de compración> se incorpora a la lista ligada LL, igual que en el inciso b) de 4.4.1.1.
C) Al principio de la lista ligada LL se adiciona otro nodo. Este nodo tiene como tipo <primario>, el valor de "pred. comp. forma 2".
siguiente:
Para evaluar un predicado de comparación de esta forma, se toma el primer elemento de la lista ligada LL y se determina de qué tipo de nodo se trata. En este caso, el nodo tiene indicado que se trata de un predicado de comparaci6n de la forma 2. Esto significa que el resto de LL se va a tratar de la siguiente manera:
a) Verificar que el resultado de la <subconsulta> sea una tabla de grado y cardinalidad igual a uno (3.3.2.4.3.3.2.1). Si ésto no es verdadero entonces el resultado de la <subconsulta> es el valor nulo. El valor de la subconsulta (que puede ser el valor nulo o un valor no nulo) se guarda en una variable v2 del tipo TNodoPila.
b) Evaluar la expresi6n El (como se indicó en 4.3). Esto se hace recorriendo la lista hasta que el tipo de nodo sea un operador de comparación.
b) El resultado de El se guarda en una variable vi del tipo TNodoPila (4.3).
c ) Guardar el operador de comparación en una variable Top que es de tipo Tipooperador ( =, >, <, >=, <=, <>) y pasar al siguiente nodo de LL.
d) Se efectúa la comparación de V1 y V2 conforme a las reglas establecidas en 3.3.2.4.3.3.2.1. El tipo de comparación que se realiza depende de la variable Top.
e) El resultado del inciso d) se guarda en una variable tipo NodoPilaBooleana (4.2).
97
4 . 5 Evaluación d e una.condic i6n d e Msqueda
Para eva lua r una condición d e búsqueda se e fec túa l o s i g u i e n t e :
1 ) Una <condición de búsqueda> CB se t raduce a una <condición d e búsqueda> en notación p o s t f i j a CBP ( 4 . 4 ) . Los elementos d e una tcondic ión de búsqueda> son <predicado>s y <op. 16gico>s . si una <condición d e búsqueda> t i e n e un s o l o <predicado>, éste se r ep re sen t a mediante una l i s t a l i g a d a LL ( i g u a l que en 4 . 4 ) . si hubiera algún top. l óg i co> u o t ro predicado en CBP, é s t o s se adic ionan a l a l i s t a LL.
2 ) Para eva lua r CBP, se recorren l o s elementos de l a l i s t a LL. Cuando se t r a t e d e un <predicado>, éste se evalúa (como en 4 , 4 ) y e l r e s u l t a d o se depos i ta en una p i l a booleana PB ( 4 . 4 ) . Cuando se t r a t e de un <operador l óg i co> AND y OR, se ex t raen l o s dos elementos en e l tope d e l a p i l a PB y se les a p l i c a e l <operador l óg i co> d e acuerdo a l a s r e g l a s e s t a b l e c i d a s en 3 . 3 . 2 . 4 . 3 . 3 . 2 . 1 y e l r e su l t ado se depos i t a nuevamente en PB; si el <operador l óg i co> es NOT, entonces éste se a p l i c a sobre e l elemento en e l tope de PB.
3 ) E l r e s u l t a d o f i n a l de CBP se encuentra en e l único elemento de PB .
d. 6 Traducción y evaluaci6n de una <espec i f i cac ión d e consu l ta>
Con l a forma e s t a b l e c i d a para t r a d u c i r y eva luar una <expres ión e s c a l a r > y una tcondic ión de búsqueda>, se puede e s t a b l e c e r l a forma de manejar e l código generado para una <espec i f i cac ión de consu l t a> .
Como se e s t a b l e c i ó en 3 . 3 . 2 . 4 . 3 . 5 para una <espec i f i cac ión d e consu l t a> d e l a forma:
SELECT 1 FROM 1 WERE 1
(SELECT 2 FROM 2 WHERE 2
(SELECT N FROM N WHERE NI); ,
98
J el precompilador debe producir una salida de la forma:
FROM. N WHERE N *I
SELECT N FROM 2 WHERE 2 . SELECT 2 FROM 1 WHERE 1 SELECT 1.
J LO anterior significa que el orden de los elementos de una
<especificación de consulta> debe invertirse (de acuerdo al orden de definición) para poder ser resuelta. Esto puede resolverse utilizando una nueva pila de estatutos (la cual dominaremos PE) . La <especificación de consulta> se resuelve entonces al ir sacando cada elemento de la pila de estatutos PE y ejecutarlo. El primer elemento (estatuto) en una <especificación de consulta> original es el primer elemento que se coloca en PE y as1 se convierte en el último elemento a ejecutarse.
La estructura para manejar PE es la siguiente:
Type TEstatutos = (E Insert, E From, E-Where, E SeiectConsuita,
EzSelectSub?onsulta, E-Update, E-Delete) ;
ApPilaEstatutos = ^NodoEstatuto; NodoEstatuto = record
Estatuto : TEstatutos; ApFrenteLL, ApFinaiLL : ApListaLIgadaLL; SigEstatuto : ApPiiaEstatutos;
ApTOpPE : ApPiiaEstatutos; Var ~
J Como puede observarse, un nodo de una pila PE contiene, además del tipo de estatuto, dos apuntadores a una lista lisada LL (como la de 4.5 ) . La-ej_e-cmn-deicada-es.tatuto consiste précisamente en recorrer su -lista-L&-r-e-alizando ,81 fE1-d- w i d - acciones propias de cada tipo de estatUto(-3.J.2=4-;3;-).
El código generado para una <especificacibn de consulta> consiste en llamadas a algunos procedimientos de la unidad SOL. Estos procedimientos consisten en colocar en la pila de estatutos PE cada elemento de la tespecificación de consulta> as1 como los
99
elementos de cada lista ligada LL.
llamadas a la unidad SQL para la consulta de la Figura 3.25.
-1) Colocar en PE un elemento con valor E From.
- 3 ) Colocar en PE un elernento con valor E Where.
Por ejemplo, el pseudocodigo siguiente muestra las primeras
2) Colocar en LL un elemento tipo Element~From con un valor igual a 'SP".
4) Colocar en LL un elemento tipo Predica0 con un valor igual a "Forma 1".
5) Colocar en LL un elemento tipo Columna con los siguientes valores : TipoDato = Cadena, LongCoi = 6, DespiazCol = 7, etcétera.
igual a "= I * . -
valores : TipoDato : Cadena, valor : 'Pl'.
" 8 ) Colocar en PE un elemento con valor ESelectSubconsulta.
valores : TipoDato = Cadena, LongCoi = 6, DespiazCoi = 1, etcétera.
6) Colocar en LL un elemento tipo OperRelacional con un valor
7) Colocar en LL un elemento tipo Literal con los siguientes
9 ) Colocar en LL un elemento tipo Columna con los siguienets
'10) Colocar en PE un elemento con valor EWhere.
17) Llamar al procedimiento EjecutaSQL.
El procedimiento EjecutaSQL tiene como funcidn ir sacando los elemento de PE y de acuerdo al valor de cada uno, llamar a la rutina correspondiente para ejecutar el estatuto correspondiente. El c6digo de esta rutina consiste en lo siguiente:
While ApTopPE (> Nil do begin Case ApTopPE.Estatut0 Of E From : EjecutaFrom; EzWhere : EjecutaWhere;
E-SelectSubconsulta : EjecutaSelSubconsulta
.. .. end; (case) ApTopPE := ApTopPE^.SigEstatuto
end; (while)
100
. .~ . . . .
PRUEBAS AL PRECWPIlllMlR DEL LMD *.
. .
En este capítulo se presentan las pruebas realizadas ai precompil,ador del lenguaje de manipulación de datos desarrollado en este proyecp. Las pruebas consistieron en ejecutar una serie de programas en Pascal con estatutos de SQL intercalados y verificar que el resultado de cada ejecución fuera equivalente a la semántica de las proposiciones en el programa fuente. Las pruebas se realizaron sobre la .BDD descrita en 3.1. El número de pruebas (programas) efectuadas al precompilador fue de aproximadamente 125, tratando de abarcar todos los puntos sintácticos de la gramática de SQL soportada por el precompilador (Anexo A). Por cuestiones de espacio se presentan en este capítulo sólo aquellas pruebas que se consideran más representativas.
5.1 Objetivos de las pruebas
principalmente los siguientes: Los objetivos de las pruebas al precompilador son
1) Verificar que las acciones semánticas efectuadas por el programa que resulta de la precompilación, sean equivalentes a los estatutos del lenguaje SQL intercalado en el lenguaje anfitrión.
2 ) verificar que los programas ejecutables cumplan con la transparencia de localización.
Para lograr el punto I), se implement6 una serie de programas fuentes en Turbo Pascal y SQL. Cada programa corresponde a un ejercicio del capítulo 6 de la referencia [32]. Se seleccionaron aquellos ejercicios que contemplaran el uso de los estatutos más representativos de SQL. Para cada programa fuente se efectuó el proceso de precompilación y los programas resultantes se compilaron con el compilador de nirbo Pascal para producir programas
ejecutables. Los resultados obtenidos de cada programa ejecutable se verificaron contra los resultados de los ejercicios mencionados, los cuales aparecen en la referencia citada.
Para lograr el punto 2) se verificó que los estatutos de SQL utilizados en los programas de entrada. no especificaran el nodo o los nodos donde se encontraban las tablas involucradas en cada programa con excepción del estatuto CREATE TABLE, ya m e este estatuto requiere especificar el nodo donde se desea crear la tabla.
5.2 Condiciones de las pruebas
Las pruebas se efectuaron en la base de datos distribuida descrita en 3.1. Las tablas sobre las que se operaron en los programas de prueba, son las que aparecen en la Figura 3.0. Para los programas orientados a las operaciones de selection, los resultados se desplegaron por pantalla y por impresora.
5.3 Presentation de las pruebas
A continuación se presentan los listados de los programas fuentes en Pascal y SQL correspondientes a las pruebas junto Con
ados obtenidos por impresora cuando sea el caso.
102
x
1 (----- 2 3
~ t u b a m. 1. para el PrecaglladBr de SPL. objetlvo : Crear fisicawnte las tablas S. P. SP an los mdDs
4 5 Fecha : 4 de dlcl-e dü 1991. 6 Autor : Victor I$wl Arellano M~Es. 7- 1 8 9 @in
10 $Create Table S ( 11 Slb char(5) Not )lull Primry KEY, 12 Snaie char(Al), 13 Status SRiaIllnt, 14 Ci ty char(7.U) ) in 'AlfaUlfa-c'; 15 16 $Create Table P( 17 PNo char@) ibt iQI1 Primry Key. 18 Pnaie char(20), 19 Color char(Ñ), 20 WEl$lt DBClMl, 21 Ci ty char('M) ) in 'üetaQ8ta-c'; n 23 $Create Table SP( 24 SNo char(5) Not Hill. 25 P N ~ m r ( 5 ) Not MI, 26 P i y lntsgsr) 1 in '6anal6ania-c'; 21 28 end.
ALFA, BETA Y GAYA resgeCtivaiSnte. '
103
TES12.EP mUrsday. 4r i i 30, 1992 7:n
~ ~~~~ . . 2 3 4 5 Fecha : 4 de diciepbre de 1991. 6 Autor : Victor ~~inue i Areiiarh h t e s . 7 --.A-.- .. . 8 usessql; 9
10 t begin declare section 11 IEm : Strlng i31; 12 USHaile : String í201; 13 vstatm: Integer; 14 Wity : String[íUl; 15 end declare sectlm; 16 17 Var 18 F : text; 19 begin 20 Assign(F.'Prov.dat'); 21 reset(F); n 23 readIn(F.VSno); 24 readln(F,üSNm); 25 readln(F,üStatls); 26 readin(F,UCity);
HD. 2. para el ~ecaoiiadoi~de SOL:. m j e t i w : insertar IOS valores de los rwim la . ih ia S.: t.
LOS datos se iem del ardi lw IB texto Pr&.dat I
. ,
1 : . . . . .
nhi le not &(F) do begin
27 readln(F); 28 writein(üSn:5. üSNam:lO. üStatus:5. LCity:lO);
104
'pROV.oAT
1 Sl 2 smith 3 2 0 4 London 5 6 s2 7Jones 8 10 9 Paris 10 1 1 s3 12 Blake 13 30 14 Paris 1s 16 s4 17 Clark 18 20 19 L(n6ñi
21 s5 22 Adam 23 30 24 Athens
m
.e , . . . .. . . . .~ . .. . . . .
. ,.". ,
105
I)
2 3 4 Los datos se leen del ardi lw ds texto psrtea.dat 5 Fecha : 4 de dlcIBibre de 1991. 8 Autor : Victor hum1 Areilam h t m . 7 1 8 us86691; 9
10 S begin declare sactlm 11 URiO : Strlng [31; 12 uptlsie : String [m]; 13 UCDlor : String [201: 14 weight: Real; 15 UClty : Strlng[P]; 16 end declare &Ion; 17 18 var 19 F : text; m begin
22 reset(f); 23
25 readln(F.LP)(aae); 73 readln(F.UColor); 27 readln(F.Might); 28 readln(F.lCity); 23 readln(F); 30 31 32 $Insert IMOP 33 34 35 nitein('SP1WOE .I ', SQLCOOE); 36 Bnd; 37 ciose(F); 38 erd.
Pnieba U. 3. cara el PrecogIlacbr de 9pL. Cbletlvo : l m r t a r los valorea de los rwlm de la tabla P.
21 Ass Igi(F. 'prteb .dat ');
i h l l e rot eof(F) do begin 24 readln(F.LRio);
rritein(URio:S. Wiiam:iü. ü%lor:lO. uleifl:8:2. UC1ty:lO);
valtiea (:wib. :iWm. : O l o r . : W i @ t , :uClty);
106
PWITES.DAT
1 Pl 2m 3 Red 4 12 5 London 6 7 P2 8 Bolt 9 G r m 10 17 11 Paris 12 13 p3 14 $crerc 15 BlUe 16 17 17 R o l e 18 19 D4 20 Screw 21 Red 22 14 23 L a m l 24 25 p5 26 Can 27 BlUe 28 12 29 Paris 30 31 p6
33 Red 34 19 35 Laimn
32 coe
, !. . .
107
TEsT4.EP Thursday. Ipril 30. 1992 7:28 p
1 {----.------- -I
2 3 4 5 Fecha : 4 de dicieiabre de 1991. 6 Autor : Victor UimeI Atellara yntes. 7 IP-.IIC.P-ll------ ----) 8 USSWi; 9 10 S begin declare SSctIon 11 Usno : String 131; 12 upna : Strlng [31; 13 UMy : Intsger; 14 end declare saction; Id 18 Var 17 F : text; 18 begln 19 Asslgn(F.’Sp.Dat’); M reset(F); 21 22 readln(F,UPw); 23 readln(F,Iho); 24 readln(F.WtY); 25 readln(F); 26 writein(ü%o:5. W : 5 , U P ~ Y : ~ ) ; 27 28 $insert into SP 29 vaiw (:ucNo. :UPNO, :U)tY); 30 31 rirltein(’SüLMaE = ’, SPLCOOE); 32 end; 33 c l m ( F ) ; 24 end.
Pnieba No. 4. para el Precmpilador de SPL w r s i m 2 mjetivo : insertar los valores de los renglones de la tabla P.
Los datos se iem del archivo de datos $.Dat.
mi le not eof(F) do begin
100
:sP.DAT
1 s1 2 PI 3 3 0 0 4 5 s1 6 ~2 7 2 0 0 8 9 S l
10 p3 11 400 12 13 S l 14 p4 15 200 16 17 s l 18 p5 19 im 20 21 S l 22 P6
24 25 s2 26 Pl 27 300 28 29 s2 30 P2 31 400 32 33 s3 34 p2 35 m 36 37 s4 38 P2 39200 40 41 84 42 P4 43 300 U 45 s4 48 P5 47 4ca
23 io0
mrsday. &ll 30, 1992 7:37 P
109
i
TEST5.EP
1 2 3 4 5 6 7 8 9 10 1 1 12 13 14 15 18 17 18 19
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42
m
Thursday, Mrll 30, 1(En 7:28 p
(----a------
Pruaba No. 5 para e l P r m l l a d o r de %. CbJEtiM : Cbtener ios maros de partes para todas las partes
Refermla: Ejerclclo 6.2.1.b del libro: sriiinistradas, ellilnando drpllcados.
‘A introdicticn to Gatabase Systw’ Vol. 1. C.J. Date.
Fecha Autor
: 4 de dlclefbre de 1991. : VlctW uanusl AmIIsn, yontes.
1 ._p_-_--pp_--__--
uses sql, prlnter;
$ begln declare sectlon
wd declare ssctim; UPNo : Strirg [31;
begin $ tiaclare Cursor TestCi i r for
select dlst lnct Ftb frm sp;
t(pen TestCur;
nritein(’i?esuitado de la ~Neba m r o 5:’); nriteln(1st); nritein(ist); writeln(ist); nrlteln(lst); mite ln( lst) ; wrlteln(lst.’ writein; nriteln(1st); rapeat
Resulta& de la prueba m r o 5:’);
$fetch TestCur into :wm;
If SQLWOE - O then begin i r i te In(lF”0: 15); i r itein( ist.WNo:l5) ;
end;
uit I I S Q C O O E ~ O ;
tcim TBStCur; end.
Resultado de la prueba numero 5:
111
.., 1:. .. . I
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
' 27 28 29 30 31 32 33 34 35 38 31 38 39 40 41 42 43 44 45 48 41 48
(--- - Prueba lb. 6 para el PrecoiplladDr de SU. mjetiw : Cbtwr los detalles aw~ le tos ds taks los prwee6Jres. Refermcla: Ejsrclclo 6.2.3 del I ibro:
'A Introtkt ion t o Oatabase Susten' Vol. 1. C.J. Date.
~edia : 4 de dlcleibre de 1991. : victw yanusl wellam mes. AutDT
usss al. printer;
S begin declare mction u9io : Rrirg [31; USNaie : Rrirg 1201; IrdHam : Integer; Ustatus : Integer; indstatus : Integer; UClty : String[MI; IndClty : Integer;
end deciare Ssct ion;
bee in $ Oaclare Cursor Testcur for
select ' fnN s;
SQm TestCur;
wrlteln('ResultadD de la prueba m r o 6:'); writein(1st); witein( ist): ririteln(1st); wrlteln(lst); ini teln(lst); wr i te in( 1st.' i r i te ln ; r i t e l n ( i s t ) ; repsat
ResuitadD de l a prueba tnmro 6 : ' ) ;
Sfetch Testa0 Into
i f snmE - o then begin
:USNO. :~)$iie: Inrnem. :Unatus: Instatus. :UCity: IrdCity:
wr I te(USho:5); write( ist,USm:15); i f ind(aie o then begin
write('<dll lb>' 5); rrlte( 1st. '-iML>>':15) end else begin
end; if indstatus o then begin
end
i r ite(usiiam:lO); i r ¡te( 1st .ucNails: 10):
irite('.dULL>>' :IO); w i I te( i s t . ' 4 U L L ~ > ' :lo) 112
11.3
I , 4 '
I Resultado de la Prueba nunier
?I., Smith 20 va ;z: I.
s3 Blake 30 Paris , ,.
s5 Adanis 30 Athens .: .
.- ,I'
. . s2 Jones 10 Par i s
84 Clark 20 London .. ,. :.
i ! <* , .. . ;+i :
114
- 1 ( 2 3 4 5 6 7 8 9 C.J. Date.
Pnisba No. 7 para el Prmmllador de SU. objetivo : mtener la I n f omc im de todas las mbinaclms~ de
paries y provsadwes tal we el p r d r y parte en amstim esten locallzadm en la nlma ciudad pero aitiaido provBBdDres am status a).
-A Introdictlon to Oatabase Spta' Vol. 1. RefwmcIa: EJerclclo 6.3.3 del I ibro:
i o F- : 4 de d ic lame de 1991. 11 Autor : Vlctor Manuel Arellano umtes. 12 - ----=I 13 uses sui, printer; 14 15 t win declare sactlm 16 u9io : String C31; 17 LLsHaae : String 1201; 18 UStatls : integer; 19 USCity : Strlng[201; 20 LIRio : Strlng 131; 21 Waw : String 1201; 22 UColor : String 1203; 23 u#Bl@t : Real; 24 LB>Clty : String[20]; 25 end declare sect im; 26 27 begin
t Declare airsor Testa i r for 28 29 30 31 32 33 34 35 38 31 38 39 40 41 42 43 44 45 46 47
select fra S.P -re S.Clty - P.Clty and S.Statu8 o 20;
scorn Testcur;
wrltein('ñesulta63 de in prueba fuero 7:'); i r i te in( ist) ; wrlteln(Ist): writeln(i6t); writein(ist): wrlteln(Ist): wr itein(ist.' writeln; wr I teln(lst); repeat
Resultado de la pnieba w r a 7:');
Sfetch Testair Into :osPo. :usNam. $Status. : W i t y , :IRio, :Wane. :UCoior. :Wei$d, :U'Clty:
i f SPLCDDE - O then begin writeln(üSm:4. uSNam:lO. UStatus:5. USClty:8. m:4. ü"am:8. UCol0r:B. u#Bi@t:7:2. UPClty:8)
115
116
Resultado de l a prueba'numero 7:
s2 Jones 10 Parls p2 Bolt Green 17.00 Parls 92 Jones 10 Parls p5 Cam Blue 12.00 Par16 s3 Blake 30 Parls p2 Bolt Green 17.00 Parls 93 Blake 30 Paris p5 Cam Blue 12.00 Paris
117
. r
TEST8.EP Thursday. bprii 30. 1992 7:íü p mge 1
- - 1 (--- __P__-_-m
2 Pnisba tb. 8 para el PrecDapilador de SU. 3 objetivo : Caterer t e Im pares de -res de ciujades ta l 4 5 6 7 8 C.J. Date. 9 ~ebia : 4 de dicleabre de iw. IO Autor : Vlctw MWJEI Arellarm mes. 11 -- - ---."-) 12 USBC sql. prlnter; 13 14 t begin declare rat ion 15 USCitY. 16 UPCity : String [201; 17 erd declare ssctim: 18 19 begin 20 t Declare airw Testar for 21 select distinct S.Clty, P.City -22 frm S.9.P 23 where S.W .I SP.W 24 and SP.PN0-P.PN0; 25 28 #psnTestCw; 27 28 29 ariteln(lst,' Resultam de la prueba m e r o 8:'); 30 ariteln; 31 wr I teln( 1st); 32 repsat 33 34 sfetch Testa i r Into 35 :LGClty. : m i t y ;
37 38 39 writein(ist,USCity:19, UPCity:W; 40 end: 41 42 i n t i 1 S9luwEOO; 43 44 SClDseTestW; 45 end.
we el Prov. situado 81 la w l w a ciudad sll l lnistre VUI parte almamda 81 la segrda ciudad.
'A Introdict lm to Database Systea' Vol. 1. ReferaICIa: Ejerclclo 6.3.5 del i ibro:
writein('Resulta& de la prueba m e r o 8:'); writeln(lst); writein(ist): writein(ist); wrlteln(lst); wr i te ln (W;
38 if SULWDE - o then begin
wr 1 tein(UCCi ty :lo. UPCity:lO);
118
Resultado de la prueba hume.ro 8 :
London London London
P a r l s Par Is
London Par I s Ame
London Par Is
119
TEST9.EP
P-- - 1 (- 2 3 4 la parte p2. 5 Refermla: Ejercicio 6.4.4 del libro: 6 7 C.J. Date. 8 ~ e ~ h a : 4 de diclwre de 1991. 9 Autor : VlCtW Yarasl Arellano Ibntss.
10 - ~ m , , . , - - - - ~ - = = = - - ~ = m ~ . = - - . m )
11 uses sul. printer; 12 13 $ begin declare sectlm 14 Total : Integer; 15 erd declare sxtim; 16 17 begin 18 t Select SIEKqtY) 19 into :Total 20 frm SP 21 -re pno - 'P2'; 22 23 24 25 nritein(ist. ' Resultado de la prueba m r o 9:'); 26 writeln; 27 nrIteln(1st); 28 29 30 i r lteln(1ota I); 31 *riteln(lst,Total:17); 32 end; 33 end.
Pnieba No. 9 para el Precopllador de SU. Objetivo : Obtmer la cantidad total suministrada de
'A 1ntr-t ion to Databasa Systes' Vol. 1.
writeln('iiesuita6J de la pru& m r o 9:'); writeln( 1st); writein( 1st); writeln(lst); writein( 1st); wr iteln( 1st);
i f S P L C ~ E = O then begin
120
Resultado de la Bruebe numero e: 2000
121
il
lEsTlO.0)
1 2 3 4 5 6 7 8 9
10 11 12 13 14 15 16 17 18 19 20 21 n 23 24 25 28 27 20 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
PNeba No. 10 para el Precoapilador de SPL. Dbjetlvo : mtensr todas las partes aiyo r a b r e miwa m la
letra C.
Refermcla: EJerclcio 6.5.1 del IIbro: 'A Introdictlon to Oatabase Systm' Vol. 1. C.J. üate.
Fedui M o r
: 4 de dlclepbre de 1991. : Victor Manuel Arel lam mes.
--------------------------I use6 sqi, prlnter;
t bagln Calare sactlm LIRio : String 131; uwaie : Strlng 1201; m l o r : String [Ñ?;
UPClty : String[ZOl; might : Real;
end Calare sectim;
begin $ Declare airsor TestQv for
select ' fra P -re FWm I Ike ' C X ;
topa, Testcur;
writeln('Resultado de la prueba m e r o 10:'); writein(ist); wrlteln(ist); wrlteln(lst); writeln(1st); w r i t e l n ( W ; writein( 1st.' wr I te In; wr iteln( 1st); reQeat
m i t a d o de la pnisba m r o 10:');
sfetch Testcur into :m, :~p~aie. : m i o r . :Usei@t. :LPCity;
If SPLWDE - O tha w i n writeln(LRo:4. Lp#aaa:iO. ~ 1 w : l O . UlleigM:ü:Z, UFC1ty:lO); nrlteln(lst.m:15. upHaie:lO. UCo1or:lO. wisign:8:2. LPCity:lO);
46 47 $ c l < s e T e s t ~ ; 48 end.
122
Resultado de l a prueba numero 10:
P5 Cam Blue 12.00 Par IS P6 cog Red 19.00 London
1 '1
123
TEST11 .EP Ti-ursday, brli 30. 1992 7:28 P
1 2 3 4 5 6 7 8 9
10 11 12 13 14 15 16 17 18 19
21 22 23 24 25 26 21 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
m
Pnisba No. 11 B r a e1 Precrrpllador de S U . übjetlvo : mtmer 10s &res de proveadores para p r o m
w siainlstran a l mas ma parte roja.
Refermcla: EJercicio 6.5.4 del libro: 'A Introdict Ion to Databass Suster' Vol. 1. C.J. Date.
Fecha Autor
: 4 de dlclsiabre de 1991. : Vlctw Yanel Arellano Yntes. --------..-..----)
mes sgl. printer;
S begin declare section
end declare section; us~anie : Stririg [mi;
begin $ h l a r e (2irsor TestCur for
select SNaaie froia S &re SNo in
( sslect gn frm cp -re pi0 In ( select pi0
frw P rhere color - 'Red'));
$@m Testair;
nriteln('llesu1tado de la prusba m e r o 11:'); writeln(1st); wrlteln(Ist); wrlteln(lst); wrltein(1st); rnlteln(lst); wrIteln(1st.' wr Iteln; n l te in ( l s t ) ;
reDsat
m i t a d o de la prusba r u m 0 11:');
sfetch TestRa Into :uswaie;
if SPLMDE - o then twin wr I te ln(UCHss8: 10) ; wr I te in( 1st ,USWm: 18);
end;
124
TEsTl1.W
49 50 tc loseTes t~: 51 52 end.
125
Pa@ 2
Resultado de la prueba numero 11:
Smith Jones Clark
126
IE812.EQ miraday. lor11 30. la82 7 2 1 ) P
- 1 ( 2 a m j a h : mtensr los rad!res de proveedpres wa Pm. 4
8
P W Ib. 12 para e l Recoqllador de SPL.
an UI valor de status mmr gie e l statur wlm
'A Introdictlm to Databarn WteV Mi. 1. 5
7 C.J. Date. 8 F e : 4 de dlcleibre de 1991.
Rfere i~ la : Ljerclclo 8.5.6 dsl Ilbro:
9 Autor : V i c t o r YMiSl Arellm yntes. 10 -1 11 691. prlnter; 12 13 $begin declare sectlm 14 W : String [nl; 15 aid declare mlm, 18 17 begin 18 19 wiact snais 20 f rn s 21 d r e status< 22 ( mlact iax(statu9 23 frol s); 24 25 t(penTestRir; 28 27 28 29 nrlteln(lst.' Resultado de la pNeba wero 12:'); 30 r l t e l n ; 31 r l t e I n ( l s t ) ; 32 33 repeat 34 $fetchTestair Into 35 :uswaie; 38 37 If SPLCmE - O then begln 38 39 i r I teln( Ist.USMam:lü); 4a aid; 41 rntll SILWX-O; 42 43 ScloSeTsstorr; 44 end.
$ Declare Curscf Testcur for
nrlteln('Resultado de la prueba m r o 12:'); nrlteln( 1st); r l t e l n ( 1st); nrlteln( 1st); i r i teIn(Ist) ; i r Iteln( 1st):
i r I te In(USNam :lo);
127
Resultado da l a prueba numero 12:
Smith Jones Clark
i2e
iEST13.W mursday. Lprll 30. 1992 7:28 P
1 ( 2 3 4 para el proveedor 55. 5 6 7 C.J. Date. 8 ~ebia : 4 de dicienbre de 1991. 9 Autor : Victw üaml Areiim mea.
10 .C....II--PIIDI--- e.=.-- I 11 119Bs sal; 12 13 tmgin 14 t update S 15 set Statis - Hill 16 irhsre sw - ' ~ 5 ' ; 17 18 iiriteln('SPLCODE = '. SQLWa); 19 end.
Prueba M. 13 para el PrecaOllaáor de SQL. übjetivo : En la labia S. coiccnr el valor HLL en la colwm STATUS
Referencia: Ejerclcio 6.5.2.a del libro: *A Introdict iM to Databa= Spteii' Vol . 1.
129
TEST14.V lhursday, &fll %l. 1992 7:a pm
I ( - 2 3 4 5 8 r C.J. Date.
9 Autor : Victor Yanral Arellam antes.
PW No. 14 pnra el Precaplladw de Sn. objetivo : obtener los mero6 de prwee6Jres cara prow. em dade
Refemcia: EJerclc:o 6.5.2.b del libro: la ualtmm status tw el valor rulo.
"A Introdrction to Databasa Systm' Vol. 1.
8 Fectia : 4 de d1cled)re de 1991.
.- 11 1ffb8 sal, printer; 12 13 t begin declare sactlon 14 Usno : Strifg C31; 15 end declare section;
17 begin 18 19 select ho 20 f ra S 21 *re Status is cull; 22 23 tqienTBstQK; 24 25 28 27 writeIn(lst,' Resuitado de la Drueh m r o 14:'); 28 nritein; nrrcteln(lst); 29 30 r m t 31 32 sfetch Testcur into 33 :USNO; 34 35 if SMCCOE - O then begin 36 nriteln(llCm:5); 31 nrlteln( Ist.UCm:l5); , 38 end; 39 40 inti1 SíILCUX-0; 41 42 SClCmreTBSt~; 43 end.
16
t Declare Cursor TestWr for
nriteln('Resuitado de la pnieba m r o 14:'): nrlteln( 1st); writsin( 1st) ; writsin( 1st); wrlteln( 1st); wrlteln( 1st);
130
Resultado de la prueba numero 14:
s5
131
lEST15.EP mursday, b r l I 30. 1992 7 : B P
2 Prueba No. 15 para e l PreCOgllador de SUL. 3 übjetlw : @arar el prowedor s l . 4 Referala: Ejerclclo 6.6.5 del I lbro: 5 6 C.J. Date. 7 Fecha : 4 de dlcletbre da 1991. 8 Autor : Vlctoc Yanusl Arellano kmtes. 9 ----------------=-,.--)
10 LLSBS sal; 11 12 begin 13 t Delete 14 frcm s 15 *re 6m - 's i ' ; I6 17 wrlteln('SPLCODE - '.Sam); 18 end.
'A Introdict Ion to Database Wtw' Vol. 1.
132
TESi6.EP mursday, npril 30. 1992 8:s P
1 [---- ------ 2 3 4 Referencia: Ejercicio 6.2.3 del i ibro: 5 6 C.J. Date.
8 Autor : Victor M a m i Arellano wont=. g -------------.------------------.)
10 USBS mi. printer; 11 12 t begin dsciare saction 13 U S i O : String [31; 14 USNasre : String [al; 15 IndNam : Integsr; 16 M a t u s : integsr; 17 IrdStatuC : integer; 18 E i t y : StringCMI; 19 IrdClty : Integer; 20 Bnd deciare sactim; 21 22 begin 23 24 select * 25 from S; 26 27 $Exkm Testüx; 28 29 30 31 writein(ist.' Resultado de l a pnieba m r o 6:'); 32 writein; mlteln(lst); 33 repeat 34 35 t fetd, Testair into 36 :Et&. :&aNanxc: IrdaNam, :&tatus: IMtatus. :E i ty : IndCity; 37 38 39 40 41 42 m 43 else begin 44 wr ite(&Ham:lO); irrite( ist.USHame:lO); 45 end; 46 47
PNeba No. 6 para el Premgiiador de SPC. Objetiv~ : (btener los detalles coqletos de todos los prwBBdorBc.
'A introdict ion t o Database System' Vol. 1 .
7 Feda : 4 de diciepbre de 1991.
t Deciare Cursor TestCur for
writein('Resu1tado de la prueba m e r o 6:'); writein(ist); writein(ist); irritein(ist); writein(ist); writeln(1st);
if SOLCDOE - O then begln wr i t e ( W : 5 ) ; write( 1st .LMc:15); If Inam < O then begin
i r ite('-".L-' :5); write( 1st. '<4(ULL>r' :15)
i f indStatus < O then begin wr Ite('<d(uLL>>' :lo); write( 1st ,'4.lLLw' : lo)
48 end 133
TEST6.EP hirsday. aprli 30. 1992 8:05 pii
49 else begin 50 51 end; 52 53 54 end 55 else begin 56 57 end 58 end; 59
61 62 SClDsE Testcur; 63 end.
Mr I te(USt3tus: 10); Mrl te( 1st ,Unatus: 10);
I f IndClty < O then begin nrlteln('<dRLL~r' :io); wr itein( 1st .'«iUll>>' :lo);
wr Iteln(lCity:lO); wr itein( ist.lCity:lO);
m ut11 S P L C O D E ~ ~ :
134
Resultado de la prueba numero 6:
82 Jones 10 Par 1s 93 B I ake 30 Par 1s 54 Clark 20 London 95 Adams <<NULL>> Athens
135
CAPITULO 6
CONCLUSIONES
La tecnologia de las bases de datos distribuidas se ha convertido en uno de los desarrollos recientes más importantes en el área del procesamiento de datos. Se estima que en los siguientes diez años los manejadores de bases de datos centralizadas se moverán hacia manejadores de bases de datos distribuidas [ 4 ] . Las bases de datos distribuidas eliminan algunos de los inconvenientes de las bases de datos centralizadas y se ajustan de forma más natural en las estructuras descentralizadas de muchas organizaciones.
Actualmente existe un enorme interés por parte de la comunidad investigadora así como del mercado comercial en esta área. Sin embargo, a la fecha no se sabe de la liberación de un producto comercial que cumpla con todas las caracteristicas que un sistema manejador de bases de datos distribuidas debe poseer [15, 161. Esto se debe en gran parte a los numerosos problemas de carácter técnico asociados con la implementación de bases de datos distribuidas.
El desarrollo de este proyecto tuvo como propósito dar soluci6n a algunos de los problemas relacionados con BDDs con el fin de asimilar esta tecnología y estar en condiciones de ofrecerla al sector eléctrico cuando éste lo requiera.
A continuación se describen las conclusiones obtenidas en el desarrollo del presente trabajo:
a) Se desarrolló el precompilador para el lenguaje de manipulación de datos de SQL conforme a la Norma Internacional de SQL y se extendió el lenguaje SQL para que soportara el ambiente distribuido. Mediante pruebas efectuadas en una red local con tres PCs interconectadas a la red se demuestra que el c6digo generado por el precompilador es semánticamente equivalente a los estatutos de SQL. En el capitulo 6 se describen las pruebas efectuadas para cada uno de los estatutos.
136
b) Se muestra mediante la implementación física de índices que se cumple con la restricción de unicidad al insertar renglones en una tabla que ha sido definida con alguna especificación de unicidad.
c) Se resuelve el problema de l o s valores por omisión que puede tomar una columna de un rengl6n al insertarlo en una tabla. La definición del valor por omisión para un atributo se realiza al declarar una tabla en el diccionario de datos.
d) Se muestra mediante pruebas que es posible el acceso simultáneo a una tabla por varios programas (cada programa ejecutándose en una PC conectada a la red).
e) El paquete que se desarrolló funciona no sólo para una base de datos distribuida, sino tambíen, en el caso de no contar con una red de computadoras, funciona en una sola máquina como si se tuviera una base de datos centralizada.
6.1 Posibles extensiones
Este trabajo es susceptible de tener varias extensiones, describiéndose a continuación las que se consideran más importantes.
a) OPTIMIZACION DE CONSULTAS: El c6digo que genera el precompilador posee un cierto grado de optimización al momento que se desea insertar un renglón en una tabla que ha sido definida con alguna cláusula de unicidad para algunas columnas. Esto es debido a que se manejan físicamente índices del tipo "B Tree". Sin embargo, cuando se realiza una consulta ne se considera ninguna estrategia de optimización para realizar los accesos a los datos involucrados. La optimización de consultas adquiere mayor importancia en las bases de datos distribuiadas por cuestiones relacionadas con los tiempos de acceso a través de la red, cuando tablas que residen en diferentes máquinas de la red están involucradas en una consulta. una extensión a este trabajo consistiría en que el cbdigo generado considerara estrategias para optimizar las consultas al tiempo de ejecución. Podría por ejemplo utilizar los índices que se definen sobre las columnas mediante la proposición CREATE INDEX, que aunque está implementada no se toma en cuenta para las consultas.
b) INTERPRETE DE SQL : En este proyecto se tiene el lenguaje SQL intercalado con el lenguaje Pascal y aunque el proceso de precompilación es rápido, algunas veces se hace necesario por cuestiones prácticas, efectuar consultas a una base de datos de una manera interactiva o en línea, es decir, sin necesidad de escribir un programa en Pascal se desea únicamente expresar la consulta en SQL y en lugar de utilizar cursores y variables anfitrionas para ir almacenando los resultados, se visualiza el resultado directamente
137
en pantalla.
c) MANEJADOR DE '~"SACCIONES: una transacción es una unidad atómica de ejecución, es decir, es una secuencia de operaciones las cuales son realizadas en su totalidad o no se realiza ninguna. Las transacciones son el medio para obtener integridad en una base de datos debido a que aseguran la transición de un estado congruente de la BDD a otro estado también congruente. Los dos enemigos principales de las transacciones son las fallas físicas en el sistema y los accesos concurrentes. Es claro que el manejo de transacciones toma un sabor muy especiai en bases de datos distribuidas debido a que los datos se encuentran en diferentes sitios de la red y algunas veces estos sitios sufren fallas.
d) MANEJADOR DE TRANSPARENCIA DE REDUNDANCIA: Algunas veces por razones de disponibilidad para accesar datos y mejorar los tiempos de acceso y otras para que los sistemas sean tolerantes a fallas, es deseable tener cierta redundancia de datos. El problema consiste en propogar las actualizaciones de los datos a cada uno de los sitios donde se tiene una copia. Esta acción se torna complicada cuando los sitios donde se encuentran copias no se encuentran disponibles.
e) MANEJADOR DE TRANSPARENCIA DE FRAGMENTACION: Efectuar la fragmentación de una tabla, es decir, descomponer la tabla tal que diferentes partes (sea por columnas o por renglones) residan en diferentes sitios puede resultar algunas veces conveniente. Por ejemplo, en el caso de que la tabla sea demasiado grande para poder ser almacenada en el disco de una computadora o cuando por razones organizacionales conviene que cada departamento involucrado en la información de la tabla maneje sólo la parte relacionanda con ese departamento por razones de control. La fragmentación puede contribuir a mejorar los tiempos de accesos cuando los fragmentos son distribuidos correctamente en la red.
6.2 Beneficios
La existencia de redes de comunicaciones para computadoras, así como los manejadores de bases de datos distribuidas, posibilitan la integración de sistemas de información que actualmente se encuentran en máquinas aisladas. Así mismo, estas tecnologías tambikn posibilitan la extensión de capacidad de procesamiento de un sistema de cómputo más allá de los limites naturales de una s61a máquina.
Considerando la popularización que adquieren en México las redes de comunicaciones para computadoras, es previsible que en un futuro cercano, se presente la necesidad de interconectar sistemas de información aislados o de repartir un sistema de información muy grande en varias computadoras.
138
De lo anterior se desprende que los beneficiarios naturales de esta tecnología son aquellas empresas que se encuentran geográficamente distribuidas, tales como empresas F e corresponden al sector eléctrico, petrolero, bancario, etcétera.
uno de los beneficios obtenidos con esta tesis fue el haber asimilado y desarrollado parte de la tecnología de las bases de datos distribuidas en México y de esta manera se está ya en mejores condiciones más adecuadas para resolver algunos de los problemas técnicos que se presentan en los sectores antes mencionados.
Actualmente existe mucha literatura acerca de bases de datos. Sin embargo, con esta información no de puede desarrollar un SABDD porque quedan por resolver un sinnúmero de problemas eminentemente prácticos relacionados, por ejemplo, con la estructura y organización de la información, métodos de acceso, creación y mantenimiento de índices, control de acceso concurrente, etcétera. Uno de los beneficios obtenidos con esta tesis es la aportación de técnicas, procedimientos y estrategias de solución para los problemas citados anteriormente.
Otro beneficio obtenido es que se cuenta ahora con una herramienta de apoyo didáctico de mucho valor para la enseñanza de la computación, especialmente en el área de bases de datos, ya que no sólo se cuenta con el concepto de un manejador de bases de datos como una caja negra, sino que se puede ver como una caja transparente con su correspondiente código fuente.
139
---
ANEXO A
GRAMATICA DEL LENGUAJE SQL SOPORTADA POR EL PRECOMPILAWR DEL LENGUAJE DE MANIPULACION DE DATOS
Notación
La notación que se usa en la Norma de SQL es BNF ("Backus Normal Form", o "Backus Naur Form"), con la siguientes extensiones:
1) Paréntesis cuadrados ( [ I ) indican elementos opcionales.
2 ) Eiipsis (...) indican elementos que pueden ser repetidos una
3 ) Llaves (0) agrupan secuencias de elementos. o más veces.
1 Elementos comunes
<dígito>::=O 1 1 1 2 1 3 I 4 I 5 1 6 I 7 I 8 I 9
<letra>::= tletra mayúscula> I <letra minúscula>
tletra mayúscula>::= A l B I C I D I E I F I G l H l I / J I K I L'I M I N I O
l P l Q l R l S l T l U l V l W l X l Y l Z
<letra minúscula>::= a l b l c l d l e l f l g l h l i l j l k l l l m l ~ l o
~ p l q l r l s l t l u l v l w l x l y l z
2 <literal>
~uici6n:
Formato:
<literal>::= <cadena de caracteres> 1 <número> <cadena de caracteres> ::= '<representación de carácter>...'
<representación de carácter>::=
I <representación apóstrofo>
Especifica un valor no nulo.
<carácter no apóstrofo>
140
<carácter no apóstrofo>::= Es cualquier carácter diferente del carácter ( I ) .
trepresentaci6n apóstrofo>::=
<número>::= tnúmero exacto> I <número aproximado>
tnúmero exacto>::= [+ I - ] ( <entero sin signo> [.<entero sin signo>] I <entero sin signo>. I.<entero sin signo> )
<número aproximado>::= <mantisa> E <exponente>
<mantisa>::= (numero exacto>
<exponente>::= <entero con signo>
<entero con signo>::= [+I-] <entero sin signo>
<entero sin signo> ::= ,J <digito> ... 3 <token>
Función: Especifica unidades léxicas.
Formato:
<token>::= <token no delimitador> 1 ctoken delimitador> ctoken no delimitador>:=
<identificador> I <palabra reservada> I <número>
<identificador>::= <letra> [(<letra> I <dígito>) . . . I
<palabra reservada>::= ALL 1 AND I AVG I BEGIN I BETWEEN I CHAR I CLOSE I COUNT I CREATE I CURSOR I DELETE I DECIMAL 1 DISTINCT I DOUBLE I END I EXIST 1 FETCH I FLOAT 1 FOR I FROM I IN I INDICATOR I INSERT I INTEGER I INTO I IS I KEY I LIKE I MAX I MIN I NOT I NULL I NUMERIC I OPEN I PRECISION I PRIMARY I PROCEDURE 1 REAL I SECTION I SELECT I SET I SMALLINT I SMALLFLOAT I SQLCODE I SUM I TABLE I TO I UNIQUE I UPDATE I VALUES I WHERE
141
.-
<token limitador>::= <cadena de caracteres> l n l ~ l ~ l ~ l ~ l * l : l I = I + I - I / 1 <> 1 >= I <=
<separador>::= ( <espacio> I <linea nueva) )... <espacio>::= carácter blanco o carácter espacio
<linea nueva>::= carácter de fin de linea, LF o CR.
4 Nombres
Función: Especifican nombres. Formato:
<nombre de tabla>::= <identificador>
cidentificador de tabla>::= <identificador>
<nombre de columna>::= <identificador>
<nombre de cursor>::= <identificador>
5 < t i p de dato>
Funcion: Especifica un tipo de dato.
Formato:
<tipo de dato>::= CHAR [(<longitud>)]
1 NUMERIC [(<precisión> [,<escala>])] 1 DECIMAL [(<precisión> [,<escala>])] 1 INTEGER I SMALLFLOAT I FLOAT
<longitud>::= <entero sin signo>
<precisión>::= <entero sin signo>
<escala>::= <entero sin signo>
6
Aincion: Especifican uno o más valores o variables.
Formato:
<especificación de valor> y <especificaci6n objeto>
142
- -
<especificación de valor> ::= <especificación de variable>
I <literal>
<especificación objeto> : := <especificación de variable>
<especificación de variable>::= : <nombre de variable inmersa> [(variable indicadora>]
<variable indicadora>::= [INDICATOR I : ]
<nombre de variable inmesa>::=
<nombre de variable inmersa>
tidentificador de Pascal>
tidentificador de Pascal>::= Es cualquier identificador de variable válido en Pascal.
7 <especificación de columna>
Función: Referencia una columna con nombre.
Formato: ,
<especificación de columna>::=
<calificador>::= <nombre de tabla>
[<calificador>.] <nombre de columna>
8 <especificación de función de conjunto>
~unción: especifica un valor derivado por la aplicación de una
Formato:
<especificación de función de conjunto>::=
<función de conjunto> ::=
función a un argumento.
COUNT(*) I <función de conjunto>
( AVG I MAX I MIN I SUM )
9 <expresión escalar>
Función: Especifica un valor.
143
--
Formato:
<expresión escalar>::= <término>
I <expresión escalar> + <término> I <expresión escalar> - <término>
<término>::= <factor>
1 <term> * <factor> I <term> / <factor>
<factor>::= [+I-]<primario>
<primario>::= <especificación de valor>
I <especificación de columna> I <especificación de función de conjunto> I (<expresión escalar>)
10 <predicado>
Ainci6n: Especifica una condición que puede ser evaluada a un valor de verdad de "verdadero", "falso" o "desconocido".
Formato:
<predicado>: := <predicado de comparación>
I <predicado betweem I <predicado in> I cpredicado like> I <predicado null> I <predicado exist>
11 <predicado de comparación>
Función:
Formato:
cpredicado de comparación>::=
Especifica una comparación de dos valores.
<expresión escalar> cop. de comparación> [expresión escalar> I <subconsultas]
top. de comparación>::= = I <> 1 < I > I <= I >=
144
<subconsulta>::= Véase 21.
12 <predicado between>
Función:
Formato:
Especifica una comparacibn de rango.
<predicado between>::= <expresión escalar> [NOT] BETWEEN <expresión escalar> AND <expresión escalar>
13 <predicado in>
Función: Especifica una comparación cuantificada.
Formato :
<predicado in>: := <expresión escalar> [NOT] IN
<lista de valores in>::=
( <subconsulta> I (<lista de valores in>) }
<especificacl&n de valor> [, <especificación de valor>) ...
14 (predicado like>
FunciOn: Especifica una comparación de "correspondencia patrón".
Formato:
<predicado like>::= <especificación de columna> [NOT] LIKE <patrón> <patrón>:= <cadena de caracteres
15 <predicado null>
Función:
Formato:
<predicado null>::=
Especifica una prueba para un valor nulo.
<especificación de columna> IS [NOT] NULL
145
16 <predicado ex i s t>
Función: Especifica una prueba para un conjunto vacío.
Formato:
<predicado e x i s t > : = EXIST <subconsulta>
/i, <condición de búsqueda>
Función: Especifica una condición que es "verdadero", "falso" o "desconocido" dependiendo d e l resultado de apl icar operadores booleanos a condiciones especificadas.
Formato:
<condición de búsqueda>::=
<término booleano>::=
<término booleano> I <condición de búsqueda> OR <término booleano>
<factor booleano> I <término booleano> AND <factor booleano>
<factor booleano>::= [NOT] <primario booleano>
<primario booleano>::= <predicado>
/ 18 <expresión de tabla>
Funci6n: Especifica una tabla .
Formato:
<expresión de tabla>::= tcláusula from> [<cláusula where>]
J' 19 <cláusula from>
m c i ó n : Especifica una tab la derivada de una o más tablas .
Formato:
tcláusula from>::= FROM <nombre de tabla> [(,<nombre de tabla>) . . . I
146
60 <cláusula where> mción: Especifica una tabla derivada por la aplicación de *a
<condiciOn de búsqueda> al resultado de la <cláusula from> anterior.
Formato:
<cl&usula where>::= WHERE <condición de bSisqueda>
6 2 1 <subconsuite>
Función: Especifica un multiconjunto de valores definidos del
Formato: <subconsulta>::=
resultado de una <expresión de tabla>.
(SELECT [ALL I DISTINCT] <especificación de resultado> <expresión de tabla>)
tespecificación de resultado>::= <expresión escalar>
( 2 2 tespecificación de consulta>
I *
Función: Especifica una tabla derivada del resultado de una
Formato:
tespecificaci6n de consulta>::= SELECT [ALL I DISTINCT] <lista del select> <expresión de tabla>
<expresión escalar> [(,<expresión escalar>) ...I
<expresión de tabla>.
(lista del select>::=
I *
LENGUAJE DE DEE'INiCIOES DE DATOS
23 <definición de tabla>
Función: Define una tabla.
Formato:
147
tdefinición de tabla>::= CREATE TABLE <nombre de tabla>
. , I ' :. . '. ( <element [(,telemento de tabla>)...])
<e .~ <definición de columna> I <definición de restricción de tabla>
tdefinición de restricción de tabla>::= Véase 2 6 . . , I . .
24 <definición de columna>
Función:
Formato:
Define una columna de una tabla.
<definición de columna>::= <nombre $de columna> <tipo de dato> [<cláusula default>] [<restricción de columna> . . . I
NOT NULL [tespecificación de unicidad>]
Véase 2 7 .
<restricción de columna>::=
tespecificación de unicidad>::=
25 <cláusula default>
~unción: Especifica el valor por omisión para una <definición de columna>.
Formato:
<cláusula default>::= DEFAULT (<literal> I NULL)
26
Función: Especifica una restricción de integridad.
Format0 :
<definición de restricción de tabla>::=
<definición de KeStKiCCi6Xl de tabla>
<definición de restricción de unicidad>
148
27 (definición de restricción de unicidad?::=
Función:
Formato:
<definición de restricción de unicidad>::=
(<lista de columnas de unicidad>)
Especifica una restricción de unlcfdad para una tabla.
.<especificación de unicidad>
tespecificación de unicidad>::= UNIQUE I PRIMARY KEY
<lista de columnas de unicidad>::= <nombre de columna> [(,<nombre de columna>) . . . I
LENGUAJE DE MANIPULACION DE DATOS
28 <estatuto close>
Función: Cierra un cursor.
Formato:
<estatuto close>::= CLOSE tnombre de cursor>
29 <declaración de cursor> / Función: Define un cursor.
Formato:
<declaraci6n de cursor>::= DECLARE tnombre de cursor> CURSOR FOR tespecificación de consulta>
30 <estatuto delete>
Función: Borra renglones de una tabla.
Formato :
149
<es ta tu to delete>::= DELETE FROM <nombre de tabla> [WHERE <condición de búsqueda>]
31 <esta tu to fetch>
Funci6n:
Formato:
Recupera los valores sobre el. renglón que está colocado y después posiciona e l cursor a l s iguiente renglón.
<es ta tu to fetch>::= FETCH <nombre de cursor> INTO t l i s t a objeto fetch>
tespecif icación objeto> [( ,<especif icación objeto>) . . . I t l i s t a objeto fetch>: :=
32 <es ta tu to i n s e r t >
Función: Crea un nuevo renglón en una tabla.
Formato: <es ta tu to inse r t> : :=
INSERT INTO <nombre de tabla> [ ( l i s t a de columnas i n se r t> ] VALUES ( < l i s t a de valores inser t>)
< l i s t a de columnas inse r t> : := <nombre de columna> [( ,<nombre d e columna>) . . . I
< l i s t a de valores inse r t> : := <valor i n se r t> [ ( ,<va lo r i n s e r t > ) . . . I
tespecif icación de valor> I NULL <va lo r inser t>: :=
33 <esta tu to open>
Función: A b r e un cursor.
Formato:
<es ta tu to open>::= OPEN <nombre de cursor>
J 34 <esta tu to select>
Función: Recupera valores de un renglón específ ico d e una tabla.
150
Pormato:
t e s t a tu to select>::= SELECT [ALL I DISTINCT] < l i s t a select> INTO < l i s t a objeto select> <expresión de tabla>
<especificación objeto> [(,<especificación objeto>) . . . I < l i s t a objeto select>::=
35 <esta tu to update>
AUiciOn:
Formato :
<esta tu to update>::=
Actualiza renglones de una tabla.
UPDATE tnombre de tabla> SET <cláusula set> [( ,<cláusula set>) . . . I [WHERE <condición de búsqueda>]
<columna objeto> = (<expresión escalar> I NULL) <cláusula set>::=
<columna objeto>::= tnombre d e columna>
36 Elementos de un programa en Pascal con SQL inmerso
t es ta tu to d e SQL inmerso>::= <pre f i jo SQL> ( <declaración de cursor> I t e s ta tu to de SQL>) cterminador SQL>
<pre f i jo SQL>: :=$
<estatuto d e SQL>::= t e s t a tu to close>
I <esta tu to delete> I <esta tu to fetch> I <esta tu to inse r t> I t e s ta tu to open> 1 < e s t a t u t o select> I t e s ta tu to update>
cterminador SQL>::= ;
151
<sección de declaración de SQL inmerso>::= tdeclaración inicio SQL inmerso> [<definición de variable Pascal>] tdeclaración final SQL inmerso>
<prefijo SQL> BEGIN DECLARE SECTION tdeclaraci6n inicio SQL inmerso>::=
<declaración final SQL inmerso>::= END DECLARE SECTION <terminador SQL>
<definición de variable Pascal>::= cIdentificador de Pascal> [(,<identificador de Pascal)...]: tespecificaci6n de tipo Pascal>
Es cualquier identificador de variable válido en Pascal. <Identificador de Pascal>::=
<especificación de tipo Pascal>::= INTEGER
1 REAL I STRING <corchete izquierdo> <length> <corchete derecho>
<corchete izquierdo>::= [
<corchete derecho>::= ]
152
ANEXO B
PRIMITIVAS DEL SISTEMA ADMINIS-R DE BASES DE DATOS DISTRIBUIDAS
En este anexo se describe el conjunto completo de las primitivas del sistema administrador de bases de datos distribuidas (SABDD) desarrollado por el IIE [ 9 , lo].
Las primitivas fueron desarrolladas en lenguaje ensamblador MASM versión 4 y pueden accesarse desde un programa en nirbo Pascal versiones 4 o posteriores. Las primitivas se encuentran disponibles a través de una unidad de nirbo Pascal que se denomina RUTINA2.
A continuación se describe la forma de llamarlas desde un programa en Pascal. La descripción se realiza agrupando a las primitivas de acuerdo al tipo de funci6n que realizan.
1 Primitivas para la apertura y cierre de archivos
1.1 Abre2
Nombre de la rutina: Abre2. mnción: Abre un archivo de la BDD en forma transparente. Forma de llamarse desde Pascal:
Abre2(entidad, uso, permiso, estado);
donde:
entidad es el nombre del archivo que se desea abrir. uso es el uso del archivo que desea el programa
invocador (lectura, escritura y total). permiso es el uso del archivo que permite el programa invocador
a otros programas (ninguno, lectura, escritura y total). estado regresa un valor que indica si la operacibn fue exitosa
o no.
1.2 Cierra2
Nombre de la rutina: Cierra2. minci6n: Cierra un archivo de la BDD en forma transparente. Forma de llamarse desde Pascal:
Cierraz(entidad, estado);
153
donde:
entidad estado
es el nombre del archivo que se desea cerrar. regresa un valor que indica si la operación fue exitosa o no.
2 Lectura, escritura, modificacibn y borrado de registros
2.1 Lee2
Nombre de la rutina: Lee2. Función: Lee un registro de un archivo de la BDD en forma
Forma de llamarse desde Pascal: transparente.
LeeZ(entidad, numreg, registro, estado);
donde:
entidad
numreg es el número de registro que se desea leer. registro
estado
es el nombre del archivo que contiene el registro que se desea leer.
es una variable tipo apuntador que contiene la direcci6n de la variable donde será leída la información del registro. regresa un valor que indica si la operación fue exitosa o no.
2.2 Escribe2
Nombre de la rutina: Escribe2. Función:
Forma de llamarse desde Pascal:
EscribeP(entidad, registro, estado);
donde:
entidad es el nombre del archivo donde se desea escribir el
Escribe un registro al final de un archivo de la BDD en forma transparente.
registro. es una variable tipo apuntador que contiene la dirección de la información a grabar en el archivo. regresa un valor que indica si la operación fue exitosa o no.
registro
estado
154
2.3 ~odifica2
Nombre de la rutina: Modifica2. Función: Modifica el contenido de un registro de un archivo de la
BDD en forma transparente. Forma de l¡amarse desde Pascal:
ModificaZ(entidad, numreg, registro, estado);
donde:
entidad
numreg registro
estado
es el nombre del archivo que contiene el registro que se desea modificar. es el número de registro que se desea modificar. es una variable tipo apuntador que contiene la dirección de la nueva información del registro. regresa un valor que indica si la operación fue exitosa o no.
2.4 Borra2
Nombre de la rutina: Borra2. Función: Borra un registro de un archivo de la BDD en forma
Forma de llamarse desde Pascal: transparente.
BorraZ(entidad, numreg, estado);
donde:
entidad
numreg estado
es el nombre del archivo que contiene el registro que se desea borrar. es el número de registro que se desea borrar. regresa un valor que indica si la operación fue exitosa o no.
3 Reservación y liberación de registros
3.1 ResReg2
Nombre de la rutina: ResReg2. Función: Reserva un registro de un archivo de la BDD en forma
transparente. La reservación del registro es para usarlo de manera exclusiva.
Forma de llamarse desde Pascal:
ResRegZ(entidad, numreg, estado);
155
donde:
entidad es el nombre del archivo que contiene el registro que se desea reservar.
numreg estado
es el número de registro que se desea reservar. regresa un valor que indica si la operación fue exitosa o no.
3.2 LibReg2
Nombre de la rutina: LibReg2. Función:
Forma de llamarse desde Pascal:
LibRegZ(entidad, numreg, estado);
donde:
entidad
numreg estado
Libera un registro previamente reservado de un archivo de la BDD en forma transparente.
es el nombre del archivo que contiene el registro que se desea liberar. es el número de registro que se desea liberar. regresa un valor que indica si la operación fue exitosa o no.
4 Borrado y creaci4n de archivos
4.1 ~orraArch2
Nombre de la rutina: BorraArch2. Función: Borra un archivo de la BDD en forma transparente. Forma de llamarse desde Pascal:
BorraArchZ(entidad, estado).
donde:
entidad estado indica si la operación fue exitosa o no.
es el nombre del archivo que se desea borrar.
4.2 CreaArch2
N o m b r e de la rutina: CreaArch2. _ _ -~ ~
Función: Crear un archivo en la BDD. Mota: Esta rutina es la única del conjunto de las primitivas
m e necesita especificar el nodo donde se desea efectuar fa operación. Todas las demás primitivas se realizan de manera transparente.
156
Forma de llamarse desde Pascal:
CreaArch2(nodo, entidad, longreg, estado).
donde:
nodo es el nombre de la computadora donde se desea crear el arhivo,
entidad es el nombre del archivo que se desea crear. longreg es l a longitud que deben tener los registros del
archivo. estado indica SI la operación fue exitosa o no.
15.7
ANEXO c
En este anexo se presentan las extensiones hechas a la Norma de SQL para el SABDD. La principal extensión se hizo para facilitar la creación de una tabla en cualquier nodo de la base de datos distribuida, desde cualquier nodo. Esto es para facilitar la distribución de las tablas por los programas de aplicación de la
La segunda extensión que se realizó tuvo como objetivo, facilitar al desarrollador de aplicaciones el manejo de otro tipo de dato diferente a los especificados en la Norma de SQL. Este tipo de dato se denomina "Date" y sirve para manejar variables tipo fecha.
BDD .
La tercera extensión que se hizo fue para facilitar el borrado
La cuarta extensión se realizó para proporcionar el manejo de índices (creación y borrado) sobre columnas que no necesariamente requieren una especificación de unicidad. Esto es con el objeto de optimizar las operaciones de selecci6n. Aunque el precompilador del LMD no incluye estrategias de optimización de acceso, futuras extensiones a este trabajo podrán utilizarlos,
La quinta extensión se realizó para controlar el acceso concurrente a la BDD y consistió en la implementación de dos estatutos para reservar y liberar tablas en forma exclusiva (LOCK y UNLOCK). Cuando un programa de aplicación aplica un LOCK sobre otra tabla, ningún otro programa de aplicación puede operar sobre esa tabla: cualquier intento de utilizar esa tabla (por otro programa) detiene la ejecución de ese programa.
de una tabla de la BDD (DROP TABLE).
EXTENSIONES REALIZADAS
1) <especificación de nodo>
Función: Especifica el nodo donde se quiere crear la tabla y es parte opcional de una <definición de tabla>. Si no se especifica, entonces se supone que el nodo donde se creará la tabla es el nodo local, es decir, el nodo donde se ejecuta el programa.
158
Formato:
<definición de tabla>::= CREATE TABLE <nombre de tabla> ( <elemento de tabla> [(,<elemento de tabla>) . . . I ) [<especificación de nodo>]
<especificación de nodo>::= IN tnombre de nodo>
tnombre de nodo>::= <identificador>
E j emplo :
$Create table E j e m l ( Nombre Char(20) ) in 'Alfa\Aifa-C';
2 <tipo de dato fecha>
Punción: Especifica un tipo de dato fecha en el formato {DD-MM- AAAA). Un tipo de dato fecha se maneja físicamente como un t ipo de dato LongInt de Pascal y ocupa 4 bytes.
Formato:
<tipo de dato fecha>::= DATE.
E j emplo :
$Create Table E j em2 ( Nombre Char(20), FechaIngreso Date);
3 <literal fecha>
Ainci6n:
Formato:
<literal fecha>::=
Especifica un valor no nul0 que es de tipo DATE.
tllave izq> <dia> <separador fecha> <mes> <separador fecha> <ano> tllave der>
<llave izq>::= (
<dia>::= <entero sin signo> en el rango de 01..31
159
<separador fecha>::= / 1 - <mes>::= tentero sin signo> en el rango de 01..12
, . . ,..
<año>::= <año completo>. I .<aAo parte> <año completo>:= - * i . , .
. A
tentero sin signo> en el rango de 1980 .. 1999. <entero sin signo> en el rango de 80..99.
<año parte>::=
<llave der>,: :s ]
E-j emplo : < .
$Create Table Ejem3 (
$Insert Into Ejem3 ('Smith', (10/08/92));
Nombre Char(20), FechaIng Date default (04-12-91));
> . . . . . .: . , , , . . "
. . 4
Las variables anfitrionas para el tipo de dato Date deben declararse de la sigueiente manera:
<Identificador de Pascal> [[tidentificador de Pascal)...]: SQLDATE;
donde
SQLDATE es un tipo de dato declarado en la unidad SQL y consiste en un tipo de dato string[iO]. Por lo tanto, para asignar a una valor a una variable anfitriona tipo SQLDATE un valor, éste debe encerrarse entre comillas.
Variables 'anfitrionas para el tipo de dato Date
160
Ej -10 :
uses SQL; $begin declare section
Nombre : String[20]; Fecha : SqiDate;
end declare section;
begin Nombre:='Smith'; Fecha:='20-01-1992'; $Insert into Ejem3 (:Nombre, :Fecha);
$Select FechaIng Into :Fecha where Nombre = 'Clark';
end.
5 <estatuto drop table>
Rinción: Borra una tabla de la base de datos distribuida y los
mnnato:
<drop table>::= Drop Table <nombre de tabla>
índices definidos sobre ella (en caso de haberlos).
Ej -10 :
Uses SQL; begin
end. $Drop Table Ejem3;
6 testatuto create index>
RinciOn: Crea un archivo tabla.
! índices sobre las columnas de una
mrmato:
testatuto create index>::= CREATE INDEX [UNIQUE I DISTINCT] <nombre de índice> ON <nombre de tabla> (<lista de columnas índice>);
tnombre de índice>::=<identificador> <lista de columnas índice>::=
tnombre de columna> [(,<nombre de columna>...)]
161
Notas :
1) S i un t e s t a tu to c rea te index> especif ica UNIQUE o DISTINCT, entonces e l índ ice asociado está restr ingido a no aceptar valores iguales sobre l a combinacibn d e l a s c o l m a s especificadas en l a < l i s t a de columnas índice>.
2 ) La < l i s t a de c o l m a s índice> no podrá contener <nombre de columnam repetidos.
Ejemplo :
Uses SQL; begin
end.
$Create Index IndEjem on Ejem3 (Nombre) :
>
,-" i .
7 <esta tu to drop index>
Fhci6n:. . ~.Borra:un i índice ' previamente definido' sobre ' k a tabla .
Formato:
t e s t a tu to drop index>: :=.
. r ' ' . .~ . . ~ . .
:. ,
DROP INDEX <nombre de . índice>
Ej emplo :
Uses SQL; begin
end. $Drop Index IndEjem;
8 <esta tu to lock table>
~FuncIOn: Reserva una tabla para uso exlusivo.
Formato:
<es ta tu to lock table>::= . . . .
LOCK <nombre de . t ab l a> . .
. .
162
E j emp10 :
Uses SQL; begin
end. $Lock E j e m 3 ;
g <estatuto d o c k table>
Función:
Formato:
<estatuto unlock table>::=
L i b e r a una tabla previamente reservada.
UNLOCK <nombre de tabla>
Ej emplo :
Uses CQL; begin
Sunlock end.
Ejem3;
163
. .
BIBLIOGRAPIA Y m w
Ozsu, M. Tamer [y] P. Valduriez, "Distributed Database Systems: Where Are We Now". En: Computer, Vol. 24. NO. 8 (1991), pp. 68.
Stonebraker, M., Readinus in Database Systems. San Meteo, California: Morgan Kaufmenn, 1988, 189 p.
Ozsu, M. Tamer [y] P. Valduriez, Principles of Distributed Database Systems. Englewood Cliffs, New Jersey: Prentice Hail, 1991, ix int.
Mohan, C., Tutorial: Recent Advances in Distributed Database Manauement. Silver Spring, UD.: IEEE Computer Society Press, 1984, 1 p.
Ullman, Jeffrey D., Principles of Database Systems. Second Edition, Rockville, Md.: Computer Skience Press, 1982, 169-170 P. Ozsu, M. Tamer [y! P. Valduriez, Principles of Distributed Database Systems, op cit., 17 p.
Mohan, C., op cit., 9 p.
Date, C. J., A Guide to the SQL Standar. USA: 'Addison-Wesley Publishing Company, 1987, 1-4 p.
PBrez, Ortega Joaquín [y] Rodolfo A. Pazos Rangei, Wanejador de Archivos Distribuidos con Acceso Concurrente en una Red Local de PCs". En: Memorias de la XVII-Reuni6n Internacional MEXICON del IEEE M6xico. Tomo I, México, D.F., 17-22 de Septiembre 1989.
[lo] PBrez, Ortega Joaquín, "Informe del Algoritmo de Transparencia de Localizaci6n de Archivos", Informe del proyecto 2159 del Departamento de sistemas de Informaci6n del IIE, Cuernavaca, Morelos, 1989.
[ill Guzmán, Ramlrez Salvador, "Desarrollo de un Lenguaje de Hanipulaci6n de Datos para un Manejador de Bases de Datos Distribuidas ( B D D ) " . Puebla, Pue. : Universidad Autbnoma de Puebla, 1990 (Tesis de Licenciatura).
[I21 ISO/IEC: Database Language SOL with Integrity Enhacament, Documento ISO/IEC 9075: 1989 (E) 120p.
[13] Ceri, Stefan0 [y] Giuseppe Pelagatti, Distributed Databases Principles and Systems. Singapore: McGraw-Hili, 1985, 6 p.
16 4
1141 Date, C . J., "What Is a Distributed Database System". En: Date c. J., Relational Databases: Selected Writinqs. Reading, Mass.: Addison-Wesley, 1986.
[is] OZSU, M. Tamer [y] P. Valduriez, "Distributed Database Systems: Where Are We NOW", OR Cit., pp. 72.
1161 Darling, Charles B., "Waiting For Distributed Database". En:
[17] Krasowski, Michael, "why Choose Distributed Database?". En: Database Progrminq and Desisn, Vol. 4, No. 3 (1991). pp. 53.
[18] Rothnie, J.B., P.A. Bernstein, P.A., et ai., "Introduction to a System for Distributed Databases (SDD-1)". En: e Transactions on Database Svstems, Vol. 5, No. 1, March 1980,
[ig] Lindsay, B.J., "A Retrospective of R*: A Distributed Database Management System". En: Proc. IEEE, Vol. 75, No. 5, May 1987,
[20] Chan, A., U. Fox, et al., "Overview of An ADA* Compatible Distributed DatabaseManager". En: Proc. SIGMOND 83, May 1983,
[21] Stonebraker, M . , J. Woodfill, et al., "Performance Analysis of Distributed Data Base Systems". En: Database Enqineerinq, Vol. 5 , N o . 2, December 1982.
[22] Neuhold, E. J. [y] B. Walter, "An Overview of the Architecture of the Distributed Database System POREL". En Proc. 2nd International Symposium on Distributed Data Bases, Berlin, September 1982, Nort Holland Publishing Company.
[23] Codd, E. F., "A Relational Model of Data for Large Shared Data Banks". En: Communications of the ACM, Vol. 13, No. 6 (1970),
- DBMS. Vol 4, NO. 10 (1991). pp. 46.
pp. 1-17.
pp. 668-673.
pp. 228-237.
pp. 377-387.
[24] Date, C . J., An Introduction to Database Svstems. Vol. 1, Cuarta Ed., Addison-Wesley, 1986, 97 p.
[25] Borland International, "Turbo Pascal Programmer's Guide",
[26] Ibid, 133 p.
Versi6n 6.0, Scotts, Valley, California, 3990. 129-130 p.
[ 2 7 ] Date, C . J., An Introduction to Database Svstems, op cit., 63 P.
[28] Knuth, Donal E., The Art of COmDuter Proqramminq, Voi.3, USA: Addison-Wesley. 1976, 473-476 p.
165
[29] Wirth, Niklaus, AlqorithRIn + Data Structures = Proqrms.
[30] Aho, ALfred v . [y] Jeffrey D. U l l m a n , Principies of Compiler
Englewood Cliffs, New Jersey: PtenticeHall, 1976, 245-264 p.
Design. USA: Addison-Wesley Publishing Company, c1977.
(311 Tremblay, Jean-Paul [y] Paul C . Sorenson, The Theory and Practice of Compiler Writing. USA: McGraw-Hili, 1985.
[32] Date, C. J., An Introduction to Database Systems, OD Cit., 127-163 p.
166