Introducción a las bases de datos relacionales

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 ______________________________________________ 26

Base de datos tipo relacional ____________________________________________ 26

Base de datos tipo red _________________________________________________ 26

Base de datos tipo jerárquico ____________________________________________ 27

1.3 Confusiones acerca de las Bases de Datos _______________________________ 28

Advertencia: las hojas de cálculo no son bases de datos _______________________ 28

2-Fundamentos de bases de datos relacionales _____________________ 29

2.1. Diseño de bases de datos relacionales __________________________________ 30

2.1.1. Diagrama de Entidades y Asociaciones (DEA) _________________________ 31

Enfoque de Entidad-Asociación ________________________________________ 31

Componentes de un DEA _____________________________________________ 31

Componentes gráficos de un Diagrama de entidad-asociación ________________ 35

2.2. Resistencia al Modelo Relacional _____________________________________ 40

3-Reglas de integridad ________________________________________ 41

3.1. Reglas de Integridad de la Base de Datos ______________________________ 42

Reglas de Integridad de Tablas __________________________________________ 42

Reglas de Integridad entre Tablas ________________________________________ 44

3.2. Propagación de Operaciones ________________________________________ 49

4-Introducción al SQL básico __________________________________ 52

4.1. ¿Que es SQL? _____________________________________________________ 53

4.2. Las funciones de SQL ______________________________________________ 53

4.3. Trabajando con SQL _______________________________________________ 55

Recuperación de datos (Select) __________________________________________ 56

La Cláusula WHERE ________________________________________________ 57

El uso de asterisco (*) ________________________________________________ 58

Los operadores lógicos y el Test de rango (BetWeen) _______________________ 59

El Test de pertenencia (IN) ____________________________________________ 59

Test de correspondencia con patrón (LIKE) _______________________________ 60

Filas duplicadas (DISTINCT) __________________________________________ 61

Consultas multitablas (Join) ___________________________________________ 61

Funciones de Agrupación (Sum, Avg, Count, Max, Min) ______________________ 63

La función Suma (Sum) ______________________________________________ 63

La función Promedio (Avg) ___________________________________________ 65

La función Cuenta (Count) ____________________________________________ 66

La función Máximo (Max) ____________________________________________ 67

La función Mínimo (Min) _____________________________________________ 69

Adición de datos (Insert) _______________________________________________ 70

Eliminación de datos (Delete) ___________________________________________ 71

Actualización de datos (Update) _________________________________________ 72

Creación de tablas (Create) ____________________________________________ 73

4.4. Notas finales acerca de SQL _________________________________________ 75

5-Apéndices _________________________________________________ 76

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

Apéndice B: Contenido de tablas de la base de datos ejemplo NOMINA: _______ 78

Apéndice C: Script SQL para crear las tablas de la base de datos ejemplo

NOMINA: ___________________________________________________________ 81

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

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

Un comentario acerca de las Bases de Datos A pesar de las múltiples confusiones conceptuales que todavía existen acerca de las

bases de datos, es imposible negar que su desarrollo y avance tecnológico es a pasos

agigantados, por lo que aquellos profesionales del desarrollo de software que no se

actualicen en la materia, simple y sencillamente se quedarán a la zaga o al margen de la

creación y operación de los nuevos y grandes sistemas de información. Hoy en día, y debido

a la importancia que tiene la información en todas las organizaciones, a las bases de datos

se les ha puesto gran atención y ello ha conducido al desarrollo de conceptos y técnicas para

manejar los datos en forma eficiente. En este curso se estudiarán todos esos conceptos a

detalle.

1.1. Definición de Base de Datos Una base de datos es un conjunto cualquiera de datos estructuralmente relacionados

entre sí. Convencionalmente, los datos se organizan como un archivo de datos, el archivo

consta de registros y los registros están compuestos por uno o más campos de datos, siendo

los campos de un tipo de dato de un conjunto de varios tipos de datos. Sin embargo,

muchas veces la definición anterior resulta demasiado pobre al usuario. Por lo mismo, para

poder entender mejor lo que significa una base de datos, empezaremos por ver las

particularidades de los sistemas que precedieron al uso de la tecnología de las bases de

datos, es decir, los sistemas de procesamiento de archivos, ya que estos sistemas revelan los

problemas que ha resuelto la tecnología de las bases de datos.

1.1.1. Sistemas de procesamiento de archivos Como se mencionó anteriormente un archivo de datos es un cúmulo de datos de

diferentes tipos organizados en un mismo lugar, que es el propio archivo. Este archivo está

identificado con un nombre propio y con este se le hace acceso ya sea para agregar,

eliminar, modificar o solamente consultar datos.



El archivo está estructuralmente compuesto por registros, que son bloques contiguos

identificados por un número llamado número de registro, a su vez estos registros están

conformados por divisiones de menor tamaño de información llamadas campos1, donde

estos campos almacenarán cualquier tipo de datos, es decir, que estos pueden ser datos

alfanuméricos o numéricos según sea la necesidad.

FIGURA 1.1. Forma o estructura de un archivo de datos.

En el pasado los sistemas de procesamiento de archivos eran generalmente

proporcionados por el fabricante del computador (tales como la nómina y los registros de

contabilidad) como parte del sistema operativo, llevaba la cuenta de los nombres y

ubicaciones de los archivos. El sistema de gestión de archivos básicamente no tenía un

modelo de datos, es decir, no sabía nada acerca de los contenidos internos de los archivos.

Para el sistema de gestión de archivos un archivo que contuviera un documento de

procesamiento de textos y un archivo que contuviera datos de nóminas simplemente no los

distinguiría. El conocimiento acerca del contenido de un archivo –que datos almacena y

como están organizados- estaba incorporado a los programas de aplicación que utilizaban el

archivo.

1 Los títulos de los campos no son almacenados en el archivo, es decir, que no forman parte de él, aquí se presentan para

una mera explicación.

NomEmp DirEmp FechNac IngAnual

1 Rosalba Arciniega López Av. Michoacán 1340, Col. Progreso. 750612 50000.00

2 Domingo Abarca Ramírez Cuauhtémoc 70-B, Col. Centro 680514

3 Eva Samayoa Dorantes Gaviotas 45,Fracc. Las Playas, Caleta. 740422 60000.00

.

.

.

99 Alejandro Apac Sandoval Baja California 99, Col. Progreso. 690223 200000.00

100 Luis Orozco Bedolla Mina 64, Col. Centro. 660825 100000.00

Registros

No. de Registro Campos alfanuméricos Campos numéricos



Así, tal como lo muestra la Figura 1.2. los primeros sistemas de información

comerciales almacenaban grupos de registros en archivos separados.

FIGURA 1.2. Aplicación de nómina utilizando un sistema de procesamiento de archivos.

En esta aplicación de nómina, cada uno de los programas (hechos en COBOL) que

procesaban el archivo maestro de empleados contenía una descripción de archivo (DA) que

describía la composición de los datos en el archivo. Si la estructura de los datos cambiaba –

por ejemplo, si un grupo adicional de datos fuera a ser almacenado por cada empleado-

todos los programas que accedían al archivo tenían que ser modificados. Como el número

de archivos y programas crecía con el tiempo, todo el esfuerzo de procesamiento de datos

de un departamento de desarrollo se perdía en mantener aplicaciones (programas) existentes

en lugar de desarrollar otras nuevas.

Programa de actualización de empleados. DA

Archivo maestro de empleados

Programa de informe de empleados. DA

Archivo de historia de

sueldos

Programa de impresión de cheques. DA

DA

Usuario del sistema de nómina.



Aunque los sistemas de procesamiento de archivos representan una significativa mejoría

sobre los sistemas manuales de registro, estos tienen importantes limitaciones:

Los datos están separados y aislados.

Con frecuencia, los datos están duplicados.

Los programas de aplicación dependen de los formatos de los archivos.

Con frecuencia, los archivos son incompatibles entre sí.

Es difícil representar los datos en el modo en que los usuarios los ven.

Veamos cada uno de estas limitaciones por separado.

Datos separados y aislados

El usuario de la Figura 1.2 necesita relacionar a los empleados con cada uno de los

sueldos que les corresponde para poder así imprimir el cheque de su pago adecuadamente.

En este caso los datos necesitan extraerse de algún modo de los archivos de empleados y de

historia de sueldos y combinarse en un archivo sencillo donde estarán los datos deseados

que serán impresos. Con el procesamiento de archivos, tal cuestión es difícil. Los analistas

de sistemas y los programadores deben determinar cuáles partes de cada archivo son

necesarias; deben también decidir cómo se relacionan los archivos entre sí y deben

coordinar el procesamiento de los archivos de modo tal que se extraigan los datos correctos.

FIGURA 1.3. En un sistema de procesamiento de archivos extraer los datos

suele ser muy complicado.

Coordinar dos archivos es muy difícil, imagínese la tarea de coordinar diez o más de

ellos, simple y sencillamente es una tarea titánica.

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

Necesito esos reportes para hoy a las 4:00 p.m. Gómez.

Sí señor. Pondré todo mi esfuerzo.



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:



FIGURA 1.4. Formato de pantalla deseada por el usuario para una aplicación.

Para mostrar los datos de este modo es necesario extraer, combinar y presentar juntos varios

