Bases de Datos I-97

1
BASES DE DATOS I
UNIDAD I. INTRODUCCION A LOS CONCEPTOS DE BASE DE DATOS
DEFINICION DE BASES DE DATOS
Una base de datos es un conjunto autodescriptivo de registros integrados.
Una base de datos es autodescriptiva: porque 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).
La autodescripción de una base de datos es importante porque promueve la independencia entre el programa y los
datos, ya que hace posible determinar la estructura y el contenido de la base de datos examinando la misma.
Si cambia la estructura de los datos en la base de datos (por ejemplo agregar un campo), solo se introduce
el cambio al diccionario de datos.
JERARQUIA DE LOS DATOS
La jerarquía normal de los datos es: los bits conforman bytes o caracteres; los caracteres constituyen campos; los
campos integran registros y los registros componen archivos.
Una base de datos incluye archivos de datos del usuario y más. Como se menciona 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 la base de datos. La base de datos
contiene a veces la información de las aplicaciones que las utilizan. La ultima categoría de los datos se denomina
metadatos de aplicación.
Bits Bytes o caracteres Campos Registros Archivos.
Una base de datos contiene los siguientes tipos de datos:
a) Archivos de datos del usuario.

b) Metadatos
c) Índices
d) Metadatos de aplicación
Archivos Base de Datos

+
Metadatos
+
Índices
+
Metadatos de
aplicación
1.2. OBJETIVOS DE LOS SISTEMAS DE BASES DE DATOS
De los sistemas tradicionales de Archivos a las Bases de Datos.
Los sistemas informáticos tradicionales han sido llamados sistemas orientados hacia proceso, debido a que en ellos
se pone énfasis en los tratamientos que reciben los datos, los cuales se almacenan en archivos diseñados para una
determinada aplicación. Las aplicaciones se analizan e implantan con entera independencia unas de otras, y los
datos no se suelen transferir entre ellas, sino que se duplican siempre que los trabajos correspondientes los
necesitan.
Por lo cual, además de ocupación inútil de memoria secundaria, un aumento de los tiempos de proceso, al
repetirse los mismos controles y operaciones en los distintos archivos. Pero más grave son las inconsistencias que a
2
menudo se presentan en estos sistemas, debido a que la actualización de los mismos datos, cuando se encuentran
en mas de un archivo, no se suele realizar de forma simultanea en todos los archivos.
Por otra parte, la dependencia de los datos respecto al soporte físico y a los programas de lugar a una falta de
flexibilidad y de adaptabilidad frente a los cambios que repercute muy negativamente en el rendimiento de conjunto
del sistema informático.
De esto, se puede deducir claramente la necesidad de una gestión más racional del conjunto de datos,
surgiendo así un nuevo enfoque que se apoya sobre una base de datos en la cual los datos son recogidos y
almacenados una sola vez, con independencia de los tratamientos.
Por lo tanto, se ve la solución de los problemas asociados al tratamiento de los datos en los sistemas
tradicionales lleva a un cambio en el enfoque del sistema de información, en el cual los datos se organizan y
mantienen en un conjunto estructurado que no esta diseñado para una aplicación concreta, sino que, por el
contrario, tiende a satisfacer las necesidades de información de toda la organización.
Estos sistemas orientados hacia los datos van sustituyendo a los sistemas orientados al proceso, que por poca
fiabilidad, falta de adecuación a la realidad y mal asegurada confidencialidad han ido perdiendo la confianza de los
usuarios.
a) Ventajas de las Bases de Datos Frente a los Archivos Clásicos.
Las bases de datos, surgidas como respuesta al nuevo planteamiento de los sistemas orientados hacia los datos,
para mejorar la calidad de las prestaciones de los sistemas informáticos y aumentar su rendimiento, presentan una
multitud de ventajas frente a los sistemas clásicos de archivos.
Las ventajas son:
b) Independencia de los datos respecto a los tratamientos y viceversa.
La mutua independencia de los datos y tratamiento lleva a que un cambio de estos últimos no imponga un
nuevo diseño lógico y/o físico de la base de datos. Por otra parte, la inclusión de nuevas informaciones, desaparición
de otras, cambios en la estructura física o en los cambios de acceso, no deben obligar a alterar los programas. Esta
independencia de los tratamientos frente a la estructura de la base de datos, supone una considerable ventaja, al
evitar esfuerzo que origina la reprogramación de las aplicaciones cuando se producen cambios en los datos.
La flexibilidad que proporciona la independencia de los datos y programas es muy importante para conseguir
sin excesivos costos la continua adaptación del sistema de información a la evolución de las organizaciones.
c) Coherencia de los Resultados
Debido a que la base de datos se recoge y almacena una sola vez, en todos los tratamientos se utilizan los
mismos datos, por lo que los resultados de todos ellos son coherentes y perfectamente comparable.
Además, al no existir la redundancia en los datos, desaparece el problema que se presentaba en el enfoque
clásico, de que el cambio de un dato obligaba a actualizar una serie de archivos. De esta forma se elimina también el
inconveniente de las divergencias en los resultados debidas a actualizaciones no simultáneas en todos los archivos.
d) Mejor disponibilidad de los datos para el conjunto de los usuarios.
Cuando se aplica la metodología de base de datos, cada usuario ya no es propietario de los datos, puesto que
estos se comparten entre el conjunto de aplicaciones, existiendo una mejor disponibilidad de los datos para todos los
que tienen necesidad de ellos, siempre que estén autorizados para su acceso.
Hay también una mayor transparencia respecto a la información existente, que todos los datos que se
encuentran en la base de datos se deben relacionar en un catalogo o diccionario, que puede ser ampliamente
difundido y accedido por medios informáticos.
3
e) Mayor Valor Informativo

Puesto que la base de datos en un sistema reflejo del mundo real, donde los distintos elementos están
interrelacionados, el valor informativo de su conjunto es superior a la suma del valor informativo de los elementos
individuales que los constituyen.
f) Mejor y más normalizada documentación de la información, la cual esta integrada con los
datos.
En el enfoque clásico los datos se encuentran separados de su contenido semántico, los primeros se
almacenan en los archivos y su descripción se hace mediante un lenguaje de programación. La documentación de
los datos, realizada por el analista o programador, es en general insuficiente y a veces incluso inexistente.
g) Mayor eficiencia en la recolección, validación y entrada de los datos al sistema
Al no existir apenas redundancias, los datos se recogen y validan una sola vez, aumentando así el rendimiento
de todo el proceso previo al almacenamiento.
h) Reducción del espacio de almacenamiento
La desaparición de las redundancias, así como la aplicación de técnicas de comparación, lleva en los sistemas
de base de datos a una menor ocupación de almacenamiento secundario.
Mantener información de la organización en un sistema de procesamiento de archivos tiene una serie de

inconvenientes. Los propósitos de los sistemas de bases de datos son eliminar los siguientes inconvenientes:
 Redundancia e inconsistencia de datos.- Debido a que los archivos de aplicación son creados por
diferentes programadores en un largo periodo de tiempo, los diversos archivos tienen probablemente diferentes
formatos y los programas pueden estar escritos en diferentes lenguajes. Mas aun la información puede estar
duplicada en diferentes archivos.
 Dificultad en el acceso a los datos.- Supóngase que uno de los empleados de un banco necesita
averiguar los nombres de todos los clientes que viven en el distrito postal 28733 de la ciudad. El empleado pide
al departamento del procesamiento de datos que genere dicha lista. Debido a que esta petición no fue prevista
cuando el sistema original fue diseñado, no hay un programa de aplicación a mano para satisfacerla. Hay, sin
embargo, un programa de aplicación que genera la lista de todos los clientes. El empleado del banco tiene 2
opciones: bien obtener la lista de todos los clientes y obtener la información que necesita manualmente, o bien
pedir al departamento de procesamiento de datos que haga que un programador de sistemas escriba el
programa de aplicación necesario.
 Aislamiento de datos.- Debido a que los datos están dispersos en varios archivos, y los archivos pueden
estar en diferentes formatos, es difícil escribir nuevos programas de aplicación para recuperar los datos
apropiados.
 Problemas de integridad.- Los valores de los datos almacenados en la base de datos deben satisfacer
ciertos tipos de ligaduras de consistencia. Por ejemplo, el saldo de una cuenta bancario no debe ser menor de
cierta cantidad. Los desarrolladores hacen cumplir esas ligaduras en el sistema añadiendo el código apropiado
en los diversos programas de aplicación. Sin embargo, cuando añaden nuevas ligaduras, es difícil cambiar los
programas para hacer que se cumplan. El problema es complicado cuando las ligaduras implican diferentes
elementos de datos de diferentes archivos.
 Problemas de Atomicidad.- Un sistema de una computadora, como cualquier otro dispositivo mecánico o
eléctrico, esta sujeto a fallo. En muchas aplicaciones es crucial asegurar que una vez que un fallo ha ocurrido y
se ha detectado, los datos se restauran al estado de consistencia que existía antes del fallo.
4
 Anomalías en el acceso concurrente.- Conforme se han ido mejorando el conjunto de ejecución de los
sistemas y ha sido posible una respuesta en tiempo más rápida, muchos sistemas han ido permitiendo a
múltiples usuarios actualizar los datos simultáneamente. En tales sistemas un entorno de interacción de
actualizaciones concurrentes puede dar lugar a datos inconsistentes.
 Problemas de seguridad.- No todos los usuarios de un sistema de base de datos deberían poder acceder
a todos los datos. Por ejemplo en un sistema bancario, el personal de nomina a necesita ver solo esa parte de la
base de datos que tiene información acerca de varios empleados del banco. No necesitan acceder a la
información acerca de las cuentas de los clientes.
1.3 . ABSTRACCION DE LA INFORMACION
Para que un sistema sea útil, debe recuperar los datos eficientemente. Esto ha conducido al diseño de estructura de
datos complejas para la representación de los datos en la base de datos. Como muchos usuarios de base de datos
no están familiarizados con computadoras, los desarrolladores esconden la complejidad a los usuarios a través de
varios niveles de abstracción para simplificar la interacción de los usuarios con el sistema:
Nivel Físico.- El nivel mas bajo de abstracción describe como se almacenan realmente los datos. El nivel físico se
describen en detalle las estructuras de datos complejas de bajo nivel.
Nivel Lógico.- El siguiente nivel mas alto de abstracción describe que datos se almacenan en la base de datos y que
relaciones existen entre esos datos. La base de datos completa se describe así en términos de numero pequeño de
estructuras relativamente simples. Aunque la implementación de estructuras simples en el nivel lógico puede
involucrar estructuras complejas del nivel físico, los usuarios del nivel lógico no necesitan preocuparse de esta
complejidad. Los administradores de base de datos, que deben decidir la información que se mantiene en la base de
datos, usan el nivel lógico de abstracción.
Nivel de Vistas.- El nivel mas alto de abstracción describe solo parte de la base de datos completa. A pesar del uso
de estructuras más simples en el nivel lógico, queda algo de complejidad, debido al gran tamaño de la base de datos.
A muchos usuarios del sistema de base de datos nos les preocupará toda esa información. En su lugar solo
necesitan acceder solo una parte de la base de datos. Para que su interacción con el sistema se simplifique, se
define la abstracción del nivel de vistas. Dicho sistema puede proporcionar muchas vistas para la misma base de
datos.
Niveles de Abstracción
Vista 1 Vista 2 ... Vista n
Nivel Lógico
Nivel Físico
1.4 MODELOS DE DATOS
La parte esencial de la estructura de base de datos es el modelo de datos. Una colección de herramientas
conceptuales para describir los datos, las relaciones de datos, la semántica de los datos y las ligaduras de
consistencia.
5
El modelado de datos es el proceso que implica crear una representación de la visión que tienen los usuarios
de los datos. Es la tarea más importante en el desarrollo de eficaces aplicaciones de base de datos. Si el modelo de
datos representa en forma incorrecta la visión que poseen los usuarios de los datos, encontraran las aplicaciones
difíciles de usar, incompletas y por supuesto frustrantes.
Los diferentes modelos de datos que se han propuesto se clasifican tres grupos diferentes: modelos lógicos
basados en objetos, modelos lógicos basados en registros y modelos físicos.
MODELOS LOGICOS BASADOS EN OBJETOS
Los modelos lógicos basados en objetos se usan para describir datos en los niveles lógico y de vistas. Se
caracterizan por el hecho de que proporcionan capacidades estructurales muy flexibles y permiten que las ligaduras
de datos sean especificadas explícitamente. Varios de los mas ampliamente conocidos son:
a) Modelo Entidad-Relación.
b) Modelo Orientado a Objetos.
c) Modelo de datos semántico
d) Modelo de datos funcional.
MODELOS LOGICOS BASADOS EN REGISTROS
Estos modelos se usan para describir datos en los niveles lógico y de vistas. En contraste con los modelos de datos
basados en objetos, se usan tanto para especificar la estructura lógica completa de la base de datos como para
proporcionar una descripción de alto nivel de la implementación.
Los modelos basados en registros se llaman así debido a que la base de datos se estructura en registros de
formato fijo de diferentes tipos. En cada tipo de registro se define un numero fijo de campos o atributos, y cada
campo tiene normalmente una longitud física.
Los tres modelos basados en registros mas ampliamente conocidos son:
a) Modelo Relacional
b) Modelo de Red
c) Modelo Jerárquico
Diferencia entre los modelos
El modelo relacional se diferencia de los modelos de redes y jerárquico en que no usa punteros o enlaces. En su
lugar, el modelo relacional relaciona registros mediante los valores que ellos contienen. Esta liberación del uso de
punteros permite que se defina mediante un fundamento matemático formal.
MODELO DE DATOS FISICO
Este modelo se usa para describir datos en un nivel mas bajo. En contraste con el modelo de datos lógico, hay pocos
modelos de datos físicos en uso. Dos de los mas conocidos son el modelo de unificación y el modelo de memoria por
marcos.
1.5 INSTANCIA Y ESQUEMAS

Las bases de datos van combinando a lo largo del tiempo conforme la información se inserta y borra. La colección de
información almacenada en la base de datos en un momento particular se llama una instancia de la base de datos.
El diseño completo de la base de datos se llama esquema de la base de datos. Los esquemas son raramente
modificados.
Un esquema de base de datos corresponde a una definición de tipo en un lenguaje de programación. Una
variable de un tipo dado tiene un valor particular en un instante de tiempo. Así el valor de una variable en lenguajes
de programación corresponde a una instancia de un esquema de la base de datos.
6
Los sistemas de bases de datos tienen varios esquemas divididos, de acuerdo al nivel de abstracción. En el
nivel mas bajo esta el esquema físico; en el nivel intermedio esta el esquema lógico, y el nivel más alto es el
subesquema.
1.6 INDEPENDENCIA DE LOS DATOS

La capacidad para modificar una definición de esquema en un nivel sin que afecte a una definición de esquema en el
siguiente nivel mas alto se llama independencia de datos. Hay dos niveles de independencia de datos:
1. Independencia física de datos.- Es la capacidad para modificar el esquema físico sin provocar que los
programas de aplicación tengan que rescribirse. Las modificaciones en el nivel físico son ocasionalmente
necesarias para mejorar el funcionamiento.
2. Independencia lógica de datos.- Es la capacidad para modificar el esquema lógico sin causar que los
programas de aplicación tengan que rescribirse. Las modificaciones en el nivel lógico son necesarias siempre
que la estructura lógica de la base de datos se altere.
La independencia de datos lógica es más difícil de proporcionar que la independencia física, ya que los
programas de aplicación son frecuentemente dependientes de la estructura lógica de los datos a los que ellos
acceden.
El concepto de independencia de datos es similar en muchos aspectos al concepto de tipos abstractos de datos
en los lenguajes de programación modernos. Ambos esconden los detalles de implementación a los usuarios para
permitirles concentrarse en la estructura general, mas que en los detalles de implementación de nivel mas bajo.
LENGUAJES DE BASES DE DATOS
Un sistema de base de datos proporciona dos tipos de lenguajes diferentes: uno para especificar el esquema de
base de datos y el otro para expresar las consultas y actualizaciones de la base de datos.
1.7 LENGUAJE DE DEFINICION DE DATOS
Un esquema de base de datos se especifica mediante un conjunto de definiciones expresadas mediante un lenguaje
especial llamado lenguaje de definición de datos (LDD). El resultado de la compilación de las estructuras del LDD es
un conjunto de tablas que se almacenan en un archivo especial llamado diccionario de datos o directorio de datos.
Este archivo se consulta antes de leer o modificar los datos reales del sistema de base de datos.
La estructura de almacenamiento y los métodos de acceso usados por el sistema de base de datos se
especifican mediante un conjunto de definiciones en un tipo especial de LDD llamado un lenguaje de
almacenamiento y definición de datos. El resultado de la compilación de estas definiciones es un conjunto de
instrucciones para especificar los detalles de implementación de los esquemas de la base de datos.
1.8 LENGUAJES DE MANIPULACION DE DATOS
Por manipulación de datos se quiere decir:
 La recuperación de información almacenada en la base de datos.

 La inserción de información nueva en la base de datos.
 El borrado de información.
 La modificación de información almacenada en la base de datos.
En el nivel físico se deben definir algoritmos que permitan un acceso eficiente a los datos. En los niveles mas
altos de abstracción se enfatiza la facilidad de uso.
Un Lenguaje de Manipulación de datos (LMD) es un lenguaje que permite a los usuarios acceder a manipular
los datos organizados mediante el modelo de datos apropiado. Existen dos tipos de LMD:
 LMD Procedimentales.- Requieren que el usuario especifique que datos se necesitan y como obtener esos
datos.
 LMD NO Procedimentales.- Requieren que el usuario especifique qué datos se necesitan, sin especificar
