Introducción a las bases de datos relacionales

INTRODUCCION A
LAS BASES DE
DATOS
RELACIONALES
Domingo Abarca Ramírez.
Diciembre de 1999, México.

Contenido
1-Introducción a las bases de datos _______________________________ 5
Un comentario acerca de las Bases de Datos ________________________________ 6
1.1. Definición de Base de Datos __________________________________________ 6
1.1.1. Sistemas de procesamiento de archivos________________________________ 6
1.1.2. Sistemas de procesamiento de bases de datos __________________________ 11
1.1.2.1 Conceptos de bases de datos_____________________________________ 12
Sistema manejador de bases de datos (DBMS)___________________________ 13
Datos Integrados __________________________________________________ 14
Menos duplicación de datos o no-redundancia de información ______________ 14
Independencia programas/datos ______________________________________ 15
Fácil representación de la vista de datos a los usuarios ____________________ 16
Una base de datos es autodescriptiva __________________________________ 16
Una base de datos es un conjunto de registros integrados___________________ 16
1.1.2.2. Componentes de una base de datos _______________________________ 18
Hardware y software _______________________________________________ 18
Lenguajes de bases de datos _________________________________________ 19
Lenguaje de definición de datos (DDL) ________________________________ 19
Lenguaje de manipulación de datos (DML) _____________________________ 20
Manejador de base de datos (DBMS) __________________________________ 20
Usuarios_________________________________________________________ 21
Usuarios de programas de aplicación_________________________________ 21
Programadores de aplicación _______________________________________ 22
Usuarios que utilizan los lenguajes de manipulación de información________ 22
Administrador de la base de datos (DBA) _____________________________ 23
1.1.2.3. Arquitectura de un sistema de bases de datos _______________________ 24
1.2 Tipos de bases de datos______________________________________________ 26
Base de datos tipo relacional ____________________________________________ 26
Base de datos tipo red _________________________________________________ 26
Base de datos tipo jerárquico ____________________________________________ 27
1.3 Confusiones acerca de las Bases de Datos_______________________________ 28
Advertencia: las hojas de cálculo no son bases de datos _______________________ 28
2-Fundamentos de bases de datos relacionales_____________________ 29
2.1. Diseño de bases de datos relacionales__________________________________ 30
2.1.1. Diagrama de Entidades y Asociaciones (DEA) _________________________ 31
Enfoque de Entidad-Asociación ________________________________________ 31
Componentes de un DEA _____________________________________________ 31
Componentes gráficos de un Diagrama de entidad-asociación ________________ 35
2.2. Resistencia al Modelo Relacional _____________________________________ 40

3-Reglas de integridad ________________________________________ 41
3.1. Reglas de Integridad de la Base de Datos ______________________________ 42
Reglas de Integridad de Tablas __________________________________________ 42
Reglas de Integridad entre Tablas ________________________________________ 44
3.2. Propagación de Operaciones ________________________________________ 49
4-Introducción al SQL básico __________________________________ 52
4.1. ¿Que es SQL? _____________________________________________________ 53
4.2. Las funciones de SQL ______________________________________________ 53
4.3. Trabajando con SQL _______________________________________________ 55
Recuperación de datos (Select) __________________________________________ 56
La Cláusula WHERE ________________________________________________ 57
El uso de asterisco (*)________________________________________________ 58
Los operadores lógicos y el Test de rango (BetWeen) _______________________ 59
El Test de pertenencia (IN)____________________________________________ 59
Test de correspondencia con patrón (LIKE)_______________________________ 60
Filas duplicadas (DISTINCT)__________________________________________ 61
Consultas multitablas (Join) ___________________________________________ 61
Funciones de Agrupación (Sum, Avg, Count, Max, Min)______________________ 63
La función Suma (Sum) ______________________________________________ 63
La función Promedio (Avg) ___________________________________________ 65
La función Cuenta (Count)____________________________________________ 66
La función Máximo (Max) ____________________________________________ 67
La función Mínimo (Min)_____________________________________________ 69
Adición de datos (Insert) _______________________________________________ 70
Eliminación de datos (Delete) ___________________________________________ 71
Actualización de datos (Update) _________________________________________ 72
Creación de tablas (Create)____________________________________________ 73
4.4. Notas finales acerca de SQL _________________________________________ 75
5-Apéndices _________________________________________________ 76
Apéndice A: Estructura de tablas de la base de datos ejemplo NOMINA: _______ 77
Apéndice B: Contenido de tablas de la base de datos ejemplo NOMINA: _______ 78
Apéndice C: Script SQL para crear las tablas de la base de datos ejemplo
NOMINA: ___________________________________________________________ 81

1-Introducción a las bases de datos
Los directores de empresas quieren que sus sistemas
de bases de datos ¡NUNCA! fallen. No hay nada
peor que llegar a depender de un sistema de
información por computadora y encontrarse con
que no se puede contar con él.
Extraído de la revista BD Computers, artículo
publicado en enero de 1992.

BASES DE DATOS RELACIONALES Introducción a las bases de datos
© Domingo Abarca Ramírez – Métodos e Ingeniería en Sistemas. página 6
Un comentario acerca de las Bases de Datos
A pesar de las múltiples confusiones conceptuales que todavía existen acerca de las
bases de datos, es imposible negar que su desarrollo y avance tecnológico es a pasos
agigantados, por lo que aquellos profesionales del desarrollo de software que no se
actualicen en la materia, simple y sencillamente se quedarán a la zaga o al margen de la
creación y operación de los nuevos y grandes sistemas de información. Hoy en día, y debido
a la importancia que tiene la información en todas las organizaciones, a las bases de datos
se les ha puesto gran atención y ello ha conducido al desarrollo de conceptos y técnicas para
manejar los datos en forma eficiente. En este curso se estudiarán todos esos conceptos a
detalle.
1.1. Definición de Base de Datos
Una base de datos es un conjunto cualquiera de datos estructuralmente relacionados
entre sí. Convencionalmente, los datos se organizan como un archivo de datos, el archivo
consta de registros y los registros están compuestos por uno o más campos de datos, siendo
los campos de un tipo de dato de un conjunto de varios tipos de datos. Sin embargo,
muchas veces la definición anterior resulta demasiado pobre al usuario. Por lo mismo, para
poder entender mejor lo que significa una base de datos, empezaremos por ver las
particularidades de los sistemas que precedieron al uso de la tecnología de las bases de
datos, es decir, los sistemas de procesamiento de archivos, ya que estos sistemas revelan los
problemas que ha resuelto la tecnología de las bases de datos.
1.1.1. Sistemas de procesamiento de archivos
Como se mencionó anteriormente un archivo de datos es un cúmulo de datos de
diferentes tipos organizados en un mismo lugar, que es el propio archivo. Este archivo está
identificado con un nombre propio y con este se le hace acceso ya sea para agregar,
eliminar, modificar o solamente consultar datos.

