La Cara Oculta de C++ Builder

Un gato camina sobre el borde del tejado;Tras l, el Sol se pone.

Gira su cara hacia m, y creo que me sonre.Luego, de un salto, pasa sobre la lnea del horizonte.

Dedicado a Vivian, dondequiera que est.Ian \

INDICEINDICE

PRLOGO DEL AUTOR 17

CONTENIDO DEL LIBRO 17AGRADECIMIENTOS 19

EL LENGUAJE SQL 21

1. SISTEMAS DE BASES DE DATOS 23

ACERCA DEL ACCESO TRANSPARENTE A BASES DE DATOS 23BASES DE DATOS RELACIONALES 24INFORMACIN SEMNTICA = RESTRICCIONES 26RESTRICCIONES DE UNICIDAD Y CLAVES PRIMARIAS 27INTEGRIDAD REFERENCIAL 28QU TIENE DE MALO EL MODELO RELACIONAL? 29BASES DE DATOS LOCALES Y SERVIDORES SQL 31CARACTERSTICAS GENERALES DE LOS SISTEMAS SQL 33EL FORMATO PARADOX 34EL FORMATO DBF7 37CRITERIOS PARA EVALUAR UN SERVIDOR SQL 39INTERBASE 41MICROSOFT SQL SERVER 43ORACLE 45OTROS SISTEMAS DE USO FRECUENTE 46

2. BREVE INTRODUCCIN A SQL 49

LA ESTRUCTURA DE SQL 49PARA SEGUIR LOS EJEMPLOS DE ESTE LIBRO 50LA CREACIN Y CONEXIN A LA BASE DE DATOS 52TIPOS DE DATOS EN SQL 53REPRESENTACIN DE DATOS EN INTERBASE 54CREACIN DE TABLAS 55COLUMNAS CALCULADAS 56VALORES POR OMISIN 57RESTRICCIONES DE INTEGRIDAD 57CLAVES PRIMARIAS Y ALTERNATIVAS 58INTEGRIDAD REFERENCIAL 60ACCIONES REFERENCIALES 61NOMBRES PARA LAS RESTRICCIONES 62

4 La Cara Oculta de C++ Builder

DEFINICIN Y USO DE DOMINIOS 63CREACIN DE NDICES 64MODIFICACIN DE TABLAS E NDICES 65CREACIN DE VISTAS 66CREACIN DE USUARIOS 66ASIGNACIN DE PRIVILEGIOS 68ROLES 69UN EJEMPLO COMPLETO DE SCRIPT SQL 70

3. CONSULTAS Y MODIFICACIONES 73

LA INSTRUCCIN SELECT: EL LENGUAJE DE CONSULTAS 73LA CONDICIN DE SELECCIN 75OPERADORES DE CADENAS 75YO SLO QUIERO LOS DIEZ PRIMEROS... 76EL VALOR NULO: ENFRENTNDONOS A LO DESCONOCIDO 77ELIMINACIN DE DUPLICADOS 78PRODUCTOS CARTESIANOS Y ENCUENTROS 79ORDENANDO LOS RESULTADOS 81EL USO DE GRUPOS 82FUNCIONES DE CONJUNTOS 83LA CLUSULA HAVING 84EL USO DE SINNIMOS PARA TABLAS 85SUBCONSULTAS: SELECCIN NICA 86SUBCONSULTAS: LOS OPERADORES IN Y EXISTS 87SUBCONSULTAS CORRELACIONADAS 88EQUIVALENCIAS DE SUBCONSULTAS 89ENCUENTROS EXTERNOS 91LA CURIOSA SINTAXIS DEL ENCUENTRO INTERNO 93LAS INSTRUCCIONES DE ACTUALIZACIN 94LA SEMNTICA DE LA INSTRUCCIN UPDATE 95VISTAS 96

4. PROCEDIMIENTOS ALMACENADOS Y TRIGGERS 99

PARA QU USAR PROCEDIMIENTOS ALMACENADOS? 99CMO SE UTILIZA UN PROCEDIMIENTO ALMACENADO 101EL CARCTER DE TERMINACIN 102PROCEDIMIENTOS ALMACENADOS EN INTERBASE 103PROCEDIMIENTOS QUE DEVUELVEN UN CONJUNTO DE DATOS 106RECORRIENDO UN CONJUNTO DE DATOS 108TRIGGERS, O DISPARADORES 109LAS VARIABLES NEW Y OLD 111MS EJEMPLOS DE TRIGGERS 111GENERADORES 113

Indice 5

SIMULANDO LA INTEGRIDAD REFERENCIAL 116EXCEPCIONES 117ALERTADORES DE EVENTOS 119FUNCIONES DE USUARIO EN INTERBASE 121

5. TRANSACCIONES 125

POR QU NECESITAMOS TRANSACCIONES? 125EL CIDO SABOR DE LAS TRANSACCIONES 127TRANSACCIONES SQL Y EN BASES DE DATOS LOCALES 128TRANSACCIONES IMPLCITAS Y EXPLCITAS 128NIVELES DE AISLAMIENTO DE TRANSACCIONES 131REGISTROS DE TRANSACCIONES Y BLOQUEOS 133LECTURAS REPETIBLES MEDIANTE BLOQUEOS 136VARIACIONES SOBRE EL TEMA DE BLOQUEOS 138EL JARDN DE LOS SENDEROS QUE SE BIFURCAN 139BLOQUEOS O VERSIONES? 141NIVELES DE AISLAMIENTO Y TRANSACCIONES IMPLCITAS 143

6. MICROSOFT SQL SERVER 145

HERRAMIENTAS DE DESARROLLO EN EL CLIENTE 145CREACIN DE BASES DE DATOS CON MS SQL SERVER 146BASES DE DATOS EN LA VERSIN 7 148TIPOS DE DATOS PREDEFINIDOS 149TIPOS DE DATOS DEFINIDOS POR EL PROGRAMADOR 150CREACIN DE TABLAS Y ATRIBUTOS DE COLUMNAS 151INTEGRIDAD REFERENCIAL 152INDICES 153SEGURIDAD EN MS SQL SERVER 153PROCEDIMIENTOS ALMACENADOS 154CURSORES 155TRIGGERS EN TRANSACT-SQL 157INTEGRIDAD REFERENCIAL MEDIANTE TRIGGERS 159TRIGGERS ANIDADOS Y TRIGGERS RECURSIVOS 161

7. ORACLE 163

SOBREVIVIENDO A SQL*PLUS 163INSTANCIAS, BASES DE DATOS, USUARIOS 165TIPOS DE DATOS 166CREACIN DE TABLAS 167INDICES EN ORACLE 168ORGANIZACIN FSICA DE LAS TABLAS 169PROCEDIMIENTOS ALMACENADOS EN PL/SQL 171CONSULTAS RECURSIVAS 172


PLANES DE OPTIMIZACIN EN ORACLE 173CURSORES 174TRIGGERS EN PL/SQL 176LA INVASIN DE LAS TABLAS MUTANTES 177PAQUETES 179ACTUALIZACIN DE VISTAS MEDIANTE TRIGGERS 181SECUENCIAS 182TIPOS DE OBJETOS 184

8. DB2 UNIVERSAL DATABASE 189

ARQUITECTURA Y PLATAFORMAS 189AISLAMIENTO DE TRANSACCIONES 190TIPOS DE DATOS 191CREACIN DE TABLAS Y RESTRICCIONES 193INDICES 194TRIGGERS 195CONSULTAS RECURSIVAS 196PROCEDIMIENTOS ALMACENADOS 198

9. EL MOTOR DE DATOS DE BORLAND 199

QU ES, Y CMO FUNCIONA 200CONTROLADORES LOCALES Y SQL LINKS 201ACCESO A FUENTES DE DATOS ODBC 202DNDE SE INSTALA EL BDE? 202EL ADMINISTRADOR DEL MOTOR DE DATOS 204CONFIGURACIN DEL REGISTRO E INFORMACIN DE VERSIN 204EL CONCEPTO DE ALIAS 206PARMETROS DEL SISTEMA 206PARMETROS DE LOS CONTROLADORES PARA BD LOCALES 208BLOQUEOS OPORTUNISTAS 210PARMETROS COMUNES A LOS CONTROLADORES SQL 211CONFIGURACIN DE INTERBASE 214CONFIGURACIN DE MS SQL SERVER 216CONFIGURACIN DE ORACLE 217CONFIGURACIN DE OTROS SISTEMAS 219CREACIN DE ALIAS PARA BASES DE DATOS LOCALES Y SQL 219ALTERNATIVAS AL MOTOR DE DATOS 220

C++ BUILDER: NAVEGACIN Y BSQUEDAS 221

10. CONJUNTOS DE DATOS: TABLAS 223

LA JERARQUA DE LOS CONJUNTOS DE DATOS 223

Indice 7

LA ARQUITECTURA DE OBJETOS DEL MOTOR DE DATOS 225TABLA O CONSULTA? 227TABLAS (POR EL MOMENTO) 229EXCLUSIVIDAD Y BLOQUEOS 231CONEXIN CON COMPONENTES VISUALES 232NAVEGANDO POR LAS FILAS 234MARCAS DE POSICIN 235ENCAPSULAMIENTO DE LA ITERACIN 236LA RELACIN MASTER/DETAIL 239NAVEGACIN Y RELACIONES MASTER/DETAIL 242EL ESTADO DE UN CONJUNTO DE DATOS 247

11. ACCESO A CAMPOS 249

CREACIN DE COMPONENTES DE CAMPOS 249CLASES DE CAMPOS 251NOMBRE DEL CAMPO Y ETIQUETA DE VISUALIZACIN 253ACCESO A LOS CAMPOS POR MEDIO DE LA TABLA 254EXTRAYENDO INFORMACIN DE LOS CAMPOS 255LAS MSCARAS DE FORMATO Y EDICIN 256LOS EVENTOS DE FORMATO DE CAMPOS 258CAMPOS CALCULADOS 259CAMPOS DE BSQUEDA 261LA CACH DE BSQUEDA 263EL ORDEN DE EVALUACIN DE LOS CAMPOS 264EXTENSIONES PARA LOS TIPOS DE OBJETOS DE ORACLE 8 265INFORMACIN SOBRE CAMPOS 268CREACIN DE TABLAS 269

12. VALIDACIONES Y EL DICCIONARIO DE DATOS 273

VALIDACIN A NIVEL DE CAMPOS 273PROPIEDADES DE VALIDACIN 274EL DICCIONARIO DE DATOS 275CONJUNTOS DE ATRIBUTOS 276IMPORTANDO BASES DE DATOS 277EVALUANDO RESTRICCIONES EN EL CLIENTE 278

13. CONTROLES DE DATOS Y FUENTES DE DATOS 281

CONTROLES DATA-AWARE 281LOS ENLACES DE DATOS 283CREACIN DE CONTROLES DE DATOS 284LOS CUADROS DE EDICIN 285EDITORES DE TEXTO 286TEXTOS NO EDITABLES 287


COMBOS Y LISTAS CON CONTENIDO FIJO 287COMBOS Y LISTAS DE BSQUEDA 290ESENCIA Y APARIENCIA 292CASILLAS DE VERIFICACIN Y GRUPOS DE BOTONES 292IMGENES EXTRADAS DE BASES DE DATOS 293LA TCNICA DEL COMPONENTE DEL POBRE 293PERMITIENDO LAS MODIFICACIONES 295BLOB, BLOB, BLOB 297LA CLASE TBLOBSTREAM 298

14. REJILLAS Y BARRAS DE NAVEGACIN 301

EL USO Y ABUSO DE LAS REJILLAS 301EL FUNCIONAMIENTO BSICO DE UNA REJILLA DE DATOS 302OPCIONES DE REJILLAS 304COLUMNAS A LA MEDIDA 304GUARDAR Y RESTAURAR LOS ANCHOS DE COLUMNAS 307LISTAS DESPLEGABLES Y BOTONES DE EDICIN 308NMEROS VERDES Y NMEROS ROJOS 309MS EVENTOS DE REJILLAS 312LA BARRA DE DESPLAZAMIENTO DE LA REJILLA 313REJILLAS DE SELECCIN MLTIPLE 313BARRAS DE NAVEGACIN 314HABA UNA VEZ UN USUARIO TORPE, MUY TORPE 315AYUDAS PARA NAVEGAR 316EL COMPORTAMIENTO DE LA BARRA DE NAVEGACIN 316REJILLAS DE CONTROLES 318

