Base De Datos

Por Jose Marquez

"Dominando las Bases de Datos" es una obra exhaustiva que te sumerge en el fascinante mundo de la gestión y utilización de datos. Desde los conceptos fundamentales hasta las aplicaciones más avanzadas, este libro es una guía completa para comprender y dominar el poder de las bases de datos en el mundo digital actual.

En las páginas de este libro, los lectores encontrarán:

Fundamentos Claros: Una introducción comprensiva a los principios básicos de las bases de datos, incluyendo modelos de datos, normalización, y diseño de bases de datos relacionales y no relacionales.

Dominio de SQL: Una exploración detallada del lenguaje SQL (Structured Query Language), desde consultas simples hasta operaciones avanzadas como subconsultas, joins, procedimientos almacenados y desencadenadores (triggers).

Optimización y Rendimiento: Estrategias efectivas para optimizar el rendimiento de las consultas y asegurar la eficiencia en la gestión de grandes volúmenes de datos.

Seguridad y Privacidad: Consideraciones importantes sobre la seguridad de la base de datos, incluyendo autenticación, autorización, cifrado y auditoría.

Aplicaciones Avanzadas: Una mirada profunda a tecnologías emergentes como bases de datos NoSQL, bases de datos distribuidas, big data, y aplicaciones de bases de datos en la nube.

Casos de Estudio y Proyectos Prácticos: Ejemplos prácticos y casos de estudio que ayudan a los lectores a aplicar los conceptos aprendidos en situaciones del mundo real, reforzando así su comprensión y habilidades prácticas.

Ya sea que seas un principiante absoluto en el mundo de las bases de datos o un profesional experimentado en busca de ampliar tus conocimientos, "Dominando las Bases de Datos" te proporcionará las herramientas y el conocimiento necesarios para convertirte en un experto en la gestión y utilización de datos.

• Idioma: Español
• Editorial: Jose Marquez
• Fecha de lanzamiento: 21 jun 2024
• ISBN: 9798227222459

Vista previa del libro

Bases de datos

Bases de datos

Contenido

Prefacio xvii

Agradecimientos xxi

  Bases de datos en la vida cotidiana 2

Una base de datos de muestra 3

El entorno de base de datos integrada 5

Roles en el entorno de base de datos integrada 7

Ventajas del enfoque de base de datos integrada 9

Desventajas del enfoque de base de datos integrada 12

Desarrollos históricos en los sistemas de información 13

Resumen del capítulo 17

Ejercicios 18

Ejercicios de laboratorio 19

PROYECTO DE MUESTRA: La galería de arte 23

PROYECTOS ESTUDIANTILES: Introducción a los proyectos estudiantiles 37

2.1  Los datos como un recurso 50

2.2  Características de los datos 50

viii Contenido

2.3  Etapas en el diseño de bases de datos 54

2.4  Herramientas de diseño 57

2.5  Administración de bases de datos 59

2.6  La arquitectura en tres niveles de las bases de datos 62

2.7  Panorama de los modelos de datos 70

2.8  Resumen del capítulo 74

Ejercicios 75

Ejercicios de laboratorio 77

PROYECTO DE MUESTRA: Aplicación de técnicas de planificación al proyecto de galería de arte  77

PROYECTOS ESTUDIANTILES: Aplicación de las técnicas de planificación a los proyectos estudiantiles  82

3.1 Propósito del modelo E-R 88

3.7 Dependencia de existencia y entidades débiles 101

PROYECTO DE MUESTRA: Creación del diagrama E-R para el proyecto galería de arte  109

PROYECTOS ESTUDIANTILES: Creación de diagramas E-R para los proyectos estudiantiles  122

Contenido ix

4.1  Breve historia del modelo relacional 124

4.2  Ventajas del modelo relacional 124

4.3  Estructuras de datos relacionales 125

4.4  Restricciones de integridad: dominio, clave, clave externa, restricciones generales  130

4.5  Representación de esquemas de bases de datos relacionales 131

4.6  Lenguajes de manipulación de datos relacionales 132

4.7  Vistas 150

4.8  Mapeo de un modelo E-R a un modelo relacional 151

4.9  Reglas de Codd para un sistema de gestión de base de datos relacional 156

4.10  Resumen del capítulo 157

Ejercicios 158

PROYECTO DE MUESTRA: Mapeo inicial del modelo E-R a tablas para la galería de arte  162

PROYECTOS ESTUDIANTILES: Mapeo inicial a tablas para proyectos estudiantiles  164

5.1  Objetivos de la normalización 166

5.2  Anomalías de inserción, actualización y borrado 166

5.3  Dependencia funcional 168

5.4  Superclaves, claves candidatas y claves primarias 170

5.5  El proceso de normalización usando claves primarias 171

5.6  Propiedades de las descomposiciones relacionales 182

5.7  Diseño relacional formal 185

x Contenido

5.8  Dependencias multivaluadas y cuarta forma normal 190

5.9  Descomposición sin pérdida y quinta forma normal 193

PROYECTO DE MUESTRA: Normalización del modelo relacional para la galería de arte  202

PROYECTOS ESTUDIANTILES: Normalización del modelo relacional para los proyectos estudiantiles  207

6.1  Breve historia de SQL en sistemas de bases de datos relacionales  210

6.2  Arquitectura de un sistema de gestión de bases de datos relacional  210

6.3  Definición de la base de datos: SQL DDL 212

6.4  Manipulación de la base de datos: DML SQL 218

6.5  Bases de datos activas 239

6.6  Uso de los enunciados COMMIT y ROLLBACK 244

6.7  Programación SQL 244

6.8  Creación y uso de vistas 251

6.9  El catálogo del sistema 254

6.10  Resumen del capítulo 256

Ejercicios 257

Ejercicios de laboratorio 260

Contenido xi

PROYECTO DE MUESTRA: Creación y manipulación de una base de datos relacional para la galería de arte  261

PROYECTOS ESTUDIANTILES: Creación y uso de una base de datos relacional para los proyectos estudiantiles  271

7.1  Razones para la extensión del modelo E-R 274

7.2  Generalización y especialización 274

7.3  Unión 282

7.4  Uso de notación (mín..máx) para cardinalidad y participación 284

7.5  Un diagrama de muestra EE-R 285

7.6  Mapeo de un modelo EE-R a un modelo relacional 286

7.7  Extensión del modelo relacional 289

7.8  Conversión de un diagrama EE-R a un modelo de base de datos objeto-relacional  297

7.9  Representación de objetos en Oracle 298

7.10  Resumen del capítulo 304

Ejercicios 306

Ejercicio de laboratorio 307

PROYECTO DE MUESTRA: Dibujo de un diagrama EE-R y creación de una base de datos relacional para la galería de arte  308

PROYECTOS ESTUDIANTILES: Dibujo de un diagrama EE-R y creación de una base de datos objeto-relacional para los proyectos estudiantiles  316

8.1  Razones para el modelo de datos orientado a objetos 318

8.2  Conceptos de datos orientados a objetos 318

xii Contenido

8.3  Modelado de datos orientados a objetos usando UML 323

8.4  El modelo ODMG y ODL 325

8.5  Lenguaje de consulta de objetos 331

8.6  Desarrollo de una base de datos oo 334

8.7  Resumen del capítulo 335

Ejercicios 336

Ejercicios de laboratorio 337

PROYECTO DE MUESTRA: Creación de un diagrama UML para la galería de arte y conversión del diagrama a un esquema de base de datos orientado a objetos  337

