You are on page 1of 82

INTRODUCCION A LAS BASES DE DATOS RELACIONALES

Domingo Abarca Ramírez. Diciembre de 1999, México.

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 ______________________________________________ Base de datos tipo relacional ____________________________________________ Base de datos tipo red _________________________________________________ Base de datos tipo jerárquico ____________________________________________ 26 26 26 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 __________________________________ 2.1.1. Diagrama de Entidades y Asociaciones (DEA) _________________________ Enfoque de Entidad-Asociación ________________________________________ Componentes de un DEA _____________________________________________ Componentes gráficos de un Diagrama de entidad-asociación ________________ 30 31 31 31 35

2.2. Resistencia al Modelo Relacional _____________________________________ 40

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 _______________________________________________ Recuperación de datos (Select) __________________________________________ La Cláusula WHERE ________________________________________________ El uso de asterisco (*) ________________________________________________ Los operadores lógicos y el Test de rango (BetWeen) _______________________ El Test de pertenencia (IN) ____________________________________________ Test de correspondencia con patrón (LIKE) _______________________________ Filas duplicadas (DISTINCT) __________________________________________ Consultas multitablas (Join) ___________________________________________ Funciones de Agrupación (Sum, Avg, Count, Max, Min) ______________________ La función Suma (Sum) ______________________________________________ La función Promedio (Avg) ___________________________________________ La función Cuenta (Count) ____________________________________________ La función Máximo (Max) ____________________________________________ La función Mínimo (Min)_____________________________________________ Adición de datos (Insert) _______________________________________________ Eliminación de datos (Delete) ___________________________________________ Actualización de datos (Update) _________________________________________ Creación de tablas (Create)____________________________________________ 55 56 57 58 59 59 60 61 61 63 63 65 66 67 69 70 71 72 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

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.

BASES DE DATOS RELACIONALES

Introducción a las bases de datos

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 6

BASES DE DATOS RELACIONALES

Introducción a las bases de datos

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.

No. de Registro

Campos alfanuméricos DirEmp Av. Michoacán 1340, Col. Progreso. Cuauhtémoc 70-B, Col. Centro Gaviotas 45,Fracc. Las Playas, Caleta.

Campos numéricos FechNac 750612 680514 740422 IngAnual 50000.00 60000.00 Registros

1 2 3 . . . 99 100

NomEmp Rosalba Arciniega López Domingo Abarca Ramírez Eva Samayoa Dorantes

Alejandro Apac Sandoval Luis Orozco Bedolla

Baja California 99, Col. Progreso. Mina 64, Col. Centro.

690223 660825

200000.00 100000.00

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 7

BASES DE DATOS RELACIONALES

Introducción a las bases de datos

Así, tal como lo muestra la Figura 1.2. los primeros sistemas de información comerciales almacenaban grupos de registros en archivos separados.

Programa de actualización de empleados. DA Archivo maestro de empleados

Programa de informe de empleados. Usuario del sistema de nómina. DA

Programa de impresión de cheques. DA DA Archivo de historia de sueldos

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 empleadotodos 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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 8

BASES DE DATOS RELACIONALES

Introducción a las bases de datos

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.

Sí señor. Pondré todo mi esfuerzo. Necesito esos reportes para hoy a las 4:00 p.m. Gómez.

Como si fuera tan sencillo, con este “desm...” de datos que tiene aquí...

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 9

BASES DE DATOS RELACIONALES

Introducción a las bases de datos

 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:

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 10

BASES DE DATOS RELACIONALES

Introducción a las bases de datos

Empresa X Nómina

S.I.I.G.Y. Consultor de Empleados

DD/MM/AA consnom.exe

Sucursal: 12 Renacimiento Tipo de Empleado: 01 Confianza

Id. Emp. 600234 609314 601256 602567 605621 609152 601045

Nombre: Samayoa Dorantes Eva García Hernández Fidel Ramos Baños Luis Viilegas Reyes Josefina Hernández Bravo Juan Miguel Olivar Campos Víctor Cortez Dillanes Marco Antonio

Dirección: xxxx xxxx xxxx xxxx xxxx xxxx xxxx

Sueldo: 5000.00 6000.00 7000.00 5000.00 8000.00 8500.00 9000.00

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 11

BASES DE DATOS RELACIONALES

Introducción a las bases de datos

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:

Aplicación(es) de base de datos

DBMS

Base de datos

Usuario del sistema de nómina.

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 12

BASES DE DATOS RELACIONALES

Introducción a las bases de datos

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.

Base de Datos

DBMS

FIGURA 1.6. Esquematización de la labor de un DBMS.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 13

BASES DE DATOS RELACIONALES

Introducción a las bases de datos

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 14

BASES DE DATOS RELACIONALES

Introducción a las bases de datos

Num_Pedido 23455 24879 34488 23455 34488 23455

Fecha 13/01/92 17/01/92 20/01/92 13/01/92 20/01/92 13/01/92

DescConcepto Computadoras ATT Drives de 5 ¼ “ Monitores de color Computadoras ATT Monitores de color Computadoras ATT

a) Archivo de pedidos
Clave_Concepto 23455 24879 34488 DescConcepto Computadoras ATT Drives de 5 ¼ “ 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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 15

BASES DE DATOS RELACIONALES

Introducción a las bases de datos

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 16

BASES DE DATOS RELACIONALES

Introducción a las bases de datos

Bits

Bytes o Caracteres

Campos

Registros

Archivos

a)

Bits

Bytes o Caracteres

Campos

Registros

b)

Archivos + Metadatos + Índices + Metadatos de aplicación .

Base de datos

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 17

BASES DE DATOS RELACIONALES

Introducción a las bases de datos

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 18

BASES DE DATOS RELACIONALES

Introducción a las bases de datos

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 19

BASES DE DATOS RELACIONALES

Introducción a las bases de datos

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 20

BASES DE DATOS RELACIONALES

Introducción a las bases de datos

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.

Voy a accesar al sistema de contabilidad...

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 21

BASES DE DATOS RELACIONALES

Introducción a las bases de datos

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.

SELECT a.nomcia, a.rfccia FROM tacias a WHERE a.idcia = :fidcia; COMMIT;

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 22

BASES DE DATOS RELACIONALES

Introducción a las bases de datos

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 23

BASES DE DATOS RELACIONALES

Introducción a las bases de datos

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

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 24

BASES DE DATOS RELACIONALES

Introducción a las bases de datos

La Figura 1.12 muestra los componentes de un sistema de base de datos y las conexiones entre ellos.

Usuarios de las aplicaciones