15. INDICES 321

CON QU NDICES PODEMOS CONTAR 321ESPECIFICANDO EL NDICE ACTIVO 323INDICES EN DBASE 325ESPECIFICANDO UN ORDEN EN TABLAS SQL 326BSQUEDA BASADA EN NDICES 327IMPLEMENTACIN DE REFERENCIAS MEDIANTE FINDKEY 329BSQUEDAS UTILIZANDO SETKEY 330EXPERIMENTANDO CON SETKEY 330POR QU EXISTE SETKEY? 332RANGOS: DESDE EL ALFA A LA OMEGA 333EL EJEMPLO DE RANGOS DE CASI TODOS LOS LIBROS 335MS PROBLEMAS CON LOS NDICES DE DBASE 336CMO CREAR UN NDICE TEMPORAL 337

Indice 9

16. MTODOS DE BSQUEDA 341

FILTROS 341ESTO NO LO DICE LA DOCUMENTACIN 342UN EJEMPLO CON FILTROS RPIDOS 343EL EVENTO ONFILTERRECORD 346LOCALIZACIN Y BSQUEDA 347UN DILOGO GENRICO DE LOCALIZACIN 350FILTROS LATENTES 352FILTER BY EXAMPLE 354BSQUEDA EN UNA TABLA DE DETALLES 358

17. NAVEGACIN MEDIANTE CONSULTAS 361

EL COMPONENTE TQUERY COMO CONJUNTO DE DATOS 361QUIN EJECUTA LAS INSTRUCCIONES? 362CONSULTAS ACTUALIZABLES 363SIEMPRE HACIA ADELANTE 365CONSULTAS PARAMTRICAS 368CONSULTAS DEPENDIENTES 370LA PREPARACIN DE LA CONSULTA 371VISUAL QUERY BUILDER 373

18. COMUNICACIN CLIENTE/SERVIDOR 377

NUESTRA ARMA LETAL: SQL MONITOR 377APERTURA DE TABLAS Y CONSULTAS 378LA CACH DE ESQUEMAS 380OPERACIONES DE NAVEGACIN SIMPLE 380BSQUEDAS EXACTAS CON LOCATE 381BSQUEDAS PARCIALES 382UNA SOLUCIN PARA BSQUEDAS PARCIALES RPIDAS 383BSQUEDAS CON FILTROS LATENTES 384

C++ BUILDER: ACTUALIZACIONES Y CONCURRENCIA 387

19. ACTUALIZACIONES 389

LOS ESTADOS DE EDICIN Y LOS MTODOS DE TRANSICIN 389ASIGNACIONES A CAMPOS 390CONFIRMANDO LAS ACTUALIZACIONES 392DIFERENCIAS ENTRE INSERT Y APPEND 393COMO POR AZAR 394MTODOS ABREVIADOS DE INSERCIN 395EL GRAN EXPERIMENTO 396


EL GRAN EXPERIMENTO: TABLAS LOCALES 397EL GRAN EXPERIMENTO: TABLAS SQL 398PESIMISTAS Y OPTIMISTAS 399EL MODO DE ACTUALIZACIN 400LA RELECTURA DEL REGISTRO ACTUAL 402ELIMINANDO REGISTROS 404ACTUALIZACIN DIRECTA VS VARIABLES EN MEMORIA 404AUTOMATIZANDO LA ENTRADA DE DATOS 406ENTRADA DE DATOS CONTINUA 408

20. ACTUALIZACIONES MEDIANTE CONSULTAS 411

INSTRUCCIONES DEL DML 411ALMACENAR EL RESULTADO DE UNA CONSULTA 412EJECUTAR O ACTIVAR? 413NUEVAMENTE COMO POR AZAR.... 416ACTUALIZACIN SOBRE CURSORES DE CONSULTAS 417UTILIZANDO PROCEDIMIENTOS ALMACENADOS 418

21. EVENTOS DE TRANSICIN DE ESTADOS 421

CUANDO EL ESTADO CAMBIA 421REGLAS DE EMPRESA: EN EL SERVIDOR O EN EL CLIENTE? 422INICIALIZACIN DE REGISTROS: EL EVENTO ONNEWRECORD 423VALIDACIONES A NIVEL DE REGISTROS 424ANTES Y DESPUS DE UNA MODIFICACIN 425PROPAGACIN DE CAMBIOS EN CASCADA 427ACTUALIZACIONES COORDINADAS MASTER/DETAIL 428ANTES Y DESPUS DE LA APERTURA DE UNA TABLA 429TIRANDO DE LA CADENA 430LOS EVENTOS DE DETECCIN DE ERRORES 431LA ESTRUCTURA DE LA EXCEPCIN EDBENGINEERROR 432APLICACIONES DE LOS EVENTOS DE ERRORES 436UNA VEZ MS, LA ORIENTACIN A OBJETOS 438

22. BASES DE DATOS Y TRANSACCIONES 439

EL COMPONENTE TDATABASE 439OBJETOS DE BASES DE DATOS PERSISTENTES 440CAMBIANDO UN ALIAS DINMICAMENTE 441BASES DE DATOS Y CONJUNTOS DE DATOS 443PARMETROS DE CONEXIN 444LA PETICIN DE CONTRASEAS 445EL DIRECTORIO TEMPORAL DE WINDOWS 447COMPARTIENDO LA CONEXIN 448CONTROL EXPLCITO DE TRANSACCIONES 449

Indice 11

ENTRADA DE DATOS Y TRANSACCIONES 450

23. SESIONES 453

PARA QU SIRVEN LAS SESIONES? 453ESPECIFICANDO LA SESIN 454CADA SESIN ES UN USUARIO 454EL INICIO DE SESIN Y LA INICIALIZACIN DEL BDE 455SESIONES E HILOS PARALELOS 457INFORMACIN SOBRE ESQUEMAS 460EL MINIEXPLORADOR DE BASES DE DATOS 461GESTIN DE ALIAS A TRAVS DE TSESSION 463DIRECTORIOS PRIVADOS, DE RED Y CONTRASEAS 464

24. ACTUALIZACIONES EN CACH 467

CACH PARA QU? 467ACTIVACIN DE LAS ACTUALIZACIONES EN CACH 468CONFIRMACIN DE LAS ACTUALIZACIONES 469MARCHA ATRS 471EL ESTADO DE ACTUALIZACIN 472EL FILTRO DE TIPOS DE REGISTROS 473UN EJEMPLO INTEGRAL 474EL GRAN FINAL: EDICIN Y ENTRADA DE DATOS 476COMBINANDO LA CACH CON GRABACIONES DIRECTAS 478PROTOTIPOS Y MTODOS VIRTUALES 482CMO ACTUALIZAR CONSULTAS NO ACTUALIZABLES 483EL EVENTO ONUPDATERECORD 486DETECCIN DE ERRORES DURANTE LA GRABACIN 487TABLAS ... O CONSULTAS EN CACH? 489

PROGRAMACIN DISTRIBUIDA 491

25. CONJUNTOS DE DATOS CLIENTES 493

CREACIN DE CONJUNTOS DE DATOS 493CMO EL TCLIENTDATASET OBTIENE SUS DATOS 495NAVEGACIN, BSQUEDA Y SELECCIN 496FILTROS 497EDICIN DE DATOS 498CONJUNTOS DE DATOS ANIDADOS 499CAMPOS CALCULADOS INTERNOS 502INDICES, GRUPOS Y VALORES AGREGADOS 503


26. EL MODELO DE OBJETOS COMPONENTES 507

UN MODELO BINARIO DE OBJETOS 507YO QUIERO VER CDIGO! 508CLASES, OBJETOS E INTERFACES 509EL LENGUAJE DE DESCRIPCIN DE INTERFACES 511IDENTIFICADORES GLOBALES NICOS 513INTERFACES 514LA INTERFAZ IUNKNOWN 516TIEMPO DE VIDA 517INTROSPECCIN 518CMO OBTENER UN OBJETO COM 520PUNTEROS INTELIGENTES A INTERFACES 521

27. SERVIDORES COM 525

INTERCEPTANDO OPERACIONES EN DIRECTORIOS 525DENTRO DEL PROCESO, EN LA MISMA MQUINA, REMOTO... 526CARGA Y DESCARGA DE LA DLL 529OLE Y EL REGISTRO DE WINDOWS 530REGISTRANDO EL SERVIDOR 532IMPLEMENTACIN DE INTERFACES 534EL HUEVO, LA GALLINA Y LAS FBRICAS DE CLASES 536IMPLEMENTANDO LA FBRICA DE CLASES 538

28. AUTOMATIZACIN OLE: CONTROLADORES 541

POR QU EXISTE LA AUTOMATIZACIN OLE? 541CONTROLADORES DE AUTOMATIZACIN CON VARIANTES 543PROPIEDADES OLE Y PARMETROS POR NOMBRE 544INTERFACES DUALES 545BIBLIOTECAS DE TIPOS 546IMPORTACIN DE BIBLIOTECAS DE TIPOS 547EVENTOS 549ESCUCHANDO A WORD 552

29. AUTOMATIZACIN OLE: SERVIDORES 557

INFORMES AUTOMATIZADOS 557EL OBJETO DE AUTOMATIZACIN 559LA PARTE CLIENTE 563DECLARANDO UNA INTERFAZ COMN 564MODELOS DE INSTANCIACIN 566MODELOS DE CONCURRENCIA 568UN SERVIDOR DE BLOQUEOS 570LA IMPLEMENTACIN DE LA LISTA DE BLOQUEOS 572

Indice 13

CONTROL DE CONCURRENCIA 574PONIENDO A PRUEBA EL SERVIDOR 577

30. MIDAS 579

QU ES MIDAS? 579CUNDO UTILIZAR Y CUNDO NO UTILIZAR MIDAS 581MIDAS Y LAS BASES DE DATOS DE ESCRITORIO 583MDULOS DE DATOS REMOTOS 584PROVEEDORES 587SERVIDORES REMOTOS Y CONJUNTOS DE DATOS CLIENTES 589GRABACIN DE DATOS 591RESOLUCIN 594CONTROL DE ERRORES DURANTE LA RESOLUCIN 596RECONCILIACIN 599RELACIONES MASTER/DETAIL Y TABLAS ANIDADAS 601ENVO DE PARMETROS 601EXTENDIENDO LA INTERFAZ DEL SERVIDOR 602ALGUIEN LLAMA A MI PUERTA 604LA METFORA DEL MALETN 606TIPOS DE CONEXIN 606BALANCE DE CARGA SIMPLE 609INTERFACES DUALES EN MIDAS 610COGE EL DINERO Y CORRE: TRABAJO SIN CONEXIN 611

31. SERVIDORES DE INTERNET 617

EL MODELO DE INTERACCIN EN LA WEB 617APRENDA HTML EN 14 MINUTOS 618EXTENSIONES DEL SERVIDOR Y PGINAS DINMICAS 620QU NECESITO PARA ESTE SEGUIR LOS EJEMPLOS? 622MDULOS WEB 623ACCIONES 626RECUPERACIN DE PARMETROS 628GENERADORES DE CONTENIDO 629GENERADORES DE TABLAS 631MANTENIMIENTO DE LA INFORMACIN DE ESTADO 632LE APETECE UNA GALLETA? 634UN SIMPLE NAVEGADOR 635AL OTRO LADO DE LA LNEA... 639ACTIVEFORMS: FORMULARIOS EN LA WEB 640


LEFTOVERTURE 645

32. IMPRESIN DE INFORMES CON QUICKREPORT 647

LA HISTORIA DEL PRODUCTO 647LA FILOSOFA DEL PRODUCTO 648PLANTILLAS Y EXPERTOS PARA QUICKREPORT 649EL CORAZN DE UN INFORME 650LAS BANDAS 652EL EVENTO BEFOREPRINT 654COMPONENTES DE IMPRESIN 655EL EVALUADOR DE EXPRESIONES 656UTILIZANDO GRUPOS 657ELIMINANDO DUPLICADOS 659INFORMES MASTER/DETAIL 661INFORMES COMPUESTOS 662PREVISUALIZACIN A LA MEDIDA 663LISTADOS AL VUELO 665ENVIANDO CDIGOS BINARIOS A UNA IMPRESORA 667

