Introducción A Las Bases de Datos Relacionales

INTRODUCCION A LAS BASES DE DATOS RELACIONALES
Domingo Abarca Ramrez. Diciembre de 1999, Mxico.
Contenido
1-Introduccin a las bases de datos _______________________________ 5
Un comentario acerca de las Bases de Datos ________________________________ 6 1.1. Definicin 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 duplicacin de datos o no-redundancia de informacin ______________ 14 Independencia programas/datos ______________________________________ 15 Fcil representacin 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 definicin de datos (DDL) ________________________________ 19 Lenguaje de manipulacin de datos (DML) _____________________________ 20 Manejador de base de datos (DBMS) __________________________________ 20 Usuarios_________________________________________________________ 21 Usuarios de programas de aplicacin_________________________________ 21 Programadores de aplicacin _______________________________________ 22 Usuarios que utilizan los lenguajes de manipulacin de informacin ________ 22 Administrador de la base de datos (DBA) _____________________________ 23 1.1.2.3. Arquitectura de un sistema de bases de datos _______________________ 24 1.2 Tipos de bases de datos ______________________________________________ Base de datos tipo relacional ____________________________________________ Base de datos tipo red _________________________________________________ Base de datos tipo jerrquico ____________________________________________ 26 26 26 27
1.3 Confusiones acerca de las Bases de Datos _______________________________ 28 Advertencia: las hojas de clculo no son bases de datos _______________________ 28
2-Fundamentos de bases de datos relacionales _____________________ 29

2.1. Diseo de bases de datos relacionales __________________________________ 2.1.1. Diagrama de Entidades y Asociaciones (DEA) _________________________ Enfoque de Entidad-Asociacin ________________________________________ Componentes de un DEA _____________________________________________ Componentes grficos de un Diagrama de entidad-asociacin ________________ 30 31 31 31 35
2.2. Resistencia al Modelo Relacional _____________________________________ 40
3-Reglas de integridad ________________________________________ 41

3.1. Reglas de Integridad de la Base de Datos ______________________________ 42 Reglas de Integridad de Tablas __________________________________________ 42 Reglas de Integridad entre Tablas ________________________________________ 44 3.2. Propagacin de Operaciones ________________________________________ 49
4-Introduccin al SQL bsico __________________________________ 52

4.1. Que es SQL? _____________________________________________________ 53 4.2. Las funciones de SQL ______________________________________________ 53 4.3. Trabajando con SQL _______________________________________________ Recuperacin de datos (Select) __________________________________________ La Clusula WHERE ________________________________________________ El uso de asterisco (*) ________________________________________________ Los operadores lgicos y el Test de rango (BetWeen) _______________________ El Test de pertenencia (IN) ____________________________________________ Test de correspondencia con patrn (LIKE) _______________________________ Filas duplicadas (DISTINCT) __________________________________________ Consultas multitablas (Join) ___________________________________________ Funciones de Agrupacin (Sum, Avg, Count, Max, Min) ______________________ La funcin Suma (Sum) ______________________________________________ La funcin Promedio (Avg) ___________________________________________ La funcin Cuenta (Count) ____________________________________________ La funcin Mximo (Max) ____________________________________________ La funcin Mnimo (Min)_____________________________________________ Adicin de datos (Insert) _______________________________________________ Eliminacin de datos (Delete) ___________________________________________ Actualizacin de datos (Update) _________________________________________ Creacin de tablas (Create)____________________________________________ 55 56 57 58 59 59 60 61 61 63 63 65 66 67 69 70 71 72 73
4.4. Notas finales acerca de SQL _________________________________________ 75
5-Apndices _________________________________________________ 76
Apndice A: Estructura de tablas de la base de datos ejemplo NOMINA: _______ 77 Apndice B: Contenido de tablas de la base de datos ejemplo NOMINA: _______ 78 Apndice C: Script SQL para crear las tablas de la base de datos ejemplo NOMINA: ___________________________________________________________ 81
1-Introduccin 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 informacin por computadora y encontrarse con que no se puede contar con l.
Extrado de la revista BD Computers, artculo publicado en enero de 1992.
BASES DE DATOS RELACIONALES
Introduccin a las bases de datos
Un comentario acerca de las Bases de Datos

A pesar de las mltiples confusiones conceptuales que todava existen acerca de las bases de datos, es imposible negar que su desarrollo y avance tecnolgico es a pasos agigantados, por lo que aquellos profesionales del desarrollo de software que no se actualicen en la materia, simple y sencillamente se quedarn a la zaga o al margen de la creacin y operacin de los nuevos y grandes sistemas de informacin. Hoy en da, y debido a la importancia que tiene la informacin en todas las organizaciones, a las bases de datos se les ha puesto gran atencin y ello ha conducido al desarrollo de conceptos y tcnicas para manejar los datos en forma eficiente. En este curso se estudiarn todos esos conceptos a detalle.
1.1. Definicin 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 estn compuestos por uno o ms campos de datos, siendo los campos de un tipo de dato de un conjunto de varios tipos de datos. Sin embargo, muchas veces la definicin 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 tecnologa de las bases de datos, es decir, los sistemas de procesamiento de archivos, ya que estos sistemas revelan los problemas que ha resuelto la tecnologa de las bases de datos.
1.1.1. Sistemas de procesamiento de archivos

Como se mencion anteriormente un archivo de datos es un cmulo de datos de diferentes tipos organizados en un mismo lugar, que es el propio archivo. Este archivo est identificado con un nombre propio y con este se le hace acceso ya sea para agregar, eliminar, modificar o solamente consultar datos.
Domingo Abarca Ramrez Mtodos e Ingeniera en Sistemas.
pgina 6
El archivo est estructuralmente compuesto por registros, que son bloques contiguos identificados por un nmero llamado nmero de registro, a su vez estos registros estn conformados por divisiones de menor tamao de informacin llamadas campos1, donde estos campos almacenarn cualquier tipo de datos, es decir, que estos pueden ser datos alfanumricos o numricos segn sea la necesidad.
No. de Registro
Campos alfanumricos DirEmp Av. Michoacn 1340, Col. Progreso. Cuauhtmoc 70-B, Col. Centro Gaviotas 45,Fracc. Las Playas, Caleta.
Campos numricos FechNac 750612 680514 740422 IngAnual 50000.00 60000.00 Registros
1 2 3 . . . 99 100
NomEmp Rosalba Arciniega Lpez Domingo Abarca Ramrez Eva Samayoa Dorantes
Alejandro Apac Sandoval Luis Orozco Bedolla
Baja California 99, Col. Progreso. Mina 64, Col. Centro.
690223 660825
200000.00 100000.00
FIGURA 1.1. Forma o estructura de un archivo de datos.
En el pasado los sistemas de procesamiento de archivos eran generalmente proporcionados por el fabricante del computador (tales como la nmina y los registros de contabilidad) como parte del sistema operativo, llevaba la cuenta de los nombres y ubicaciones de los archivos. El sistema de gestin de archivos bsicamente no tena un modelo de datos, es decir, no saba nada acerca de los contenidos internos de los archivos. Para el sistema de gestin de archivos un archivo que contuviera un documento de procesamiento de textos y un archivo que contuviera datos de nminas simplemente no los distinguira. El conocimiento acerca del contenido de un archivo que datos almacena y como estn organizados- estaba incorporado a los programas de aplicacin que utilizaban el archivo.
Los ttulos de los campos no son almacenados en el archivo, es decir, que no forman parte de l, aqu se presentan para una mera explicacin.
pgina 7
As, tal como lo muestra la Figura 1.2. los primeros sistemas de informacin comerciales almacenaban grupos de registros en archivos separados.
Programa de actualizacin de empleados. DA Archivo maestro de empleados
Programa de informe de empleados. Usuario del sistema de nmina. DA
Programa de impresin de cheques. DA DA Archivo de historia de sueldos
FIGURA 1.2. Aplicacin de nmina utilizando un sistema de procesamiento de archivos.
En esta aplicacin de nmina, cada uno de los programas (hechos en COBOL) que procesaban el archivo maestro de empleados contena una descripcin de archivo (DA) que describa la composicin de los datos en el archivo. Si la estructura de los datos cambiaba por ejemplo, si un grupo adicional de datos fuera a ser almacenado por cada empleadotodos los programas que accedan al archivo tenan que ser modificados. Como el nmero de archivos y programas creca con el tiempo, todo el esfuerzo de procesamiento de datos de un departamento de desarrollo se perda en mantener aplicaciones (programas) existentes en lugar de desarrollar otras nuevas.
pgina 8
Aunque los sistemas de procesamiento de archivos representan una significativa mejora sobre los sistemas manuales de registro, estos tienen importantes limitaciones: Los datos estn separados y aislados. Con frecuencia, los datos estn duplicados. Los programas de aplicacin dependen de los formatos de los archivos. Con frecuencia, los archivos son incompatibles entre s. Es difcil 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 algn modo de los archivos de empleados y de historia de sueldos y combinarse en un archivo sencillo donde estarn los datos deseados que sern impresos. Con el procesamiento de archivos, tal cuestin es difcil. Los analistas de sistemas y los programadores deben determinar cules partes de cada archivo son necesarias; deben tambin decidir cmo se relacionan los archivos entre s y deben coordinar el procesamiento de los archivos de modo tal que se extraigan los datos correctos.
S seor. Pondr todo mi esfuerzo. Necesito esos reportes para hoy a las 4:00 p.m. Gmez.
Como si fuera tan sencillo, con este desm... de datos que tiene aqu...
FIGURA 1.3. En un sistema de procesamiento de archivos extraer los datos suele ser muy complicado.
Coordinar dos archivos es muy difcil, imagnese la tarea de coordinar diez o ms de ellos, simple y sencillamente es una tarea titnica.
pgina 9
Duplicacin de los datos En el ejemplo de la nmina 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 ms serio. La dificultad significativa de la duplicacin de los datos tiene que ver con la integridad de la informacin. 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 integracin de los datos. Por ejemplo si un empleado cambia su nmero de identificacin o su direccin, 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 produciran resultados inconsistentes. Si un reporte de una aplicacin es diferente al de otra aplicacin, quin decidira cul es la correcta?. Cuando los resultados son inconsistentes se duda de la credibilidad de los datos almacenados, e incluso de la funcin misma del sistema. Dependencia del programa de aplicacin Con el procesamiento de archivos, los programas de aplicacin dependen de los formatos del archivo. En estos sistemas los formatos fsicos de los archivos y los registros son parte del cdigo de la aplicacin. El problema con esta forma de trabajar es que cuando se hacen cambios en los formatos de los archivos, tambin 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 difcil 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 continuacin:
pgina 10
Empresa X Nmina
S.I.I.G.Y. Consultor de Empleados
DD/MM/AA consnom.exe
Sucursal: 12 Renacimiento Tipo de Empleado: 01 Confianza
Id. Emp. 600234 609314 601256 602567 605621 609152 601045
Nombre: Samayoa Dorantes Eva Garca Hernndez Fidel Ramos Baos Luis Viilegas Reyes Josefina Hernndez Bravo Juan Miguel Olivar Campos Vctor Cortez Dillanes Marco Antonio
Direccin: xxxx xxxx xxxx xxxx xxxx xxxx xxxx
Sueldo: 5000.00 6000.00 7000.00 5000.00 8000.00 8500.00 9000.00
FIGURA 1.4. Formato de pantalla deseada por el usuario para una aplicacin.
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 cules EMPLEADOS son los que se desean presentar con su SUELDO actual, es difcil 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 gestin de base de datos. La idea detrs de estos sistemas era sencilla: tomar la definicin 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 informacin de la base de datos el manejador (llamado DBMS) que la controla puede tomar un papel mucho ms activo en la gestin de los datos y en los cambios a la estructura de la base de datos.
pgina 11
La tecnologa 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 nmina en la figura siguiente:
Aplicacin(es) de base de datos
DBMS
Base de datos
Usuario del sistema de nmina.
FIGURA 1.5. Aplicacin de nmina 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 ms fcil la tarea de programar la aplicacin. Los programadores no deben preocuparse por las formas en que los datos se almacenan. Ms bien quedan libres para concentrarse en cuestiones importantes para el usuario, y no con aspectos del sistema de computacin.
1.1.2.1 Conceptos de bases de datos