PROYECTOS ESTUDIANTILES: Dibuje un diagrama UML y diseñe un modelo de base de datos orientado a objetos  342

9.1  Temas de la seguridad en las bases de datos 344

9.2  Seguridad física y autentificación del usuario 345

9.3  Autorización 346

9.4  Control del acceso 346

9.5  Uso de las vistas para el control del acceso 347

9.6  Registros de seguridad y procedimientos de auditoría 347

9.7  Encriptado 348

9.8  Lenguaje de autorización en SQL 351

9.9  La seguridad en Oracle 353

9.10  Seguridad de una base de datos estadística 356

9.11  La seguridad de las bases de datos en Internet 356

9.12  Resumen del capítulo 358

Ejercicios 359

Ejercicios de laboratorio 360

Contenido xiii

PROYECTO DE MUESTRA: Implantación de medidas de seguridad para la base de datos de la galería de arte  360

PROYECTOS ESTUDIANTILES: Implantación de medidas de seguridad para los proyectos estudiantiles  361

10.1  Propiedades de las transacciones 364

10.2  Necesidad del control de la concurrencia 366

10.3  Serialización 370

10.4  Candados 372

10.5  Estampas de tiempo 379

10.6  Técnicas de validación 382

10.7  Necesidad de la recuperación 383

10.8  Técnicas de recuperación 384

10.9  Administración de transacciones en Oracle 388

10.10  Resumen del capítulo 389

Ejercicios 391

11.1  Interpretación y optimización de consultas 396

11.2  Técnicas algebraicas para la transformación de una consulta 397

11.3  Técnicas de procesamiento y estimación del costo 407

11.4  Establecimiento de ductos 418

11.5  Optimización de las consultas en Oracle 418

11.6  Resumen del capítulo 419

Ejercicios 419

xiv Contenido

12.1  Racionalidad de la distribución 426

12.2  Arquitecturas para un sistema distribuido 427

12.3  Componentes de un sistema de bases de datos distribuidas  433

12.4  Colocación de los datos 435

12.5  Transparencia 439

12.6  Control de transacciones para bases de datos distribuidas  440

12.7  Procesamiento distribuido de consultas 447

12.8  Resumen del capítulo 453

Ejercicios 454

PROYECTO DE MUESTRA: Planeación de la distribución de la base de datos relacional para la galería de arte  457

PROYECTOS ESTUDIANTILES: Planeación para la distribución 465

13.1  Introducción 468

13.2  Conceptos fundamentales de Internet y la World Wide Web  468

13.3  Arquitecturas multicapas 476

13.4  Modelo de datos semiestructurado 484

13.5  XML y las bases de datos relacionales 491

13.6  Resumen del capítulo 494

Ejercicios 496

Ejercicios de laboratorio 498

Contenido xv

PROYECTO DE MUESTRA: Creación de un sitio web que use Access, para la galería de arte  500

PROYECTOS ESTUDIANTILES: Creación de un sitio web para los proyectos estudiantiles  500

14.1  Computarización y aspectos éticos 502

14.2  Propiedad intelectual 503

14.3  Aspectos de privacidad 515

14.4  Factores humanos 521

14.5  Resumen del capítulo 538

Ejercicios 541

15.1  Orígenes de los almacenes de datos 544

15.2  Bases de datos operativas y almacenes de datos 544

15.3  Arquitectura de un almacén de datos 545

15.4  Modelos de datos para almacenes de datos 546

15.5  Consultas de almacén de datos y extensión OLAP SQL: 1999 550

15.6  Técnicas de indexado 552

15.7  Vistas y materialización de vistas 553

15.8  Minado de datos 554

15.9  Propósito del minado de datos 554

15.10  Tipos de conocimiento descubierto 555

15.11  Métodos utilizados 556

15.12  Aplicaciones del minado de datos 559

xvi Contenido

15.13  Resumen del capítulo 561

Ejercicios 562

Bibliografía 629

Índice analítico 635

1

Conceptos introductorios a las bases de datos

––––––––

CONTENIDO

Bases de datos en la vida cotidiana

Una base de datos de muestra

El entorno de base de datos integrada

Roles en el entorno de base de datos integrada

Ventajas del enfoque de base de datos integrada

Desventajas del enfoque de base de datos integrada

Desarrollos históricos en los sistemas de información

Resumen del capítulo

Ejercicios

Ejercicios de laboratorio

Exploración de la base de datos Access para el ejemplo Universidad Creación y uso de una nueva base de datos Access

PROYECTO DE MUESTRA: La galería de arte

PROYECTOS ESTUDIANTILES: Introducción a los proyectos estudiantiles

Proyecto uno: Colecta anual de la Universidad Beta Proyecto dos: Grupo de teatro de la comunidad Pleasantville Proyecto tres: Distribuidor Autos Amistosos

Proyecto cuatro: Estudio Imágenes Fotográficas Proyecto cinco: Grupo Médico Clínica Bienestar

––––––––

Objetivos del capítulo

En este capítulo aprenderá lo siguiente:

■  Cómo se usan las bases de datos en la vida cotidiana

■  Las principales funciones de un sistema de gestión de bases de datos

■  Ventajas de usar un sis­ tema de base de datos inte­ grada

■  Desventajas de las bases de datos

■  Roles en el entorno de base de datos integrada

■  La historia de los sistemas de información

Jose Marquez

2 CAPÍTULO 1  Conceptos introductorios a las bases de datos

En la actualidad, las bases de datos se usan tan ampliamente que se pueden encontrar en organizaciones de todos los tamaños, desde grandes corporaciones y agencias gubernamen­ tales, hasta pequeños negocios e incluso en hogares. Las actividades diarias con frecuencia lo ponen en contacto con las bases de datos, ya sea directa o indirectamente.

n Cuando visita un portal de Internet del consumidor que permite navegar y ordenar en línea bienes como libros o ropa, accede a una base de datos. La información acerca de los productos disponibles y los datos acerca del pedido se almacenan en una base de datos. También es posible que pueda ver los datos almacenados acerca de pedidos anteriores que haya levantado. Algunos sitios Web pueden usar informa­ ción acerca de sus pedidos, o incluso sus actividades de navegación, para sugerir pro­ ductos o servicios que es probable que le interesen.

■  Cuando visita un sitio Web interactivo de servicio al cliente, como la página de ini­ cio de una compañía de servicios o una aseguradora de salud, es capaz de acceder a información acerca de sus propios registros de servicios o productos proporciona­ dos. Es posible que sea capaz de actualizar entradas en la base de datos con informa­ ción personal como su dirección o número telefónico. Algunos sitios Web de servi­ cios al cliente le permiten hacer cambios a los servicios a los que se suscribe. Por ejemplo, su proveedor de servicios telefónicos o compañía eléctrica pueden permi­ tirle cambiar planes en línea.

■  Si usa banca electrónica, puede recuperar registros de base de datos acerca de depó­ sitos, retiros, pago de facturas y otras transacciones para sus cuentas. Puede transferir fondos, ordenar cheques y realizar muchas otras funciones, todas las cuales involu­ cran el uso de una base de datos.

■  Cuando usa una tarjeta de crédito, el vendedor por lo general espera la aprobación por computadora de su compra antes de presentarle un recibo para que lo firme. El proceso de aprobación consulta una base de datos para verificar que su tarjeta no se perdió o la robaron y para encontrar su límite de crédito, saldo actual y cantidad de compras ya aprobadas. La base de datos se actualiza automáticamente para reflejar la nueva cantidad aprobada. Para una tarjeta de débito, se consulta la base de datos del banco para verificar su número de cuenta, su NIP, su saldo actual y su saldo ajustado previo a la aprobación de la compra. La cantidad de compra se deduce en forma automática de su cuenta mientras la transacción se completa.