Programadores de las aplicaciones

Usuarios Casuales

Administrador de la base de datos

Programas de aplicación

Código fuente de los programas de aplicación

Consulta

Esquema de la base de datos DBMS

Precompilador de lenguaje de manejo de datos

Procesador de consultas

Precompilador de lenguaje de definición de datos

Código objeto de los programas de aplicación

Manejador de base de datos

Manejador de archivos

Archivos de datos Diccionario de datos

Almacenamiento en disco

FIGURA 1.12. Estructura del sistema de base de datos

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 25

BASES DE DATOS RELACIONALES

Introducción a las bases de datos

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.

81315

José Luís Martínez CA-10 Matutino

83534

Alberto López CB-09 Matutino

85555

Beatriz Álvarez CF-07 Vespertino

87221

Mario Martínez

FIGURA 1.13. Ejemplo de una base de datos de red.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 26

BASES DE DATOS RELACIONALES

Introducción a las bases de datos

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.
Alumnos

81315

José Luís Martínez

85555

Beatriz Álvarez

83534

Alberto López

87221

Mario Martínez

CA-10

Matutino CB-09 Matutino

CB-09

Matutino

CF-07

Vespertino

CA-10

Matutino

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 27

BASES DE DATOS RELACIONALES

Introducción a las bases de datos

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 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.

BASES DE DATOS RELACIONALES

Fundamentos de Bases de Datos Relacionales

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.
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

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 30

BASES DE DATOS RELACIONALES

Fundamentos de Bases de Datos Relacionales

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 entidadasociación y se les llaman atributos. Por ejemplo, los posibles atributos del conjunto

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 31

BASES DE DATOS RELACIONALES

Fundamentos de Bases de Datos Relacionales

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 12765 12766 . . . Título Física General Física General . . . Autor Ullman Van Der Merwe . . . Colocación F277-739-1.1 F277-739-1.1 . . . Tema Física Física . . . Editorial Mc. Graw Hill Mc. Graw Hill . . . Páginas 289 273 . . . País México México . . .

Usuarios
Matrícula 78344 78345 . . . Nombre Jeanette Ríos Alberto Delgadillo . . . Dirección Bernal Díaz del Castillo No. 235 Rio Balsas No. 125 . . . Colonia Progreso Vista Alegre . . . Ciudad Acapulco, Gro. 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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 32

BASES DE DATOS RELACIONALES

Fundamentos de Bases de Datos Relacionales

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

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 33

BASES DE DATOS RELACIONALES

Fundamentos de Bases de Datos Relacionales

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.
Discriminador

CuentaHabientes
Número_Cuenta 1526568 1526569 . . . CuentaHabiente Domingo Abarca Ramírez Iraís Díaz Galeana . . .

Transacciones

?

Número_Transacción 1 1 . . .

Fecha 05/08/97 17/09/97 . . .

Importe 12300.00 6000.00

a)- Entidad Fuerte

a)- Entidad Débil 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).
Llave primaria

CuentaHabientes
Número_Cuenta 1526568 1526569 . . . CuentaHabiente Domingo Abarca Ramírez Iraís Díaz Galeana . . .

Transacciones
Número_Cuenta 1526568 1526569 . . . Número_Transacción 1 1 . . . Fecha 05/08/97 17/09/97 . . . Importe 12300.00 6000.00

a)- Entidad Fuerte

a)- Entidad Débil

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 34

BASES DE DATOS RELACIONALES

Fundamentos de Bases de Datos Relacionales

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 35

BASES DE DATOS RELACIONALES

Fundamentos de Bases de Datos Relacionales

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. 1 2 3 4 5 Símbolo Se lee: Uno y solo uno Cero o uno Uno o muchos Cero, uno o muchos 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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 36

BASES DE DATOS RELACIONALES

Fundamentos de Bases de Datos Relacionales

 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:

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 37

BASES DE DATOS RELACIONALES

Fundamentos de Bases de Datos Relacionales

Nombre_Entidad Key Data atributo1 [PK1] atributo2 [PK2] Non-Key Data atributo3 o o o atributoN Volume min. ##### max. ##### T abla 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: atributo1 atributo2 atributo3 . . . atributoN min. #### max. #### Nombre_Tabla_Físico Se refiere al nombre lógico que tendrá la entidad, está deberá coincidir con el nombre del Almacén del DFD. 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.

Se refiere al mínimo y máximo de registros que guardará la entidad ya como tabla física. 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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 38

BASES DE DATOS RELACIONALES

Fundamentos de Bases de Datos Relacionales

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:

DEA del Sistema Bibliotecario

Libros Préstamos Usuarios
Key Data Key Data Key Data

Numero_Adquisición [PK1]
Non-Key Data

Matrícula [PK1]
Non-Key Data

Matrícula [PK1] Número_Adquisición [PK2]
Non-Key Data

Nombre Dirección Colonia Ciudad
Volume

Puede tener

Fecha
Volume

Debe existir en

Min. 1 Max. 1000000
Tabla Ingres

Título Autor Colocación Tema Editorial Páginas País
Volume

Min. 1 Max. 10000
Tabla Ingres

TaPrestamo

Min. 1 Max. 10000
Tabla Ingres

TaUsuario

TaLibro

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:
Prefijo Id Num Ce Do SdoIni Nom Desc Stat Significado Identificador numérico que no lleva una secuencia Identificador numérico que lleva una secuencia Clave identificador alfanumérico Saldo Saldo inicial Nombre Descripción Estado lógico Sufijo Pol Emp Oper Fact Significado Póliza Empleado Operación Factura

TABLAS 2.3. Ejemplos de prefijos y sufijos para nombrar atributos.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 39

BASES DE DATOS RELACIONALES

Fundamentos de Bases de Datos Relacionales

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 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.

BASES DE DATOS RELACIONALES

Reglas de Integridad.

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

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 42

BASES DE DATOS RELACIONALES

Reglas de Integridad.

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 Inserción Regla de Integridad El número de adquisición deberá ser dado por el usuario, y verificará de forma automática que este no exista ya en la tabla. Todos los demás campos son de edición directa. se

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 43

BASES DE DATOS RELACIONALES

Reglas de Integridad.

Operación Eliminación

Regla de Integridad 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 Inserción Modificación Eliminación Regla de Integridad <Texto de regla de Inserción> <Texto de regla de Modificació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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 44

BASES DE DATOS RELACIONALES

Reglas de Integridad.

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 - Inserción Otras tablas relacionadas Ninguna Restricciones Ninguna No Mod. De Llaves No Existencia

- Modificación No aplica