Ahora bien, el trmino 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 trmino con un significado especfico: una base de datos es un conjunto autodescriptivo de registros integrados controlados por un DBMS. Es importante comprender cada parte de tal descripcin.
pgina 12
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 comnmente como base de datos. Las bases de datos generalmente contienen informacin acerca de una empresa determinada. El objetivo primordial de un DBMS es crear un ambiente en el que sea posible guardar y recuperar informacin 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 acta como intrprete de un lenguaje de alto nivel. Los sistemas de bases de datos se disean para manejar grandes volmenes de informacin 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 definicin de las estructuras como los mecanismos para el acceso de la informacin. Adems, el sistema de bases de datos cuida la seguridad de la informacin almacenada en la base de datos, tanto contra las cadas del sistema, como contra los intentos de acceso no autorizado. Si los datos ven a compartirse para varios usuarios, el sistema debe proteger que al efectuar modificaciones no se encuentren resultados que presenten inconsistencias.
Base de Datos
DBMS
FIGURA 1.6. Esquematizacin de la labor de un DBMS.
pgina 13
Como se aprecia en la figura anterior, puede haber un gran nmero 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 distribucin de los datos para cada uno de los usuarios sera un verdadero caos. Por ejemplo, si ms de uno tratara de leer la misma informacin al mismo tiempo el resultado de dicha consulta sera desastroso en la confiabilidad de la respuesta y lento en el proceso de la misma. Para evitar esto, cada uno de ellos tendra que programar sus tiempos de consulta de tal forma que no afectasen o chocasen con los dems. Por el contrario, con la existencia del DBMS esto es ms sencillo, pues el se encarga de todos estos aspectos y de muchos otros ms evitando as, la prdida de tiempo e informacin.
Datos Integrados
En un sistema de base de datos todos los datos de la aplicacin se almacenan en un medio sencillo llamado base de datos. Un programa de aplicacin 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 aplicacin solo especifica como debern 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 duplicacin de datos o no-redundancia de informacin

Que es la redundancia de informacin? Supngase 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 relacin entre ambas archivos debera haberse dado a travs de la clave del concepto, que es un campo de menor tamao. 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 habra que hacer la actualizacin en cada uno de ellos.
pgina 14
Num_Pedido 23455 24879 34488 23455 34488 23455
Fecha 13/01/92 17/01/92 20/01/92 13/01/92 20/01/92 13/01/92
DescConcepto Computadoras ATT Drives de 5 Monitores de color Computadoras ATT Monitores de color Computadoras ATT
a) Archivo de pedidos
Clave_Concepto 23455 24879 34488 DescConcepto Computadoras ATT Drives de 5 Monitores de color
b) Archivo de conceptos FIGURA 1.7. Redundancia de informacin en los archivos.
El problema se ampla si se piensa en que existiesen otros archivos como facturas, notas de crdito, recibidos, plizas, etc., que tuviesen relacin con el archivo de conceptos y estuvieran representados de la misma forma. Con el procesamiento de base de datos, es mnima la duplicacin 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 existira, pues el campo DescConcepto se almacenara solo una vez, es decir, en un solo archivo. Siempre que el DBMS necesite estos datos puede traerlos y solo es necesaria una operacin para modificarlos. Debido a que estos datos se almacenan en un slo lugar, resultan menos comunes los problemas de integridad de datos; hay menor oportunidad de discrepancias entre las mltiples 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 aplicacin. A diferencia de los programas de procesamiento de archivos, los programas de aplicacin de base de datos no necesitan incluir el formato de los registros y los archivos que procesan.
pgina 15
Fcil representacin de la vista de datos a los usuarios

La tecnologa 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 estn almacenadas en ella relaciones entre los registros de los datos.
Una base de datos es autodescriptiva

Una base de datos es autodescriptiva: Adems de los datos fuente del usuario contiene tambin una descripcin de su propia estructura. Tal descripcin 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. Adems de libros, la biblioteca contiene un catlogo de tarjetas que los describen. En la misma forma, el diccionario de datos (que es parte de la base de datos, tanto como el catlogo es parte de la biblioteca) describe los datos contenidos en la base de datos. Por qu es importante esta caracterstica de autodescripcin 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 documentacin 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 ms 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 mayora de los casos, solo deben alterarse los programas que procesen los datos modificados.
Una base de datos es un conjunto de registros integrados

La jerarqua 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(vase Figura 1.8(a).). Es tentador seguir la tendencia precedente y decir que los archivos conforman bases de datos. Aunque tal expresin es verdadera no va muy lejos.
pgina 16
Bits
Bytes o Caracteres
Campos
Registros
Archivos
a)
Bits
Bytes o Caracteres
Campos
Registros
b)
Archivos + Metadatos + ndices + Metadatos de aplicacin .
Base de datos
FIGURA 1.8. Jerarqua de los elementos: (a) Jerarqua de datos en el procesamiento de archivos y (b) Jerarqua de elementos de datos en el procesamiento de base de datos.
Una base de datos incluye archivos de datos del usuario y ms. Como se mencion, una base de datos contiene una descripcin 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 desempeo de las aplicaciones de la base de datos. La base de datos contiene a veces informacin 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 categora de datos denominados metadatos de aplicacin. 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 aplicacin.
pgina 17
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 tecnologas, los sistemas de computacin se estn desarrollando cada vez en mayor nmero. As, el hardware necesario para hacer frente a los grandes sistemas de computacin puede constituirse a un precio moderado. El hardware se compone de dispositivos de almacenamiento secundario como discos duros, cintas magnticas, discos pticos etc., donde reside la base de datos fsica, junto con un dispositivo asociados como unidades de control. Por lo que respecta al software, los sistemas de base de datos estn compuestos por un conjunto de programas. En el nivel ms 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 bsicos: 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 generacin y se les conoce como lenguajes anfitriones. Dentro del primer grupo, se encuentran los lenguajes de propsito general; en ellos, la estructura de los programas de aplicacin debe construirse mediante programacin tradicional, es decir, deben crearse funciones para conformar el ambiente sobre el que debe ejecutarse la aplicacin, tales como ventanas, mens 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 programacin de este tipo de sistemas es sumamente flexible, aunque complicada de realizar. Un lenguaje de alto nivel de tercera generacin del tipo de Pascal, C, Modula2, APL, etc., no restringe ningn tipo de proceso y la interfaz puede programarse de acuerdo al gusto ms exigente del usuario.
pgina 18
Los lenguajes de cuarta generacin para construccin de sistemas de informacin que utilizan bases de datos, son de propsitos especfico y contienen las funciones suficientes para generar fcilmente una interfaz y ligar el diseo de pantalla de captura, mens 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 aplicacin presentan, solicitan o reportan la informacin. Los accesos a la base de datos tambin se llevan a cabo a travs del DBMS, cuyas funciones se encuentran inmersa en los programas de aplicacin.
Lenguajes de bases de datos

En el mundo de las bases de datos es normal separar las funciones de computacin en dos partes y dos diferentes lenguajes. Esto es porque en un programa normal, las variables de programa existen slo mientras el programa est ejecutndose; 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 definicin de datos y al de manipulacin de datos.
Lenguaje de definicin 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 definicin de datos (Data Definition Language, DDL). El resultado de la compilacin 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 mtodos 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 definicin de datos. El resultado de la compilacin de estas definiciones es una serie de instrucciones que especifican los detalles de implantacin de los esquemas de bases de datos que normalmente no pueden ver los usuarios.
pgina 19
Lenguaje de manipulacin 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 fsicos a cerca de los datos. La manipulacin que se hace con este lenguaje consiste en lo siguiente: Recuperacin de informacin almacenada en la base de datos. Insercin de informacin nueva en la base de datos. Modificacin y eliminacin de informacin de la base de datos. Lo importante que debe cumplir este lenguaje es la facilidad de uso. El objetivo es lograr una interaccin eficiente entre los usuarios y el sistema. Un lenguaje de manipulacin de datos (Data Manipulation Language, DML) permite a los usuarios manejar o tener acceso a los datos que estn expresados por medio del modelo apropiado. Existen bsicamente dos tipos de DML: Procedimental Necesita que el usuario especifique cules datos quiere y cmo deben obtenerse. No procedimental Requiere que el usuario especifique solamente cules datos quiere. Una consulta es una sentencia que solicita la recuperacin de informacin. 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 mdulo 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: Interaccin con el manejador de archivos. Implantacin de la integridad. Puesta en prctica de la seguridad. Respaldo y recuperacin. Control de concurrencia.
pgina 20
Usuarios
En un sistema de bases de datos existe una gran diversidad de usuarios, cada uno, tiene necesidades especficas y visualiza el sistema de manera distinta. Enseguida se da un perfil de cada uno de ellos. Usuarios de programas de aplicacin 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 travs de la ejecucin de programas.
Voy a accesar al sistema de contabilidad...
FIGURA 1.9. Los usuarios de aplicaciones de bases de datos no necesitan saber datos tcnicos acerca de esta y tampoco que manejen algn lenguaje de programacin.
Estos usuarios no estn obligados ms que a tener conocimiento sobre la forma de uso del programa y los resultados que ste genera, tambin tienen acceso limitado a la informacin de la base de datos y estn sujetos slo a lo que la aplicacin les proporcione.
pgina 21
Programadores de aplicacin Estos usuarios construyen los programas de aplicacin, que estn compuestos de las instrucciones necesarias para poder acceder a la base de datos. Estos programas en conjunto, realizan una funcin especfica del sistema de computacin de la organizacin en donde se ubican y estn escritos en lenguajes de alto nivel, los cuales pueden ser de dos tipos: lenguajes de 3a. generacin (3GL) o de 4a generacin (4GL) (aunque ltimamente se les est abriendo paso a los de 5 generacin). Los primeros son lenguajes de propsito general, como C, Pascal, FORTRAN, COBOL, y otros. Los segundos son lenguajes especializados para la construccin de interfaces para sistemas de informacin y manipulacin de datos a travs de lenguajes de bases de datos como SQL, QUEL, etc.
SELECT a.nomcia, a.rfccia FROM tacias a WHERE a.idcia = :fidcia; COMMIT;
FIGURA 1.10. Los programadores de aplicaciones de bases de datos son los que disean las aplicaciones que utilizarn usuarios como el de la Figura 1.9. Es necesario que conozcan datos tcnicos acerca de la base de datos y que manejen lenguajes de programacin.
Usuarios que utilizan los lenguajes de manipulacin de informacin En diversos sistemas, existen usuarios que no pueden esperar a que los programadores de aplicacin construyan los programas que producirn la informacin que necesitan; estos usuarios son inquietos y por lo regular tienen gran iniciativa, por ello, no les importa aprender los lenguajes de manipulacin para poder acceder directamente a la base de datos y ala informacin que necesitan.
pgina 22
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 mltiples 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: Definicin del esquema de la B.D. Creacin original en la descripcin 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 fsica. Asigna del acceso a la base de datos; da la informacin o parte de ella a los usuarios. Modificacin de la descripcin de la base de datos y reparacin de daos por fallas de hardware o software.
Especificacin de las limitantes de integridad.
pgina 23
1.1.2.3. Arquitectura de un sistema de bases de datos