33. ANLISIS GRFICO 671

GRFICOS Y BIORRITMOS 671EL COMPONENTE TDBCHART 675COMPONENTES NO VISUALES DE DECISION CUBE 677REJILLAS Y GRFICOS DE DECISIN 679USO Y ABUSO DE DECISION CUBE 681MODIFICANDO EL MAPA DE DIMENSIONES 682

34. DESCENSO A LOS ABISMOS 685

INICIALIZACIN Y FINALIZACIN DEL BDE 685EL CONTROL DE ERRORES 687SESIONES Y CONEXIONES A BASES DE DATOS 688CREACIN DE TABLAS 690REESTRUCTURACIN 693ELIMINACIN FSICA DE REGISTROS BORRADOS 695CURSORES 696UN EJEMPLO DE ITERACIN 698PROPIEDADES 700LAS FUNCIONES DE RESPUESTA DEL BDE 702

35. CREACIN DE INSTALACIONES 705

LOS PROYECTOS DE INSTALLSHIELD EXPRESS 705LA PRESENTACIN DE LA INSTALACIN 707

Indice 15

LAS MACROS DE DIRECTORIOS 708GRUPOS Y COMPONENTES 709INSTALANDO EL BDE Y LOS SQL LINKS 711CONFIGURACIN ADICIONAL DEL BDE 713INSTALACIN DE PAQUETES 713INTERACCIN CON EL USUARIO 714LAS CLAVES DEL REGISTRO DE WINDOWS 716CMO SE REGISTRAN LOS COMPONENTES ACTIVEX 717ICONOS Y CARPETAS 718GENERANDO Y PROBANDO LA INSTALACIN 719LA VERSIN COMPLETA DE INSTALLSHIELD EXPRESS 720LAS EXTENSIONES DE INSTALLSHIELD EXPRESS 721

36. EJEMPLOS: LIBRETAS DE AHORRO 723

DESCRIPCIN DEL MODELO DE DATOS 723LIBRETAS DE AHORRO EN MS SQL SERVER 729AHORA, EN ORACLE 733EL MDULO DE DATOS 736TRANSACCIONES EXPLCITAS 739GESTIN DE LIBRETAS Y OPERACIONES 740ENTRADA DE APUNTES 742LA VENTANA PRINCIPAL 744CORRIGIENDO EL IMPORTE DE UN APUNTE 746

37. EJEMPLOS: UN SERVIDOR DE INTERNET 749

BSQUEDA DE PRODUCTOS 749EL MOTOR DE BSQUEDAS 751CREANDO LA EXTENSIN WEB 754GENERANDO LA TABLA DE RESULTADOS 756DOCUMENTOS HTML Y SUSTITUCIN DE ETIQUETAS 757RESPONDIENDO A LAS ACCIONES 759

APENDICE: EXCEPCIONES 761

SISTEMAS DE CONTROL DE ERRORES 761CONTRATOS INCUMPLIDOS 762CMO SE INDICA UN ERROR 763LA EJECUCIN DEL PROGRAMA FLUYE EN DOS DIMENSIONES 764PAGAMOS NUESTRAS DEUDAS 765LA DESTRUCCIN DE OBJETOS DINMICOS 766EL BLOQUE DE PROTECCIN DE RECURSOS 768CMO TRANQUILIZAR A UN PROGRAMA ASUSTADO 770EJEMPLOS DE CAPTURA DE EXCEPCIONES 771CAPTURANDO EL OBJETO DE EXCEPCIN 772


CAPTURA Y PROPAGACIN DE EXCEPCIONES DE LA VCL 773DISTINGUIR EL TIPO DE EXCEPCIN 773LAS TRES REGLAS DE MARTEENS 774CICLO DE MENSAJES Y MANEJO DE EXCEPCIONES 775EXCEPCIONES A LA TERCERA REGLA DE MARTEENS 777EL EVENTO ONEXCEPTION 778LA EXCEPCIN SILENCIOSA 781CONSTRUCTORES Y EXCEPCIONES 782

INDICE ALFABETICO 787

Prlogo del AutorPrlogo del AutorThe day must come - if the world last long enough - said Arthur,

when every possible tune will have been composed - every possible pun perpetrated ...and, worse than that, every possible book written! For the number of words is finite.

Itll make very little difference to the authors, I suggested. Instead of saying what book shall Iwrite? an author will ask himself which book shall I write? A mere verbal distinction!

Lady Muriel gave me an approving smile. But lunatics would always write new books, surely?she went on. They couldnt write the sane books over again!

Lewis Carroll - Sylvie and Bruno Concluded

O CREO EN LAS ENCICLOPEDIAS; de hecho, nunca he podido terminar deleer alguna. Sin embargo, cada vez que hojeo un nuevo libro sobre C++Builder o Delphi me da la impresin de que el autor ha intentado preci-

samente escribir una enciclopedia; lstima que, en la mayora de los casos, el volumendel libro se limita a lo sumo a un tomo de no ms de 1000 pginas.

Este libro no pretende ni puede abarcar todos los temas relacionados con la pro-gramacin en C++ Builder; su objetivo concreto son LAS TCNICAS DE PROGRAMA-CIN DE BASES DE DATOS UTILIZANDO C++ BUILDER, con nfasis especial en eldesarrollo de aplicaciones cliente/servidor y de mltiples capas, tarea para la que losentornos de programacin de Borland estn particularmente bien preparados.

Por lo tanto, asumir cierta familiaridad del lector con C++, bastante comn entrelos programadores de hoy da; sera impensable intentar suplantar a clsicos de talenvergadura como El Lenguaje de Programacin C++ del creador del lenguaje, BjarneStroustrup.

Contenido del libroEl libro se divide en cinco partes, que son las siguientes:

La Parte 1 El lenguaje SQL ofrece una extensa presentacin de loselementos de SQL, tanto en lo referente a las instrucciones bsicas del estndarANSI 92, como en todo lo relacionado con la programacin del lado delservidor: el lenguaje de triggers y procedimientos almacenados. En este ltimoaspecto, los conceptos se presentan utilizando la sintaxis de InterBase, elservidor SQL de Borland. Posteriormente, presentamos por separado lascaractersticas distintivas de los tres sistemas cliente/servidor ms utilizados hoy:Microsoft SQL Server, IBM DB2 Universal Database y Oracle.

N


La Parte 2 Navegacin y bsqueda describe las facilidades bsicas queofrecen los componentes VCL incluidos en C++ Builder para querepresentemos los conjuntos de datos con los que vamos a trabajar y nosdesplacemos por los registros que los componen. Esta parte se encarga tambinde presentar la filosofa de utilizacin de controles visuales con conexin a datos(data-aware controls) y de mostrar ejemplos de cmo obtener interfaces de usuarioatractivas para mostrar la informacin. Para concluir esta parte, Comunicacincliente/servidor describe las tcnicas generales que deben tenerse en cuenta alinteractuar con bases de datos remotas; en este captulo mostramos lainconsistencia de varios mitos de amplia difusin entre la comunidad deprogramadores.

En la Parte 3 Actualizaciones y concurrencia se describen en detalle lasposibilidades que ofrece C++ Builder a la hora de actualizar el contenido denuestras bases de datos. En estos captulos se hace especial nfasis en todo lorelacionado con la optimizacin del acceso concurrente a las bases de datos, deforma que sea posible minimizar la contencin entre aplicaciones que se ejecutensimultneamente desde diferentes clientes, y se describen las posibilidades queofrece el Motor de Datos de Borland (Borland Database Engine - BDE) para laimplementacin de transacciones y las ventajas y limitaciones en este sentido delos diferentes sistemas SQL con los que el BDE puede comunicarse.

La Parte 4 Programacin Distribuida es, tcnicamente hablando, la mscompleja del libro. En esta parte describir inicialmente en detalle las posibili-dades del componente TClientDataSet, la clase sobre la que se basa la programa-cin de clientes delgados para el desarrollo de aplicaciones de mltiples capas enC++ Builder. Luego introducir los conceptos fundamentales del Modelo deObjetos Componentes (COM) de Microsoft, la base sobre la que se apoya laprogramacin de servidores de capa intermedia; inmediatamente despus, unamplio captulo describe en detalle las posibilidades de la tecnologa que Borlandha llamado MIDAS y se presentan ejemplos de aplicaciones de tres capas. Perotodava le quedar mucho ms por ver en esta parte: el siguiente captulo muestracmo utilizar los asistentes y componentes que incluye C++ Builder para crearextensiones de servidores de Internet que construyan dinmicamente pginasHTML a partir del contenido de bases de datos.

En la Parte 5, que he denominado Leftoverture1, se aglutina toda una serie decaptulos que en principio no tienen una conexin directa entre s. Aquencontrar todo lo relacionado con cmo utilizar QuickReport, la herramienta degeneracin de informes que se incluye en C++ Builder, cmo incluir en sus apli-caciones tablas de anlisis multidimensional de datos a partir de los componentesDecision Cube, o cmo generar instalaciones con InstallShield Express for C++

1 Leftoverture es el nombre de un lbum producido en 1976 por Kansas. El nombre esuna combinacin de las palabras leftover (remanente, residuo) y overture (obertura). Lapieza clave del lbum fue compuesta mezclando trozos de otras canciones que haban sidodescartadas por el grupo.

Prlogo del Autor 19

Builder. Los dos ltimos captulos presentan dos ejemplos completos deaplicaciones, cuyo cdigo fuente podr utilizar como material de estudio.

Mi propsito es que ste sea un libro vivo, que crezca a la vista de todos. As intentoevitar la incmoda sensacin que queda al entregar los ficheros a la imprenta de quete has olvidado de mencionar algo importante. Cmo crece este libro? Visite mipgina Web, en www.marteens.com, donde podr encontrar trucos y artculostcnicos que sirven de extensin a estas pginas.

AgradecimientosComo siempre, los protagonistas de todos mis libros son todos los programadoresque tengo el gusto de conocer y trabajar en alguna medida con ellos. Lo poco deoriginal que hay en estas pginas casi siempre ha surgido de problemas reales que noshemos vistos obligados a enfrentar en conjunto. A veces la solucin ha sido nuestra,pero muchas otras nos han salvado la vida tantas personas que nos sera imposibleintentar mencionarlas a todas. Y estn los cientos de programadores que, a travs delcorreo electrnico, nos han animado a seguir adelante. Pero la principal fuerza que hamovido este proyecto ha sido Dave. Sin l, este libro no estara ahora en sus manos.

Como no me gusta ponerme solemne, quiero concluir agradeciendo a Dios, al Dia-blo o a la Seleccin Natural (no estoy seguro), por haberme colocado en el crneoesa neurona sarcstica que impide que tome en serio a algo o a alguien, incluyn-dome a m mismo. El da que me falle ... quizs me dedique a escribir sobre la capade ozono.

Ian MarteensMadrid, Junio de 1999

El Lenguaje SQL

Sistemas de bases de datos Breve introduccin a SQL Consultas y modificaciones Procedimientos almacenados y triggers Transacciones Microsoft SQL Server Oracle DB2 Universal Database El Motor de Datos de Borland

Parte

Captulo

1Sistemas de bases de datosSistemas de bases de datos

STE ES EL MOMENTO APROPIADO para presentar a los protagonistas de estedrama: los sistemas de gestin de bases de datos con los que intentaremostrabajar. En mi trabajo de consultor, la primera pregunta que escucho, y la

ms frecuente, es en qu lenguaje debe realizarse determinado proyecto. Enfoqueequivocado. La mayora de los proyectos que llegan a mis manos son aplicacionespara redes de rea local, y os garantizo que la eleccin del lenguaje es asunto relati-vamente secundario para el xito de las mismas; por supuesto, siempre recomiendoalgn lenguaje decente, sin limitaciones intrnsecas, como C++ Builder o Delphi.La primera pregunta debera ser: qu sistema de bases de datos es el ms apropiadoa mis necesidades?