■  Cuando compra bienes en un supermercado o tienda al menudeo, se usan escáne­ res para leer códigos universales de producto u otros identificadores de mercancía. Al usar el código escaneado, el sistema de base de datos puede identificar el artículo exacto y producir un recibo con el nombre del artículo y su precio, y toma en consi­ deración cualquier precio de venta especial. El sistema también puede proporcionar entrada para un sistema de control de inventarios, de modo que el registro de inven­ tario para cada artículo se puede actualizar con el fin de reflejar la venta. Si el inventa­ rio cae por abajo de un nivel llamado punto de resurtido, la computadora automá­ ticamente puede colocar un pedido para volver a surtir el inventario.

■  Cuando hace planes para viajar, puede ingresar al sistema de reservaciones de una aerolínea en la que se usa una base de datos para rastrear los vuelos programados y las reservaciones de pasajeros. Dado que muchos viajeros pueden solicitar reserva­ ciones de manera simultánea, el sistema debe ser capaz de manejar peticiones rápida­ mente, resolver conflictos y aceptar solicitudes hasta que se alcance el número máximo de asientos. Muchas cadenas hoteleras y compañías de renta de autos tam­

  Una base de datos de muestra 3

bién tienen sistemas centralizados de reservaciones para aceptar reservaciones en cualquiera de sus ubicaciones, con el uso de un sistema de base de datos integrada.

■  Si visita al médico, es posible que sus registros médicos y datos de facturación se conserven en una base de datos. Cuando le extienden una receta, probablemente el farmacéutico usará una base de datos para registrar información acerca de la pres­ cripción, comprobar las interacciones con los medicamentos que use en la actualidad e imprimir la etiqueta y la receta. Tanto el médico como el farmacéutico pueden usar sus bases de datos para hacer cobranzas a terceras partes, que automáticamente veri­ fican la cobertura y extienden las cobranzas del seguro para los gastos cubiertos, mientras que usted sólo paga el deducible. A todos los proveedores de salud en Es­ tados Unidos se les requiere proteger la privacidad durante estas transacciones, en concordancia con la legislación de privacidad de la Ley de Transportabilidad de Responsabilidad en Seguros de Salud (HIPAA, por sus siglas en inglés).

■  Sus registros laborales se pueden mantener en una base de datos que almacena información básica como nombre, dirección, identificación de empleado, labores a desarrollar y evaluaciones de desempeño. La nómina probablemente se produce con el uso de una base de datos que almacena información acerca de cada periodo de pago y datos acerca de pago bruto anual, deducciones de impuestos e impuestos rete­ nidos, entre otras cosas. Su recibo de pago refleja estos datos cada día de pago.

■  Sus registros escolares tal vez se conservan en una base de datos que se actualiza cada periodo al registrar su inscripción, conclusión y calificación para cada clase.

■  Para hacer investigación, puede usar una base de datos bibliográfica en la que ingrese palabras clave que describan el tema de interés. Puede obtener resultados que contengan hipertexto, lo que le permite recuperar resúmenes o artículos de interés completos en su área de interés.

Como demuestra este breve panorama de actividades, las bases de datos se usan para satis­ facer las necesidades de información de muchas organizaciones e individuos en una varie­ dad de áreas. Sin embargo, una base de datos deficientemente diseñada fracasa para proporcionar la información requerida u ofrece información no actualizada, falsa o contra­ dictoria. Con la finalidad de maximizar sus beneficios potenciales, es importante compren­ der los fundamentos teóricos, estructura interna, diseño y gestión de las bases de datos.

Considere una base de datos simple que registra información acerca de estudiantes univer­ sitarios, las clases que toman durante un semestre y los profesores que imparten las clases. La información de cada estudiante incluye identificación (ID), nombre, especialidad y número total de créditos obtenidos del estudiante. Con el uso de Microsoft Access para este ejemplo, se tiene una tabla para estos datos, como se muestra en la figura 1.1(a). La tabla S t ud e n t (estudiante) tiene cinco columnas, llamadas s t u I d (identificación del estudian­ te), l a s t Name (apellido), f i r s t Name (nombre), ma j o r (especialidad) y c r e d it s (créditos). Cada fila de la tabla muestra la identificación del estudiante, apellido, nombre, especialidad y número de créditos para un estudiante. Los valores de estos ítems para cada estudiante se colocan en las columnas con los nombres correspondientes. La tabla Facu lt y (facultad) tiene columnas llamadas f ac I d (identificación del docente), n ame (nombre), d e p a r tme n t (departamento) y r a nk (posición), como se muestra en la figura 1.1(b). Cada fila de dicha tabla proporciona la identificación del profesor, el apellido, departamento y posición de un miembro del personal académico. La información de clase que se mantiene para cada clase impartida incluye el número de clase, la ID del profesor en la facultad, el

4 CAPÍTULO 1  Conceptos introductorios a las bases de datos

––––––––

horario y el salón, en columnas apropiadas como se muestra en la tabla C l a ss (Clase) en la figura 1.1(c). Estas tres tablas solas no permiten determinar cuáles clases toma un estu­ diante. Para representar el hecho de que un estudiante está inscrito en una clase particular, se necesita otra tabla, que se llama En r o ll (inscripción), que se presenta en la figura 1.1(d). Las columnas de En r o ll son s t u I d, c l a ssNumb e r (número de clase) y g r a d e (calificación). Note que la tabla E n r o l l representa la relación entre S t ud e n t y C l a ss, lo que indica cuáles filas de estas tablas se relacionan (es decir, cuáles estudiantes toman cuáles clases). Por ejemplo, la primer fila, con valores S1001, ART103A, dice que el estudiante cuya ID es S1001 está inscrito en la clase cuyo número de clase es ART103A. La última columna de la fila menciona la calificación que obtuvo cada estudiante en cada clase. Dado que esto representa inscripciones actuales, se supondrá que la calificación es la califi­ cación de medio semestre. Al final del semestre, se puede cambiar a la calificación final. Note que en esta tabla no se pusieron ni los nombres de estudiante ni las ID, porque ya están en la tabla S t ud e n t, y se quiere evitar la redundancia y posibles inconsistencias que

––––––––

FigUrA 1.1(a)

La tabla Student

FigUrA 1.1(b) 

La tabla Faculty

FigUrA 1.1(c)

La tabla Class

Faculty 

  El entorno de base de datos integrada 5

––––––––

––––––––

––––––––

causaría el almacenar los nombres dos veces. Las tablas que se muestran se crearon con Access, y se puede usar Access para actualizarlas, para plantear preguntas (queries, consul­ tas) acerca de los datos en ellas, para crear reportes acerca de los datos y para hacer muchas otras funciones. Como ejemplo de una consulta, suponga que se quieren los nombres de todos los estudiantes inscritos en ART103A. Primero, ¿cómo encuentra visualmente la res­ puesta a la pregunta? Al buscar en la base de datos, se ve que la tabla En r o ll dice cuáles estudiantes están inscritos en ART103A. Sin embargo, da el s t u I d de cada estudiante, no el nombre. Los nombres de los estudiantes aparecen en la tabla S t ud e n t. Un plan para responder la pregunta es buscar en la tabla En ro l l y encontrar todas las filas donde el valor de c l a ssNumb e r sea ART103 y tomar nota de los valores s t u I d en dichas filas, a saber, S1001, S1002 y S1010. Luego se busca en la tabla S t ud e n t y se encuentran las filas que contengan dichos valores en la columna s t u I d. La respuesta a la pregunta se encuen­ tra al citar los valores l a s t Name y f i r s t Name en dichas filas, lo que produce Smith Tom, Chin Ann y Burns Edward. Access proporciona una herramienta de consulta (query tool) que permite comprobar cuáles columnas se incluyen en una consulta y especificar condiciones para los registros en los resultados. La figura 1.2 muestra los resultados de eje­ cutar la consulta precedente usando esta herramienta. También se puede usar la herramien- ta reporte (reporting tool) en Access para generar una variedad de reportes. La figura 1.3 muestra un reporte común llamado Class Lists (listas de clase) que muestra cada número de clase, la ID y el nombre del miembro docente que imparte la clase, y las ID y nombres de todos los estudiantes en dicha clase.