El archivo está estructuralmente compuesto por registros, que son bloques contiguos
identificados por un número llamado número de registro, a su vez estos registros están
conformados por divisiones de menor tamaño de información llamadas campos1
, donde
estos campos almacenarán cualquier tipo de datos, es decir, que estos pueden ser datos
alfanuméricos o numéricos según sea la necesidad.
FIGURA 1.1. Forma o estructura de un archivo de datos.
En el pasado los sistemas de procesamiento de archivos eran generalmente
proporcionados por el fabricante del computador (tales como la nómina y los registros de
contabilidad) como parte del sistema operativo, llevaba la cuenta de los nombres y
ubicaciones de los archivos. El sistema de gestión de archivos básicamente no tenía un
modelo de datos, es decir, no sabía nada acerca de los contenidos internos de los archivos.
Para el sistema de gestión de archivos un archivo que contuviera un documento de
procesamiento de textos y un archivo que contuviera datos de nóminas simplemente no los
distinguiría. El conocimiento acerca del contenido de un archivo –que datos almacena y
como están organizados- estaba incorporado a los programas de aplicación que utilizaban el
archivo.
1
Los títulos de los campos no son almacenados en el archivo, es decir, que no forman parte de él, aquí se presentan para
una mera explicación.
NomEmp DirEmp FechNac IngAnual
1 Rosalba Arciniega López Av. Michoacán 1340, Col. Progreso. 750612 50000.00
2 Domingo Abarca Ramírez Cuauhtémoc 70-B, Col. Centro 680514
3 Eva Samayoa Dorantes Gaviotas 45,Fracc. Las Playas, Caleta. 740422 60000.00
.
.
.
99 Alejandro Apac Sandoval Baja California 99, Col. Progreso. 690223 200000.00
100 Luis Orozco Bedolla Mina 64, Col. Centro. 660825 100000.00
Registros
No. de Registro Campos alfanuméricos Campos numéricos

Así, tal como lo muestra la Figura 1.2. los primeros sistemas de información
comerciales almacenaban grupos de registros en archivos separados.
FIGURA 1.2. Aplicación de nómina utilizando un sistema de procesamiento de archivos.
En esta aplicación de nómina, cada uno de los programas (hechos en COBOL) que
procesaban el archivo maestro de empleados contenía una descripción de archivo (DA) que
describía la composición de los datos en el archivo. Si la estructura de los datos cambiaba –
por ejemplo, si un grupo adicional de datos fuera a ser almacenado por cada empleado-
todos los programas que accedían al archivo tenían que ser modificados. Como el número
de archivos y programas crecía con el tiempo, todo el esfuerzo de procesamiento de datos
de un departamento de desarrollo se perdía en mantener aplicaciones (programas) existentes
en lugar de desarrollar otras nuevas.
Programa de
actualización de
empleados.
DA
Archivo
maestro de
empleados
Programa de informe
de empleados.
DA
Archivo de
historia de
sueldos
Programa de
impresión de cheques.
DA
DA
Usuario del
sistema de nómina.

Aunque los sistemas de procesamiento de archivos representan una significativa mejoría
sobre los sistemas manuales de registro, estos tienen importantes limitaciones:
 Los datos están separados y aislados.
 Con frecuencia, los datos están duplicados.
 Los programas de aplicación dependen de los formatos de los archivos.
 Con frecuencia, los archivos son incompatibles entre sí.
 Es difícil representar los datos en el modo en que los usuarios los ven.
Veamos cada uno de estas limitaciones por separado.
 Datos separados y aislados
El usuario de la Figura 1.2 necesita relacionar a los empleados con cada uno de los
sueldos que les corresponde para poder así imprimir el cheque de su pago adecuadamente.
En este caso los datos necesitan extraerse de algún modo de los archivos de empleados y de
historia de sueldos y combinarse en un archivo sencillo donde estarán los datos deseados
que serán impresos. Con el procesamiento de archivos, tal cuestión es difícil. Los analistas
de sistemas y los programadores deben determinar cuáles partes de cada archivo son
necesarias; deben también decidir cómo se relacionan los archivos entre sí y deben
coordinar el procesamiento de los archivos de modo tal que se extraigan los datos correctos.
FIGURA 1.3. En un sistema de procesamiento de archivos extraer los datos
suele ser muy complicado.
Coordinar dos archivos es muy difícil, imagínese la tarea de coordinar diez o más de
ellos, simple y sencillamente es una tarea titánica.
Como si fuera tan sencillo,
con este “desm...” de datos
que tiene aquí...Necesito esos reportes
para hoy a las 4:00
p.m. Gómez.
Sí señor. Pondré
todo mi esfuerzo.

 Duplicación de los datos
En el ejemplo de la nómina puede almacenarse varias veces el nombre de un empleado,
así como sus otros datos. Los datos se almacenan una vez para el archivo de empleados y de
nuevo en el archivo de historia de sueldos para cada sueldo que el empleado ha tenido a lo
largo de su estancia en la empresa. Los datos duplicados desperdician espacio para
archivos, lo cual no es el problema más serio. La dificultad significativa de la duplicación
de los datos tiene que ver con la integridad de la información.
Un conjunto de datos tiene integridad si son consistentes, si se ensamblan entre sí. Con
frecuencia en los sistemas de procesamiento de archivos se aprecia una pobre integración de
los datos. Por ejemplo si un empleado cambia su número de identificación o su dirección,
deben actualizarse todos los archivos que contienen sus datos; el peligro reside en que todos
los archivos pudieran no actualizarse, causando discrepancias.
Los problemas de integridad de los datos son serios. Si los contenidos de los datos
difieren producirían resultados inconsistentes. Si un reporte de una aplicación es diferente
al de otra aplicación, ¿quién decidiría cuál es la correcta?. Cuando los resultados son
inconsistentes se duda de la credibilidad de los datos almacenados, e incluso de la función
misma del sistema.
 Dependencia del programa de aplicación