como obtener esos datos.
7
Los LMD no procedimentales son más fáciles de aprender y usar que los LMD procedimentales. Sin embargo,
como el usuario no especifica como conseguir esos datos, estos lenguajes pueden generar código que no sea tan
eficiente como el que generan los lenguajes procedimentales.
1.9 MANEJADOR DE BASE DE DATOS
Evolución de los Sistemas Manejadores de Base de Datos
A principio de la década de los sesentas, el punto más importante fue la introducción por parte de CODASYL
(Conference on Data Systems Languages) del compilador COBOL, acompañado por la evolución de unidades de
almacenamiento en cinta y la aparición subsecuente de los dispositivos de almacenamiento de acceso directo. Al
surgir las necesidades de aplicaciones más complejas se observo la necesidad de agregar al compilador de COBOL
paquetes que facilitaran el ordenamiento y clasificación de datos así como la generación de reportes surgiendo
también las organizaciones lógicas de alto nivel para los datos y las aplicaciones comenzaron a interrelacionarse
entre sí para ponerse a disposición de un mayor numero de usuarios.
Como productos comerciales surgieron los sistemas Generalizados para Manejo de Archivos (GFMS), Sistemas
Generalizados para la Administración de Base de Datos (GDBMS) y Sistemas de Bases de Datos.
Se puede definir el Manejador de Base de Datos (DBMS Data Base Management System) como un conjunto
coordinado de programas, procedimientos, lenguajes, que suministra, tanto a los usuarios no informáticos como a los
analistas, programadores o al administrador, los medios necesarios para describir, recuperar y manipular los datos
almacenados en la base, manteniendo su integridad, confidencialidad y seguridad.
Si se tiene en cuenta a los diferentes usuarios de las bases de datos con diferentes necesidades y variables a
lo largo del tiempo que son susceptibles de trabajar simultáneamente con subconjuntos de esta colección de datos,
se pone de manifiesto que es imprescindible dotar al sistema de la adecuada flexibilidad para que pueda atender las
exigencias de todos los usuarios y para que sea capaz de responder a los cambios.
Las operaciones típicas que debe realizar un DBMS pueden resumirse en aquellas que afecten la totalidad de
los datos o a todos los registros de un determinado tipo y las que tienen lugar sobre registros concretos.
Las funciones esenciales de un DBMS son las de descripción, manipulación y utilización.
A) Función de descripción o definición
Esta función debe permitir al administrador de la base de datos especifican los elementos de datos que la
integran, su estructura y las relaciones que existen entre ellos, las reglas de integridad semántica, los controles a
afectar antes de autorizar el acceso a la base, así como las características de tipo físico y las vistas lógicas de los
usuarios.
Esta función, realizada por el lenguaje de descripción o definición de datos (LDD) propio de cada DBMS debe
suministrar los medios para definir las tres estructuras de datos(externa, lógica global e interna), especificando las
características de los datos a cada uno de estos niveles.
A nivel interno, se ha de indicar el espacio (volúmenes, cilindros y pistas) reservado para la base, la longitud de
los campos o elementos de datos, su modo de representación (binario, decimal, alfanumérico, punto fijo o flotante).
Además, se debe poder definir caminos de acceso, como punteros, índices, etc.
Para las estructuras externa y lógica global, la función de descripción ha de proporcionar los instrumentos para
la definición de las entidades y su identificación, atributos de las mismas, interrelaciones entre ellas, autorizaciones
de acceso, restricciones de integridad.
B) Función de Manipulación.
La función de manipulación permite a los usuarios de la base de datos, informáticos, o n o, buscar, añadir,
suprimir o modificar los datos de la misma, siempre de acuerdo con las especificaciones y las normas de seguridad
dictadas por el administrador.
La función de manipulación se llevara a cabo por medio de un lenguaje de manipulación de datos (LMD) que
facilita los instrumentos necesarios para la realización de estas tareas.
8
C) Función de Utilización
La función de utilización reúne todas las interfaces que necesitan los diferentes usuarios para comunicarse con
la base y proporciona un conjunto de procedimientos para el administrador.
Las exigencias respecto a la forma de utilizar la base de datos son muy diferentes, según los tipos de procesos
y según los usuarios, siendo preciso que la función de utilización responda a todas ellas.
En la mayoría de los Sistemas Manejadores de Base de Datos existen funciones de servicio, como cambiar la
capacidad de los ficheros, obtener estadísticas de utilización, cargar archivos y principalmente las relacionadas con
la seguridad física y de protección frente a acceso no autorizados.
Objetivos de los Sistemas Manejadores de Bases de Datos.
 Control de concurrencia
Múltiples usuarios pueden acceder a la misma información al mismo tiempo, sin que con ello se tengan
problemas con los datos.
 Proteger los datos contra fallas del Sistema

Es la capacidad de restaurar la integridad y consistencia después de una falla del sistema.
 El Diccionario de Datos
Es la capacidad que da el manejador de la base de datos de poder tener la descripción de los datos que están
almacenados en la base de datos.
 Interfaz de alto nivel con los programadores

El manejo de un lenguaje, como lo es SQL.
Un Manejador de Base de Datos debe incluir lo siguiente:
 Independencia de los programas respecto a los cambios en la estructura de los datos.

 Programas de utilería para la administración de la base de datos.
 Mecanismos de seguridad para imponer limites de acceso.
 Recuperación de caso de fallas.
 Facilidades para afinación de la base de datos.
 Un lenguaje de consulta propio
 Capacidad para proceso de transacciones en Línea.
 Diccionario de datos.
 Control de concurrencia.
 Facilidad de acceso.
 Protección de los datos.
1.10. ADMINISTRADOR DE LA BASE DE DATOS
Una de las principales razones para usar un Sistema de Gestión de Base de Datos es tener un control centralizado
tanto de los datos como de los programas que acceden a esos datos. La persona que tiene este control central sobre
el sistema se llama Administrador de la base de datos (ABD). Las funciones del ABD son:
 Definición del Esquema.- El Administrador de la Base de Datos crea el esquema original de la base de
datos escribiendo un conjunto de definiciones que el compilador del Lenguaje de definición de datos (LDD)
traduce a un conjunto de tablas que son almacenadas permanentemente en el diccionario de datos.
 Estructura de Almacenamiento y Definición del Método de Acceso.- Los Administradores de la Base de
Datos crean las estructuras de almacenamiento apropiadas y los métodos de acceso escribiendo un conjunto de
definiciones, que son traducidas por el compilador del Lenguaje de Definición y Almacenamiento de datos.
 Esquema y Modificación de la Organización Física.- Los programadores llevan a cabo las

modificaciones sobre el esquema de base de datos o la descripción de la organización de almacenamiento físico
escribiendo un conjunto de definiciones que son usadas por el compilador de LDD o por el compilador del
9
lenguaje de definición y almacenamiento de datos para generar las modificaciones en las tablas
correspondientes del sistema interno.
 Concesión de la Autorización para el acceso a los datos.- La concesión de diferentes tipos de

autorización permite al administrador de la base de datos determinar que parte de la base de datos pueden
acceder los diferentes usuarios. La información de autorización se mantiene en una estructura del sistema
especial que el sistema de la base de datos consulta cuando se intenta el acceso a los datos en el sistema.
 Especificación de la Ligaduras de Integridad.- Los valores de los datos almacenados en la base de datos
deben satisfacer ciertas ligaduras de integridad. Por ejemplo, quizás él numero de horas que un empleado
puede trabajar en una semana no debe exceder de un limite especificado (por ejemplo, 80 horas). Tales
ligaduras deben ser especificadas explícitamente por el Administrador de la Base de Datos. Las ligaduras de
integridad se mantienen en una estructura del sistema especial que el sistema de base de datos consulta
cuando tiene lugar una actualización en el sistema.
1.11 USUARIOS DE BASE DE DATOS
Un primer objetivo de un sistema de base de datos es proporcionar un entorno para la recuperación de la información
y el almacenamiento de nueva información en la base de datos. Hay cuatro tipos de diferentes de usuarios de un
sistema de base de datos, diferenciados por la forma en que ellos esperan interactuar con el sistema.
 Programadores de Aplicaciones.- Son profesionales informáticos que interactúan con el sistema a través
de llamadas del Lenguaje de Manipulación de Datos(LMD), que están incluidas en un programa escrito en un
lenguaje anfitrión (por ejemplo, Cobol, PL/I, Pascal, C ).Estos programas comúnmente se llaman programas de
aplicación. Por ejemplo un sistema bancario, incluye programas que generan cheques de nominas, cargan
cuentas, abonan cuestas o transfieren fondos entre cuentas.
Debido a que la sintaxis de los LMD es habitualmente muy diferente de la sintaxis del lenguaje anfitrión, las
llamadas del LMD están normalmente precedidas de un carácter especial para que se puede generar código
apropiado. Un preprocesador especial, llamado precompilador del LMD, convierte las instrucciones del LMD en
llamadas a procedimientos normales en el lenguaje anfitrión. El programa resultante se compila a continuación
mediante el compilador del lenguaje anfitrión, que genera el código objeto apropiado.
Hay tipos de lenguajes de programación de programación especiales que combinan estructuras de control de
lenguajes tipo Pascal con estructuras de control para la manipulación de objetos de una base de datos (por ejemplo,
relaciones). Estos lenguajes, llamados lenguajes de cuarta generación, a menudo incluyen características especiales
para facilitar la generación de formularios y la presentación de datos en pantalla. La mayoría de los sistemas de
bases de datos comerciales incluyen un lenguaje de cuarta generación.
 Usuarios Sofisticados.- Interactúan con el sistema sin programas escritos. En su lugar, ellos forman sus
consultas en un lenguaje de consulta de base de datos. Cada una de estas consultas se envía al procesador de
consultas, cuya función es transformar instrucciones LMD a instrucciones que el gestor de almacenamiento
entienda. Los analistas que envían las consultas para explorar los datos en la base de datos entran en esta
categoría.
 Usuarios Especializados.- Son usuarios que escriben aplicaciones de bases de datos especializadas que
no son adecuadas en el marco de procesamiento de datos tradicional. Entre estas aplicaciones están los
sistemas de diseño asistido por computadora, sistemas de bases de conocimientos y expertos, sistema que
almacenan los datos con los tipos de datos completos (por ejemplo, datos gráficos y datos de audio).
 Usuarios Normales o Finales.- Son usuarios que interactúan con el sistema mediante la invocación de
alguno de los programas de aplicación permanentes que se han escrito previamente.
1.12 ESTRUCTURA GENERAL DEL SISTEMA
Un sistema de base de datos se divide en módulos que se encargan de cada una de las responsabilidades del
sistema completo. Algunas de estas funciones del sistema de base de datos las puede proporcionar el sistema
operativo de la computadora.
10
Los componentes funcionales de un sistema de base de datos se puede dividir en componentes de

procesamiento de consultas y componentes de gestión de almacenamiento.
Los componentes de procesamiento de consultas incluyen:
 Compilador del LMD.- Traduce las instrucciones del LMD en lenguaje de consultas a instrucciones a bajo
nivel que entiende el motor de evaluación de consultas. Además, el compilador de LMD intenta transformar las
peticiones del usuario en otras equivalentes pero más eficientes, encontrando así una buena estrategia para
ejecutar la consulta.
 Precompilador de LMD incorporado.- Convierte las instrucciones del LMD incorporadas en un programa
de aplicación en llamadas a procedimientos normales en el lenguaje anfitrión. El precompilador debe interactuar
con el compilador del LMD para generar el código apropiado.
 Interprete del LDD.- Interpreta las instrucciones del LDD y las registra en un conjunto de tablas que
contiene metadatos.
 Motor de Evaluación de Consultas.- Ejecuta las instrucciones a bajo nivel generadas por el compilador del
LMD.
Los componentes de gestión de almacenamiento proporcionan la interfaz entre los datos de bajo nivel
almacenados en la base de datos y los programas de aplicación y envío de consultas al sistema. Dicho gestor
incluye:
11
ESTRUCTURA GENERAL DEL SISTEMA
Usuarios
normales Programadores Usuarios Administrador de
usuarios
(cajeros, agentes, de aplicaciones Sofisticados base de datos
etc)
interfaces de programas de esquema de

consulta
aplicaciones aplicación base de datos
precompilador
compilador de intérprete del
del LMD
LMD LDD
incorporado
procesador de
consultas
código objeto de
motor de
los programas de sistena de
evaluación de
aplicación gestión de
consultas
base s
dedatos
gestor de
gestor de
memoria
transacciones
intermedia
gestor de
almacenamiento
gestor de
archivos
índices datos estadísticos

almacenamiento
en disco
archivos de datos diccionario de datos
 Gestor de autorización e integridad.- Comprueba que se satisfagan las ligaduras de integridad y la

autorización de los usuarios para acceder a los datos.
 Gestor de transacciones.- Asegura que la base de datos quede en un estado consistente (correcto) a
pesar de los fallos del sistema, y que las ejecuciones de transacciones concurrentes ocurran sin conflictos.
 Gestor de Archivos.- Gestión la reserva de espacio de almacenamiento de disco y las estructuras de datos
usadas para representar la información almacenada en disco.
12
 Gestor de memoria intermedia.- Es responsable de traer los datos del disco de almacenamiento a
memoria principal y decidir que datos tratar en la memoria cache.
 Archivos de datos.- Almacenan la base de datos en sí.
 Diccionario de datos.- Almacena metadatos acerca de la estructura de la base de datos.
 Índices.- Proporcionan acceso rápido a elementos de datos que tienen valores particulares.
 Datos Estadísticos.- Almacén información estadística sobre los datos en la base de datos. El procesador
de consultas usa esta información para seleccionar las formas eficientes para ejecutar una consulta.
UNIDAD II. MODELO ENTIDAD-RELACION
El modelo entidad-relación (E-R) esta basado en una percepción del mundo real que consta de un conjunto de
objetos básicos llamados entidades y de relaciones entre objetos. Se desarrollo para facilitar el diseño de base de
datos permitiendo la especificación de un esquema de la empresa que representa la estructura lógica completa de
una base de datos.
2.1. ENTIDADES Y CONJUNTO DE ENTIDADES
Una entidad es un <<objeto>> en el mundo real que es distinguible de todos los demás objetos. Por ejemplo, cada
persona es una entidad. Una entidad tiene un conjunto de propiedades, y los valores para algún conjunto de
propiedades pueden identificar una entidad. Una entidad tiene un conjunto de propiedades, y los valores para algún
conjunto de propiedades pueden identificar una entidad de forma unívoca. Por ejemplo del CURP identifica a una
persona particular.
Un conjunto de entidades es la totalidad de las entidades del mismo tipo que comparten las mismas
propiedades o atributos. El conjunto de todas las personas que son clientes de un banco, por ejemplo, se pueden
definir como el conjunto de entidades cliente. De la misma manera, el conjunto de entidades préstamo-bancario
podría representar el conjunto de todos los prestamos concedidos por un banco particular. Las entidades individuales
que constituyen un conjunto se llaman la extensión del conjunto de entidades. Así, todos los clientes de un banco son
la extensión del conjunto de entidades cliente.
Los conjuntos de entidades no son necesariamente disjuntos. Por ejemplo, es posible definir el conjunto de
entidades de todos los empleados de un banco (empleado) y el conjunto de entidades de todos los clientes de banco.
Una entidad persona puede ser una entidad empleado, una entidad cliente o ambas.
Una entidad se representa mediante un conjunto de atributos. Los atributos describen propiedades que posee
cada miembro de un conjunto de entidades. La designación de un atributo para un conjunto de entidades expresa
que la base de datos almacena información similar concerniente a cada entidad del conjunto de entidades; sin
embargo cada entidad puede tener su propio valor para cada atributo.
Posibles atributos del conjunto de entidad cliente son: nombre-cliente,dni, calle-cliente y ciudad-cliente.
Posibles atributos del conjunto de entidades préstamo-bancario son: numero-prestamos e importe. Para cada atributo
hay un conjunto de atributos permitidos, llamados el dominio o el conjunto de valores, de ese atributo. El dominio
del atributo nombre-cliente puede ser el conjunto de todas las cadenas de texto de una cierta longitud.
Análogamente, el dominio del atributo numero-préstamo podría ser el conjunto de todos los enteros positivos. Una
base de datos incluye así una colección de conjunto de entidades, cada una de las cuales, cada una de las cuales
contiene un numero de entidades del mismo tipo.
A continuación se muestra una parte de una base de datos de un banco que consta de dos conjuntos de
entidades, cliente y préstamo-bancario.
Conjuntos de entidades cliente y préstamo-bancario

13
Santos 32112312 Mayor Peguerinos P-17 200,000.00

Gómez 19283746 Carretas Cerceda P-23 400,000.00
López 67789901 Mayor Peguerinos P-15 300,000.00
Sotoca 12345678 Real Cádiz P-14 300,000.00
Pérez 55555555 Carretas Cerceda P-93 100,000.00
Valdivieso 96396396 Goya Vigo P-11 180,000.00
Fernández 33557799 Jazmín León P-16 260,000.00
Formalmente, un atributo de un conjunto de entidades es una función que asigna al conjunto de entidades el
dominio. Como un conjunto de entidades puede tener diferentes atributos, cada entidad se puede describir como un
conjunto de pares (atributo, valor), un par para cada atributo del conjunto de entidades. Por ejemplo una entidad
concreta cliente se puede describir mediante el conjunto {(nombre, López), (DNI, 677789901), (nombre-calle, Mayor),
(ciudad-cliente, Peguerinos)}, queriendo decir que la entidad describe una persona llamada López que tiene un DNI
67789901 y reside en la calle Mayor en Peguerinos. Los valores de los atributos que describen una entidad
constituirían una porción significante de los datos almacenados en la base de datos.
Un atributo en el modelo E-R se puede clasificar en los siguientes tipos:

 Atributos Simples y Compuestos.- En los conjuntos de entidades anteriores los atributos que se usaron
son simples; por que no están divididos en subpartes. En cambio, los atributos compuestos, se pueden dividir en
subpartes, es decir, se pueden dividir en otros atributos. Por ejemplo nombre-cliente podría estar estructurado
como un atributo compuesto consistente en nombre, primer-apellido y segundo apellido. Usar atributos
compuestos en un esquema de diseño es una buena elección si el usuario desea referirse a un atributo entero
en algunas ocasiones y a algún componente del atributo en otras. Se podrían haber sustituido los atributos del
conjunto de entidades cliente, calle-cliente, y ciudad-cliente, por el atributo compuesto dirección-cliente, con los
atributos calle, ciudad, provincia y código-postal. Los atributos compuestos ayudan a agrupar los atributos
relacionados, haciendo los modelos más claros. Un atributo compuesto puede aparecer como una jerarquía.
Viendo el ejemplo de atributo compuesto dirección-cliente, su componente calle, puede ser a su vez dividido en
numero-calle, nombre-calle, y piso.
Atributos compuestos nombre-cliente y dirección-cliente.
 Atributos univalorados y multivalorados.- Los atributos que se han especificados en el ejemplo anterior
todos tienen un valor solo para una entidad concreta. Por ejemplo el atributo numero-préstamo para una entidad
préstamo especifico, referencia a un único numero de préstamo bancario. Tales atributos se llaman univalorados.
Puede haber ocasiones en las que un atributo tiene un conjunto de valores para una entidad especifica.
Considerando un conjunto de entidades empleado con un atributo nombre-subordinado. Cualquier empleado
puede tener cero, uno o más subordinados; por lo tanto, diferentes entidades empleado dentro del conjunto de
entidades tendrán diferentes números de valores para el atributo nombre-subordinado. Este tipo de atributo se
llama multivalorado. En ellos se pueden colocar apropiadamente limites inferior y superior en el numero de
valores en el atributo multivalorado. Por ejemplo, un banco puede limitar el numero de direcciones almacenadas
para un único cliente a dos. Colocando limites en este caso, se expresa que el atributo dirección-cliente del
conjunto de entidades cliente puede tener entre cero y dos valores.
 Atributos Nulos.- Un valor nulo se usa cuando una entidad no tiene un valor para un atributo, Por ejemplo,
si un empleado en particular no tiene subordinados, el valor nombre-subordinado para ese empleado será nulo.
Nulo puede también designar que el valor de un atributo es desconocido.
 Atributo derivado.- El valor de este atributo se puede derivar de los valores de otros atributos o entidades.
Por ejemplo, si se tiene el conjunto de entidades cliente que tiene un atributo prestamos que representa cuantos
prestamos tiene un cliente en el banco. Este atributo se puede derivar contando el numero de entidades
préstamo asociadas con ese cliente.
2.2 RELACIONES Y CONJUNTOS DE RELACIONES
Una relación es una asociación entre diferentes entidades. Considerando las dos entidades cliente y préstamo. Se
define un conjunto de relaciones prestatario denotarla asociación entre clientes y prestamos bancarios que los
clientes tengan.
Conjunto de relaciones prestatario