––––––––

FigUrA 1.1(d) 

La tabla Enroll

FigUrA 1.2 

resultados de la consulta: Encontrar nombres de todos los estudiantes inscritos en ArT103A

––––––––

Un entorno de base de datos integrada tiene un único gran repositorio de datos, llamado base de datos, que usan de manera simultánea muchos departamentos y usuarios en una

6 CAPÍTULO 1  Conceptos introductorios a las bases de datos

FigUrA 1.3 

reporte Class Lists

––––––––

Class Lists 

––––––––

organización. Todos los datos que la organización necesita para un grupo específico de apli­ caciones, o incluso para todas sus aplicaciones, se almacenan juntos, con tan poca repeti­ ción como sea posible. (Nota: Aunque la palabra data (datos) es plural en el inglés usual, es obligatorio usarla como singular y plural en la literatura de bases de datos, como en datos es y datos son.) En la base de datos pueden aparecer diferentes tipos de registros. Las conexiones lógicas entre los ítems y registros de datos también se almacenan en la base de datos, de modo que el sistema sabe, por ejemplo, cuál registro de docente está conectado a un registro de clase particular. La base de datos no es propiedad de un solo departamento, sino que es un recurso compartido. En una organización grande, la base de datos la gestiona un administrador de base de datos (ABD), quien es el responsable de crear y mantener la base de datos para satisfacer las necesidades de los usuarios. Todos los accesos a la base de datos están controlados mediante un sofisticado paquete de software llamado sistema de gestión de base de datos (DBMS, por sus siglas en inglés). Este paquete tiene programas que establecen las estructuras de almacenamiento originales, cargan los datos, aceptan peti­ ciones de datos de programas y usuarios, dan formato a los datos recuperados de modo que aparezcan en la forma que el programa o el usuario esperan, ocultan datos a los que un usuario particular no debe tener acceso, aceptan y realizan actualizaciones, permiten el uso concurrente de los datos sin hacer que los usuarios interfieran unos con otros, y realizan respaldos y procedimientos de recuperación automáticamente. Éstas son sólo algunas de las muchas funciones del sistema de gestión de la base de datos.

La figura 1.4 ilustra un entorno de base de datos integrada. Aquí, todos los datos acerca de estudiantes, clases, personal docente e inscripciones se almacenan en una sola base de datos. Los datos están integrados, de modo que los ítems de datos se almacenan en forma­ tos compatibles y las conexiones lógicas entre ellos también se almacenan. La base de datos contiene una descripción de su propia estructura, de modo que el DBMS sabe cuáles ítems de datos existen y cómo están estructurados o agrupados. La comparten muchos usuarios, por lo general de manera concurrente. Todo acceso a los datos es a través del DBMS. Los programas de aplicaciones, que se pueden escribir en diferentes lenguajes de programación, pasan por el DBMS, que puede presentar los datos en la forma que cada pro­ grama espera. Sólo el DBMS está al tanto de las estructuras de almacenamiento utilizadas en la base de datos. Además de proporcionar apoyo para las aplicaciones, el DBMS propor­ ciona una interfaz de usuario para consultas interactivas. Los usuarios autorizados pueden preguntar a la base de datos directamente, con el lenguaje de consulta del DBMS particular.

  roles en el entorno de base de datos integrada 7

BASE DE DATOS

DBMS

APLICACIÓN SALIDA

FigUrA 1.4 

El entorno de base de datos integrada

––––––––

Muchos individuos o grupos están involucrados en las operaciones de un sistema de base de datos. Juegan diferentes roles, dependiendo de la forma en que interactúan con la base de datos, como se muestra en la figura 1.5.

■  Usuarios finales

La base de datos se diseña, crea y mantiene para satisfacer las necesidades de infor­ mación de los usuarios finales, las personas que usan los datos para realizar sus labores. Sin importar la elegancia del diseño de la base de datos, o la sofisticación del hardware y el software utilizados, si la base de datos no proporciona información adecuada a los usuarios, es un fracaso. A final de cuentas, son los usuarios quienes juzgan el éxito del sistema. Los usuarios se pueden categorizar de acuerdo con la forma en que acceden a los datos. Los usuarios sofisticados (también llamados usua- rios casuales) están capacitados en el uso del lenguaje de consulta interactivo, y acceden a los datos mediante el ingreso de consultas en estaciones de trabajo. La fle­ xibilidad del lenguaje de consulta les permite realizar muchas operaciones diferentes

8 CAPÍTULO 1  Conceptos introductorios a las bases de datos

FigUrA 1.5 

roles en el entorno de base de datos

––––––––

sobre la base de datos, sólo limitadas por las vistas que se les asigne y sus autoriza­ ciones. Los usuarios casuales pueden realizar operaciones de recuperación, inser­ ción, borrado o actualización mediante el lenguaje de consulta, siempre que tengan autorización para hacerlo. Los usuarios aficionados no usan el lenguaje de consulta interactivo, sino que acceden a los datos mediante programas de aplicación que se escribieron para ellos. Invocan los programas al ingresar comandos simples o elegir opciones de un menú. No necesitan conocer detalle alguno de la estructura o len­ guaje del sistema de base de datos. Interactúan con el sistema en una forma menos sofisticada y restringen su acceso a operaciones realizadas por los programas. Los programas mismos pueden realizar operaciones de actualización o recuperación. Un grupo todavía más grande de usuarios secundarios puede usar la información en la base de datos sin interactuar directamente con ella, al recibir salida que usan en sus labores.

Por ejemplo, en una oficina de admisión en una universidad, los empleados pueden ser usuarios aficionados, mientras que el encargado de admisión puede ser un usua­ rio casual. Los empleados realizan simples tareas repetitivas como imprimir trans­ cripciones estudiantiles. Pueden ingresar el nombre de la transacción, TRANSCRIP­

  Ventajas del enfoque de base de datos integrada 9

CIÓN, o elegir una opción como IMPRIMIR TRANSCRIPCIÓN de un menú. El programa TRANSCRIBIR pediría al empleado la ID del estudiante u otra informa­ ción de identificación, y completaría su tarea sin mayores instrucciones del empleado. El encargado de admisión usa el lenguaje de consulta para plantear pre­ guntas específicas como ¿cuántos estudiantes están registrados en seis o más clases este semestre? Si no hay un programa preescrito en el DBMS para responder esta pregunta, el encargado escribe enunciados en el lenguaje de consulta de dicha base de datos particular. Los estudiantes que reciben transcripciones impresas, y los profe­ sores que reciben listas de nombres para la clase, son usuarios secundarios.

■  Programadores de aplicaciones