Con el procesamiento de archivos, los programas de aplicación dependen de los
formatos del archivo. En estos sistemas los formatos físicos de los archivos y los registros
son parte del código de la aplicación. El problema con esta forma de trabajar es que cuando
se hacen cambios en los formatos de los archivos, también deben modificarse los programas
de aplicaciones.
 Archivos incompatibles
Una de las consecuencias de la dependencia de los datos del programa es que los
formatos del archivo dependen del lenguaje o del producto usado para generarlos. El
formato de un archivo procesado por un programa COBOL es diferente al de un programa
BASIC, que es distinto al de un archivo procesado por un programa en lenguaje C.
 La dificultad de representar los datos como los ve el usuario
Es difícil representar los datos del procesamiento de archivos en una forma que parezca
natural a los usuarios. Los usuarios quieren ver los datos de un empleado en un formato
como el que se presenta a continuación:

FIGURA 1.4. Formato de pantalla deseada por el usuario para una aplicación.
Para mostrar los datos de este modo es necesario extraer, combinar y presentar juntos varios
archivos diferentes. Esta dificultad surge porque con el procesamiento de archivos no se
representan o procesan con sencillez las relaciones entre los registros. Debido a que un
sistema de procesamiento de archivos no puede determinar con rapidez cuáles
EMPLEADOS son los que se desean presentar con su SUELDO actual, es difícil producir
una forma que muestre los datos solicitados.
1.1.2. Sistemas de procesamiento de bases de datos
Los problemas de mantener grandes sistemas basados en archivos condujeron a
finales de los sesenta al desarrollo de los sistemas de gestión de base de datos. La idea
detrás de estos sistemas era sencilla: tomar la definición de los contenidos de un archivo y
la estructura de los programas individuales, y almacenarla, junto con los datos, en una base
de datos. Utilizando la información de la base de datos el manejador (llamado DBMS) que
la controla puede tomar un papel mucho más activo en la gestión de los datos y en los
cambios a la estructura de la base de datos.
Empresa X S.I.I.G.Y. DD/MM/AA
Nómina Consultor de Empleados consnom.exe
Sucursal: 12 Renacimiento
Tipo de Empleado: 01 Confianza
Id. Emp. Nombre: Dirección: Sueldo:
600234 Samayoa Dorantes Eva xxxx 5000.00
609314 García Hernández Fidel xxxx 6000.00
601256 Ramos Baños Luis xxxx 7000.00
602567 Viilegas Reyes Josefina xxxx 5000.00
605621 Hernández Bravo Juan Miguel xxxx 8000.00
609152 Olivar Campos Víctor xxxx 8500.00
601045 Cortez Dillanes Marco Antonio xxxx 9000.00

La tecnología de las bases de datos se desarrolló para superar las limitaciones de los
sistemas de procesamiento de archivos. Compare el sistema de procesamiento de archivos
de la Figura 1.2 con el sistema de bases de datos para la misma nómina en la figura
siguiente:
FIGURA 1.5. Aplicación de nómina utilizando un sistema de procesamiento de base
de datos.
Los programas de procesamiento de archivos acceden a los archivos de los datos
almacenados. En contraste, los programas de procesamiento de base de datos acuden al
DBMS para acceder a los datos almacenados. Esta diferencia es significativa: hace más
fácil la tarea de programar la aplicación. Los programadores no deben preocuparse por las
formas en que los datos se almacenan. Más bien quedan libres para concentrarse en
cuestiones importantes para el usuario, y no con aspectos del sistema de computación.
1.1.2.1 Conceptos de bases de datos
Ahora bien, el término base de datos permite distintas interpretaciones. Ha sido usado
para referirse tanto a un conjunto de tarjetas índice como a los millones y millones de datos
que un gobierno recopila acerca de sus ciudadanos. Usaremos el término con un significado
específico: una base de datos es un conjunto autodescriptivo de registros integrados
controlados por un DBMS. Es importante comprender cada parte de tal descripción.
Aplicación(es)
de base de
datos DBMS
Base de datos
Usuario del sistema
de nómina.

Sistema manejador de bases de datos (DBMS)
Un sistema manejador de bases de datos (Database Management System, DBMS),
consiste en un conjunto de datos relacionados entre sí y un grupo de programas que les den
acceso. El conjunto de datos se conoce comúnmente como base de datos. Las bases de datos
generalmente contienen información acerca de una empresa determinada.
El objetivo primordial de un DBMS es crear un ambiente en el que sea posible
guardar y recuperar información de la base de datos en forma eficiente; es decir, permitir a
los usuarios trabajen o traten con los datos en forma simple, sin necesidad de atender la
forma en que la computadora los almacena.
En este sentido, el DBMS actúa como intérprete de un lenguaje de alto nivel. Los
sistemas de bases de datos se diseñan para manejar grandes volúmenes de información a
sabiendas que la cantidad de usuarios que la utilicen será considerable, tal como se puede
esquematizar en la Figura 1.6.
El manejo de los datos incluye tanto la definición de las estructuras como los
mecanismos para el acceso de la información. Además, el sistema de bases de datos cuida la
seguridad de la información almacenada en la base de datos, tanto contra las caídas del
sistema, como contra los intentos de acceso no autorizado. Si los datos ven a compartirse
para varios usuarios, el sistema debe proteger que al efectuar modificaciones no se
encuentren resultados que presenten inconsistencias.
FIGURA 1.6. Esquematización de la labor de un DBMS.
DBMS
Base de
Datos