Un sistema de base de datos se divide en mdulos 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 mayora de los casos, el sistema operativo proporciona slo los servicios ms elementales y la base de datos debe partir de ese fundamento. As, el diseo de la base de datos debe incluir la consideracin 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
Adems, se requieren varias estructuras de datos como parte de la implantacin del sistema fsico, tales como: Archivos de datos Diccionario de datos ndices
pgina 24
La Figura 1.12 muestra los componentes de un sistema de base de datos y las conexiones entre ellos.
Usuarios de las aplicaciones
Programadores de las aplicaciones
Usuarios Casuales
Administrador de la base de datos
Programas de aplicacin
Cdigo fuente de los programas de aplicacin
Consulta
Esquema de la base de datos DBMS
Precompilador de lenguaje de manejo de datos
Procesador de consultas
Precompilador de lenguaje de definicin de datos
Cdigo objeto de los programas de aplicacin
Manejador de base de datos
Manejador de archivos
Archivos de datos Diccionario de datos
Almacenamiento en disco
FIGURA 1.12. Estructura del sistema de base de datos
pgina 25
1.2 Tipos de bases de datos

Los tipos de bases de datos ms comnmente utilizados son bases de datos fundamentadas en la distribucin de sus datos a travs de registros (similar a los registros de archivos). Base de datos tipo relacional Base de datos tipo red Base de datos tipo jerrquico 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 estn basados la mayora 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 grficas arbitrarias. La Figura 1.13 muestra un ejemplo de este modelo, estableciendo la relacin entre alumnos y grupos en un sistema de control escolar.
81315
Jos Lus Martnez CA-10 Matutino
83534
Alberto Lpez CB-09 Matutino
85555
Beatriz lvarez CF-07 Vespertino
87221
Mario Martnez
FIGURA 1.13. Ejemplo de una base de datos de red.
pgina 26
Base de datos tipo jerrquico

El modelo jerrquico 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 jerrquico difiere del de red en que los registros estn organizados como rboles y no como grficas arbitrarias. En la Figura 1.14 se muestra un ejemplo de este modelo.
Alumnos
81315
Jos Lus Martnez
85555
Beatriz lvarez
83534
Alberto Lpez
87221
Mario Martnez
CA-10
Matutino CB-09 Matutino
CB-09
Matutino
CF-07
Vespertino
CA-10
Matutino
FIGURA 1.14. Ejemplo de una base de datos jerrquica.
Las bases de datos en red y jerrquicas son bastante eficientes al momento de extraer de ellas la informacin, ms, sin embargo, tambin tiene sus desventajas. La estructura de estas resulta ser muy rgida. 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 tpicamente la reconstruccin de la base de datos completa. Estas bases de datos son herramientas especficas para programadores, pues es muy difcil que un usuario comn extraiga informacin 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 travs de estas bases de datos. La anotacin de las peticiones para informes a medida dura con frecuencia semanas o meses, y para el momento en que el programa est escrito la informacin con frecuencia ya no merece la pena. Estos dos tipos de bases de datos son muy poco utilizados hoy en da, pues han sido suplantadas exitosamente por las bases de datos relacionales.
pgina 27
1.3 Confusiones acerca de las Bases de Datos

En 1979 una pequea compaa llamada Ashton-Tate introdujo un producto para microcomputadoras llamado dBase II y lo denomin un DBMS relacional. En una tctica promocional muy exitosa, Ashton-Tate distribuy casi gratis ms 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 nmero de aplicaciones de dBase creci con rapidez. Ashton-Tate se volvi una de las primeras grandes corporaciones en la industria de las microcomputadoras, despus fue comprada por Borland, que ahora vende la lnea de productos dBase. Sin embargo, el xito de este producto confundi y embroll el tema del procesamiento a travs de bases de datos. El problema era el siguiente: de acuerdo con la definicin 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 programacin con capacidades generalizadas de procesamiento de archivos (no de procesamiento de base de datos). Los sistemas que se desarrollaron con dBase II se parecan ms a los mostrados en la Figura 1.2 que a los mostrados en la Figura 1.5. Alrededor de un milln de usuarios de dBase II crean que estaban usando un DBMS relacional cuando en realidad no era as. Los trminos sistema de administracin 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 hacan 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 todava 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 clculo no son bases de datos

Antes de concluir este tema, es importante aclarar el concepto falso acerca del trmino base de datos. La mayor parte de las hojas de clculo populares como Lotus 1-2-3, Excel y Quatro Pro contienen caractersticas y funciones que han sido denominadas de bases de datos, emplean este trmino en forma muy imprecisa, en desacorde con la realidad. Una hoja de clculo solo tiene una pequea parte de la funcionalidad que se espera de una base de datos y de un DBMS, y para terminar rpido con el comentario, simple y sencillamente violan casi todas (sino es que todas) las caractersticas de una verdadera base de datos.
pgina 28
2-Fundamentos de bases de datos relacionales
El diseo de una base de datos no es una cosa fcil. El crear adecuadamente entidades con sus relaciones, reglas que cuiden la integridad y todo aquello que respete y asuma los lneamientos 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 organizacin que se dedique al desarrollo del buen software. Dave M- Kroenke, asesor externo de sistemas, y catedrtico de UCLA. Abril de 1993.
Fundamentos de Bases de Datos Relacionales
2.1. Diseo de bases de datos relacionales

Las desventajas de los modelos jerrquicos y en red condujeron a un intenso inters 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 explcitas padre/hijo que contienen las bases de datos jerrquicas 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 versin relacional de la base de datos en red y jerrquica de las Figuras 1.13 y 1.14.
Tabla ALUMNOS CONTROL NOMBRE 81315 Jos Lus Martnez 83534 Alberto Lpez 85555 Beatriz lvarez 87221 Mario Martnez Tabla GRUPOS GRUPO TURNO CA-10 Matutino CB-09 Matutino CF-07 Vespertino
FIGURA 2.1. Ejemplo de una base de datos relacional.
El Dr. Codd escribi un artculo 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 definicin de un DBMS verdaderamente relacional. Sin embargo, es ms fcil comenzar con una definicin ms informal.
Una base de datos relacional es una base de datos en donde todos los datos visibles al usuario estn 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 diseada, sin embargo, esta confusin quedar disuelta al introducirnos en el tema Diagramas de Entidades y Asociaciones que es propio de las bases de datos relacionales.
A los tipos de bases de datos tambin se les conoce como modelos de datos.
pgina 30
2.1.1. Diagrama de Entidades y Asociaciones (DEA)