14
Santos 32112312 Mayor Peguerinos P-17 200,000.00
Gómez 19283746 Carretas Cerceda P-23 400,000.00
López 67789901 Mayor Peguerinos P-15 300,000.00
Sotoca 12345678 Real Cádiz P-14 300,000.00
Pérez 55555555 Carretas Cerceda P-93 100,000.00
Valdivieso 96396396 Goya Vigo P-11 180,000.00
Fernández 33557799 Jazmín León P-16 260,000.00
Un conjunto de relaciones es un conjunto de relaciones del mismo tipo. Formalmente es una relación matemática con
n 2 de conjuntos de entidades. Si E1, E2, ..., En son conjuntos de entidades, entonces un conjunto de relaciones R
es un subconjunto de
{(e1, e2,..., en) | e1 E1, e2 E2,..., en En }
donde (e1, e2,..., en) es una relación.
Considerando los dos conjuntos de entidades préstamo y sucursal. Se puede definir un conjunto de relaciones
sucursal-préstamo para denotar la asociación entre un préstamo bancario y la sucursal en que se mantiene ese
préstamo.
La asociación entre conjunto de entidades se referencia como participación; es decir, los conjuntos de
entidades E1, E2,...,En participan en el conjunto de relaciones R.
La función que desempeña una entidad en una relación se llama papel de la entidad. Debido a que los
conjuntos de entidades que participan en un conjunto de relaciones son generalmente distintos, los papeles están
implícitos y no se especifican normalmente. Sin embargo son útiles cuando el significado de una relación necesita
aclaración.
Una relación puede también tener atributos descriptivos. Considerando un conjunto de relaciones impositor con
conjuntos de entidades cliente y cuenta. Se podría asociar el atributo fecha-acceso a esta relación para especificar la
fecha mas reciente en que un cliente accedió una cuenta.
El conjunto de relaciones prestatario y sucursal-préstamo proporcionan un ejemplo de un conjunto de

relaciones binario. La mayoría de los conjuntos de relaciones en un sistema de base de datos son binarios.
Ocasionalmente, los conjuntos de relaciones implican mas de dos conjuntos de entidades. Por ejemplo, se podrían
combinar los conjuntos de entidades prestatario y sucursal-préstamo para formar un conjunto de relaciones ternario
CPS entre los conjuntos de entidades cliente(C), préstamo (P) y sucursal (S).
Él numero de conjunto de entidades que participan en un conjunto de relaciones es también el grado del
conjunto de relaciones. Un conjunto de relaciones binario tiene grado 2; un conjunto de relaciones ternario tiene
grado 3.
2.3 LIMITANTES DE MAPEO
Un esquema de desarrollo E-R puede definir ciertas restricciones a las que los contenidos de la base de datos se
deben adaptar. Una restricción importante es la de las cardinalidades de asignación, que expresan el numero de
entidades a las que la otra entidad puede estar asociada mediante un conjunto de relaciones.
15
La correspondencia de cardinalidades es la mas útil describiendo conjunto de relaciones binaria, aunque

ocasionalmente contribuyen a la descripción de conjuntos de relaciones que implican mas de dos conjuntos de
entidades.
Para un conjunto de relaciones binarias R entre los conjuntos de entidades A y B, la correspondencia de
cardinalidades debe ser:
Uno a Uno.- Una entidad en A se asocia con a lo sumo una entidad en B, y una entidad en B se asocia con a lo
sumo una entidad en A.
A B
a1 b1
a2 b2
a3 b3
a4 b4
Relación Uno a Uno
Uno a Varios.- Una entidad en A se asocia con cualquier numero de entidades en B. Una entidad en B, sin embargo,
se puede asociar con a lo sumo una entidad en A.
A B
b1
a1 b2
a2 b3
a3 b4
b4
Relación Uno a Varios
Varios a Uno.- Una entidad en A se asocia con a lo sumo una entidad en B. Una entidad en B, sin embargo, se
puede asociar con cualquier numero de entidades en A.
16
A B
a1
a2 b1
a3 b2
a4 b3
a5
Relación Varios a Uno
Varios a Varios.- Una entidad en A se asocia con cualquier numero de entidades en B, y una entidad en B, se asocia
con cualquier numero de entidades en A.
A B
a1 b1
a2 b2
a3 b3
a4 b4
Relación Varios a Varios
La correspondencia de cardinalidades para un conjunto de relaciones particular es obviamente dependiente de la

situación del mundo real que el conjunto de relaciones modela.
La razón de cardinalidad de una relación puede afectar a la situación de los atributos de la relación. Los
atributos de los conjuntos de las relaciones uno a uno o uno a varios pueden estar asociados con uno de los dos
conjuntos de entidades participantes, además de con el conjunto de relaciones.
2.4 LLAVES PRIMARIAS
Es importante ser capaz de especificar como las entidades dentro de un conjunto de entidades dado y las relaciones
dentro de un conjunto de relaciones dado son distinguibles. Las entidades y relaciones individuales son distintas;
desde una perspectiva de base de datos, sin embargo, la diferencia entre ellas se debe expresar en términos de sus
atributos. El concepto de clave permite hacer tales distinciones.
Una superclave es un conjunto de uno o más atributos que, tomados colectivamente, permiten identificar de
forma única una entidad en el conjunto de entidades. Por ejemplo, el atributo dni del conjunto de entidades cliente es
suficiente para distinguir una entidad cliente de las otras. Así dni, superclave. Análogamente, la combinación de
17
nombre-cliente y dni es una superclave del conjunto de entidades cliente. El atributo nombre-cliente de la entidad
cliente no es una superclave, porque varias personas podrían tener el mismo nombre.
Si K es una superclave, entonces también lo es cualquier superconjunto de K. Los subconjuntos propios de las
superclaves no son superclaves. Tales superclaves mínimas se llaman claves candidatas.
Es posible que conjuntos distintos de atributos pudieran servir como clave candidata. Suponiendo que una
combinación de nombre-cliente y calle-cliente es suficiente para distinguir entre los miembros del conjunto de
entidades cliente. Entonces, los conjuntos {dni} y {nombre-cliente, calle-cliente} son claves candidatas. Aunque los
atributos dni, y nombre cliente juntos puedan distinguir entidades cliente, su combinación no forma una clave
candidata, ya que el atributo dni por si solo es una clave candidata.
Las claves candidatas se deben designar con cuidado. El termino clave primaria se usa para denotar una clave
candidata que es elegida por el diseñador de la base de datos como elemento principal para identificar las entidades
dentro del conjunto de entidades. Una clave(primaria, candidata y superclave) es una propiedad del conjunto de
entidades, mas que de las entidades individuales.
La clave primaria de un conjunto de entidades permite distinguir entre las diferentes entidades del conjunto. Se
necesita un mecanismo similar para distinguir entre las diferentes relaciones de un conjunto de relaciones.
Sea R un conjunto de relaciones que implica los conjuntos de entidades E 1, E2,...,En. Sea clave-primaria (Ei) el
conjunto de atributos que forma la clave primaria para el conjunto de entidades E i. Asúmase, que los nombres de los
atributos de todas las clave primarias sin únicos. La composición de la clave primaria para un conjunto de relaciones
depende de la estructura de los atributos asociados al conjunto de relaciones R.
Si el conjunto de relaciones R no tiene atributos asociados, entonces el conjunto de atributos
Clave-primaria(E1) U clave-primaria(E2) U...U clave-primaria(En)
Describe una relación individual en el conjunto R.
Si el conjunto de relaciones R tiene atributos a1,a2,...,an asociados a él, entonces del conjunto de atributos.
Clave-primaria(E1) U clave-primaria(E2) U...U clave-primaria (En) U {a1,a2,...,am}.
Describe una relación individual en el conjunto R.
En ambos casos, el conjunto de atributos
Clave-primaria(E1) U clave-primaria(E2) U...U clave-primaria (En)
Forma una superclave para el conjunto de relaciones.
La estructura de la clave primaria para un conjunto de relaciones depende de la cardinalidad asociada al
conjunto de relaciones. Como ejemplo, considérese el conjunto de entidades cliente y empleado, y un conjunto de
relaciones banquero-cliente que representa una asociación entre un cliente y su banquero (una entidad empleado).
Supóngase que el conjunto de relaciones es varios a varios, y también supóngase que el conjunto de
relaciones tiene el atributo tipo asociado a él, representando la relación (por ejemplo, responsables de prestamos o
banquero personal). Entonces la clave primaria de banquero-empleado consiste en la unión de las claves primarias
de cliente y empleado. Sin embargo, si un cliente puede tener un solo banquero, es decir, si la relación banquero-
cliente es varios a uno, entonces la clave primaria de banquero-empleado es simplemente la clave primaria de
cliente. Para relaciones uno a uno se puede usar cualquier clave primaria.
2.5 DIAGRAMA ENTIDAD-RELACION
La estructura lógica global de una base de datos se puede expresar gráficamente mediante un diagrama E-R. La
simplicidad relativa y la claridad de esta técnica de diagrama puede ser en gran parte la causa del uso ampliamente
extendido del modelo E-R. Tal diagrama consta de los siguientes componentes:
Rectángulos.- Representan los conjuntos de entidades.

Elipses.- Representan los atributos.
Rombos.- Representan las relaciones.
Líneas.- Unen los atributos a conjuntos de entidades y conjunto de entidades a conjunto de relaciones.
Elipses dobles.- Representan atributos multivalorados.
Elipses discontinuas.- Denotan atributos derivados.
Líneas dobles.- Indican la participación total de una entidad en un conjunto de relaciones.
18
Considere el diagrama entidad-relación de la siguiente figura, que consta de dos conjuntos de entidades,
cliente y préstamo, relacionadas a través de un conjunto de relaciones binarias prestatario. Los atributos asociados
con cliente son: nombre-cliente, dni, calle-
cliente y ciudad-cliente. Los atributos asociados con son numero-préstamo e importe. Las llaves o claves primarias
se subrayan.
dni calle-cliente numero-préstamo importe
nombre-cliente ciudad-cliente
cliente prestatario préstamo
El conjunto de relaciones prestatario pueden ser varios a varios, uno a varios, varios a uno, o no a uno. Para
distinguir entre estos tipos, se dibuja una línea dirigida () o una línea no dirigida entre el conjunto de relaciones y el
conjunto de entidades.
Diagrama E-R. Uno a Varios

19
Diagrama E-R. Uno a Uno
Si un conjunto de relaciones tiene también algunos atributos asociados a él, entonces se unen esos atributos a
ese conjunto de relaciones. Por ejemplo del siguiente diagrama:
fecha-acceso
cliente impositor préstamo
Diagrama E-R. con un atributo unido a un conjunto de relaciones
se tiene el atributo descriptivo fecha-acceso unido al conjunto de relaciones impositor para especificar la fecha mas
reciente en que un cliente accedió a esa cuenta.
En los diagramas E-R se indican papeles mediante etiquetas en las líneas que unen a rombos con rectángulos.
En el siguiente ejemplo se muestra el papel indicando director y trabajador entre el conjunto de entidades empleado
y el conjunto de relaciones trabaja-para.
20
nombre-empleado
número-teléfono
dni-e
director
empleado trabaja-para
trabaja-para
Diagrama E-R con indicadores de papel
Los conjuntos de relaciones no binarias se pueden especificar fácilmente mediante un diagrama E-R. El
siguiente ejemplo consta de tres conjuntos de entidades cliente, préstamo y sucursal, relacionados a través del
conjunto de relaciones CPS. Este diagrama especifica que un cliente puede tener varios prestamos, y esos
prestamos pueden pertenecer a varios clientes. La flecha que apunta a sucursal indica que cada par préstamo-
cliente esta asociado con una sucursal bancaria especifica.
ciudad-sucursal
nombre-sucursal activos
sucursal
dni calle-cliente
número-préstamo importe
cliente CPS préstamo
ENTIDADES DEBILES
21
Un conjunto de entidades puede no tener suficientes atributos para formar una clave primaria. Tal conjunto de
entidades se denomina conjunto de entidades débil. Un conjunto de entidades que tiene una clave primaria se
denomina conjunto de entidades fuerte.
Considerando un conjunto de entidades pago, que tiene los atributos: numero-pago, fecha-pago, e importe-
pago. Aunque cada entidad pago es distinta, los pagos para diferentes prestamos pueden compartir el mismo
numero de pago. Así, este conjunto de entidades no tiene una clave primaria; es un conjunto de entidades débil. Para
que un conjunto de entidades débil tenga sentido, debe formar parte de un conjunto de relaciones uno a varios.
Aunque un conjunto de entidades débil no tiene clave primaria, solamente se necesita conocer la distinción
entre todas aquellas entidades del conjunto de entidades que dependen de una entidad particular fuerte. El
descriminante de un conjunto de entidades débil es un conjunto de atributos que permite que esta distinción se haga.
Por ejemplo, el discriminante del conjunto de entidades débil pago es el atributo numero-pago ya que para cada
préstamo un numero de pago identifica de forma única un pago simple de ese préstamo.
La clave primaria de un conjunto de entidades débil se forma mediante la clave primaria del conjunto de
entidades fuerte de cuya existencia depende el conjunto de entidades débil, mas el descriminante del conjunto de
entidades débil. En el caso del conjunto de entidades pago, su clave primaria es {numero-préstamo, numero-pago},
donde numero-préstamo identifica la entidad dominante de un pago y numero-pago distingue las entidades pago
dentro del mismo préstamo.
El conjunto de entidades dominante identificador se llama propietario del conjunto de entidades débil que
identifica. La relación que asocia el conjunto de entidades débil con un propietario se llama relación de identificación.
En el ejemplo anterior, préstamo-pago es la relación de identificación para pago.
Un conjunto de entidades débil se indica en los diagramas E-R mediante un rectángulo dibujado con una línea
doble y la correspondiente relación de identificación mediante un rombo dibujado con linera doble.
fecha-pago
número-préstamo número-pago importe-pago
importe
préstamo-
préstamo pago
pago
Diagrama E-R con un conjunto de entidades débil
El diagrama anterior, el conjunto de entidades débil pago es dependiente del conjunto de entidades fuerte
préstamo a través del conjunto de relaciones préstamo-pago. También se muestra el uso de líneas dobles para
indicar la participación total del conjunto de entidades pago en la relación préstamo-pago, significando que cada pago
debe estar relacionado a través de préstamo-pago con alguna cuenta.
Un conjunto de entidades débil puede participar como propietario en una relación de identificación con otro
conjunto de entidades débil. Incluso aunque la existencia de un conjunto de entidades débil dependa siempre de una
22
entidad dominante, una dependencia no debe existir necesariamente en un conjunto de entidades débil; es decir, el
conjunto de entidades subordinado puede tener una clave primaria.
2.6 REDUCCION DE LOS DIAGRAMAS E-R A TABLAS
Una base de datos que se constituye es un esquema de base de datos E-R se puede representar por una colección
de tablas. Para cada conjunto de entidades de la base de datos y para cada conjunto de relaciones hay una única
tabla a la que se le asigna el nombre de conjunto de entidades o del conjunto de relaciones correspondientes.
Ambos modelos, el modelo E-R y el modelo de bases de datos relacional, son representación abstractas y
lógicas del desarrollo del mundo real. Debido a que los dos modelos emplean principios de diseño similares, se
puede convertir un diseño E-R en un diseño relacional.
Sea E un conjunto de entidades fuertes con los atributos descriptivos a1, a2, ..., a n. Esta entidad se representa
mediante una tabla llamada E con n columnas distintas, cada una de las cuales corresponde a uno de los atributos
de E. Cada fila de la tabla corresponde a una entidad del conjunto de entidades E.
Considerando el conjunto de entidades préstamo con sus atributos número-préstamo e importe. Se representa
este conjunto de entidades mediante una tabla llamada préstamo, con dos columnas. Como se muestra a
continuación:
Tabla Préstamo
Número-préstamo Importe
P-17 200,000
P-23 400,000
P-25 300,000
P-14 300,000
P-93 100,000
P-11 180,000
P-16 260,000
La fila (P-17, 200,000) significa que el numero de préstamo P-17 tiene un importe de préstamo de 200,000. Se
puede añadir una nueva entidad a la base de datos insertando una fila en la tabla. También se pueden borrar o
modificar las filas.
Considerando el conjunto de entidades cliente con los atributos: nombre-cliente, dni, calle-cliente y ciudad-
cliente. La tabla correspondiente a cliente tiene cuatro columnas.
dni calle-cliente
cliente
Diagrama E-R para el conjunto de entidades cliente
Tabla de equivalencia
23
Nombre-cliente Dni Calle-cliente Ciudad-cliente

Santos 32112312 Mayor Peguerinos
Gómez 19283746 Carretas Cerceda
López 67789901 Mayor Peguerinos
Pérez 55555555 Carretas Cerceda
Rupérez 24466880 Ramblas León
Abril 96396396 Preciados Valsaín
Valdivieso 96396396 Goya Vigo
Fernández 33557799 Jazmín León
González 19283746 Arenal La Granja
Representación tabular de los conjuntos de entidades débiles
Sea A un conjunto de entidades débil con los atributos a1, a2,...,am. Sea B el conjunto de entidades fuerte del que A
depende. Sea la clave primaria el conjunto de atributos b1,b2,...,bn. Se representa el conjunto de entidades A
mediante una tabla llamada A con una columna por cada uno de sus atributos del conjunto:
{a1,a2,...,am} U {b1,b2,...,bn}
Considerando al conjunto de entidades pago con sus atributos: numero-pago, fecha-pago e importe-pago,. La
clave primaria del conjunto de entidades préstamo, de la que depende, es número-préstamo.
fecha-pago
número-préstamo número-pago importe-pago
importe
préstamo-
préstamo pago
pago
Diagrama E-R con un conjunto de entidades débil
Tabla de equivalencia
Tabla pago
Número-préstamo Número-pago Fecha-pago Importe-pago

P-17 5 10 mayo 2000 10,000
P-23 11 17 mayo 2000 15,000
P-15 22 23 mayo 2000 60,000
P-14 69 28 mayo 2000 100,000
P-93 103 3 junio 2000 180,000
P-17 6 7 junio 2000 10,000
P-11 53 7 junio 2000 25,000
P-93 104 13 junio 2000 40,000
P-17 7 17 junio 2000 20,000
24
P-16 58 18 junio 2000 27,000
Representación tabular del conjunto de relaciones
Sea R un conjunto de relaciones, sean a1, a2 ,..., am, el conjunto de atributos formados por la unión de las
claves primaria de cada uno de los conjuntos de entidades que participan en R, y sean b1, b2,..., bn los atributos
descriptivos de R. El conjunto de relaciones se representa mediante una tabla llamada R con una columna por cada
uno de los atributos del conjunto.
Considerando el siguiente diagrama, el conjunto de relaciones prestatario implica los dos siguientes conjuntos de
entidades.
Cliente. Con la clave primaria dni.

Préstamo. Con la clave primaria número-préstamo.
Debido a que el conjunto de relaciones no tiene atributos, la tabla prestatario tiene 2 columnas etiquetadas dni y
numero-préstamo.
Diagrama E-R. Uno a Uno
Tabla prestatario
Dni Numero-
préstamo
32112312 P-17
19283746 P-23
67789901 P-15
55555555 P-14
24466880 P-93
19283746 P-11
93696396 P-17
33557799 P-16
Redundancia de tablas
El caso de un conjunto de relaciones unido a un conjunto de entidades débil con el correspondiente conjunto de
entidades fuerte es especial. Estas relaciones son varios a uno y no tienen atributos descriptivos. Además la clave
primaria de un conjunto de entidades débil incluye la clave primaria del conjunto de entidades fuerte.
Del diagrama E-R con el conjunto de entidades débil pago, éste depende del conjunto de entidades fuerte
préstamo a través del conjunto de relaciones préstamo-pago. La clave primaria de pago es {numero-préstamo,
numero-pago} y la clave primaria de préstamo es {numero-préstamo}. Como préstamo-pago no tiene atributos
descriptivos, la tabla para préstamo-pago tendría dos columnas, numero-préstamo y numero-pago. La tabla pago
tiene cuatro columnas, numero-préstamo, numero-pago, fecha-pago, e importe-pago. Así, la tabla préstamo-pago es
redundante, la tabla para el conjunto de relaciones que une a un conjunto de entidades débil con su correspondiente
25
conjunto de entidades fuerte es redundante y no necesita ser representada en una representación tabular de un
diagrama E-R.
Combinación de tablas
Considerando un conjunto AB de relaciones varios a uno del conjunto de entidades A al conjunto de entidades B.
Usando el esquema de construcción de tablas se construyen tres tablas: A, B, y AB. Sin embargo, si hay una
dependencia de existencia de A a B (esto es, para cada entidad a en A, la existencia de a depende de la existencia
de alguna entidad b en B), entonces se pueden combinar las tablas A y AB para formar una única tabla consiste en la
unión de las columnas de ambas tablas.
Ejemplo, considerando el siguiente diagrama:
ciudad-sucursal
número-cuenta saldo nombre-sucursal