Como se aprecia en la figura anterior, puede haber un gran número de usuarios
trabajando en la base de datos que puede estar almacenada en un servidor (llamado servidor
de base de datos), si no existiese el DBMS el control y distribución de los datos para cada
uno de los usuarios sería un verdadero caos. Por ejemplo, si más de uno tratara de leer la
misma información al mismo tiempo el resultado de dicha consulta sería desastroso en la
confiabilidad de la respuesta y lento en el proceso de la misma. Para evitar esto, cada uno
de ellos tendría que programar sus tiempos de consulta de tal forma que no afectasen o
chocasen con los demás. Por el contrario, con la existencia del DBMS esto es más sencillo,
pues el se encarga de todos estos aspectos y de muchos otros más evitando así, la pérdida de
tiempo e información.
Datos Integrados
En un sistema de base de datos todos los datos de la aplicación se almacenan en un
medio sencillo llamado base de datos. Un programa de aplicación puede pedirle al DBMS
que acceda a datos en particular como los datos personales de un empleado, sus impuestos
retenidos, su historia de sueldos, o todos al mismo tiempo. Si todos se necesitan el
programador de la aplicación solo especifica como deberán combinarse los datos y el
DBMS realiza las operaciones necesarias para conseguirlo. El programador no es
responsable de escribir los programas para coordinar los archivos, lo cual si debe hacer para
el sistema de la Figura 1.2.
Menos duplicación de datos o no-redundancia de información
¿Que es la redundancia de información?
Supóngase que en un sistema de procesamiento de archivos se tiene el archivo de
pedidos que se muestra en la Figura 1.7(a) y el archivo de conceptos de la Figura 1.7(b).
Como se observa, el DescConcepto se encuentra en ambos archivos, lo cual provoca dos
inconvenientes: por un lado se desperdicia espacio ya que tal campo es demasiado grande y
la relación entre ambas archivos debería haberse dado a través de la clave del concepto, que
es un campo de menor tamaño. Por otro lado, el problema principal radica en que la
integridad de los datos puede verse en peligro si se decide cambiar DescConcepto del
archivo de conceptos, ya que en el archivo de pedidos ese campo se encuentra en varios
renglones, esto implica que habría que hacer la actualización en cada uno de ellos.

Num_Pedido Fecha DescConcepto
23455 13/01/92 Computadoras ATT
24879 17/01/92 Drives de 5 ¼ “
34488 20/01/92 Monitores de color
34488 20/01/92 Monitores de color
a) Archivo de pedidos
Clave_Concepto DescConcepto
23455 Computadoras ATT
24879 Drives de 5 ¼ “
34488 Monitores de color
b) Archivo de conceptos
FIGURA 1.7. Redundancia de información en los archivos.
El problema se amplía si se piensa en que existiesen otros archivos como facturas,
notas de crédito, recibidos, pólizas, etc., que tuviesen relación con el archivo de conceptos y
estuvieran representados de la misma forma.
Con el procesamiento de base de datos, es mínima la duplicación o redundancia de
datos. En una base de datos bien definida como la de la Figura 1.5, el problema de los
archivos anteriormente descritos simplemente no existiría, pues el campo DescConcepto se
almacenaría solo una vez, es decir, en un solo archivo. Siempre que el DBMS necesite estos
datos puede traerlos y solo es necesaria una operación para modificarlos. Debido a que
estos datos se almacenan en un sólo lugar, resultan menos comunes los problemas de
integridad de datos; hay menor oportunidad de discrepancias entre las múltiples copias de
los mismos elementos de datos.
Independencia programas/datos
El procesamiento de base de datos hace que los programas dependan menos de los
formatos de los archivos. Los formatos de registro se almacenan en la misma base de datos
(junto con los datos) y son accedidos por el DBMS, no por los programas de aplicación.
A diferencia de los programas de procesamiento de archivos, los programas de
aplicación de base de datos no necesitan incluir el formato de los registros y los archivos
que procesan.

Fácil representación de la vista de datos a los usuarios
La tecnología de base de datos hace posible representar de un modo directo a los
objetos en el universo del usuario. Por ejemplo, las formas como la de la Figura 1.4. pueden
producirse a partir de una base de datos, ya que están almacenadas en ella relaciones entre
los registros de los datos.
Una base de datos es autodescriptiva
Una base de datos es autodescriptiva: Además de los datos fuente del usuario contiene
también una descripción de su propia estructura. Tal descripción es conocida como
diccionario de datos (o directorio de datos o metadatos). El diccionario de datos vuelve
posible la independencia entre el programa y los datos.
En este sentido, una base de datos es similar a una biblioteca. Que es un conjunto
autodescriptivo de libros. Además de libros, la biblioteca contiene un catálogo de tarjetas
que los describen. En la misma forma, el diccionario de datos (que es parte de la base de
datos, tanto como el catálogo es parte de la biblioteca) describe los datos contenidos en la
base de datos.
¿Por qué es importante esta característica de autodescripción de una base de datos?.
Porque promueve la independencia programa/datos, hace posible determinar la estructura y
el contenido de la base de datos examinando la base de datos misma. No se requiere
adivinar que contiene la base de datos ni mantener documentación externa del archivo y los
formatos de registro, como se hace en los sistemas de procesamiento de archivos.
Si cambia la estructura de los datos en la base de datos (por ejemplo cambiar anchura
de campos o agregar más campos a un registro existente), solo se introduce el cambio al
diccionario de datos. Necesitan cambiarse pocos programas (sí tal es el caso).
En la mayoría de los casos, solo deben alterarse los programas que procesen los datos
modificados.
Una base de datos es un conjunto de registros integrados
La jerarquía normal de los datos es la siguiente: Los bits conforman bytes o
caracteres; los caracteres constituyen campos; los campos integran registros y los registros
componen archivos(véase Figura 1.8(a).). Es tentador seguir la tendencia precedente y
decir que los archivos conforman bases de datos. Aunque tal expresión es verdadera no va
muy lejos.

