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