En este captulo recordaremos los principios bsicos de los sistemas de bases dedatos relacionales, y haremos una rpida introduccin a algunos sistemas concretoscon los que C++ Builder puede trabajar de modo directo. La explicacin relativa alos sistemas de bases de datos locales ser ms detallada que la de los sistemascliente/servidor, pues las caractersticas de estos ltimos (implementacin de ndices,integridad referencial, seguridad) irn siendo desveladas a lo largo del libro.

Acerca del acceso transparente a bases de datosPero acaso C++ Builder no ofrece cierta transparencia con respecto al formato delos datos con los que estamos trabajando? Pues s, sobre todo para los formatossoportados por el Motor de Bases de Datos de Borland (BDE), que estudiaremos enel captulo correspondiente. Sin embargo, esta transparencia no es total, incluso den-tro de las bases de datos accesibles mediante el BDE. Hay una primera gran divisinentre las bases de datos locales y los denominados sistemas SQL. Luego vienen lasdistintas posibilidades expresivas de los formatos; incluso las bases de datos SQL,que son las ms parecidas entre s, se diferencian en las operaciones que permiten ono. Si usted est dispuesto a utilizar el mnimo comn denominador entre todas ellas,su aplicacin puede que funcione sin incidentes sobre determinado rango de posiblessistemas ... pero le aseguro que del mismo modo desperdiciar recursos de progra-

E


macin y diseo que le habran permitido terminar mucho antes la aplicacin, y questa se ejecutara ms eficientemente.

Bases de datos relacionalesPor supuesto, estimado amigo, todos los sistemas de bases de datos con los que va-mos a trabajar en C++ Builder sern sistemas relacionales. Por desgracia. Cmo quepor desgracia, hereje insensato? Para saber qu nos estamos perdiendo con los siste-mas relacionales tendramos que conocer las alternativas. Necesitaremos, lo lamento,un poco de vieja Historia.

En el principio no haba ordenadores, claro est. Pero cuando los hubo, y despus delargos aos de almacenar informacin plana en grandes cintas magnticas o perfo-radas, los informticos comenzaron a organizar sus datos en dos tipos de modelos: elmodelo jerrquico y el modelo de redes. El modelo jerrquico era un invento dignode un oficial prusiano. Los diferentes tipos de informacin se clasificaban en formade rbol. En determinada base de datos, por ejemplo, la raz de este rbol eran losregistros de empresas. Cada empresa almacenara los datos de un conjunto de de-partamentos, estos ltimos seran responsables de guardar los datos de sus emplea-dos, y as sucesivamente. Adems del conjunto de departamentos, una empresa po-dra ser propietaria de otro conjunto de registros, como bienes inmuebles o algo as.El problema, como es fcil de imaginar, es que el mundo real no se adapta fcilmentea este tipo de organizacin. Por lo tanto, a este modelo de datos se le aaden chapu-zas tales como registros virtuales que son, en el fondo, una forma primitiva depunteros entre registros.

El modelo de redes era ms flexible. Un registro poda contener un conjunto deotros registros. Y cada uno de estos registros poda pertenecer a ms de un conjunto.La implementacin ms frecuente de esta caracterstica se realizaba mediante punte-ros. El sistema ms famoso que segua este modelo, curiosamente, fue comprado porcierta compaa tristemente conocida por hacerse con sistemas de bases de datospara convertirlos en historia... No, no es esa Compaa en la que estis pensando... s,esa Otra...

Vale, el modelo jerrquico no era muy completo, pero el modelo de redes era razo-nablemente bueno. Qu pas con ellos, entonces? Por qu se extinguieron en elJursico? Bsicamente, porque eran sistemas navegacionales. Para obtener cualquierinformacin haba que tener una idea muy clara de cmo estaban organizados losdatos. Pero lo ms molesto era que no existan herramientas sencillas que permitieranrealizar consultas arbitrarias en una base de datos. Si el presidente de la compaaquera saber cuntos clientes del rea del Pacfico beban Coca-Cola a las cinco de latarde en vez de t, tena que llamar al programador para que le desarrollara una pe-quea aplicacin.

Sistemas de bases de datos 25

Entonces apareci Mr. Codd, un matemtico de IBM. No invent el concepto deregistro, que ya exista haca tiempo. Pero se dio cuenta que si obligaba a que todoslos campos de los registros fueran campos simples (es decir, que no fueran punteros,vectores o subregistros) poda disearse un grcil sistema matemtico que permitadescomponer informacin acerca de objetos complejos en estos registros planos, conla seguridad de poder restaurar la informacin original ms adelante, con la ayuda deoperaciones algebraicas. Lo ms importante: casi cualquier tipo de informacin podadescomponerse de este modo, as que el modelo era lo suficientemente general. A lateora matemtica que desarroll se le conoce con el nombre de lgebra relacional, y esla base de nuestro conocido lenguaje SQL y del quizs menos popular Query By Ex-ample, o QBE. De este modo, el directivo del prrafo anterior poda sentarse frente auna consola, teclear un par de instrucciones en SQL y ahorrarse el pago de las horasextras del programador2.

Tomemos como ejemplo una base de datos que almacene datos acerca de Departa-mentos y sus Empleados. Los modelos jerrquicos y de redes la representaran conun diagrama similar al siguiente:

Departamentos

Empleados

Investigacin &Desarrollo

Ventas

A. Einstein P. Dirac Nelson R. Alfred C.H. Ford

$1.000.000$10.000

Como puede verse, los punteros son parte ineludible del modelo. Hay algn mate-mtico que sepa cmo comportarse frente a un puntero? Al parecer, no los haba enlos 60 y 70. Sin embargo, los datos anteriores pueden expresarse, en el modelo rela-cional, mediante dos conjuntos uniformes de registros y sin utilizar punteros, al me-nos de forma explcita. De esta manera, es factible analizar matemticamente losdatos, y efectuar operaciones algebraicas sobre los mismos:

DEPARTAMENTOS EMPLEADOSCodigo Nombre Presupuesto Dpto Nombre

I+D Investigacin y Desarrollo $10.000 I+D A. EinsteinV Ventas $1.000.000 I+D P. Dirac

V Nelson R.V Henri F.V Alfred C.

Mira, mam, sin punteros! Departamentos y Empleados son tablas, aunque matemtica-mente se les denomina relaciones. A los registros de estas tablas se les llama filas, para 2 Aunque personalmente no conozco a ningn individuo con alfiler de corbata y BMW quesepa SQL, no cabe duda de que debe existir alguno por ah.


hacer rabiar a los matemticos que les llaman tuplas. Y para no desentonar, Codigo,Nombre y Presupuesto son columnas para unos, mientras que para los otros son campos.Qu ms da! Ah, la coleccin de tablas o relaciones es lo que se conoce como base dedatos.

Las personas inteligentes (como usted y como yo) se dan cuenta enseguida de que enrealidad no hemos eliminado los punteros, sino que los hemos disfrazado. Existe unvnculo3 entre los campos Cdigo y Dpto que es el sustituto de los punteros. Perocuando se representan los datos de esta manera, es ms fcil operar con ellos mate-mticamente. Note, por ejemplo, que para ilustrar los modelos anteriores necesit undibujo, mientras que una vulgar tabla de mi procesador de texto me ha bastado en elsegundo caso. Bueno, en realidad han sido dos tablas.

Me deja el lector que resuma en un par de frases lo que lograba Codd con su mo-delo relacional? Codd apuntaba su pistola de rayos desintegradores a cualquier objetoque se pona a tiro, incluyendo a su perro, y lo reduca a cenizas atmicas. Despus,con un elegante par de operaciones matemticas, poda resucitar al animalito, si antesel viento no barra sus restos de la alfombra.

Informacin semntica = restriccionesTodo lo que he escrito antes le puede sonar al lector como un disco rayado de tantoescucharlo. Sin embargo, gran parte de los programadores que se inician en C++Builder solamente han llegado a asimilar esta parte bsica del modelo relacional, ypresentan lagunas aterradoras en el resto de las caractersticas del modelo, comoveremos dentro de poco. Qu le falta a las ideas anteriores para que sean completa-mente prcticas y funcionales? Esencialmente, informacin semntica: algo que nosimpida o haga improbable colocar la cabeza del perro donde va la cola, o viceversa(el perro de una vecina ma da esa impresin).

Casi siempre, esta informacin semntica se expresa mediante restricciones a losvalores que pueden tomar los datos de una tabla. Las restricciones ms sencillas tie-nen que ver con el tipo de valores que puede albergar una columna. Por ejemplo, lacolumna Presupuesto solamente admite valores enteros. Pero no cualquier valor entero:tienen que ser valores positivos. A este tipo de verificaciones se les conoce comorestricciones de dominio.

El nivel siguiente lo conforman las restricciones que pueden verificarse analizandolos valores de cada fila de forma independiente. Estas no tienen un nombre especial.

3 Observe con qu exquisito cuidado he evitado aqu la palabra relacin. En ingls existen dospalabras diferentes: relation y relationship. Pero el equivalente ms cercano a esta ltima seraalgo as como relacionalidad, y eso suena peor que un prrafo del BOE.


En el ejemplo de los departamentos y los empleados, tal como lo hemos presentado,no hay restricciones de este tipo. Pero nos podemos inventar una, que deben satisfa-cer los registros de empleados:

Dpto "I+D" or Especialidad "Psiquiatra"

Es decir, que no pueden trabajar psiquiatras en Investigacin y Desarrollo (termina-ran igual de locos). Lo ms importante de todo lo que he explicado en esta seccines que las restricciones ms sencillas pueden expresarse mediante elegantes frmulasmatemticas que utilizan los nombres de las columnas, o campos, como variables.

Restricciones de unicidad y claves primariasLos tipos de restricciones siguen complicndose. Ahora se trata de realizar verifica-ciones que afectan los valores almacenados en varias filas. Las ms importantes deestas validaciones son las denominadas restricciones de unicidad. Son muy fciles de ex-plicar en la teora. Por ejemplo, no pueden haber dos filas en la tabla de departa-mentos con el mismo valor en la columna Codigo. Abusando del lenguaje, se dice quela columna Codigo es nica.

En el caso de la tabla de departamentos, resulta que tambin existe una restriccin deunicidad sobre la columna Nombre. Y no pasa nada. Sin embargo, quiero que el lectorpueda distinguir sin problemas entre estas dos diferentes situaciones:

1. (Situacin real) Hay una restriccin de unicidad sobre Codigo y otra restriccin deunicidad sobre Nombre.

2. (Situacin ficticia) Hay una restriccin de unicidad sobre la combinacin de co-lumnas Codigo y Nombre.

Esta segunda restriccin posible es ms relajada que la combinacin real de dos res-tricciones (comprubelo). La unicidad de una combinacin de columnas puede vi-sualizarse de manera sencilla: si se recortan de la tabla las columnas que no partici-pan en la restriccin, no deben quedar registros duplicados despus de esta opera-cin. Por ejemplo, en la tabla de empleados, la combinacin Dpto y Nombre es nica.

La mayora de los sistemas de bases de datos se apoyan en ndices para hacer cumplirlas restricciones de unicidad. Estos ndices se crean automticamente tomando comobase a la columna o combinacin de columnas que deben satisfacer estas condicio-nes. Antes de insertar un nuevo registro, y antes de modificar una columna de estetipo, se busca dentro del ndice correspondiente para ver si se va a generar un valorduplicado. En tal caso se aborta la operacin.


As que una tabla puede tener una o varias restricciones de unicidad (o ninguna).Escoja una de ellas y desgnela como clave primaria. Cmo, de forma arbitraria? Casi:se supone que la clave primaria identifica unvocamente y de forma algo misteriosa lams recndita esencia de los registros de una tabla. Pero para esto vale lo mismocualquier otra restriccin de unicidad, y en programacin no vale recurrir al misti-cismo. Hay quienes justifican la eleccin de la clave primaria entre todas las restric-ciones de unicidad en relacin con la integridad referencial, que estudiaremos en laprxima seccin. Esto tampoco es una justificacin, como veremos en breve. Endefinitiva, que todas las restricciones de unicidad son iguales, aunque algunas sonms iguales que otras.