- Eliminación

TaPrestamo

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 45

BASES DE DATOS RELACIONALES

Reglas de Integridad.

Tabla: TaPrestamo
Operación - Inserción Otras tablas relacionadas TaLibro TaUsuario Restricciones Existencia. Existencia. No Mod. De Llaves No Existencia. No Existencia.

- Modificación No aplica - Eliminación TaLibro TaUsuario

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 46

BASES DE DATOS RELACIONALES

Reglas de Integridad.

Tabla: TaUsuario
Operación - Inserción Otras tablas relacionadas Ninguna Restricciones Ninguna No Mod. De Llaves No Existencia.

- Modificación No aplica - Eliminación TaPrestamo

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 <Nombre_Tabla> Operación Inserción Modificación Eliminación Tablas Relacionadas <Nombre_Tabla_Rel.> Tipo de Restricción <Restricción para op.> <Restricción para op.> <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

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 47

BASES DE DATOS RELACIONALES

Reglas de Integridad.

ú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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 48

BASES DE DATOS RELACIONALES

Reglas de Integridad.

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 49

BASES DE DATOS RELACIONALES

Reglas de Integridad.

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:

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 50

BASES DE DATOS RELACIONALES

Reglas de Integridad.

Tabla TaCxP

Operación Inserción

Tablas Padre o Hijo TaPoliza

Descripción de Propagación Al insertar una cuenta por pagar se inserta la póliza correspondiente. Las modificaciones realizadas sobre la Cuenta Por Pagar afectan la póliza. La cancelación de una Cuenta Por Pagar origina la cancelación de la Póliza también. La cancelación de la Póliza provoca también la eliminación de los movimientos de la misma. No existe

Modificación

TaPoliza

Cancelación

TaPóliza

TaMovPol

TaPoliza

Inserción

TaMovPol

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 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.

BASES DE DATOS RELACIONALES

Intoducción al SQL básico

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 53

BASES DE DATOS RELACIONALES

Intoducción al SQL básico

 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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 54

BASES DE DATOS RELACIONALES

Intoducción al SQL básico

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:

Concepto de Pago @IdConcPag DescConcPag OperConcPag TaConcepto

Historia Sueldo @IdEmp @FechIniSdo @FechFinSdo SdoBaseEmp TaHistSueldo

Puesto @IdPuesto DescPuesto TaPuesto

Ligada a Compuesto de Que tiene

Periodo @IdEjer @IdPer FechIniPer FechPagoPer TaPeriodo

Realizado en

Pago @IdEjer @IdPer @IdEmp @IdConcPag ImpPag TaPago

Reciben un

Empleado @IdEmp IdPlaza NomEmp RFCEmp DirEmp NumIMSSEmp SdoBaseEmp StatEmp FechStatEmp FechIngEmp TaEmpleado

Que cubre

Plaza @IdPlaza DescPlaza IdPuesto TaPlaza

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 55

BASES DE DATOS RELACIONALES

Intoducción al SQL básico

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.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 56

BASES DE DATOS RELACIONALES

Intoducción al SQL básico

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).

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 57

BASES DE DATOS RELACIONALES

Intoducción al SQL básico

SELECT IdEmp, NomEmp, SdoBaseEmp FROM TaEmpleado WHERE Year(FechIngEmp) = 1990;

SELECT IdEmp, NomEmp, SdoBaseEmp FROM TaEmpleado WHERE Day(FechIngEmp) >= 16;

El uso de asterisco (*)
El caracter asterisco (*) tiene un uso importante dentro de una sentencia SELECT, pues este ahorra muchas veces la escritura de todos los atributos de la tabla que se desea consultar, es decir, que esto equivale a decirle al precompilador del DBMS que se desean todos los atributos de esta tabla. Su equivalente es usar la palabra reservada ALL. Por ejemplo, la primera consulta antes vista, bien pude escribirse así:
SELECT * FROM TaEmpleado;

y como seguramente ya se dio cuenta, los resultados son exactamente los mismos.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 58

BASES DE DATOS RELACIONALES

Intoducción al SQL básico

Los operadores lógicos y el Test de rango (BetWeen)
Los operadores lógicos como son AND, OR, y NOT también tienen un uso relevante en una condición WHERE. Debido a que con ellos resulta mucho más fácil acotar grupos de registros, su uso es muy frecuente en casi todas las condiciones. La siguiente consulta esta diseñada especialmente pata extraer los datos de los empleados cuyos números van del 1590 al 1592
SELECT IdEmp, NomEmp, SdoBaseEmp FROM TaEmpleado WHERE IdEmp >= 1590 AND IdEmp <= 1592;

Existe un operador muy especial en SQL conocido como Test de rango (BetWeen), y cuya finalidad es extraer datos que se encuentren entre un rango marcado por un valor inicial y uno final, y de alguna manera facilitar consultas que resultarían complicadas con solo operadores lógicos. La forma de uso de BETWEEN es la siguiente: A BetWeen B Y C donde A es el atributo cuyo valor debe encontrase entre B y C. El siguiente ejemplo nos muestra como ejecutar la misma consulta anterior inmediata con BETWEEN:

SELECT IdEmp, NomEmp, SdoBaseEmp FROM TaEmpleado WHERE IdEmp BetWeen 1590 AND 1592;

El Test de pertenencia (IN)
Habrá casos en los que se desee extraer datos muy específicos y exactos, es decir, no traer de la tabla un grupo de registros pertenecientes a un rango, sino más bien, los mínimos y exactamente deseados. Para lograr esto usando operadores lógicos, se necesita de un poco de pericia, paciencia y a veces suerte, pues la construcción de la condición para este tipo de consultas muchas veces resulta complicada. Como por ejemplo, el caso de construir una consulta para extraer los datos solamente de los empleados con número 1587, 2000, y 2001, se podría hacer de la siguiente manera:

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 59

BASES DE DATOS RELACIONALES

Intoducción al SQL básico

SELECT IdEmp, NomEmp, SdoBaseEmp FROM TaEmpleado WHERE IdEmp = 1587 OR (IdEmp >= 2000 AND IdEmp <=2001);

Ciertamente el resultado es el deseado, pero porque en realidad se ha corrido con algo de suerte pues entre 2000 y 2001 no puede haber otro número entero; pero ¿Qué pasaría si el número último fuera mayor de 2001?. Seguramente la condición se complicaría. Para estos casos existe un operador muy especial llamado de pertenencia (IN) que nos permite especificar en un conjunto de valores aquellos que deseamos exactamente. La sintaxis de IN es la siguiente: A IN (valor1, valor2, ..., valorN) donde A es el atributo cuyo valor debe ser cualquiera de valor1 a valorN. Entonces la consulta anterior bien puede construirse de la siguiente forma:

SELECT IdEmp, NomEmp, SdoBaseEmp FROM TaEmpleado WHERE IdEmp IN (1587, 2000, 2001);

Test de correspondencia con patrón (LIKE)
SQL también proporciona un operador para poder buscar en atributos cuyo contenido es de tipo caracter, usando patrones. Este es el operador LIKE, el cual puede ser acompañado por el caracter comodín signo de porcentaje (%). Para ejemplificar su uso, observe la siguiente consulta, la cual está diseñada para extraer los datos de la tabla TaEmpleado cuyos nombres empiecen con la letra ‘S’:
SELECT IdEmp, NomEmp, SdoBaseEmp FROM TaEmpleado WHERE NomEmp LIKE 'S%';

La función del % es corresponderse con cualquier secuencia de cero o más caracteres subsecuentes a lo que está antes que él, en este caso la ‘S’.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 60

BASES DE DATOS RELACIONALES

Intoducción al SQL básico

En este otro, se desea extraer los datos de aquellos empleados cuyo nombre comienza con ‘S’ y lo que continua después del espacio en blanco (el primer apellido) sea algo que comience con la palabra ‘PEREA’:

SELECT IdEmp, NomEmp, SdoBaseEmp FROM TaEmpleado WHERE NomEmp LIKE 'S%PEREA%';

Filas duplicadas (DISTINCT)
Es muy común que el resultado de una consulta muchas veces traiga filas o registros duplicados, algo que no siempre es agradable y mucho menos deseable. Así por ejemplo, la sentencia de abajo hace una consulta sobre la tabla TaHistSueldo para extraer los empleados que ahí están registrados.

SELECT IdEmp FROM TaHistSueldo;

Como pudo ver, el resultado de la consulta es muchos números de empleado repetidos, es decir, registros duplicados. Para solucionar esto, existe un especificador llamado DISTINCT, que como su nombre lo indica su función es hacer que solo aparezcan los que cumplan la condición de distintos suficientes, es decir, uno de cada grupo de registros repetidos que lo hagan distinto de otro de otro grupo, y así sucesivamente. Así, el problema ocasionado por la consulta anterior puede resolverse con la siguiente:

SELECT DISTINCT IdEmp FROM TaHistSueldo;

Consultas multitablas (Join)
Hasta ahora solo se han realizado consultas sobre una sola tabla, algo que resulta ser muy sencillo. Sin embargo, en la práctica no siempre es así, pues muy comúnmente se requerirá extraer información la cual esté compuesta de atributos que pertenezcan a

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 61

BASES DE DATOS RELACIONALES

Intoducción al SQL básico

diferentes tablas. SQL permite hacer esto utilizando la característica de asociación (Join) que es propia del álgebra relacional. Los Join pueden realizarse usando simplemente los nombres de las tablas y sus atributos, o también usando alias de las tablas que facilitan mucho la legibilidad de las sentencias, pero sobre todo que resuelven el problema de ambigüedad cuando existen atributos con el mismo nombre en dos o más tablas que forman parte del Join. Los alias, no son más que sustituciones de nombres de tablas por otros, casi siempre más cortos (el alias) y que son utilizados para evitar confusiones en la ejecución y lectura de una consulta. Aunque bien estos alias pueden ser los propios nombres de las tablas. Por ejemplo, si quisiéramos referirnos a atributos IdPlaza e IdPuesto de la tabla TaPlaza usando el alias x, entonces esto tendría que escribirse así: x.IdPlaza, x.IdPuesto Veamos el ejemplo siguiente:

SELECT IdEmp, NomEmp, DescPlaza, SdoBaseEmp FROM TaEmpleado, TaPlaza;

Observe que el resultado total en registros leídos es igual a 275 que es nada más y nada menos que el resultado de multiplicar 11 X 25, es decir, el número de registros que existen en la tabla TaEmpleado por el número de registros que existen en TaPlaza. Esto se debe a que como se comentó anteriormente, los Join (y todo el SQL) son construidos siguiendo las reglas del álgebra relacional, por lo que un Join, es el producto de dos o más tablas. La solución a esto es muy simple, y consiste en utilizar condiciones WHERE lo bastantes completas como para evitar la multiplicación de datos. Por lo que el problema de la consulta anterior se puede resolver ligando los atributos de asociación que existen entre una tabla y otra, como se muestra a continuación:

SELECT a.IdEmp, a.NomEmp, b.DescPlaza, a.SdoBaseEmp FROM TaEmpleado a, TaPlaza b WHERE a.IdPlaza = b.IdPlaza;

Aun si la complejidad creciera al aumentar más tablas al Join, esto no debe preocuparnos si las asociaciones de atributos en la cláusula WHERE están debidamente construidas. Así, si a la consulta anterior le agregamos una tabla más como es TaPuesto, esto puede solucionarse fácil asociando los atributos IdPuesto de las tablas correspondientes, en este caso TaPlaza y TaPuesto, tal como lo muestra la siguiente sentencia:

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 62

BASES DE DATOS RELACIONALES

Intoducción al SQL básico

SELECT a.IdEmp, a.NomEmp, b.DescPlaza, c.DescPuesto, a.SdoBaseEmp FROM TaEmpleado a, TaPlaza b, TaPuesto c WHERE a.IdPlaza = b.IdPlaza AND b.IdPuesto = c.IdPuesto;

Funciones de Agrupación (Sum, Avg, Count, Max, Min)
Siempre será necesario en cualquier lenguaje, funciones que cumplan la misión de agrupar datos y después operar sobre este grupo obteniendo un resultado específico (la suma del grupo, el promedio, el total, el mínimo, el máximo, etc.). En los lenguajes de programación comunes generalmente estos grupos son arreglos o estructuras de datos en memoria. SQL también contiene estas funciones, pero a diferencia de los lenguajes normales, las operaciones son sobre columnas de tablas de la base de datos. Todas estas funciones (llamadas funciones de columna) pueden usarse de forma simple, cuando lo que intervenga en la cláusula SELECT solamente sea la columna agrupada, pero cuando esta esté acompañada de una o más columnas no agrupadas, entonces será necesario incluir en la parte final de la sentencia la cláusula GROUP BY.