FIGURA 1.8. Jerarquía de los elementos: (a) Jerarquía de datos en el procesamiento
de archivos y (b) Jerarquía de elementos de datos en el procesamiento
de base de datos.
Una base de datos incluye archivos de datos del usuario y más. Como se mencionó,
una base de datos contiene una descripción de sí misma en los metadatos. Una base de
datos incluye índices que se usan para representar las relaciones entre los datos y para
mejorar el desempeño de las aplicaciones de la base de datos. La base de datos contiene a
veces información de las aplicaciones que la utilizan. La estructura de las formas de entrada
de datos o de un reporte es parte de la base de datos. La última categoría de datos
denominados metadatos de aplicación. Una base de datos contiene los cuatro tipos de
datos mostrados en la Figura 1.8(b): archivos de datos del usuario, metadatos, índices y
metadatos de aplicación.
ArchivosBits
Bytes
o
Caracteres
Campos Registros
a)
Bits
Bytes
o
Caracteres
Campos Registros
b)
Archivos
+
Metadatos
+
Índices
+
Metadatos
de
aplicación
.
Base de
datos

1.1.2.2. Componentes de una base de datos
La arquitectura de una base de datos es compleja y está compuesta por una gran
cantidad de elementos. Enseguida se analiza cada componente.
Hardware y software
A medida que el costo del hardware de las computadoras disminuye debido a las
nuevas tecnologías, los sistemas de computación se están desarrollando cada vez en mayor
número. Así, el hardware necesario para hacer frente a los grandes sistemas de computación
puede constituirse a un precio moderado.
El hardware se compone de dispositivos de almacenamiento secundario como discos
duros, cintas magnéticas, discos ópticos etc., donde reside la base de datos física, junto con
un dispositivo asociados como unidades de control.
Por lo que respecta al software, los sistemas de base de datos están compuestos por un
conjunto de programas. En el nivel más alto, se encuentra el DBMS que es un conjunto de
programas que manipulan estructuras de datos complejas para definir, manipular y consultar
los datos. El usuario no necesita preocuparse por la forma en la que el DBMS realiza sus
funciones y los programadores de aplicaciones deben conformar sus programas sobre la
base de un lenguaje de alto nivel que interacciones con el manejador de la base de datos.
Esto es, los programas se construyen atendiendo dos objetivos básicos: dar acceso a la base
de datos y crear una interfaz con el usuario, que se encargue de solicitar los datos que se
desean consultar, insertar o eliminar.
Los lenguajes con los que se construye la interfaz pueden ser de tercera o cuarta
generación y se les conoce como lenguajes anfitriones.
Dentro del primer grupo, se encuentran los lenguajes de propósito general; en ellos,
la estructura de los programas de aplicación debe construirse mediante programación
tradicional, es decir, deben crearse funciones para conformar el ambiente sobre el que debe
ejecutarse la aplicación, tales como ventanas, menús y capturas; así mismo deben validarse
los datos y los procesos y cuando se requiere, hacer uso de las funciones que proporciona el
DBMS. La programación de este tipo de sistemas es sumamente flexible, aunque
complicada de realizar. Un lenguaje de alto nivel de tercera generación del tipo de Pascal,
C, Modula2, APL, etc., no restringe ningún tipo de proceso y la interfaz puede programarse
de acuerdo al gusto más exigente del usuario.

Los lenguajes de cuarta generación para construcción de sistemas de información que
utilizan bases de datos, son de propósitos específico y contienen las funciones suficientes
para generar fácilmente una interfaz y ligar el diseño de pantalla de captura, menús y
reportes a la base de datos. Este tipo de lenguajes permiten realizar sistemas de manera
simple y eficaz, pero generalmente son inflexibles. El usuario debe saber que su sistema
desarrollado bajo un lenguaje de este tipo estará limitado a las capacidades de la
herramienta. Estas limitaciones no afectan los accesos a la base de datos, sino a la forma en
la que los programas de aplicación presentan, solicitan o reportan la información. Los
accesos a la base de datos también se llevan a cabo a través del DBMS, cuyas funciones se
encuentran inmersa en los programas de aplicación.
Lenguajes de bases de datos
En el mundo de las bases de datos es normal separar las funciones de computación en
dos partes y dos diferentes lenguajes. Esto es porque en un programa normal, las variables
de programa existen sólo mientras el programa está ejecutándose; en un sistema de bases de
datos, los datos existen siempre y pueden ser declarados una vez para todos los programas.
Esto da origen a los lenguajes de definición de datos y al de manipulación de datos.
Lenguaje de definición de datos (DDL)
Un esquema de la base de datos se especifica por medio de una serie de definiciones
que se expresan en un lenguaje especial llamado lenguaje de definición de datos (Data
Definition Language, DDL). El resultado de la compilación de las sentencias en el DDL es
un conjunto de tablas que se almacenan en un archivo especial llamado diccionario de
datos.
Un diccionario de datos es un archivo que contiene metadatos, es decir, datos acerca
de los datos. La estructura de almacenamiento y los métodos de acceso empleados por el
sistema de bases de datos se especifican por medio de un conjunto de definiciones de un
tipo especial de DDL llamado lenguaje de almacenamiento y definición de datos. El
resultado de la compilación de estas definiciones es una serie de instrucciones que
especifican los detalles de implantación de los esquemas de bases de datos que
normalmente no pueden ver los usuarios.

Lenguaje de manipulación de datos (DML)
Este lenguaje es utilizado para realizar las diferentes operaciones sobre la base de
datos sin que el usuario tenga que hacer complicados programas para ello y al mismo
tiempo saber detalles físicos a cerca de los datos. La manipulación que se hace con este
lenguaje consiste en lo siguiente:
 Recuperación de información almacenada en la base de datos.
 Inserción de información nueva en la base de datos.
 Modificación y eliminación de información de la base de datos.
Lo importante que debe cumplir este lenguaje es la facilidad de uso. El objetivo es
lograr una interacción eficiente entre los usuarios y el sistema.
Un lenguaje de manipulación de datos (Data Manipulation Language, DML) permite
a los usuarios manejar o tener acceso a los datos que estén expresados por medio del
modelo apropiado. Existen básicamente dos tipos de DML:
 Procedimental
Necesita que el usuario especifique cuáles datos quiere y cómo deben obtenerse.
 No procedimental