activos
cuenta cuenta-sucursal sucursal
El conjunto de relaciones cuenta-sucursal es varios a uno desde cuenta a sucursal. Además, la sobre línea indica
que la participación de cuenta en cuenta-sucursal es total. Además una cuenta no puede existir sin estar asociada
con una sucursal en particular. Por lo tanto se necesitan las dos siguientes tablas:
cuenta.- con los atributos: numero-cuenta, saldo, nombre-sucursal.
Sucursal.- con los atributos: nombre-sucursal, ciudad-sucursal y activos.
2.7 GENERALIZACION Y ESPECIALIZACION
ESPECIALIZACION
Un conjunto de entidades puede incluir subgrupos de entidades que se diferencian de alguna forma de las otras
entidades del conjunto. Por ejemplo, un subconjunto de entidades en un conjunto de entidades puede tener atributos
que no son compartidos por todas las entidades. El modelo E-R proporciona una forma de representación de estos
grupos de entidades distintos.
Considérese el conjunto de entidades cuenta con atributos numero-cuenta y saldo.
Una cuenta se puede clasificar como una de las siguientes:

1. cuenta-ahorro.
2. Cuenta-corriente
Cada uno de estos tipos de cuentas se describen mediante un conjunto de atributos que incluyen los atributos
del conjunto de entidades cuenta más otros atributos adicionales. Por ejemplo, las entidades cuenta-ahorro se
describen además mediante el atributo tipo-interés, mientras que las entidades cuenta-corriente se describen
además mediante el atributo descubierto. El proceso de designación de subgrupos dentro de un conjunto de
entidades es la especialización. La especialización de cuenta permite distinguir entre las cuentas basándose en el
tipo de cuenta.
Un conjunto de entidades se puede especializar mediante mas de una característica distintiva. En este ejemplo,
la característica distintiva es el tipo de cuenta.
En términos de un diagrama E-R, la especialización se representa por medio de un componente triangular

etiquetado ISA, como se muestra a continuación. La etiqueta ISA significa << is a >> (ES) y representa, por ejemplo,
que una cuenta de ahorro es una cuenta.
26
número-cuenta saldo
cuenta
ISA
tipo-in te rés descubierto
cuenta-
cuenta-ahorro
corriente
ISA
normal oro senio r
número-
pago-interés sald o-mínimo fecha-nacimie nto
movimiento s
GENERALIZACION
El refinamiento desde un conjunto de entidades inicial en sucesivos niveles de subgrupos en entidades representa un
proceso de diseño descendente (top-down) en el que las distinciones se hacen explícitas. El proceso de diseño
puede ser también de forma ascendente (bottom-up) en que los múltiples conjuntos de entidades se sintetizan en un
conjunto de entidades de nivel mas alto basado en características comunes. El diseñador de la base de datos puede
haber identificado primero el conjunto de entidades cuenta-corriente con los atributos numero-cuenta, saldo y
descubierto, y el conjunto de entidades cuenta-ahorro con los atributos numero-cuenta, saldo y tipo interés. Hay
similitudes entre el conjunto de entidades cuenta-corriente y el conjunto de entidades cuenta-ahorro en el sentido de
que tienen varios atributos en común. Esta similitud se puede expresar mediante generalización, que es una relación
contenida que existe entre el conjunto de entidades de nivel mas alto y uno o más conjuntos de entidades de nivel
mas bajo. En el ejemplo, cuenta es el conjunto de entidades del nivel mas alto, y los conjuntos de entidades cuenta-
ahorro y cuenta-corriente son del nivel mas bajo.
2.8 AGREGACION
Una limitación del modelo E-R es que no es posible expresar relaciones entre relaciones. Para ilustrar la necesidad
de tales construcciones, considérese una base de datos que describe información acerca de clientes y prestamos.
Supóngase que cada par cliente-préstamo puede tener un empleado del banco que es el responsable de prestamos
para ese par particular. Usando las construcciones del modelo E-R básico, se obtiene el siguiente diagrama:
27
dni calle-cliente
responsable-
prestamo
empleado
dni-e número-teléfono
nombre-empleado
En el que se observa los conjuntos de relaciones prestatario y responsable-préstamo se pueden combinar en un

conjunto de relaciones simple. De otro modo no se podría combinar, ya que haciéndolo, se oscurece la estructura
lógica del esquema. Por ejemplo, si se combinan los conjuntos de relaciones prestatario y responsable-préstamo,
esta combinación especifica que un responsable de prestamos debe estar asignado a cada par cliente-préstamo, lo
cual no es cierto. La separación en dos conjuntos de relaciones diferentes resuelve este problema.
Sin embargo, hay información redundante, en el diagrama, ya que cada par cliente-préstamo en responsable-
préstamo esta también prestatario. Si el responsable de prestamos fuera un valor en lugar de una entidad empleado,
se podría en su lugar hacer referencia a un atributo multivalorado responsable-préstamo en la relación prestatario.
Pero esto implica, que es más difícil, encontrar, por ejemplo, los pares cliente-préstamo de los que un empleado es
responsable.
La mejor forma de modelar esta situación como esta es usar agregación. La agregación es una abstracción a
través de la cual las relaciones se tratan como entidades de nivel mas alto. Para el ejemplo, se considera el conjunto
de relaciones prestatario y los conjuntos de relaciones cliente y préstamo como un conjunto de entidades llamado
prestatario. Tal conjunto de entidades se trata de la misma forma que cualquier otro conjunto de entidades.
El diagrama utilizando agregación quedaría de la siguiente manera:

28
dni calle-cliente
responsable-
prestamo
empleado
dni-e número-teléfono
nombre-empleado
29
UNIDAD III. MODELO RELACIONAL
3.1. ESTRUCTURA DE LAS BASES DE DATOS RELACIONALES
Una base de datos relaciones consiste en un conjunto de tablas, a cada una de las cuales se le asigna un nombre
exclusivo. Cada fila de la tabla representa una relación entre un conjunto de valores.
Considerando la siguiente tabla:
Nombre-sucursal Número-cuenta saldo

Centro C-101 100,000
Becerril C-215 140,000
Navacerrada C-102 80,000
Collado Mediano C-305 70,000
Galapagar C-201 180,000
Moralzarzal C-222 140,000
Galapagar C-217 150,000
Tiene tres cabeceras de columna: nombre-sucursal, numero-cuenta y saldo. Se puede hacer referencia a estas
cabeceras como atributos. Para cada atributo hay un conjunto de valores permitidos denominado dominio de ese
atributo. Para el atributo nombre-sucursal, por ejemplo el dominio es el conjunto de los nombres de las sucursales.
Suponiendo que D1 denota este conjunto, D2 el conjunto de los numero de cuenta y D3 el conjunto de los saldos.
Todas la filas de cuenta deben coincidir en una tupla (v1,v2,v3) donde v1 es un nombre de sucursal (v1 esta en el
dominio de D1), v2 es un numero de cuenta (v2 esta en el dominio D2) y v3 es un saldo. En general cuenta solo tendrá
un subconjunto del conjunto de todas las filas posibles. Por lo tanto cuenta es un subconjunto de:
D1 X D 2 X D 3
En general, una tabla de n atributos debe ser un subconjunto de:
D1 X D2 X...XDn-1 X Dn
Como las tablas son esencialmente relaciones, se utilizan los términos matemáticos relación y tupla en lugar de
tabla y fila.
ALGEBRA RELACIONAL
El álgebra relacional es un lenguaje de consulta procedimental. Consta de un conjunto de operaciones que toman
como entrada una o dos relaciones y producen como resultado una nueva relación.
El álgebra relacional esta divido en dos grupos:
1. Operadores tradicionales de conjuntos.- Unión, Intersección, diferencia y producto cartesiano.
2. Operadores relacionales especiales.- Selección, proyección, reunión natural y división.
Tomando como base las siguientes relaciones para ejemplificar cada uno de los operadores.
RELACION A
S# NOMBRE CIUDAD STATUS

S1 SALAZAR LONDRES 20
S4 CORDOVA LONDRES 20
RELACION B
30

S2 JAIMES PARIS 10
Además se debe respetar que el operador unión, intersección y diferencias sean compatibles con la unión. Es
decir, que las tablas a operar deben ser del mismo grado y los j-ésimos atributos de las relaciones (j = rango de 1 a n)
deben tener el mismo dominio (no es necesario que tengan el mismo nombre)
UNION.- La unión de dos relaciones A y B compatibles con la unión, denotado por A unión B, es una relación cuya
cabecera es idéntica a la de A o de B y cuyo cuerpo son las tuplas t pertenecientes ya sea a A o B o ambas.
AUB=

S2 JAIMES PARIS 10
INTERSECCION.- La intersección de dos relaciones A y B compatibles con la unión, denotado por A intersección B,
es una relación cuya cabecera es idéntica a la de A o de B y cuyo cuerpo son las tuplas t pertenecientes tanto a A
como B o ambos.

DIFERENCIA.- La diferencia entre dos relaciones compatibles a la unión A y B, denotado por A minus B, es una
relación cuya cabecera es idéntica a la de A o B y cuyo cuerpo esta formado por todas las tuplas t pertenecientes a A
pero no a B.
A–B=

PRODUCTO CARTESIANO.- El producto cartesiano de las tablas A y B, denotado por A times B se define como una
relación cuya cabecera es la combinación de las cabeceras A y B, y cuyo cuerpo esta formado por el conjunto de
todas las tuplas t de tal modo que t sea una combinación de una tupla A perteneciente a la relación A y una tupla b
perteneciente a la relación B.
Por ejemplo.- Suponiendo las relaciones Ay B. Definidas de la siguiente manera: sea la relación A el conjunto
de todos los números de proveedor y B el conjunto de todos los números de partes. Entonces A times B es el
conjunto de todos los pares posibles numero de proveedor/numero de parte.
A B A Times B
S# P# S# P#
S1 P1 S1 P1
S2 P2 S1 P2
S3 S2 P1
S2 P2
S3 P1
S3 P2
OPERADORES RELACIONALES ESPECIALES

31
Operador selección ().-El operador algebraico de selección produce un conjunto horizontal de una relación
especifica, es decir, el conjunto de las tuplas de la relación para el cual se cumple un predicado especifico. Sea theta
cualquiera de los siguientes operadores =, <, >, <=, >=, <>, entonces quedaría:
SELECT A WHERE X THETA Y
Es una relación con la misma cabecera de A y con un cuerpo formado por el conjunto de tuplas t de la relación
A siempre y cuando la evaluación de comparación “X THETA Y” resulte verdadera.
La expresión condicional puede estar compuesta por expresiones boleanas unidad por AND, OR y NOT.
Ejemplos:
4. S WHERE CIUDAD =’LONDRES’

4. P WHERE PESO < 14
4. SP WHERE S# =’S1’ AND P#=’P1’
Proyección ( ).- El operador de proyección produce un subconjunto vertical de una relación dada, es decir, el
subconjunto obtenido al seleccionar los atributos que se indican en un orden de izquierda a derecha y eliminando las
tuplas duplicadas.
La proyección de una relación A según los atributos x, y, z.
A[x, y, z] es una relación con (x, y, z) como cabecera y cuyo cuerpo esta formado por el conjunto de tuplas (A-x, A-y,
A-z), es decir, se selecciona de la tabla, las columnas x, y, z.
Por ejemplo: S[CIUDAD]
CIUDAD
LONDRES
PARIS
ATENAS
REUNION NATURAL (JOIN).- Sean las cabeceras de las relaciones A y B respectivamente:

(X1, X2,..., Xm, Y1, Y2,..., Yn)
(Y1, Y2,..., Yn, Z1, Z2,..., Zn)
es decir, los atributos Y1, Y2,..., Yn son los únicos comunes a las dos relaciones y además están definidos bajo el
mismo dominio.
Considerando las siguientes relaciones:
RELACION S

S1 JOSE JOJUTLA 20
S2 JAVIER TLAQUI 30
S3 CARLOS MEXICO 10
S4 MARIO JOJUTLA 20
RELACION SP
S# P# CANT
32
S1 P1 100
S1 P2 200
S1 P5 100
S2 P1 200
S2 P2 400
S3 P3 100
S4 P4 200
S JOIN SP
S# NOMBRE CIUDAD STATUS P# CANT

S1 JOSE JOJUTLA 20 P1 100
S2 JAVIER TLAQUI 30 P1 200
S2 JAVIER TLAQUI 30 P2 400
S3 CARLOS MEXICO 10 P3 100
S4 MARIO JOJUTLA 20 P4 200
DIVISION.- Sean las cabeceras de las relaciones A y B (X1,X2,...,Xm, Y1,Y2,...,Yn) y (Y1,Y2,...,Yn), es decir los atributos
(Y1,Y2,...,Yn) son comunes a las 2 relaciones donde A representa al dividendo y B al divisor. Para ello, tanto los
atributos (Y1, Y2,...,Yn) de A como B deben estar definidos bajo el mismo dominio.
DIVIDENDO DIVISOR DIVIDENDO BY DIVISOR
S# P# P# S#
S1 P1 P1 S1
S1 P2 S2
S1 P3
S1 P4 P# S#
S1 P5 P2 S1
S1 P6 P4 S4
S2 P1
S2 P3 P# S#
S3 P2 P1 S1
S4 P2 P2
S4 P4 P3
S4 P5 P4
P5
P6
3.2 LENGUAJES DE CONSULTA FORMALES
Un lenguaje de consulta es un lenguaje en el que el usuario solicita información de la base de datos. Estos lenguajes
suelen ser de un nivel superior que el de los lenguajes de programación habituales. Los lenguajes de consulta
pueden clasificarse como procedimentales o no procedimentales. En los lenguajes procedimentales, el usuario
instruye al sistema para que lleve a cabo una serie de operaciones en la base de datos para calcular el resultado
deseado. En los lenguajes no procedimentales, el usuario describe la información deseada sin dar un procedimiento
concreto para obtener esa información.
La mayor parte de los sistemas comerciales de base de datos relacionales ofrecen un lenguaje de consulta que
incluye elementos de los enfoque procedimental y no procedimental.
33
3.4. MODIFICACION DE LA BASE DE DATOS
Las modificaciones de la base de datos se expresan utilizando la operación asignación.
Las tablas mostradas a continuación se utilizarán para mostrar ejemplos de las diferentes modificaciones que
se puedan tener. Estos ejemplos serán por medio de SQL de ORACLE.
SQL (Structured Query Language) es un Lenguaje Estructurado de Consulta Comercial que nos permite
interactuar con la base de datos. SQL contiene otras características además de la consulta en bases de datos.
Incluye características para definir la estructura de los datos, para la modificación de los datos en la base de datos y
para la especificación de ligaduras de seguridad.
SQL contiene comandos que se utilizan para crear, almacenar, cambiar, recuperar y mantener la información en
una base de Datos. Un comando de SQL se guarda en una parte de la memoria llamada SQL Buffer, en donde se
queda hasta que un nuevo comando es introducido.
TABLAS
Tabla EMP. Descripción de sus Campos o Atributos
EMPNO NOT NULL NUMBER(4)

ENAME CHAR(10)
JOB CHAR(10)
MGR NUMBER(4)
HIREDATE DATE
SAL NUMBER(7,2)
COMM NUMBER(7,2)
DEPTNO NUMBER(2)
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO

7369 SMITH CLERK 7902 17-DEC-80 800 20
7499 ALLEN SALESMAN 7698 20-FEB-81 1600 300 30
7521 WARD SALESMAN 7698 22-FEB-81 1250 500 30
7566 JONES MANAGER 7839 02-APR-81 2975 20
7654 MARTIN SALESMAN 7698 28-SEP-81 1250 1400 30
7698 BLAKE MANAGER 7839 01-MAY-81 2850 30
7782 CLARK MANAGER 7839 09-JUN-81 2450 10
7788 SCOTT ANALYST 7566 07-JUN-81 3000 20
7839 KING PRESIDENT 17-NOV-81 5000 10
7844 TURNER SALESMAN 7698 08-SEP-81 1500 0 30
7876 ADAMS CLERK 7788 11-JUL-87 1100 20
7900 JAMES CLERK 7698 03-DEC-81 950 30
7902 FORD ANALYST 7566 03-DEC-81 3000 20
7934 MILLER CLERK 7782 23-JAN-82 1300 10
Tabla DEPT. Descripción de sus Campos.
DEPTNO NUMBER(2)
DNAME CHAR(14)
LOC LOC ()
DEPTNO DNAME LOC

10 ACCOUNTING NEW YORK
20 RESEARCH DALLAS
30 SALES CHICAGO
40 OPERATIONS BOSTON
Borrado.- Las solicitudes de borrado se expresan básicamente igual que las consultas. Sin embargo en lugar de
mostrar las tuplas al usuario. Solo se eliminan de la base de datos las tuplas seleccionadas. Solo se pueden borrar
34
tuplas enteras; no se pueden borra valores de atributos concretos. En el álgebra relacional los borrados se expresan
mediante:
rr–E
Donde r es una relación y E es una consulta de álgebra relacional.
Por ejemplo:
4. Borrar todas las cuentas de Gómez
Cuenta cuenta - nombre-cliente=<<Gómez>>(cuenta)
4. Borrar todos los prestamos con importes entro 0 y 800
Préstamo préstamo - importe >= 0 and importe =< 8000 (préstamo)
Tomando en cuenta las tablas anteriores. Mediante SQL se tendría Los borrados utilizando el Comando
DELETE.
Al realizar borrados se debe tomar en cuenta lo siguiente:
 No se pueden borrar renglones parciales. Si se quiere hacer esto, actualice la columna por NULL.
 La cláusula WHERE determina los renglones a borrar de la tabla.
 Si omitimos la cláusula WHERE, se borrarían TODOS los renglones de la tabla.
Ejemplo:
Martín renuncio. Se debe remover de la BASE DE DATOS.
SQL> DELETE FROM EMP

WHERE EMPNO=7654;
EMPNO ENAME JOB MGR HIREDATE

7369 SMITH CLERK 7902 17-DEC-80
7499 ALLEN SALESMAN 7698 20-FEB-81
7521 WARD SALESMAN 7698 22-FEB-81
7566 JONES MANAGER 7839 2-APR-81
7654 MARTIN SALESMAN 7698 28-SEP-81
7698 BLAKE MANAGER 7839 1-MAY-81
7782 CLARK MANAGER 7839 9-JUN-81
.
.
.
Inserción.- Para insertar datos en una relación hay que especificar la tupla que se va a insertar o escribir una
consulta cuyo resultado sea un conjunto de tuplas que vayan a insertarse. Evidentemente, el valor de los atributos de
las tuplas insertadas deben ser miembros del dominio de cada atributo. De manera parecida las tuplas insertadas
deben ser de la aridad correcta. En el álgebra relacional las inserciones se expresan mediante:
r rUE
35
Donde r es una relajación y E es una expresión de la álgebra relacional. La inserción de una sola tupla se
expresa haciendo que E sea una relación constante que contiene una tupla.
* Supóngase que desea insertar el hecho de que Gómez tiene 200,000.00 en la cuenta C-973 en la sucursal
Navacerrada. Hay que escribir:
cuenta cuenta U {(<<Navacerrada>>, C-973,240,000.00)}
Tomando en cuenta las tablas anteriores. Mediante SQL se tendría las inserciones de la siguiente manera:
SQL> INSERT INTO DEPT VALUES (10,’ACCOUNTING’,’NEW YORK’)
TABLA DEPT
DEPTNO DNAME LOC