Quiere saber la verdad? He jugado con trampa en el prrafo anterior. Esa esenciamisteriosa del registro no es ms que un mecanismo utilizado por el modelo relacio-nal para sustituir a los desterrados punteros. Podris llamarlo identidad del registro, ocualquier otro nombre rimbombante, pero no es ms que una forma de disfrazar unpuntero, y muy poco eficiente, por cierto. Observe la tabla de departamentos: entreel cdigo y el nombre, cul columna elegira como clave primaria? Por supuesto queel cdigo, pues es el tipo de datos que menos espacio ocupa, y cuando tengamos elcdigo en la mano podremos localizar el registro de forma ms rpida que cuandotengamos el nombre.

De todos modos, hay alguien que aprovecha inteligentemente la existencia de clavesprimarias: el Motor de Datos de Borland. De hecho, estas claves primarias son laforma en que el Motor de Datos puede simular el concepto de registro activo en unatabla SQL. Pero tendremos que esperar un poco para desentraar este ingeniosomecanismo.

Integridad referencialEste tipo de restriccin es an ms complicada, y se presenta en la columna Dpto dela tabla de empleados. Es evidente que todos los valores de esta columna deben co-rresponder a valores almacenados en la columna Codigo de la tabla de departamentos.Siguiendo mi teora de la conspiracin de los punteros encubiertos, esto equivale aque cada registro de empleado tenga un puntero a un registro de departamento.

Un poco de terminologa: a estas restricciones se les denomina integridad referencial, oreferential integrity. Tambin se dice que la columna Dpto de Empleados es una clave ex-terna de esta tabla, o foreign key, en el idioma de Henry Morgan. Podemos llamar tabladependiente, o tabla de detalles, a la tabla que contiene la clave externa, y tablamaestra a la otra. En el ejemplo que consideramos, la clave externa consiste en unasola columna, pero en el caso general podemos tener claves externas compuestas.


Como es fcil de ver, las columnas de la tabla maestra a las que se hace referencia enuna integridad referencial deben satisfacer una restriccin de unicidad. En la teoraoriginal, estas columnas deberan ser la clave primaria, pero la mayora de los siste-mas relacionales actuales admiten cualquiera de las combinaciones de columnas ni-cas definidas.

Cuando se establece una relacin de integridad referencial, la tabla dependienteasume responsabilidades:

No se puede insertar una nueva fila con un valor en las columnas de la claveexterna que no se encuentre en la tabla maestra.

No se puede modificar la clave externa en una fila existente con un valor que noexista en la tabla maestra.

Pero tambin la tabla maestra tiene su parte de responsabilidad en el contrato, que semanifiesta cuando alguien intenta eliminar una de sus filas, o modificar el valor de suclave primaria. En las modificaciones, en general, pueden desearse dos tipos diferen-tes de comportamiento:

Se prohibe la modificacin de la clave primaria de un registro que tenga filas dedetalles asociadas.

Alternativamente, la modificacin de la clave se propaga a las tablas depen-dientes.

Si se trata de un borrado, son tres los comportamientos posibles:

Prohibir el borrado, si existen filas dependientes del registro. Borrar tambin las filas dependientes. Permitir el borrado y, en vez de borrar las filas dependientes, romper el vnculo

asociando a la clave externa un valor por omisin, que en SQL casi siempre es elvalor nulo (ver el siguiente captulo).

La forma ms directa de implementar las verificaciones de integridad referencial esutilizar ndices. Las responsabilidades de la tabla dependiente se resuelven compro-bando la existencia del valor a insertar o a modificar en el ndice asociado a la restric-cin de unicidad definida en la tabla maestra. Las responsabilidades de la tabla maes-tra se resuelven generalmente mediante ndices definidos sobre la tabla de detalles.

Qu tiene de malo el modelo relacional?El modelo relacional funciona. Adems, funciona razonablemente bien. Pero comohe tratado de explicar a lo largo de las secciones anteriores, en determinados aspectos


significa un retroceso en comparacin con modelos de datos anteriores. Me refiero alo artificioso del proceso de eliminar los punteros implcitos de forma natural en elmodelo semntico a representar. Esto se refleja tambin en la eficiencia de las opera-ciones. Supongamos que tenemos un registro de empleado en nuestras manos y que-remos saber el nombre del departamento al que pertenece. Bien, pues tenemos quebuscar el cdigo de departamento dentro de un ndice para despus localizar fsica-mente el registro del departamento correspondiente y leer su nombre. Al menos, unpar de accesos al disco duro. Compare con la sencillez de buscar directamente elregistro de departamento dado su puntero (existen implementaciones eficientes delconcepto de puntero cuando se trabaja con datos persistentes).

En este momento, las investigaciones de vanguardia se centran en las bases de datosorientadas a objetos, que retoman algunos conceptos del modelo de redes y del pro-pio modelo relacional. Desde la dcada de los 70, la investigacin matemtica haavanzado lo suficiente como para disponer de potentes lenguajes de interrogacinsobre bases de datos arbitrarias. No quiero entrar a analizar el porqu no se ha aca-bado de imponer el modelo orientado a objetos sobre el relacional, pues en estoinfluyen tanto factores tcnicos como comerciales. Pero es bueno que el lector sepaqu puede pasar en un futuro cercano.

Es sumamente significativo que la principal ventaja del modelo relacional, la posibili-dad de realizar consultas ad hoc estuviera fuera del alcance del modelo relacionalms popular a lo largo de los ochenta: dBase, y sus secuelas Clipper y FoxPro.Cuando escucho elogios sobre Clipper por parte de programadores que hicieroncarrera con este lenguaje, pienso con tristeza que los elogios los merecen los propiosprogramadores que pudieron realizar software funcional con herramientas tan primi-tivas. Mi aplauso para ellos; en ningn caso para el lenguaje. Y mi consejo de queabandonen el viejo buque (y las malas costumbres aprendidas durante la travesa)antes de que termine de hundirse.

Ilustracin 1 El perro de Codd


Y a todas estas, qu pas con la mascota de Mr. Codd? Lo inevitable: muri comoconsecuencia de un experimento fallido. Sin embargo, Brahma se apiad de l, yreencarn al ao en un chico que, con el tiempo, se ha convertido en un exitoso pro-gramador afincado en el sur de la Florida. Al verlo, nadie pensara que fue un perroen su vida anterior, de no ser por la mana que tiene de rascarse peridicamente laoreja. No obstante, por haber destrozado la tapicera del sof de su dueo y orinarseun par de veces en la alfombra del saln, fue condenado a programar dos largos aosen Visual Basic, hasta que C++ Builder (o fue Delphi?) lleg a su vida y se convirtien un hombre feliz.

Bases de datos locales y servidores SQLBasta ya de teora, y veamos los ingredientes con que contamos para cocinar apli-caciones de bases de datos. La primera gran divisin entre los sistemas de bases dedatos existentes se produce entre los sistemas locales, o de escritorio, y las bases dedatos SQL, o cliente/servidor.

A los sistemas de bases de datos locales se les llama de este modo porque comenza-ron su existencia como soluciones baratas para un solo usuario, ejecutndose en unsolo ordenador. Sin embargo, no es un nombre muy apropiado, porque ms adelanteestos sistemas crecieron para permitir su explotacin en red. Tampoco es adecuadoclasificarlas como lo que queda despus de quitar las bases de datos SQL. Es ciertoque en sus inicios ninguna de estas bases de datos soportaba un lenguaje de consultasdecente, pero esta situacin tambin ha cambiado.

En definitiva, cul es la esencia de las bases de datos de escritorio? Pues el hecho deque la programacin usual con las mismas se realiza en una sola capa. Todos estossistemas utilizan como interfaz de aplicaciones un motor de datos que, en la era de lasupremaca de Windows, se implementa como una DLL. En la poca de MS-DOS,en cambio, eran funciones que se enlazaban estticamente dentro del ejecutable.Observe el siguiente diagrama, que representa el uso en red de una base de datos deescritorio:

BDE BDE

Aplicacin Aplicacin

Base deDatos


Aunque la segunda burbuja dice BDE, el Motor de Datos de Borland, sustituyaestas siglas por DAO, y podr aplicar el diagrama a Access. He representado la apli-cacin y el motor de datos en dos burbujas separadas, pero en realidad, constituyenun mismo ejecutable. Lo ms importante, sin embargo, es que no existe un softwarecentral que sirva de rbitro para el acceso a la base de datos fsica. Es como si lasdos aplicaciones deambularan a ciegas en un cuarto oscuro, tratando de sentarse enalgn sitio libre. Por supuesto, la nica forma que tienen de saberlo es intentar ha-cerlo y confiar en que no haya nadie debajo.

Debido a esta forma primitiva de resolver las inevitables colisiones, la implementa-cin de la concurrencia, las transacciones y, en ltimo trmino, la recuperacin des-pus de fallos, ha sido tradicionalmente el punto dbil de las bases de datos de escri-torio. Si est pensando en decenas o cientos de usuarios atacando simultneamente asus datos, y en ejrcitos de extremidades inferiores listas para tropezar con cables,olvdese de Paradox, dBase y Access, pues necesitar una base de datoscliente/servidor.

Las bases de datos cliente/servidor, o bases de datos SQL, se caracterizan por utili-zar al menos dos capas de software, como se aprecia en el siguiente diagrama:

Cliente SQL Cliente SQL

Aplicacin Aplicacin

Base deDatos

Servidor SQL

El par aplicacin + motor local de datos ya no tiene acceso directo a los ficheros dela base de datos, pues hay un nuevo actor en el drama: el servidor SQL. He cambiadoel rtulo de la burbuja del motor de datos, y ahora dice cliente SQL. Esta es unadenominacin genrica. Para las aplicaciones desarrolladas con C++ Builder y elMotor de Datos de Borland, este cliente consiste en la combinacin del BDE pro-piamente dicho ms alguna biblioteca dinmica o DLL suministrada por el fabricantede la base de datos. En cualquier caso, todas estas bibliotecas se funden junto a laaplicacin dentro de una misma capa de software, compartiendo el mismo espacio dememoria y procesamiento.

La divisin entre bases de datos de escritorio y las bases de datos SQL no es unaclasificacin tajante, pues se basa en la combinacin de una serie de caractersticas.


Puede que uno de estos das aparezca un sistema que mezcle de otra forma estos ras-gos definitorios.

Caractersticas generales de los sistemas SQLEl hecho de que exista un rbitro en las aplicaciones cliente/servidor hace posibleimplementar una gran variedad de tcnicas y recursos que estn ausentes en la mayo-ra de los sistemas de bases de datos de escritorio. Por ejemplo, el control de concu-rrencia se hace ms sencillo y fiable, pues el servidor puede llevar la cuenta de quclientes estn accediendo a qu registros durante todo el tiempo. Tambin es msfcil implementar transacciones atmicas, esto es, agrupar operaciones de modifi-cacin de forma tal que, o se efecten todas, o ninguna llegue a tener efecto.

Pero una de las principales caractersticas de las bases de datos con las que vamos atrabajar es la forma peculiar en que conversan los clientes con el servidor. Resultaque estas conversaciones tienen lugar en forma de peticin de ejecucin de coman-dos del lenguaje SQL. De aqu el nombre comn que reciben estos sistemas. Supon-gamos que un ordenador necesita leer la tabla de inventario. Recuerde que ahora nopodemos abrir directamente un fichero situado en el servidor. Lo que realmente hacela estacin de trabajo es pedirle al servidor que ejecute la siguiente instruccin SQL:

select * from Inventario order by CodigoProducto asc

El servidor calcula qu registros pertenecen al resultado de la consulta, y todo esteclculo tiene lugar en la mquina que alberga al propio servidor. Entonces, cada vezque el usuario de la estacin de trabajo se mueve de registro a registro, el cliente SQLpide a su servidor el siguiente registro mediante la siguiente instruccin:

fetch