archivos diferentes. Esta dificultad surge porque con el procesamiento de archivos no se

representan o procesan con sencillez las relaciones entre los registros. Debido a que un

sistema de procesamiento de archivos no puede determinar con rapidez cuáles

EMPLEADOS son los que se desean presentar con su SUELDO actual, es difícil producir

una forma que muestre los datos solicitados.

1.1.2. Sistemas de procesamiento de bases de datos Los problemas de mantener grandes sistemas basados en archivos condujeron a

finales de los sesenta al desarrollo de los sistemas de gestión de base de datos. La idea

detrás de estos sistemas era sencilla: tomar la definición de los contenidos de un archivo y

la estructura de los programas individuales, y almacenarla, junto con los datos, en una base

de datos. Utilizando la información de la base de datos el manejador (llamado DBMS) que

la controla puede tomar un papel mucho más activo en la gestión de los datos y en los

cambios a la estructura de la base de datos.

Empresa X S.I.I.G.Y. DD/MM/AA

Nómina Consultor de Empleados consnom.exe

Sucursal: 12 Renacimiento

Tipo de Empleado: 01 Confianza

Id. Emp. Nombre: Dirección: Sueldo:

600234 Samayoa Dorantes Eva xxxx 5000.00

609314 García Hernández Fidel xxxx 6000.00

601256 Ramos Baños Luis xxxx 7000.00

602567 Viilegas Reyes Josefina xxxx 5000.00

605621 Hernández Bravo Juan Miguel xxxx 8000.00

609152 Olivar Campos Víctor xxxx 8500.00

601045 Cortez Dillanes Marco Antonio xxxx 9000.00



La tecnología de las bases de datos se desarrolló para superar las limitaciones de los

sistemas de procesamiento de archivos. Compare el sistema de procesamiento de archivos

de la Figura 1.2 con el sistema de bases de datos para la misma nómina en la figura

siguiente:

FIGURA 1.5. Aplicación de nómina utilizando un sistema de procesamiento de base de datos.

Los programas de procesamiento de archivos acceden a los archivos de los datos

almacenados. En contraste, los programas de procesamiento de base de datos acuden al

DBMS para acceder a los datos almacenados. Esta diferencia es significativa: hace más

fácil la tarea de programar la aplicación. Los programadores no deben preocuparse por las

formas en que los datos se almacenan. Más bien quedan libres para concentrarse en

cuestiones importantes para el usuario, y no con aspectos del sistema de computación.

1.1.2.1 Conceptos de bases de datos

Ahora bien, el término base de datos permite distintas interpretaciones. Ha sido usado

para referirse tanto a un conjunto de tarjetas índice como a los millones y millones de datos

que un gobierno recopila acerca de sus ciudadanos. Usaremos el término con un significado

específico: una base de datos es un conjunto autodescriptivo de registros integrados

controlados por un DBMS. Es importante comprender cada parte de tal descripción.

Aplicación(es) de base de datos

DBMS

Base de datos

Usuario del sistema de nómina.



Sistema manejador de bases de datos (DBMS)

Un sistema manejador de bases de datos (Database Management System, DBMS),

consiste en un conjunto de datos relacionados entre sí y un grupo de programas que les den

acceso. El conjunto de datos se conoce comúnmente como base de datos. Las bases de datos

generalmente contienen información acerca de una empresa determinada.

El objetivo primordial de un DBMS es crear un ambiente en el que sea posible

guardar y recuperar información de la base de datos en forma eficiente; es decir, permitir a

los usuarios trabajen o traten con los datos en forma simple, sin necesidad de atender la

forma en que la computadora los almacena.

En este sentido, el DBMS actúa como intérprete de un lenguaje de alto nivel. Los

sistemas de bases de datos se diseñan para manejar grandes volúmenes de información a

sabiendas que la cantidad de usuarios que la utilicen será considerable, tal como se puede

esquematizar en la Figura 1.6.

El manejo de los datos incluye tanto la definición de las estructuras como los

mecanismos para el acceso de la información. Además, el sistema de bases de datos cuida la

seguridad de la información almacenada en la base de datos, tanto contra las caídas del

sistema, como contra los intentos de acceso no autorizado. Si los datos ven a compartirse

para varios usuarios, el sistema debe proteger que al efectuar modificaciones no se

encuentren resultados que presenten inconsistencias.

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

DBMS

Base de Datos



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.



Num_Pedido Fecha DescConcepto

23455 13/01/92 Computadoras ATT

24879 17/01/92 Drives de 5 ¼ “

34488 20/01/92 Monitores de color


34488 20/01/92 Monitores de color


a) Archivo de pedidos

Clave_Concepto DescConcepto

23455 Computadoras ATT

24879 Drives de 5 ¼ “

34488 Monitores de color

b) Archivo de conceptos

FIGURA 1.7. Redundancia de información en los archivos.

El problema se amplía si se piensa en que existiesen otros archivos como facturas,

notas de crédito, recibidos, pólizas, etc., que tuviesen relación con el archivo de conceptos y

estuvieran representados de la misma forma.

Con el procesamiento de base de datos, es mínima la duplicación o redundancia de

datos. En una base de datos bien definida como la de la Figura 1.5, el problema de los

archivos anteriormente descritos simplemente no existiría, pues el campo DescConcepto se

almacenaría solo una vez, es decir, en un solo archivo. Siempre que el DBMS necesite estos

datos puede traerlos y solo es necesaria una operación para modificarlos. Debido a que

estos datos se almacenan en un sólo lugar, resultan menos comunes los problemas de

integridad de datos; hay menor oportunidad de discrepancias entre las múltiples copias de

los mismos elementos de datos.

Independencia programas/datos

El procesamiento de base de datos hace que los programas dependan menos de los

formatos de los archivos. Los formatos de registro se almacenan en la misma base de datos

(junto con los datos) y son accedidos por el DBMS, no por los programas de aplicación.

A diferencia de los programas de procesamiento de archivos, los programas de

aplicación de base de datos no necesitan incluir el formato de los registros y los archivos

que procesan.



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.



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.

Archivos Bits

Bytes

o

Caracteres Campos Registros

a)

Bits

Bytes

o

Caracteres Campos Registros

b)

Archivos

+

Metadatos

+

Índices

+

Metadatos

de

aplicación

.

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



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.



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.



Usuarios

En un sistema de bases de datos existe una gran diversidad de usuarios, cada uno,

tiene necesidades específicas y visualiza el sistema de manera distinta. Enseguida se da un

perfil de cada uno de ellos.

Usuarios de programas de aplicación

El primer tipo de usuario de un sistema es el que utiliza los servicios para los que fue

realizado, es decir, un sistema resuelve problemas concretos a través de la ejecución de

programas.

FIGURA 1.9. Los usuarios de aplicaciones de bases de datos no necesitan saber

datos técnicos acerca de esta y tampoco que manejen algún lenguaje de programación.

Estos usuarios no están obligados más que a tener conocimiento sobre la forma de uso

del programa y los resultados que éste genera, también tienen acceso limitado a la

información de la base de datos y están sujetos sólo a lo que la aplicación les proporcione.

Voy a accesar al sistema de contabilidad...



Programadores de aplicación

Estos usuarios construyen los programas de aplicación, que están compuestos de las

instrucciones necesarias para poder acceder a la base de datos. Estos programas en

conjunto, realizan una función específica del sistema de computación de la organización en

donde se ubican y están escritos en lenguajes de alto nivel, los cuales pueden ser de dos

tipos: lenguajes de 3a. generación (3GL) o de 4a generación (4GL) (aunque últimamente se

les está abriendo paso a los de 5ª generación).

Los primeros son lenguajes de propósito general, como C, Pascal, FORTRAN,

COBOL, y otros. Los segundos son lenguajes especializados para la construcción de

interfaces para sistemas de información y manipulación de datos a través de lenguajes de

bases de datos como SQL, QUEL, etc.

FIGURA 1.10. Los programadores de aplicaciones de bases de datos son los que

diseñan las aplicaciones que utilizarán usuarios como el de la Figura 1.9. Es necesario que conozcan datos técnicos acerca de la base de datos y que manejen lenguajes de programación.

Usuarios que utilizan los lenguajes de manipulación de información

En diversos sistemas, existen usuarios que no pueden esperar a que los programadores

de aplicación construyan los programas que producirán la información que necesitan; estos

usuarios son inquietos y por lo regular tienen gran iniciativa, por ello, no les importa

aprender los lenguajes de manipulación para poder acceder directamente a la base de datos

y ala información que necesitan.

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



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.



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



Usuarios de las aplicaciones

Programadores de las aplicaciones

Usuarios Casuales

Administrador de la base de datos

Precompilador de lenguaje de manejo de datos

Procesador de consultas

Precompilador de lenguaje de

definición de datos

Manejador de base de datos

Manejador de archivos

Consulta

Código objeto de los programas de aplicación

Archivos de datos

Almacenamiento en disco

DBMS

La Figura 1.12 muestra los componentes de un sistema de base de datos y las

conexiones entre ellos.

FIGURA 1.12. Estructura del sistema de base de datos

Código fuente de los programas de

aplicación

Programas de aplicación