10 ACCOUNTING NEW YORK
DONDE:
 La tabla debe crearse antes de insertar datos.

 Los valores se separan con comas.
 Utilice el comando DESCRIBE para mostrar el orden y tipo de las columnas de la tabla.
 Los valores deben coincidir con el tipo de dato de la columna a la que se insertan.
 Los datos tipo CHAR y DATE deben ponerse entre apóstrofes.
Otra forma de insertar es:
SQL> INSERT INTO DEPT (DNAME,EPTNO) VALUES (’ACCOUNTING’,10)
TABLA DEPT
DEPTNO DNAME LOC

10 ACCOUNTING
DONDE:
 Se listan los nombres de las columnas en el INSERT para:

- Insertar datos solamente en algunas columnas de la tabla.
- Introducir datos en alguna secuencia especifica.
 Los valores de deben dar en el orden especificado en la cláusula INSERT.
Insertando renglones de otra tabla
 Se puede utilizar el comando INSERT con un query para seleccionar renglones de una tabla e insertarlos en
otra.
 El query sustituye la cláusula VALUES.
SQL> INSERT INTO EMP(EMPNO,ENAME,DEPTNO)

SELECT ID,NAME,DEPARTMENT
FROM OLD_EMP
36
WHERE DEPARTMENT IN (10,20,30,40);

Utilizando Parámetros en el Comando INSERT
Un comando INSERT puede contener parámetros representando valores que van a ser provistos por el usuario
al momento de correr el comando.
Cada parámetro consiste de un & seguido por el nombre de la columna.
SQL> INSERT INTO DEPT VALUES (&DEPTNO, &DNAME, &LOC);
La ejecución de este comando hace que se pida al usuario los valores para cada uno de los parámetros.
No es necesario poner apóstrofes en datos tipo CHAR y DATE si se pone el parámetro.
Insertando Valores Nulos.
Si no se inserta una columna en cláusula INSERT, el valor de esa columna queda como NULO por default.
Se puede especificar NULL en la cláusula VALUES (a menos que NOT NULL esté especificado para esa
columna).
SQL> INSERT INTO DEPT VALUES (50,’EDUCATION’,NULL)
Insertando valores tipo DATE
Formato default para introducir fechas (valores tipo DATE):
‘DD-MON-YY’
Introducir a un nuevo empleado ‘STONE’
SQL> INSERT INTO EMP (EMPNO,ENAME,HIREDATE)

VALUES (7963,’STONE’,’07-APR-87’);
Para introducir automáticamente la fecha y la hora actual: SYSDATE
Introducir a un nuevo empleado ‘KOHN’ que fue contratado hoy
SQL> INSERT INTO EMP (EMPNO,ENAME,HIREDATE)

VALUES (7600,’KOHN’,SYSDATE)
Actualización.- Puede que en algunas ocasiones que desee modificar un valor de una tupla sin modificar todos los
valores de la tupla. Se puede utilizar el operador proyección generalizada para realizar esta tarea:
r F1,F2,...,Fn (r)
Donde cada Fi es el i-ésimo atributo de r, si el i-ésimo atributo no esta actualizado, o si hay que actualizar el
atributo, Fi es solo una expresión que solo implica constantes y los atributos de r, que da el nuevo valor del atributo.
Si se desea seleccionar varias tuplas de r y solo actualizar esas mismas tuplas, se puede utilizar la expresión
siguiente:
R F1, F2,..., Fn ( P(r)) U (r - P (P))
Para ilustrar el uso de la operación actualización, supóngase que se realiza el pago de los intereses y que hay
que aumentar todos los saldos en un 5%. Hay que escribir.
Cuenta nombre-sucursal, numero-cuenta, saldo saldo *1.05 (cuenta)

37
Tomando en cuenta las tablas anteriores. Mediante SQL se tendría las Actualizaciones utilizando el Comando
UPDATE.
Ejemplo:
Promover a Martin a MANAGER (gerente)

SQL> UPDATE EMP
SET JOB=’MANAGER’
WHERE ENAME=’MARTIN’;
Tabla EMP Original Tabla EMP Actualizada
EMPNO ENAME JOB EMPNO ENAME JOB

7369 SMITH CLERK 7369 SMITH CLERK
7499 ALLEN SALESMAN 7499 ALLEN SALESMAN
7521 WARD SALESMAN 7521 WARD SALESMAN
7566 JONES MANAGER 7566 JONES MANAGER
7654 MARTIN SALESMAN 7654 MARTIN MANAGER
7698 BLAKE MANAGER 7698 BLAKE MANAGER
7782 CLARK MANAGER 7782 CLARK MANAGER
7788 SCOTT ANALYST 7788 SCOTT ANALYST
7839 KING PRESIDENT 7839 KING PRESIDENT
7844 TURNER SALESMAN 7844 TURNER SALESMAN
7876 ADAMD CLERK 7876 ADAMD CLERK
7900 JAMES CLERK 7900 JAMES CLERK
7902 FORD ANALYST 7902 FORD ANALYST
7934 MILLER CLERK 7934 MILLER CLERK
Si omitimos la cláusula WHERE, todos los valores en la columna cambiarían al valor en la cláusula SET.
Actualizando Múltiples Renglones:
Cambiar los puestos de todos los vendedores (SALESMAN) por ‘MARKET REP’
SQL> UPDATE EMP

SET JOB=’MARKET REP’
WHERE JOB=’SALESMAN’;
Tabla EMP Original Tabla EMP Actualizada
EMPNO ENAME JOB EMPNO ENAME JOB

7369 SMITH CLERK 7369 SMITH CLERK
7499 ALLEN SALESMAN 7499 ALLEN MARKET REP
7521 WARD SALESMAN 7521 WARD MARKET REP
7566 JONES MANAGER 7566 JONES MANAGER
7654 MARTIN SALESMAN 7654 MARTIN MARKET REP
7698 BLAKE MANAGER 7698 BLAKE MANAGER
7782 CLARK MANAGER 7782 CLARK MANAGER
7788 SCOTT ANALYST 7788 SCOTT ANALYST
7839 KING PRESIDENT 7839 KING PRESIDENT
7844 TURNER SALESMAN 7844 TURNER MARKET REP
7876 ADAMD CLERK 7876 ADAMD CLERK
7900 JAMES CLERK 7900 JAMES CLERK
7902 FORD ANALYST 7902 FORD ANALYST
7934 MILLER CLERK 7934 MILLER CLERK
38
Controlando cuando tiene efecto las MODIFICACIONES A LA BASE DE DATOS
 Inserciones (altas), borrados (bajas) y actualizaciones (cambios) a tablas no se hacen permanentes hasta
que el trabajo es salvado en la base de datos con COMMIT.
 Hasta que el trabajo es salvado, únicamente el usuario que hizo los cambios los puede ver, todos los demás
usuarios ven los datos como estaban al momento del ultimo COMMIT.
 Un COMMIT puede ser explicito, implícito o automático:
COMMIT Explicito.- Se debe dar el commit de SQL COMMIT para que los cambios se hagan permanentes.
SQL> COMMIT;
COMMIT Implícito.- Los siguientes comandos de SQL causan un COMMIT implícito:
ALTER, AUDIT, COMMENT, CONNECT, CREATE, DISCONNECT, DROP, EXIT, GRANT, NOAUDIT, QUIT, REVOKE
y RENAME.
COMMIT Automático.- Los cambios tienen efecto inmediatamente después de un INSERT, UPDATE o DELETE si el
AUTOCOMMIT se encuentra habilitado.
Para esto se utiliza el comando SET DE SQL *PLUS
SQL> SET AUTOCOMMIT ON
El comando ROLLBACK cancela todos los cambios pendientes regresando al estado en que estaba la
información al momento del ultimo COMMIT.
3.5 VISTAS
No es deseable que todos los usuarios puedan ver la totalidad del modelo lógico. Las consideraciones sobre la
seguridad pueden exigir que algunos datos queden ocultos para los usuarios. Considérese una persona que desea
saber el numero de préstamo de un cliente pero que no necesita ver el importe del préstamo. Esta persona debería
ver una relación descrita, en el álgebra relacional, mediante:
nombre-cliente, numero-préstamo (prestatario x préstamo)
A parte de las consideraciones sobre la seguridad, puede que se desee crear un conjunto personalizado de
relaciones que se adapte mejor que el modelo lógico a la intuición de un usuario concreto.
Definición de Vistas. Las vistas se definen utilizando la instrucción create view. Para definir una vista hay que darle
un nombre e indicar la consulta que la va a calcular. La forma de la instrucción view es:
Create view v como <expresión de consulta>
Donde <expresión de consulta> es cualquier expresión de consulta del álgebra relacional. El nombre de la vista
se representa mediante v.
Como ejemplo, considérese la vista consistente en las sucursales y sus clientes. Supóngase que se desea que esta
vista se denomine todos-los-clientes. Esta vista se define de la siguiente manera.
Create view todos-los-clientes as nombre-sucursal, nombre-cliente (impositor x cuenta) U

nombre-sucursal, nombre-cliente (prestatario x préstamo).
39
Una vez que se ha definido una vista, se puede utilizar el nombre de la vista para hacer referencia a la relación
virtual que genera la vista. Utilizando la vista todos-los-clientes se puede averiguar el nombre de todos los clientes
de la sucursal de Navacerrada, escribiendo:
Los nombres de las vistas pueden aparecer en cualquier lugar en el que pueda aparecer el nombre de una
relación, siempre y cuando no se ejecuten sobre las vistas operaciones de actualización.
Si una relación de vistas se calcula y se guarda, puede quedar desfasada si las relaciones utilizadas para
definirla se modifican. En vez de eso, las vistas suelen implementarse de la manera siguiente. Cuando se define una
vista, el sistema de base de datos guarda la definición de la propia vista, en vez, del resultado de la evaluación de la
expresión del álgebra relacional que la define. Siempre que se utiliza una relación de vistas en una consulta, se
sustituye por la expresión de consulta guardada. Por tanto, la relación de vistas vuelve a calcularse siempre que se
evalúa la consulta.
Algunos sistemas de base de datos permiten que se guarden las relaciones de vistas, pero se aseguran que si
las relaciones reales utilizadas en la definición de la vista cambian, la vista se mantenga actualizada. Estas vistas se
denominan vistas materializadas. Las aplicaciones en la que se utiliza frecuentemente una vista se benefician del uso
de vistas materializadas, igual que las aplicaciones en las que el tiempo de respuesta a ciertas consultas basadas en
vistas es de suprema importancia.
Aunque las vistas son una herramienta útil para las consultas, plantean problemas significativos si con ellas se
expresan las actualizaciones, las inserciones o los borrados. La dificultad radica en que las modificaciones de la base
de datos expresadas en términos de vistas deben traducirse en modificaciones de las relaciones reales en el modelo
lógico de la base de datos.
Tomando en cuenta las tablas anteriores. Mediante SQL se tiene la creación de vistas de la siguiente manera.
Una Tabla, con Múltiples vistas
 Se puede tener muchas vistas de la misma tabla.
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO

7369 SMITH CLERK 7902 17-DEC-80 800 20
7499 ALLEN SALESMAN 7698 20-FEB-81 1,600 300 30
7521 WARD SALESMAN 7698 22-FEB-81 1,250 500 30
7566 JONES MANAGER 7839 2-APR-81 2,975 20
7654 MARTIN SALESMAN 7698 28-SEP-81 1,250 1,400 30
7698 BLAKE MANAGER 7839 1-MAY-81 2,850 30
7782 CLARK MANAGER 7839 9-JUN-81 2,450 10
7768 SCOTT ANALYST 7566 9-NOV-81 3,000 20
7839 KING PRESIDENT 17-NOV-81 5,000 10
7844 TURNER SALESMAN 7698 8-SEP-81 1,500 0 30
7876 ADAMS CLERK 7788 23-SEP-81 1,100 20
7900 JAMES CLERK 7698 3-DEC-81 950 30
7902 FORD ANALYST 7566 3-DEC-81 3,000 20
7934 MILLER CLERK 7782 23-JAN-82 1,300 10
Vista de “CLERKS” Vista de “MANAGERS”

40
ENAME JOB ENAME JOB SAL

SMITH CLERK JONES MANAGER 2,975
ADAMS CLERK BLAKE MANAGER 2,850
JAIMES CLERK CLARK MANAGER 2,450
MILLER CLERK
Como crear, Nombrar y Consultar Vistas
SQL> CREATE VIEW MANAGERS AS

SELECT ENAME,JOB,SAL
FROM EMP
WHERE JOB=’MANAGER’;
Se puede utilizar cualquier SELECT que con contenga un ORDER BY cuando crea una vista.
Para consultar una vista, se hace un SELECT como si la vista fuera una tabla.
SQL> SELECT *
FROM MANAGERS;
ENAME JOB SAL

JONES MANAGER 2,975
BLAKE MANAGER 2,850
CLARK MANAGER 2,450
Creando VISTAS con ALIAS de nombres de columnas
A menos que se especifique lo contrario, la vista hereda los nombres de las columnas de la tabla de la que se
deriva.
Para dar a la vista nombres de columnas diferentes a los de la tabla base, se utiliza la siguiente sintaxis:
CREATE VIEW nombre_vista (alias, alias,...) AS query
SQL> CREATE VIEW MYDEPT

(PERSON,TITLE,SALARY)
AS SELECT ENAME,JOB,SAL
FROM EMP
WHERE DEPTNO=10;
Mas acerca de las vistas con WITH CHECK OPTION
WITH CHECK OPTION .- Especifica que la inserciones y actualizaciones hechas a la base de datos a partir de la
vista, no pueden manipular datos que la vista no puede seleccionar.
SQL> CREATE VIEW DEPT20 AS

SELECT ENAME,JOB, SAL, DEPTNO
FROM EMP
WHERE DEPTNO=20
41
WITH CHECK OPTION
El siguiente commando de actualización generaría un error:
SQL> UPDATE DEPT20

SET DEPTNO= 30
WHERE ENAME=’WARD’
Copiando Tablas y Vistas
 Razones para copiar tablas y vistas:

- Respaldar tablas y vistas originales.
- Dar una copia a alguien mas.
- Hacer cambios tentativos.
- Archivarlas antes de borrarlas.
 Para copiar una Tabla:

- Utilice el commando CREATE TABLE con la cláusula AS seguida por un subquery.
- Cuando la tabla es copiada, la copia incluye la definición de las columnas y los datos.
Borrado de Tablas y Vistas.
 Para borrar TABLAS

- El comando de SQL es DROP TABLE nombre_tabla.
- Si la tabla tiene datos, estos van a ser borrados permanentemente.
- Una vez que la tabla se borra no se puede recuperar.
 Para borrar vistas.

- El comando de SQL es DROP VIEW nombre_vista.
- Las tablas en las que se basa la vista no se altera.
UNIDAD IV. DISEÑO DE BASES DE DATOS RELACIONALES
4.1 PELIGRO EN EL DISEÑO DE BASES DE DATOS RELACIONALES
Uno de los retos en el diseño de la base de datos es el de obtener una estructura estable y lógica tal que:
1. El sistema de base de datos no sufra de anomalías de almacenamiento.
2. El modelo lógico pueda modificarse fácilmente para admitir nuevos requerimientos.
Una base de datos implantada sobre un modelo bien diseñado tiene mayor esperanza de vida aun en un
ambiente dinámico, que una base de datos con un diseño pobre. En promedio, una base de datos experimenta una
reorganización general cada seis años, dependiendo de lo dinámico de los requerimientos de los usuarios. Una base
de datos bien diseñada tendrá un buen desempeño aunque aumente su tamaño, y será lo suficientemente flexible
para incorporar nuevos requerimientos o características adicionales.
Existen diversos riesgos en el diseño de las bases de datos relacionales que afecten la funcionalidad de la misma,
los riesgos generalmente son la redundancia de información y la inconsistencia de datos.
42
La normalización es el proceso de simplificar la relación entre los campos de un registro.

Por medio de la normalización un conjunto de datos en un registro se reemplaza por varios registros que son más
simples y predecibles y, por lo tanto, más manejables. La normalización se lleva a cabo por cuatro razones:
1. Estructurar los datos de forma que se puedan representar las relaciones pertinentes entre los
datos.
2. Permitir la recuperación sencilla de los datos en respuesta a las solicitudes de consultas y reportes.
3. Simplificar el mantenimiento de los datos actualizándolos, insertándolos y borrándolos.
4. Reducir la necesidad de reestructurar o reorganizar los datos cuando surjan nuevas aplicaciones.
En términos más sencillos la normalización trata de simplificar el diseño de una base de datos, esto a
través de la búsqueda de la mejor estructuración que pueda utilizarse con las entidades involucradas en
ella.
Pasos de la normalización:
1. Descomponer todos los grupos de datos en registros bidimensionales.
2. Eliminar todas las relaciones en la que los datos no dependan completamente de la llave primaria
del registro.
3. Eliminar todas las relaciones que contengan dependencias transitivas.
La teoría de normalización tiene como fundamento el concepto de formas normales; se dice que una relación está
en una determinada forma normal si satisface un conjunto de restricciones.
4.2. PRIMERA Y SEGUNDA FORMA NORMAL
Una afinidad es una tabla de dos dimensiones. Cada hilera en la tabla tiene datos que pertenecen a alguna cosa o
una parte de alguna cosa. Cada columna de la tabla contiene datos referentes a un atributo. Las hileras de
denominan tuplas y las columnas atributos.
PRIMERA FORMA NORMAL. Cualquier tabla de datos que cumpla con la definición de una afinidad, se dice que
esta en la primera forma normal. Para que una tabla sea una afinidad, debe cumplirse lo siguiente: la celda de la
tabla debe poseer valores simples y no se permiten grupos ni arreglos repetidos como valores. Todos los ingresos en
cualquier columna (atributo), deben ser del mismo tipo. Cada columna debe tener un nombre único, el orden las
columnas en la tabla no es importante Dos hileras en una tabla no deben ser idénticas.
La siguiente afinidad esta en primera forma normal
SID ACTIVIDAD CUOTA

100 ESQUI 200
150 NATACION 50
175 SQUASH 50
200 NATACION 50
SEGUNDA FORMA NORMAL.- Para entender la segunda forma normal, consideramos la figura anterior. Tal afinidad
posee anomalías de modificación. Si se elimina la tupla para estudiante 175, se perderá el hecho de que SQUASH
43
cuesta $50. Tampoco se puede ingresar una actividad hasta que se inscriba un estudiante. La afinidad esta expuesta
a anomalías de eliminación y de inserción.
El problema con tal afinidad es que posee una dependencia que involucra solo parte de la clave. La clave es la
combinación (Clave, actividad), la afinidad contiene una dependencia, Actividad Cuota. El determinante de esta
dependencia (Actividad) es la parte de la clave (SID, Actividad). Se dice que cuota es parcialmente dependiente de la
clave de la tabla. No habría anomalías de modificación si cuota dependiera por completo de la clave. Para eliminar
las anomalías se debe separar la afinidad en dos afinidades.
Esta situación conduce a la definición de segunda forma normal: Una afinidad esta en segunda forma normal si
todos sus atributos que no son claves dependen por completo de la clave.
De acuerdo con esta definición, cada afinidad que tiene un atributo único como clave, esta en segunda forma
normal. La clave es solo un atributo, en forma predeterminada, cada atributo que no es clave depende por completo
de la clave; no puede haber dependencias parciales. La segunda forma normal solo hace referencia a afinidades con
claves compuestas.
La afinidad ACTIVIDADES una vez aplicada la segunda forma normal quedaría:
AFINIDAD ESTU-ACT ACT-COST