Este grupo incluye a los programadores que escriben aplicaciones batch, o interacti­ vas, para otros usuarios. Sus programas de aplicación se pueden escribir en una variedad de lenguajes de programación huéspedes como Java, C, C++, C#, Visual BASIC, RPG o COBOL. Cada programa que accede a la base de datos contiene enun­ ciados que solicitan al sistema de gestión de la base de datos realizar actualizaciones o recuperaciones en la base de datos. Algunos usuarios finales sofisticados que tienen tanto el conocimiento del lenguaje de programación, como el permiso para hacerlo, son capaces de escribir aplicaciones para su propio uso.

■  Administrador de la base de datos

El administrador de la base de datos es el individuo o grupo responsable del diseño, creación de la estructura y mantenimiento de la base de datos. En muchos casos, la base de datos la diseña un especialista, y el ABD toma la responsabilidad una vez que el diseño está completo. El diseñador de la base de datos comienza el proceso de diseño al entrevistar a los usuarios para determinar sus necesidades de datos. Examina el sistema actual, analiza la organización y sus necesidades de información, y desarrolla un modelo tentativo para la base de datos. El modelo se refina y mejora conforme el diseñador, al consultar a los usuarios, está más al tanto de sus necesida­ des de datos y aprende más acerca del funcionamiento de la organización. Cuando se desarrolla un diseño satisfactorio, el ABD lo implementa. Una vez más, se consulta a los usuarios para determinar si el sistema operativo es adecuado. El diseño, refina­ miento y rediseño del sistema son esfuerzos de equipo, con el diseñador, el ABD y los usuarios trabajando en conjunto para desarrollar la mejor fuente de datos para toda la organización. El ABD interactúa con la base de datos operativa como un superusua­ rio, quien controla y accede a la información acerca de la estructura y el uso de la base de datos en sí, en oposición a los usuarios finales, quienes acceden a los datos dentro de la base de datos. El capítulo 2 contiene una descripción más detallada de las funciones del administrador de la base de datos.

Antes de crearse las bases de datos integrada, se usaban sistemas de procesamiento de archivos, y los datos que usaban los programas de aplicación de una organización se alma­ cenaban en archivos separados. Por lo general, un departamento que necesitaba un progra­ ma de aplicación trabajaba con el departamento de procesamiento de datos de la organización para crear especificaciones tanto para el programa como para los datos nece­ sarios para él. Con frecuencia los mismos datos se recopilaban y almacenaban de manera independiente mediante varios departamentos dentro de una organización, pero no se compartían. Cada aplicación tenía sus propios archivos de datos que se creaban de manera específica para la aplicación, y éstos pertenecían al departamento para el que se escribía la aplicación. El enfoque de base de datos integrada tiene muchas ventajas:

10 CAPÍTULO 1  Conceptos introductorios a las bases de datos

Compartición de datos

La base de datos pertenece a toda la organización. El ABD gestiona los datos, pero éstos no pertenecen a algún individuo o departamento. Por ende, la organización tiene el control sobre los datos que necesita para dirigir su negocio. Muchos usuarios pueden tener autorización para acceder al mismo trozo de información. La autoriza­ ción para acceder a los datos la otorga el ABD, no otro departamento.

Control de redundancia

Cuando se almacena en una base de datos, la información se integra de modo que múltiples copias de los mismos datos no se almacenan a menos que sea necesario. Se permite alguna redundancia limitada para mantener las conexiones lógicas entre los ítems de datos o para mejorar el rendimiento. Para poner un caso, en el ejemplo de universidad que se discutió en la sección 1.2, la ID del estudiante aparecía tanto en la tabla Student como en la tabla Enroll. El sistema de gestión de la base de datos sabe acerca de dicha repetición. Una base de datos de ordinario no tiene múltiples copias de registros enteros, a diferencia de un sistema de archivos, donde distintos departa­ mentos podían tener duplicados de archivos enteros.

Consistencia de datos

Un efecto de eliminar o controlar la redundancia es que los datos son consistentes. Si un ítem de datos aparece sólo una vez, cualquier actualización a su valor necesita realizarse sólo una vez, y todos los usuarios tendrán acceso al mismo nuevo valor. Si el sistema tiene cierta redundancia controlada, cuando recibe una actualización a un ítem que aparezca más de una vez con frecuencia puede realizar actualizaciones en cascada. Esto significa que automáticamente actualizará cada ocurrencia de dicho ítem, lo que mantiene consistente a la base de datos. Por ejemplo, si se cambia la ID de un estudiante en la tabla Student, los registros Enroll para dicho estudiante se actualizarán para mostrar la nueva ID en forma automática.

Estándares de datos mejorados

El ABD, que es responsable del diseño y mantenimiento de la base de datos para satisfacer las necesidades de todos los usuarios, define y refuerza los estándares de toda la organización para la representación de datos en la base de datos. En esta cate­ goría se incluyen reglas como el formato de todos los ítems de datos, convenciones acerca de nombres de datos, estándares de documentación, frecuencia de actualiza­ ciones, procedimientos de actualización, frecuencia de respaldos, procedimientos de respaldos y uso permitido de la base de datos. Por ejemplo, el ABD puede elaborar una regla para que las direcciones se almacenen en un formato particular. En Estados Unidos, una convención puede ser que, para los nombres de los estados, se usen abreviaturas con dos letras. La base de datos se puede configurar de modo que cual­ quier otra representación se rechace. En otros países, las zonas postales pueden defi­ nirse con base en cierto número de caracteres.

Mejor seguridad de datos

Los datos en la base de datos de una organización son un valioso recurso corporativo que se debe proteger de mal uso intencional o accidental. La seguridad de datos es la protección de la base de datos de acceso no autorizado por personas o programas que puedan hacer mal uso o dañar los datos. Un sistema de base de datos permite la definición y fortalecimiento de restricciones de seguridad en varios niveles. Todo acceso autorizado a la base de datos es a través del DBMS, que puede requerir que los usuarios pasen a través de procedimientos de seguridad o usar contraseñas para obtener acceso a la base de datos. Para eliminar la posibilidad de que un usuario pase por un lado del DBMS y obtenga acceso a los datos en forma ilegal, el DBMS puede encriptar los datos antes de almacenarlos. Entonces, cuando un usuario autorizado

1.5 Ventajas del enfoque de base de datos integrada 11

desee recuperar datos, se desencriptarán automáticamente. Los datos recuperados en cualquiera otra forma aparecerán en su forma encriptada. Los usuarios autorizados pueden no estar al tanto de la encriptación de datos. A cada usuario se le proporcio­ na una vista de una porción predefinida de la base de datos. Por ejemplo, en una uni­ versidad, la oficina de admisión puede tener acceso a cierta información del personal docente, como la tabla Faculty en el ejemplo anterior, pero no a ítems como el sala­ rio. En la vista se incluyen descripciones de los ítems de datos a los que se permite el acceso del usuario, y el tipo de acceso permitido, ya sea sólo recuperación, actualiza­ ción o borrado de registros existentes, o inserción de nuevos registros. Si un usuario intenta acceder a un ítem que no está incluido en su vista, o intenta una operación no autorizada, el DBMS automáticamente registra la ID del usuario en una bitácora (log) de seguridad que está disponible al ABD.

Integridad de datos mejorada

Algunos sistemas de gestión de base de datos permiten al ABD definir restricciones de integridad: reglas de consistencia que la base de datos debe obedecer. Estas res­ tricciones se aplican a ítems dentro de un registro (restricciones intrarregistro) o a registros que se relacionan mutuamente (restricciones interregistro), o pueden ser restricciones generales del negocio. Por ejemplo, en los registros de clase, puede haber una regla de que el número de estudiantes inscritos en una clase nunca supere algún máximo de inscripción permitido. Otra regla puede ser que la ID del personal docente en un registro de clase deba corresponder a una ID de personal docente real en un registro de personal docente. El DBMS es responsable de nunca permitir la inserción, el borrado o la actualización de un registro que viole una restricción de integridad.