Esquema de la base de datos

Diccionario de datos



1.2 Tipos de bases de datos Los tipos de bases de datos más comúnmente utilizados son bases de datos

fundamentadas en la distribución de sus datos a través de registros (similar a los registros

de archivos).

Base de datos tipo relacional

Base de datos tipo red

Base de datos tipo jerárquico

Enseguida se bosquejan cada uno de ellos.

Base de datos tipo relacional Los datos y las relaciones entre ellos se representan por medio de tablas, cada una de

las cuales tienen varias columnas con nombres únicos. Este será uno de los temas

fundamentales de este curso debido a que alrededor de este modelo están basados la

mayoría de los DBMS.

Base de datos tipo red Los datos en este modelo se representan por medio de registro (en el sentido que la

palabra tiene en Pascal o PL/1) y las relaciones entre los datos se establecen por medio de

ligas, que pueden considerarse como apuntadores.

Los registros de la base de datos se organizan en forma de conjuntos de gráficas

arbitrarias. La Figura 1.13 muestra un ejemplo de este modelo, estableciendo la relación

entre alumnos y grupos en un sistema de control escolar.

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

81315 José Luís Martínez

83534 Alberto López

85555 Beatriz Álvarez

87221 Mario Martínez

CA-10 Matutino

CB-09 Matutino

CF-07 Vespertino



Base de datos tipo jerárquico El modelo jerárquico es similar al de red en cuanto a que los datos y las asociaciones

se representan por medio de registros, y ligas, respectivamente.

Sin embargo, el modelo jerárquico difiere del de red en que los registros están

organizados como árboles y no como gráficas arbitrarias. En la Figura 1.14 se muestra un

ejemplo de este modelo.

FIGURA 1.14. Ejemplo de una base de datos jerárquica.

Las bases de datos en red y jerárquicas son bastante eficientes al momento de extraer

de ellas la información, más, sin embargo, también tiene sus desventajas. La estructura de

estas resulta ser muy rígida. Las relaciones de conjunto y la estructura de los registros tiene

que ser especificadas de antemano. El modificar la estructura de la base de datos requiere

típicamente la reconstrucción de la base de datos completa.

Estas bases de datos son herramientas específicas para programadores, pues es muy

difícil que un usuario común extraiga información de ellas por la estructura compleja que

estas guardan. Aun así un programador experto muchas veces tiene que escribir un

programa que recorra el camino complicado hacia los datos solicitados a través de estas

bases de datos. La anotación de las peticiones para informes a medida dura con frecuencia

semanas o meses, y para el momento en que el programa está escrito la información con

frecuencia ya no merece la pena. Estos dos tipos de bases de datos son muy poco utilizados

hoy en día, pues han sido suplantadas exitosamente por las bases de datos relacionales.





CA-10 Matutino

CB-09 Matutino

CF-07 Vespertino

Alumnos

CA-10 Matutino

CB-09 Matutino



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.

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

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

página 30

2.1. Diseño de bases de datos relacionales Las desventajas de los modelos jerárquicos y en red condujeron a un intenso interés

en el nuevo modelo2 de datos relacional cuando fue escrito por primera vez por el Dr. Codd

en 1970. El modelo de datos relacional simplifica la estructura de la base de datos. Elimina

las estructuras explícitas padre/hijo que contienen las bases de datos jerárquicas y en red, y

en su lugar representa todos los datos en la base de datos como sencillas tablas fila/columna

de valores de datos. La Figura 2.1 muestra una versión relacional de la base de datos en red

y jerárquica de las Figuras 1.13 y 1.14.

FIGURA 2.1. Ejemplo de una base de datos relacional.

El Dr. Codd escribió un artículo en 1985 estableciendo doce reglas a seguir por cualquier

base de datos que se llamara “verdaderamente relacional”. Las doce reglas de Codd han

sido aceptadas desde entonces como la definición de un DBMS verdaderamente relacional.

Sin embargo, es más fácil comenzar con una definición más informal.

Una base de datos relacional es una base de datos en donde todos los datos visibles al usuario están

organizados estrictamente como tablas de valores, y en donde todas las operaciones de la base de datos operan

sobre esas tablas.

Tal vez en este momento parezca un poco complejo la manera en que los datos han

sido distribuidos en la base de datos relacional de la Figura 2.1, porque realmente esta base

de datos no está debidamente diseñada, sin embargo, esta confusión quedará disuelta al

introducirnos en el tema Diagramas de Entidades y Asociaciones que es propio de las bases

de datos relacionales.

2 A los tipos de bases de datos también se les conoce como modelos de datos.

Tabla ALUMNOS

CONTROL NOMBRE





Tabla GRUPOS

GRUPO TURNO

CA-10 Matutino

CB-09 Matutino

CF-07 Vespertino



página 31

2.1.1. Diagrama de Entidades y Asociaciones (DEA) Son la herramienta más conveniente para el diseño de la base de datos relacional.

Originalmente presentan conjuntos de entidades, relaciones y atributos, pero después se le

agregan otros elementos.

Enfoque de Entidad-Asociación

El modelo de entidad-asociación (E-A) se basa en una percepción de un mundo real,

que consiste en un conjunto de objetos básicos llamados entidades y de las asociaciones

entre esos objetos. Este modelo se desarrolló para facilitar el diseño de bases de datos

permitiendo especificar el esquema de cualquier sistema de información.

Componentes de un DEA

Una entidad es un objeto que existe y puede distinguirse de otros. La distinción se

logra asociando a cada entidad un conjunto de atributos que describen al objeto. Por

ejemplo, los atributos número y saldo describen una entidad Cuenta en un banco.

La asociación es el vínculo que existe entre varias entidades. Por ejemplo una

asociación Cliente-Cuenta relaciona una entidad Cliente con cada una de las Cuentas que

tiene. El conjunto de todas las entidades y asociaciones del mismo tipo se denomina

conjunto de entidades y conjunto de asociaciones, respectivamente.

Además, este modelo permite establecer los requisitos que debe cumplir una base de

datos. Uno de estos requisitos importantes es la funcionalidad, que expresa el número de

entidades con las que puede asociarse otra entidad por medio de un conjunto de

asociaciones.

Un diagrama de entidad-asociación queda constituido por entidades, atributos que las

distinguen y asociaciones que las relacionan. Enseguida se describen cada uno de ellos.

Entidades

Una entidad es un objeto que existe y es distinguible; por ejemplo, una silla, un

auto, un alumno, una cuenta, etc. Un grupo de entidades similares compone un

conjunto de entidades. El conjunto de todas las personas que tienen una cuenta en

el banco, por ejemplo, puede definirse como el conjunto de entidades

CuentaHabientes. En forma similar el conjunto de todos los libros de una biblioteca

puede definirse como el conjunto de entidades Libros.

Atributos

Como las entidades tienen propiedades, éstas se incluyen en el modelo entidad-

asociación y se les llaman atributos. Por ejemplo, los posibles atributos del conjunto



página 32

de entidades Libros son número_adquisición, título, autor, colocación, tema,

editorial, páginas, país. Para cada atributo existe un conjunto de valores permitidos,

llamado dominio. Así, el dominio del atributo título podría ser el conjunto de todas

las cadenas de caracteres de cierta longitud. Por lo que se dice que una ocurrencia de

un conjunto de entidades es una instancia específica de una entidad. Usualmente los

dominios son enteros, reales, cadenas de caracteres, etc. Para definir el concepto de

atributo, veamos un ejemplo de préstamo de libros, definiendo dos entidades

participantes que son libros y usuarios, como se muestra en la Figura 2.2.

Libros

Número_Adquisición Título Autor Colocación Tema Editorial Páginas País

12765 Física

General

Ullman F277-739-1.1 Física Mc. Graw

Hill

289 México

12766 Física General

Van Der Merwe

F277-739-1.1 Física Mc. Graw Hill

273 México

. . . . . . . .

. . . . . . . .

. . . . . . . .

Usuarios

Matrícula Nombre Dirección Colonia Ciudad

78344 Jeanette Ríos Bernal Díaz del Castillo No. 235 Progreso Acapulco, Gro.

78345 Alberto Delgadillo Rio Balsas No. 125 Vista Alegre Acapulco, Gro.

. . . .

. . . .

. . . .

FIGURA 2.2. Ejemplo de conjuntos de entidades para el préstamo de libros en una biblioteca

Asociaciones

Una asociación es una relación entre varias entidades. Por ejemplo, se puede

definir una asociación que relacione al usuario “Janette Ríos” con el libro que tenga

número de adquisición “12765”. Un conjunto de asociaciones es un grupo de

relaciones del mismo tipo. Para el ejemplo del préstamo de libros en una biblioteca

se puede enunciar la asociación de la siguiente manera:

Libro Prestado a Usuario

Nótese que la asociación se lee en cierta dirección, pero también puede leerse

en las direcciones que uno quiere que se exploren, es decir, al diseñar una asociación

se hace con el fin de que por medio del modelo se puedan contestar preguntas y

sobre la base de ellas deben plantearse los sentidos en que se deben leer las

asociaciones.

Las asociaciones en este modelo no tienen que ser binarias por fuerza y se

admite también que un atributo no pertenezca a ninguna de las entidades ligadas por