CLAVE: SID CLAVE:ACTIVIDAD
SID ACTIVIDAD ACTIVIDAD CUOTA
100 ESQUI ESQUI 200
150 NATACION NATACION 50
175 SQUASH SQUASH 50
200 NATACION
4.3 TERCERA Y FORMAL NORMAL DE BOYCE-CODD
TERCERA FORMA NORMAL.- Las afinidades en la segunda forma normal también tienen anomalías. Considerando
la afinidad VIVIENDA de la siguiente figura. La clave es SID y las dependencias funcionales son SID Edificio y
Edificio Cuota. Estas dependencias surgen porque cada estudiante vive en un edificio y cada edificio tiene una
cuota. Cada estudiante que vive en Randolph Hall paga $1200 por trimestre.
SID EDIFICIO CUOTA

100 RANDOLPH 1200
150 INGERSOLL 1100
200 RANDOLPH 1200
250 PITKIN 1100
300 RANDOLPH 1200
Debido a que SID determina Edificio y Edificio determina cuota. Indirectamente SID Cuota. Un arreglo de
dependencias funcionales como este se denomina una dependencia transitiva, ya que SID determina Cuota por
medio del atributo Edificio.
Por esta dependencia transitiva, SID es la clave y la afinidad esta en segunda forma normal. A pesar de esto
vivienda tiene anomalías.
Para eliminar las anomalías de una afinidad en segunda forma normal, debe quitarse la dependencia transitiva, lo
que conduce a la definición de una tercera forma normal: Una afinidad está en tercera forma normal si está en
segunda forma normal y no tiene dependencias transitivas.
La afinidad vivienda puede dividirse en dos afinidades en tercera forma normal.
SID EDIFICIO EDIFICIO CUOTA

100 RANDOLPH RANDOLPH 1200
150 INGERSOLL INGERSOLL 1100
200 RANDOLPH PITKIN 1100
250 PITKIN
300 RANDOLPH
44
FORMA NORMAL DE BOYCE-CODD
Incluso las afinidades en tercera forma normal pueden tener anomalías. Considere la siguiente afinidad ASESOR.
Suponga que los requerimientos que sustentan esta afinidad son que un estudiante (SID), pueda tener una ó más
especialidades, una especialidad puede tener varios miembros de la facultad (nombreF) como consejeros, y un
miembro de la facultad (nombreF), sólo imparte asesoría en una área de especialidad.
SID ESPECIALIDAD NOMBREF

100 MATEMATICAS CAUCHY
150 PSICOLOGIA JUNG
200 MATEMATICAS RIEMANN
250 MATEMATICAS CAUCHY
300 PSICOLOGIA PERLS
300 MATEMATICAS RIEMANN
Puesto que los estudiantes pueden tener varias especialidades, SID, no determina la especialidad. Como los
estudiantes pueden tener varios asesores, SID tampoco determina nombre F. SID por si mismo no puede ser una
clave.
La combinación (SID, especialidad) determina nombre F y la combinación (SID, nombre F), determina
especialidad. Cualquiera de las combinaciones puede ser una clave. Dos ó mas atributos o conjuntos de atributos
que puedan ser una clave, se denominan claves candidatas. Cualquiera de las candidatas que se seleccione para
ser la clave se denomina clave primaria.
ASESOR está en primera forma normal. También está en segunda forma normal, pues cualquier atributo que
no es clave depende de toda la clave (sin importar cual clave candidata se seleccione). También está en tercera
forma normal porque no tiene dependencias transitivas. A pesar de todo esto tiene anomalías por modificación.
Suponga que estudiante 300 deja la escuela, si quita la tupla de estudiante 300 se perderá el hecho de que
Perls imparte asesoría en psicología. Ésta es una anomalía de eliminación. En forma similar ¿Cómo se almacena el
hecho de que Keynes asesor en economía? No es posible, hasta que un estudiante se inscribe en tal materia. Esta
es una anomalía de inserción.
Situaciones como la anterior conducen a la definición de la forma normal de Boyce-Codd (BCNF): Una afinidad
está en BCNF si cada determinante es una clave candidata. ASESOR no está en BCNF puesto que tiene un
determinante, nombre F, que no es una clave candidata.
ASESOR puede descomponerse en dos afinidades que no tengan anomalías.
ESTU-ASE ASE-MATERIA
(SID, NOMBREF) (NOMBREF,MATERIA)
SID NOMBREF NOMBREF MATERIA
100 CAUCHY CAUCHY MATEMATICAS
150 JUNG JUNG PSICOLOGIA
200 RIEMANN RIEMANN MATEMATICAS
250 CAUCHY PERLS PSICOLOGIA
300 PERLS
300 RIEMANN
4.4 CUARTA Y QUINTA FORMA NORMAL
CUARTA FORMA NORMAL
Considere usted la afinidad ESTUDIANTE que muestra la relación entre estudiantes, especialidades y actividades.
Suponga que los estudiantes pueden inscribirse en varias especialidades y participar en diversas actividades. La
única clave es la combinación de los atributos (SID, Especialidad, Actividad). La estudiante 100 tiene su especialidad
45
en Música y Contabilidad y también participa en Natación y Tenis. El estudiante 150 sólo tiene especialidad en
Matemáticas y participa en Carrera.
ESTUDIANTE(SID, ESPECIALIDAD, ACTIVIDAD)
SID ESPECIALIDAD ACTIVIDAD

100 MUSICA NATACION
100 CONTABILIDAD NATACION
100 MUSICA TENIS
100 CONTABILIDAD TENIS
150 MATEMATICAS CARRERA
¿Cuál es la relación entre SID y especialidad? No es una dependencia funcional porque los estudiantes
pueden tener distintas especialidades. Un valor único de SID puede poseer muchos valores de Especialidad. Esto
también se aplica a la relación entre SID y Actividad.
Tal dependencia por atributos de denomina dependencia de valores múltiples. Las dependencias de valores
múltiples conducen a anomalías de modificación. Observe la redundancia en datos de la figura. La estudiante 100
tiene cuatros registros, cada uno de los cuales muestra una de sus especialidades junto con una de sus actividades.
Si los datos se almacenaran con menos hileras: si hubiera sólo dos tuplas, uno para música y natación y uno para
contaduría y tenis, las implicaciones serían engañosas. Parecería que la Estudiante 100 sólo nadó cuando tenía
música como especialidad y jugó tenis sólo cuando tenía contaduría como especialidad. Esa interpretación no es
lógica. Sus especialidades y sus actividades son independientes entre sí. Para prevenir tales engañosas
conclusiones se almacenan todas las combinaciones de especialidades y actividades.
Suponga que, debido a que la Estudiante 100 decide apuntarse en Esquí, se debe agregar la tupla (100,
MÚSICA, ESQUÍ), como en la figura. La afinidad en este punto indica que la Estudiante 100 esquía cuando estudia
música, pero no cuando tiene contaduría como especialidad. A fin de mantener la consistencia en los datos, se debe
agregar una hilera para cada uno de una de sus actividades ligadas con Esquí. También se debe agregar la hilera)
(100, CONTABILIDAD, ESQUÍ), como en la figura. Ésta es una anomalía de actualización: hay que hacer
demasiadas actualizaciones para realizar un cambio en los datos.
ESTUDIANTE(SID, ESPECIALIDAD, ACTIVIDAD)
SID ESPECIALIDAD ACTIVIDAD

100 MUSICA ESQUI
100 CONTABILIDAD ESQUI
100 MUSICA NATACION
100 CONTABILIDAD NATACION
100 MUSICA TENIS
100 CONTABILIDAD TENIS
150 MATEMATICAS CARRERA
Existe una dependencia de valores múltiples cuando una afinidad tiene al menos tres atributos, dos de los
cuales poseen valores múltiples y sus valores dependen sólo del tercer atributo. En otras palabras en la afinidad R
(A, B, C) existe una dependencia de valores múltiples si A determina valores múltiples de B, A determina valores
múltiples de especialidad, y SID determina valores múltiples de Actividad, pero Especialidad y Actividad son
independientes entre sí.
Observe otra vez la figura. Vea cómo están escritas las dependencias de valores múltiples: SID Especialidad
y SID Actividad. Esto se lee "SID multidetermina Especialidad, y SID multidermina Actividad". Esta afinidad está en
BCNF (2NF porque todo es clave; 3NF porque no tiene dependencias transitivas; y BCNF porque no tiene
determinantes que no son claves). Hemos visto que posee anomalías: si un estudiante toma otra especialidad, se
debe ingresar un tuple para la nueva especialidad, y juntarlo con cada una de las actividades del estudiante. Sucede
lo mismo si un estudiante se inscribe en una nueva actividad. Si un estudiante deja una especialidad se deben
eliminar cada uno de los registros que contienen tal materia. Si participa en cuatro actividades, habrá cutro tuples
que contengan la especilidad que ha dejado y deberá borrarse cada uno.
Para evitar tales anomalías, se deben las dependencias de valores múltiples. Esto se hace construyendo dos
afinidades, donde cada una almacena datos para solamente uno de los atributos de valores múltiples. La afinidades
resultantes no tienen anomalías. Ellas son ESTU-ESPECIALIDAD (SID, Especialidad) y ESTU-ACT (SID, Actividad).
46
A partir de estas observaciones, se define la cuarta forma normal: Una afinidad está en cuarta forma normal si
está en BCNF y no tiene dependencias de valores múltiples.
Quedaria de la siguiente manera:
ESTU-ESPECIALIDAD ESTU-ACT
(SID, ESPECIALIDAD) (SID, ACTIVIDAD)
SID ESPECIALIDAD SID ACTIVIDAD
100 MUSICA 100 ESQUI
100 CONTABILIDAD 100 NATACION
150 MATEMATICAS 100 TENIS
150 CARRERA
QUINTA FORMA NORMAL
La quinta forma normal se refiere a dependencias que son extrañas. Tiene que ver con afinidades que pueden
dividirse en subafinidades (como se ha venido haciendo), pero que no pueden reconstruirse. La condición bajo la
cual surge esta situación, no tiene significado intuitivo preciso. No se sabe cuáles son las consecuencias de tales
dependencias, incluso si tienen consecuencias prácticas. Para más información acerca de la quinta forma normal,
consulte la investigación de Date citada antes en este capítulo.
Cada una de las formas normales que se han analizado, fueron identificadas por investigadores que
encontraron anomalías de modificación con afinidades en la segunda forma normal condujeron a la definición de la
tercera forma normal. Aunque cada forma normal resolvía algunos de los problemas identificados con la forma
normal anterior, nadie podía saber cuáles problemas todavía no habías sido identificados. Cada paso, se avanzaba
a una definición estructurada de las bases de datos, nadie podía garantizar que no se encontarían más anomalías.
En la siguiente sección se estudia una forma normal que garantiza que no habrá anomalías de ningún tipo. Cuando
se ponen las afinidades en esa forma, se sabe que no pueden ocurrir ni siquiera las extrañas anomalías asociadas
con la quinta forma normal.
4.5 OTROS ENFOQUES HACIA EL DISEÑO DE BASES DE DATOS
Considerando la base de datos de la siguiente figura, se muestra una relación info-préstamo descompuesta en
FNRP. En dicha base de representa una situación en la cual aún no se ha determinado el importe del préstamo P-58.
pero se quiere grabar el resto de los datos del préstamo. Si ejecutamos la reunión natural de estas relaciones, todas
la tuplas que se refieren al préstamo P-58 desaparecen. En otras palabras. No hay una relación info-préstamo que se
corresponda con las relaciones de la figura. Las tuplas que desaparecen cuando se ejecuta la reunión natural son
tuplas colgantes. Formalmente, sean r1 (R1) , r2 (R2) ,..., rn(Rn) un conjunto de relaciones. Una tupla t de la relación ri
es una tupla colgante si t no está en la relación.
La forma normal de reunión por proyección (FNRP) se define de la forma similar a la FNBC y 4FN, salvo que se
usan las dependencias de reunión.
Un esquema de relación R esta en FNRP respecto a un conjunto D dependencias funcionales, multivaloradas y

de reunión si para toda dependencia de reunión perteneciente a D de la forma * (R1, R2,...,RN), donde casa R1 R y
R = R1 U R2 ... U Rn, se cumple al menos una de las siguientes condiciones:
 * (R1, R2,...,RN) es una dependencia de reunión.

 Cada Ri es una superclave de R.
Un diseño de base de datos está en FNRP si cada miembro del conjunto de esquemas de relación que
constituye el diseño está en FNRP. Alguno autores denominan también quinta forma normal (5FN) a la FNRP.
Descomposición en FNRP.
47
NOMBRE-SUCURSAL NUMERO-PRÉSTAMO
COLLADO MEDIANO P-58
NUMERO-PRESTAMO IMPORTE
NUMERO-PRESTAMO NOMBRE-CLIENTE
P-58 GONZALEZ
Las tuplas colgantes se pueden dar en aplicaciones prácticas de bases de datos. Representan información
incompleta, como se vio en el ejemplo, donde se quiere almacenar datos sobre un préstamo que aún esta en
proceso de negociación.
A la relación r1 reunión natural con r2 se le llama relación universal, ya que involucra todos los atributos del
universo definido por R1 U R2 U...U Rn.
El único modo de que se puede escribir una relación universal para el ejemplo anterior, es incluir valores nulos
en la relación universal. Debido a la dificultad para manejar valores nulos, puede ser mejor considerar las relaciones
del diseño descompuesto como representantes de la base de datos, en vez de la relación universal cuyo esquema se
descompone durante el proceso de normalización.
Nótese que se puede introducir toda la información incompleta en la base de datos. Sin recurrir al uso de
valores nulos. Por ejemplo, no se puede introducir un número de préstamo a menos que no se sepa algo de lo
siguiente:
 El nombre del cliente.

 El nombre de la sucursal.
 El importe del préstamo.
Por tanto, una descomposición particular define una forma restringida de la información incompleta que es
aceptable en la base de datos.
Las formas normales que se definieron generan buenos diseños de bases de datos desde el punto de vista de
la representación de información incompleta.
Si se permiten tuplas colgantes en la base de datos, puede ser preferible tomar una vista alternativa del
proceso de diseño de bases de datos. Un lugar de descomponer una relación universal, se puede sintetizar una serie
de esquemas en forma normal a partir de un conjunto de atributos dados.
Otra consecuencia de este enfoque de diseño de bases de datos es que los nombres de los atributos deben ser
únicos en la relación universal. No se puede usar nombre para referirse a nombre-cliente y nombre-sucursal.
Sin embargo, en un lenguaje como SQL no hay operaciones de reunión natural, por lo que en una consulta que
incluya a préstamo-sucursal y préstamo-cliente se debe eliminar la ambigüedad en las referencias a nombre
poniendo como prefijo el nombre de la relación. En estos entornos, los diversos significados de nombre son menos
problemáticos y se pueden usar fácilmente.
El uso del supuesto de papel único es generalmente preferible a reutilizar el mismo nombre para varios
atributos. Cuando no se cumple el supuesto del papel único, el diseñador de la base de datos debe tener un cuidado
especial al construir un diseño normalizado de la base de datos relacional.
UNIDAD V. MODELO DE DATOS DE RED
5.1 CONCEPTOS BÁSICOS.

48
Una base de datos de red como su nombre lo índica, esta formado por una colección de registros, los cuales están
conectados entre sí por medio de enlaces. El registro es similar a una entidad como las empleadas en el modelo
entidad-relación.
Un registro es una colección de campos (atributos), cada uno de los cuales contiene solamente almacenado
un solo valor, el enlace es la asociación entre dos registros exclusivamente, así que podemos verla como una
relación estrictamente binaria.
Para mostrar la estructura de los registros en una base de datos de red, consideremos la base de datos alumno-
materia, los registros en lenguaje Pascal entonces quedarían como sigue:
type alumno=record
NombreA:string[30];
Control:string[8];
Esp: string[3];
end;
type materia = record
Clave:string[7];
NombreM:string[25];
Cred=string[2];
end;
5.2 DIAGRAMAS DE ESTRUCTURA DE DATOS.
Un diagrama de estructura de datos es un esquema que representa el diseño de una base de datos de red. Este
modelo se basa en representaciones entre registros por medio de ligas, existen relaciones en las que participan solo
dos entidades(binarias) y relaciones en las que participan más de dos entidades (generales) ya sea con o sin atributo
descriptivo en la relación. Los diagramas constan de dos componentes básicos:
Rectángulos: representan a los campos del registro.
Líneas: representan a los enlaces entre los registros.
Un diagrama de estructura de datos de red, especifica la estructura lógica global de la base de datos; su
representación gráfica se basa en el acomodo de los campos de un registro en un conjunto de celdas que se ligan
con otro(s) registro(s), ejemplificaremos esto de la siguiente manera:
Consideremos la relación alumno-cursa-materia donde la relación cursa no tiene atributos descriptivos:

49
Nombre NomM
Control Clave Creditos

Esp
Alumno Cursa Materia
Las estructuras de datos según la cardinalidad se representan en los siguientes casos:
Cuando el enlace no tiene atributos descriptivos
Caso 1. Cardinalidad Uno a Uno.
Registro Alumno Registro Materia
Control NombreA Esp Clave NombreM Cred

Enlace
Diagrama de estructura de datos

Caso 2. Cardinalidad Muchos a uno.

Enlace
Caso 3. Cardinalidad Muchos a muchos.

50

Enlace
Cuando el enlace tiene atributos descriptivos.
Consideremos que a la relación cursa le agregamos el atributo Cal (calificación), nuestro modelo E-R quedaría de
la siguiente manera:
Nombre NomM
Cal
Esp
La forma de convertir a diagramas de estructura de datos consiste en realizar lo siguiente:
1. Realizar la representación de los campos del registro agrupándolos en sus celdas correspondientes. 2.
Crear nuevo registro, denominado Calif, para este caso, con un solo campo, el de cal (calif). 3. Crear los
enlaces indicando la cardinalidad de :
AluCal, del registro Calif al registro Alumno.
MatCal, del registro Calif al registro Materia. AluCal y MatCal son solo los nombres que emplearemos para
identificar el enlace, pueden ser otros y no son empleados para otra cosa.
Los diagramas de estructuras de datos según la cardinalidad

se transforman en:
Caso 1. Cardinalidad uno a uno.

51

AluCal MatCal
Cal
Registro Calif
Caso 2. Cardinalidad Uno a muchos.

AluCal MatCal
Cal
Registro Calif
Caso 3. Cardinalidad Muchos a muchos.

AluCal MatCal
Cal
Registro Calif
DIAGRAMAS DE ESTRUCTURA DE DATOS CUANDO INTERVIENEN

MÁS DE DOS ENTIDADES Y EL ENLACE NO TIENE ATRIBUTOS DESCRIPTIVOS.
52
Consideremos que a la relación alumno-cursa-materia le agregamos la entidad maestro, quien es el que imparte
dicha materia.
Nuestro diagrama E-R quedaría de la siguiente manera:
Nombre NomM