Equilibrio de los requisitos en conflicto

Cada departamento o usuario individual tiene necesidades de datos que pueden estar en conflicto con los de otros usuarios. El ABD está al tanto de las necesidades de todos los usuarios y puede tomar decisiones acerca del diseño, uso y mantenimiento de la base de datos que proporcionen las mejores soluciones para la organización como un todo. Estas decisiones por lo general favorecen las aplicaciones más impor­ tantes, posiblemente a costa de las menos vitales.

Desarrollo más rápido de nuevas aplicaciones

Una base de datos bien diseñada proporciona un modelo preciso de las operaciones de la organización. Cuando se propone una nueva aplicación, es probable que los datos requeridos ya estén almacenados en la base de datos. Si es así, el DBMS puede proporcionar datos en la forma requerida por el programa. El tiempo de desarrollo se reduce porque no se necesita una fase de creación de archivos para la nueva apli­ cación, como ocurría cuando se usaban los sistemas de procesamiento de archivos.

Mejor accesibilidad de datos

Además de proporcionar datos para los programas, la mayoría de los sistemas de ges­ tión de base de datos permiten acceso interactivo a los usuarios. Proporcionan len­ guajes de consulta que permiten a los usuarios plantear preguntas ad hoc y obtener la información deseada.

Economía de escala

Cuando todos los requisitos de datos de la organización se satisfacen mediante una base de datos en lugar de muchos archivos separados, el tamaño de la operación combinada proporciona muchas ventajas. La porción del presupuesto que de ordina­ rio se asignaría a varios departamentos para sus costos de diseño, almacenamiento y costos de datos, se puede combinar, lo que posiblemente resulte en un costo total más bajo. Los recursos combinados se pueden usar para desarrollar un sistema más

12 CAPÍTULO 1  Conceptos introductorios a las bases de datos

––––––––

sofisticado y poderoso que cualquier departamento podría costear en forma indivi­ dual, lo que proporciona características no disponibles en un entorno de procesa­ miento de archivos. El tiempo de programador que ordinariamente se dedicaría al diseño de archivos y la escritura de programas para acceder a ellos se puede emplear en la mejora de la base de datos. Cualquier mejora a la base de datos beneficia a muchos usuarios.

Más control sobre la concurrencia

Si a dos usuarios se les permite ingresar a datos simultáneamente, y al menos uno de ellos actualiza datos, es posible que interfieran uno con el otro. Por ejemplo, si ambos intentan realizar actualizaciones, una actualización se puede perder, porque el segun­ do puede sobrescribir el valor grabado por el primero. Si las actualizaciones tienen la intención de ser acumulativas, éste es un serio problema. La mayoría de los sistemas de gestión de bases de datos integradas tienen subsistemas para controlar concurren­ cia, de modo que las transacciones no se pierdan o desempeñen de manera inco­ rrecta.

Mejores procedimientos de respaldo y recuperación

En un entorno de base de datos, los registros de la base de datos por lo general se res­ paldan (copian) de manera regular, acaso por la noche. Para mantener seguro el res­ paldo, se usa una cinta u otro medio. Conforme se realizan transacciones, cualquier actualización se registra en una bitácora (log) de cambios. Si el sistema fracasa, cinta y log se usan para llevar la base de datos al estado en que estaba justo antes de la falla. Por tanto, el sistema se autorrecupera.

También existen algunas desventajas en un entorno de base de datos integrada, en compa­ ración con un sistema de archivos:

Alto costo de DBMS

Puesto que un sistema de gestión de base de datos completo es una pieza de software muy grande y sofisticada, su compra o arrendamiento es costoso.

Costos de hardware más altos

Para correr el DBMS se requieren memoria adicional y potencia de procesamiento, lo que resulta en la necesidad de actualizar el hardware.

Costos de programación más altos

Puesto que un DBMS es una herramienta compleja con muchas características, los programadores de la organización necesitan un conocimiento extenso del sistema con la finalidad de usarlo con mayor ventaja. Si la organización contrata programa­ dores de base de datos experimentados o capacita a su propio personal de programa­ ción, paga por la experiencia.

Altos costos de conversión

Cuando una organización convierte a un nuevo sistema de base de datos, se tienen que remover datos de los archivos existentes y cargarlos en la base de datos. Debido a los diferentes formatos usados en los archivos, éste puede ser un proceso difícil y que consume tiempo. Además, los programas de aplicaciones, que contienen detalles acerca del almacenamiento y la estructura de los archivos antiguos, se deben modifi­ car para trabajar con el DBMS.

1.7 Desarrollos históricos en los sistemas de información 13

Procesamiento más lento de algunas aplicaciones

Aunque una base de datos integrada se diseña para proporcionar mejor información más rápidamente que un sistema tradicional que use archivos separados, algunas aplicaciones son más lentas. Por ejemplo, un archivo de nómina típico se configura en una secuencia que coincide con el programa de nómina, y contiene sólo los datos necesarios para esta aplicación. Está diseñado específicamente para hacer a dicha aplicación tan eficiente como sea posible. En la base de datos, los registros de los empleados pueden no almacenarse de manera consecutiva y la recuperación normal puede no ser en la secuencia necesaria por el programa de nómina. Por tanto, este programa tardará más tiempo en ejecutarse.

Vulnerabilidad aumentada

Siempre que los recursos están centralizados, existe un aumento en el riesgo de segu­ ridad. Dado que todas las aplicaciones dependen del sistema de base de datos, la falla de cualquier componente del sistema puede llevar las operaciones a un estancamien­ to. La falla de un solo programa de aplicaciones puede tener un efecto sobre otros programas que es posible usen datos incorrectos creados por el programa dañado.

Recuperación más difícil

El proceso de recuperación después de una falla de la base de datos es complicado porque muchas transacciones podrían estar en progreso cuando falle el sistema. Como parte de su recuperación, el sistema debe determinar cuáles transacciones se completaron y cuáles todavía estaban en progreso al momento de la falla. Si la base de datos está dañada, se puede recuperar con el uso de la cinta de recuperación y el log. El hecho de que una base de datos permita a los usuarios realizar actualizaciones concurrentes complica aún más el proceso de recuperación.

La necesidad de registrar datos se remonta a la historia reconocida más antigua. Los inten­ tos para proporcionar registros permanentes de transacciones se ven en las tablas de arcilla sumerias, en artefactos dejados por los babilonios, en los jeroglíficos del antiguo Egipto e incluso en las pinturas rupestres. Los registros en papel u otras formas escritas se han usado durante siglos para registrar información acerca de historias familiares, tratados y otros acuerdos, inventarios domésticos o empresariales, reclutamiento escolar, registros de empleados, pago de bienes o servicios, datos censales y muchas otras facetas de la vida.