una asociación, sino a la asociación misma.

En resumen, una asociación llega a convertirse en una especie de entidad

formada con atributos de las entidades asociadas y propios.



página 33

Llaves

Una tarea muy importante dentro del modelaje de bases de datos consiste en

especificar cómo se van a distinguir las entidades y las asociaciones.

Conceptualmente, las entidades individuales y las asociaciones son distintas entre sí,

pero desde el punto de vista de una base de datos la diferencia entre ellas debe

expresarse en términos de sus atributos. Para hacer estas distinciones, se asigna una

llave a cada conjunto de entidades.

La llave es un conjunto de uno o más atributos, que juntos, permiten identificar

en forma única una entidad dentro de un conjunto de entidades. Por ejemplo, el

atributo número_adquisición del conjunto de entidades Libros es suficiente para

distinguir a una entidad de otra dentro del mismo conjunto, porque los números de

adquisición de libros no se repiten, es decir, que nunca habrá números de

adquisición iguales. Por tanto, número_adquisición es una llave para el conjunto de

entidades Libros. De manera similar, la combinación de número_adquisición y

título es una llave para el conjunto de entidades Libros; pero el atributo título no es

en sí una llave ya que es posible que varios libros tengan el mismo título.

El concepto de llave no es suficiente para el modelaje de la base de datos, pues

una llave puede incluir atributos ajenos. Generalmente lo que se busca es la llave

más pequeña posible. Estas llaves mínimas se denominan llaves candidato.

Es posible que existan varios conjuntos de atributos distintos que pudieran

servir como llaves candidato. Por ejemplo, una combinación de título y autor podrá

ser suficiente para distinguir una entidad del conjunto de entidades Libros. De esta

manera, tanto {número_adquisición} como {título, autor} son llaves candidatos.

Aunque los atributos número_adquisición y título juntos pueden servir para

identificar unívocamente una entidad, su combinación no es una llave candidato,

puesto que número_adquisición es por sí sola una llave candidato, dado que es la

más pequeña.

Llave Primaria

Se utiliza el término llave primaria para referirse a la llave candidato que elija

el diseñador de la base de datos como la forma de identificar a las entidades dentro

de un conjunto de éstas.

Es posible que un conjunto de entidades no tenga suficientes atributos para

formar una llave primaria. Por ejemplo, en un sistema bancario, el conjunto de

entidades Transacciones, puede tener como atributos número_transacción, fecha e

importe. Ninguno de estos atributos sirve para identificar en forma única una

entidad, ya que dos transacciones realizadas en diferentes cuentas pueden tener el

mismo número de transacción. Por lo que este conjunto de entidades no tiene llave

primaria. Una entidad de un conjunto de este tipo se denomina entidad débil. Una

entidad que cuenta con una llave primaria se le conoce como entidad fuerte.

Aunque un conjunto de entidades débiles no cuentan con una llave primaria, es

necesario tener una forma de distinguir entre todas esas entidades aquellas que



página 34

Llave primaria

Transacciones

Número_Cuenta Número_Transacción Fecha Importe

1526568 1 05/08/97 12300.00

1526569 1 17/09/97 6000.00

. . .

. . .

. . .

a)- Entidad Débil

dependen de una entidad fuerte determinada. El discriminador de un conjunto de

entidades débiles es un conjunto de atributos que permite hacer esta distinción. Por

ejemplo, el discriminador del conjunto de entidades débiles Transacciones es el

atributo número_transacción, ya que para cada cuenta estos números de transacción

identifican en forma única cada una de las transacciones.

FIGURA 2.3. La entidad fuerte contra la entidad débil.

La llave primaria de un conjunto de entidades débiles está formada por la llave

primaria de la entidad fuerte de la que dependen y de su discriminador. En el caso

del conjunto de entidades Transacción, su llave primaria es (número_cuenta,

número_transacción).

FIGURA 2.4. La llave primaria de una entidad débil.

Los conjuntos de asociaciones también tienen llaves primarias. Sus llaves

primarias se forman tomando todos los atributos que constituyen las llaves primarias

de los conjuntos de asociaciones que definen al conjunto de asociaciones. Por

ejemplo matrícula es la llave primaria del conjunto de entidades Usuarios y

número_adquisición es la llave primaria del conjunto de entidades Libros. Por tanto,

la llave primaria del conjunto de asociaciones Préstamos es (matrícula,

número_adquisición).

En el aspecto físico de la Base de Datos, las entidades y las asociaciones se

convierten en tablas, los atributos de las entidades son las columnas de estas tablas y

las llaves seleccionadas como tales dan como resultados tablas índice.

Discriminador

Transacciones

Número_Transacción Fecha Importe

1 05/08/97 12300.00

1 17/09/97 6000.00

. .

. .

. .

a)- Entidad Débil

CuentaHabientes

Número_Cuenta CuentaHabiente

1526568 Domingo Abarca Ramírez

1526569 Iraís Díaz Galeana

. .

. .

. .

a)- Entidad Fuerte

CuentaHabientes

Número_Cuenta CuentaHabiente

1526568 Domingo Abarca Ramírez

1526569 Iraís Díaz Galeana

. .

. .

. .

a)- Entidad Fuerte

?



página 35

Componentes gráficos de un Diagrama de entidad-asociación

Ya que la descripción de cualquier cosa en un lenguaje natural puede acarrear

confusiones, para evitarlas es necesario emplear cierta notación.

Para expresar con claridad las ideas y la estructura lógica general de una base de datos

en forma gráfica, se utiliza un diagrama de entidad-asociación (llamado clásico) que se

integra con los siguientes componentes:

Rectángulos

Representa conjuntos de entidades.

Elipses

Representan atributos.

Líneas uniendo entidades

Representan asociaciones entre conjuntos de entidades.

Líneas uniendo atributos y entidades o asociaciones

Conectan los atributos a los conjuntos de entidades y los conjuntos de entidades a las

asociaciones. Sobre esas mismas líneas se puede indicar el grado de la relación.

Cada componente se etiqueta con un nombre específico. Así podemos definir nuestros

conjuntos de entidades, las asociaciones existentes entre ellas y los atributos que se asignan

a cada una de esas entidades.

Si se retoma nuevamente al ejemplo del préstamo de libros en una biblioteca, se

puede obtener del sistema tanto consultas, como reportes e información se requieran. En la

Figura 2.2 pueden observarse las entidades Libros y Usuarios así como sus atributos.

En la Figura 2.5 se muestra un ejemplo de un diagrama de entidad-asociación, en el

cual se modela la asociación que existe entre usuarios y libros de una biblioteca, a través del

préstamo del acervo. Se observa que la asociación contiene un atributo propio, que es la

fecha, por medio de la cual se identifica el día del préstamo y se calcula la fecha de

devolución.



página 36

FIGURA 2.5. Ejemplo de un DEA clásico.

Funcionalidad de las asociaciones

Es necesario identificar cómo se asocian las entidades; es decir, identificar el grupo

de ocurrencias de una entidad que se relaciona con el grupo de ocurrencias de la entidad

asociada. A continuación se muestra la simbología utilizada para representar el grado de la

asociación entre dos entidades:

No. Símbolo Se lee:

1

Uno y solo uno

2

Cero o uno

3

Uno o muchos

4 Cero, uno o muchos

5

Más de uno

TABLA 2.1. Simbología utilizada para representar grados de asociaciones entre entidades.

Se puede definir el grado de una relación como el número máximo de ocurrencias de

una entidad E (de un conjunto de entidades), que puede participar en una asociación con

una sola ocurrencia de otra entidad. Así, para un conjunto binario de asociaciones entre los

conjuntos de entidades A y B, la funcionalidad consiste en las ocurrencias de asociación

entre A y B, el cual debe estar entre alguna de las siguientes.



página 37

Una a una (1:1)

Una entidad en A está asociada sólo con una entidad en B, y una entidad en B está asociada

sólo con una entidad en A. Se pueden utilizar los símbolos 1 ó 2 en el extremo izquierdo y

también los símbolos 1 ó 2 en el extremo derecho.

Una a muchas (1:n)

Una entidad en A está asociada con cualquier número de entidades de B, pero una entidad

de B puede relacionarse sólo con una entidad en A. Se pueden utilizar los símbolos 1 ó 2 en

el extremo izquierdo y los símbolos 3, 4 ó 5 en el extremo derecho.

Muchas a una (n:1)

Una entidad de A está asociada con una entidad en B, pero una entidad de B está vinculada

con cualquier número de entidades de A. Se pueden utilizar los símbolos 3, 4, ó 5 en el

extremo izquierdo y los símbolos 1 ó 2 en el extremo derecho.

Muchas a muchas (n:n)

Una entidad de A está relacionada con cualquier número de entidades en B y una entidad de

B está asociada con cualquier número de entidades de A. Se pueden utilizar los símbolos 3,

4, ó 5 en el extremo izquierdo e igualmente los símbolos 3, 4, ó 5 en el extremo derecho.

Por ejemplo si se piensa en forma restringida, una cuenta sólo puede pertenecer a un

cuentahabiente y un cuentahabiente puede tener más de una cuenta. Se identifican las

entidades Cuenta y CuentaHabiente, en el que las relaciones de sus ocurrencias son:

Una cuenta a un cuentahabiente.

Un cuentahabiente a una o más cuentas.

Esto significa que tiene relación de una a muchas.

Piénsese también, en el ejemplo del sistema bibliotecario que se mostró en la Figura

2.5. Se observa que la asociación entre usuarios y libros es de uno a muchos, ya que un

usuario puede tener cero o varios, libros, pero un ejemplar de un libro sólo lo puede tener

un usuario como máximo y cero como mínimo. En la figura se denota la asociación de

grado n por medio de una pata de gallo. El diagrama que se utilizará aquí (y el cual es el

más práctico) difiere del diagrama clásico de la Figura 2.5. En este diagrama la entidad

tiene una representación diferente a la “caja” simple, dado que aquí es representada en algo

conocido como Diagrama de Estructura de Datos. La siguiente figura identifica

plenamente a este diagrama de estructura:



página 38

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:

Se refiere al nombre lógico que tendrá la entidad, está deberá coincidir con

el nombre del Almacén del DFD.

atributo1

atributo2

atributo3

.

.

.

atributoN

Se refiere al nombre de cada uno de los atributos (campos de la tabla ya en

la Base de Datos) que componen la entidad, donde los que se encuentran

en la zona “Key Data” son atributos llave.

min. ####

max. ####

Se refiere al mínimo y máximo de registros que guardará la entidad ya

como tabla física.

Nombre_Tabla_Físico Es el nombre físico de la tabla en la Base de Datos

TABLA 2.2. Elementos que componen una Entidad como diagrama de estructura de datos.

Además, estos DEA que se utilizarán son DEA en donde sólo se tienen asociaciones

binarias y son descritas a través de una línea que une a dos conjuntos de entidades

indicando la cardinalidad de la asociación igual que el diagrama clásico, con una notación

de pata de gallo.

Los DEA sólo contendrán asociaciones de 1:N o bien de 1:1, pero nunca de N:N. Los

conjuntos de entidades tendrán un nombre, una descripción un conjunto de atributos que la

compone, indicaciones sobre estos atributos en cuanto a cuales son atributos llave y cual no

lo son, número mínimo promedio y máximo de entidades esperadas, nombre de la tabla del

DBSM a la que corresponderá en la implantación (etapa de diseño y programación).

Además las asociaciones son sustituidas por diagramas de estructuras de datos, es

decir, por entidades nuevas cuyo nombre es el de la propia asociación.



página 39

DEA del Sistema Bibliotecario

PréstamosKey Data

Matrícula [PK1]

Número_Adquisición [PK2]Non-Key Data

FechaVolume

Min. 1

Max. 1000000Tabla Ingres

TaPrestamo

LibrosKey Data

Numero_Adquisición [PK1]Non-Key Data

Título

Autor

Colocación

Tema

Editorial

Páginas

PaísVolume

Min. 1


TaLibro

UsuariosKey Data

Matrícula [PK1]Non-Key Data

Nombre

Dirección

Colonia

CiudadVolume

Min. 1


TaUsuario

Debe existir enPuede tener

Para ejemplificar, se diseña en la figura de abajo el mismo DEA de la Figura 2.5 pero

ahora utilizando el estilo de la Figura 1.3.6, sustituyendo las cajas y óvalos por los

diagramas de estructura de datos:

FIGURA 2.7. DEA del Sistema bibliotecario.

Como se observa en la Figura 2.7, la asociación Préstamos de la figura 2.5 es

sustituida por una entidad del mismo nombre cuyos atributos son los atributos llave de las

entidades relacionadas (Matrícula y Número_Adquisición) y el atributo fecha que es propio

de la asociación.

Las asociaciones sólo tendrán un nombre y reglas de integridad. Los atributos se

documentarán con un identificador, el cual está compuesto por un prefijo que indicará la

naturaleza del atributo y un sufijo que indicará la entidad con la cual se le relaciona. A

continuación se dan algunos ejemplos en las dos tablas siguientes:

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

Prefijo Significado

Id Identificador numérico que no lleva una secuencia

Num Identificador numérico que lleva una secuencia

Ce Clave identificador alfanumérico

Do Saldo

SdoIni Saldo inicial

Nom Nombre

Desc Descripción

Stat Estado lógico

Sufijo Significado

Pol Póliza

Emp Empleado

Oper Operación

Fact Factura



página 40

Se hace notar que de aquí en adelante todos los DEA creados usarán esta nueva forma

de nombrar a sus atributos, así como sus respectivas tablas físicas.

Ahora bien, para comprender mejor al DEA anterior, habría que entender primero a

las propias entidades, por lo que analizaremos a la entidad Usuarios:

Está compuesta por cinco atributos de los cuales Matrícula (número de control

del usuario o alumno)es atributo llave, es decir, habrá exactamente un usuario por

tupla o registro, y por su parte Nombre, Dirección, Colonia y Ciudad solamente son

atributos descriptivos del usuario. Nos habla de que tendrá un mínimo de 1 usuario y

un máximo de 10000 y que el nombre físico de la tabla en la Base de Datos será

TaUsuario.

Dada la explicación anterior, entonces la interpretación o lectura del DEA da la figura 2.7

es de la siguiente manera:

1. Los usuarios de la biblioteca, identificados por su número de control (Matrícula), se

verifican en la entidad Préstamos para saber si tiene o no libros en calidad de préstamo,

es decir, uno y solo un usuario de la biblioteca puede tener uno o más libros prestados.

2. Estos préstamos registran el número del libro (Número_Adquisición) prestado el cual

debe existir en la entidad Libros por una sola vez, es decir, el libro prestado está

registrado una y solo una vez en el catálogo de libros.

3. En caso de que existan préstamos estos están registrados en determinada Fecha.

2.2. Resistencia al Modelo Relacional El modelo relacional encontró mucha resistencia. Los sistemas de bases de datos

relacionales requieren más recursos computacionales y, por lo tanto, al principio eran

mucho más lentos que los sistemas basados en modelos anteriores de bases de datos.

Aunque eran fáciles de usar, la respuesta era lenta y con frecuencia inaceptable. A tal grado

que los productos DBMS relacionales resultaron imprácticos hasta los 80, cuando se

desarrolló un hardware más rápido para computadoras y la relación precio-desempeño cayó

de un modo dramático.

El modelo relacional también le parecía extraño a varios programadores. Estaban

acostumbrados a escribir programas en los cuales procesaban los datos de un registro a la

vez. Pero los productos DBMS relacionales procesan datos con mayor naturalidad; una

tabla a la vez. De acuerdo con ello, los programadores debían aprender un nuevo modo de

pensar acerca del procesamiento de datos.

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.


página 42

3.1. Reglas de Integridad de la Base de Datos Las tablas se encuentran asociadas a otras tablas por medio de sus llaves primarias.

Dichas asociaciones normalmente son de 1 a N, es decir a un elemento de una tabla padre le

corresponden varios elementos de la tabla hijo. Aunque puede darse el caso de que a un

elemento de una tabla se le asocie tan solo un elemento de otra, y aun más, puede darse el

caso de que al elemento de una tabla padre no le corresponda ningún hijo. El caso que

jamás debe darse es que un hijo no tenga padre. Y el evitar este último ejemplo es

precisamente parte de lo que se le conoce como Integridad de la base de datos.

Es por esto, que cuando se efectúa una transacción que involucra operaciones de

actualización y eliminación sobre una tabla, es necesario reflejar esos cambios en todas las

tablas asociadas.

Por ejemplo, si se elimina un registro de la tabla Clientes (Entiéndase un base d datos

de CXC), es necesario eliminar todos los registros de las tablas Facturas, Notas de Crédito,

Pedidos, Saldos, etc., en los que aparezca el cliente eliminado. De no hacerlo, la base de

datos presentará datos incongruentes y quedará en un estado que se le llama Inconsistencia.

Cualquiera que sean los casos de asociaciones que se presenten en la base de datos,

estos deben preverse durante la etapa de diseño de la misma. Para vigilar que las relaciones

establecidas entre las tablas se conserven, existe lo que se conoce con el nombre de Reglas

de Integridad.

Las reglas de integridad verifican que las operaciones realizadas sobre las base de

datos (Agregar, Eliminar, Modificar) sean consistentes, y en caso de no ser así, entonces

una regla de integridad se “disparará” para evitar que la base de datos se degrade.

Las reglas de integridad pueden ser de tablas o bien entre tablas. Las de tabla verifican

las operaciones que se realizan sobre la tabla, y las otras la repercusión que tienen las

operaciones realizadas en una tabla sobre otras que son normalmente las asociadas a esta.

Para los dos casos se han diseñado estándares con respecto a la forma en que las

reglas de integridad deben ser adecuadamente documentadas.

Reglas de Integridad de Tablas Las reglas de integridad en tablas sirven para estipular el cómo deben hacerse las

diferentes operaciones de SQL en los registros y en las columnas de la tabla, delimitando

claramente el alcance de la operación con respecto a los propios registros y columnas de la

tabla e inclusive a otras tablas asociadas.

Así por ejemplo, en una operación de inserción de registros debe dejarse bien claro

que reglas debe de cumplir esta operación para poder efectuarse correctamente, reglas que