La función Suma (Sum)
La función Sum() proporciona la suma completa de todos los datos que estén en la columna agrupada. Esto es muy necesario cuando se desea saber, por ejemplo, el número total de mercancías en el almacén. Y esto se logra precisamente sumando todos los valores de la columna que contenga las cantidades de existencia de estas mercancías en la tabla de mercancías. Veamos el siguiente código SQL:
SELECT ImpPag FROM TaPago WHERE IdEjer = 1999;

La intención real de este código es extraer el total pagado a los empleados en el año de 1999, sin embargo, lo único que se consigue es traer todas las cantidades de importes de pago de cada uno de los empleados, lo cual no nos ayuda en mucho. Si ahora modificamos un poco este código y hacemos uso de la función Sum, este podría quedar así:

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 63

BASES DE DATOS RELACIONALES

Intoducción al SQL básico

SELECT Sum(ImpPag) FROM TaPago WHERE IdEjer = 1999;

Y el resultado obtenido es el deseado. Lo que estamos haciendo es sumarizar todos los valores que se encuentren en la columna ImpPag de la tabla TaPago cuando el ejercicio (IdEjer) haya sido el año de 1999. Ahora tenemos el caso de extraer nuevamente estos importes de la misma tabla, pero para períodos específicos (1 y 2: mes de enero) y el empleado 1587:
SELECT Sum(ImpPag) FROM TaPago WHERE IdEjer = 1999 AND IdPer IN (1,2) AND IdEmp = 1587;

El resultado de este SELECT es bastante engañoso, pues si bien nos da la suma correcta, en realidad nos está proporcionando el total pagado sin importar si se trata de un ingreso o de un descuento. Para solucionar esto veamos primero, que conceptos fueron pagados y cual es su naturaleza de pago de cada uno de ellos (deducción o percepción). Para ello hacemos el siguiente SELECT basado en un Join de las tablas TaPago y TaConcepto:

SELECT a.ImpPag, b.IdConcPag, b.OperConcPag FROM TaPago a, TaConcepto b WHERE a.IdEjer = 1999 AND a.IdPer IN (1,2) AND a.IdEmp = 1587 AND a.IdConcPag = b.IdConcPag;

El resultado es el deseado. La consulta siguiente nos proporciona el total pagado en estos períodos (en el mes) sin distinguir:

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 64

BASES DE DATOS RELACIONALES

Intoducción al SQL básico

SELECT Sum(a.ImpPag * b.OperConcPag) FROM TaPago a, TaConcepto b WHERE a.IdEjer = 1999 AND a.IdPer IN (1,2) AND a.IdEmp = 1587 AND a.IdConcPag = b.IdConcPag;

Si deseamos saber cuanto se le pagó en cada período (quincena) tendremos que modificar nuestra consulta para que nos divida la suma en dos filas:

SELECT a.IdPer, Sum(a.ImpPag * b.OperConcPag) FROM TaPago a, TaConcepto b WHERE a.IdEjer = 1999 AND a.IdPer IN (1,2) AND a.IdEmp = 1587 AND a.IdConcPag = b.IdConcPag GROUP BY a.IdPer;

Observe que ahora se usó la cláusula GROUP BY, la cual es necesaria pues se ha agregado una columna al SELECT, la cual no forma parte de la sumarización, pero que nos permite indicarle a SQL que deseamos hacer una suma agrupando por IdPer, es decir, una suma por cada período distinto, en este caso 1 y 2.

La función Promedio (Avg)
La función Avg() se usa para calcular el valor promedio de un grupo de datos de la columna especificada. El siguiente código nos despliega el importe de pago por el concepto sueldo en cada período para el año 1999 y el mes de enero:
SELECT IdEmp, IdPer, ImpPag FROM TaPago WHERE IdEjer = 1999 AND IdPer IN (1, 2) AND IdConcPag = 1000 ORDER BY IdPer, IdEmp;

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 65

BASES DE DATOS RELACIONALES

Intoducción al SQL básico

Como se habrá dado cuenta, se ha agregado una nueva cláusula a la sentencia SELECT. La cláusula ORDER BY. Esta cláusula es necesaria cuando se desea que nuestros datos sean extraídos en un orden específico, lo cual lo determinan los atributos escritos después del ORDER BY. En este caso IdPer e IdEmp. Centrándonos nuevamente en el resultado del SELECT anterior, se nos ocurre ahora que podríamos calcular el importe de pago promedio para este mismo concepto, en este mismo año y mes. Esto lo logramos de la siguiente manera:

SELECT IdPer, Avg(ImpPag) FROM TaPago WHERE IdEjer = 1999 AND IdPer IN (1, 2) AND IdConcPag = 1000 GROUP BY IdPer;

Necesitamos agrupar por IdPer para que el resultado sea el buscado, de lo contrario no obtendríamos lo especificado anteriormente.

La función Cuenta (Count)
La función Count() realiza un conteo del número de registros encontrados en la columna no importando el tipo de esta. Esta función siempre devolverá un valor entero, que es exactamente el número de registros contados. Por ejemplo, para determinar cuantos registros (empleados) existen en la tabla TaEmpleado podemos lograrlo usando Count() así:
SELECT Count(*) FROM TaEmpleado;

También podemos hacer uso de condiciones en la cláusula WHERE, como en el ejemplo siguiente, que extrae el número de empleados actualmente activos (con status=1):
SELECT Count(*) FROM TaEmpleado WHERE StatEmp = 1;

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 66

BASES DE DATOS RELACIONALES

Intoducción al SQL básico

Las dos siguientes consultas nos proporcionan resultados diferentes, y esto es debido a que el número de registros para cada empleado (1590 y 1594) en la tabla TaHistSueldo, son diferentes:
SELECT Count(*) FROM TaHistSueldo WHERE IdEmp = 1590;

SELECT Count(*) FROM TaHistSueldo WHERE IdEmp = 1594;

La siguiente sentencia es solo para ejemplificar como se puede usar el resultado de una función de agrupación, como es Count(), con cualquier operando, ya sea otro atributo o bien una constante directa como es un número:

SELECT Count(IdEmp) * 300 FROM TaHistSueldo WHERE; IdEmp = 1594;

La función Máximo (Max)
Esta función obtiene el valor máximo de la columna agrupada. La siguiente sentencia obtiene el número de empleado mayor que existe en la tabla TaEmpleado:

SELECT Max(IdEmp) FROM TaEmpleado;

Esta otra pretende obtener el máximo pago hecho por concepto de sueldo:

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 67

BASES DE DATOS RELACIONALES

Intoducción al SQL básico

SELECT Max(ImpPag) FROM TaPago WHERE IdConcPag = 1000;

Con la siguiente, la intención es encontrar esto mismo pero identificando a que empleado se le otorgo este pago:
SELECT IdEmp, Max(ImpPag) FROM TaPago WHERE IdConcPag = 1000 Group By IdEmp;

