Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Introducción a las bases de datos relacionales

432 views

Published on

Una introducción a las bases de datos, pasando por sus principios básicos, viejas confusiones con otros tipos de datos, tipos, estructuras y finalizando con una rápida, pero concisa introducción al SQL.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Introducción a las bases de datos relacionales

  1. 1. INTRODUCCION A LAS BASES DE DATOS RELACIONALES Domingo Abarca Ramírez. Diciembre de 1999, México.
  2. 2. Contenido 1-Introducción a las bases de datos _______________________________ 5 Un comentario acerca de las Bases de Datos ________________________________ 6 1.1. Definición de Base de Datos __________________________________________ 6 1.1.1. Sistemas de procesamiento de archivos________________________________ 6 1.1.2. Sistemas de procesamiento de bases de datos __________________________ 11 1.1.2.1 Conceptos de bases de datos_____________________________________ 12 Sistema manejador de bases de datos (DBMS)___________________________ 13 Datos Integrados __________________________________________________ 14 Menos duplicación de datos o no-redundancia de información ______________ 14 Independencia programas/datos ______________________________________ 15 Fácil representación de la vista de datos a los usuarios ____________________ 16 Una base de datos es autodescriptiva __________________________________ 16 Una base de datos es un conjunto de registros integrados___________________ 16 1.1.2.2. Componentes de una base de datos _______________________________ 18 Hardware y software _______________________________________________ 18 Lenguajes de bases de datos _________________________________________ 19 Lenguaje de definición de datos (DDL) ________________________________ 19 Lenguaje de manipulación de datos (DML) _____________________________ 20 Manejador de base de datos (DBMS) __________________________________ 20 Usuarios_________________________________________________________ 21 Usuarios de programas de aplicación_________________________________ 21 Programadores de aplicación _______________________________________ 22 Usuarios que utilizan los lenguajes de manipulación de información________ 22 Administrador de la base de datos (DBA) _____________________________ 23 1.1.2.3. Arquitectura de un sistema de bases de datos _______________________ 24 1.2 Tipos de bases de datos______________________________________________ 26 Base de datos tipo relacional ____________________________________________ 26 Base de datos tipo red _________________________________________________ 26 Base de datos tipo jerárquico ____________________________________________ 27 1.3 Confusiones acerca de las Bases de Datos_______________________________ 28 Advertencia: las hojas de cálculo no son bases de datos _______________________ 28 2-Fundamentos de bases de datos relacionales_____________________ 29 2.1. Diseño de bases de datos relacionales__________________________________ 30 2.1.1. Diagrama de Entidades y Asociaciones (DEA) _________________________ 31 Enfoque de Entidad-Asociación ________________________________________ 31 Componentes de un DEA _____________________________________________ 31 Componentes gráficos de un Diagrama de entidad-asociación ________________ 35 2.2. Resistencia al Modelo Relacional _____________________________________ 40
  3. 3. 3-Reglas de integridad ________________________________________ 41 3.1. Reglas de Integridad de la Base de Datos ______________________________ 42 Reglas de Integridad de Tablas __________________________________________ 42 Reglas de Integridad entre Tablas ________________________________________ 44 3.2. Propagación de Operaciones ________________________________________ 49 4-Introducción al SQL básico __________________________________ 52 4.1. ¿Que es SQL? _____________________________________________________ 53 4.2. Las funciones de SQL ______________________________________________ 53 4.3. Trabajando con SQL _______________________________________________ 55 Recuperación de datos (Select) __________________________________________ 56 La Cláusula WHERE ________________________________________________ 57 El uso de asterisco (*)________________________________________________ 58 Los operadores lógicos y el Test de rango (BetWeen) _______________________ 59 El Test de pertenencia (IN)____________________________________________ 59 Test de correspondencia con patrón (LIKE)_______________________________ 60 Filas duplicadas (DISTINCT)__________________________________________ 61 Consultas multitablas (Join) ___________________________________________ 61 Funciones de Agrupación (Sum, Avg, Count, Max, Min)______________________ 63 La función Suma (Sum) ______________________________________________ 63 La función Promedio (Avg) ___________________________________________ 65 La función Cuenta (Count)____________________________________________ 66 La función Máximo (Max) ____________________________________________ 67 La función Mínimo (Min)_____________________________________________ 69 Adición de datos (Insert) _______________________________________________ 70 Eliminación de datos (Delete) ___________________________________________ 71 Actualización de datos (Update) _________________________________________ 72 Creación de tablas (Create)____________________________________________ 73 4.4. Notas finales acerca de SQL _________________________________________ 75 5-Apéndices _________________________________________________ 76 Apéndice A: Estructura de tablas de la base de datos ejemplo NOMINA: _______ 77 Apéndice B: Contenido de tablas de la base de datos ejemplo NOMINA: _______ 78 Apéndice C: Script SQL para crear las tablas de la base de datos ejemplo NOMINA: ___________________________________________________________ 81
  4. 4. 1-Introducción a las bases de datos Los directores de empresas quieren que sus sistemas de bases de datos ¡NUNCA! fallen. No hay nada peor que llegar a depender de un sistema de información por computadora y encontrarse con que no se puede contar con él. Extraído de la revista BD Computers, artículo publicado en enero de 1992.
  5. 5. BASES DE DATOS RELACIONALES Introducción a las bases de datos © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 6 Un comentario acerca de las Bases de Datos A pesar de las múltiples confusiones conceptuales que todavía existen acerca de las bases de datos, es imposible negar que su desarrollo y avance tecnológico es a pasos agigantados, por lo que aquellos profesionales del desarrollo de software que no se actualicen en la materia, simple y sencillamente se quedarán a la zaga o al margen de la creación y operación de los nuevos y grandes sistemas de información. Hoy en día, y debido a la importancia que tiene la información en todas las organizaciones, a las bases de datos se les ha puesto gran atención y ello ha conducido al desarrollo de conceptos y técnicas para manejar los datos en forma eficiente. En este curso se estudiarán todos esos conceptos a detalle. 1.1. Definición de Base de Datos Una base de datos es un conjunto cualquiera de datos estructuralmente relacionados entre sí. Convencionalmente, los datos se organizan como un archivo de datos, el archivo consta de registros y los registros están compuestos por uno o más campos de datos, siendo los campos de un tipo de dato de un conjunto de varios tipos de datos. Sin embargo, muchas veces la definición anterior resulta demasiado pobre al usuario. Por lo mismo, para poder entender mejor lo que significa una base de datos, empezaremos por ver las particularidades de los sistemas que precedieron al uso de la tecnología de las bases de datos, es decir, los sistemas de procesamiento de archivos, ya que estos sistemas revelan los problemas que ha resuelto la tecnología de las bases de datos. 1.1.1. Sistemas de procesamiento de archivos Como se mencionó anteriormente un archivo de datos es un cúmulo de datos de diferentes tipos organizados en un mismo lugar, que es el propio archivo. Este archivo está identificado con un nombre propio y con este se le hace acceso ya sea para agregar, eliminar, modificar o solamente consultar datos.
  6. 6. BASES DE DATOS RELACIONALES Introducción a las bases de datos © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 7 El archivo está estructuralmente compuesto por registros, que son bloques contiguos identificados por un número llamado número de registro, a su vez estos registros están conformados por divisiones de menor tamaño de información llamadas campos1 , donde estos campos almacenarán cualquier tipo de datos, es decir, que estos pueden ser datos alfanuméricos o numéricos según sea la necesidad. FIGURA 1.1. Forma o estructura de un archivo de datos. En el pasado los sistemas de procesamiento de archivos eran generalmente proporcionados por el fabricante del computador (tales como la nómina y los registros de contabilidad) como parte del sistema operativo, llevaba la cuenta de los nombres y ubicaciones de los archivos. El sistema de gestión de archivos básicamente no tenía un modelo de datos, es decir, no sabía nada acerca de los contenidos internos de los archivos. Para el sistema de gestión de archivos un archivo que contuviera un documento de procesamiento de textos y un archivo que contuviera datos de nóminas simplemente no los distinguiría. El conocimiento acerca del contenido de un archivo –que datos almacena y como están organizados- estaba incorporado a los programas de aplicación que utilizaban el archivo. 1 Los títulos de los campos no son almacenados en el archivo, es decir, que no forman parte de él, aquí se presentan para una mera explicación. NomEmp DirEmp FechNac IngAnual 1 Rosalba Arciniega López Av. Michoacán 1340, Col. Progreso. 750612 50000.00 2 Domingo Abarca Ramírez Cuauhtémoc 70-B, Col. Centro 680514 3 Eva Samayoa Dorantes Gaviotas 45,Fracc. Las Playas, Caleta. 740422 60000.00 . . . 99 Alejandro Apac Sandoval Baja California 99, Col. Progreso. 690223 200000.00 100 Luis Orozco Bedolla Mina 64, Col. Centro. 660825 100000.00 Registros No. de Registro Campos alfanuméricos Campos numéricos
  7. 7. BASES DE DATOS RELACIONALES Introducción a las bases de datos © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 8 Así, tal como lo muestra la Figura 1.2. los primeros sistemas de información comerciales almacenaban grupos de registros en archivos separados. FIGURA 1.2. Aplicación de nómina utilizando un sistema de procesamiento de archivos. En esta aplicación de nómina, cada uno de los programas (hechos en COBOL) que procesaban el archivo maestro de empleados contenía una descripción de archivo (DA) que describía la composición de los datos en el archivo. Si la estructura de los datos cambiaba – por ejemplo, si un grupo adicional de datos fuera a ser almacenado por cada empleado- todos los programas que accedían al archivo tenían que ser modificados. Como el número de archivos y programas crecía con el tiempo, todo el esfuerzo de procesamiento de datos de un departamento de desarrollo se perdía en mantener aplicaciones (programas) existentes en lugar de desarrollar otras nuevas. Programa de actualización de empleados. DA Archivo maestro de empleados Programa de informe de empleados. DA Archivo de historia de sueldos Programa de impresión de cheques. DA DA Usuario del sistema de nómina.
  8. 8. BASES DE DATOS RELACIONALES Introducción a las bases de datos © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 9 Aunque los sistemas de procesamiento de archivos representan una significativa mejoría sobre los sistemas manuales de registro, estos tienen importantes limitaciones:  Los datos están separados y aislados.  Con frecuencia, los datos están duplicados.  Los programas de aplicación dependen de los formatos de los archivos.  Con frecuencia, los archivos son incompatibles entre sí.  Es difícil representar los datos en el modo en que los usuarios los ven. Veamos cada uno de estas limitaciones por separado.  Datos separados y aislados El usuario de la Figura 1.2 necesita relacionar a los empleados con cada uno de los sueldos que les corresponde para poder así imprimir el cheque de su pago adecuadamente. En este caso los datos necesitan extraerse de algún modo de los archivos de empleados y de historia de sueldos y combinarse en un archivo sencillo donde estarán los datos deseados que serán impresos. Con el procesamiento de archivos, tal cuestión es difícil. Los analistas de sistemas y los programadores deben determinar cuáles partes de cada archivo son necesarias; deben también decidir cómo se relacionan los archivos entre sí y deben coordinar el procesamiento de los archivos de modo tal que se extraigan los datos correctos. FIGURA 1.3. En un sistema de procesamiento de archivos extraer los datos suele ser muy complicado. Coordinar dos archivos es muy difícil, imagínese la tarea de coordinar diez o más de ellos, simple y sencillamente es una tarea titánica. Como si fuera tan sencillo, con este “desm...” de datos que tiene aquí...Necesito esos reportes para hoy a las 4:00 p.m. Gómez. Sí señor. Pondré todo mi esfuerzo.
  9. 9. BASES DE DATOS RELACIONALES Introducción a las bases de datos © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 10  Duplicación de los datos En el ejemplo de la nómina puede almacenarse varias veces el nombre de un empleado, así como sus otros datos. Los datos se almacenan una vez para el archivo de empleados y de nuevo en el archivo de historia de sueldos para cada sueldo que el empleado ha tenido a lo largo de su estancia en la empresa. Los datos duplicados desperdician espacio para archivos, lo cual no es el problema más serio. La dificultad significativa de la duplicación de los datos tiene que ver con la integridad de la información. Un conjunto de datos tiene integridad si son consistentes, si se ensamblan entre sí. Con frecuencia en los sistemas de procesamiento de archivos se aprecia una pobre integración de los datos. Por ejemplo si un empleado cambia su número de identificación o su dirección, deben actualizarse todos los archivos que contienen sus datos; el peligro reside en que todos los archivos pudieran no actualizarse, causando discrepancias. Los problemas de integridad de los datos son serios. Si los contenidos de los datos difieren producirían resultados inconsistentes. Si un reporte de una aplicación es diferente al de otra aplicación, ¿quién decidiría cuál es la correcta?. Cuando los resultados son inconsistentes se duda de la credibilidad de los datos almacenados, e incluso de la función misma del sistema.  Dependencia del programa de aplicación Con el procesamiento de archivos, los programas de aplicación dependen de los formatos del archivo. En estos sistemas los formatos físicos de los archivos y los registros son parte del código de la aplicación. El problema con esta forma de trabajar es que cuando se hacen cambios en los formatos de los archivos, también deben modificarse los programas de aplicaciones.  Archivos incompatibles Una de las consecuencias de la dependencia de los datos del programa es que los formatos del archivo dependen del lenguaje o del producto usado para generarlos. El formato de un archivo procesado por un programa COBOL es diferente al de un programa BASIC, que es distinto al de un archivo procesado por un programa en lenguaje C.  La dificultad de representar los datos como los ve el usuario Es difícil representar los datos del procesamiento de archivos en una forma que parezca natural a los usuarios. Los usuarios quieren ver los datos de un empleado en un formato como el que se presenta a continuación:
  10. 10. BASES DE DATOS RELACIONALES Introducción a las bases de datos © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 11 FIGURA 1.4. Formato de pantalla deseada por el usuario para una aplicación. Para mostrar los datos de este modo es necesario extraer, combinar y presentar juntos varios archivos diferentes. Esta dificultad surge porque con el procesamiento de archivos no se representan o procesan con sencillez las relaciones entre los registros. Debido a que un sistema de procesamiento de archivos no puede determinar con rapidez cuáles EMPLEADOS son los que se desean presentar con su SUELDO actual, es difícil producir una forma que muestre los datos solicitados. 1.1.2. Sistemas de procesamiento de bases de datos Los problemas de mantener grandes sistemas basados en archivos condujeron a finales de los sesenta al desarrollo de los sistemas de gestión de base de datos. La idea detrás de estos sistemas era sencilla: tomar la definición de los contenidos de un archivo y la estructura de los programas individuales, y almacenarla, junto con los datos, en una base de datos. Utilizando la información de la base de datos el manejador (llamado DBMS) que la controla puede tomar un papel mucho más activo en la gestión de los datos y en los cambios a la estructura de la base de datos. Empresa X S.I.I.G.Y. DD/MM/AA Nómina Consultor de Empleados consnom.exe Sucursal: 12 Renacimiento Tipo de Empleado: 01 Confianza Id. Emp. Nombre: Dirección: Sueldo: 600234 Samayoa Dorantes Eva xxxx 5000.00 609314 García Hernández Fidel xxxx 6000.00 601256 Ramos Baños Luis xxxx 7000.00 602567 Viilegas Reyes Josefina xxxx 5000.00 605621 Hernández Bravo Juan Miguel xxxx 8000.00 609152 Olivar Campos Víctor xxxx 8500.00 601045 Cortez Dillanes Marco Antonio xxxx 9000.00
  11. 11. BASES DE DATOS RELACIONALES Introducción a las bases de datos © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 12 La tecnología de las bases de datos se desarrolló para superar las limitaciones de los sistemas de procesamiento de archivos. Compare el sistema de procesamiento de archivos de la Figura 1.2 con el sistema de bases de datos para la misma nómina en la figura siguiente: FIGURA 1.5. Aplicación de nómina utilizando un sistema de procesamiento de base de datos. Los programas de procesamiento de archivos acceden a los archivos de los datos almacenados. En contraste, los programas de procesamiento de base de datos acuden al DBMS para acceder a los datos almacenados. Esta diferencia es significativa: hace más fácil la tarea de programar la aplicación. Los programadores no deben preocuparse por las formas en que los datos se almacenan. Más bien quedan libres para concentrarse en cuestiones importantes para el usuario, y no con aspectos del sistema de computación. 1.1.2.1 Conceptos de bases de datos Ahora bien, el término base de datos permite distintas interpretaciones. Ha sido usado para referirse tanto a un conjunto de tarjetas índice como a los millones y millones de datos que un gobierno recopila acerca de sus ciudadanos. Usaremos el término con un significado específico: una base de datos es un conjunto autodescriptivo de registros integrados controlados por un DBMS. Es importante comprender cada parte de tal descripción. Aplicación(es) de base de datos DBMS Base de datos Usuario del sistema de nómina.
  12. 12. BASES DE DATOS RELACIONALES Introducción a las bases de datos © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 13 Sistema manejador de bases de datos (DBMS) Un sistema manejador de bases de datos (Database Management System, DBMS), consiste en un conjunto de datos relacionados entre sí y un grupo de programas que les den acceso. El conjunto de datos se conoce comúnmente como base de datos. Las bases de datos generalmente contienen información acerca de una empresa determinada. El objetivo primordial de un DBMS es crear un ambiente en el que sea posible guardar y recuperar información de la base de datos en forma eficiente; es decir, permitir a los usuarios trabajen o traten con los datos en forma simple, sin necesidad de atender la forma en que la computadora los almacena. En este sentido, el DBMS actúa como intérprete de un lenguaje de alto nivel. Los sistemas de bases de datos se diseñan para manejar grandes volúmenes de información a sabiendas que la cantidad de usuarios que la utilicen será considerable, tal como se puede esquematizar en la Figura 1.6. El manejo de los datos incluye tanto la definición de las estructuras como los mecanismos para el acceso de la información. Además, el sistema de bases de datos cuida la seguridad de la información almacenada en la base de datos, tanto contra las caídas del sistema, como contra los intentos de acceso no autorizado. Si los datos ven a compartirse para varios usuarios, el sistema debe proteger que al efectuar modificaciones no se encuentren resultados que presenten inconsistencias. FIGURA 1.6. Esquematización de la labor de un DBMS. DBMS Base de Datos
  13. 13. BASES DE DATOS RELACIONALES Introducción a las bases de datos © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 14 Como se aprecia en la figura anterior, puede haber un gran número de usuarios trabajando en la base de datos que puede estar almacenada en un servidor (llamado servidor de base de datos), si no existiese el DBMS el control y distribución de los datos para cada uno de los usuarios sería un verdadero caos. Por ejemplo, si más de uno tratara de leer la misma información al mismo tiempo el resultado de dicha consulta sería desastroso en la confiabilidad de la respuesta y lento en el proceso de la misma. Para evitar esto, cada uno de ellos tendría que programar sus tiempos de consulta de tal forma que no afectasen o chocasen con los demás. Por el contrario, con la existencia del DBMS esto es más sencillo, pues el se encarga de todos estos aspectos y de muchos otros más evitando así, la pérdida de tiempo e información. Datos Integrados En un sistema de base de datos todos los datos de la aplicación se almacenan en un medio sencillo llamado base de datos. Un programa de aplicación puede pedirle al DBMS que acceda a datos en particular como los datos personales de un empleado, sus impuestos retenidos, su historia de sueldos, o todos al mismo tiempo. Si todos se necesitan el programador de la aplicación solo especifica como deberán combinarse los datos y el DBMS realiza las operaciones necesarias para conseguirlo. El programador no es responsable de escribir los programas para coordinar los archivos, lo cual si debe hacer para el sistema de la Figura 1.2. Menos duplicación de datos o no-redundancia de información ¿Que es la redundancia de información? Supóngase que en un sistema de procesamiento de archivos se tiene el archivo de pedidos que se muestra en la Figura 1.7(a) y el archivo de conceptos de la Figura 1.7(b). Como se observa, el DescConcepto se encuentra en ambos archivos, lo cual provoca dos inconvenientes: por un lado se desperdicia espacio ya que tal campo es demasiado grande y la relación entre ambas archivos debería haberse dado a través de la clave del concepto, que es un campo de menor tamaño. Por otro lado, el problema principal radica en que la integridad de los datos puede verse en peligro si se decide cambiar DescConcepto del archivo de conceptos, ya que en el archivo de pedidos ese campo se encuentra en varios renglones, esto implica que habría que hacer la actualización en cada uno de ellos.
  14. 14. BASES DE DATOS RELACIONALES Introducción a las bases de datos © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 15 Num_Pedido Fecha DescConcepto 23455 13/01/92 Computadoras ATT 24879 17/01/92 Drives de 5 ¼ “ 34488 20/01/92 Monitores de color 23455 13/01/92 Computadoras ATT 34488 20/01/92 Monitores de color 23455 13/01/92 Computadoras ATT a) Archivo de pedidos Clave_Concepto DescConcepto 23455 Computadoras ATT 24879 Drives de 5 ¼ “ 34488 Monitores de color b) Archivo de conceptos FIGURA 1.7. Redundancia de información en los archivos. El problema se amplía si se piensa en que existiesen otros archivos como facturas, notas de crédito, recibidos, pólizas, etc., que tuviesen relación con el archivo de conceptos y estuvieran representados de la misma forma. Con el procesamiento de base de datos, es mínima la duplicación o redundancia de datos. En una base de datos bien definida como la de la Figura 1.5, el problema de los archivos anteriormente descritos simplemente no existiría, pues el campo DescConcepto se almacenaría solo una vez, es decir, en un solo archivo. Siempre que el DBMS necesite estos datos puede traerlos y solo es necesaria una operación para modificarlos. Debido a que estos datos se almacenan en un sólo lugar, resultan menos comunes los problemas de integridad de datos; hay menor oportunidad de discrepancias entre las múltiples copias de los mismos elementos de datos. Independencia programas/datos El procesamiento de base de datos hace que los programas dependan menos de los formatos de los archivos. Los formatos de registro se almacenan en la misma base de datos (junto con los datos) y son accedidos por el DBMS, no por los programas de aplicación. A diferencia de los programas de procesamiento de archivos, los programas de aplicación de base de datos no necesitan incluir el formato de los registros y los archivos que procesan.
  15. 15. BASES DE DATOS RELACIONALES Introducción a las bases de datos © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 16 Fácil representación de la vista de datos a los usuarios La tecnología de base de datos hace posible representar de un modo directo a los objetos en el universo del usuario. Por ejemplo, las formas como la de la Figura 1.4. pueden producirse a partir de una base de datos, ya que están almacenadas en ella relaciones entre los registros de los datos. Una base de datos es autodescriptiva Una base de datos es autodescriptiva: Además de los datos fuente del usuario contiene también una descripción de su propia estructura. Tal descripción es conocida como diccionario de datos (o directorio de datos o metadatos). El diccionario de datos vuelve posible la independencia entre el programa y los datos. En este sentido, una base de datos es similar a una biblioteca. Que es un conjunto autodescriptivo de libros. Además de libros, la biblioteca contiene un catálogo de tarjetas que los describen. En la misma forma, el diccionario de datos (que es parte de la base de datos, tanto como el catálogo es parte de la biblioteca) describe los datos contenidos en la base de datos. ¿Por qué es importante esta característica de autodescripción de una base de datos?. Porque promueve la independencia programa/datos, hace posible determinar la estructura y el contenido de la base de datos examinando la base de datos misma. No se requiere adivinar que contiene la base de datos ni mantener documentación externa del archivo y los formatos de registro, como se hace en los sistemas de procesamiento de archivos. Si cambia la estructura de los datos en la base de datos (por ejemplo cambiar anchura de campos o agregar más campos a un registro existente), solo se introduce el cambio al diccionario de datos. Necesitan cambiarse pocos programas (sí tal es el caso). En la mayoría de los casos, solo deben alterarse los programas que procesen los datos modificados. Una base de datos es un conjunto de registros integrados La jerarquía normal de los datos es la siguiente: Los bits conforman bytes o caracteres; los caracteres constituyen campos; los campos integran registros y los registros componen archivos(véase Figura 1.8(a).). Es tentador seguir la tendencia precedente y decir que los archivos conforman bases de datos. Aunque tal expresión es verdadera no va muy lejos.
  16. 16. BASES DE DATOS RELACIONALES Introducción a las bases de datos © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 17 FIGURA 1.8. Jerarquía de los elementos: (a) Jerarquía de datos en el procesamiento de archivos y (b) Jerarquía de elementos de datos en el procesamiento de base de datos. Una base de datos incluye archivos de datos del usuario y más. Como se mencionó, una base de datos contiene una descripción de sí misma en los metadatos. Una base de datos incluye índices que se usan para representar las relaciones entre los datos y para mejorar el desempeño de las aplicaciones de la base de datos. La base de datos contiene a veces información de las aplicaciones que la utilizan. La estructura de las formas de entrada de datos o de un reporte es parte de la base de datos. La última categoría de datos denominados metadatos de aplicación. Una base de datos contiene los cuatro tipos de datos mostrados en la Figura 1.8(b): archivos de datos del usuario, metadatos, índices y metadatos de aplicación. ArchivosBits Bytes o Caracteres Campos Registros a) Bits Bytes o Caracteres Campos Registros b) Archivos + Metadatos + Índices + Metadatos de aplicación . Base de datos
  17. 17. BASES DE DATOS RELACIONALES Introducción a las bases de datos © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 18 1.1.2.2. Componentes de una base de datos La arquitectura de una base de datos es compleja y está compuesta por una gran cantidad de elementos. Enseguida se analiza cada componente. Hardware y software A medida que el costo del hardware de las computadoras disminuye debido a las nuevas tecnologías, los sistemas de computación se están desarrollando cada vez en mayor número. Así, el hardware necesario para hacer frente a los grandes sistemas de computación puede constituirse a un precio moderado. El hardware se compone de dispositivos de almacenamiento secundario como discos duros, cintas magnéticas, discos ópticos etc., donde reside la base de datos física, junto con un dispositivo asociados como unidades de control. Por lo que respecta al software, los sistemas de base de datos están compuestos por un conjunto de programas. En el nivel más alto, se encuentra el DBMS que es un conjunto de programas que manipulan estructuras de datos complejas para definir, manipular y consultar los datos. El usuario no necesita preocuparse por la forma en la que el DBMS realiza sus funciones y los programadores de aplicaciones deben conformar sus programas sobre la base de un lenguaje de alto nivel que interacciones con el manejador de la base de datos. Esto es, los programas se construyen atendiendo dos objetivos básicos: dar acceso a la base de datos y crear una interfaz con el usuario, que se encargue de solicitar los datos que se desean consultar, insertar o eliminar. Los lenguajes con los que se construye la interfaz pueden ser de tercera o cuarta generación y se les conoce como lenguajes anfitriones. Dentro del primer grupo, se encuentran los lenguajes de propósito general; en ellos, la estructura de los programas de aplicación debe construirse mediante programación tradicional, es decir, deben crearse funciones para conformar el ambiente sobre el que debe ejecutarse la aplicación, tales como ventanas, menús y capturas; así mismo deben validarse los datos y los procesos y cuando se requiere, hacer uso de las funciones que proporciona el DBMS. La programación de este tipo de sistemas es sumamente flexible, aunque complicada de realizar. Un lenguaje de alto nivel de tercera generación del tipo de Pascal, C, Modula2, APL, etc., no restringe ningún tipo de proceso y la interfaz puede programarse de acuerdo al gusto más exigente del usuario.
  18. 18. BASES DE DATOS RELACIONALES Introducción a las bases de datos © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 19 Los lenguajes de cuarta generación para construcción de sistemas de información que utilizan bases de datos, son de propósitos específico y contienen las funciones suficientes para generar fácilmente una interfaz y ligar el diseño de pantalla de captura, menús y reportes a la base de datos. Este tipo de lenguajes permiten realizar sistemas de manera simple y eficaz, pero generalmente son inflexibles. El usuario debe saber que su sistema desarrollado bajo un lenguaje de este tipo estará limitado a las capacidades de la herramienta. Estas limitaciones no afectan los accesos a la base de datos, sino a la forma en la que los programas de aplicación presentan, solicitan o reportan la información. Los accesos a la base de datos también se llevan a cabo a través del DBMS, cuyas funciones se encuentran inmersa en los programas de aplicación. Lenguajes de bases de datos En el mundo de las bases de datos es normal separar las funciones de computación en dos partes y dos diferentes lenguajes. Esto es porque en un programa normal, las variables de programa existen sólo mientras el programa está ejecutándose; en un sistema de bases de datos, los datos existen siempre y pueden ser declarados una vez para todos los programas. Esto da origen a los lenguajes de definición de datos y al de manipulación de datos. Lenguaje de definición de datos (DDL) Un esquema de la base de datos se especifica por medio de una serie de definiciones que se expresan en un lenguaje especial llamado lenguaje de definición de datos (Data Definition Language, DDL). El resultado de la compilación de las sentencias en el DDL es un conjunto de tablas que se almacenan en un archivo especial llamado diccionario de datos. Un diccionario de datos es un archivo que contiene metadatos, es decir, datos acerca de los datos. La estructura de almacenamiento y los métodos de acceso empleados por el sistema de bases de datos se especifican por medio de un conjunto de definiciones de un tipo especial de DDL llamado lenguaje de almacenamiento y definición de datos. El resultado de la compilación de estas definiciones es una serie de instrucciones que especifican los detalles de implantación de los esquemas de bases de datos que normalmente no pueden ver los usuarios.
  19. 19. BASES DE DATOS RELACIONALES Introducción a las bases de datos © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 20 Lenguaje de manipulación de datos (DML) Este lenguaje es utilizado para realizar las diferentes operaciones sobre la base de datos sin que el usuario tenga que hacer complicados programas para ello y al mismo tiempo saber detalles físicos a cerca de los datos. La manipulación que se hace con este lenguaje consiste en lo siguiente:  Recuperación de información almacenada en la base de datos.  Inserción de información nueva en la base de datos.  Modificación y eliminación de información de la base de datos. Lo importante que debe cumplir este lenguaje es la facilidad de uso. El objetivo es lograr una interacción eficiente entre los usuarios y el sistema. Un lenguaje de manipulación de datos (Data Manipulation Language, DML) permite a los usuarios manejar o tener acceso a los datos que estén expresados por medio del modelo apropiado. Existen básicamente dos tipos de DML:  Procedimental Necesita que el usuario especifique cuáles datos quiere y cómo deben obtenerse.  No procedimental Requiere que el usuario especifique solamente cuáles datos quiere. Una consulta es una sentencia que solicita la recuperación de información. La parte de un DML que realiza esta labor se llama lenguaje de consultas. Manejador de base de datos (DBMS) El manejador de base de datos es un módulo de programas que constituye la interfaz entre los datos de bajo nivel almacenados, los programas de aplicaciones y las consultas hechas al sistema. El manejador de base de datos es responsable de las siguientes tareas:  Interacción con el manejador de archivos.  Implantación de la integridad.  Puesta en práctica de la seguridad.  Respaldo y recuperación.  Control de concurrencia.
  20. 20. BASES DE DATOS RELACIONALES Introducción a las bases de datos © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 21 Usuarios En un sistema de bases de datos existe una gran diversidad de usuarios, cada uno, tiene necesidades específicas y visualiza el sistema de manera distinta. Enseguida se da un perfil de cada uno de ellos. Usuarios de programas de aplicación El primer tipo de usuario de un sistema es el que utiliza los servicios para los que fue realizado, es decir, un sistema resuelve problemas concretos a través de la ejecución de programas. FIGURA 1.9. Los usuarios de aplicaciones de bases de datos no necesitan saber datos técnicos acerca de esta y tampoco que manejen algún lenguaje de programación. Estos usuarios no están obligados más que a tener conocimiento sobre la forma de uso del programa y los resultados que éste genera, también tienen acceso limitado a la información de la base de datos y están sujetos sólo a lo que la aplicación les proporcione. Voy a accesar al sistema de contabilidad...
  21. 21. BASES DE DATOS RELACIONALES Introducción a las bases de datos © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 22 Programadores de aplicación Estos usuarios construyen los programas de aplicación, que están compuestos de las instrucciones necesarias para poder acceder a la base de datos. Estos programas en conjunto, realizan una función específica del sistema de computación de la organización en donde se ubican y están escritos en lenguajes de alto nivel, los cuales pueden ser de dos tipos: lenguajes de 3a. generación (3GL) o de 4a generación (4GL) (aunque últimamente se les está abriendo paso a los de 5ª generación). Los primeros son lenguajes de propósito general, como C, Pascal, FORTRAN, COBOL, y otros. Los segundos son lenguajes especializados para la construcción de interfaces para sistemas de información y manipulación de datos a través de lenguajes de bases de datos como SQL, QUEL, etc. FIGURA 1.10. Los programadores de aplicaciones de bases de datos son los que diseñan las aplicaciones que utilizarán usuarios como el de la Figura 1.9. Es necesario que conozcan datos técnicos acerca de la base de datos y que manejen lenguajes de programación. Usuarios que utilizan los lenguajes de manipulación de información En diversos sistemas, existen usuarios que no pueden esperar a que los programadores de aplicación construyan los programas que producirán la información que necesitan; estos usuarios son inquietos y por lo regular tienen gran iniciativa, por ello, no les importa aprender los lenguajes de manipulación para poder acceder directamente a la base de datos y ala información que necesitan. SELECT a.nomcia, a.rfccia FROM tacias a WHERE a.idcia = :fidcia; COMMIT;
  22. 22. BASES DE DATOS RELACIONALES Introducción a las bases de datos © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 23 Administrador de la base de datos (DBA) El administrador de la base de datos (Database Administrator DBA), es un usuario (o usuarios) que realiza el control centralizado tanto de los datos como de los programas. Es muy necesario que este conozca todo lo referente a la base de datos, desde los metadatos hasta los lenguajes de consulta que esta base de datos soporte. FIGURA 1.11. El administrador de la base de datos (DBA) debe proporcionar múltiples servicios a todos los usuarios de la misma, es decir, a los usuarios anteriormente descritos. Las funciones del administrador de la base de datos son las siguientes:  Definición del esquema de la B.D.  Creación original en la descripción de la estructura de la base de datos y la forma en que la estructura es reflejada por los archivos de la base de datos física.  Asigna del acceso a la base de datos; da la información o parte de ella a los usuarios.  Modificación de la descripción de la base de datos y reparación de daños por fallas de hardware o software.  Especificación de las limitantes de integridad.
  23. 23. BASES DE DATOS RELACIONALES Introducción a las bases de datos © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 24 1.1.2.3. Arquitectura de un sistema de bases de datos Un sistema de base de datos se divide en módulos que se encargan de cada una de las tareas del sistema general. Algunas de las funciones del sistema de base de datos pueden ser realizadas por el sistema operativo. En la mayoría de los casos, el sistema operativo proporciona sólo los servicios más elementales y la base de datos debe partir de ese fundamento. Así, el diseño de la base de datos debe incluir la consideración de la interfaz entre el sistema de base y el sistema operativo. Un sistema de base de datos se divide en varios componentes funcionales, entre los que se cuentan los siguientes.  Manejador de archivos  Manejador de base de datos  Procesador de consultas  Precompilador de DML  Compilador de DDL Además, se requieren varias estructuras de datos como parte de la implantación del sistema físico, tales como:  Archivos de datos  Diccionario de datos  Índices
  24. 24. BASES DE DATOS RELACIONALES Introducción a las bases de datos © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 25 Usuarios de las aplicaciones Programadores de las aplicaciones Usuarios Casuales Administrador de la base de datos Precompilador de lenguaje de manejo de datos Procesador de consultas Precompilador de lenguaje de definición de datos Manejador de base de datos Manejador de archivos Consulta Código objeto de los programas de aplicación Archivos de datos Almacenamiento en disco DBMS La Figura 1.12 muestra los componentes de un sistema de base de datos y las conexiones entre ellos. FIGURA 1.12. Estructura del sistema de base de datos Código fuente de los programas de aplicación Programas de aplicación Esquema de la base de datos Diccionario de datos
  25. 25. BASES DE DATOS RELACIONALES Introducción a las bases de datos © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 26 1.2 Tipos de bases de datos Los tipos de bases de datos más comúnmente utilizados son bases de datos fundamentadas en la distribución de sus datos a través de registros (similar a los registros de archivos).  Base de datos tipo relacional  Base de datos tipo red  Base de datos tipo jerárquico Enseguida se bosquejan cada uno de ellos. Base de datos tipo relacional Los datos y las relaciones entre ellos se representan por medio de tablas, cada una de las cuales tienen varias columnas con nombres únicos. Este será uno de los temas fundamentales de este curso debido a que alrededor de este modelo están basados la mayoría de los DBMS. Base de datos tipo red Los datos en este modelo se representan por medio de registro (en el sentido que la palabra tiene en Pascal o PL/1) y las relaciones entre los datos se establecen por medio de ligas, que pueden considerarse como apuntadores. Los registros de la base de datos se organizan en forma de conjuntos de gráficas arbitrarias. La Figura 1.13 muestra un ejemplo de este modelo, estableciendo la relación entre alumnos y grupos en un sistema de control escolar. FIGURA 1.13. Ejemplo de una base de datos de red. 81315 José Luís Martínez 83534 Alberto López 85555 Beatriz Álvarez 87221 Mario Martínez CA-10 Matutino CB-09 Matutino CF-07 Vespertino
  26. 26. BASES DE DATOS RELACIONALES Introducción a las bases de datos © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 27 Base de datos tipo jerárquico El modelo jerárquico es similar al de red en cuanto a que los datos y las asociaciones se representan por medio de registros, y ligas, respectivamente. Sin embargo, el modelo jerárquico difiere del de red en que los registros están organizados como árboles y no como gráficas arbitrarias. En la Figura 1.14 se muestra un ejemplo de este modelo. FIGURA 1.14. Ejemplo de una base de datos jerárquica. Las bases de datos en red y jerárquicas son bastante eficientes al momento de extraer de ellas la información, más, sin embargo, también tiene sus desventajas. La estructura de estas resulta ser muy rígida. Las relaciones de conjunto y la estructura de los registros tiene que ser especificadas de antemano. El modificar la estructura de la base de datos requiere típicamente la reconstrucción de la base de datos completa. Estas bases de datos son herramientas específicas para programadores, pues es muy difícil que un usuario común extraiga información de ellas por la estructura compleja que estas guardan. Aun así un programador experto muchas veces tiene que escribir un programa que recorra el camino complicado hacia los datos solicitados a través de estas bases de datos. La anotación de las peticiones para informes a medida dura con frecuencia semanas o meses, y para el momento en que el programa está escrito la información con frecuencia ya no merece la pena. Estos dos tipos de bases de datos son muy poco utilizados hoy en día, pues han sido suplantadas exitosamente por las bases de datos relacionales. 81315 José Luís Martínez 83534 Alberto López 85555 Beatriz Álvarez 87221 Mario Martínez CA-10 Matutino CB-09 Matutino CF-07 Vespertino Alumnos CA-10 MatutinoCB-09 Matutino
  27. 27. BASES DE DATOS RELACIONALES Introducción a las bases de datos © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 28 1.3 Confusiones acerca de las Bases de Datos En 1979 una pequeña compañía llamada Ashton-Tate introdujo un producto para microcomputadoras llamado dBase II y lo denominó un DBMS relacional. En una táctica promocional muy exitosa, Ashton-Tate distribuyó casi gratis más de cien mil copias de su producto a compradores de las nuevas microcomputadoras Osborne. Muchas de las personas que compraron estas computadoras fueron pioneros en la industria de las microcomputadoras. Empezaron a inventar aplicaciones de microcomputadora usando dBase y el número de aplicaciones de dBase creció con rapidez. Ashton-Tate se volvió una de las primeras grandes corporaciones en la industria de las microcomputadoras, después fue comprada por Borland, que ahora vende la línea de productos dBase. Sin embargo, el éxito de este producto confundió y embrolló el tema del procesamiento a través de bases de datos. El problema era el siguiente: de acuerdo con la definición de base de datos relacional, dBase II no era ni DBMS ni relacional (aunque era comercializado como sí fuera ambos). De hecho era un lenguaje de programación con capacidades generalizadas de procesamiento de archivos (no de procesamiento de base de datos). Los sistemas que se desarrollaron con dBase II se parecían más a los mostrados en la Figura 1.2 que a los mostrados en la Figura 1.5. Alrededor de un millón de usuarios de dBase II creían que estaban usando un DBMS relacional cuando en realidad no era así. Los términos sistema de administración de base de datos y base de datos relacional se usaron de manera vaga en el inicio del auge de las microcomputadoras. La mayor parte de las personas que procesaban una base de datos en microcomputadoras lo que hacían era trabajar con archivos y no aprovechaban el procesamiento de una base de datos, aunque no se dieran cuenta. Aunque hoy existen supuestas nuevas versiones mejoradas de dBase y otras herramientas como FoxPro, Paradox, Revelation, Clipper y Access por nombrar algunas, la verdad es que todavía distan mucho de ser verdaderos DBMS. Debido a esto, los vendedores de reales DBMS relacionales como Oracle, Focus e Ingres han trasladado sus productos de macro y minicomputadoras a microcomputadoras con un éxito rotundo, a tal grado de incorporar sus propios lenguajes 4GL y 5GL como herramientas de desarrollo de sus propias bases de datos. Advertencia: las hojas de cálculo no son bases de datos Antes de concluir este tema, es importante aclarar el concepto falso acerca del término base de datos. La mayor parte de las hojas de cálculo populares como Lotus 1-2-3, Excel y Quatro Pro contienen características y funciones que han sido denominadas de bases de datos, emplean este término en forma muy imprecisa, en desacorde con la realidad. Una hoja de cálculo solo tiene una pequeña parte de la funcionalidad que se espera de una base de datos y de un DBMS, y para terminar rápido con el comentario, simple y sencillamente violan casi todas (sino es que todas) las características de una verdadera base de datos.
  28. 28. 2-Fundamentos de bases de datos relacionales El diseño de una base de datos no es una cosa fácil. El crear adecuadamente entidades con sus relaciones, reglas que cuiden la integridad y todo aquello que respete y asuma los líneamientos de una base de datos y que permita su permanencia en el tiempo, implica un verdadero esfuerzo de muchas horas que solo la gente con experiencia en el ramo lo puede hacer. Es por eso que hoy cualquier profesional de esta área tendrá siempre las puertas abiertas en cualquier organización que se dedique al desarrollo del buen software. Dave M- Kroenke, asesor externo de sistemas, y catedrático de UCLA. Abril de 1993.
  29. 29. BASES DE DATOS RELACIONALES Fundamentos de Bases de Datos Relacionales © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 30 2.1. Diseño de bases de datos relacionales Las desventajas de los modelos jerárquicos y en red condujeron a un intenso interés en el nuevo modelo2 de datos relacional cuando fue escrito por primera vez por el Dr. Codd en 1970. El modelo de datos relacional simplifica la estructura de la base de datos. Elimina las estructuras explícitas padre/hijo que contienen las bases de datos jerárquicas y en red, y en su lugar representa todos los datos en la base de datos como sencillas tablas fila/columna de valores de datos. La Figura 2.1 muestra una versión relacional de la base de datos en red y jerárquica de las Figuras 1.13 y 1.14. FIGURA 2.1. Ejemplo de una base de datos relacional. El Dr. Codd escribió un artículo en 1985 estableciendo doce reglas a seguir por cualquier base de datos que se llamara “verdaderamente relacional”. Las doce reglas de Codd han sido aceptadas desde entonces como la definición de un DBMS verdaderamente relacional. Sin embargo, es más fácil comenzar con una definición más informal. Una base de datos relacional es una base de datos en donde todos los datos visibles al usuario están organizados estrictamente como tablas de valores, y en donde todas las operaciones de la base de datos operan sobre esas tablas. Tal vez en este momento parezca un poco complejo la manera en que los datos han sido distribuidos en la base de datos relacional de la Figura 2.1, porque realmente esta base de datos no está debidamente diseñada, sin embargo, esta confusión quedará disuelta al introducirnos en el tema Diagramas de Entidades y Asociaciones que es propio de las bases de datos relacionales. 2 A los tipos de bases de datos también se les conoce como modelos de datos. Tabla ALUMNOS CONTROL NOMBRE 81315 José Luís Martínez 83534 Alberto López 85555 Beatriz Álvarez 87221 Mario Martínez Tabla GRUPOS GRUPO TURNO CA-10 Matutino CB-09 Matutino CF-07 Vespertino
  30. 30. BASES DE DATOS RELACIONALES Fundamentos de Bases de Datos Relacionales © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 31 2.1.1. Diagrama de Entidades y Asociaciones (DEA) Son la herramienta más conveniente para el diseño de la base de datos relacional. Originalmente presentan conjuntos de entidades, relaciones y atributos, pero después se le agregan otros elementos. Enfoque de Entidad-Asociación El modelo de entidad-asociación (E-A) se basa en una percepción de un mundo real, que consiste en un conjunto de objetos básicos llamados entidades y de las asociaciones entre esos objetos. Este modelo se desarrolló para facilitar el diseño de bases de datos permitiendo especificar el esquema de cualquier sistema de información. Componentes de un DEA Una entidad es un objeto que existe y puede distinguirse de otros. La distinción se logra asociando a cada entidad un conjunto de atributos que describen al objeto. Por ejemplo, los atributos número y saldo describen una entidad Cuenta en un banco. La asociación es el vínculo que existe entre varias entidades. Por ejemplo una asociación Cliente-Cuenta relaciona una entidad Cliente con cada una de las Cuentas que tiene. El conjunto de todas las entidades y asociaciones del mismo tipo se denomina conjunto de entidades y conjunto de asociaciones, respectivamente. Además, este modelo permite establecer los requisitos que debe cumplir una base de datos. Uno de estos requisitos importantes es la funcionalidad, que expresa el número de entidades con las que puede asociarse otra entidad por medio de un conjunto de asociaciones. Un diagrama de entidad-asociación queda constituido por entidades, atributos que las distinguen y asociaciones que las relacionan. Enseguida se describen cada uno de ellos. Entidades Una entidad es un objeto que existe y es distinguible; por ejemplo, una silla, un auto, un alumno, una cuenta, etc. Un grupo de entidades similares compone un conjunto de entidades. El conjunto de todas las personas que tienen una cuenta en el banco, por ejemplo, puede definirse como el conjunto de entidades CuentaHabientes. En forma similar el conjunto de todos los libros de una biblioteca puede definirse como el conjunto de entidades Libros. Atributos Como las entidades tienen propiedades, éstas se incluyen en el modelo entidad- asociación y se les llaman atributos. Por ejemplo, los posibles atributos del conjunto
  31. 31. BASES DE DATOS RELACIONALES Fundamentos de Bases de Datos Relacionales © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 32 de entidades Libros son número_adquisición, título, autor, colocación, tema, editorial, páginas, país. Para cada atributo existe un conjunto de valores permitidos, llamado dominio. Así, el dominio del atributo título podría ser el conjunto de todas las cadenas de caracteres de cierta longitud. Por lo que se dice que una ocurrencia de un conjunto de entidades es una instancia específica de una entidad. Usualmente los dominios son enteros, reales, cadenas de caracteres, etc. Para definir el concepto de atributo, veamos un ejemplo de préstamo de libros, definiendo dos entidades participantes que son libros y usuarios, como se muestra en la Figura 2.2. Libros Número_Adquisición Título Autor Colocación Tema Editorial Páginas País 12765 Física General Ullman F277-739-1.1 Física Mc. Graw Hill 289 México 12766 Física General Van Der Merwe F277-739-1.1 Física Mc. Graw Hill 273 México . . . . . . . . . . . . . . . . . . . . . . . . Usuarios Matrícula Nombre Dirección Colonia Ciudad 78344 Jeanette Ríos Bernal Díaz del Castillo No. 235 Progreso Acapulco, Gro. 78345 Alberto Delgadillo Rio Balsas No. 125 Vista Alegre Acapulco, Gro. . . . . . . . . . . . . FIGURA 2.2. Ejemplo de conjuntos de entidades para el préstamo de libros en una biblioteca Asociaciones Una asociación es una relación entre varias entidades. Por ejemplo, se puede definir una asociación que relacione al usuario “Janette Ríos” con el libro que tenga número de adquisición “12765”. Un conjunto de asociaciones es un grupo de relaciones del mismo tipo. Para el ejemplo del préstamo de libros en una biblioteca se puede enunciar la asociación de la siguiente manera: Libro Prestado a Usuario Nótese que la asociación se lee en cierta dirección, pero también puede leerse en las direcciones que uno quiere que se exploren, es decir, al diseñar una asociación se hace con el fin de que por medio del modelo se puedan contestar preguntas y sobre la base de ellas deben plantearse los sentidos en que se deben leer las asociaciones. Las asociaciones en este modelo no tienen que ser binarias por fuerza y se admite también que un atributo no pertenezca a ninguna de las entidades ligadas por una asociación, sino a la asociación misma. En resumen, una asociación llega a convertirse en una especie de entidad formada con atributos de las entidades asociadas y propios.
  32. 32. BASES DE DATOS RELACIONALES Fundamentos de Bases de Datos Relacionales © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 33 Llaves Una tarea muy importante dentro del modelaje de bases de datos consiste en especificar cómo se van a distinguir las entidades y las asociaciones. Conceptualmente, las entidades individuales y las asociaciones son distintas entre sí, pero desde el punto de vista de una base de datos la diferencia entre ellas debe expresarse en términos de sus atributos. Para hacer estas distinciones, se asigna una llave a cada conjunto de entidades. La llave es un conjunto de uno o más atributos, que juntos, permiten identificar en forma única una entidad dentro de un conjunto de entidades. Por ejemplo, el atributo número_adquisición del conjunto de entidades Libros es suficiente para distinguir a una entidad de otra dentro del mismo conjunto, porque los números de adquisición de libros no se repiten, es decir, que nunca habrá números de adquisición iguales. Por tanto, número_adquisición es una llave para el conjunto de entidades Libros. De manera similar, la combinación de número_adquisición y título es una llave para el conjunto de entidades Libros; pero el atributo título no es en sí una llave ya que es posible que varios libros tengan el mismo título. El concepto de llave no es suficiente para el modelaje de la base de datos, pues una llave puede incluir atributos ajenos. Generalmente lo que se busca es la llave más pequeña posible. Estas llaves mínimas se denominan llaves candidato. Es posible que existan varios conjuntos de atributos distintos que pudieran servir como llaves candidato. Por ejemplo, una combinación de título y autor podrá ser suficiente para distinguir una entidad del conjunto de entidades Libros. De esta manera, tanto {número_adquisición} como {título, autor} son llaves candidatos. Aunque los atributos número_adquisición y título juntos pueden servir para identificar unívocamente una entidad, su combinación no es una llave candidato, puesto que número_adquisición es por sí sola una llave candidato, dado que es la más pequeña. Llave Primaria Se utiliza el término llave primaria para referirse a la llave candidato que elija el diseñador de la base de datos como la forma de identificar a las entidades dentro de un conjunto de éstas. Es posible que un conjunto de entidades no tenga suficientes atributos para formar una llave primaria. Por ejemplo, en un sistema bancario, el conjunto de entidades Transacciones, puede tener como atributos número_transacción, fecha e importe. Ninguno de estos atributos sirve para identificar en forma única una entidad, ya que dos transacciones realizadas en diferentes cuentas pueden tener el mismo número de transacción. Por lo que este conjunto de entidades no tiene llave primaria. Una entidad de un conjunto de este tipo se denomina entidad débil. Una entidad que cuenta con una llave primaria se le conoce como entidad fuerte. Aunque un conjunto de entidades débiles no cuentan con una llave primaria, es necesario tener una forma de distinguir entre todas esas entidades aquellas que
  33. 33. BASES DE DATOS RELACIONALES Fundamentos de Bases de Datos Relacionales © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 34 Llave primaria Transacciones Número_Cuenta Número_Transacción Fecha Importe 1526568 1 05/08/97 12300.00 1526569 1 17/09/97 6000.00 . . . . . . . . . a)- Entidad Débil dependen de una entidad fuerte determinada. El discriminador de un conjunto de entidades débiles es un conjunto de atributos que permite hacer esta distinción. Por ejemplo, el discriminador del conjunto de entidades débiles Transacciones es el atributo número_transacción, ya que para cada cuenta estos números de transacción identifican en forma única cada una de las transacciones. FIGURA 2.3. La entidad fuerte contra la entidad débil. La llave primaria de un conjunto de entidades débiles está formada por la llave primaria de la entidad fuerte de la que dependen y de su discriminador. En el caso del conjunto de entidades Transacción, su llave primaria es (número_cuenta, número_transacción). FIGURA 2.4. La llave primaria de una entidad débil. Los conjuntos de asociaciones también tienen llaves primarias. Sus llaves primarias se forman tomando todos los atributos que constituyen las llaves primarias de los conjuntos de asociaciones que definen al conjunto de asociaciones. Por ejemplo matrícula es la llave primaria del conjunto de entidades Usuarios y número_adquisición es la llave primaria del conjunto de entidades Libros. Por tanto, la llave primaria del conjunto de asociaciones Préstamos es (matrícula, número_adquisición). En el aspecto físico de la Base de Datos, las entidades y las asociaciones se convierten en tablas, los atributos de las entidades son las columnas de estas tablas y las llaves seleccionadas como tales dan como resultados tablas índice. Discriminador Transacciones Número_Transacción Fecha Importe 1 05/08/97 12300.00 1 17/09/97 6000.00 . . . . . . a)- Entidad Débil CuentaHabientes Número_Cuenta CuentaHabiente 1526568 Domingo Abarca Ramírez 1526569 Iraís Díaz Galeana . . . . . . a)- Entidad Fuerte CuentaHabientes Número_Cuenta CuentaHabiente 1526568 Domingo Abarca Ramírez 1526569 Iraís Díaz Galeana . . . . . . a)- Entidad Fuerte ?
  34. 34. BASES DE DATOS RELACIONALES Fundamentos de Bases de Datos Relacionales © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 35 Componentes gráficos de un Diagrama de entidad-asociación Ya que la descripción de cualquier cosa en un lenguaje natural puede acarrear confusiones, para evitarlas es necesario emplear cierta notación. Para expresar con claridad las ideas y la estructura lógica general de una base de datos en forma gráfica, se utiliza un diagrama de entidad-asociación (llamado clásico) que se integra con los siguientes componentes:  Rectángulos Representa conjuntos de entidades.  Elipses Representan atributos.  Líneas uniendo entidades Representan asociaciones entre conjuntos de entidades.  Líneas uniendo atributos y entidades o asociaciones Conectan los atributos a los conjuntos de entidades y los conjuntos de entidades a las asociaciones. Sobre esas mismas líneas se puede indicar el grado de la relación. Cada componente se etiqueta con un nombre específico. Así podemos definir nuestros conjuntos de entidades, las asociaciones existentes entre ellas y los atributos que se asignan a cada una de esas entidades. Si se retoma nuevamente al ejemplo del préstamo de libros en una biblioteca, se puede obtener del sistema tanto consultas, como reportes e información se requieran. En la Figura 2.2 pueden observarse las entidades Libros y Usuarios así como sus atributos. En la Figura 2.5 se muestra un ejemplo de un diagrama de entidad-asociación, en el cual se modela la asociación que existe entre usuarios y libros de una biblioteca, a través del préstamo del acervo. Se observa que la asociación contiene un atributo propio, que es la fecha, por medio de la cual se identifica el día del préstamo y se calcula la fecha de devolución.
  35. 35. BASES DE DATOS RELACIONALES Fundamentos de Bases de Datos Relacionales © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 36 FIGURA 2.5. Ejemplo de un DEA clásico. Funcionalidad de las asociaciones Es necesario identificar cómo se asocian las entidades; es decir, identificar el grupo de ocurrencias de una entidad que se relaciona con el grupo de ocurrencias de la entidad asociada. A continuación se muestra la simbología utilizada para representar el grado de la asociación entre dos entidades: No. Símbolo Se lee: 1 Uno y solo uno 2 Cero o uno 3 Uno o muchos 4 Cero, uno o muchos 5 Más de uno TABLA 2.1. Simbología utilizada para representar grados de asociaciones entre entidades. Se puede definir el grado de una relación como el número máximo de ocurrencias de una entidad E (de un conjunto de entidades), que puede participar en una asociación con una sola ocurrencia de otra entidad. Así, para un conjunto binario de asociaciones entre los conjuntos de entidades A y B, la funcionalidad consiste en las ocurrencias de asociación entre A y B, el cual debe estar entre alguna de las siguientes.
  36. 36. BASES DE DATOS RELACIONALES Fundamentos de Bases de Datos Relacionales © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 37  Una a una (1:1) Una entidad en A está asociada sólo con una entidad en B, y una entidad en B está asociada sólo con una entidad en A. Se pueden utilizar los símbolos 1 ó 2 en el extremo izquierdo y también los símbolos 1 ó 2 en el extremo derecho.  Una a muchas (1:n) Una entidad en A está asociada con cualquier número de entidades de B, pero una entidad de B puede relacionarse sólo con una entidad en A. Se pueden utilizar los símbolos 1 ó 2 en el extremo izquierdo y los símbolos 3, 4 ó 5 en el extremo derecho.  Muchas a una (n:1) Una entidad de A está asociada con una entidad en B, pero una entidad de B está vinculada con cualquier número de entidades de A. Se pueden utilizar los símbolos 3, 4, ó 5 en el extremo izquierdo y los símbolos 1 ó 2 en el extremo derecho.  Muchas a muchas (n:n) Una entidad de A está relacionada con cualquier número de entidades en B y una entidad de B está asociada con cualquier número de entidades de A. Se pueden utilizar los símbolos 3, 4, ó 5 en el extremo izquierdo e igualmente los símbolos 3, 4, ó 5 en el extremo derecho. Por ejemplo si se piensa en forma restringida, una cuenta sólo puede pertenecer a un cuentahabiente y un cuentahabiente puede tener más de una cuenta. Se identifican las entidades Cuenta y CuentaHabiente, en el que las relaciones de sus ocurrencias son:  Una cuenta a un cuentahabiente.  Un cuentahabiente a una o más cuentas. Esto significa que tiene relación de una a muchas. Piénsese también, en el ejemplo del sistema bibliotecario que se mostró en la Figura 2.5. Se observa que la asociación entre usuarios y libros es de uno a muchos, ya que un usuario puede tener cero o varios, libros, pero un ejemplar de un libro sólo lo puede tener un usuario como máximo y cero como mínimo. En la figura se denota la asociación de grado n por medio de una pata de gallo. El diagrama que se utilizará aquí (y el cual es el más práctico) difiere del diagrama clásico de la Figura 2.5. En este diagrama la entidad tiene una representación diferente a la “caja” simple, dado que aquí es representada en algo conocido como Diagrama de Estructura de Datos. La siguiente figura identifica plenamente a este diagrama de estructura:
  37. 37. BASES DE DATOS RELACIONALES Fundamentos de Bases de Datos Relacionales © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 38 Nombre_Entidad Key Data atributo1 [PK1] atributo2 [PK2] Non-Key Data atributo3 o o o atributoN Volume min. ##### max. ##### Tabla Ingres Nombre_Tabla_Físico FIGURA 2.6. Cuerpo de una Entidad como diagrama de estructura de datos. Los elementos que componen a esta entidad son los siguientes: Nombre_Entidad: Se refiere al nombre lógico que tendrá la entidad, está deberá coincidir con el nombre del Almacén del DFD. atributo1 atributo2 atributo3 . . . atributoN Se refiere al nombre de cada uno de los atributos (campos de la tabla ya en la Base de Datos) que componen la entidad, donde los que se encuentran en la zona “Key Data” son atributos llave. min. #### max. #### Se refiere al mínimo y máximo de registros que guardará la entidad ya como tabla física. Nombre_Tabla_Físico Es el nombre físico de la tabla en la Base de Datos TABLA 2.2. Elementos que componen una Entidad como diagrama de estructura de datos. Además, estos DEA que se utilizarán son DEA en donde sólo se tienen asociaciones binarias y son descritas a través de una línea que une a dos conjuntos de entidades indicando la cardinalidad de la asociación igual que el diagrama clásico, con una notación de pata de gallo. Los DEA sólo contendrán asociaciones de 1:N o bien de 1:1, pero nunca de N:N. Los conjuntos de entidades tendrán un nombre, una descripción un conjunto de atributos que la compone, indicaciones sobre estos atributos en cuanto a cuales son atributos llave y cual no lo son, número mínimo promedio y máximo de entidades esperadas, nombre de la tabla del DBSM a la que corresponderá en la implantación (etapa de diseño y programación). Además las asociaciones son sustituidas por diagramas de estructuras de datos, es decir, por entidades nuevas cuyo nombre es el de la propia asociación.
  38. 38. BASES DE DATOS RELACIONALES Fundamentos de Bases de Datos Relacionales © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 39 DEA del Sistema Bibliotecario Préstamos Key Data Matrícula [PK1] Número_Adquisición [PK2] Non-Key Data Fecha Volume Min. 1 Max. 1000000 Tabla Ingres TaPrestamo Libros Key Data Numero_Adquisición [PK1] Non-Key Data Título Autor Colocación Tema Editorial Páginas País Volume Min. 1 Max. 10000 Tabla Ingres TaLibro Usuarios Key Data Matrícula [PK1] Non-Key Data Nombre Dirección Colonia Ciudad Volume Min. 1 Max. 10000 Tabla Ingres TaUsuario Debe existir en Puede tener Para ejemplificar, se diseña en la figura de abajo el mismo DEA de la Figura 2.5 pero ahora utilizando el estilo de la Figura 1.3.6, sustituyendo las cajas y óvalos por los diagramas de estructura de datos: FIGURA 2.7. DEA del Sistema bibliotecario. Como se observa en la Figura 2.7, la asociación Préstamos de la figura 2.5 es sustituida por una entidad del mismo nombre cuyos atributos son los atributos llave de las entidades relacionadas (Matrícula y Número_Adquisición) y el atributo fecha que es propio de la asociación. Las asociaciones sólo tendrán un nombre y reglas de integridad. Los atributos se documentarán con un identificador, el cual está compuesto por un prefijo que indicará la naturaleza del atributo y un sufijo que indicará la entidad con la cual se le relaciona. A continuación se dan algunos ejemplos en las dos tablas siguientes: TABLAS 2.3. Ejemplos de prefijos y sufijos para nombrar atributos. Prefijo Significado Id Identificador numérico que no lleva una secuencia Num Identificador numérico que lleva una secuencia Ce Clave identificador alfanumérico Do Saldo SdoIni Saldo inicial Nom Nombre Desc Descripción Stat Estado lógico Sufijo Significado Pol Póliza Emp Empleado Oper Operación Fact Factura
  39. 39. BASES DE DATOS RELACIONALES Fundamentos de Bases de Datos Relacionales © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 40 Se hace notar que de aquí en adelante todos los DEA creados usarán esta nueva forma de nombrar a sus atributos, así como sus respectivas tablas físicas. Ahora bien, para comprender mejor al DEA anterior, habría que entender primero a las propias entidades, por lo que analizaremos a la entidad Usuarios: Está compuesta por cinco atributos de los cuales Matrícula (número de control del usuario o alumno)es atributo llave, es decir, habrá exactamente un usuario por tupla o registro, y por su parte Nombre, Dirección, Colonia y Ciudad solamente son atributos descriptivos del usuario. Nos habla de que tendrá un mínimo de 1 usuario y un máximo de 10000 y que el nombre físico de la tabla en la Base de Datos será TaUsuario. Dada la explicación anterior, entonces la interpretación o lectura del DEA da la figura 2.7 es de la siguiente manera: 1. Los usuarios de la biblioteca, identificados por su número de control (Matrícula), se verifican en la entidad Préstamos para saber si tiene o no libros en calidad de préstamo, es decir, uno y solo un usuario de la biblioteca puede tener uno o más libros prestados. 2. Estos préstamos registran el número del libro (Número_Adquisición) prestado el cual debe existir en la entidad Libros por una sola vez, es decir, el libro prestado está registrado una y solo una vez en el catálogo de libros. 3. En caso de que existan préstamos estos están registrados en determinada Fecha. 2.2. Resistencia al Modelo Relacional El modelo relacional encontró mucha resistencia. Los sistemas de bases de datos relacionales requieren más recursos computacionales y, por lo tanto, al principio eran mucho más lentos que los sistemas basados en modelos anteriores de bases de datos. Aunque eran fáciles de usar, la respuesta era lenta y con frecuencia inaceptable. A tal grado que los productos DBMS relacionales resultaron imprácticos hasta los 80, cuando se desarrolló un hardware más rápido para computadoras y la relación precio-desempeño cayó de un modo dramático. El modelo relacional también le parecía extraño a varios programadores. Estaban acostumbrados a escribir programas en los cuales procesaban los datos de un registro a la vez. Pero los productos DBMS relacionales procesan datos con mayor naturalidad; una tabla a la vez. De acuerdo con ello, los programadores debían aprender un nuevo modo de pensar acerca del procesamiento de datos.
  40. 40. 3-Reglas de integridad Las bases de datos relacionales son como la sociedad: mientras se mantengan sanas las relaciones todo marchará bien, en el momento en que estas se contaminen, todo fallará. Boyce, R. F., consultor de BD, Agosto de 1994.
  41. 41. BASES DE DATOS RELACIONALES Reglas de Integridad. © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 42 3.1. Reglas de Integridad de la Base de Datos Las tablas se encuentran asociadas a otras tablas por medio de sus llaves primarias. Dichas asociaciones normalmente son de 1 a N, es decir a un elemento de una tabla padre le corresponden varios elementos de la tabla hijo. Aunque puede darse el caso de que a un elemento de una tabla se le asocie tan solo un elemento de otra, y aun más, puede darse el caso de que al elemento de una tabla padre no le corresponda ningún hijo. El caso que jamás debe darse es que un hijo no tenga padre. Y el evitar este último ejemplo es precisamente parte de lo que se le conoce como Integridad de la base de datos. Es por esto, que cuando se efectúa una transacción que involucra operaciones de actualización y eliminación sobre una tabla, es necesario reflejar esos cambios en todas las tablas asociadas. Por ejemplo, si se elimina un registro de la tabla Clientes (Entiéndase un base d datos de CXC), es necesario eliminar todos los registros de las tablas Facturas, Notas de Crédito, Pedidos, Saldos, etc., en los que aparezca el cliente eliminado. De no hacerlo, la base de datos presentará datos incongruentes y quedará en un estado que se le llama Inconsistencia. Cualquiera que sean los casos de asociaciones que se presenten en la base de datos, estos deben preverse durante la etapa de diseño de la misma. Para vigilar que las relaciones establecidas entre las tablas se conserven, existe lo que se conoce con el nombre de Reglas de Integridad. Las reglas de integridad verifican que las operaciones realizadas sobre las base de datos (Agregar, Eliminar, Modificar) sean consistentes, y en caso de no ser así, entonces una regla de integridad se “disparará” para evitar que la base de datos se degrade. Las reglas de integridad pueden ser de tablas o bien entre tablas. Las de tabla verifican las operaciones que se realizan sobre la tabla, y las otras la repercusión que tienen las operaciones realizadas en una tabla sobre otras que son normalmente las asociadas a esta. Para los dos casos se han diseñado estándares con respecto a la forma en que las reglas de integridad deben ser adecuadamente documentadas. Reglas de Integridad de Tablas Las reglas de integridad en tablas sirven para estipular el cómo deben hacerse las diferentes operaciones de SQL en los registros y en las columnas de la tabla, delimitando claramente el alcance de la operación con respecto a los propios registros y columnas de la tabla e inclusive a otras tablas asociadas. Así por ejemplo, en una operación de inserción de registros debe dejarse bien claro que reglas debe de cumplir esta operación para poder efectuarse correctamente, reglas que bien pueden ser simples incrementos de algún atributo llave, verificación de no-existencia , o algunas operaciones extras como el provocar otras inserciones hacia otras tablas
  42. 42. BASES DE DATOS RELACIONALES Reglas de Integridad. © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 43 asociadas. Es decir, que estas operaciones o limitantes pueden darse tanto antes de la propia operación de inserción o posterior a ella. Las únicas operaciones que deben cumplir con reglas de integridad son aquellas que provocan el cambio directo de la información en la base de datos, como son Inserción, Modificación y Eliminación. Para dejar más claro esto veamos como ejemplo las reglas de integridad que se estipularían para la tabla TaLibro (entidad Libros) del DEA del Sistema Bibliotecario de la Figura 2.7: Operación Regla de Integridad Inserción El número de adquisición deberá ser dado por el usuario, y se verificará de forma automática que este no exista ya en la tabla. Todos los demás campos son de edición directa. Explicación: Se está estipulando para esta operación que el sistema deberá permitir la libre edición al usuario para capturar el campo Número_Adquisición, pero que al mismo tiempo el propio sistema deberá validar este valor capturado contra la misma tabla verificando que no exista, ya que de lo contrario se repetirían, y dado que es un campo llave el permitirlo acarrearía un serio problema de inconsistencia de información en la propia tabla al existir llaves duplicadas. Por otro lado, también se está marcando que los demás campos restantes (Título, Autor, Colocación, etc.) se pueden editar de forma libre ya que estos no provocan propagación de operaciones como el anterior, Número_Adquisición. Operación Regla de Integridad Modificación La modificación puede hacerse sobre todos los campos a excepción de Número de Adquisición. Explicación: Es permitida la modificación en todos los campos a excepción del campo Número_Adquisición que es un campo llave, y este impedimento se debe a que si se permitiera modificarlo entonces se correría el mismo riesgo de duplicidad de llaves por un lado, y por otro al modificar un campo llave entonces esta operación de modificación tendría que propagarse hacia otras tablas asociadas por medio de este atributo a la tabla TaLibro (como es la tabla TaPrestamo), lo cual acarrearía un alto costo de programación extra.
  43. 43. BASES DE DATOS RELACIONALES Reglas de Integridad. © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 44 Operación Regla de Integridad Eliminación No deben existir préstamos asociados al libro. Explicación: Para poder eliminar un “libro” de la tabla TaLibro deberá comprobarse primero que este no existe como “préstamo” en la tabla TaPrestamo, y esto se logra por medio del atributo común entre los dos que es Número_Adquisición. Si el libro con Número_Adquisición no existe en la tabla TaPrestamo entonces esto indica que el libro no ha sido prestado y por lo tanto puede ser eliminado, de lo contrario la eliminación será negada. Ahora bien, para registrar fácilmente reglas de integridad en tablas, se propone que estas deberán hacerse en el siguiente formato práctico: Tabla: <Nombre_Tabla> Operación Regla de Integridad Inserción <Texto de regla de Inserción> Modificación <Texto de regla de Modificación> Eliminación <Texto de regla de Eliminación> Tabla 3.1. Formato para registrar las reglas de integridad en tablas. Donde Nombre_Tabla es el nombre de la tabla para la cual se están estipulando las reglas de integridad. En la columna Operación se registrarán las tres operaciones permitidas, y en la columna Regla de Integridad se pondrá el texto de la regla que corresponde a la operación en turno. Reglas de Integridad entre Tablas Las reglas de integridad entre tablas indican las restricciones que deben seguirse en cualquier operación que se realice en alguna tabla de la base de datos. La idea es que dicho evento no rompa la integridad de las tablas asociadas a la tabla en la que se aplicó tal operación. Estas reglas de integridad sólo deben aplicarse cuando las reglas de integridad de la propia tabla permitan que se efectúe la operación, en caso contrario no aplica la integridad entre tablas.
  44. 44. BASES DE DATOS RELACIONALES Reglas de Integridad. © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 45 En otras palabras, las reglas de integridad entre tablas sólo serán activadas cuando la regla de integridad de la tabla lo decida. Nuevamente, para aclarar mejor esto, recurrimos al DEA del Sistema Bibliotecario de la Figura 2.7 y ponemos como ejemplo las reglas de integridad entre tablas que se estipularían para las tablas TaLibro (entidad Libros), TaPrestamo (entidad Préstamos) y TaUsuario (entidad Usuarios): Tabla: TaLibro Operación Otras tablas relacionadas Restricciones - Inserción Ninguna Ninguna - Modificación No aplica No Mod. De Llaves - Eliminación TaPrestamo No Existencia Explicación: En la operación de Inserción se está estipulando que al realizarse esta, puede hacerse libremente sin realizar verificación alguna en otra tabla, pues el insertar un registro en esta tabla no implica un detalle que deba agregarse en alguna otra tabla hijo. Si se observa el DEA nos daremos cuenta que esta tabla no tiene ninguna asociación de uno a muchos con alguna otra tabla, lo cual nos indica que no tiene descendientes. En la operación de Modificación el establecer “No aplica" está informando que es irrelevante la relación que guarde con otras tablas, porque la operación misma limita esto al establecer como restricción la “No modificación de llaves”, y hay que recordar que las asociaciones entre tablas se dan precisamente a través de las llaves. Con lo que respecta a la operación de Eliminación, se está informando que existe una tabla asociada, la cual es TaPrestamo, y al observar esto en el DEA nos damos cuenta que efectivamente existe la relación y que además es de cero o muchos a uno, lo cual implica que es forzoso que se verifique la “No Existencia” del registro a eliminar en la tabla relacionada, pues el eliminar este registro de la tabla actual teniendo otros registros asociados en la tabla TaPrestamo (que tengan el mismo identificador Número_Adquisición) implicaría el dejar libros prestados sin que estos existan en la biblioteca.
  45. 45. BASES DE DATOS RELACIONALES Reglas de Integridad. © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 46 Tabla: TaPrestamo Operación Otras tablas relacionadas Restricciones - Inserción TaLibro TaUsuario Existencia. Existencia. - Modificación No aplica No Mod. De Llaves - Eliminación TaLibro TaUsuario No Existencia. No Existencia. Explicación: En la operación de Inserción se está informando que para poder realizarse esta, debe verificarse en las tablas asociadas TaLibro y TaUsuario la “Existencia” de registros que contengan los campos que forman la asociación con esta tabla (Matrícula y Número_Adquisición) pues ambos forman la llave del registro a insertar, con lo cual en caso de no existir en las tablas antes dichas y permitir la inserción, entonces se incurriría en una incongruencia o también llamada inconsistencia de la tabla. Con lo que respecta a la operación de Modificación cabe la misma explicación que se dio para esta misma operación en la tabla TaLibro. En la operación de Eliminación, se procede igual que para la eliminación en la tabla TaLibro solo que aquí la verificación de “No existencia” se hace en dos tablas que son TaLibro y TaUsuario, ambas asociadas a la tabla en cuestión.
  46. 46. BASES DE DATOS RELACIONALES Reglas de Integridad. © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 47 Tabla: TaUsuario Operación Otras tablas relacionadas Restricciones - Inserción Ninguna Ninguna - Modificación No aplica No Mod. De Llaves - Eliminación TaPrestamo No Existencia. Explicación: En las dos primera operaciones cabe la misma explicación que para la tabla TaLibro. Con lo que respecta a la operación de Eliminación, se está informando que existe una asociación con la tabla TaPrestamo, y al observar esto en el DEA nos damos cuenta que la relación es de cero o muchos a uno o cero, lo cual implica que es forzoso que se verifique la “No Existencia” del registro a eliminar en la tabla relacionada, pues el eliminar este registro de la tabla actual teniendo otros registros asociados en la tabla TaPrestamo (que tengan el mismo identificador Matrícula) implicaría el dejar usuarios con préstamos sin que estos existan ya, o dicho en palabras coloquiales “es tanto como el que se fue sin pagar”. De la misma manera que existe un formato para el registro de reglas de integridad en tablas, también se sugiere como un estándar que para registrar reglas de integridad entre tablas estas pueden hacerse en el siguiente formato: Tabla Operación Tablas Relacionadas Tipo de Restricción <Nombre_Tabla> Inserción <Nombre_Tabla_Rel.> <Restricción para op.> Modificación <Restricción para op.> Eliminación <Restricción para op.> Tabla 3.2. Formato para registrar las reglas de integridad entre tablas. donde Nombre_Tabla es el nombre de la tabla para la cual se están estipulando las reglas de integridad. En la columna Operación se registrarán las tres operaciones permitidas, en la columna Tablas Relacionadas se escriben los nombres de aquellas tabla que tengan una relación con la tabla en cuestión y que se vena afectadas en la operación en turno y por
  47. 47. BASES DE DATOS RELACIONALES Reglas de Integridad. © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 48 último la columna Tipo de Restricción estipula las condiciones que deben cumplirse en la tabla relacionada para poder efectuar la operación. Los tipos de restricción tienen los siguientes valores: Ninguna No hay restricción entre tablas para efectuar la operación. Existencia Es necesario que exista el registro relacionado en la tabla relacionada correspondiente. No Existencia Es necesario que no existan registros relacionados en la tabla relacionada correspondiente. No Mod. De Llaves La tabla no permite modificación en sus valores llave, por lo que no aplica ninguna restricción entre tablas. No Permite Baja La tabla no permite bajas, por lo que no aplica ninguna restricción entre tablas.
  48. 48. BASES DE DATOS RELACIONALES Reglas de Integridad. © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 49 3.2. Propagación de Operaciones Una vez que se permite realizar una operación dadas las reglas de integridad de y entre tablas, es necesario revisar si la operación se propaga más allá de la tabla. Es decir, que es probable que la operación aplicada a la tabla provoque una o más operaciones extras en tablas relacionadas con esta. Cuando se efectúa una operación de Inserción, Eliminación o Modificación, el efecto de la misma se puede propagar a los registros asociados a tablas relacionadas a la que se le aplica la operación. Si esta operación no se lleva a cabo, es posible que la base de datos pierda integridad. Esto se debe fundamentalmente a que todas las relaciones entre tablas manejan una cardinalidad 1:N, donde la tabla ubicada en el extremo del 1 es la tabla padre y la tabla ubicada en el extremo del N es la tabla hijo y generalmente una opcionalidad de mínimo uno (mínimo están relacionados con al menos un registro de la tabla relacionada). Si existiese un registro en cualquiera de los dos lados sin que esté relacionado con su contraparte, entonces esto indica un posible problema de integridad, sin embargo, aquí manejaremos la posibilidad de que existan padres sin hijo, pero no hijos sin padre. Lo que haremos en esta situación es cambiar el status del padre a Inactivo, lo que da origen a una nueva operación llamada Cancelación. En otras palabras el padre será eliminado solo lógicamente pero nunca físicamente. En la Inserción, al agregar un registro en la tabla padre no será necesario agregar registros vacíos en algunas de sus tablas hijo. En la Eliminación, al eliminar un registro de una tabla hijo, no es necesario propagar la operación a la tabla padre. Por su parte, en la Modificación, si se modifican los datos que no pertenecen a llave, normalmente no hay propagación en la operación, sin embargo, cuando se modifican valores en los campos llave, será necesario propagar la operación de modificación a todos los registros hijos. Esta situación es rara, y son pocas las ocasiones que se realiza.
  49. 49. BASES DE DATOS RELACIONALES Reglas de Integridad. © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 50 A continuación se describe la forma en que se propagan las operaciones entre las distintas tablas relacionadas para una pequeña porción de un DEA de un Sistema de Cuentas Por Pagar. Figura 3.1. Porción de un DEA de un sistema de Cuentas Por Pagar. El formato a utilizar, es semejante al presentado en la sección anterior, excepto que en la última columna tiene ahora una descripción. Este se muestra en la siguiente página:
  50. 50. BASES DE DATOS RELACIONALES Reglas de Integridad. © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 51 Tabla Operación Tablas Padre o Hijo Descripción de Propagación TaCxP Inserción TaPoliza Al insertar una cuenta por pagar se inserta la póliza correspondiente. Modificación TaPoliza Las modificaciones realizadas sobre la Cuenta Por Pagar afectan la póliza. Cancelación TaPóliza La cancelación de una Cuenta Por Pagar origina la cancelación de la Póliza también. TaMovPol La cancelación de la Póliza provoca también la eliminación de los movimientos de la misma. TaPoliza Inserción TaMovPol No existe Modificación TaMovPol No existe Eliminación TaMovPol Al eliminar una póliza también deben ser eliminados sus movimientos. Tabla 3.3. Formato para registrar la propagación de operaciones.
  51. 51. 4-Introducción al SQL básico Una transacción SQL mal construida es siempre motivo de enojo, tanto en los usuarios como en el propio programador, por los resultados que esta trae y el tiempo que hay que invertir en corregirla. Pero realmente no hay nada mas grave que además de esto, el error solo se produzca en determinados eventos, lo cual lo hace difícil de detectar. ¡Eso si pone en jaque a cualquier sistema de información!. El autor. Trabajando para Grupo Yoli. Octubre de 1992.
  52. 52. BASES DE DATOS RELACIONALES Intoducción al SQL básico © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 53 4.1. ¿Que es SQL? El lenguaje de consulta estructurada: SQL (Structured Query Languaje), es el lenguaje de manejo de bases de datos relacionales de mayor importancia en uso hoy en día. Ha recibido la aceptación de ANSI como lenguaje de elección para el manejo de bases de datos, y es el lenguaje de acceso a los datos que se aplica en muchos productos DBMS comerciales. Es tal su popularidad, que el SQL se ha convertido en el lenguaje estándar para el intercambio de información entre computadoras. Ya que existe una versión de SQL que puede ejecutarse en casi cualquier computadora y sistema operativo, los sistemas de computación pueden intercambiar datos pasando consultas y respuestas SQL entre sí, lo cual es una capacidad que cada día aumenta más. Las construcciones y las expresiones permitidas de una puesta en práctica particular de SQL (por ejemplo, en INGRES o en ORACLE) pudieran diferir de alguna forma del estándar ANSI, en parte debido a que múltiples productos DBMS fueron desarrollados antes de llegar al acuerdo sobre el estándar y también debido a que los fabricantes han añadido capacidades a sus productos para adquirir ventajas competitivas. Desde una perspectiva de comercialización, el hecho de cumplir con el estándar ANSI pudiera ser juzgado como no suficientemente interesante. Los comandos SQL pueden ser utilizados en forma interactiva, como lenguaje de consulta, o pueden insertarse en programas de aplicación. En este último caso, son procesados por un precompilador. Por lo tanto SQL no es un lenguaje de programación; más bien se trata de un sublenguaje de datos, o de un lenguaje de acceso a datos, insertado algunas veces en otros lenguajes (conocido como Embeded SQL). 4.2. Las funciones de SQL SQL es mucho más que una herramienta de consulta, aunque ese fue su propósito original y recuperar datos sigue siendo una de sus principales funciones. SQL se utiliza para controlar todas las funciones que un DBMS proporciona a sus usuarios, las cuales son:  Definición de datos. SQL permite a un usuario definir la estructura y organización de los datos almacenados y las relaciones entre ellos.  Recuperación de datos. SQL permite a un usuario o a un programa de aplicación recuperar los datos almacenados de la base de datos y utilizarlos.  Manipulación de datos. SQL permite a un usuario o a un programa de aplicación actualizar la base de datos añadiendo nuevos datos, suprimiendo datos antiguos y modificando datos previamente almacenados.
  53. 53. BASES DE DATOS RELACIONALES Intoducción al SQL básico © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 54  Control de acceso. SQL permite ser utilizado para restringir la capacidad de un usuario para recuperar, añadir y modificar datos, protegiendo así los datos almacenados frente a accesos no autorizados.  Compartición de datos. SQL se utiliza para coordinar la compartición de datos por parte de usuarios concurrentes, asegurando que no interfieran unos con otros.  Integridad de datos. SQL define restricciones de integridad en la base de datos, protegiéndola contra corrupciones debidas a actualizaciones inconsistentes o a fallas del sistema. Por lo tanto SQL es un lenguaje completo de control e interactuación con un sistema de gestión de base de datos. Finalmente SQL no es un lenguaje particularmente estructurado, especialmente cuando se compara con lenguajes altamente estructurados como C o Pascal. En vez de ello, las sentencias SQL se asemejan a frases en inglés, completadas con “palabras de relleno” que no añaden nada al significado de la frase pero que hace que se lea más naturalmente. Hay unas cuantas inconsistencias en el lenguaje SQL, y también existen algunas reglas especiales para impedir la construcción de sentencias SQL que parecen perfectamente legales, pero que no tienen sentido.
  54. 54. BASES DE DATOS RELACIONALES Intoducción al SQL básico © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 55 4.3. Trabajando con SQL Ahora nos introduciremos al mundo del SQL utilizando sus sentencias básicas como son SELECT, DELETE, UPDATE, INSERT y algunas otras más. En realidad SQL contiene muy pocas sentencias nativas (30 más o menos), es decir, con estándar ANSI, pero pueden encontrarse algunas más dependiendo del DBMS que se esté utilizando. De cualquier forma usted se dará cuenta de la potencia con la que este lenguaje de consulta cuenta para hurgar las bases de datos relacionales. Para realizar los ejercicios utilizaremos una pequeña base de datos llamada NOMINA previamente creada en su computadora, y cuyo diagrama de entidades y asociaciones es el siguiente: La estructura y contenido (datos) de cada una de estas tablas podrá encontrarlas en los Apéndices A y B que se encuentran al final de estas notas. Empleado @IdEmp IdPlaza NomEmp RFCEmp DirEmp NumIMSSEmp SdoBaseEmp StatEmp FechStatEmp FechIngEmp TaEmpleado Historia Sueldo @IdEmp @FechIniSdo @FechFinSdo SdoBaseEmp TaHistSueldo Plaza @IdPlaza DescPlaza IdPuesto TaPlaza Puesto @IdPuesto DescPuesto TaPuesto Pago @IdEjer @IdPer @IdEmp @IdConcPag ImpPag TaPago Periodo @IdEjer @IdPer FechIniPer FechPagoPer TaPeriodo Concepto de Pago @IdConcPag DescConcPag OperConcPag TaConcepto Realizado en Compuesto de Reciben un Que cubre Que tiene Ligada a
  55. 55. BASES DE DATOS RELACIONALES Intoducción al SQL básico © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 56 Recuperación de datos (Select) La sentencia SELECT es la sentencia básica del SQL, a partir de ella pueden construirse múltiples transacciones para consultar o incluso, modificar la base de datos. Ya sea sola o en combinación con otras sentencias. El objetivo de SELECT (usada sin sentencias adicionales) es la lectura o recuperación rápida de datos de una o más tablas. Esto puede lograrse con sentencias de consulta sencillas o bien, tan complejas como se requiera. La sintaxis de la sentencia SELECT es la siguiente: SELECT <Atributos> FROM <Tablas> WHERE <Condición>; Donde Atributos son uno o más atributos de una o más tablas de la base de datos en cuestión. Tablas son el o los nombres de las tablas que se desean consultar. Y finalmente Condición es una serie de condiciones que nos sirven para acotar el grupo de registros que serán leídos, los cuales muchas veces es en cantidad innecesaria. Para comenzar veamos la siguiente consulta: SELECT IdEmp, IdPlaza, NomEmp, RFCEmp, DirEmp, NumIMSSEmp, SdoBaseEmp, StatEmp, FechStatEmp, FechIngEmp FROM TaEmpleado; Como se puede observar, en esta consulta nos estamos refiriendo a todos los atributos de la tabla TaEmpleado. Note también, que no estamos usando la cláusula WHERE, pues en este caso no es necesario. El resultado de esta consulta debe ser el total de registros de esta tabla. Ahora observe la siguiente sentencia SELECT: SELECT IdEmp, NomEmp, SdoBaseEmp FROM TaEmpleado; Para este caso, le estamos indicando al DBMS que solo queremos leer tres atributos de la tabla TaEmpleado. Esto no implica que la cantidad de registros leídos deba cambiar, pues de la cláusula FROM hacia abajo es todo igual a la consulta anterior.
  56. 56. BASES DE DATOS RELACIONALES Intoducción al SQL básico © Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 57 La Cláusula WHERE Como se dijo anteriormente, la cláusula WHERE es usada cuando se necesita acotar el grupo de registros leídos en una consulta. Si recordamos, en las dos consultas anteriores el grupo de registros leídos es el total que existen en la tabla TaEmpleado, pero no siempre será así. Veamos ahora como podemos acotar este grupo especificándole a SELECT cual o cuales son los registros que deseamos. Así por ejemplo, si solo queremos visualizar los datos del empleado 1590, esto lo podemos lograr usando la cláusula WHERE de la siguiente forma: SELECT IdEmp, NomEmp, SdoBaseEmp FROM TaEmpleado WHERE IdEmp = 1590; Ahora bien, las condiciones de WHERE no están sujetas solo a igualdades y a atributos de tipo numérico, por el contrario, es permitido utilizar todos los operadores relacionales existentes (>, <, =, >=, <=, <>) y cualquier clase de atributo sin importar su tipo, aunque se recomienda siempre usar lo más posible atributos de tipo numérico, pues los de otro tipo hacen “lenta” la consulta. Desdichadamente no siempre podrá evitarse, como en el siguiente caso, donde se desea presentar los registros de aquellos empleados que ingresaron en la segunda quincena de junio de 1998 SELECT IdEmp, NomEmp, SdoBaseEmp FROM TaEmpleado WHERE FechIngEmp = Date('98/06/16'); El uso de funciones de conversión de datos de atributos siempre será bastante variado de un DBMS a otro, pues ya sea la conversión o extracción de datos no están definidas en el estándar ANSI del SQL. En las siguientes dos consultas se desea extraer la información de todos aquellos empleados que hayan ingresado en el año de 1990 (primera consulta) y de todos los que hayan ingresado en la segunda quincena de cualquier mes y de cualquier año (segunda consulta).

×