bien pueden ser simples incrementos de algún atributo llave, verificación de no-existencia ,

o algunas operaciones extras como el provocar otras inserciones hacia otras tablas



página 43

asociadas. Es decir, que estas operaciones o limitantes pueden darse tanto antes de la propia

operación de inserción o posterior a ella.

Las únicas operaciones que deben cumplir con reglas de integridad son aquellas que

provocan el cambio directo de la información en la base de datos, como son Inserción,

Modificación y Eliminación.

Para dejar más claro esto veamos como ejemplo las reglas de integridad que se

estipularían para la tabla TaLibro (entidad Libros) del DEA del Sistema Bibliotecario de la

Figura 2.7:

Operación Regla de Integridad Inserción El número de adquisición deberá ser dado por el usuario, y se

verificará de forma automática que este no exista ya en la tabla. Todos los demás campos son de edición directa.

Explicación: Se está estipulando para esta operación que el sistema deberá permitir la libre edición al usuario para capturar el campo Número_Adquisición, pero que al mismo tiempo el propio sistema deberá validar este valor capturado contra la misma tabla verificando que no exista, ya que de lo contrario se repetirían, y dado que es un campo llave el permitirlo acarrearía un serio problema de inconsistencia de información en la propia tabla al existir llaves duplicadas. Por otro lado, también se está marcando que los demás campos restantes (Título, Autor, Colocación, etc.) se pueden editar de forma libre ya que estos no provocan propagación de operaciones como el anterior, Número_Adquisición.

Operación Regla de Integridad Modificación La modificación puede hacerse sobre todos los campos a excepción de

Número de Adquisición.

Explicación: Es permitida la modificación en todos los campos a excepción del campo Número_Adquisición que es un campo llave, y este impedimento se debe a que si se permitiera modificarlo entonces se correría el mismo riesgo de duplicidad de llaves por un lado, y por otro al modificar un campo llave entonces esta operación de modificación tendría que propagarse hacia otras tablas asociadas por medio de este atributo a la tabla TaLibro (como es la tabla TaPrestamo), lo cual acarrearía un alto costo de programación extra.



página 44

Operación Regla de Integridad Eliminación No deben existir préstamos asociados al libro.

Explicación: Para poder eliminar un “libro” de la tabla TaLibro deberá comprobarse primero que este no existe como “préstamo” en la tabla TaPrestamo, y esto se logra por medio del atributo común entre los dos que es Número_Adquisición. Si el libro con Número_Adquisición no existe en la tabla TaPrestamo entonces esto indica que el libro no ha sido prestado y por lo tanto puede ser eliminado, de lo contrario la eliminación será negada.

Ahora bien, para registrar fácilmente reglas de integridad en tablas, se propone que estas

deberán hacerse en el siguiente formato práctico:

Tabla: <Nombre_Tabla>

Operación Regla de Integridad

Inserción <Texto de regla de Inserción>

Modificación <Texto de regla de Modificación>

Eliminación <Texto de regla de Eliminación>

Tabla 3.1. Formato para registrar las reglas de integridad en tablas.

Donde Nombre_Tabla es el nombre de la tabla para la cual se están estipulando las reglas

de integridad. En la columna Operación se registrarán las tres operaciones permitidas, y en

la columna Regla de Integridad se pondrá el texto de la regla que corresponde a la

operación en turno.

Reglas de Integridad entre Tablas Las reglas de integridad entre tablas indican las restricciones que deben seguirse en

cualquier operación que se realice en alguna tabla de la base de datos. La idea es que dicho

evento no rompa la integridad de las tablas asociadas a la tabla en la que se aplicó tal

operación.

Estas reglas de integridad sólo deben aplicarse cuando las reglas de integridad de la

propia tabla permitan que se efectúe la operación, en caso contrario no aplica la integridad

entre tablas.



página 45

En otras palabras, las reglas de integridad entre tablas sólo serán activadas cuando la

regla de integridad de la tabla lo decida.

Nuevamente, para aclarar mejor esto, recurrimos al DEA del Sistema Bibliotecario de la

Figura 2.7 y ponemos como ejemplo las reglas de integridad entre tablas que se estipularían

para las tablas TaLibro (entidad Libros), TaPrestamo (entidad Préstamos) y TaUsuario

(entidad Usuarios):

Tabla: TaLibro

Operación Otras tablas relacionadas

Restricciones

- Inserción Ninguna Ninguna

- Modificación No aplica No Mod. De Llaves

- Eliminación TaPrestamo No Existencia

Explicación: En la operación de Inserción se está estipulando que al

realizarse esta, puede hacerse libremente sin realizar verificación alguna en otra tabla, pues el insertar un registro en esta tabla no implica un detalle que deba agregarse en alguna otra tabla hijo. Si se observa el DEA nos daremos cuenta que esta tabla no tiene ninguna asociación de uno a muchos con alguna otra tabla, lo cual nos indica que no tiene descendientes. En la operación de Modificación el establecer “No aplica" está informando que es irrelevante la relación que guarde con otras tablas, porque la operación misma limita esto al establecer como restricción la “No modificación de llaves”, y hay que recordar que las asociaciones entre tablas se dan precisamente a través de las llaves. Con lo que respecta a la operación de Eliminación, se está informando que existe una tabla asociada, la cual es TaPrestamo, y al observar esto en el DEA nos damos cuenta que efectivamente existe la relación y que además es de cero o muchos a uno, lo cual implica que es forzoso que se verifique la “No Existencia” del registro a eliminar en la tabla relacionada, pues el eliminar este registro de la tabla actual teniendo otros registros asociados en la tabla TaPrestamo (que tengan el mismo identificador Número_Adquisición) implicaría el dejar libros prestados sin que estos existan en la biblioteca.



página 46

Tabla: TaPrestamo


Restricciones

- Inserción TaLibro TaUsuario

Existencia. Existencia.

- Modificación

No aplica No Mod. De Llaves

- Eliminación TaLibro TaUsuario

No Existencia. No Existencia.

Explicación: En la operación de Inserción se está informando que para poder realizarse esta, debe verificarse en las tablas asociadas TaLibro y TaUsuario la “Existencia” de registros que contengan los campos que forman la asociación con esta tabla (Matrícula y Número_Adquisición) pues ambos forman la llave del registro a insertar, con lo cual en caso de no existir en las tablas antes dichas y permitir la inserción, entonces se incurriría en una incongruencia o también llamada inconsistencia de la tabla. Con lo que respecta a la operación de Modificación cabe la misma explicación que se dio para esta misma operación en la tabla TaLibro. En la operación de Eliminación, se procede igual que para la eliminación en la tabla TaLibro solo que aquí la verificación de “No existencia” se hace en dos tablas que son TaLibro y TaUsuario, ambas asociadas a la tabla en cuestión.



página 47

Tabla: TaUsuario


Restricciones

- Inserción Ninguna Ninguna

- Modificación

No aplica No Mod. De Llaves

- Eliminación TaPrestamo No Existencia.

Explicación: En las dos primera operaciones cabe la misma explicación que para la tabla TaLibro. Con lo que respecta a la operación de Eliminación, se está informando que existe una asociación con la tabla TaPrestamo, y al observar esto en el DEA nos damos cuenta que la relación es de cero o muchos a uno o cero, lo cual implica que es forzoso que se verifique la “No Existencia” del registro a eliminar en la tabla relacionada, pues el eliminar este registro de la tabla actual teniendo otros registros asociados en la tabla TaPrestamo (que tengan el mismo identificador Matrícula) implicaría el dejar usuarios con préstamos sin que estos existan ya, o dicho en palabras coloquiales “es tanto como el que se fue sin pagar”.

De la misma manera que existe un formato para el registro de reglas de integridad en

tablas, también se sugiere como un estándar que para registrar reglas de integridad entre

tablas estas pueden hacerse en el siguiente formato:

Tabla Operación Tablas Relacionadas Tipo de Restricción

<Nombre_Tabla> Inserción <Nombre_Tabla_Rel.> <Restricción para op.>

Modificación <Restricción para op.>

Eliminación <Restricción para op.>

Tabla 3.2. Formato para registrar las reglas de integridad entre tablas.

donde Nombre_Tabla es el nombre de la tabla para la cual se están estipulando las reglas de

integridad. En la columna Operación se registrarán las tres operaciones permitidas, en la

columna Tablas Relacionadas se escriben los nombres de aquellas tabla que tengan una

relación con la tabla en cuestión y que se vena afectadas en la operación en turno y por



página 48

último la columna Tipo de Restricción estipula las condiciones que deben cumplirse en la

tabla relacionada para poder efectuar la operación.

Los tipos de restricción tienen los siguientes valores:

Ninguna No hay restricción entre tablas para efectuar la operación.

Existencia Es necesario que exista el registro relacionado en la tabla relacionada correspondiente.

No Existencia Es necesario que no existan registros relacionados en la tabla relacionada correspondiente.

No Mod. De Llaves La tabla no permite modificación en sus valores llave, por lo que no aplica ninguna restricción entre tablas.

No Permite Baja La tabla no permite bajas, por lo que no aplica ninguna restricción entre tablas.



página 49