Sin embargo, el resultado no es el esperado, y esto se debe a que en realidad lo que estamos especificando aquí, es que nos traiga el importe máximo pagado por concepto de sueldo, pero por cada empleado. Para hacer que nuestra consulta haga lo que nosotros esperamos, haremos uso de un procedimiento válido y a veces muy socorrido en el SQL: las subconsultas. Una subconsulta es un SELECT que forma parte del WHERE de otro SELECT, es decir, un SELECT anidado.

SELECT IdEmp, Max(ImpPag) FROM TaPago WHERE IdConcPag = 1000 AND ImpPag = (SELECT Max(ImpPag) FROM TaPago WHERE IdConcPag = 1000) GROUP BY IdEmp;

Se especifica que se extraiga el máximo importe pagado por concepto de sueldo, y con el empleado que le corresponde esta cantidad, siempre y cuando este importe sea el máximo del total que existen en la propia tabla.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 68

BASES DE DATOS RELACIONALES

Intoducción al SQL básico

La función Mínimo (Min)
La función Min() obtiene el valor mínimo de la columna agrupada. Las siguientes sentencias realizan operaciones similares a las anteriores para la función Max(), pero ahora calculando el mínimo:

SELECT Min(IdEmp) FROM TaEmpleado;

SELECT Min(ImpPag) FROM TaPago WHERE IdConcPag = 1000;

SELECT IdEmp, Min(ImpPag) FROM TaPago WHERE IdConcPag = 1000 Group By IdEmp;

SELECT IdEmp, Min(ImpPag) FROM TaPago WHERE IdConcPag = 1000 AND ImpPag = (SELECT Min(ImpPag) FROM TaPago WHERE IdConcPag = 1000) GROUP BY IdEmp;

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 69

BASES DE DATOS RELACIONALES

Intoducción al SQL básico

Adición de datos (Insert)
La modificación de la base de datos es una cosa de todos los días en la operación de un sistema de información. Agregar, actualizar o eliminar registros de las tablas son operaciones que son fundamentales; por lo que SQL proporciona tres sentencias diferentes para estos casos, una para cada operación: Insert, Update y Delete. La sentencia INSERT es usada exclusivamente para agregar nuevos registros a una tabla especifica (una a la vez). Esto se puede hacer con sentencias simples de valores directos usando la cláusula VALUES o bien a partir de un SELECT. En este momento veremos el primer caso y dejaremos el segundo para después. La sintaxis de INSERT usando VALUES es como sigue: INSERT INTO Tabla VALUES(Valor1, Valor2, Valor3, ..., ValorN); donde Tabla es el nombre de la tabla a la cual se desea agregar registros y Valor1, Valor2, Valor3, ..., ValorN son los valores del registro que se desea agregar en dicha tabla, los cuales tienen correspondencia con cada una de las columnas de esta. Por ejemplo, deseamos agregar un nuevo empleado, una nueva plaza y un nuevo puesto con las siguientes sentencias:

INSERT INTO TaEmpleado VALUES(1000, 200, 'RAMON DIAZ LUNA', 'DILR-680914-Q23', 'DOM. CONOCIDO', 3542627682, 1, 250.00, Date('1998/11/16'), Date('1998/08/16'));

INSERT INTO TaPlaza VALUES (200, 'Capacitación', 23);

INSERT INTO TaPuesto VALUES (23, 'Capacitador de Personal');

¿Tuvo problemas?. Esto es normal, pues si recuerda un poco acerca de las reglas de integridad en tablas, al ejecutar estas sentencias estamos violando más de una. ¿Podría corregirlo?.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 70

BASES DE DATOS RELACIONALES

Intoducción al SQL básico

Eliminación de datos (Delete)
La eliminación de registros de una tabla, se hace por medio de la sentencia DELETE, y cabe aclarar que aquí, una vez eliminados los registros es imposible recuperarlos. La sintaxis de DELETE es: DELETE FROM Tabla WHERE <Condición>; donde Tabla es la tabla de la cual se desean eliminar registros y Condición es una condición cualquiera usada en un WHERE. Trate ahora de ejecutar las siguientes sentencias:

DELETE FROM TaPuesto WHERE IdPuesto = 23;

DELETE FROM TaPlaza WHERE IdPlaza = 200;

DELETE FROM TaEmpleado WHERE IdEmp = 1000;

DELETE FROM TaHistSueldo WHERE IdEmp = 1000;

¿Volvió a tener problemas?. Trate de explicar porque.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 71

BASES DE DATOS RELACIONALES

Intoducción al SQL básico

Actualización de datos (Update)
La sentencia UPDATE tiene la función de actualizar uno o más registros de acuerdo a una condición. Su sintaxis es como sigue: UPDATE Tabla SET Atributo1 = Valor1, Atributo2 = Valor2, . . . AtributoN = ValorN WHERE <Condición>; donde Tabla es la tabla que se desea modificar, Atributo1, Atributo2, ..., AtributoN son las columnas que desean modificarse y Valor1, Valor2, ..., ValorN son los nuevos valores que tendrán estas columnas. Condición es una condición cualquiera usada en un WHERE. En el siguiente ejemplo, se supone que al empleado número 1000 (el cual fue agregado anteriormente) se le ha cambiado de sueldo, por lo que su sueldo anterior debe pasar al histórico de sueldos y posteriormente modificar en la tabla TaEmpleado su sueldo con el importe nuevo. Note aquí que para el primer paso, se está usando un INSERT a partir de un SELECT, es decir, el segundo caso de esta sentencia del que ya habíamos comentado.

INSERT INTO TaHistSueldo SELECT b.IdEmp, b.FechIngEmp, Date('1999/04/30'), b.SdoBaseEmp FROM TaEmpleado b WHERE b.IdEmp = 1000;

UPDATE TaEmpleado SET SdoBaseEmp = 300.00 WHERE IdEmp = 1000;

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 72

BASES DE DATOS RELACIONALES

Intoducción al SQL básico

Creación de tablas (Create)
La sentencia CREATE cuya función es crear tablas, es siempre útil cuando no se tiene un asistente de DBMS, o bien cuando se desean crear tablas temporales en tiempo de ejecución en alguna aplicación.

La sintaxis de CREATE es: CREATE TABLE Tabla ( Atributo1 Tipo_de_dato [especificación_de_nulidad], Atributo2 Tipo_de_dato [especificación_de_nulidad], . . . AtributoN Tipo_de_dato [especificación_de_nulidad], PRIMARY KEY (Atributos_Llave), . . . [Otras_especificaciones]);