Requiere que el usuario especifique solamente cuáles datos quiere.
Una consulta es una sentencia que solicita la recuperación de información. La parte de
un DML que realiza esta labor se llama lenguaje de consultas.
Manejador de base de datos (DBMS)
El manejador de base de datos es un módulo de programas que constituye la interfaz
entre los datos de bajo nivel almacenados, los programas de aplicaciones y las consultas
hechas al sistema. El manejador de base de datos es responsable de las siguientes tareas:
 Interacción con el manejador de archivos.
 Implantación de la integridad.
 Puesta en práctica de la seguridad.
 Respaldo y recuperación.
 Control de concurrencia.

Usuarios
En un sistema de bases de datos existe una gran diversidad de usuarios, cada uno,
tiene necesidades específicas y visualiza el sistema de manera distinta. Enseguida se da un
perfil de cada uno de ellos.
Usuarios de programas de aplicación
El primer tipo de usuario de un sistema es el que utiliza los servicios para los que fue
realizado, es decir, un sistema resuelve problemas concretos a través de la ejecución de
programas.
FIGURA 1.9. Los usuarios de aplicaciones de bases de datos no necesitan saber
datos técnicos acerca de esta y tampoco que manejen algún
lenguaje de programación.
Estos usuarios no están obligados más que a tener conocimiento sobre la forma de uso
del programa y los resultados que éste genera, también tienen acceso limitado a la
información de la base de datos y están sujetos sólo a lo que la aplicación les proporcione.
Voy a accesar al
sistema de
contabilidad...

Programadores de aplicación
Estos usuarios construyen los programas de aplicación, que están compuestos de las
instrucciones necesarias para poder acceder a la base de datos. Estos programas en
conjunto, realizan una función específica del sistema de computación de la organización en
donde se ubican y están escritos en lenguajes de alto nivel, los cuales pueden ser de dos
tipos: lenguajes de 3a. generación (3GL) o de 4a generación (4GL) (aunque últimamente se
les está abriendo paso a los de 5ª generación).
Los primeros son lenguajes de propósito general, como C, Pascal, FORTRAN,
COBOL, y otros. Los segundos son lenguajes especializados para la construcción de
interfaces para sistemas de información y manipulación de datos a través de lenguajes de
bases de datos como SQL, QUEL, etc.
FIGURA 1.10. Los programadores de aplicaciones de bases de datos son los que
diseñan las aplicaciones que utilizarán usuarios como el de la
Figura 1.9. Es necesario que conozcan datos técnicos acerca de la
base de datos y que manejen lenguajes de programación.
Usuarios que utilizan los lenguajes de manipulación de información
En diversos sistemas, existen usuarios que no pueden esperar a que los programadores
de aplicación construyan los programas que producirán la información que necesitan; estos
usuarios son inquietos y por lo regular tienen gran iniciativa, por ello, no les importa
aprender los lenguajes de manipulación para poder acceder directamente a la base de datos
y ala información que necesitan.
SELECT
a.nomcia, a.rfccia
FROM
tacias a
WHERE
a.idcia = :fidcia;
COMMIT;

Administrador de la base de datos (DBA)
El administrador de la base de datos (Database Administrator DBA), es un usuario (o
usuarios) que realiza el control centralizado tanto de los datos como de los programas. Es
muy necesario que este conozca todo lo referente a la base de datos, desde los metadatos
hasta los lenguajes de consulta que esta base de datos soporte.
FIGURA 1.11. El administrador de la base de datos (DBA) debe
proporcionar múltiples servicios a todos los usuarios de la
misma, es decir, a los usuarios anteriormente descritos.
Las funciones del administrador de la base de datos son las siguientes:
 Definición del esquema de la B.D.
 Creación original en la descripción de la estructura de la base de datos y la forma en que
la estructura es reflejada por los archivos de la base de datos física.
 Asigna del acceso a la base de datos; da la información o parte de ella a los usuarios.
 Modificación de la descripción de la base de datos y reparación de daños por fallas de
hardware o software.
 Especificación de las limitantes de integridad.

1.1.2.3. Arquitectura de un sistema de bases de datos
Un sistema de base de datos se divide en módulos que se encargan de cada una de las
tareas del sistema general. Algunas de las funciones del sistema de base de datos pueden ser
realizadas por el sistema operativo.
En la mayoría de los casos, el sistema operativo proporciona sólo los servicios más
elementales y la base de datos debe partir de ese fundamento. Así, el diseño de la base de
datos debe incluir la consideración de la interfaz entre el sistema de base y el sistema
operativo.
Un sistema de base de datos se divide en varios componentes funcionales, entre los que
se cuentan los siguientes.
 Manejador de archivos
 Manejador de base de datos
 Procesador de consultas
 Precompilador de DML
 Compilador de DDL
Además, se requieren varias estructuras de datos como parte de la implantación del
sistema físico, tales como:
 Archivos de datos
 Diccionario de datos
 Índices

Usuarios de las
aplicaciones
Programadores de
las aplicaciones
Usuarios
Casuales
Administrador de
la base de datos
Precompilador de
lenguaje de manejo
de datos
Procesador de
consultas
Precompilador de
lenguaje de
definición de datos
Manejador de base
de datos
Manejador de
archivos
Consulta
Código objeto de
los programas de
aplicación
Archivos
de datos
Almacenamiento en
disco
DBMS
La Figura 1.12 muestra los componentes de un sistema de base de datos y las
conexiones entre ellos.
FIGURA 1.12. Estructura del sistema de base de datos
Código fuente de
los programas de
aplicación
Programas
de aplicación
Esquema
de la base
de datos
Diccionario
de datos

1.2 Tipos de bases de datos
Los tipos de bases de datos más comúnmente utilizados son bases de datos
fundamentadas en la distribución de sus datos a través de registros (similar a los registros
de archivos).
 Base de datos tipo relacional
 Base de datos tipo red
 Base de datos tipo jerárquico
Enseguida se bosquejan cada uno de ellos.
Base de datos tipo relacional
Los datos y las relaciones entre ellos se representan por medio de tablas, cada una de
las cuales tienen varias columnas con nombres únicos. Este será uno de los temas
fundamentales de este curso debido a que alrededor de este modelo están basados la
mayoría de los DBMS.
Base de datos tipo red
Los datos en este modelo se representan por medio de registro (en el sentido que la
palabra tiene en Pascal o PL/1) y las relaciones entre los datos se establecen por medio de
ligas, que pueden considerarse como apuntadores.
Los registros de la base de datos se organizan en forma de conjuntos de gráficas
arbitrarias. La Figura 1.13 muestra un ejemplo de este modelo, estableciendo la relación
entre alumnos y grupos en un sistema de control escolar.
FIGURA 1.13. Ejemplo de una base de datos de red.
81315 José Luís Martínez
83534 Alberto López
85555 Beatriz Álvarez
87221 Mario Martínez
CA-10 Matutino
CB-09 Matutino
CF-07 Vespertino