Ms adelante necesitaremos estudiar cmo se realizan las modificaciones, inserciones,borrados y bsquedas, pero con esto basta por el momento. Hay una conclusinimportante a la que ya podemos llegar: qu es ms rpido, pulsar un botn en lamquina de bebidas o mandar a un aclito a que vaya por una Coca-Cola? A no serque usted sea ms vago que yo, preferir la primera opcin. Bien, pues un sistemaSQL es inherentemente ms lento que una base de datos local. Antes manipulba-mos directamente un fichero. Ahora tenemos que pedrselo a alguien, con un proto-colo y con reglas de cortesa. Ese alguien tiene que entender nuestra peticin, esdecir, compilar la instruccin. Luego debe ejecutarla y solamente entonces procedera enviarnos el primer registro a travs de la red. Est de acuerdo conmigo?

No pasa una semana sin que conozca a alguien que ha desarrollado una aplicacinpara bases de datos locales, haya decidido pasarla a un entorno SQL, y haya pensado


que con un par de modificaciones en su aplicacin era suficiente. Entonces descubreque la aplicacin se ejecuta con mayor lentitud que antes, cae de rodillas, mira al cieloy clama: dnde est entonces la ventaja de trabajar con sistemas cliente/servidor?Est, amigo mo, en la posibilidad de meter cdigo en el servidor, y si fallamos enhacerlo estaremos desaprovechando las mejores dotes de nuestra base de datos.

Hay dos formas principales de hacerlo: mediante procedimientos almacenados ymediante triggers. Los primeros son conjuntos de instrucciones que se almacenandentro de la propia base de datos. Se activan mediante una peticin explcita de uncliente, pero se ejecutan en el espacio de aplicacin del servidor. Por descontado,estos procedimientos no deben incluir instrucciones de entrada y salida. Cualquierproceso en lote que no contenga este tipo de instrucciones es candidato a codificarsecomo un procedimiento almacenado. La ventaja?, que evitamos que los registrosprocesados por el procedimiento tengan que atravesar la barrera del espacio de me-moria del servidor y viajar a travs de la red hasta el cliente.

Los triggers son tambin secuencias de instrucciones, pero en vez de ser activadosexplcitamente, se ejecutan como preludio y coda de las tres operaciones bsicas deactualizacin de SQL: update, insert y delete. No importa la forma en que estastres operaciones se ejecuten, si es a instancias de una aplicacin o mediante algunaherramienta incluida en el propio sistema; los triggers que se hayan programado seactivarn en cualquier caso.

Estos recursos se estudiarn ms adelante, cuando exploremos el lenguaje SQL.

El formato ParadoxComenzaremos nuestra aventura explicando algunas caractersticas de los sistemas debases de datos de escritorio que pueden utilizarse directamente con C++ Builder. Deestos, mi actual favorito es Paradox. Pongo el adjetivo actual porque el nuevo for-mato de Visual dBase VII comienza a aproximarse a la riqueza expresiva soportadadesde hace mucho por Paradox. Dedicaremos a dBase la siguiente seccin.

Paradox no reconoce directamente el concepto de base de datos, sino que administratablas en ficheros independientes. Cada tabla se almacena en un conjunto de ficheros,todos con el mismo nombre, pero con las extensiones que explicamos a continua-cin:

Extensin Explicacin.db Definicin de la tabla y campos de longitud mxima fija.mb Campos de longitud variable, como los memos y grficos.px El ndice de la clave primaria


Extensin Explicacin.Xnn, .Ynn Indices secundarios.val Validaciones e integridad referencial

En el fichero .db se almacena una cabecera con la descripcin de la tabla, adems delos datos de los registros que corresponden a campos de longitud fija. Este ficheroest estructurado en bloques de idntico tamao; se pueden definir bloques de 1, 2,4, 8, 16 y 32KB. El tamao de bloque se determina durante la creacin de la tablamediante el parmetro BLOCK SIZE del controlador de Paradox del BDE (por omi-sin, 2048 bytes); en el captulo 16 aprenderemos a gestionar ste y muchos otrosparmetros. El tamao de bloque influye en la extensin mxima de la tabla, puesParadox solamente permite 216 bloques por fichero. Si se utiliza el tamao de bloquepor omisin tendramos el siguiente tamao mximo por fichero de datos:

2048 65536 = 2 11 2 16 = 2 27 = 2 7 2 20 = 128MB

Un registro debe caber completamente dentro de un bloque, y si la tabla tiene unaclave primaria (recomendable!) deben existir al menos tres registros por bloque; estose refiere a los datos de longitud fija del registro, excluyendo campos de texto largos,de imgenes y binarios. Dentro de cada bloque, los registros se ordenan segn suclave primaria, para agilizar la bsqueda una vez que el bloque ha sido ledo en lacach. Un registro, adems, siempre ocupa el mismo espacio dentro del fichero .db,incluso si contiene campos alfanumricos que, a diferencia de lo que sucede endBase, no se rellenan con blancos hasta ocupar el ancho total del campo.

Paradox permite trabajar con un ndice primario por cada tabla y con varios ndicessecundarios. Todos estos ndices pueden ser mantenidos automticamente por elsistema, aunque existe la posibilidad de crear ndices secundarios no mantenidos. Elndice primario de la tabla se almacena en el fichero de extensin .px. No es necesa-rio que una tabla tenga ndice primario, pero es altamente ventajoso. Al estar ordena-dos los registros dentro los bloques de datos, slo se necesita almacenar en el ndicela clave del primer registro de cada bloque. Esto disminuye considerablemente losrequerimientos de espacio del ndice, y acelera las bsquedas.

Es interesante conocer cmo Paradox implementa los ndices secundarios. En reali-dad, cada ndice secundario es internamente una tabla, con su propio fichero de da-tos, de extensin .Xnn, y su ndice asociado .Ynn. La numeracin de los ndices sigueun esquema sencillo: los dos ltimos caracteres de la extensin indican el nmero delcampo en hexadecimal, si es un ndice sobre un solo campo. Si es un ndice com-puesto, se utiliza una pseudo numeracin hexadecimal, pero comenzando desde elvalor G0 y progresando en forma secuencial. Desde el punto de vista del usuario,los ndices secundarios tienen un nombre asociado. El ndice primario, en cambio, notiene nombre.


Se permite el uso directo de ndices con claves compuestas, formadas por varioscampos. Otras opciones posibles de un ndice Paradox son ignorar las maysculas yminsculas en los campos de cadenas (la opcin por omisin), la restriccin de clavesnicas y la posibilidad de ordenacin en sentido descendente.

Paradox permite la definicin de relaciones de integridad referencial. La siguienteimagen muestra el dilogo de Database Desktop que lo hace posible:

El motor de datos crea automticamente un ndice secundario sobre las columnas dela tabla dependiente que participan en una restriccin de integridad. Si la restriccinest basada en una sola columna, el ndice recibe el nombre de la misma. La tabla queincluyo a continuacin describe la implementacin en Paradox del comportamientode la integridad referencial respecto a actualizaciones en la tabla maestra:

Borrados ModificacionesProhibir la operacin S S

Propagar en cascada No SAsignar valor por omisin No -

No se permiten los borrados en cascada. No obstante, este no es un impedimentosignificativo, pues dichos borrados pueden implementarse fcilmente en las aplica-ciones clientes. En cambio, trate el lector de implementar una propagacin en cas-cada de un cambio de clave cuando existe una integridad referencial...

No fue hasta la aparicin de la versin 3.0 del BDE, que acompa a Delphi 2, queParadox y dBase contaron con algn tipo de soporte para transacciones. No obs-tante, este soporte es actualmente muy elemental. Utiliza un undo log, es decir, unfichero en el que se van grabando las operaciones que deben deshacerse. Si se desco-necta la mquina durante una de estas transacciones, los cambios aplicados a mediasquedan grabados, y actualmente no hay forma de deshacerlos. La independenciaentre transacciones lanzadas por diferentes procesos es la mnima posible, pues un


proceso puede ver los cambios efectuados por otro proceso aunque ste no hayaconfirmado an toda la transaccin.

Finalmente, las transacciones locales tienen una limitacin importante. La contencinentre procesos est implementada mediante bloqueos. Actualmente Paradox permitehasta 255 bloqueos por tabla, y dBase solamente 100. De modo que una transaccinen Paradox puede modificar directamente un mximo de 255 registros por tabla.

El formato DBF7Quin no ha tenido que trabajar, en algn momento y de una forma u otra, con losconocidos ficheros DBF? La popularidad de este formato se desarroll en paralelocon la aparicin de los PCs y la propagacin de MS-DOS. En el principio, era pro-piedad de una compaa llamada Ashton-Tate. Ashton fue el empresario que comprel software a su desarrollador, y tena un loro llamado Tate, o era al revs? Despusa esta empresa le fueron mal las cosas y Borland adquiri sus productos. Aunquemuchos interpretaron esta accin como un reconocimiento a los mritos tcnicosde dBase, se trataba en realidad de adquirir otro producto de bases de datos, que enaquel momento era un perfecto desconocido: InterBase. Hay que advertir que Inter-Base haba sido a su vez comprado por Ashton-Tate a sus desarrolladores originales,una efmera compaa de nombre Groton Database Systems, cuyas siglas an perdu-ran en la extensin por omisin de los ficheros de InterBase: gdb.

El formato DBF es muy sencillo ... y muy malo. Fue diseado como la base de da-tos de los pobres. Cada tabla, al igual que sucede en Paradox, se representa en unconjunto de ficheros. El fichero de extensin dbf contiene a la vez la descripcin delos campos y los registros, estos ltimos de longitud fija. Los registros se almacenande forma secuencial, sin importar las fronteras de bloques y la prdida de eficienciaque esto causa. Los tipos de datos originales se representaban en formato ASCIIlegible, en vez de utilizar su codificacin binaria, ms compacta. De este modo, lasfechas se representaban en ocho caracteres, con el formato AAAAMMDD, y unvalor entero de 16 bits ocupaba 40 bits, o 48 si se representaba el signo. Por otraparte, hasta fechas recientes el nico tipo de cadena implementado tena longitud fija,obligando a los programadores a usar exhaustivamente la funcin Trim.

Se pueden utilizar campos de longitud variable, que en principio estuvieron limitadosal tipo texto, o memo. Los valores de estos campos se almacenan en un fichero para-lelo de extensin dbt. En este fichero los datos s respetan la frontera de bloque. Poromisin, el tamao de estos bloques es de 1024 bytes, pero este parmetro es confi-gurable. Los ndices, por su parte, se almacenan todos en un fichero de extensinmdx. Aunque, en principio, una tabla puede tener varios ficheros mdx asociados, so-lamente los ndices que se encuentran en el fichero que tiene el mismo nombre que la


tabla se actualizan automticamente, por lo que en la prctica solamente cuenta estefichero, denominado ndice de produccin.

Una de las peculiaridades de dBase es la forma en que se implementan los ndicessobre varias columnas. dBase no tiene ndices compuestos, al estilo de Paradox y delos sistemas SQL. Como alternativa ofrece los ndices basados en expresiones: siqueremos un ndice compuesto por las columnas Nombre y Apellidos, tenemos quedefinir un ndice por la expresin Nombre+Apellidos. Puede parecer que sta es unaopcin muy potente, pero en la prctica el uso de los ndices sobre expresiones sereduce a sustituir los ndices compuestos de otros sistemas. Adems, veremos quetrabajar con estos ndices en C++ Builder es bastante penoso. Claves primarias,integridad referencial? Nada de eso tena originalmente el formato DBF. Cuesta mstrabajo redisear una aplicacin escrita en C++ Builder con dBase para que se eje-cute en un sistema cliente/servidor que si hubiera sido desarrollada para Paradox.

Algo a favor de este formato? Las dos cualidades que mencionar son consecuenciade la simplicidad de sus ficheros. En primer lugar, las operaciones de actualizacinson un poco ms rpidas en dBase que en Paradox. Y, lo ms importante, al existirmenos cosas para romperse, hay ms estabilidad en este formato y ms toleranciarespecto a fallos en el sistema operativo.

Con la aparicin de Visual dBase 7 junto a la versin 4.50 del BDE, el formato DBFfue renovado en gran medida. Una de las novedades ms importantes es la incorpo-racin de relaciones de integridad referencial, que incluyen los borrados en cascada,como se muestra en el siguiente cuadro de dilogo del Administrador de Bases deDatos de Visual dBase 7:

Tambin se han aadido tipos de datos representados en forma binaria, condicionesde verificacin, que consisten en expresiones lgicas que deben satisfacer siempre lasfilas de una tabla, valores por omisin, etc. Lamentablemente, seguimos con los ndi-


ces de expresiones como sustitutos de los ndices compuestos, y el lmite de registrosmodificados por transaccin sigue siendo 100.

Criterios para evaluar un servidor SQLCmo saber cul es el sistema de bases de datos cliente/servidor ms adecuado paranuestros objetivos? En esta seccin trato de establecer criterios de comparacin paraestos sistemas. No hay dos aplicaciones con las mismas necesidades, as que el hechode que un sistema no ofrezca determinada opcin no lo invalida como la solucinque usted necesita. Recuerde que no siempre ms es mejor.

Plataformas soportadasEn qu sistema operativo debe ejecutarse el servidor? La respuesta es impor-tante por dos razones. La primera: nos da una medida de la flexibilidad que te-nemos a la hora de seleccionar una configuracin de la red. Si vamos a instalaruna aplicacin en una empresa que tiene toda su red basada en determinado ser-vidor con determinado protocolo, no es recomendable que abandonen todo loque tienen hecho para que el recin llegado pueda ejecutarse.En segundo lugar, no todos los sistemas operativos se comportan igual de efi-cientes actuando como servidores de bases de datos. Esto tiene que ver sobretodo con la implementacin que realiza el SO de la concurrencia. Mi favorito eneste sentido es UNIX: un InterBase, un Oracle, un Informix, ejecutndose sobrecualquier sabor de UNIX (HP-UX, AIX, Solaris).Puede suceder, por supuesto, que el mantenimiento de la red no est en manosde un profesional dedicado a esta rea. En tal caso, hay que reconocer que esmucho ms sencillo administrar un Windows NT.

Soporte de tipos de datos y restriccionesEn realidad, casi todos los sistemas SQL actuales tienen tipos de datos que in-cluyen a los especificados en el estndar de SQL, excepto determinados casospatolgicos. De lo que se trata sobre todo es la implementacin de los mismos.Por ejemplo, no todas los formatos de bases de datos implementan con la mismaeficiencia el tipo VARCHAR, que almacena cadenas de longitud variable. Lalongitud mxima es uno de los parmetros que varan, y el formato de represen-tacin: si siempre se asigna un tamao fijo (el mximo) para estos campos, o si lalongitud total del registro puede variar.Ms importante es el soporte para validaciones declarativas, esto es, verificacio-nes para las cuales no hay que desarrollar cdigo especial. Dentro de este apar-tado entran las claves primarias, claves alternativas, relaciones de integridad refe-rencial, dominios, chequeos a nivel de fila, etc. Un elemento a tener en cuenta,por ejemplo, es si se permite o no la propagacin en cascada de modificacionesen la tabla maestra de una relacin de integridad referencial. En caso positivo,


esto puede ahorrarnos bastante cdigo en triggers y permitir mejores modelos debases de datos.

Lenguaje de triggers y procedimientos almacenadosEste es uno de los criterios a los que concedo mayor importancia. El xito deuna aplicacin, o un conjunto de aplicaciones, en un entorno C/S depende engran medida de la forma en que dividamos la carga de la aplicacin entre el ser-vidor de datos y los clientes. En este punto es donde podemos encontrar mayo-res diferencias entre los sistemas SQL, pues no hay dos dialectos de este lenguajeque sean exactamente iguales.Debemos fijarnos en si el lenguaje permite triggers a nivel de fila o de operacin,o de ambos niveles. Un trigger a nivel de fila se dispara antes o despus de modi-ficar una fila individual. Por el contrario, un trigger a nivel de operacin se disparadespus de que se ejecute una operacin completa que puede afectar a varias fi-las. Recuerde que SQL permite instrucciones como la siguiente:

delete from Clienteswhere Ciudad in ("Pompeya", "Herculano")

Si la base de datos en cuestin slo ejecuta sus triggers al terminar las operaciones,ser mucho ms complicada la programacin de los mismos, pues ms trabajocostar restablecer los valores anteriores y posteriores de cada fila particular.Tambin debe tenerse en cuenta las posibilidades de extensin del lenguaje, porejemplo, incorporando funciones definidas en otros lenguajes, o el poder utilizarservidores de automatizacin COM o CORBA, si se permiten o no llamadas re-cursivas, etc.

Implementacin de transacciones: recuperacin y aislamientoEste es mi otro criterio de anlisis preferido. Las transacciones ofrecen a las ba-ses de datos la consistencia necesaria para que operaciones parciales no priven desentido semntico a los datos almacenados. Al constituir las unidades bsicas deprocesamiento del servidor, el mecanismo que las soporta debe encargarse tam-bin de aislar a los usuarios entre s, de modo que la secuencia exacta de pasosconcurrentes que realicen no influya en el resultado final de sus acciones. Por lotanto, hay dos puntos en los que centrar la atencin: cmo se implementa laatomicidad (la forma en que el sistema deshace operaciones inconclusas), y elmtodo empleado para aislar entre s las transacciones concurrentes.

SegmentacinEs conveniente poder distribuir los datos de un servidor en distintos dispositivosfsicos. Al situar tablas en distintos discos, o segmentos de las propias tablas, po-demos aprovechar la concurrencia inherente a la existencia de varios controlado-res fsicos de estos medios de almacenamiento. Esta opcin permite, adems,


superar las restricciones impuestas por el tamao de los discos en el tamao de labase de datos.

ReplicacinUno de los usos principales de la replicacin consiste en aislar las aplicacionesque realizan mantenimientos (transacciones OLTP) de las aplicaciones para tomade decisiones (transacciones DSS). Las aplicaciones con fuerte base OLTP tien-den a modificar en cada transaccin un pequeo nmero de registros. Las aplica-ciones DSS se caracterizan por leer grandes cantidades de informacin, siendopoco probable que escriban en la base de datos. En sistemas de bases de datosque implementan el aislamiento de transacciones mediante bloqueos, ambos ti-pos de transacciones tienen una coexistencia difcil. Por lo tanto, es convenientedisponer de rplicas de la base de datos slo para lectura, y que sea a estos clonesa quienes se refieran las aplicaciones DSS.

Me da un poco de vergenza aadir el ltimo factor a la lista anterior: el precio. To-dos queremos lo mejor, pero no siempre estamos dispuestos a pagar por eso. As quemuchas veces una decisin de compra representa un balance entre la calidad y elprecio ... como en todo.

InterBaseLos antiguos griegos representaban a la Fama y a la Fortuna como caprichosas diosasque otorgaban sus favores muchas veces a quienes menos lo merecan; estos griegosde antes, la verdad, eran bastante misginos, entre otras cosas. En cualquier caso,InterBase debe haber tenido algn altercado con la seorita Fama, porque no tiene lapopularidad que merecera por sus muchas virtudes.

Una de estas virtudes es que se puede instalar el servidor en muchos sistemas opera-tivos: Windows NT y 9x, NetWare, Solaris, HP-UX, SCO, Linux... Otra es que encualquiera de estos sistemas ocupa muy poco espacio, del orden de los 10 20 MB.El mantenimiento de un servidor, una vez instalado, es tambin mnimo. Cada basede datos se sita en uno o ms ficheros, casi siempre de extensin gdb. Estos ficheroscrecen automticamente cuando hace falta ms espacio, y no hay que preocuparsepor reservar espacio adicional para registrar los cambios efectuados por las transac-ciones, como en otros sistemas. Se pueden realizar copias de seguridad de una basede datos en caliente, mientras que otros sistemas requieren que no existan usuariosactivos para efectuar esta operacin. Y la recuperacin despus de un fallo de hard-ware es sencilla e inmediata: vuelva a encender el servidor.


Tal sencillez tiene un precio, y es que actualmente InterBase no implementa directa-mente ciertas opciones avanzadas de administracin, como la segmentacin y la re-plicacin. Esta ltima debe ser implementada manualmente, por medio de triggersdefinidos por el diseador de la base de datos, y con la ayuda de un proceso en se-gundo plano que vaya grabando los datos del original a la rplica. No obstante, In-terBase permite definir directamente copias en espejo (mirrors) de una base de datos,de forma tal que existan dos copias sincronizadas de una misma base de datos endiscos duros diferentes del mismo servidor. De este modo, si se produce un fallo dehardware en uno de los discos o controladores, la explotacin de la base de datospuede continuar con la segunda copia.

En lo que atae a los tipos de datos, InterBase implementa todos los tipos del estn-dar SQL con una excepcin. Este lenguaje define tres tipos de campos para la fecha yla hora: DATE, para fechas, TIME, para horas, y TIMESTAMP para almacenarconjuntamente fechas y horas. InterBase solamente tiene DATE, pero como equiva-lente al TIMESTAMP del estndar. Esto en s no conlleva problemas, a no ser quehaya que escribir una aplicacin que acceda indistintamente a bases de datos de In-terBase y de cualquier otro sistema SQL. Pero cuando estudiemos el uso del Diccio-nario de Datos de C++ Builder, veremos cmo resolver esta nimiedad.

InterBase tiene, hoy por hoy, una de las implementaciones ms completas de lasrestricciones de integridad referencial, pues permite especificar declarativamente lapropagacin en cascada de borrados y modificaciones:


Propagar en cascada S SAsignar valor por omisin S -

Por supuesto, tenemos todas las restricciones de unicidad, claves primarias, valida-ciones a nivel de registro (clusulas check). Estas ltimas son ms potentes que en elresto de los sistemas, pues permiten realizar comprobaciones que involucren a regis-tros de otras tablas.


Los triggers de InterBase se ejecutan antes o despus de cada operacin de actualiza-cin, fila por fila, que es como Dios manda. Por otra parte, tiene un lenguaje de pro-cedimientos almacenados muy completo, que permite llamadas recursivas, y la defini-cin de procedimientos de seleccin, que devuelven ms de un registro de datos pordemanda. Todo ello se integra con un mecanismo de excepciones muy elegante, quecompagina muy bien con las tcnicas transaccionales. Es posible, adems, extender elconjunto de funciones del lenguaje mediante mdulos dinmicos, DLLs en el caso delas versiones para Windows y Windows NT.

Pero la caracterstica ms destacada de InterBase es la forma en la que logra imple-mentar el acceso concurrente a sus bases de datos garantizando que, en lo posible,cada usuario no se vea afectado por las acciones del resto. Casi todos los sistemasexistentes utilizan, de una forma u otra, bloqueos para este fin. InterBase utiliza ladenominada arquitectura multigeneracional, en la cual cada vez que una transaccin mo-difica un registro se genera una nueva versin del mismo. Tericamente, esta tcnicapermite la mayor cantidad de acciones concurrentes sobre las bases de datos. En laprctica, la implementacin de InterBase es muy eficiente y confiable. Todo esto loestudiaremos en el captulo 12, que trata acerca de las transacciones.

La ltima versin de InterBase, en el momento en que escribo estas lneas, es la 5.5, yacompaa a C++ Builder 4: en la versin Profesional con licencias para InterBaseLocal, y en la Cliente/Servidor, con licencias para un servidor sobre Windows 9x yNT.

Microsoft SQL ServerToda semejanza en la explicacin de las caractersticas de Microsoft SQL Server conlas de Sybase ser algo ms que una simple coincidencia. Realmente MS SQL Servercomenz como un derivado del servidor de Sybase, por lo que la arquitectura deambos es muy parecida. De modo que gran parte de lo que se diga en esta seccinsobre un sistema, vale para el otro.

Es muy fcil tropezarse por ah con MS SQL Server. Hay incluso quienes lo tieneninstalado y an no se han dado cuenta. Microsoft tiene una poltica de distribucinbastante agresiva para este producto, pues lo incluye en el paquete BackOffice, juntoa su sistema operativo Windows NT y unos cuantos programas ms. Como puedeimaginar el lector, SQL Server 6.5 puede ejecutarse en Windows NT y en WindowsNT. Por fortuna, la versin 7.0 ofrece un servidor para Windows 9x ... aunque obligaal usuario a instalar primeramente Internet Explorer 4.