donde Tabla es el nuevo nombre de la tabla a crear (el cual no debe existir), Atributo1, Atributo2, ..., AtributoN son los nombres de las columnas de la nueva tabla. Tipo_de_dato es cualquier tipo de dato válido aceptado por el DBMS (integer, float, char, varchar, date, etc.), especificación_de_nulidad le informa a la base de datos que el Atributo en cuestión recibirá o no datos nulos en cualquier modificación. La cláusula PRIMARY KEY es usada para definir la llave primaria de la tabla. Ejemplo: Suponga que le han solicitado que envíe un reporte en una tabla temporal llamada TaTemporal los datos necesarios (Período, Número, Nombre y Pago) de aquellos empleados que han cobrado sueldo en el último período de 1999. Una forma de solucionar esto es, primero construir una tabla temporal con las especificaciones solicitadas y haciendo llave primaria a las dos primera columnas:

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 73

BASES DE DATOS RELACIONALES

Intoducción al SQL básico

CREATE TABLE TaTemporal ( IdPer integer not null, IdEmp integer not null, NomEmp varchar(40) not null, ImpPag float not null, PRIMARY KEY (IdPer, IdEmp));

posteriormente, hay que insertar en esta tabla los datos solicitados, para lo que será necesario auxiliarse de un subselect que nos traiga exactamente los datos correspondientes al último período, es decir, el máximo:

INSERT INTO TaTemporal SELECT b.IdPer, a.IdEmp, a.NomEmp, b.ImpPag FROM TaEmpleado a, TaPago b WHERE b.IdEmp = a.IdEmp AND b.IdEjer = 1999 AND b.IdConcPag = 1000 AND b.IdPer = (SELECT Max(IdPer) FROM TaPago WHERE IdEjer = 1999 AND IdConcPag = 1000) ORDER BY a.IdEmp;

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 74

BASES DE DATOS RELACIONALES

Intoducción al SQL básico

4.4. Notas finales acerca de SQL
Si bien el tema no está orientado a convertir a los participantes en verdaderos expertos de SQL, si permite a los mismos abrirse un panorama más amplio acerca de la potencia de este lenguaje de consulta. Pues aunque se haya leído o escuchado acerca de él, nunca la teoría sin la debida práctica, ayudará en mucho a un futuro diseñador u operador de bases de datos relacionales con verdaderos DBMS.

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 75

5-Apéndices

A pesar de que hoy en día se experimenta con nuevos tipos de bases de datos como son las orinetadas a objeto, faltará mucho tiempo todavía para que estas puedan suplantar en su totalidad a las relacionales, pués a pesar de todo , estas siguen siendo una garantía en el proceso rápido de datos, y además, sin muchas complicaciones.

R. Fagin, experto en BD. Enero de 1999.

BASES DE DATOS RELACIONALES

Apéndice B

Apéndice A: Estructura de tablas de la base de datos ejemplo NOMINA:

Tabla: TaEmpleado Atributo Tipo IdEmp integer IdPlaza integer NomEmp varchar RFCEmp varchar DirEmp varchar NumIMSSEmp integer SdoBaseEmp float StatEmp integer FechStatEmp date FechIngEmp date

Longitud

40 15 100

Tabla: TaPlaza Atributo Tipo IdPlaza integer DescPlaza varchar IdPuesto integer

Longitud 30

Tabla: TaPuesto Atributo Tipo IdPuesto integer DescPuesto varchar

Longitud 30

Tabla: TaPeriodo Atributo Tipo IdEjer integer IdPer integer FechIniPer integer FechFinPer integer

Longitud

Tabla: TaConcepto Atributo Tipo IdConcPag integer DescConcPag varchar OperConcPag integer

Longitud 30

Tabla: TaPago Atributo Tipo IdEjer integer IdPer integer IdEmp integer IdConcPag integer ImpPag float

Longitud

Tabla: TaHistSueldo Atributo Tipo IdEmp integer FechIniSdo date FechFinSdo date SdoBaseEmp float

Longitud

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 77

BASES DE DATOS RELACIONALES

Apéndice B

Apéndice B: Contenido de tablas de la base de datos ejemplo NOMINA:
Se aclara aquí, que algunas tablas no están presentadas en su totalidad de registros debido al tamaño que estas tienen, en especial las tablas TaPeriodo y TaPago que llegan a rebasar el medio millar de tuplas.
Tabla: TaPlaza IdPlaza DescPlaza 100 Auxiliar Ventas 101 Ventas 102 Auxiliar de contabilidad 103 Coordinación de Contabilidad 104 Coordinación de Contabilidad 105 Auxiliar Auditoría 106 Auditoría 107 Programador 108 Programador 109 Analista 110 Analista 111 Coordinador 112 Auxiliar Mecánico 113 Mecánico 115 Vigilante 116 Vigilante 117 Programador 118 Prgramador 119 Coordinador 120 Coordinador 121 Gerente 122 Gerente 123 Gerente 124 Gerente 125 Gerente IdPuesto 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 15 8 9 12 16 17 19 20 21 22 Tabla: TaPuesto IdPuesto DescPuesto 1 Auxiliar de ventas 2 Vendedor Titular 3 Auxilar de contabilidad 4 Coordinador de CXC 5 Coordinador de CXP 6 Auxiliar de Auditoría 7 Auditor 8 Programador A 9 programador B 10 Analista A 11 Analista B 12 Lider de Proyectos 13 Ayudante de mecánico 14 Mecánico titular 15 Vigilante 16 Jefe de Vigilantes 17 Gerente de Ventas 18 Gerente de Compras 19 Gerente de Desarr. de Sistemas 20 Gerente de Contabilidad 21 Gerente de Auditoría interna 22 Gerente de Mantenimiento Tabla: TaPeriodo IdEjer IdPer FechIniPer FechPagoPer 1999 1 01/01/99 14/01/99 1999 2 16/01/99 29/01/99 1999 3 01/02/99 13/02/99 1999 4 16/02/99 27/02/99 1999 5 01/03/99 14/03/99 1999 6 16/03/99 29/03/99 1999 7 01/04/99 14/04/99 1999 8 16/04/99 28/04/99 1999 9 01/05/99 13/05/99 1999 10 16/05/99 27/05/99 1999 11 01/06/99 14/06/99 1999 12 16/06/99 28/06/99 1999 13 01/07/99 13/07/99 1999 14 16/07/99 29/07/99 1999 15 01/08/99 13/08/99 1999 16 16/08/99 28/08/99 1999 17 01/09/99 13/09/99 1999 18 16/09/99 27/09/99 1999 19 01/10/99 14/10/99 1999 20 16/10/99 27/10/99 1999 21 01/11/99 14/11/99 1999 22 16/11/99 29/11/99 1999 23 01/12/99 12/12/99 1999 24 16/12/99 28/12/99