Base de datos tipo jerárquico
El modelo jerárquico es similar al de red en cuanto a que los datos y las asociaciones
se representan por medio de registros, y ligas, respectivamente.
Sin embargo, el modelo jerárquico difiere del de red en que los registros están
organizados como árboles y no como gráficas arbitrarias. En la Figura 1.14 se muestra un
ejemplo de este modelo.
FIGURA 1.14. Ejemplo de una base de datos jerárquica.
Las bases de datos en red y jerárquicas son bastante eficientes al momento de extraer
de ellas la información, más, sin embargo, también tiene sus desventajas. La estructura de
estas resulta ser muy rígida. Las relaciones de conjunto y la estructura de los registros tiene
que ser especificadas de antemano. El modificar la estructura de la base de datos requiere
típicamente la reconstrucción de la base de datos completa.
Estas bases de datos son herramientas específicas para programadores, pues es muy
difícil que un usuario común extraiga información de ellas por la estructura compleja que
estas guardan. Aun así un programador experto muchas veces tiene que escribir un
programa que recorra el camino complicado hacia los datos solicitados a través de estas
bases de datos. La anotación de las peticiones para informes a medida dura con frecuencia
semanas o meses, y para el momento en que el programa está escrito la información con
frecuencia ya no merece la pena. Estos dos tipos de bases de datos son muy poco utilizados
hoy en día, pues han sido suplantadas exitosamente por las bases de datos relacionales.
CA-10 Matutino
CB-09 Matutino
CF-07 Vespertino
Alumnos
CA-10 MatutinoCB-09 Matutino

1.3 Confusiones acerca de las Bases de Datos
En 1979 una pequeña compañía llamada Ashton-Tate introdujo un producto para
microcomputadoras llamado dBase II y lo denominó un DBMS relacional. En una táctica
promocional muy exitosa, Ashton-Tate distribuyó casi gratis más de cien mil copias de su
producto a compradores de las nuevas microcomputadoras Osborne. Muchas de las
personas que compraron estas computadoras fueron pioneros en la industria de las
microcomputadoras. Empezaron a inventar aplicaciones de microcomputadora usando
dBase y el número de aplicaciones de dBase creció con rapidez. Ashton-Tate se volvió una
de las primeras grandes corporaciones en la industria de las microcomputadoras, después
fue comprada por Borland, que ahora vende la línea de productos dBase.
Sin embargo, el éxito de este producto confundió y embrolló el tema del
procesamiento a través de bases de datos. El problema era el siguiente: de acuerdo con la
definición de base de datos relacional, dBase II no era ni DBMS ni relacional (aunque era
comercializado como sí fuera ambos). De hecho era un lenguaje de programación con
capacidades generalizadas de procesamiento de archivos (no de procesamiento de base de
datos). Los sistemas que se desarrollaron con dBase II se parecían más a los mostrados en la
Figura 1.2 que a los mostrados en la Figura 1.5. Alrededor de un millón de usuarios de
dBase II creían que estaban usando un DBMS relacional cuando en realidad no era así.
Los términos sistema de administración de base de datos y base de datos relacional
se usaron de manera vaga en el inicio del auge de las microcomputadoras. La mayor parte
de las personas que procesaban una base de datos en microcomputadoras lo que hacían era
trabajar con archivos y no aprovechaban el procesamiento de una base de datos, aunque no
se dieran cuenta.
Aunque hoy existen supuestas nuevas versiones mejoradas de dBase y otras
herramientas como FoxPro, Paradox, Revelation, Clipper y Access por nombrar algunas, la
verdad es que todavía distan mucho de ser verdaderos DBMS. Debido a esto, los
vendedores de reales DBMS relacionales como Oracle, Focus e Ingres han trasladado sus
productos de macro y minicomputadoras a microcomputadoras con un éxito rotundo, a tal
grado de incorporar sus propios lenguajes 4GL y 5GL como herramientas de desarrollo de
sus propias bases de datos.
Advertencia: las hojas de cálculo no son bases de datos
Antes de concluir este tema, es importante aclarar el concepto falso acerca del término base
de datos. La mayor parte de las hojas de cálculo populares como Lotus 1-2-3, Excel y
Quatro Pro contienen características y funciones que han sido denominadas de bases de
datos, emplean este término en forma muy imprecisa, en desacorde con la realidad. Una
hoja de cálculo solo tiene una pequeña parte de la funcionalidad que se espera de una base
de datos y de un DBMS, y para terminar rápido con el comentario, simple y sencillamente
violan casi todas (sino es que todas) las características de una verdadera base de datos.

2-Fundamentos de bases de datos relacionales
El diseño de una base de datos no es una cosa fácil.
El crear adecuadamente entidades con sus
relaciones, reglas que cuiden la integridad y todo
aquello que respete y asuma los líneamientos de una
base de datos y que permita su permanencia en el
tiempo, implica un verdadero esfuerzo de muchas
horas que solo la gente con experiencia en el ramo
lo puede hacer. Es por eso que hoy cualquier
profesional de esta área tendrá siempre las puertas
abiertas en cualquier organización que se dedique
al desarrollo del buen software.
Dave M- Kroenke, asesor externo de sistemas, y
catedrático de UCLA. Abril de 1993.