Lo primero que llama la atencin es la cantidad de recursos del sistema que consumeuna instalacin de SQL Server. La versin 6.5 ocupa de 70 a 90MB, mientras que la


versin 7 llega a los 180MB de espacio en disco. La explicacin? Asistentes, y msasistentes: en esto contrasta con la austeridad espartana de InterBase.

A pesar de que la instalacin del servidor es relativamente sencilla, su mantenimientoes bastante complicado, sobre todo en la versin 6.5. Cada base de datos reside enuno o ms dispositivos fsicos, que el fondo no son ms que vulgares ficheros. Estosdispositivos ayudan a implementar la segmentacin, pero no crecen automtica-mente, por lo que el administrador del sistema deber estar pendiente del momentoen que los datos estn a punto de producir un desbordamiento. A diferencia de In-terBase, para cada base de datos hay que definir explcitamente un log, o registro detransacciones, que compite en espacio con los datos verdaderos, aunque este registropuede residir en otro dispositivo (lo cual se recomienda).

Aunque los mecanismos de logging, en combinacin con los bloqueos, son los msfrecuentes en las bases de datos relacionales como forma de implementar transaccio-nes atmicas, presentan claras desventajas en comparacin con la arquitectura multi-generacional. En primer lugar, no se pueden realizar copias de seguridad con usua-rios conectados a una base de datos. Los procesos que escriben bloquean a los pro-cesos que se limitan a leer informacin, y viceversa. Si se desconecta fsicamente elservidor, es muy probable que haya que examinar el registro de transacciones antesde volver a echar a andar las bases de datos. Por ltimo, hay que estar pendientes delcrecimiento de estos ficheros. Hay un experimento muy sencillo que realizo confrecuencia en InterBase, poblar una tabla con medio milln de registros, que nuncahe logrado repetir en SQL Server, por mucho que he modificado parmetros deconfiguracin.

Hay que reconocer que esta situacin mejora un poco con la versin 7, pues desapa-rece el concepto de dispositivo, siendo sustituido por el de fichero del propio sistemaoperativo: las bases de datos se sitan en ficheros de extensin mdf y ndf, los registrosde transacciones, en ficheros ldf. Este nuevo formato permite que los ficheros dedatos y de transacciones crezcan dinmicamente, por demanda.

Otro grave problema de versiones anteriores que soluciona la nueva versin es lagranularidad de los bloqueos. Antes, cada modificacin de un registro impona unbloqueo a toda la pgina en que ste se encontraba. Adems, las pginas tenan un ta-mao fijo de 2048 bytes, lo que limitaba a su vez el tamao mximo de un registro.En la versin 6.5 se introdujo el bloqueo a nivel de registro ... pero nicamente paralas inserciones, que es cuando menos hacen falta. Finalmente, la versin 7 permitesiempre bloqueos de registros, que pueden escalarse por demanda a bloqueos depgina o a nivel de tablas, y aumenta el tamao de pgina a 8192 bytes. No obstante,este tamao sigue sin poder ajustarse.

Microsoft SQL Server ofrece extraas extensiones a SQL que solamente sirven paracomplicarnos la vida a usted y m. Por ejemplo, aunque el SQL estndar dice que por


omisin una columna admite valores nulos, esto depende en SQL Server del estadode un parmetro, que por omisin produce el efecto contrario! La implementacinde la integridad referencial en este sistema es bastante pobre, pues solamente permiterestringir las actualizaciones y borrados en la tabla maestra; nada de propagacin encascada y otras alegras. Tambin es curioso que SQL Server no crea automtica-mente ndices secundarios sobre las tablas que contienen claves externas.


Propagar en cascada No NoAsignar valor por omisin No -

Otro de los aspectos negativos de SQL Server es su lenguaje de triggers y procedi-mientos almacenados, llamado Transact-SQL, que es bastante excntrico respecto alresto de los lenguajes existentes y a la propuesta de estndar. Uno puede acostum-brarse a soberanas tonteras tales como obligar a que todas las variables locales yparmetros comiencen con el carcter @. Pero es bastante difcil programar determi-nadas reglas de empresa cuando los triggers se disparan solamente despus de instruc-ciones completas.

En versiones anteriores del BDE, el nivel superior de aislamiento de transaccionessolamente se alcanzaba en bases de datos abiertas en modo slo lectura. Actualmentees posible activar este nivel desde C++ Builder sin problemas, aunque en el captulodedicado a este sistema de bases de datos estudiaremos trucos para garantizar lectu-ras repetibles sin necesidad de afectar demasiado a otros usuarios.

OracleOracle es uno de los abuelos en el negocio de las bases de datos relacionales; el otroes DB2, de IBM4. Este sistema es otra de las apuestas seguras en el caso de tener queelegir un servidor de bases de datos. Su principal desventaja? Resulta que no es decarcter tcnico, sino que tiene que ver con una poltica de precios altos, alto coste dela formacin y del mantenimiento posterior del sistema. Pero si usted puede permi-tirse el lujo...

Piense en una plataforma de hardware ... ya?, pues Oracle funciona en la misma. Losejemplos para Oracle de este libro han sido desarrollados, concretamente, con Per-sonal Oracle, versiones 7.3 y 8.0, para Windows 95. Este es un servidor muy estable,quizs algo lento en establecer la conexin a la base de datos, que a veces cuesta unpoco instalar adecuadamente (sobre todo por las complicaciones tpicas de TCP/IP), 4 Debe haber una explicacin (nunca me la han contado) a esta pulsin freudiana del giganteazul para que sus productos siempre sean segundos: DB2, OS/2, PS/2 ...


pero una vez en funcionamiento va de maravillas. As que con Oracle no tiene pre-textos para no llevarse trabajo a casa.

Oracle permite todas las funciones avanzadas de un servidor SQL serio: segmenta-cin, replicacin, etc. Incluso puede pensarse que tiene demasiados parmetros deconfiguracin. La parte principal del control de transacciones se implementa me-diante bloqueos y registros de transacciones, aunque el nivel de aislamiento superiorse logra mediante copias slo lectura de los datos. Por supuesto, el nivel mnimo degranularidad de estos bloqueos es a nivel de registro.

Tipos de datos? Todos los que usted desee. Restricciones check? No tan generalescomo las de InterBase, pero quedan compensadas por la mayor abundancia de fun-ciones predefinidas. Hasta la versin 7.3, Oracle implementaba solamente la propa-gacin en cascada de borrados para la integridad referencial, como muestra la si-guiente tabla:


Propagar en cascada S NoAsignar valor por omisin S -

Las extensiones procedimentales a SQL, denominadas PL/SQL, conforman un len-guaje potente, que permite programar paquetes (packages) para la implementacin detipos de datos abstractos. Con la versin 8, incluso, se pueden definir tipos de clases,u objetos. Esta ltima extensin no es, sin embargo, lo suficientemente general comopara clasificar a este sistema como una base de datos orientada a objetos, en el sen-tido moderno de esta denominacin. Uno de los puntos fuertes de la versin 4.0 deC++ Builder es la posibilidad de trabajar con las extensiones de objetos de Oracle 8.

Como pudiera esperarse, el lenguaje de triggers es muy completo, y permite especifi-carlos tanto a nivel de fila como de operacin. Hay montones de funciones utiliza-bles desde SQL, y curiosas extensiones al lenguaje consulta, como la posibilidad derealizar determinados tipos de clausuras transitivas.

Otros sistemas de uso frecuenteEvidentemente, es imposible hablar con autoridad acerca de todos los formatos debases de datos existentes en el mercado, y en las secciones anteriores me he limitadoa presentar aquellos sistemas con los que he trabajado con mayor frecuencia. Sinembargo, gracias a las particularidades de mi actual ocupacin, he podido ver enfuncionamiento a muchos de los restantes sistemas SQL con los que C++ Buildernos permite trabajar directamente.


Por ejemplo, DB2, de IBM. Antes mencion que este sistema y Oracle eran los dossistemas que ms tiempo llevaban en este negocio, y los frutos de esta experiencia sedejan notar tambin en DB2. Existen actualmente versiones de DB2 para una ampliagama de sistemas operativos. El autor lo ha visto funcionar sobre OS/2, WindowsNT y Windows 95, teniendo una versin de evaluacin sobre este ltimo sistema.Por supuesto, estas no son las nicas plataformas sobre las que puede ejecutarse.

La arquitectura de DB2 es similar a la de Oracle, a la que se parece la de MS SQLServer, que es similar a la de Sybase SQL Server.. En realidad, la concepcin de estossistemas est basada en un proyecto experimental de IBM, denominado System-R,que fue la primera implementacin de un sistema relacional. En este proyecto sedesarrollaron o perfeccionaron tcnicas como los identificadores de registros, losmecanismos de bloqueos actuales, registros de transacciones, ndices basados enrboles balanceados, los algoritmos de optimizacin de consultas, etc. As que tam-bin podr usted esperar de DB2 la posibilidad de dividir en segmentos sus bases dedatos, de poder realizar rplicas y de disponer de transacciones atmicas y coheren-tes. El mantenimiento de las bases de datos de DB2 puede ser todo lo simple queusted desee (sacrificando algo el rendimiento), o todo lo complicado que le parezca(a costa de su cuero cabelludo). El lenguaje de triggers y procedimientos almacenadoses muy completo, y similar al de Oracle e InterBase, como era de esperar. La nicapega que le puedo poner a DB2 es que la instalacin de clientes es bastante pesada, ypara poder conectar una estacin de trabajo hay que realizar manualmente un pro-ceso conocido como catalogacin. Pero esto mismo le sucede a Oracle con su SQLNet.

Otro sistema importante es Informix, que est bastante ligado al mundo de UNIX,aunque en estos momentos existen versiones del servidor para Windows NT. Suarquitectura es similar a la de los sistemas antes mencionados.

Finalmente, quiero referirme aunque sea de pasada a otras bases de datos no BDE.Tenemos, por ejemplo, la posibilidad de trabajar con bases de datos de AS/400.Aunque el motor de datos que viene con C++ Builder no permite el acceso directo alas mismas, podemos programar para estas bases de datos colocando una pasarelaDB2 como interfaz. No obstante, el producto C++ Builder/400 s que nos dejasaltarnos las capas intermedias, logrando mayor eficiencia a expensas de la prdida deportabilidad. Tambin est muy difundido Btrieve, una base de datos que inicio suvida como un sistema navegacional, pero que en sus ltimas versiones ha desarro-llado el producto Pervasive SQL, que es un motor de datos cliente/servidor relacio-nal. Lamentablemente, tampoco est soportado directamente por el motor de datosde C++ Builder, por el momento.

Captulo

2Breve introduccin a SQLBreve introduccin a SQL

UANDO IBM DESARROLL EL PRIMER PROTOTIPO DE base de datos relacio-nal, el famoso System R, cre en paralelo un lenguaje de definicin y mani-pulacin de datos, llamado QUEL. La versin mejorada de este lenguaje que

apareci un poco ms tarde se denomin, un poco en broma, SEQUEL. Finalmente,las siglas se quedaron en SQL: Structured Query Language, o Lenguaje de ConsultasEstructurado. Hay quien sigue pronunciando estas siglas en ingls como sequel, esdecir, secuela.

La estructura de SQLLas instrucciones de SQL se pueden agrupar en dos grandes categoras: las instruc-ciones que trabajan con la estructura de los datos y las instrucciones que trabajan conlos datos en s. Al primer grupo de instrucciones se le denomina tambin el Lenguajede Definicin de Datos, en ingls Data Definition Language, con las siglas DDL. Al se-gundo grupo se le denomina el Lenguaje de Manipulacin de Datos, en ingls Data Ma-nipulation Language, o DML. A veces las instrucciones que modifican el acceso de losusuarios a los objetos de la base de datos, y que en este libro se incluyen en el DDL,se consideran pertenecientes a un tercer conjunto: el Lenguaje de Control de Datos, DataControl Language, DCL.

En estos momentos existen estndares aceptables para estos tres componentes dellenguaje. El primer estndar, realizado por la institucin norteamericana ANSI yluego adoptada por la internacional ISO, se termin de elaborar en 1987. El segundo,que es el que est actualmente en vigor, es del ao 1992. En estos moment

Documents

La Cara Oculta de C++ Builder