3.2. Propagación de Operaciones Una vez que se permite realizar una operación dadas las reglas de integridad de y

entre tablas, es necesario revisar si la operación se propaga más allá de la tabla. Es decir,

que es probable que la operación aplicada a la tabla provoque una o más operaciones extras

en tablas relacionadas con esta.

Cuando se efectúa una operación de Inserción, Eliminación o Modificación, el efecto

de la misma se puede propagar a los registros asociados a tablas relacionadas a la que se le

aplica la operación. Si esta operación no se lleva a cabo, es posible que la base de datos

pierda integridad.

Esto se debe fundamentalmente a que todas las relaciones entre tablas manejan una

cardinalidad 1:N, donde la tabla ubicada en el extremo del 1 es la tabla padre y la tabla

ubicada en el extremo del N es la tabla hijo y generalmente una opcionalidad de mínimo

uno (mínimo están relacionados con al menos un registro de la tabla relacionada).

Si existiese un registro en cualquiera de los dos lados sin que esté relacionado con su

contraparte, entonces esto indica un posible problema de integridad, sin embargo, aquí

manejaremos la posibilidad de que existan padres sin hijo, pero no hijos sin padre. Lo que

haremos en esta situación es cambiar el status del padre a Inactivo, lo que da origen a una

nueva operación llamada Cancelación. En otras palabras el padre será eliminado solo

lógicamente pero nunca físicamente.

En la Inserción, al agregar un registro en la tabla padre no será necesario agregar

registros vacíos en algunas de sus tablas hijo. En la Eliminación, al eliminar un registro de

una tabla hijo, no es necesario propagar la operación a la tabla padre.

Por su parte, en la Modificación, si se modifican los datos que no pertenecen a llave,

normalmente no hay propagación en la operación, sin embargo, cuando se modifican

valores en los campos llave, será necesario propagar la operación de modificación a todos

los registros hijos. Esta situación es rara, y son pocas las ocasiones que se realiza.



página 50

A continuación se describe la forma en que se propagan las operaciones entre las

distintas tablas relacionadas para una pequeña porción de un DEA de un Sistema de

Cuentas Por Pagar.

Figura 3.1. Porción de un DEA de un sistema de Cuentas Por Pagar.

El formato a utilizar, es semejante al presentado en la sección anterior, excepto que

en la última columna tiene ahora una descripción. Este se muestra en la siguiente página:



página 51

Tabla Operación Tablas Padre o Hijo Descripción de

Propagación

TaCxP Inserción TaPoliza Al insertar una cuenta por pagar se inserta la póliza correspondiente.

Modificación TaPoliza Las modificaciones realizadas sobre la Cuenta Por Pagar afectan la póliza.

Cancelación TaPóliza La cancelación de una Cuenta Por Pagar origina la cancelación de la Póliza también.

TaMovPol La cancelación de la Póliza provoca también la eliminación de los movimientos de la misma.

TaPoliza Inserción TaMovPol No existe

Modificación TaMovPol No existe

Eliminación TaMovPol Al eliminar una póliza también deben ser eliminados sus movimientos.

Tabla 3.3. Formato para registrar la propagación de operaciones.

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


página 53

4.1. ¿Que es SQL? El lenguaje de consulta estructurada: SQL (Structured Query Languaje), es el lenguaje

de manejo de bases de datos relacionales de mayor importancia en uso hoy en día. Ha

recibido la aceptación de ANSI como lenguaje de elección para el manejo de bases de

datos, y es el lenguaje de acceso a los datos que se aplica en muchos productos DBMS

comerciales. Es tal su popularidad, que el SQL se ha convertido en el lenguaje estándar para

el intercambio de información entre computadoras. Ya que existe una versión de SQL que

puede ejecutarse en casi cualquier computadora y sistema operativo, los sistemas de

computación pueden intercambiar datos pasando consultas y respuestas SQL entre sí, lo

cual es una capacidad que cada día aumenta más.

Las construcciones y las expresiones permitidas de una puesta en práctica particular

de SQL (por ejemplo, en INGRES o en ORACLE) pudieran diferir de alguna forma del

estándar ANSI, en parte debido a que múltiples productos DBMS fueron desarrollados

antes de llegar al acuerdo sobre el estándar y también debido a que los fabricantes han

añadido capacidades a sus productos para adquirir ventajas competitivas. Desde una

perspectiva de comercialización, el hecho de cumplir con el estándar ANSI pudiera ser

juzgado como no suficientemente interesante.

Los comandos SQL pueden ser utilizados en forma interactiva, como lenguaje de

consulta, o pueden insertarse en programas de aplicación. En este último caso, son

procesados por un precompilador. Por lo tanto SQL no es un lenguaje de programación;

más bien se trata de un sublenguaje de datos, o de un lenguaje de acceso a datos, insertado

algunas veces en otros lenguajes (conocido como Embeded SQL).

4.2. Las funciones de SQL SQL es mucho más que una herramienta de consulta, aunque ese fue su propósito

original y recuperar datos sigue siendo una de sus principales funciones. SQL se utiliza para

controlar todas las funciones que un DBMS proporciona a sus usuarios, las cuales son:

Definición de datos. SQL permite a un usuario definir la estructura y organización

de los datos almacenados y las relaciones entre ellos.

Recuperación de datos. SQL permite a un usuario o a un programa de aplicación

recuperar los datos almacenados de la base de datos y utilizarlos.

Manipulación de datos. SQL permite a un usuario o a un programa de aplicación

actualizar la base de datos añadiendo nuevos datos, suprimiendo datos antiguos y

modificando datos previamente almacenados.



página 54

Control de acceso. SQL permite ser utilizado para restringir la capacidad de un

usuario para recuperar, añadir y modificar datos, protegiendo así los datos

almacenados frente a accesos no autorizados.

Compartición de datos. SQL se utiliza para coordinar la compartición de datos por

parte de usuarios concurrentes, asegurando que no interfieran unos con otros.

Integridad de datos. SQL define restricciones de integridad en la base de datos,

protegiéndola contra corrupciones debidas a actualizaciones inconsistentes o a fallas

del sistema.

Por lo tanto SQL es un lenguaje completo de control e interactuación con un sistema de

gestión de base de datos.

Finalmente SQL no es un lenguaje particularmente estructurado, especialmente

cuando se compara con lenguajes altamente estructurados como C o Pascal. En vez de ello,

las sentencias SQL se asemejan a frases en inglés, completadas con “palabras de relleno”

que no añaden nada al significado de la frase pero que hace que se lea más naturalmente.

Hay unas cuantas inconsistencias en el lenguaje SQL, y también existen algunas reglas

especiales para impedir la construcción de sentencias SQL que parecen perfectamente

legales, pero que no tienen sentido.



página 55

4.3. Trabajando con SQL Ahora nos introduciremos al mundo del SQL utilizando sus sentencias básicas como

son SELECT, DELETE, UPDATE, INSERT y algunas otras más.

En realidad SQL contiene muy pocas sentencias nativas (30 más o menos), es decir,

con estándar ANSI, pero pueden encontrarse algunas más dependiendo del DBMS que se

esté utilizando.

De cualquier forma usted se dará cuenta de la potencia con la que este lenguaje de

consulta cuenta para hurgar las bases de datos relacionales.

Para realizar los ejercicios utilizaremos una pequeña base de datos llamada NOMINA

previamente creada en su computadora, y cuyo diagrama de entidades y asociaciones es el

siguiente:

La estructura y contenido (datos) de cada una de estas tablas podrá encontrarlas en los

Apéndices A y B que se encuentran al final de estas notas.

Empleado

@IdEmp

IdPlaza

NomEmp RFCEmp DirEmp NumIMSSEmp SdoBaseEmp StatEmp FechStatEmp FechIngEmp

TaEmpleado

Historia Sueldo

@IdEmp @FechIniSdo @FechFinSdo

SdoBaseEmp

TaHistSueldo

Plaza

@IdPlaza

DescPlaza IdPuesto

TaPlaza

Puesto

@IdPuesto

DescPuesto

TaPuesto

Pago

@IdEjer @IdPer @IdEmp @IdConcPag

ImpPag

TaPago

Periodo

@IdEjer @IdPer

FechIniPer FechPagoPer

TaPeriodo

Concepto de Pago

@IdConcPag

DescConcPag OperConcPag

TaConcepto

Realizado en

Compuesto

de

Reciben un Que cubre

Que tiene Ligada a



página 56

Recuperación de datos (Select) La sentencia SELECT es la sentencia básica del SQL, a partir de ella pueden

construirse múltiples transacciones para consultar o incluso, modificar la base de datos. Ya

sea sola o en combinación con otras sentencias.

El objetivo de SELECT (usada sin sentencias adicionales) es la lectura o recuperación

rápida de datos de una o más tablas. Esto puede lograrse con sentencias de consulta

sencillas o bien, tan complejas como se requiera. La sintaxis de la sentencia SELECT es la

siguiente:

SELECT <Atributos> FROM <Tablas> WHERE <Condición>;

Donde Atributos son uno o más atributos de una o más tablas de la base de datos en

cuestión. Tablas son el o los nombres de las tablas que se desean consultar. Y finalmente

Condición es una serie de condiciones que nos sirven para acotar el grupo de registros que