Esp
Maestro
NoEmp RFC
Nombre Plaza
La transformación a diagramas de estructura de datos se realiza mediante los siguientes pasos:
1.Crear los respectivos registros para cada una de las entidades que intervienen en el modelo.
2. Crear un nuevo tipo de registro que llamaremos Reenlace, que puede no tener campos o tener solo uno que
contenga un identificador único, el identificador lo proporcionará el sistema y no lo utiliza directamente el programa
de aplicación, a este registro se le denomina también como registro ficticio o de enlace o unión.
Siguiendo los pasos anteriores nuestra estructura finalmente es: (Considerando una relación con cardinalidad Uno
a Uno)
Registro Alumno Registro Maestro Registro Materia
NombreA Control Esp NoEmp Nombre Plaza RFC NombreA Clave Cred
MaRenl
ARenl MRenl
Renlace
53
Ahora si nuestro enlace tuviera atributos descriptivos, se crea el registro con los campos respectivos y se liga
indicando el tipo de cardinalidad de que se trate.
En este caso tomamos el ejemplo anterior con cardinalidad uno a uno y le agregamos a la relación el atributo calif.
(calificación).
MaeCur
ACur Calif MatCur
5.3 EL MODELO CODASYL DBTG.
Este modelo fue desarrollado en 1971 por un grupo conocido como CODASYL: Conference on Data System
Languages, Data Base Task Group, de ahí el nombre; este comité es mejor conocido por haber sido el grupo que
desarrolló los estándares para COBOL.El modelo CODASYL ha evolucionado durante los últimos años y existen
diversos productos DBMS orientados a transacciones que se basan sobre el, sin embargo hoy día, estos productos
están en declinación, ya que este modelo es complejo y no cohesivo; los diseñadores y programadores deben de
tener mucho cuidado al elaborar bases de datos y aplicaciones DBTG, además este modelo tiene mucho enfoque de
COBOL, gran parte a las deficiencias detectadas en la actualidad se le atribuye a que este modelo fue desarrollado
muy pronto antes de que se establecieran correctamente los conceptos esenciales de la tecnología de bases de
datos.
La historia del modelo CODASYL es compleja. Se desarrollaron tres versiones distintas y, aunque el modelo
de datos fue sometido dos veces a la consideración del American Nartional Standards Institute (ANSI) como una
norma nacional, jamás fue aceptado. En su lugar, en agosto de 1986, se reconoció como el estándar nacional de
base de datos el modelo relacional SQL.
Las funciones y características básicas de las tres versiones del modelo CODASYL son iguales. La mayor
parte de los productos DBMS comerciales basados en este modelo se basan en la primera, desarrollada en 1971.
Los modelos posteriores de 1978 y 1981 modificaron parte del lenguaje y la sintaxis, agregaron características de
soporte para la definición de restricciones e incluyeron otras modificaciones.
En el modelo DBTG solamente pueden emplearse enlaces uno a uno y uno a muchos. En este modelo existen dos
elementos principales que son el dueño y el miembro, donde solo puede existir un dueño y varios miembros, donde
cada miembro depende solamente de un dueño.
Para mejor entendimiento de este modelo ilustremos el siguiente:
Empleando el ejemplo de la relación Alumno-cursa-Materia.
Si la relación es uno a muchos sin atributos descriptivos, entonces el diagrama de estructura de datos apropiado es:
54

Enlace
Si la relación tiene un atributo descriptivo, como el de calif, entonces el diagrama de estructura de datos apropiado
es:

AluCal MatCal
Cal
Registro Calif
Si la relación fuera de muchos a muchos el algoritmo de transformación seria como el siguiente considerando que la
relación no tiene atributos descriptivos, entonces:
1. Crear los registros correspondientes de las entidades involucradas (alumno, materia).
2. Crear un nuevo tipo de registro ficticio, reenlace que puede no tener campos o tener sólo uno que contenga un
identificador único definido externamente.
3. Crear los enlaces correspondientes muchos a uno.

AluCal MatCal
Reenlace

55
En el caso de las relaciones generales (es decir, no binarias), el algoritmo de transformación es el mismo empleado
para el estructurado de los diagramas de los modelos de red donde intervienen más de 2 entidades.
Por ejemplo consideremos la agregación de la entidad maestro, entonces para este caso resulta la estructura
siguiente:
MaRenl
ARenl MRenl
Renlace
Conjuntos DBTG
Como se mencionó anteriormente en este modelo solo pueden utilizarse enlaces muchos a uno y uno a uno, así
un diagrama de estructura de datos en forma general de este modelo sería:
Conjunto DBTG
En el modelo DBTG, esta estructura de denomina conjunto DBTG. El nombre que se le asigna al conjunto
generalmente es el mismo que el de la relación que une a las entidades.
En todo conjunto DBTG de este tipo, el tipo de registro A se denomina dueño (o padre) del conjunto, el tipo de
registro B se le denomina miembro (o hijo) del conjunto. Cada conjunto DBTG puede tener cualquier numero de
ocurrencias del conjunto. Puesto que no se permiten enlaces del tipo muchos a muchos, cada ocurrencia del
conjunto tiene exclusivamente un dueño y cero o más registros miembros. Además ningún registro puede participar
en más de una ocurrencia del conjunto en ningún momento. Sin embargo, un registro miembro puede participar
simultáneamente en varias ocurrencias de diferentes conjuntos DBTG.
Podemos ejemplificar las ocurrencias que se pueden presentar, como:

56
a1 a2 a3
b1 b2 b3 b4 b5 b6
Tres apariciones de un conjunto
5.4 RECUPERACIÓN DE DATOS EN DBTG
El lenguaje de manipulación de datos de la propuesta DBTG consiste en un número de órdenes que se incorporan
en un lenguaje principal.
La mayor parte de los comandos de manejo de datos en DBTG de CODASYL tienen dos pasos. En primer lugar,
se emite un comando FIND para identificar el registro sobre el cual se va a actuar. El comando FIND no lee, procesa
el registro indicado; sólo identifica un registro para que lo localice el DBMS. Una vez identificado el registro, un
segundo comando DML puede emitirse para que se lleve a cabo una operación sobre él. Patrones típicos son FIND,
GET, o bien, FIND, MODIFY; o bien FIND, ERASE.
Cuando el programa emite un comando FIND, se localiza un registro y su identidad permanece almacenada en
una variable especial llamada indicador de posición. Después, cuando se emite un comando GET, MODIFY,
ERASE o bien otro, el DBMS hace referencia al indicador de posición para determinar cuál es el registro sobre el que
ha de actuar. Los indicadores de posición también se utilizan como puntos de referencia para los comandos del
procesamiento secuencial como son FIND NEXT o FIND PRIOR.
Las operaciones utilizadas para la recuperación de datos son:
FIND: Que localiza a un registro en la base de datos y da valores a los punteros de actualidad correspondientes
GET: Copia el registro al que apunta el actual de unidad de ejecución de la base de datos ala plantilla adecuada en
el área de trabajo de programa.
La orden FIND tiene varias formas, en este caso estudiaremos 2 ordenes FIND diferentes para localizar los registro
individuales de la base de datos; La orden más sencilla es de la forma:
find any < tipo de registro > using < campo de registro >
Esta orden localiza un registro del tipo <tipo registro> cuyo valor de < campo de registro> es el mismo que el del
valor de <campo de registro> en la plantilla del <tipo de registro> en el área de trabajo del programa. Una vez que se
encuentra ese registro se modifican los siguientes punteros para que apunten a ese registro:
 El puntero actual de unidad de ejecución
 El puntero de actualidad de tipo de registro que corresponde a <tipo de registro>.
 Para cada conjunto en el que participe ese registro, el puntero de actualidad de conjunto apropiado.
57
Para ilustrar lo anterior, construyamos una consulta en DBTG que nos muestre el
número de control del alumno Juan Pérez. (consideremos el modelo alumno-materia ).
alumno.nombre:="Juan Pérez";
find any alumno using nombrea;
get alumno;
print("alumno.control");
Pueden existir varios registros con el valor especificado. La orden find localiza el primero de ellos en un orden
previamente especificado. Para localizar otros registros de la base de datos que pudieran tener el mismo campo
<campo de registro, utilizamos la orden
find duplicate <tipo de registro> using <campo de registro>
Que localiza al siguiente registro (según un orden que depende del sistema) que tiene el valor de <campo
registro>.ejemplo:
Alumno.NombreA:="Juan Pérez";
find any Alumno using NombreA;
while DB-Status = 0 do
begin
get Alumno;
print (Alumno.control);
find duplicate Alumno using NombreA;
end;
Se ha encerrado parte de la consulta en un ciclo while ya que no sabemos por adelantado cuántos nombres Juan
Pérez pueden existir. Salimos del bucle cuando DB-Status<>0, esto indica que la última operación find duplicate
falló, lo que implica que ya hemos agotado todos los registros con esos datos.
5.5 ACTUALIZACIÓN EN DBTG.
Creación de nuevos registros.
La orden para crear un nuevo registro es:

58
Store <tipo de registro>
Esta técnica nos permite crear y añadir solamente un registro a la vez.
Para ejemplificar consideremos el caso siguiente:
Deseamos registrar a un nuevo alumno de nombre "Rocío Veleta", la instrucción para esto es:
Alumno.NombreA:="Rocío Veleta";
Alumno.control:="93551028";
Alumno.Esp:="LAE";
Store Alumno;
Modificación de un registro existente.
Para realizar la modificación a los registros, primero se debe encontrar ese registro en la base de datos, pasarlo a
la memoria principal y efectuar las modificaciones deseadas, posteriormente actualizamos el puntero de actualidad
hacia el registro a modificar y ejecutamos la orden Modify.
Modify <tipo de registro>
Para que el sistema se entere que se va a realizar una modificación se emplea la orden for update.
Ejemplo: Deseamos cambiar la Especialidad del alumno de nombre Rocío Veleta, por LI.
Aumno.NombreA:="Rocío Veleta";
find for update any Alumno using nombreA;
get Alumno.Esp :="LI";
modify Alumno;
Las líneas de código antes descritas, primero requieren del dato por el cual se realizará la búsqueda del registro,
la orden find for update any establecen el tipo de registro que se usara, using indica el campo por el cual debe
buscar la coincidencia para la modificación, get se antepone la línea de modificaciones que se realizaran sobre el
registro y finalmente ya que el registro fue modificado se ejecuta la instrucción modify para activar las
actualizaciones ejecutadas.
Eliminación de registros.
Para efectuar la eliminación de los registros es necesario tener el puntero de actualidad apuntando al registro que
deseamos borrar, después se ejecuta al orden:
erase <tipo de registro>

59
Esta instrucción al igual que la orden modify, requiere de la declaración de las instrucciones for update en la orden
find.
Ejemplo:Consideremos que deseamos eliminar el alumno cuyo número de control es 93551029 que pertenece al
alumno Juan Pérez.
Fin:=false;
Alumno.NombreA:="Juan Pérez";
find any Alumno using NombreA;
while DB-Status=0 and not fin do
begin
get Alumno;
if Alumno.control=93551029 then
begin
erase Alumno; fin:=true; end
else
find for update next Alumno with Alren1(*Registro reenlace*)
end;
Es posible eliminar toda una secuencia de conjunto encontrando al dueño del mismo, para ello se ejecuta la orden:
erase all <tipo de registro>
Esto borrara al dueño del conjunto y a todos sus miembros, si un miembro de un conjunto dueño de otro conjunto,
también se eliminaran los miembros de ese conjunto, esta operación es recursiva.
Ejemplo: Consideremos que deseamos borrar al Alumno de nombre Juan Pérez. y todas sus registros de materias,
entonces:
Alumno.NombreA :="Juan Pérez";
find for update any Alumno using NombreA;
erase all Alumno;
5.6 PROCESAMIENTO DE CONJUNTOS EN DBTG.
* La sentencia de conexión (connect)
Esta sentencia permite la inserción de un registro en un conjunto.

60
La sintaxis es:
Connect <tipo de registro> tp <tipo de conjunto>
La inserción de un registro nuevo se realiza creando el nuevo registro buscar el dueño(propietario) del conjunto en
donde el puntero de actualidad apuntara a el lugar adecuado donde debe insertarse el nuevo registro y
posteriormente insertamos el registro ejecutando la sentencia Connect.
Ejemplo: Considérese la consulta DBTG para el modelo alumno-materia para crear el registro de un nuevo
alumno en la materia Base de Datos.
Alumno.Control:=96552121;
Alumno.NombreA:=’Armando Sánchez’;
Alumno.Esp:=’ISC’;
Store Alumno;
Materia.Clave:=’SCB9333’;
find any Materia using Clave;
connect Alumno to AlRen1; (*Conectar el registro al reenlace *);
* Sentencia de desconexión Disconnect
Esta sentencia se utiliza para "desconectar" a un registro de un conjunto, es necesario que los punteros de
actualidad tanto del registro como del conjunto y del registro apunten a los elementos adecuados. posteriormente se
elimina el registro deseado aplicando la sentencia Disconect.
Sintaxis:
Disconnect <Tipo registro> From <Tipo de conjunto>
Esta operación solamente desconecta al registro no lo elimina de la base de datos para eliminarlo totalmente se
utiliza la orden Erase.
Sintaxis:
Erase <registro>
Sentencia de reconexión reconnect.
La función permite mover un registro de un conjunto hacia oro conjunto, para ello se requiere encontrar el registro y
el dueño apropiado.
Sintaxis:
reconnect <registro> to <Conjunto>
* Inserción y retención en conjuntos.
Cuando se define un nuevo conjunto, debemos especificar cómo se van a insertar los registros miembros. Además
de especificarse las condiciones bajo las cuales debe retenerse a un registro.
61
* Inserción en conjuntos.
Un registro recién creado, del tipo registro de un tipo de conjunto puede añadirse a una ocurrencia de un conjunto
manual o automáticamente. El modo se específica al definir el conjunto mediante la orden:
Insertion is <modo de inserción>
donde modo de inserción puede tomar los valores Manual y Automática mediante las siguientes ordenes: connect
<tipo registro> tp <tipo conjunto> y store <Tipo registro> respectivamente. En ambos casos el puntero de actualidad
del conjunto debe apuntar al conjunto sobre el cual se va a realizar la inserción.
* Retención en conjuntos.
Para que se logre la retención de miembros en un conjunto se realiza a través de una serie de restricciones que se
especifican en el momento de definir el conjunto.
Sintaxis:
retention is <modo de retención>
Donde modo de retención puede ser de tres formas:
- Fija: Una vez insertado un registro miembro en un conjunto no podrá sacarse del conjunto. En caso de querer
cambiar dicho registro primero se tendrá que eliminar el registro y volver a crearlo e insertarlo en el conjunto
deseado.
- Obligatoria: Permite la reconexión de registros miembros solo en conjuntos del mismo tipo.
- Opcional: No tiene limitaciones.
UNIDAD VI. MODELO DE DATOS JERÁRQUICO
6.1 CONCEPTOS BÁSICOS.
Una base de datos jerárquica consiste en una colección de registros que se conectan entre sí por medio de
enlaces. Los registros son similares a los expuestos en el modelo de red. Cada registro es una colección de campos
(atributos), que contienen un solo valor cada uno de ellos. Un enlace es una asociación o unión entre dos registros
exclusivamente. Por tanto, este concepto es similar al de enlace para modelos de red.
A diferencia del enfoque de red, cuyas guías están impuestas por el comité CODASYL, el enfoque jerárquico
no tiene normativa en la industria El punto a favor de los sistemas jerárquicos es que fueron los primeros que
aparecieron totalmente desarrollados en el mercado. Los sistemas Information Management System (IMS) de IBM,
es el DBMS jerárquico más conocido, es uno de los sistemas disponibles más grandes y complejos.
Consideremos la base de datos, nuevamente, que contiene la relación alumno - materia de un sistema escolar.
Existen dos tipos de registros en este sistema, alumno y materia. El registro alumno consta de tres campos:
NombreA, Control y Esp; El registro Materia esta compuesto de tres campos: Clave, NombreM y Cred.
En este tipo de modelos la organización se establece en forma de árbol, donde la raíz es un nodo ficticio. Así
tenemos que, una base de datos jerárquica es una colección de árboles de este tipo.
El contenido de un registro específico puede repetirse en varios sitios(en el mismo árbol o en varios árboles).
6.2 DIAGRAMAS DE ESTRUCTURA DE ÁRBOL

62
Los diagramas de estructura de árbol es la representación de un esquema de la base de datos jerárquica, de ahí el
nombre, ya que un árbol esta desarrollado precisamente en orden descendente formando una estructura jerárquica.
Este tipo de diagrama está formado por dos componentes básicos:
 Rectángulos: que representan a los de registros.
 Líneas: que representan a los enlaces o ligas entre los registros.
Un diagrama de árbol tiene el propósito de especificar la estructura global de la base de datos.
Un diagrama de estructura de árbol es similar a un diagrama de estructura de datos en el modelo de red. La

principal diferencia es que en el modelo de red los registros se organizan en forma de un grafo arbitrario, mientras
que en modelo de estructura de árbol los registros se organizan en forma de un árbol con raíz.
Características de las estructuras de árbol:
 El árbol no puede contener ciclos.
 Las relaciones que existen en la estructura deben ser de tal forma que solo existan relaciones
muchos a uno o uno a uno entre un padre y un hijo.
NombreA Control Esp Alumno
NombreM Clave Cred Materia
En este diagrama podemos observar que las flechas están apuntando de padres a hijos. Un padre (origen de una
rama) puede tener una flecha apuntando a un hijo, pero un hijo siempre puede tener una flecha apuntando a su
padre.
El esquema de una base de datos se representa como una colección de diagramas de estructura de árbol. Para
cada diagrama existe una única instancia de árbol de base de datos. La raíz de este árbol es un nodo ficticio. Los
hijos de ese nodo son instancias de los registros de la base de datos. Cada una de las instancias que son hijos
pueden tener a su vez, varias instancias de varios registros.
Las representaciones según las cardinalidades son:
Consideremos la relación alumno-materia sin atributo descriptivo.

63
Nombre NomM

Esp
La transformación según las cardinalidades seria:
 Cuando la relación es uno a uno.
 Cuando la relación es uno a muchos.
 Cuando la relación es muchos a uno.

64
 Cuando la relación es muchos a muchos.
NombreM Clave Cred Materia NombreA Control Esp Alumno
NombreA Control Esp Alumno NombreM Clave Cred Materia
Cuando la relación tiene atributos descriptivos, la transformación de un diagrama E-R a estructura de árbol se lleva
a cabo cubriendo los siguientes pasos:
1. Crear un nuevo tipo de registro.
2. Crear los enlaces correspondientes.
Consideremos que a la relación Alumno-Materia añadimos el atributo Cal a la relación que existe entre ambas,
entonces nuestro modelo E-R resulta:
Añadir el diagrama E-R
Nombre NomM
Cal
Esp

65
Según las cardinalidades los diagramas de estructura de árbol pueden quedar de la siguiente manera:
 Cuando la relación es uno a uno.
Cal
 Cuando la relación es uno a muchos.
Cal
 Cuando la relación es Muchos a uno.
Cal
 Cuando la relación es Muchos a Muchos.

66
Si la relación es muchos a muchos entonces la transformación a diagramas de árbol es un poco más compleja
debido a que el modelo jerárquico solo se pueden representar las relaciones uno a uno o uno a muchos.
Existen varias formas distintas de transformar este tipo de relaciones a estructura de árbol, sin embargo todas las
formas constituyen la repetición de algunos registros.
La decisión de qué método de transformación debe utilizarse depende de muchos factores, entre los que se
incluyen:
 El tipo de consultas esperadas en la base de datos.
 El grado al que el esquema global de base de datos que se está modelando se ajusta al diagrama
E-R dado.
A continuación se describe la forma de transformar un diagrama E-R a estructura de árbol con relaciones muchos
a muchos. Suponemos el ejemplo de la relación alumno-materia.
1. Crear dos diagramas de estructura de árbol distintos T1 y T2, cada uno de los cuales incluye los
tipos de registro alumno y materia, en el árbol T1 la raíz es alumno y en T2 la raíz es materia.
2. Crear los siguientes enlaces:
 Un enlace muchos a uno del registro cuenta al registro Alumno, en T1
 Un enlace muchos a uno del tipo de registro cliente al tipo de registro materia en T2.