Son la herramienta ms conveniente para el diseo de la base de datos relacional. Originalmente presentan conjuntos de entidades, relaciones y atributos, pero despus se le agregan otros elementos.
Enfoque de Entidad-Asociacin
El modelo de entidad-asociacin (E-A) se basa en una percepcin de un mundo real, que consiste en un conjunto de objetos bsicos llamados entidades y de las asociaciones entre esos objetos. Este modelo se desarroll para facilitar el diseo de bases de datos permitiendo especificar el esquema de cualquier sistema de informacin.
Componentes de un DEA
Una entidad es un objeto que existe y puede distinguirse de otros. La distincin se logra asociando a cada entidad un conjunto de atributos que describen al objeto. Por ejemplo, los atributos nmero y saldo describen una entidad Cuenta en un banco. La asociacin es el vnculo que existe entre varias entidades. Por ejemplo una asociacin 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. Adems, este modelo permite establecer los requisitos que debe cumplir una base de datos. Uno de estos requisitos importantes es la funcionalidad, que expresa el nmero de entidades con las que puede asociarse otra entidad por medio de un conjunto de asociaciones. Un diagrama de entidad-asociacin 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 entidadasociacin y se les llaman atributos. Por ejemplo, los posibles atributos del conjunto
pgina 31
de entidades Libros son nmero_adquisicin, ttulo, autor, colocacin, tema, editorial, pginas, pas. Para cada atributo existe un conjunto de valores permitidos, llamado dominio. As, el dominio del atributo ttulo podra 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 especfica de una entidad. Usualmente los dominios son enteros, reales, cadenas de caracteres, etc. Para definir el concepto de atributo, veamos un ejemplo de prstamo de libros, definiendo dos entidades participantes que son libros y usuarios, como se muestra en la Figura 2.2.
Libros
Nmero_Adquisicin 12765 12766 . . . Ttulo Fsica General Fsica General . . . Autor Ullman Van Der Merwe . . . Colocacin F277-739-1.1 F277-739-1.1 . . . Tema Fsica Fsica . . . Editorial Mc. Graw Hill Mc. Graw Hill . . . Pginas 289 273 . . . Pas Mxico Mxico . . .
Usuarios
Matrcula 78344 78345 . . . Nombre Jeanette Ros Alberto Delgadillo . . . Direccin Bernal Daz del Castillo No. 235 Rio Balsas No. 125 . . . Colonia Progreso Vista Alegre . . . Ciudad Acapulco, Gro. Acapulco, Gro.
FIGURA 2.2. Ejemplo de conjuntos de entidades para el prstamo de libros en una biblioteca
Asociaciones Una asociacin es una relacin entre varias entidades. Por ejemplo, se puede definir una asociacin que relacione al usuario Janette Ros con el libro que tenga nmero de adquisicin 12765. Un conjunto de asociaciones es un grupo de relaciones del mismo tipo. Para el ejemplo del prstamo de libros en una biblioteca se puede enunciar la asociacin de la siguiente manera: Libro Prestado a Usuario Ntese que la asociacin se lee en cierta direccin, pero tambin puede leerse en las direcciones que uno quiere que se exploren, es decir, al disear una asociacin 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 tambin que un atributo no pertenezca a ninguna de las entidades ligadas por una asociacin, sino a la asociacin misma. En resumen, una asociacin llega a convertirse en una especie de entidad formada con atributos de las entidades asociadas y propios.
pgina 32
Llaves Una tarea muy importante dentro del modelaje de bases de datos consiste en especificar cmo 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 trminos de sus atributos. Para hacer estas distinciones, se asigna una llave a cada conjunto de entidades. La llave es un conjunto de uno o ms atributos, que juntos, permiten identificar en forma nica una entidad dentro de un conjunto de entidades. Por ejemplo, el atributo nmero_adquisicin del conjunto de entidades Libros es suficiente para distinguir a una entidad de otra dentro del mismo conjunto, porque los nmeros de adquisicin de libros no se repiten, es decir, que nunca habr nmeros de adquisicin iguales. Por tanto, nmero_adquisicin es una llave para el conjunto de entidades Libros. De manera similar, la combinacin de nmero_adquisicin y ttulo es una llave para el conjunto de entidades Libros; pero el atributo ttulo no es en s una llave ya que es posible que varios libros tengan el mismo ttulo. 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 ms pequea posible. Estas llaves mnimas se denominan llaves candidato. Es posible que existan varios conjuntos de atributos distintos que pudieran servir como llaves candidato. Por ejemplo, una combinacin de ttulo y autor podr ser suficiente para distinguir una entidad del conjunto de entidades Libros. De esta manera, tanto {nmero_adquisicin} como {ttulo, autor} son llaves candidatos. Aunque los atributos nmero_adquisicin y ttulo juntos pueden servir para identificar unvocamente una entidad, su combinacin no es una llave candidato, puesto que nmero_adquisicin es por s sola una llave candidato, dado que es la ms pequea. Llave Primaria Se utiliza el trmino llave primaria para referirse a la llave candidato que elija el diseador 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 nmero_transaccin, 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 nmero de transaccin. Por lo que este conjunto de entidades no tiene llave primaria. Una entidad de un conjunto de este tipo se denomina entidad dbil. Una entidad que cuenta con una llave primaria se le conoce como entidad fuerte. Aunque un conjunto de entidades dbiles no cuentan con una llave primaria, es necesario tener una forma de distinguir entre todas esas entidades aquellas que
pgina 33
dependen de una entidad fuerte determinada. El discriminador de un conjunto de entidades dbiles es un conjunto de atributos que permite hacer esta distincin. Por ejemplo, el discriminador del conjunto de entidades dbiles Transacciones es el atributo nmero_transaccin, ya que para cada cuenta estos nmeros de transaccin identifican en forma nica cada una de las transacciones.
Discriminador
CuentaHabientes
Nmero_Cuenta 1526568 1526569 . . . CuentaHabiente Domingo Abarca Ramrez Iras Daz Galeana . . .
Transacciones
Nmero_Transaccin 1 1 . . .
Fecha 05/08/97 17/09/97 . . .
Importe 12300.00 6000.00
a)- Entidad Fuerte
a)- Entidad Dbil FIGURA 2.3. La entidad fuerte contra la entidad dbil.
La llave primaria de un conjunto de entidades dbiles 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 Transaccin, su llave primaria es (nmero_cuenta, nmero_transaccin).
Llave primaria
CuentaHabientes
Nmero_Cuenta 1526568 1526569 . . . CuentaHabiente Domingo Abarca Ramrez Iras Daz Galeana . . .
Transacciones
Nmero_Cuenta 1526568 1526569 . . . Nmero_Transaccin 1 1 . . . Fecha 05/08/97 17/09/97 . . . Importe 12300.00 6000.00
a)- Entidad Fuerte
a)- Entidad Dbil
FIGURA 2.4. La llave primaria de una entidad dbil.
Los conjuntos de asociaciones tambin 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 matrcula es la llave primaria del conjunto de entidades Usuarios y nmero_adquisicin es la llave primaria del conjunto de entidades Libros. Por tanto, la llave primaria del conjunto de asociaciones Prstamos es (matrcula, nmero_adquisicin). En el aspecto fsico 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.
pgina 34
Componentes grficos de un Diagrama de entidad-asociacin

Ya que la descripcin de cualquier cosa en un lenguaje natural puede acarrear confusiones, para evitarlas es necesario emplear cierta notacin. Para expresar con claridad las ideas y la estructura lgica general de una base de datos en forma grfica, se utiliza un diagrama de entidad-asociacin (llamado clsico) que se integra con los siguientes componentes: Rectngulos Representa conjuntos de entidades. Elipses Representan atributos. Lneas uniendo entidades Representan asociaciones entre conjuntos de entidades. Lneas 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 lneas se puede indicar el grado de la relacin.
Cada componente se etiqueta con un nombre especfico. 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 prstamo de libros en una biblioteca, se puede obtener del sistema tanto consultas, como reportes e informacin 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-asociacin, en el cual se modela la asociacin que existe entre usuarios y libros de una biblioteca, a travs del prstamo del acervo. Se observa que la asociacin contiene un atributo propio, que es la fecha, por medio de la cual se identifica el da del prstamo y se calcula la fecha de devolucin.
pgina 35
FIGURA 2.5. Ejemplo de un DEA clsico.
Funcionalidad de las asociaciones Es necesario identificar cmo 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 continuacin se muestra la simbologa utilizada para representar el grado de la asociacin entre dos entidades:
No. 1 2 3 4 5 Smbolo Se lee: Uno y solo uno Cero o uno Uno o muchos Cero, uno o muchos Ms de uno
TABLA 2.1. Simbologa utilizada para representar grados de asociaciones entre entidades.
Se puede definir el grado de una relacin como el nmero mximo de ocurrencias de una entidad E (de un conjunto de entidades), que puede participar en una asociacin 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 asociacin entre A y B, el cual debe estar entre alguna de las siguientes.
pgina 36
Una a una (1:1) Una entidad en A est asociada slo con una entidad en B, y una entidad en B est asociada slo con una entidad en A. Se pueden utilizar los smbolos 1 2 en el extremo izquierdo y tambin los smbolos 1 2 en el extremo derecho. Una a muchas (1:n) Una entidad en A est asociada con cualquier nmero de entidades de B, pero una entidad de B puede relacionarse slo con una entidad en A. Se pueden utilizar los smbolos 1 2 en el extremo izquierdo y los smbolos 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 nmero de entidades de A. Se pueden utilizar los smbolos 3, 4, 5 en el extremo izquierdo y los smbolos 1 2 en el extremo derecho. Muchas a muchas (n:n) Una entidad de A est relacionada con cualquier nmero de entidades en B y una entidad de B est asociada con cualquier nmero de entidades de A. Se pueden utilizar los smbolos 3, 4, 5 en el extremo izquierdo e igualmente los smbolos 3, 4, 5 en el extremo derecho. Por ejemplo si se piensa en forma restringida, una cuenta slo puede pertenecer a un cuentahabiente y un cuentahabiente puede tener ms 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 ms cuentas. Esto significa que tiene relacin de una a muchas. Pinsese tambin, en el ejemplo del sistema bibliotecario que se mostr en la Figura 2.5. Se observa que la asociacin 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 slo lo puede tener un usuario como mximo y cero como mnimo. En la figura se denota la asociacin de grado n por medio de una pata de gallo. El diagrama que se utilizar aqu (y el cual es el ms prctico) difiere del diagrama clsico de la Figura 2.5. En este diagrama la entidad tiene una representacin 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:
pgina 37
Nombre_Entidad Key Data atributo1 [PK1] atributo2 [PK2] Non-Key Data atributo3 o o o atributoN Volume min. ##### max. ##### T abla Ingres Nombre_Tabla_F sico
FIGURA 2.6. Cuerpo de una Entidad como diagrama de estructura de datos.
Los elementos que componen a esta entidad son los siguientes:

Nombre_Entidad: atributo1 atributo2 atributo3 . . . atributoN min. #### max. #### Nombre_Tabla_Fsico Se refiere al nombre lgico que tendr la entidad, est deber coincidir con el nombre del Almacn del DFD. Se refiere al nombre de cada uno de los atributos (campos de la tabla ya en la Base de Datos) que componen la entidad, donde los que se encuentran en la zona Key Data son atributos llave.
Se refiere al mnimo y mximo de registros que guardar la entidad ya como tabla fsica. Es el nombre fsico de la tabla en la Base de Datos
TABLA 2.2. Elementos que componen una Entidad como diagrama de estructura de datos.
Adems, estos DEA que se utilizarn son DEA en donde slo se tienen asociaciones binarias y son descritas a travs de una lnea que une a dos conjuntos de entidades indicando la cardinalidad de la asociacin igual que el diagrama clsico, con una notacin de pata de gallo. Los DEA slo contendrn asociaciones de 1:N o bien de 1:1, pero nunca de N:N. Los conjuntos de entidades tendrn un nombre, una descripcin un conjunto de atributos que la compone, indicaciones sobre estos atributos en cuanto a cuales son atributos llave y cual no lo son, nmero mnimo promedio y mximo de entidades esperadas, nombre de la tabla del DBSM a la que corresponder en la implantacin (etapa de diseo y programacin). Adems las asociaciones son sustituidas por diagramas de estructuras de datos, es decir, por entidades nuevas cuyo nombre es el de la propia asociacin.
pgina 38
Para ejemplificar, se disea en la figura de abajo el mismo DEA de la Figura 2.5 pero ahora utilizando el estilo de la Figura 1.3.6, sustituyendo las cajas y valos por los diagramas de estructura de datos:
DEA del Sistema Bibliotecario
Libros Prstamos Usuarios

Key Data Key Data Key Data
Numero_Adquisicin [PK1]
Non-Key Data
Matrcula [PK1]
Non-Key Data
Matrcula [PK1] Nmero_Adquisicin [PK2]

Non-Key Data
Nombre Direccin Colonia Ciudad

Volume
Puede tener
Fecha
Volume
Debe existir en
Min. 1 Max. 1000000

Tabla Ingres
Ttulo Autor Colocacin Tema Editorial Pginas Pas

Volume
Min. 1 Max. 10000

Tabla Ingres
TaPrestamo
Min. 1 Max. 10000