Tabla: TaConcepto IdConcPag DescConcPag 1000 Sueldo 1001 Tiempo Extra 1002 Ayuda de Despensa 2001 IMSS 2002 INFONAVIT 2003 SAR

OperConcPag 1 1 1 -1 -1 -1

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 78

BASES DE DATOS RELACIONALES

Apéndice B

Tabla: TaPago IdEjer IdPer IdEmp IdConcPag 1999 1 1587 1000 1999 1 1587 2001 1999 1 1587 2002 1999 1 1587 2003 1999 2 1587 1000 1999 2 1587 1002 1999 2 1587 2001 1999 2 1587 2002 1999 2 1587 2003

ImpPag 2250.00 300.00 100.00 120.00 2250.00 1000.00 770.00 200.00 300.00

Tabla: TaHistSueldo Idemp FechIniSdo 1587 12/01/96 1587 1/01/98 1588 1/05/95 1588 1/01/98 1589 16/01/90 1589 1/01/98 1590 1/11/91 1590 1/01/98 1591 16/01/93 1591 1/01/97 1592 16/12/90 1592 1/01/98 1593 1/01/88 1593 1/01/98 1594 16/06/98 1595 1/01/85 1595 1/01/98 2000 1/01/86 2000 1/01/96 2001 1/02/85 2001 1/01/98

FechFinSdo 31/12/97 31/12/98 31/12/97 30/06/99 31/12/97 31/12/98 31/12/98 31/12/98 31/12/96 31/12/98 31/12/98 15/03/99 31/12/97 31/12/98 31/12/98 31/12/97 31/12/98 31/12/95 31/12/98 31/12/97 31/12/98

SdoBaseEmp 100 125 75 100 150 175 250 275 250 275 275 300 425 400 275 400 425 675 650 650 675

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 79

BASES DE DATOS RELACIONALES

Apéndice B

Tabla: TaEmpleado IdEmp IdPlaza NomEmp 1587 101 GONZALO FLORES DAVALOS 1588 100 ARTURO SALAS HERNANDEZ 1589 102 CECILIA MOSSO LOMELI 1590 103 LAURA ALVAREZ JIMENEZ 1591 107 PABLO DIAZ RUIZ 1592 109 RAUL NAJERA SUAREZ 1593 111 SANDRA PEREA URIOSTEGUI 1594 117 HORACIO NORIEGA SALMERON 1595 120 LUIS MENDOZA CONTRERAS 2000 122 SALVADOR BALBUENA RAMIREZ 2001 121 FERNANDO ZAPATA BUSTOS

RFCEmp FODG-670419-E34 SAHA-701123-U34 MOLC-700212 AAJL-690720-O90 DIRP-740523-A23 NASR-720923-K23 PEUS-701210-D45 NOSH-750119-I45 MECL-660315-T56 BARS-690113-Y78 ZABF-660124-A90

DirEmp NumIMSSEmp SdoBaseEmp StatEmp FechStatEmp FechIngEmp ZARAGOZA 100, COL. ZAPATA, ACAPULCO, 1783429082 150.00 1 12/04/96 12/01/96 RIO BRAVO 123, COL. HOGAR MODERNO, A 3456123478 100.00 0 01/07/99 01/10/95 COSTERA MIGUEL ALEMAN 206, FRACC. MA 3456878909 200.00 1 16/09/90 16/07/90 AV. FARALLON NO. 148, ACAPULCO, GRO. 1287996578 300.00 1 01/02/92 01/11/91 CALZ. PIE DE LA CUESTA NO. 43-G, ACAPUL 5675687231 300.00 1 16/04/93 16/01/93 BENITO JAUREZ NO. 19 1er. PISO, UNID. HA 1254676790 300.00 0 16/03/99 16/12/90 AV. EJIDO 81, COL. HOGAR MODERNO, ACA 3254568798 450.00 1 01/04/88 01/01/88 CALLE LA LOMA NO. 1, INT. 2, FRACC. CUMB 7898908001 300.00 1 16/09/98 16/06/98 GAVIOTAS 25, FRACC. LAS PLAYAS, ACAPU 5677897892 450.00 1 01/05/85 01/02/85 FERNADO DE MAGALLANES NO. 4, FRACC. 5667544678 700.00 1 01/01/86 01/01/86 HERNAN CORTES 28, FRACC. MAGALLANES 4565678891 700.00 1 01/02/85 01/02/85

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 80

BASES DE DATOS RELACIONALES

Apéndice C

Apéndice C: Script SQL para crear las tablas de la base de datos ejemplo NOMINA:
CREATE TABLE TaEmpleado ( IdEmp integer not null, IdPlaza integer not null, NomEmp varchar(40) not null, RFCEmp varchar(15) not null, DirEmp varchar(100) not null, NumIMSSEmp integer not null, SdoBaseEmp float not null, StatEmp integer not null, FechStatEmp date not null, FechIngEmp date not null, PRIMARY KEY (IdEmp, IdPlaza)); CREATE TABLE TaPlaza ( IdPlaza integer not null, DescPlaza varchar(40) not null, IdPuesto integer not null, PRIMARY KEY (IdPlaza)); CREATE TABLE TaPuesto ( IdPuesto integer not null, DescPuesto varchar(40) not null, PRIMARY KEY (IdPuesto));

CREATE TABLE TaPeriodo ( IdEjer integer not null, IdPer integer not null, FechIniPer date not null, FechPagoPer date not null, PRIMARY KEY (IdEjer, IdPer));

CREATE TABLE TaConcepto ( IdConcPag integer not null, DescConcPag varchar(30) not null, OperConcPag integer not null, PRIMARY KEY (IdConcPag));

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 81

BASES DE DATOS RELACIONALES

Apéndice C

CREATE TABLE TaPago ( IdEjer integer not null, IdPer integer not null, IdEmp integer not null, IdConcPag integer not null, ImpPag float not null, PRIMARY KEY (IdEjer, IdPer, IdEmp, IdConcPag));

CREATE TABLE TaHistSueldo ( IdEmp integer not null, FechIniSdo date not null, FechFinSdo date not null, SdoBaseEmp float not null, PRIMARY KEY (IdEmp, FechIniSdo, FechFinSdo));

© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas.

página 82