El uso de tarjetas perforadas para almacenamiento de datos se introdujo en 1890, cuando los datos censales estadounidenses se recopilaron y almacenaron en tarjetas perforadas por primera vez. La constitución estadounidense requiere que se realice un censo completo cada 10 años. El censo de 1880 tardó siete años en completarse porque la población del país aumentó tanto que se anticipó que no habría suficiente tiempo para completar el censo antes de 1900, cuando comenzaría uno nuevo. La oficina censal patrocinó una competencia a fin de que se proporcionaran ideas acerca de las formas para hacer el censo más eficiente. Herman Hollerith, empleado de la oficina, propuso el uso de tarjetas perforadas para regis­ trar las respuestas censales de cada hogar y facilitar el procesamiento de las respuestas. Tales tarjetas ya estaban en uso en la industria de tejido de seda en Lyon, Francia, para controlar el telar Jacquard, que tejía patrones en tela de seda. Hollerith diseñó un método con el fin de usar la misma tecnología para almacenar datos censales y examinar sus patrones. Ganó la competencia y, debido a su diseño, el censo se completó en tiempo récord, y se inventó una nueva técnica para el procesamiento de datos. Después de dicho éxito, el equipo mecá­ nico de tarjetas perforadas se usó durante muchos años para almacenamiento, ordenación,

14 CAPÍTULO 1  Conceptos introductorios a las bases de datos

análisis y reporte de datos, y las tarjetas perforadas funcionaron como un medio de entrada para las computadoras, tanto para programas como para datos.

La cinta de papel perforado se usó para almacenar tanto programas de computadora como datos desde comienzos de la década de 1940, cuando se inventaron las primeras compu­ tadoras electromecánicas y electrónicas. Desde aproximadamente 1950, la cinta magnética se desarrolló y usó para entrada en las primeras computadoras, incluida la UNIVAC 1, la primera computadora comercialmente disponible. Los mazos de tarjetas perforadas, los bucles de cinta de papel perforada o los carretes de cinta magnética se usaron todos esen­ cialmente en la misma forma, tanto para almacenar programas como para proporcionar un método de almacenamiento y entrada de datos. Los datos en estos medios sólo se podían leer en el orden en el que se almacenaban. Este tipo de procesamiento secuencial de archi- vos era en extremo eficiente, pero no muy flexible. Por lo general, la nómina era la primera aplicación que un negocio elegía automatizar, debido a los complejos cálculos y requeri­ mientos de reporte que eran tediosos para las personas que los realizaban.

La figura 1.6 proporciona un panorama de una aplicación de nómina que usa procesamien­ to secuencial de archivo. El archivo maestro que contiene datos de nómina relativamente permanentes para cada empleado se mantiene en orden mediante un campo clave, acaso Número de Empleado. Los registros en este archivo también pueden contener ítems como el nombre del empleado, dirección, salario semanal, exenciones, deducciones de impuestos, totales de pago bruto en lo que va del año, impuestos y salario neto. Cada semana se prepa­ raría un archivo de transacción que contendría nuevos datos, como el número de horas laboradas dicha semana, cualquier cambio en salario, deducciones u otros datos, y cualquie­ ra otra nueva información necesaria para la nómina de dicha semana. Con frecuencia se usaba la cinta magnética para el archivo maestro, y las tarjetas perforadas para el archivo de transacción. Ambos archivos tienen que estar en el mismo orden, por Número de Emplea­ do. Un programa leería un registro maestro, luego leería el registro de transacción para el mismo empleado y completaría el procesamiento de nómina para dicha persona. En el pro­ ceso, la información en el antiguo registro maestro cambiaría para reflejar nuevos datos, y un nuevo registro se escribiría a una nueva cinta maestra. Al final del programa, la nueva cinta se convertiría en la cinta maestra actual, y se usaría la siguiente semana. A esto se le conoce como un sistema maestro antiguo/maestro nuevo o padre/hijo. El tipo de proce­ samiento descrito aquí, donde un conjunto de registros se envían como unidad a un progra­ ma que luego opera sobre ellos sin mayor intervención humana, se conoce como procesamiento por lote (batch).

El almacenamiento en disco magnético estuvo disponible hacia finales de la década de 1950, lo que hizo posible el acceso directo (acceso no secuencial) de registros. Los progra­ mas ya no requerían que el orden de acceso coincidiera con el orden físico de los registros. Las actualizaciones se podían hacer al disco, sin rescribir todo el archivo. Durante la década de 1960 se desarrollaron lenguajes de programación, incluidos COBOL y PL/1, para proce­ samiento de datos comercial que usaba datos almacenados tanto en cinta como en disco. Originalmente, se usaron organizaciones de archivo simples para organizar datos en estos dispositivos de almacenamiento secundario, pero conforme las aplicaciones se volvieron más complejas, se necesitaron métodos de almacenamiento y recuperación de datos más sofisticados. Dos modelos de base de datos competitivas, la red y la jerárquica, se desarro­ llaron en esta época. Sin embargo, continuó el uso de los sistemas de archivos para muchas aplicaciones.

El modelo jerárquico para bases de datos se desarrolló durante la década de 1960, como una solución ad hoc para las necesidades inmediatas de aplicaciones reales. El sistema de gestión de base de datos jerárquico más antiguo, el IMS de IBM, se creó con el fin de orga­ nizar y almacenar información necesaria para el programa espacial del proyecto de aluniza­

  Desarrollos históricos en los sistemas de información 15

FigUrA 1.6

roles en el entorno de base de datos

je del Apolo. North American Aviation (que se convirtió en Rockwell) e IBM trabajaron en conjunto para producir la primera versión de IMS, que se lanzó en 1968. Las primeras ver­ siones de IMS se diseñaron para utilizarse con dispositivos de cinta magnética, pero más tarde el disco magnético se convirtió en estándar. IMS pronto se volvió el sistema de gestión de base de datos jerárquico dominante en el mercado y durante muchos años fue el más ampliamente usado de todos los DBMS, hasta que lo sustituyeron los sistemas relacionales. Después de 1968 se hicieron muchas mejoras a IMS, lo que resultó en nuevas versiones que sacaron ventaja de las mejoras en hardware y software, y proporcionó nuevas características como comunicaciones de datos y maximizar el rendimiento. El sistema de reservaciones de la aerolínea SABRE se basó en IMS. IMS se conoció como un caballo de batalla capaz de procesar eficientemente grandes cantidades de datos. Usaba una estructura de árbol fami­ liar a los programadores que estaban acostumbrados a trabajar con archivos, y proporcionó rendimiento predecible.

A principios de la década de 1960, Charles Bachman, en General Electric, creó uno de los sistemas de gestión de base de datos más antiguo, Integrated Data Store (IDS, almacén datos), usando un modelo de red. Este sistema de gestión de base de datos influyó el desa­ rrollo del área de base de datos durante muchos años. La Conferencia sobre Lenguajes de Sistemas de Datos (CODASYL, por sus siglas en inglés), organización que consiste en representantes de grandes proveedores y usuarios de hardware y software, se formó para intentar estandarizar muchos aspectos del procesamiento de datos. Tuvo estándares exitosa­ mente escritos para el lenguaje COBOL. A finales de la década de 1960 formó un subgrupo llamado Database Task Group (DBTG, Grupo de tarea de base de datos) para abordar la cuestión de la estandarización para los sistemas de gestión de base de datos. Influidos por IDS, el grupo propuso un modelo basado en red y especificaciones para definición de datos y lenguajes de manipulación de datos. El reporte del anteproyecto se publicó en 1969 y resultó en muchas sugerencias para cambios por parte de sus lectores. El DBTG reconsideró su propósito y publicó su primer reporte oficial en 1971. Este documento hito se envió al American National Standards Institute (ANSI) con la esperanza de que sus especificaciones se aceptarían como un estándar para los sistemas de gestión de base de datos. Sin embargo, ANSI se rehusó a aceptar o rechazó el estándar propuesto. Al reporte de 1971 siguieron muchas versiones más nuevas, notablemente en 1973, 1978, 1981 y 1984, pero siguió siendo