Tabla Ingres
TaUsuario
TaLibro
FIGURA 2.7. DEA del Sistema bibliotecario.
Como se observa en la Figura 2.7, la asociacin Prstamos de la figura 2.5 es sustituida por una entidad del mismo nombre cuyos atributos son los atributos llave de las entidades relacionadas (Matrcula y Nmero_Adquisicin) y el atributo fecha que es propio de la asociacin. Las asociaciones slo tendrn un nombre y reglas de integridad. Los atributos se documentarn 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 continuacin se dan algunos ejemplos en las dos tablas siguientes:
Prefijo Id Num Ce Do SdoIni Nom Desc Stat Significado Identificador numrico que no lleva una secuencia Identificador numrico que lleva una secuencia Clave identificador alfanumrico Saldo Saldo inicial Nombre Descripcin Estado lgico Sufijo Pol Emp Oper Fact Significado Pliza Empleado Operacin Factura
TABLAS 2.3. Ejemplos de prefijos y sufijos para nombrar atributos.
pgina 39
Se hace notar que de aqu en adelante todos los DEA creados usarn esta nueva forma de nombrar a sus atributos, as como sus respectivas tablas fsicas. Ahora bien, para comprender mejor al DEA anterior, habra que entender primero a las propias entidades, por lo que analizaremos a la entidad Usuarios: Est compuesta por cinco atributos de los cuales Matrcula (nmero de control del usuario o alumno)es atributo llave, es decir, habr exactamente un usuario por tupla o registro, y por su parte Nombre, Direccin, Colonia y Ciudad solamente son atributos descriptivos del usuario. Nos habla de que tendr un mnimo de 1 usuario y un mximo de 10000 y que el nombre fsico de la tabla en la Base de Datos ser TaUsuario. Dada la explicacin anterior, entonces la interpretacin o lectura del DEA da la figura 2.7 es de la siguiente manera: 1. Los usuarios de la biblioteca, identificados por su nmero de control (Matrcula), se verifican en la entidad Prstamos para saber si tiene o no libros en calidad de prstamo, es decir, uno y solo un usuario de la biblioteca puede tener uno o ms libros prestados. 2. Estos prstamos registran el nmero del libro (Nmero_Adquisicin) 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 catlogo de libros. 3. En caso de que existan prstamos estos estn registrados en determinada Fecha.
2.2. Resistencia al Modelo Relacional

El modelo relacional encontr mucha resistencia. Los sistemas de bases de datos relacionales requieren ms recursos computacionales y, por lo tanto, al principio eran mucho ms lentos que los sistemas basados en modelos anteriores de bases de datos. Aunque eran fciles de usar, la respuesta era lenta y con frecuencia inaceptable. A tal grado que los productos DBMS relacionales resultaron imprcticos hasta los 80, cuando se desarroll un hardware ms rpido para computadoras y la relacin precio-desempeo cay de un modo dramtico. El modelo relacional tambin le pareca extrao 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 deban aprender un nuevo modo de pensar acerca del procesamiento de datos.
pgina 40
3-Reglas de integridad
Las bases de datos relacionales son como la sociedad: mientras se mantengan sanas las relaciones todo marchar bien, en el momento en que estas se contaminen, todo fallar.
Boyce, R. F., consultor de BD, Agosto de 1994.
Reglas de Integridad.
3.1. Reglas de Integridad de la Base de Datos

Las tablas se encuentran asociadas a otras tablas por medio de sus llaves primarias. Dichas asociaciones normalmente son de 1 a N, es decir a un elemento de una tabla padre le corresponden varios elementos de la tabla hijo. Aunque puede darse el caso de que a un elemento de una tabla se le asocie tan solo un elemento de otra, y aun ms, puede darse el caso de que al elemento de una tabla padre no le corresponda ningn hijo. El caso que jams 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 efecta una transaccin que involucra operaciones de actualizacin y eliminacin sobre una tabla, es necesario reflejar esos cambios en todas las tablas asociadas. Por ejemplo, si se elimina un registro de la tabla Clientes (Entindase un base d datos de CXC), es necesario eliminar todos los registros de las tablas Facturas, Notas de Crdito, 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 diseo 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 repercusin que tienen las operaciones realizadas en una tabla sobre otras que son normalmente las asociadas a esta. Para los dos casos se han diseado estndares 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 cmo deben hacerse las diferentes operaciones de SQL en los registros y en las columnas de la tabla, delimitando claramente el alcance de la operacin con respecto a los propios registros y columnas de la tabla e inclusive a otras tablas asociadas. As por ejemplo, en una operacin de insercin de registros debe dejarse bien claro que reglas debe de cumplir esta operacin para poder efectuarse correctamente, reglas que bien pueden ser simples incrementos de algn atributo llave, verificacin de no-existencia , o algunas operaciones extras como el provocar otras inserciones hacia otras tablas
pgina 42
asociadas. Es decir, que estas operaciones o limitantes pueden darse tanto antes de la propia operacin de insercin o posterior a ella. Las nicas operaciones que deben cumplir con reglas de integridad son aquellas que provocan el cambio directo de la informacin en la base de datos, como son Insercin, Modificacin y Eliminacin. Para dejar ms claro esto veamos como ejemplo las reglas de integridad que se estipularan para la tabla TaLibro (entidad Libros) del DEA del Sistema Bibliotecario de la Figura 2.7:
Operacin Insercin Regla de Integridad El nmero de adquisicin deber ser dado por el usuario, y verificar de forma automtica que este no exista ya en la tabla. Todos los dems campos son de edicin directa. se
Explicacin: Se est estipulando para esta operacin que el sistema deber permitir la libre edicin al usuario para capturar el campo Nmero_Adquisicin, 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 repetiran, y dado que es un campo llave el permitirlo acarreara un serio problema de inconsistencia de informacin en la propia tabla al existir llaves duplicadas. Por otro lado, tambin se est marcando que los dems campos restantes (Ttulo, Autor, Colocacin, etc.) se pueden editar de forma libre ya que estos no provocan propagacin de operaciones como el anterior, Nmero_Adquisicin.
Operacin Regla de Integridad Modificacin La modificacin puede hacerse sobre todos los campos a excepcin de Nmero de Adquisicin.
Explicacin: Es permitida la modificacin en todos los campos a excepcin del campo Nmero_Adquisicin que es un campo llave, y este impedimento se debe a que si se permitiera modificarlo entonces se correra el mismo riesgo de duplicidad de llaves por un lado, y por otro al modificar un campo llave entonces esta operacin de modificacin tendra que propagarse hacia otras tablas asociadas por medio de este atributo a la tabla TaLibro (como es la tabla TaPrestamo), lo cual acarreara un alto costo de programacin extra.
pgina 43
Operacin Eliminacin
Regla de Integridad No deben existir prstamos asociados al libro.
Explicacin: Para poder eliminar un libro de la tabla TaLibro deber comprobarse primero que este no existe como prstamo en la tabla TaPrestamo, y esto se logra por medio del atributo comn entre los dos que es Nmero_Adquisicin. Si el libro con Nmero_Adquisicin 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 eliminacin ser negada. Ahora bien, para registrar fcilmente reglas de integridad en tablas, se propone que estas debern hacerse en el siguiente formato prctico:
Tabla: <Nombre_Tabla> Operacin Insercin Modificacin Eliminacin Regla de Integridad <Texto de regla de Insercin> <Texto de regla de Modificacin> <Texto de regla de Eliminacin>
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 estn estipulando las reglas de integridad. En la columna Operacin se registrarn las tres operaciones permitidas, y en la columna Regla de Integridad se pondr el texto de la regla que corresponde a la operacin en turno.
Reglas de Integridad entre Tablas

Las reglas de integridad entre tablas indican las restricciones que deben seguirse en cualquier operacin 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 operacin. Estas reglas de integridad slo deben aplicarse cuando las reglas de integridad de la propia tabla permitan que se efecte la operacin, en caso contrario no aplica la integridad entre tablas.
pgina 44
En otras palabras, las reglas de integridad entre tablas slo sern 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 estipularan para las tablas TaLibro (entidad Libros), TaPrestamo (entidad Prstamos) y TaUsuario (entidad Usuarios): Tabla: TaLibro
Operacin - Insercin Otras tablas relacionadas Ninguna Restricciones Ninguna No Mod. De Llaves No Existencia
- Modificacin No aplica
- Eliminacin
TaPrestamo
Explicacin: En la operacin de Insercin se est estipulando que al realizarse esta, puede hacerse libremente sin realizar verificacin 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 asociacin de uno a muchos con alguna otra tabla, lo cual nos indica que no tiene descendientes. En la operacin de Modificacin el establecer No aplica" est informando que es irrelevante la relacin que guarde con otras tablas, porque la operacin misma limita esto al establecer como restriccin la No modificacin de llaves, y hay que recordar que las asociaciones entre tablas se dan precisamente a travs de las llaves. Con lo que respecta a la operacin de Eliminacin, 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 relacin y que adems 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 Nmero_Adquisicin) implicara el dejar libros prestados sin que estos existan en la biblioteca.
pgina 45
Tabla: TaPrestamo
Operacin - Insercin Otras tablas relacionadas TaLibro TaUsuario Restricciones Existencia. Existencia. No Mod. De Llaves No Existencia. No Existencia.
- Modificacin No aplica - Eliminacin TaLibro TaUsuario
Explicacin: En la operacin de Insercin 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 asociacin con esta tabla ( Matrcula y Nmero_Adquisicin) 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 insercin, entonces se incurrira en una incongruencia o tambin llamada inconsistencia de la tabla. Con lo que respecta a la operacin de Modificacin cabe la misma explicacin que se dio para esta misma operacin en la tabla TaLibro. En la operacin de Eliminacin, se procede igual que para la eliminacin en la tabla TaLibro solo que aqu la verificacin de No existencia se hace en dos tablas que son TaLibro y TaUsuario, ambas asociadas a la tabla en cuestin.
pgina 46
Tabla: TaUsuario
Operacin - Insercin Otras tablas relacionadas Ninguna Restricciones Ninguna No Mod. De Llaves No Existencia.
- Modificacin No aplica - Eliminacin TaPrestamo
Explicacin: En las dos primera operaciones cabe la misma explicacin que para la tabla TaLibro. Con lo que respecta a la operacin de Eliminacin, se est informando que existe una asociacin con la tabla TaPrestamo, y al observar esto en el DEA nos damos cuenta que la relacin 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 Matrcula) implicara el dejar usuarios con prstamos 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, tambin se sugiere como un estndar que para registrar reglas de integridad entre tablas estas pueden hacerse en el siguiente formato:
Tabla <Nombre_Tabla> Operacin Insercin Modificacin Eliminacin Tablas Relacionadas <Nombre_Tabla_Rel.> Tipo de Restriccin <Restriccin para op.> <Restriccin para op.> <Restriccin 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 estn estipulando las reglas de integridad. En la columna Operacin se registrarn las tres operaciones permitidas, en la columna Tablas Relacionadas se escriben los nombres de aquellas tabla que tengan una relacin con la tabla en cuestin y que se vena afectadas en la operacin en turno y por
pgina 47
ltimo la columna Tipo de Restriccin estipula las condiciones que deben cumplirse en la tabla relacionada para poder efectuar la operacin. Los tipos de restriccin tienen los siguientes valores: Ninguna No hay restriccin entre tablas para efectuar la operacin.
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 modificacin en sus valores llave, por lo que no aplica ninguna restriccin entre tablas.
No Permite Baja
La tabla no permite bajas, por lo que no aplica ninguna restriccin entre tablas.
pgina 48
3.2. Propagacin de Operaciones