BASES DE DATOS RELACIONALES Fundamentos de Bases de Datos Relacionales
2.1. Diseño de bases de datos relacionales
Las desventajas de los modelos jerárquicos y en red condujeron a un intenso interés
en el nuevo modelo2
de datos relacional cuando fue escrito por primera vez por el Dr. Codd
en 1970. El modelo de datos relacional simplifica la estructura de la base de datos. Elimina
las estructuras explícitas padre/hijo que contienen las bases de datos jerárquicas y en red, y
en su lugar representa todos los datos en la base de datos como sencillas tablas fila/columna
de valores de datos. La Figura 2.1 muestra una versión relacional de la base de datos en red
y jerárquica de las Figuras 1.13 y 1.14.
FIGURA 2.1. Ejemplo de una base de datos relacional.
El Dr. Codd escribió un artículo en 1985 estableciendo doce reglas a seguir por cualquier
base de datos que se llamara “verdaderamente relacional”. Las doce reglas de Codd han
sido aceptadas desde entonces como la definición de un DBMS verdaderamente relacional.
Sin embargo, es más fácil comenzar con una definición más informal.
Una base de datos relacional es una base de datos en donde todos los datos visibles al usuario están
organizados estrictamente como tablas de valores, y en donde todas las operaciones de la base de datos operan
sobre esas tablas.
Tal vez en este momento parezca un poco complejo la manera en que los datos han
sido distribuidos en la base de datos relacional de la Figura 2.1, porque realmente esta base
de datos no está debidamente diseñada, sin embargo, esta confusión quedará disuelta al
introducirnos en el tema Diagramas de Entidades y Asociaciones que es propio de las bases
de datos relacionales.
2
A los tipos de bases de datos también se les conoce como modelos de datos.
Tabla ALUMNOS
CONTROL NOMBRE
Tabla GRUPOS
GRUPO TURNO
CA-10 Matutino
CB-09 Matutino
CF-07 Vespertino

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

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.

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

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
?

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.

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.

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

Nombre_Entidad
Key Data
atributo1 [PK1]
atributo2 [PK2]
Non-Key Data
atributo3
o
o
o
atributoN
Volume
min. #####
max. #####
Tabla Ingres
Nombre_Tabla_Físico
FIGURA 2.6. Cuerpo de una Entidad como diagrama de estructura de datos.
Los elementos que componen a esta entidad son los siguientes:
Nombre_Entidad: Se refiere al nombre lógico que tendrá la entidad, está deberá coincidir con
el nombre del Almacén del DFD.
atributo1
atributo2
atributo3
.
.
.
atributoN
Se refiere al nombre de cada uno de los atributos (campos de la tabla ya en
la Base de Datos) que componen la entidad, donde los que se encuentran
en la zona “Key Data” son atributos llave.
min. ####
max. ####
Se refiere al mínimo y máximo de registros que guardará la entidad ya
como tabla física.
Nombre_Tabla_Físico Es el nombre físico de la tabla en la Base de Datos
TABLA 2.2. Elementos que componen una Entidad como diagrama de estructura de datos.
Además, estos DEA que se utilizarán son DEA en donde sólo se tienen asociaciones
binarias y son descritas a través de una línea que une a dos conjuntos de entidades
indicando la cardinalidad de la asociación igual que el diagrama clásico, con una notación
de pata de gallo.
Los DEA sólo contendrán asociaciones de 1:N o bien de 1:1, pero nunca de N:N. Los
conjuntos de entidades tendrán un nombre, una descripción un conjunto de atributos que la
compone, indicaciones sobre estos atributos en cuanto a cuales son atributos llave y cual no
lo son, número mínimo promedio y máximo de entidades esperadas, nombre de la tabla del
DBSM a la que corresponderá en la implantación (etapa de diseño y programación).
Además las asociaciones son sustituidas por diagramas de estructuras de datos, es
decir, por entidades nuevas cuyo nombre es el de la propia asociación.

DEA del Sistema Bibliotecario
Préstamos
Key Data
Matrícula [PK1]
Número_Adquisición [PK2]
Non-Key Data
Fecha
Volume
Min. 1
Max. 1000000
Tabla Ingres
TaPrestamo
Libros
Key Data
Numero_Adquisición [PK1]
Non-Key Data
Título
Autor
Colocación
Tema
Editorial
Páginas
País
Volume
Min. 1
Max. 10000
Tabla Ingres
TaLibro
Usuarios
Key Data
Matrícula [PK1]
Non-Key Data
Nombre
Dirección
Colonia
Ciudad
Volume
Min. 1
Max. 10000
Tabla Ingres
TaUsuario
Debe existir en
Puede tener
Para ejemplificar, se diseña en la figura de abajo el mismo DEA de la Figura 2.5 pero
ahora utilizando el estilo de la Figura 1.3.6, sustituyendo las cajas y óvalos por los
diagramas de estructura de datos:
FIGURA 2.7. DEA del Sistema bibliotecario.
Como se observa en la Figura 2.7, la asociación Préstamos de la figura 2.5 es
sustituida por una entidad del mismo nombre cuyos atributos son los atributos llave de las
entidades relacionadas (Matrícula y Número_Adquisición) y el atributo fecha que es propio
de la asociación.
Las asociaciones sólo tendrán un nombre y reglas de integridad. Los atributos se
documentarán con un identificador, el cual está compuesto por un prefijo que indicará la
naturaleza del atributo y un sufijo que indicará la entidad con la cual se le relaciona. A
continuación se dan algunos ejemplos en las dos tablas siguientes:
TABLAS 2.3. Ejemplos de prefijos y sufijos para nombrar atributos.
Prefijo Significado
Id Identificador numérico que no lleva una secuencia
Num Identificador numérico que lleva una secuencia
Ce Clave identificador alfanumérico
Do Saldo
SdoIni Saldo inicial
Nom Nombre
Desc Descripción
Stat Estado lógico
Sufijo Significado
Pol Póliza
Emp Empleado
Oper Operación
Fact Factura

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

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

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

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.

Tabla: TaPrestamo
relacionadas
Restricciones
- Inserción TaLibro
TaUsuario
Existencia.
Existencia.
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.

Tabla: TaUsuario
relacionadas
Restricciones
- Inserción Ninguna Ninguna
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

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

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.

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:

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

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

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

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.

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

Introducción a las bases de datos relacionales

Introducción a las bases de datos relacionales

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (15)

Andere mochten auch

Andere mochten auch (12)

Ähnlich wie Introducción a las bases de datos relacionales

Ähnlich wie Introducción a las bases de datos relacionales (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (11)

Introducción a las bases de datos relacionales