16 CAPÍTULO 1  Conceptos introductorios a las bases de datos

el principal documento que describía un modelo basado en red al que generalmente se le conoce como el modelo CODASYL o el modelo DBTG, y muchos sistemas de gestión de base de datos populares se basaron en él. Además, proporcionó el vocabulario y marco con­ ceptual para discutir los temas de base de datos, y estableció por primera vez la noción de una arquitectura de base de datos en capas y terminología común. El DBTG evolucionó en 1972 a un comité CODASYL permanente, el DDLC, o Data Description Language Commit­ tee (Comité de Lenguaje de Descripción de Datos), que continuó operando y publicaba sus descubrimientos periódicamente en su Journals of Development hasta 1984, cuando el comi­ té de estandarización ANSI X3H2 se apoderó de su función. A pesar del hecho de que DBTG y DDLC continuaron realizando cambios al modelo CODASYL, la proposición 1971 la usaron grandes proveedores como la base para sus sistemas de gestión de bases de datos. El más ampliamente usado de estos sistemas basados en red fue el IDMS de Cullinet. Otros incluyeron PRIME DBMS de PRIME Computer, IDS II de Honeywell, DMS 170 de Control Data Corporation, DC, DMSII y DMS1100 de UNISYS, y DBMS 10 y DBMS 11 de Digital Equipment Corporation.

Aunque los modelos jerárquico y de red eran poderosos y eficientes, eran complejos, y requerían que los usuarios entendieran las estructuras de datos y las rutas de acceso a los datos. Estaban diseñados para usarse con programas en lugar de para acceso interactivo de los usuarios, de modo que no soportaban consultas ad hoc. No estaban basados sobre un fundamento teórico sólido, sino que eran soluciones construidas sobre sistemas de archivos existentes.

El modelo relacional fue propuesto por primera vez por E. F. Codd en 1970, en un artículo llamado A Relational Model of Data for Large Shared Data Banks. Fue el primer modelo que se basó en nociones teóricas de matemáticas, que proporcionó una fuerte base teórica. La investigación sobre el modelo la realizaron Codd y otros en el IBM Research Laboratory en San José, California. System R, un prototipo de sistema de gestión de base de datos rela­ cional, lo desarrollaron investigadores de IBM a finales de la década de 1970. DB2, el siste­ ma de gestión de base de datos relacional de IBM, se basó en System R. SQL, un lenguaje desarrollado por System R, se convirtió en el lenguaje de datos estándar para las bases de datos relacionales, con estándares aprobados por ANSI publicados en 1986, 1989, 1992 y 1999. Otros tempranos proyectos de investigación de modelo relacional fueron el Peterlee Relational Test Vehicle, creado en el IBM UK Scientific Laboratory e INGRES, desarrolla­ do en la Universidad de California en Berkeley. La investigación condujo a una versión universitaria de INGRES, así como a un producto comercial. ORACLE se desarrolló y comercializó usando muchos de los resultados del System R. El extenso uso de micro­ computadoras que comenzó en la década de 1980 condujo a la creación de sistemas de ges­ tión de base de datos basados en PC, que eran todos relacionales. Entre los primeros sistemas de gestión de bases de datos relacionales basados en microcomputadora estaban dBase, R:Base, Foxpro y Paradox. Access de Microsoft, que usa el modelo relacional, ahora es el sistema de gestión de base de datos basado en microcomputadora de uso más extendi­ do. Oracle, DB2, Informix, Sybase y el Server SQL de Microsoft, que usan el modelo rela­ cional, en la actualidad son los sistemas de gestión de bases de datos empresariales más importantes.

El modelo relacional usa tablas simples para organizar datos. No permite a los diseñadores de bases de datos expresar algunas distinciones importantes cuando modelan una empresa. En 1976, P. P. Chen desarrolló un nuevo tipo de modelo, el modelo entidad-relación. Éste es un ejemplo de un modelo semántico que intenta capturar el significado de los datos que representa. El modelo entidad­relación en sí mismo se ha extendido muchas veces para hacerlo semánticamente más rico. Otros modelos semánticos para bases de datos se crearon para intentar capturar más del significado en los datos.

  resumen del capítulo 17

La necesidad de almacenar y manipular datos complejos que no es fácil modelar usando las simples tablas del modelo relacional, así como la aparición de lenguajes de programación usando el paradigma orientado a objeto, condujo al desarrollo de bases de datos orientadas a objeto en la década de 1990. Estas bases de datos se crearon para manipular los datos requeridos para aplicaciones avanzadas como sistemas de información geográfica (gis), multimedia, diseño y manufactura asistidos por computadora (CAD/CAM), y otros entor­ nos complejos. Los sistemas de gestión de base de datos relacional como Oracle agregan algunas capacidades orientadas a objeto a sus productos, lo que resulta en bases de datos híbridas objeto-relacional.

Los almacenes de datos se desarrollaron en la década de 1990 para proporcionar un méto­ do de captura de datos consolidado a partir de muchas bases de datos. Un almacén de datos por lo general guarda datos históricos acerca de una organización, con el propósito de minar datos, un proceso de análisis estadístico de datos que permite a la organización des­ cubrir las tendencias que puedan estar presentes en sus propios registros.

El amplio uso de Internet ha tenido un tremendo impacto sobre el desarrollo de las bases de datos. Internet conecta a los usuarios a una rica red de bases de datos en constante expan­ sión, y proporciona acceso a bibliotecas digitales, recursos multimedia, recursos educativos y mucho más. Los sitios de comercio electrónico proporcionan acceso a bases de datos de información acerca de productos y servicios a clientes a lo largo del mundo. Los disposi­ tivos computacionales inalámbricos y clientes pequeños como los PDA son otros desarro­ llos que permiten a los usuarios conectarse a recursos de base de datos en formas nuevas y flexibles.

––––––––

Las bases de datos se usan en cientos de miles de organizaciones que van desde grandes agencias gubernamentales hasta pequeños negocios. El estudio de la teoría, diseño y gestión de bases de datos permite maximizar sus beneficios potenciales.

En una base de datos típica, los datos se almacenan en un formato que hace fácil acceder, ya sea para consultas individuales o grandes reportes. En un entorno de base de datos integra­ da, todos los datos se mantienen en un solo repositorio llamado base de datos, y se gestiona mediante el administrador de base de datos (ABD). Todo acceso a la base de datos es a tra­ vés del sistema de gestión de base de datos (DBMS), un paquete de software que configura estructuras de almacenamiento, carga datos, proporciona acceso a programas y usuarios interactivos, formatea datos recuperados, oculta ciertos datos, realiza actualizaciones, con­ trola concurrencia y efectúa respaldos y recuperación para la base de datos. Los datos en una base de datos están integrados, son autodescriptivos y se comparten de manera concu­ rrente mediante muchos usuarios. El DBMS proporciona una interfaz de programa y una interfaz de usuario para consultas interactivas que se expresan en el lenguaje de consulta del DBMS particular. Las personas en el entorno de la base de datos integrada incluyen usua­ rios finales, programadores de aplicación y el ABD, quienes interactúan con la base de datos en diferentes formas.

Algunas de las ventajas del enfoque de base de datos integrada son compartición de datos, control de redundancia, consistencia de datos, mejora en estándares de datos, mejor seguri­ dad de datos, integridad de datos mejorada, balance de requerimientos en conflicto, econo­ mía de escala, más control sobre la concurrencia y mejores procedimientos de respaldo y recuperación. Algunas de las desventajas del enfoque de base de datos