Una vez que se permite realizar una operacin dadas las reglas de integridad de y entre tablas, es necesario revisar si la operacin se propaga ms all de la tabla. Es decir, que es probable que la operacin aplicada a la tabla provoque una o ms operaciones extras en tablas relacionadas con esta. Cuando se efecta una operacin de Insercin, Eliminacin o Modificacin, el efecto de la misma se puede propagar a los registros asociados a tablas relacionadas a la que se le aplica la operacin. Si esta operacin 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 mnimo uno (mnimo estn 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 situacin es cambiar el status del padre a Inactivo, lo que da origen a una nueva operacin llamada Cancelacin. En otras palabras el padre ser eliminado solo lgicamente pero nunca fsicamente. En la Insercin, al agregar un registro en la tabla padre no ser necesario agregar registros vacos en algunas de sus tablas hijo. En la Eliminacin, al eliminar un registro de una tabla hijo, no es necesario propagar la operacin a la tabla padre. Por su parte, en la Modificacin, si se modifican los datos que no pertenecen a llave, normalmente no hay propagacin en la operacin, sin embargo, cuando se modifican valores en los campos llave, ser necesario propagar la operacin de modificacin a todos los registros hijos. Esta situacin es rara, y son pocas las ocasiones que se realiza.
pgina 49
A continuacin se describe la forma en que se propagan las operaciones entre las distintas tablas relacionadas para una pequea porcin de un DEA de un Sistema de Cuentas Por Pagar.
Figura 3.1. Porcin de un DEA de un sistema de Cuentas Por Pagar.
El formato a utilizar, es semejante al presentado en la seccin anterior, excepto que en la ltima columna tiene ahora una descripcin. Este se muestra en la siguiente pgina:
pgina 50
Tabla TaCxP
Operacin Insercin
Tablas Padre o Hijo TaPoliza
Descripcin de Propagacin Al insertar una cuenta por pagar se inserta la pliza correspondiente. Las modificaciones realizadas sobre la Cuenta Por Pagar afectan la pliza. La cancelacin de una Cuenta Por Pagar origina la cancelacin de la Pliza tambin. La cancelacin de la Pliza provoca tambin la eliminacin de los movimientos de la misma. No existe
Modificacin
TaPoliza
Cancelacin
TaPliza
TaMovPol
TaPoliza
Insercin
TaMovPol
Modificacin
TaMovPol
No existe
Eliminacin
TaMovPol
Al eliminar una pliza tambin deben ser eliminados sus movimientos.
Tabla 3.3. Formato para registrar la propagacin de operaciones.
pgina 51
4-Introduccin al SQL bsico
Una transaccin 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 adems de esto, el error solo se produzca en determinados eventos, lo cual lo hace difcil de detectar. Eso si pone en jaque a cualquier sistema de informacin!. El autor. Trabajando para Grupo Yoli. Octubre de 1992.
Intoduccin al SQL bsico
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 da. Ha recibido la aceptacin de ANSI como lenguaje de eleccin 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 estndar para el intercambio de informacin entre computadoras. Ya que existe una versin de SQL que puede ejecutarse en casi cualquier computadora y sistema operativo, los sistemas de computacin pueden intercambiar datos pasando consultas y respuestas SQL entre s, lo cual es una capacidad que cada da aumenta ms. Las construcciones y las expresiones permitidas de una puesta en prctica particular de SQL (por ejemplo, en INGRES o en ORACLE) pudieran diferir de alguna forma del estndar ANSI, en parte debido a que mltiples productos DBMS fueron desarrollados antes de llegar al acuerdo sobre el estndar y tambin debido a que los fabricantes han aadido capacidades a sus productos para adquirir ventajas competitivas. Desde una perspectiva de comercializacin, el hecho de cumplir con el estndar 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 aplicacin. En este ltimo caso, son procesados por un precompilador. Por lo tanto SQL no es un lenguaje de programacin; ms 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 ms que una herramienta de consulta, aunque ese fue su propsito 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: Definicin de datos. SQL permite a un usuario definir la estructura y organizacin de los datos almacenados y las relaciones entre ellos. Recuperacin de datos. SQL permite a un usuario o a un programa de aplicacin recuperar los datos almacenados de la base de datos y utilizarlos. Manipulacin de datos. SQL permite a un usuario o a un programa de aplicacin actualizar la base de datos aadiendo nuevos datos, suprimiendo datos antiguos y modificando datos previamente almacenados.
pgina 53
Control de acceso. SQL permite ser utilizado para restringir la capacidad de un usuario para recuperar, aadir y modificar datos, protegiendo as los datos almacenados frente a accesos no autorizados. Comparticin de datos. SQL se utiliza para coordinar la comparticin 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, protegindola contra corrupciones debidas a actualizaciones inconsistentes o a fallas del sistema.
Por lo tanto SQL es un lenguaje completo de control e interactuacin con un sistema de gestin 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 ingls, completadas con palabras de relleno que no aaden nada al significado de la frase pero que hace que se lea ms naturalmente. Hay unas cuantas inconsistencias en el lenguaje SQL, y tambin existen algunas reglas especiales para impedir la construccin de sentencias SQL que parecen perfectamente legales, pero que no tienen sentido.
pgina 54
4.3. Trabajando con SQL

Ahora nos introduciremos al mundo del SQL utilizando sus sentencias bsicas como son SELECT, DELETE, UPDATE, INSERT y algunas otras ms. En realidad SQL contiene muy pocas sentencias nativas (30 ms o menos), es decir, con estndar ANSI, pero pueden encontrarse algunas ms 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 pequea base de datos llamada NOMINA previamente creada en su computadora, y cuyo diagrama de entidades y asociaciones es el siguiente:
Concepto de Pago @IdConcPag DescConcPag OperConcPag TaConcepto
Historia Sueldo @IdEmp @FechIniSdo @FechFinSdo SdoBaseEmp TaHistSueldo
Puesto @IdPuesto DescPuesto TaPuesto
Ligada a Compuesto de Que tiene
Periodo @IdEjer @IdPer FechIniPer FechPagoPer TaPeriodo
Realizado en
Pago @IdEjer @IdPer @IdEmp @IdConcPag ImpPag TaPago
Reciben un
Empleado @IdEmp IdPlaza NomEmp RFCEmp DirEmp NumIMSSEmp SdoBaseEmp StatEmp FechStatEmp FechIngEmp TaEmpleado
Que cubre
Plaza @IdPlaza DescPlaza IdPuesto TaPlaza
La estructura y contenido (datos) de cada una de estas tablas podr encontrarlas en los Apndices A y B que se encuentran al final de estas notas.
pgina 55
Recuperacin de datos (Select)

La sentencia SELECT es la sentencia bsica del SQL, a partir de ella pueden construirse mltiples transacciones para consultar o incluso, modificar la base de datos. Ya sea sola o en combinacin con otras sentencias. El objetivo de SELECT (usada sin sentencias adicionales) es la lectura o recuperacin rpida de datos de una o ms 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 <Condicin>; Donde Atributos son uno o ms atributos de una o ms tablas de la base de datos en cuestin. Tablas son el o los nombres de las tablas que se desean consultar. Y finalmente Condicin es una serie de condiciones que nos sirven para acotar el grupo de registros que sern ledos, 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 tambin, que no estamos usando la clusula 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 ledos deba cambiar, pues de la clusula FROM hacia abajo es todo igual a la consulta anterior.
pgina 56
La Clusula WHERE
Como se dijo anteriormente, la clusula WHERE es usada cuando se necesita acotar el grupo de registros ledos en una consulta. Si recordamos, en las dos consultas anteriores el grupo de registros ledos es el total que existen en la tabla TaEmpleado, pero no siempre ser as. Veamos ahora como podemos acotar este grupo especificndole 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 clusula WHERE de la siguiente forma:
SELECT IdEmp, NomEmp, SdoBaseEmp FROM TaEmpleado WHERE IdEmp = 1590;
Ahora bien, las condiciones de WHERE no estn sujetas solo a igualdades y a atributos de tipo numrico, 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 ms posible atributos de tipo numrico, 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 conversin de datos de atributos siempre ser bastante variado de un DBMS a otro, pues ya sea la conversin o extraccin de datos no estn definidas en el estndar ANSI del SQL.
En las siguientes dos consultas se desea extraer la informacin de todos aquellos empleados que hayan ingresado en el ao de 1990 (primera consulta) y de todos los que hayan ingresado en la segunda quincena de cualquier mes y de cualquier ao (segunda consulta).
pgina 57
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.
pgina 58
Los operadores lgicos y el Test de rango (BetWeen)

Los operadores lgicos como son AND, OR, y NOT tambin tienen un uso relevante en una condicin WHERE. Debido a que con ellos resulta mucho ms fcil acotar grupos de registros, su uso es muy frecuente en casi todas las condiciones. La siguiente consulta esta diseada especialmente pata extraer los datos de los empleados cuyos nmeros 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 resultaran complicadas con solo operadores lgicos. 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 especficos y exactos, es decir, no traer de la tabla un grupo de registros pertenecientes a un rango, sino ms bien, los mnimos y exactamente deseados. Para lograr esto usando operadores lgicos, se necesita de un poco de pericia, paciencia y a veces suerte, pues la construccin de la condicin 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 nmero 1587, 2000, y 2001, se podra hacer de la siguiente manera:
pgina 59
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 nmero entero; pero Qu pasara si el nmero ltimo fuera mayor de 2001?. Seguramente la condicin se complicara. 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 patrn (LIKE)

SQL tambin 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 acompaado por el caracter comodn signo de porcentaje (%). Para ejemplificar su uso, observe la siguiente consulta, la cual est diseada 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 funcin del % es corresponderse con cualquier secuencia de cero o ms caracteres subsecuentes a lo que est antes que l, en este caso la S.
pgina 60
En este otro, se desea extraer los datos de aquellos empleados cuyo nombre comienza con S y lo que continua despus 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 comn 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 estn registrados.
SELECT IdEmp FROM TaHistSueldo;
Como pudo ver, el resultado de la consulta es muchos nmeros de empleado repetidos, es decir, registros duplicados. Para solucionar esto, existe un especificador llamado DISTINCT, que como su nombre lo indica su funcin es hacer que solo aparezcan los que cumplan la condicin 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 prctica no siempre es as, pues muy comnmente se requerir extraer informacin la cual est compuesta de atributos que pertenezcan a
pgina 61
diferentes tablas. SQL permite hacer esto utilizando la caracterstica de asociacin (Join) que es propia del lgebra relacional. Los Join pueden realizarse usando simplemente los nombres de las tablas y sus atributos, o tambin usando alias de las tablas que facilitan mucho la legibilidad de las sentencias, pero sobre todo que resuelven el problema de ambigedad cuando existen atributos con el mismo nombre en dos o ms tablas que forman parte del Join. Los alias, no son ms que sustituciones de nombres de tablas por otros, casi siempre ms cortos (el alias) y que son utilizados para evitar confusiones en la ejecucin y lectura de una consulta. Aunque bien estos alias pueden ser los propios nombres de las tablas. Por ejemplo, si quisiramos referirnos a atributos IdPlaza e IdPuesto de la tabla TaPlaza usando el alias x, entonces esto tendra 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 ledos es igual a 275 que es nada ms y nada menos que el resultado de multiplicar 11 X 25, es decir, el nmero de registros que existen en la tabla TaEmpleado por el nmero 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 ms tablas. La solucin a esto es muy simple, y consiste en utilizar condiciones WHERE lo bastantes completas como para evitar la multiplicacin de datos. Por lo que el problema de la consulta anterior se puede resolver ligando los atributos de asociacin que existen entre una tabla y otra, como se muestra a continuacin:
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 ms tablas al Join, esto no debe preocuparnos si las asociaciones de atributos en la clusula WHERE estn debidamente construidas. As, si a la consulta anterior le agregamos una tabla ms como es TaPuesto, esto puede solucionarse fcil asociando los atributos IdPuesto de las tablas correspondientes, en este caso TaPlaza y TaPuesto, tal como lo muestra la siguiente sentencia:
pgina 62
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 Agrupacin (Sum, Avg, Count, Max, Min)

Siempre ser necesario en cualquier lenguaje, funciones que cumplan la misin de agrupar datos y despus operar sobre este grupo obteniendo un resultado especfico (la suma del grupo, el promedio, el total, el mnimo, el mximo, etc.). En los lenguajes de programacin comunes generalmente estos grupos son arreglos o estructuras de datos en memoria. SQL tambin 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 clusula SELECT solamente sea la columna agrupada, pero cuando esta est acompaada de una o ms columnas no agrupadas, entonces ser necesario incluir en la parte final de la sentencia la clusula GROUP BY.
La funcin Suma (Sum)

La funcin Sum() proporciona la suma completa de todos los datos que estn en la columna agrupada. Esto es muy necesario cuando se desea saber, por ejemplo, el nmero total de mercancas en el almacn. Y esto se logra precisamente sumando todos los valores de la columna que contenga las cantidades de existencia de estas mercancas en la tabla de mercancas. Veamos el siguiente cdigo SQL:
SELECT ImpPag FROM TaPago WHERE IdEjer = 1999;
La intencin real de este cdigo es extraer el total pagado a los empleados en el ao 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 cdigo y hacemos uso de la funcin Sum, este podra quedar as:
pgina 63
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 ao de 1999. Ahora tenemos el caso de extraer nuevamente estos importes de la misma tabla, pero para perodos especficos (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 engaoso, 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 (deduccin o percepcin). 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 perodos (en el mes) sin distinguir:
pgina 64
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 perodo (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 clusula GROUP BY, la cual es necesaria pues se ha agregado una columna al SELECT, la cual no forma parte de la sumarizacin, pero que nos permite indicarle a SQL que deseamos hacer una suma agrupando por IdPer, es decir, una suma por cada perodo distinto, en este caso 1 y 2.
La funcin Promedio (Avg)

La funcin Avg() se usa para calcular el valor promedio de un grupo de datos de la columna especificada. El siguiente cdigo nos despliega el importe de pago por el concepto sueldo en cada perodo para el ao 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;
pgina 65
Como se habr dado cuenta, se ha agregado una nueva clusula a la sentencia SELECT. La clusula ORDER BY. Esta clusula es necesaria cuando se desea que nuestros datos sean extrados en un orden especfico, lo cual lo determinan los atributos escritos despus del ORDER BY. En este caso IdPer e IdEmp. Centrndonos nuevamente en el resultado del SELECT anterior, se nos ocurre ahora que podramos calcular el importe de pago promedio para este mismo concepto, en este mismo ao 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 obtendramos lo especificado anteriormente.
La funcin Cuenta (Count)

La funcin Count() realiza un conteo del nmero de registros encontrados en la columna no importando el tipo de esta. Esta funcin siempre devolver un valor entero, que es exactamente el nmero de registros contados. Por ejemplo, para determinar cuantos registros (empleados) existen en la tabla TaEmpleado podemos lograrlo usando Count() as:
SELECT Count(*) FROM TaEmpleado;
Tambin podemos hacer uso de condiciones en la clusula WHERE, como en el ejemplo siguiente, que extrae el nmero de empleados actualmente activos (con status=1):
SELECT Count(*) FROM TaEmpleado WHERE StatEmp = 1;
pgina 66
Las dos siguientes consultas nos proporcionan resultados diferentes, y esto es debido a que el nmero 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 funcin de agrupacin, como es Count(), con cualquier operando, ya sea otro atributo o bien una constante directa como es un nmero:
SELECT Count(IdEmp) * 300 FROM TaHistSueldo WHERE; IdEmp = 1594;
La funcin Mximo (Max)

Esta funcin obtiene el valor mximo de la columna agrupada. La siguiente sentencia obtiene el nmero de empleado mayor que existe en la tabla TaEmpleado:
SELECT Max(IdEmp) FROM TaEmpleado;
Esta otra pretende obtener el mximo pago hecho por concepto de sueldo:
pgina 67
SELECT Max(ImpPag) FROM TaPago WHERE IdConcPag = 1000;
Con la siguiente, la intencin 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 mximo pagado por concepto de sueldo, pero por cada empleado. Para hacer que nuestra consulta haga lo que nosotros esperamos, haremos uso de un procedimiento vlido 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 mximo importe pagado por concepto de sueldo, y con el empleado que le corresponde esta cantidad, siempre y cuando este importe sea el mximo del total que existen en la propia tabla.
pgina 68
La funcin Mnimo (Min)

La funcin Min() obtiene el valor mnimo de la columna agrupada. Las siguientes sentencias realizan operaciones similares a las anteriores para la funcin Max(), pero ahora calculando el mnimo:
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;
pgina 69
Adicin de datos (Insert)

La modificacin de la base de datos es una cosa de todos los das en la operacin de un sistema de informacin. 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 operacin: 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 clusula VALUES o bien a partir de un SELECT. En este momento veremos el primer caso y dejaremos el segundo para despus. 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, 'Capacitacin', 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 ms de una. Podra corregirlo?.
pgina 70
Eliminacin de datos (Delete)

La eliminacin 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 <Condicin>; donde Tabla es la tabla de la cual se desean eliminar registros y Condicin es una condicin 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.
pgina 71
Actualizacin de datos (Update)

La sentencia UPDATE tiene la funcin de actualizar uno o ms registros de acuerdo a una condicin. Su sintaxis es como sigue: UPDATE Tabla SET Atributo1 = Valor1, Atributo2 = Valor2, . . . AtributoN = ValorN WHERE <Condicin>; 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 tendrn estas columnas. Condicin es una condicin cualquiera usada en un WHERE. En el siguiente ejemplo, se supone que al empleado nmero 1000 (el cual fue agregado anteriormente) se le ha cambiado de sueldo, por lo que su sueldo anterior debe pasar al histrico 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 habamos 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;
pgina 72
Creacin de tablas (Create)

La sentencia CREATE cuya funcin 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 ejecucin en alguna aplicacin.
La sintaxis de CREATE es: CREATE TABLE Tabla ( Atributo1 Tipo_de_dato [especificacin_de_nulidad], Atributo2 Tipo_de_dato [especificacin_de_nulidad], . . . AtributoN Tipo_de_dato [especificacin_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 vlido aceptado por el DBMS (integer, float, char, varchar, date, etc.), especificacin_de_nulidad le informa a la base de datos que el Atributo en cuestin recibir o no datos nulos en cualquier modificacin. La clusula PRIMARY KEY es usada para definir la llave primaria de la tabla. Ejemplo: Suponga que le han solicitado que enve un reporte en una tabla temporal llamada TaTemporal los datos necesarios (Perodo, Nmero, Nombre y Pago) de aquellos empleados que han cobrado sueldo en el ltimo perodo 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:
pgina 73
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 perodo, es decir, el mximo:
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;
pgina 74
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 ms amplio acerca de la potencia de este lenguaje de consulta. Pues aunque se haya ledo o escuchado acerca de l, nunca la teora sin la debida prctica, ayudar en mucho a un futuro diseador u operador de bases de datos relacionales con verdaderos DBMS.
pgina 75
5-Apndices
A pesar de que hoy en da se experimenta con nuevos tipos de bases de datos como son las orinetadas a objeto, faltar mucho tiempo todava para que estas puedan suplantar en su totalidad a las relacionales, pus a pesar de todo , estas siguen siendo una garanta en el proceso rpido de datos, y adems, sin muchas complicaciones.
R. Fagin, experto en BD. Enero de 1999.
Apndice B
Apndice A: Estructura de tablas de la base de datos ejemplo NOMINA:
Tabla: TaEmpleado Atributo Tipo IdEmp integer IdPlaza integer NomEmp varchar RFCEmp varchar DirEmp varchar NumIMSSEmp integer SdoBaseEmp float StatEmp integer FechStatEmp date FechIngEmp date
Longitud
40 15 100
Tabla: TaPlaza Atributo Tipo IdPlaza integer DescPlaza varchar IdPuesto integer
Longitud 30
Tabla: TaPuesto Atributo Tipo IdPuesto integer DescPuesto varchar
Longitud 30
Tabla: TaPeriodo Atributo Tipo IdEjer integer IdPer integer FechIniPer integer FechFinPer integer
Longitud
Tabla: TaConcepto Atributo Tipo IdConcPag integer DescConcPag varchar OperConcPag integer
Longitud 30
Tabla: TaPago Atributo Tipo IdEjer integer IdPer integer IdEmp integer IdConcPag integer ImpPag float
Longitud
Tabla: TaHistSueldo Atributo Tipo IdEmp integer FechIniSdo date FechFinSdo date SdoBaseEmp float
Longitud
pgina 77
Apndice B
Apndice B: Contenido de tablas de la base de datos ejemplo NOMINA:

Se aclara aqu, que algunas tablas no estn presentadas en su totalidad de registros debido al tamao que estas tienen, en especial las tablas TaPeriodo y TaPago que llegan a rebasar el medio millar de tuplas.
Tabla: TaPlaza IdPlaza DescPlaza 100 Auxiliar Ventas 101 Ventas 102 Auxiliar de contabilidad 103 Coordinacin de Contabilidad 104 Coordinacin de Contabilidad 105 Auxiliar Auditora 106 Auditora 107 Programador 108 Programador 109 Analista 110 Analista 111 Coordinador 112 Auxiliar Mecnico 113 Mecnico 115 Vigilante 116 Vigilante 117 Programador 118 Prgramador 119 Coordinador 120 Coordinador 121 Gerente 122 Gerente 123 Gerente 124 Gerente 125 Gerente IdPuesto 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 15 8 9 12 16 17 19 20 21 22 Tabla: TaPuesto IdPuesto DescPuesto 1 Auxiliar de ventas 2 Vendedor Titular 3 Auxilar de contabilidad 4 Coordinador de CXC 5 Coordinador de CXP 6 Auxiliar de Auditora 7 Auditor 8 Programador A 9 programador B 10 Analista A 11 Analista B 12 Lider de Proyectos 13 Ayudante de mecnico 14 Mecnico 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 Auditora interna 22 Gerente de Mantenimiento Tabla: TaPeriodo IdEjer IdPer FechIniPer FechPagoPer 1999 1 01/01/99 14/01/99 1999 2 16/01/99 29/01/99 1999 3 01/02/99 13/02/99 1999 4 16/02/99 27/02/99 1999 5 01/03/99 14/03/99 1999 6 16/03/99 29/03/99 1999 7 01/04/99 14/04/99 1999 8 16/04/99 28/04/99 1999 9 01/05/99 13/05/99 1999 10 16/05/99 27/05/99 1999 11 01/06/99 14/06/99 1999 12 16/06/99 28/06/99 1999 13 01/07/99 13/07/99 1999 14 16/07/99 29/07/99 1999 15 01/08/99 13/08/99 1999 16 16/08/99 28/08/99 1999 17 01/09/99 13/09/99 1999 18 16/09/99 27/09/99 1999 19 01/10/99 14/10/99 1999 20 16/10/99 27/10/99 1999 21 01/11/99 14/11/99 1999 22 16/11/99 29/11/99 1999 23 01/12/99 12/12/99 1999 24 16/12/99 28/12/99
Tabla: TaConcepto IdConcPag DescConcPag 1000 Sueldo 1001 Tiempo Extra 1002 Ayuda de Despensa 2001 IMSS 2002 INFONAVIT 2003 SAR
OperConcPag 1 1 1 -1 -1 -1
pgina 78
Apndice B
Tabla: TaPago IdEjer IdPer IdEmp IdConcPag 1999 1 1587 1000 1999 1 1587 2001 1999 1 1587 2002 1999 1 1587 2003 1999 2 1587 1000 1999 2 1587 1002 1999 2 1587 2001 1999 2 1587 2002 1999 2 1587 2003
ImpPag 2250.00 300.00 100.00 120.00 2250.00 1000.00 770.00 200.00 300.00
Tabla: TaHistSueldo Idemp FechIniSdo 1587 12/01/96 1587 1/01/98 1588 1/05/95 1588 1/01/98 1589 16/01/90 1589 1/01/98 1590 1/11/91 1590 1/01/98 1591 16/01/93 1591 1/01/97 1592 16/12/90 1592 1/01/98 1593 1/01/88 1593 1/01/98 1594 16/06/98 1595 1/01/85 1595 1/01/98 2000 1/01/86 2000 1/01/96 2001 1/02/85 2001 1/01/98
FechFinSdo 31/12/97 31/12/98 31/12/97 30/06/99 31/12/97 31/12/98 31/12/98 31/12/98 31/12/96 31/12/98 31/12/98 15/03/99 31/12/97 31/12/98 31/12/98 31/12/97 31/12/98 31/12/95 31/12/98 31/12/97 31/12/98
SdoBaseEmp 100 125 75 100 150 175 250 275 250 275 275 300 425 400 275 400 425 675 650 650 675
pgina 79
Apndice B
Tabla: TaEmpleado IdEmp IdPlaza NomEmp 1587 101 GONZALO FLORES DAVALOS 1588 100 ARTURO SALAS HERNANDEZ 1589 102 CECILIA MOSSO LOMELI 1590 103 LAURA ALVAREZ JIMENEZ 1591 107 PABLO DIAZ RUIZ 1592 109 RAUL NAJERA SUAREZ 1593 111 SANDRA PEREA URIOSTEGUI 1594 117 HORACIO NORIEGA SALMERON 1595 120 LUIS MENDOZA CONTRERAS 2000 122 SALVADOR BALBUENA RAMIREZ 2001 121 FERNANDO ZAPATA BUSTOS
RFCEmp FODG-670419-E34 SAHA-701123-U34 MOLC-700212 AAJL-690720-O90 DIRP-740523-A23 NASR-720923-K23 PEUS-701210-D45 NOSH-750119-I45 MECL-660315-T56 BARS-690113-Y78 ZABF-660124-A90
DirEmp NumIMSSEmp SdoBaseEmp StatEmp FechStatEmp FechIngEmp ZARAGOZA 100, COL. ZAPATA, ACAPULCO, 1783429082 150.00 1 12/04/96 12/01/96 RIO BRAVO 123, COL. HOGAR MODERNO, A 3456123478 100.00 0 01/07/99 01/10/95 COSTERA MIGUEL ALEMAN 206, FRACC. MA 3456878909 200.00 1 16/09/90 16/07/90 AV. FARALLON NO. 148, ACAPULCO, GRO. 1287996578 300.00 1 01/02/92 01/11/91 CALZ. PIE DE LA CUESTA NO. 43-G, ACAPUL 5675687231 300.00 1 16/04/93 16/01/93 BENITO JAUREZ NO. 19 1er. PISO, UNID. HA 1254676790 300.00 0 16/03/99 16/12/90 AV. EJIDO 81, COL. HOGAR MODERNO, ACA 3254568798 450.00 1 01/04/88 01/01/88 CALLE LA LOMA NO. 1, INT. 2, FRACC. CUMB 7898908001 300.00 1 16/09/98 16/06/98 GAVIOTAS 25, FRACC. LAS PLAYAS, ACAPU 5677897892 450.00 1 01/05/85 01/02/85 FERNADO DE MAGALLANES NO. 4, FRACC. 5667544678 700.00 1 01/01/86 01/01/86 HERNAN CORTES 28, FRACC. MAGALLANES 4565678891 700.00 1 01/02/85 01/02/85
pgina 80
Apndice C
Apndice 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));
pgina 81
Apndice C
CREATE TABLE TaPago ( IdEjer integer not null, IdPer integer not null, IdEmp integer not null, IdConcPag integer not null, ImpPag float not null, PRIMARY KEY (IdEjer, IdPer, IdEmp, IdConcPag));
CREATE TABLE TaHistSueldo ( IdEmp integer not null, FechIniSdo date not null, FechFinSdo date not null, SdoBaseEmp float not null, PRIMARY KEY (IdEmp, FechIniSdo, FechFinSdo));
pgina 82

Introducción A Las Bases de Datos Relacionales

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Introducción A Las Bases de Datos Relacionales

Caricato da

Copyright:

Formati disponibili

INTRODUCCION A LAS BASES DE DATOS RELACIONALES

Domingo Abarca Ramrez. Diciembre de 1999, Mxico.

2-Fundamentos de bases de datos relacionales _____________________ 29

2.2. Resistencia al Modelo Relacional _____________________________________ 40

3-Reglas de integridad ________________________________________ 41

4-Introduccin al SQL bsico __________________________________ 52

4.4. Notas finales acerca de SQL _________________________________________ 75

1-Introduccin a las bases de datos

Extrado de la revista BD Computers, artculo publicado en enero de 1992.

BASES DE DATOS RELACIONALES

Introduccin a las bases de datos

Un comentario acerca de las Bases de Datos

1.1. Definicin de Base de Datos

1.1.1. Sistemas de procesamiento de archivos

Domingo Abarca Ramrez Mtodos e Ingeniera en Sistemas.

BASES DE DATOS RELACIONALES

Introduccin a las bases de datos

Alejandro Apac Sandoval Luis Orozco Bedolla

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

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

Domingo Abarca Ramrez Mtodos e Ingeniera en Sistemas.

BASES DE DATOS RELACIONALES

Introduccin a las bases de datos

Programa de actualizacin de empleados. DA Archivo maestro de empleados

Programa de informe de empleados. Usuario del sistema de nmina. DA

Programa de impresin de cheques. DA DA Archivo de historia de sueldos

FIGURA 1.2. Aplicacin de nmina utilizando un sistema de procesamiento de archivos.

Domingo Abarca Ramrez Mtodos e Ingeniera en Sistemas.

BASES DE DATOS RELACIONALES

Introduccin a las bases de datos

Domingo Abarca Ramrez Mtodos e Ingeniera en Sistemas.

BASES DE DATOS RELACIONALES

Introduccin a las bases de datos

Domingo Abarca Ramrez Mtodos e Ingeniera en Sistemas.

BASES DE DATOS RELACIONALES

Introduccin a las bases de datos

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

Sucursal: 12 Renacimiento Tipo de Empleado: 01 Confianza

Id. Emp. 600234 609314 601256 602567 605621 609152 601045

Direccin: xxxx xxxx xxxx xxxx xxxx xxxx xxxx

Sueldo: 5000.00 6000.00 7000.00 5000.00 8000.00 8500.00 9000.00

1.1.2. Sistemas de procesamiento de bases de datos

Domingo Abarca Ramrez Mtodos e Ingeniera en Sistemas.

BASES DE DATOS RELACIONALES

Introduccin a las bases de datos

Aplicacin(es) de base de datos

Usuario del sistema de nmina.

FIGURA 1.5. Aplicacin de nmina utilizando un sistema de procesamiento de base de datos.

1.1.2.1 Conceptos de bases de datos

Domingo Abarca Ramrez Mtodos e Ingeniera en Sistemas.

BASES DE DATOS RELACIONALES

Introduccin a las bases de datos

Sistema manejador de bases de datos (DBMS)

FIGURA 1.6. Esquematizacin de la labor de un DBMS.

Domingo Abarca Ramrez Mtodos e Ingeniera en Sistemas.

BASES DE DATOS RELACIONALES

Introduccin a las bases de datos

Menos duplicacin de datos o no-redundancia de informacin

Domingo Abarca Ramrez Mtodos e Ingeniera en Sistemas.

BASES DE DATOS RELACIONALES

Introduccin a las bases de datos

Num_Pedido 23455 24879 34488 23455 34488 23455

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