Como se muestra en el siguiente diagrama:
NombreA Control Esp Alumno NombreM Clave Cred Materia
Cal Cal
NombreM Clave Cred Materia NombreA Control Esp Alumno
6.3 RECUPERACIÓN DE DATOS
Para manipular la información de una base de datos jerárquico, es necesario emplear un lenguaje de manipulación
de datos, el lenguaje consta de varias órdenes que están incorporadas en un lenguaje principal, Pascal.
67
La orden Get: La recuperación de datos se realiza mediante esta orden, se realizan las siguientes acciones:
 Localiza un registro en la base de datos y actualiza a un puntero que es el que mantiene la

dirección del último registro accesado.
 Copia los datos solicitados a un tipo de registro apropiado para la consulta.
La orden Get debe especificar en cual de los árboles de la base de datos se va a buscar.
Para revisar todos los registros de forma consistente, se debe imponer un orden en los registros. El que
normalmente se usa es el preorden, el cuál consiste en iniciar la búsqueda por la raíz y continua buscando por los
subárboles de izquierda a derecha recursivamente. Así pues, empezamos por la raíz, visitamos el hijo más a la
izquierda, y así sucesivamente, hasta que alcancemos un nodo hoja (sin hijos). A continuación movemos hacia atrás
al padre de la hoja y visitamos el hijo más a la izquierda no visitado. Continuamos de esta forma hasta que se visite
todo el árbol.
Existen dos ordenes Get diferentes para localizar registros en un árbol de base de datos. La orden más simple
tiene la forma:
get first <Tipo de registro>
where <Condición>
La cláusula where es opcional. La <Condición> que se adjunta es un predicado que puede implicar a cualquier tipo
de registro que sea un antecesor de <tipo registro> o el <Tipo de registro> mismo.
La orden get localiza el primer registro (en preorden) del tipo <Tipo registro> en la base de datos que satisfaga la
<condición > de la cláusula where. Si se omite la cláusula where, entonces se localiza el primer registro del tipo <Tipo
registro>. Una vez que se encuentra ese registro, se hace que el puntero que tiene la dirección del último registro
accesado apunte a ese registro y se copia el contenido del registro en un registro apto para la consulta.
Para ilustrar lo anterior veamos los ejemplos:
Realicemos una consulta que imprima El nombre del alumno llamado Juan Pérez (consideremos la relación
Alumno-Materia que hemos estado manejando.)
get first Alumno
where Alumno.NombreA="Juan Pérez";
print (Alumno.Control)
Ahora consideremos que deseamos la consulta de los nombres de las materias en donde el alumno de nombre
Juan Pérez a obtenido una calificación igual a 100 (si es que existe)
get first Alumno
where Alumno.NombreA="Juan Perez" and Cursa.cal= 100;
if DB-Status=0 then print (Materia.NombreM);
La condición involucra a la variable DB-Status, la cual nos indica si se encontró o no el registro.
La orden get first, solo nos muestra el primer registro encontrado que satisfaga la orden de consulta, sin embargo
puede haber más de ellos, para localizar a los demás registros empleamos la orden Get next.
68
Cuyo formato es:
get next <Tipo de registro>
where <Condición>
La cual localiza el siguiente registro en preorden que satisface la condición. Si se omite la cláusula where,
entonces se localiza el siguiente registro del tipo <Tipo registro>.
6.4 ACTUALIZACIÓN DE DATOS.
Creación de nuevos registros.
La orden utilizada para la inserción de registros es:
insert <tipo de registro>
where <Condición>
donde: tipo registro contiene los datos de los campos del registro a insertar.
Sí se incluye la cláusula where, el sistema busca en el árbol de la base de datos (en preorden) un registro que
satisfaga la condición dada, una vez encontrado, el registro creado se inserta en el árbol como un hijo más a la
izquierda. Si se omite la cláusula where, el registro nuevo es insertado en la primera posición (en preorden) en el
árbol de la base de datos donde se pueda insertar un registro del mismo tipo que el nuevo.
Ejemplos:
Consideremos que queremos añadir una nueva alumna cuyo nombre es Rocío Veleta con número de control
93551028 de la carrera de LI; entonces la inserción del nuevo registro seria de la siguiente manera:
Aumno.NombreA:=Rocío Veleta";
Alumno.Control:="93551028";
Alumno.Esp:="ISC";
insert Alumno;
Consideremos que deseamos crear la alta de la materia de matemáticas 1 a la alumna con número de control
99550168.
Materia.NombreM:="Matemáticas I";
Materia.Clave:="SCB9334";
Materia.Cred:=8;
insert Materia;
where Alumno.Control="99550168";
69
Modificación de registros existentes.
La instrucción para efectuar cambios a los registros es:
Replace
Esta instrucción no requiere los datos del registro a modificar como argumento, el registro que se afectará será
aquel al que este apuntando el puntero de actualidad, que debe ser el registro que se desea modificar.
Ejemplo:
Consideremos que deseamos reemplazar la carrera de la alumna con número de control 99550168.
Get hold first Alumno
Alumno.Esp:="LI";
replace;
Se agrega la palabra hold para que el sistema se entere que se va a modificar un registro.
Eliminación de un registro
Para eliminar un registro se debe apuntar al puntero de actualidad hacia ese registro, después se ejecuta la orden
delete, al igual que en la orden replace, se debe poner la orden Hold.
Ejemplo:
Consideremos que deseamos borrar al alumno con número de control 99550168.
Get hold first Alumno;
Where Alumno.Control=’99550168’;
delete;
También se puede borrar un registro(raíz), lo cuál eliminaría todas sus derivaciones (hijos).
Ejemplo:
Consideremos que deseamos eliminar al alumno con número de control 99550168 y todas sus materias, entonces
la instrucción quedaría:
get hold first Alumno

70
delete;
6.5 REGISTROS VIRTUALES.
En las relaciones muchos a muchos se requería la repetición de datos para conservar la organización de la
estructura del árbol de la base de datos.
La repetición de la información genera 2 grandes problemas:
 La actualización puede generar inconsistencia de los datos.
 Se genera un desperdicio considerable de espacio.
Para solventar estos problemas se introdujo el concepto de registro virtual, el cual no contiene datos almacenados,
si no un puntero lógico a un registro físico determinado.
Cuando se va a repetir un registro en varios árboles de la base de datos, se mantiene una sola copia de ese
registro en uno de los árboles y empleamos en los otros registros la utilización de un registro virtual que contiene la
dirección del registro físico original.
UNIDAD VII. BASE DE DATOS ORIENTADOS A OBJETOS.
7.1 CONCEPTOS DE ORIENTACION A OBJETOS
La orientación a objetos puede describirse como el conjunto de disciplinas que desarrollan y modelizan software que
facilitan la construcción de sistemas complejos a partir de componentes.
El atractivo intuitivo de la orientación a objetos es que proporciona conceptos y herramientas con las que se
modela y representa el mundo real tan fielmente como sea posible. Las ventajas de orientación a objetos son
muchas en programación y modelación de datos.
Las aplicaciones de las bases de datos en áreas como el diseño asistido por computadora, la ingeniería de
software y el procesamiento de documentos no se ajustan al conjunto de suposiciones que se hacen para
aplicaciones del estilo de procesamiento de datos. El modelo de datos orientado a objetos se ha propuesto para
tratar algunos de estos nuevos tipos de aplicaciones.
El modelo de bases de datos orientado a objetos es una adaptación a los sistemas de bases de datos. Se basa en
el concepto de encapsulamiento de datos y código que opera sobre estos en un objeto. Los objetos estructurados se
agrupan en clases. El conjunto de clases esta estructurado en sub y superclases basado en una extensión del
concepto ISA del modelo Entidad - Relación. Puesto que el valor de un dato en un objeto también es un objeto, es
posible representar el contenido del objeto dando como resultado un objeto compuesto.
El propósito de los sistemas de bases de datos es la gestión de grandes cantidades de información. Las primeras
bases de datos surgieron del desarrollo de los sistemas de gestión de archivos. Estos sistemas primero
evolucionaron en bases de datos de red o en bases de datos jerárquicas y, más tarde, en bases de datos
relaciónales.
71
Objetos
El modelo orientado a objetos se basa en encapsular código y datos en una única unidad, llamada objeto. El
interfaz entre un objeto y el resto del sistema se define mediante un conjunto de mensajes.
Un objeto tiene asociado:
 un conjunto de variables que contienen los datos del objeto. El valor de cada variable es un objeto.
También llamados atributos.
 Un conjunto de mensajes a los que el objeto responde cuando dicho mensajes son invocados.
 Un método, que es un trozo de código para implementar cada mensaje. Un método devuelve un
valor como respuesta al mensaje.
El término mensaje en un contexto orientado a objetos, no implica el uso de un mensaje físico en una red de
computadoras, si no que se refiere al paso de solicitudes entre objetos sin tener en cuenta detalles específicos de
implementación.
La capacidad de modificar la definición de un objeto sin afectar al resto del sistema está considerada como una de
las mayores ventajas del modelo de programación orientado a objetos.
Clases
La clase es la construcción del lenguaje utilizada más frecuentemente para definir los tipos abstractos de datos en
lenguajes de programación orientada a objetos. Generalmente, una clase se puede definir como una descripción
abstracta de un grupo de objetos, cada uno de los cuales se diferencia por el estado específico y es capaz de
realizar una serie de operaciones.
En una base de datos existen objetos que responden a los mismos mensajes, utilizan los mismos métodos y
tienen variables del mismo nombre y tipo. Sería inútil definir cada uno de estos objetos por separado por lo tanto se
agrupan los objetos similares para que formen una clase, a cada uno de estos objetos se le llama instancia de su
clase. Todos los objetos de su clase comparten una definición común, aunque difieran en los valores asignados a las
variables.
Así que básicamente las bases de datos orientados a objetos tienen la finalidad de agrupar aquellos elementos
que sean semejantes en las entidades para formar un clase, dejando por separado aquellas que no lo son en otra
clase.
La orientación a objetos trata de cumplir las necesidades de los usuarios finales, así como las propias de los
desarrolladores de productos de software. Estas tareas se realizan mediante la modelización del mundo real. El
soporte fundamental es el modelo objeto. Los cuatro elementos más importantes de este modelo son:
 Abstracción.
 Encapsulación.
 Modularidad
 Jerarquía
Abstracción
72
La abstracción es uno de los medios más importantes mediante el cual nos enfrentamos con la complejidad inherente
al software. La abstracción es la propiedad que permite representar las características esenciales de un objeto, sin
preocuparse de las restantes.
Una abstracción se centra en la vista externa de un objeto, de modo que sirva para separar el comportamiento
esencial de un objeto de su implementación. Definir una abstracción significa describir una entidad del mundo real,
no importa lo compleja que pueda ser.
Encapsulación
La encapsulación o encapsulamiento es la propiedad que permite asegurar que el contenido de la información de un

objeto está oculta al mundo exterior, el objeto A no conoce lo que hace el objeto B y viceversa. La encapsulación, en
esencia, es el proceso de ocultar todos los secretos de un objeto que no contribuyen a sus características esenciales.
Modularidad
La modularidad es la propiedad que permite subdividir una aplicación en partes más pequeñas llamadas módulos,
cada una de las cuales debe ser tan independiente como sea posible de la aplicación en sí y de las partes restantes.
Jerarquía
La jerarquía es una propiedad que permite una ordenación de las abstracciones. Las dos jerarquías más importantes
de un sistema complejo son: estructura de clases y estructura de objetos.
Las clases en un sistema orientado a objetos se representan en forma jerárquica como en el diagrama anterior, así
que las propiedades o características del elemento persona las contendrán (heredaran) los elementos alumno y
maestro. Decimos que tanto la entidad Alumno y maestro son subclases de la clase persona este concepto es similar
al utilizado en la de especialización (la relación ISA) del modelo E-R.
Se pueden crear muchas agrupaciones (clases) para simplificar un modelo así que una jerarquía (en forma gráfica)
puede quedar muy extensa, en estos casos tenemos que tener bien delimitados los elementos que intervienen en
una clase y aquellos objetos que las heredan.
Por ejemplo: Retomemos la relación alumno-cursa-materia agregándole la entidad maestro; donde los atributos
considerados para cada uno son alumno: Nombre, Dirección, Teléfono, Especialidad, Semestre, Grupo; Maestro:
Nombre, Dirección, Teléfono, Número económico, Plaza, RFC; Materia: Nombre, Créditos, Clave.
Los atributos de nombre, dirección y teléfono se repiten en la entidad alumno y maestro, así que podemos agrupar
estos elementos para formar la clase Persona con dichos campos. Quedando por separado en alumno: Especialidad,
semestre, Grupo. Y en maestro: Número económico, Plaza y RFC; la materia no entra en la agrupación (Clase
persona) ya que la clase específica los datos de solo personas, así que queda como clase materia.
7.2 MANEJO DE PERSISTENCIA, POLIFORMISMO
Polimorfismo
La quinta propiedad significativa de los lenguajes de programación orientados a objetos es el polimorfismo. Esta
propiedad no suele ser considerada como fundamental en los diferentes modelos de objetos propuestos, pero, dada
su importancia, no tiene sentido considerar un objeto modelo que no soporte esta propiedad.
Polimorfismo es la propiedad que indica, literalmente, la posibilidad de que una entidad tome mucha formas.
En términos prácticos, el polimorfismo permite referirse a objetos de clases diferentes mediante el mismo elemento
73
de programa y realizar la misma operación de diferentes formas, según sea el objeto que se referencia en ese
momento.
Persistencia
Los objetos deber poder ser persistentes, es decir, que los objetos puede permanecer después de la ejecución del
programa.
La persistencia es una propiedad que determina cuando un objeto esta activo; esto quiere decir cuando esta vigente
en memoria para ser utilizado. Cuando un objeto no esta en memoria deja de ser activo.
Consultas orientadas a objetos:
Los lenguajes de programación orientados a objetos requieren que toda la interacción con objetos se realiza
mediante el envío de mensajes.
Consideremos el ejemplo de alumno-cursa-materia deseamos realizar la consulta de los alumnos que cursan la
materia de Base de Datos 1, para realizar esta consulta se tendría que enviar un mensaje a cada instancia alumno
Así un lenguaje de consultas para un sistema de bases de datos orientado a objetos debe incluir tanto el modelo
de pasar el mensaje de objeto a objeto como el modelo de pasar el mensaje de conjunto en conjunto.
Complejidad de Modificación.
En base de datos orientados a objetos pueden existir los siguientes cambios:
 Adición de una nueva clase: Para realizar este proceso, la nueva clase debe colocarse en la
jerarquía de clase o subclase cuidando las variables o métodos de herencia correspondientes.
 Eliminación de una clase: Se requiere la realización de varias operaciones, se debe de cuidar los
elementos que se han heredado de esa clase a otras y reestructurar la jerarquía.
En sí la estructuración de modelos orientados a objetos simplifica una estructura evitando elementos o variables
repetidas en diversas entidades, sin embargo el precio de esto es dedicarle un minucioso cuidado a las relaciones
entre las clases cuando en modelo es complejo, la dificultad del manejo de objetos radica en la complejidad de las
modificaciones y eliminaciones de clases, ya que de tener variables que heredan otros objetos se tiene que realizar
una reestructuración que involucra una serie de pasos complejos.
74
VIII. BIBLIOGRAFIA
 Fundamentos de Bases de Datos

- Tercera Edición.
- Autores: Abraham Silberschatz, Henry F. Korth, S. SudarShan.
- Editorial Mc Graw Hill.
 Procesamiento de Bases de Datos. Fundamentos, Diseño e Implementación.

- Quinta Edición.
- Autor: David M. Kroenke.
- Editorial: Prentice Hall.
 Concepción y Diseño de Bases de Datos. Del Modelo E/R al Modelo Relacional

- Autores: Miguel Castaño, Mario Piattini.
- Editorial: Addison-Wesley Iberoamerica.
 Sistemas de Bases de Datos. Administración y Uso.

- Autor: Alice Y. H. Tsai.
- Editorial: Prentice Hall
 Programación Orientada a Objetos. Conceptos, modelado, diseño y codificación en C++.

- Autor: Luis Joyanes Aguilar
- Editorial: Mc Graw Hill.
75

Bases de Datos I-97

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Bases de Datos I-97

Enviado por

Direitos autorais:

Formatos disponíveis

1

DEFINICION DE BASES DE DATOS

Una base de datos es un conjunto autodescriptivo de registros integrados.

JERARQUIA DE LOS DATOS

Bits Bytes o caracteres Campos Registros Archivos.

Una base de datos contiene los siguientes tipos de datos:

a) Archivos de datos del usuario.

Archivos Base de Datos

1.2. OBJETIVOS DE LOS SISTEMAS DE BASES DE DATOS

De los sistemas tradicionales de Archivos a las Bases de Datos.

a) Ventajas de las Bases de Datos Frente a los Archivos Clásicos.

Las ventajas son:

b) Independencia de los datos respecto a los tratamientos y viceversa.

c) Coherencia de los Resultados

d) Mejor disponibilidad de los datos para el conjunto de los usuarios.

e) Mayor Valor Informativo

g) Mayor eficiencia en la recolección, validación y entrada de los datos al sistema

h) Reducción del espacio de almacenamiento

Mantener información de la organización en un sistema de procesamiento de archivos tiene una serie de

1.3 . ABSTRACCION DE LA INFORMACION

Vista 1 Vista 2 ... Vista n

1.4 MODELOS DE DATOS

MODELOS LOGICOS BASADOS EN REGISTROS

Los tres modelos basados en registros mas ampliamente conocidos son:

Diferencia entre los modelos

MODELO DE DATOS FISICO

1.5 INSTANCIA Y ESQUEMAS

1.6 INDEPENDENCIA DE LOS DATOS

LENGUAJES DE BASES DE DATOS

1.7 LENGUAJE DE DEFINICION DE DATOS

1.8 LENGUAJES DE MANIPULACION DE DATOS

Por manipulación de datos se quiere decir:

 La recuperación de información almacenada en la base de datos.

1.9 MANEJADOR DE BASE DE DATOS

Evolución de los Sistemas Manejadores de Base de Datos

Las funciones esenciales de un DBMS son las de descripción, manipulación y utilización.

A) Función de descripción o definición

Objetivos de los Sistemas Manejadores de Bases de Datos.

 Proteger los datos contra fallas del Sistema

 Interfaz de alto nivel con los programadores

Un Manejador de Base de Datos debe incluir lo siguiente:

 Independencia de los programas respecto a los cambios en la estructura de los datos.

1.10. ADMINISTRADOR DE LA BASE DE DATOS

 Esquema y Modificación de la Organización Física.- Los programadores llevan a cabo las

 Concesión de la Autorización para el acceso a los datos.- La concesión de diferentes tipos de

1.11 USUARIOS DE BASE DE DATOS

1.12 ESTRUCTURA GENERAL DEL SISTEMA

Los componentes funcionales de un sistema de base de datos se puede dividir en componentes de

ESTRUCTURA GENERAL DEL SISTEMA

interfaces de programas de esquema de

índices datos estadísticos

archivos de datos diccionario de datos

 Gestor de autorización e integridad.- Comprueba que se satisfagan las ligaduras de integridad y la

 Archivos de datos.- Almacenan la base de datos en sí.

 Diccionario de datos.- Almacena metadatos acerca de la estructura de la base de datos.

UNIDAD II. MODELO ENTIDAD-RELACION

2.1. ENTIDADES Y CONJUNTO DE ENTIDADES

Conjuntos de entidades cliente y préstamo-bancario

Santos 32112312 Mayor Peguerinos P-17 200,000.00

Un atributo en el modelo E-R se puede clasificar en los siguientes tipos:

Atributos compuestos nombre-cliente y dirección-cliente.

2.2 RELACIONES Y CONJUNTOS DE RELACIONES

Conjunto de relaciones prestatario