serán leídos, los cuales muchas veces es en cantidad innecesaria.

Para comenzar veamos la siguiente consulta:

SELECT

IdEmp, IdPlaza, NomEmp, RFCEmp, DirEmp, NumIMSSEmp, SdoBaseEmp, StatEmp, FechStatEmp, FechIngEmp

FROM TaEmpleado;

Como se puede observar, en esta consulta nos estamos refiriendo a todos los atributos de la

tabla TaEmpleado. Note también, que no estamos usando la cláusula WHERE, pues en este

caso no es necesario. El resultado de esta consulta debe ser el total de registros de esta tabla.

Ahora observe la siguiente sentencia SELECT:

SELECT IdEmp, NomEmp, SdoBaseEmp FROM TaEmpleado;

Para este caso, le estamos indicando al DBMS que solo queremos leer tres atributos de la

tabla TaEmpleado. Esto no implica que la cantidad de registros leídos deba cambiar, pues

de la cláusula FROM hacia abajo es todo igual a la consulta anterior.



página 57

La Cláusula WHERE

Como se dijo anteriormente, la cláusula WHERE es usada cuando se necesita acotar

el grupo de registros leídos en una consulta. Si recordamos, en las dos consultas anteriores

el grupo de registros leídos es el total que existen en la tabla TaEmpleado, pero no siempre

será así. Veamos ahora como podemos acotar este grupo especificándole a SELECT cual o

cuales son los registros que deseamos. Así por ejemplo, si solo queremos visualizar los

datos del empleado 1590, esto lo podemos lograr usando la cláusula WHERE de la

siguiente forma:

SELECT IdEmp, NomEmp, SdoBaseEmp FROM TaEmpleado WHERE IdEmp = 1590;

Ahora bien, las condiciones de WHERE no están sujetas solo a igualdades y a atributos de

tipo numérico, por el contrario, es permitido utilizar todos los operadores relacionales

existentes (>, <, =, >=, <=, <>) y cualquier clase de atributo sin importar su tipo, aunque se

recomienda siempre usar lo más posible atributos de tipo numérico, pues los de otro tipo

hacen “lenta” la consulta. Desdichadamente no siempre podrá evitarse, como en el siguiente

caso, donde se desea presentar los registros de aquellos empleados que ingresaron en la

segunda quincena de junio de 1998

SELECT IdEmp, NomEmp, SdoBaseEmp FROM TaEmpleado WHERE FechIngEmp = Date('98/06/16');

El uso de funciones de conversión de datos de atributos siempre será bastante variado de un

DBMS a otro, pues ya sea la conversión o extracción de datos no están definidas en el

estándar ANSI del SQL.

En las siguientes dos consultas se desea extraer la información de todos aquellos

empleados que hayan ingresado en el año de 1990 (primera consulta) y de todos los que

hayan ingresado en la segunda quincena de cualquier mes y de cualquier año (segunda

consulta).



página 58

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.



página 59

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:



página 60

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



página 61

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



página 62

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:



página 63

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



página 64

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:



página 65

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;



página 66

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;



página 67

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:



página 68

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.



página 69

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;



página 70

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



página 71

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.



página 72

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;



página 73

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:



página 74

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;



página 75

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.

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


página 77

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

ejemplo NOMINA:

Tabla: TaEmpleado

Atributo Tipo Longitud

IdEmp integer IdPlaza integer NomEmp varchar 40 RFCEmp varchar 15 DirEmp varchar 100 NumIMSSEmp integer SdoBaseEmp float StatEmp integer FechStatEmp date FechIngEmp date

Tabla: TaPlaza


IdPlaza integer DescPlaza varchar 30 IdPuesto integer

Tabla: TaPuesto


IdPuesto integer DescPuesto varchar 30

Tabla: TaPago


IdEjer integer IdPer integer IdEmp integer IdConcPag integer ImpPag float

Tabla: TaHistSueldo


IdEmp integer FechIniSdo date FechFinSdo date SdoBaseEmp float

Tabla: TaConcepto


IdConcPag integer DescConcPag varchar 30 OperConcPag integer

Tabla: TaPeriodo


IdEjer integer IdPer integer FechIniPer integer FechFinPer integer



página 78

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 IdPuesto

100 Auxiliar Ventas 1

101 Ventas 2

102 Auxiliar de contabilidad 3

103 Coordinación de Contabilidad 4

104 Coordinación de Contabilidad 5

105 Auxiliar Auditoría 6

106 Auditoría 7

107 Programador 8

108 Programador 9

109 Analista 10

110 Analista 11

111 Coordinador 12

112 Auxiliar Mecánico 13

113 Mecánico 14

115 Vigilante 15

116 Vigilante 15

117 Programador 8

118 Prgramador 9

119 Coordinador 12

120 Coordinador 16

121 Gerente 17

122 Gerente 19

123 Gerente 20

124 Gerente 21

125 Gerente 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 OperConcPag

1000 Sueldo 1

1001 Tiempo Extra 1

1002 Ayuda de Despensa 1

2001 IMSS -1

2002 INFONAVIT -1

2003 SAR -1



página 79

Tabla: TaPago

IdEjer IdPer IdEmp IdConcPag ImpPag

1999 1 1587 1000 2250.00

1999 1 1587 2001 300.00

1999 1 1587 2002 100.00

1999 1 1587 2003 120.00

1999 2 1587 1000 2250.00

1999 2 1587 1002 1000.00

1999 2 1587 2001 770.00

1999 2 1587 2002 200.00

1999 2 1587 2003 300.00

Tabla: TaHistSueldo

Idemp FechIniSdo FechFinSdo SdoBaseEmp

1587 12/01/96 31/12/97 100

1587 1/01/98 31/12/98 125

1588 1/05/95 31/12/97 75

1588 1/01/98 30/06/99 100

1589 16/01/90 31/12/97 150

1589 1/01/98 31/12/98 175

1590 1/11/91 31/12/98 250

1590 1/01/98 31/12/98 275

1591 16/01/93 31/12/96 250

1591 1/01/97 31/12/98 275

1592 16/12/90 31/12/98 275

1592 1/01/98 15/03/99 300

1593 1/01/88 31/12/97 425

1593 1/01/98 31/12/98 400

1594 16/06/98 31/12/98 275

1595 1/01/85 31/12/97 400

1595 1/01/98 31/12/98 425

2000 1/01/86 31/12/95 675

2000 1/01/96 31/12/98 650

2001 1/02/85 31/12/97 650

2001 1/01/98 31/12/98 675



página 80

Tabla: TaEmpleado

IdEmp IdPlaza NomEmp RFCEmp DirEmp NumIMSSEmp SdoBaseEmp StatEmp FechStatEmp FechIngEmp

1587 101 GONZALO FLORES DAVALOS FODG-670419-E34 ZARAGOZA 100, COL. ZAPATA, ACAPULCO, 1783429082 150.00 1 12/04/96 12/01/96

1588 100 ARTURO SALAS HERNANDEZ SAHA-701123-U34 RIO BRAVO 123, COL. HOGAR MODERNO, A 3456123478 100.00 0 01/07/99 01/10/95

1589 102 CECILIA MOSSO LOMELI MOLC-700212 COSTERA MIGUEL ALEMAN 206, FRACC. MA 3456878909 200.00 1 16/09/90 16/07/90

1590 103 LAURA ALVAREZ JIMENEZ AAJL-690720-O90 AV. FARALLON NO. 148, ACAPULCO, GRO. 1287996578 300.00 1 01/02/92 01/11/91

1591 107 PABLO DIAZ RUIZ DIRP-740523-A23 CALZ. PIE DE LA CUESTA NO. 43-G, ACAPUL 5675687231 300.00 1 16/04/93 16/01/93

1592 109 RAUL NAJERA SUAREZ NASR-720923-K23 BENITO JAUREZ NO. 19 1er. PISO, UNID. HA 1254676790 300.00 0 16/03/99 16/12/90

1593 111 SANDRA PEREA URIOSTEGUI PEUS-701210-D45 AV. EJIDO 81, COL. HOGAR MODERNO, ACA 3254568798 450.00 1 01/04/88 01/01/88

1594 117 HORACIO NORIEGA SALMERON NOSH-750119-I45 CALLE LA LOMA NO. 1, INT. 2, FRACC. CUMB 7898908001 300.00 1 16/09/98 16/06/98

1595 120 LUIS MENDOZA CONTRERAS MECL-660315-T56 GAVIOTAS 25, FRACC. LAS PLAYAS, ACAPU 5677897892 450.00 1 01/05/85 01/02/85

2000 122 SALVADOR BALBUENA RAMIREZ BARS-690113-Y78 FERNADO DE MAGALLANES NO. 4, FRACC. 5667544678 700.00 1 01/01/86 01/01/86

2001 121 FERNANDO ZAPATA BUSTOS ZABF-660124-A90 HERNAN CORTES 28, FRACC. MAGALLANES 4565678891 700.00 1 01/02/85 01/02/85

BASES DE DATOS RELACIONALES Apéndice C


página 81

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

BASES DE DATOS RELACIONALES Apéndice C


página 82

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

Introducción a las bases de datos relacionales

Technology

Transcript of Introducción a las bases de datos relacionales