Área Informática

INSTITUCIÓN CERVANTES Base de Datos I

Fundamentación
El diseño de bases de datos es el proceso por el cual se determina la forma de organizar
los datos, incluidos su estructura, contenido y las aplicaciones por desarrollar.

Durante mucho tiempo, el diseño de bases de datos fue considerado una tarea para
expertos; más un arte que una ciencia. Sin embargo, se ha progresado mucho en el
diseño de bases de datos, y este se considera ahora una disciplina estable, con técnicas y
métodos propios. Debido a la creciente aceptación de las bases de datos por parte de la
industria y el gobierno en el plano comercial, y una variedad de aplicaciones científicas y
técnicas, el diseño de bases de datos desempeña un papel central en el empleo de los
recursos de información de la mayoría de las organizaciones. El diseño de bases de datos
ha pasado a constituir parte de la formación general de los profesionales informáticos, en
el mismo nivel que la capacidad de construir algoritmos usando un lenguaje de
programación convencional.

Si consideramos que la información hoy en día, es el componente más importante y

más valioso dentro de una empresa, el diseño de bases de datos como parte integrante del
ciclo de vida de un sistema de información, tomó vital importancia. Es la base de datos la
proveedora de información para el resto de los procesos que el sistema requiera, sobre
todo, será fundamental en aquellos procesos que brinden información gerencial o
necesaria para la toma de decisiones.

Objetivos Generales

Reconocer y valorar la importancia del diseño de bases de datos dentro del ciclo de
vida de un sistema de información.

Conocer y comprender las distintas etapas para el diseño de una base de datos
obteniendo así la posibilidad de analizar bases de datos existentes o crear una.

Manipular las herramientas necesarias para el correcto diseño de una base de datos.

Adquirir conocimientos acerca de las componentes del modelo relacional de datos.

Describir, analizar y corregir estructuras de datos con anomalías de diseño.

Adquirir la capacidad de diseñar y construir un modelo de datos relacional.

Reconocer la importancia del modelado conceptual dentro de una metodología de
diseño de bases de datos, utilizando modelos que ofrezcan la suficiente semántica y
que sean independientes de las instrumentaciones.

Adquirir principios metodológicos que ayuden al diseñador a realizar un buen
esquema conceptual que permita su transformación a esquema lógico con la
mínima pérdida de semántica.

Adquirir una sólida base teórica, como es la teoría de la normalización, al diseño
lógico de bases de datos, permitiendo de esta forma aplicar procedimientos
algorítmicos a dicho diseño.

Institución Cervantes 1
INSTITUCIÓN CERVANTES

Mapa Conceptual

2 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Programa
Unidad I: Diseño de Bases de Datos

Introducción al diseño de bases de datos: Fases del diseño de Bases de datos. Ciclo de
vida de un sistema de información. Independencia de datos. Diseño conceptual.
Esquema y modelo conceptual. Diseño lógico. Esquema y modelo lógico. Diseño
físico. Esquema y modelo físico. Ventajas de bases de datos contra ficheros o archivos
tradicionales o convencionales.
Datos: Definición. Concepto. Medidas de los datos. Modelos de datos. Bases de
Datos: Definición.

Unidad II: Modelo de datos

Modelado de datos: Procesos de abstracción en el diseño conceptual o modelamiento

de Bases de Datos. Abstracción de clasificación, de agregación y de generalización.
Propiedades de las correspondencias entre clases. Agregación binaria. Agregación n-aria.
Cardinalidad mínima y máxima. Generalizaciones: propiedades de cobertura. Modelos
de datos: Modelo conceptual de datos. Modelos lógicos. El modelo de entidades-
interrelacionadas: Elementos básicos. Cualidades.

Unidad III: Arquitectura de la base de datos

Estructuras de Bases de Datos: Archivos planos: Lista secuencial, lista vinculada, lista
invertida. Bases de datos jerárquicas. Bases de datos en red. Bases de datos relacionales.
Arquitectura: Nivel interno, nivel externo y nivel conceptual.
Nivel Interno: Acceso a la Base de datos: El manejador de disco (Disk Manager - DM).
El manejador de archivos (File Manager - FM). Agrupamiento. Indexación. Arboles B
(B-Trees).
Nivel Físico de la base de datos: El administrador de la Base de datos (DBA).
Funciones. El sistema de administración de la base de datos (DBMS). Funciones.
El administrador de comunicación de datos (DC). Procesamiento Distribuido:
Sistemas de teleprocesamiento. Sistemas Cliente/Servidor. Sistemas distribuidos. Bases
de datos distribuidas.

Unidad IV: El Modelo Relacional

Estructura del modelo relacional: Dominio. Relaciones. Tablas. Propiedades y

restricciones de integridad en los esquemas relacionales de bases de datos. Integridad de
datos: Clave candidata. Clave primaria. Integridad de Entidad. Clave secundaria o
alternativa. Clave foránea o ajena. Integridad referencial.
Diseño lógico en el modelo relacional. Transformación de esquema conceptual a
esquema lógico. Eliminación de jerarquías de generalización. Interrelaciones: de uno a
uno, de uno a muchos, de muchos a muchos.

Institución Cervantes 3
INSTITUCIÓN CERVANTES

Unidad V: Descomposición y Normalización

Dependencia funcional: Definición. Tipos de dependencias.

Normalización. Definición. Diferentes formas normales.
Aplicaciones prácticas.

Bibliografía y materiales de consulta

BATINI, Carlo, CERI, Stafano, y NAVATHE, Shamkant B., Diseño Conceptual de
Bases de Datos. Un enfoque de entidades interrelaciones, Addison-Wesley/Diaz de
Santos.

DATE, C. J., Introducción a los sistemas de bases de datos, volumen 1, Addison
Wesley, Iberoamericana, MA, quinta edición.

MIGUEL, Adoración de y PITTINI, Mario. Concepción y Diseño de Bases de Datos.
Del modelo E/R al Modelo Relacional. Paradigma, RA-MA, Madrid, España.

KROENKE D.M. “Procesamiento de Base de Datos: Fundamentos, Diseño e
Instrumentación” Quinta Edición Ed. Hispanoamericana 1996.

KORTH H. “Fundamentos de Bases de Datos” Ed. Mc. Graw-Hill.

http://asia.microsoft.com/latam/technet/articulos/200002/art16/

http://www.itlp.edu.mx/publica/tutoriales/basedat2/unidad1.htm

http://epsilon.facpya.uanl.mx/class/parte1.htm

http://kiyen.face.ubiobio.cl/~cvidal/base_datos/relacional/index.htm

http://redii.cic.ipn.mx/librospro/dbdd/default.html

Orientaciones Metodológicas
Se desarrollarán clases teóricas para la presentación de cada unidad, con la ayuda de
medios audiovisuales (televisores, computadoras, etc.). En la medida que se avance con
los conceptos teóricos, se irán realizando prácticas promoviendo la participación de los
alumnos en grupos de investigación y trabajos prácticos.

Evaluación
1 parcial teórico / práctico (en aula) aprobado con 4 o más de 4 (equivale al 60% del
parcial aprobado).
1 trabajo práctico. Será indispensable tenerlo aprobado para regularizar la materia. En
el mismo se aplicarán todos los conocimientos adquiridos, interrelacionando los
conceptos vistos hasta el momento. El alumno deberá construir una base de datos desde
el comienzo.
El mismo deberá tener la siguiente estructura:

4 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

1) Introducción (Objetivos generales, fundamentación, herramientas utilizadas,

descripción del problema planteado).
2) Desarrollo.
a. Esquema conceptual. (Objetivos particulares, diagrama, conclusión)
b. Esquema lógico. (Objetivos particulares, diagrama, conclusión)
c. Esquema físico. (Objetivos particulares, diagrama, conclusión)
3) Conclusiones. (si se consiguió cumplir con los objetivos generales planteados
en la introducción y de los resultados obtenidos)

Cabe aclarar, que toda consulta y tarea deberá contar con la bibliografía y las
direcciones electrónicas utilizadas.

Institución Cervantes 5
INSTITUCIÓN CERVANTES

Evaluación Diagnóstico
1. Defina la diferencia entre dato e información.
........................................................................................
........................................................................................

2. ¿Qué entiende por manipulación de datos?

........................................................................................
........................................................................................

3. ¿De qué maneras puede almacenar un dato para manipularlo dentro de un

programa?
........................................................................................
........................................................................................

4. Enumere y defina los diferentes tipos de datos que conozca. (por ej.: numérico)
........................................................................................
........................................................................................

5. Qué entiende por almacenamiento físico.

........................................................................................
........................................................................................

6. Describa brevemente que entiende por fichero o archivo.

........................................................................................
........................................................................................

7. Defina lo que entiende por registro y campo.

........................................................................................
........................................................................................

8. Describa brevemente que entiende por Base de Datos.

........................................................................................
........................................................................................
9. Enumere y defina los distintos tipos de archivos que reconozca. (por ejemplo:
BAT, EXE, DOC, etc.)
........................................................................................
........................................................................................

6 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Unidad I
Introducción al Diseño de Bases de Datos

Objetivos

Comprender la importancia del diseño de la base de datos dentro de un sistema de
información.

Conocer la historia y evolución de los distintos tipos de almacenamientos de datos.

Valorar la importancia de las bases de datos dentro de una organización como
soporte para la toma de decisiones.

Reconocer las distintas etapas para diseñar una base de datos.

Identificar ventajas y desventajas de este modelo.

Institución Cervantes 7
INSTITUCIÓN CERVANTES

Introducción
El diseñar una base de datos es un proceso que suele ser complejo pero a veces
divertido. Cuando me ha tocado diseñar una base de datos, siempre me imagino parado
en la cima de una montaña de la cual puedo contemplar el terreno a mis pies. En él se
pueden apreciar todas las especies arbóreas que habitan el bosque, las cuales se
encuentran todas entremezcladas. Imaginen si ustedes fueran los encargados de la tarea
de ordenar y agrupar cada especie. El proceso de diseñar y administrar una base de datos
es una tarea algo parecida. Deberán interpretar los requerimientos de los usuarios, los
cuales plantearan un inmenso bosque lleno de hierbas y árboles, todo enmarañado.
Además, los usuarios van a requerir, según sus necesidades, diferente información de esas
especies. Algunos les interesará conocer si la humedad es la suficiente, a otros solo la
antigüedad de determinada especie y asi sucesivamente. Ustedes tendrán que resolver
esos problemas. Administrar la información de manera tal que a cada usuario le llegue
sólo lo que le interesa, es decir, no todo el bosque, solo la porción que quieren conocer.
Solo ustedes tendrán la visión general del bosque desde la loma. Los demas solo verán lo
que ustedes le muestren. Cómo lo harán? Esa es la misión de este curso. Que aprendan
a utilizar las herramientas necesarias para lograr ese objetivo.

Introducción al Diseño de Bases de

datos
En la historia de la informática, siempre se distinguieron etapas. En lo que a hardware
se refiere, cada una se distinguió de la anterior por los cambios producidos en los
componentes físicos de las computadoras. En el software, ocurrió algo parecido dentro
de los lenguajes de programación. Estas etapas, se marcaron por cambios producidos en
los mismos. Hoy en día los 4GL (lenguajes de cuarta generación) son los que están más
vigentes. En cuanto a los almacenamientos físicos de datos, si bien no se destacan etapas,
estos acompañaron a los cambios producidos en los lenguajes que manipulan esos datos
almacenados.

Los primeros lenguajes de programación (COBOL por ejemplo), manipulan archivos

de datos, donde la característica de estos lenguajes, era orientada a los procesos o
programas más que a los datos. Más adelante retomaremos el tema para su total
comprensión. A raíz de las dificultades que presentaba este modelo, comenzó todo un
análisis y estudio de nuevas tecnologías capaces de producir otro tipo de almacenamiento
de datos. Aparece el concepto de Base de Datos, el cual apoya su estructura en los datos
más que en los procesos, es decir revierte el criterio hasta entonces conocido.

La expresión base de datos aparece a comienzos de los años sesenta. En 1963 tuvo lugar
en Santa Mónica (USA) un simposio donde aparece por prim era vez el término Data
Base.

Una base de datos es un conjunto, colección o depósito de datos almacenados en un

soporte informático de acceso directo. Los datos deben estar relacionados y estructurados
de acuerdo con un modelo capaz de recoger el máximo contenido semántico t63
(Introducción a las Bases de Datos, Jesús Vegas)

8 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Dada la importancia que tienen en el mundo real las relaciones entre los datos (por
ejemplo la relación existente entre un alumno y las materias que cursa), es
imprescindible que la base de datos sea capaz de almacenar estas interrelaciones, al igual
que hace con otros elementos (como las entidades y atributos), siendo ésta una diferencia
esencial respecto de los ficheros donde no se almacenan las relaciones.

En las bases de datos no debe existir redundancia lógica, aunque sí se admite cierta
redundancia física por motivos de eficiencia. Desde el punto de vista de usuario, los
datos están almacenados sólo una vez, aunque el sistema los duplique para facilitar el
acceso. Por tanto, un dato se actualizará lógicamente por el usuario de forma única, el
sistema se preocupará de cambiar físicamente todos aquellos campos en los que el dato
estuviese repetido (actualización en cascada), en caso de existir redundancia física. Por
ejemplo: a un alumno se lo reconoce y se lo identifica por su número de legajo. El
mismo se encuentra almacenado en el Legajo, en las notas, en la asistencia, etc. Si ese
número cambiara por cualquier motivo, el sistema actualiza automáticamente en todas
las relaciones el número viejo por el nuevo y el usuario no se entera de lo que ha pasado.

Las bases de datos han de atender a múltiples usuarios y a diferentes aplicaciones.

Otro aspecto importante de las bases de datos es la independencia, tanto física como
lógica, entre datos y procesos. Esta independencia, objeto fundamental, es una
característica esencial que distingue a esta de los ficheros tradicionales y que ha tenido
enorme influencia en la arquitectura de los DBMS o SMBD (DATA BASE MANAGER
SYSTEM o SISTEMAS MANEJADORES DE BASES DE DATOS), como se verá más
adelante.

La definición y la descripción del conjunto de datos contenidos en la base deben ser

únicas y estar integradas con los mismos datos. En los sistemas basados en ficheros, los
datos se encuentran almacenados en soporte magnético, mientras su descripción está
separada de los mismos formando parte de los programas, la estructura de los ficheros
tienen total dependencia con los programas que los administran, para cualquier
modificación que se quiera realizar en la estructura de algún fichero, indefectiblemente
deberá modificarse el programa. En las bases de datos, la descripción y, en algunos casos,
también una definición y documentación completa (metadatos t113 se almacenan
junto con los datos, de modo que estos estén autodocumentados, y cualquier cambio que
se produzca en dicha documentación se ha de reflejar y quedará recogido en el sistema,
con todas las ventajas que de este hecho se derivan. Se dice a partir de este concepto que
las bases de datos son autodescriptivas, ya que en la misma base se almacenan datos y
definición de los mismos.

La actualización y recuperación en las bases de datos deben realizarse mediante

procesos bien determinados, estos procesos deben estar diseñados de modo que
mantengan la integridad, seguridad y confidencialidad de la base de datos.

El concepto de base de datos ha ido cambiando y configurándose a lo largo del tiempo.

En la actualidad, y de acuerdo con estas características que acabamos de analizar,
podemos definir a la base de datos como sigue:

Institución Cervantes 9
 INSTITUCIÓN CERVANTES

Colección o depósito de datos integrados, con redundancia controlada y con una

estructura que refleje las relaciones y restricciones existentes en el mundo real; los datos,
que han de ser compartidos por diferentes usuarios y aplicaciones, deben mantenerse
independientes de éstas, y su definición y descripción, únicas para cada tipo de datos, han
de estar almacenadas junto con los mismos. Los procedimientos de actualización y
recuperación, comunes y bien determinados, habrán de ser capaces de conservar la
integridad, seguridad y confidencialidad del conjunto de datos. (Introducción a las Bases
de Datos, Jesús Vegas)

Ciclo de vida de un sistema de

información
Dentro del diseño de un sistema de información, dijimos que el diseño de la base de
datos es uno de los componentes del mismo. Es por ello que necesitamos conocer donde
estamos parados para reconocer la importancia del proceso de diseño y construcción de la
misma.

Definimos un sistema de información como la reunión de todos los recursos dentro de

la organización que colaboran en la recolección, administración, uso y diseminación de
la información. En un sistema computarizado, esto es, el SGBD o DBMS, el hardware
de la computadora, los medios de almacenamiento, el personal que lo usa y maneja los
datos y el software de aplicación que tiene acceso y actualiza los datos.

El ciclo de vida del sistema de información e incluye las siguientes etapas o fases:
Fase del Ciclo de Vida Justificación
Análisis de factibilidad Analiza áreas de aplicación, relación costo – beneficio y
todas las prioridades.
Recolección y análisis de los Período de obtención de requerimientos detallados
requerimientos interactuando con los posibles usuarios
Diseño Comprende el diseño de la base de datos y de los
sistemas de aplicación
Implementación Se implementan el sistema de información, la base de
datos y sus transacciones.
Validación y prueba de El sistema es validado en cuanto a la satisfacción de los
aceptación requerimientos de los usuarios y los criterios de
rendimiento.
Operación Es aquí cuando todas las funciones del sistema están
disponibles y validadas. La supervisión y el
mantenimiento del sistema serán actividades
importantes.
Supervisión y mantenimiento El sistema se vigila y mantiene constantemente.

10 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Ventajas de las bases de datos frente a

los ficheros clásicos
Las bases de datos, presentan una multitud de ventajas frente a los sistemas clásicos de
ficheros. Cabe señalar que las bases de datos no son la panacea universal que
solucionará todos los problemas que la información plantea, es un instrumento, y su
éxito o fracaso estará condicionado por el uso que de ellas sepamos hacer tanto usuarios,
técnicos, y los responsables de los sistemas de base de datos.

Las ventajas de los sistemas de bases de datos son, entre otras, las siguientes:

Independencia de los datos respecto de los tratamientos y viceversa.

La mutua independencia de datos y tratamientos lleva a que un cambio de estos
últimos no imponga un nuevo diseño lógico y/o físico de las bases de datos. Por otra
parte, la inclusión de nuevas informaciones, desaparición de otras, cambios en la
estructura física o en los caminos de acceso, etc., no deben obligar a alterar los
programas de aplicación.

Coherencia de los datos

Debido a que la información de 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 comparables.

Mejor disponibilidad de los datos para el conjunto de los usuarios

Cuando se aplica la metodología de base de datos, cada aplicación / usuario ya no es
propietario de los datos, puesto que éstos 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 de la información existente, ya que
todos los datos se encuentran en la base se deben relacionar en un catálogo o
diccionario de datos, que puede ser ampliamente difundido y accedido por medios
informáticos.

Mayor valor informativo

Puesto que la base de datos es un sistema reflejo del mundo real, donde los distintos
elementos están relacionados, el valor informativo de sus conjuntos es superior de la
suma del valor informativo de los elementos individuales que lo constituyen.

Mejor y más normalizada documentación de la información, la cual está integrada

con los datos.

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

Al no existir redundancias, los datos se recogen y validan una sola vez, aumentando
así el rendimiento de todo el proceso previo al almacenamiento.

Reducción del espacio de almacenamiento

La desaparición (o disminución) de las redundancias, así como la aplicación de
técnicas de compactación, lleva en los sistemas de bases de datos a una menor
Institución Cervantes 11
INSTITUCIÓN CERVANTES

ocupación de almacenamiento secundario. Se ha de tener presente, sin embargo,

que los elementos del sistema (diccionarios, referencias, punteros, ficheros
invertidos, etc.) ocupan bastante espacio.

Imaginemos la siguiente situación:

En una empresa dedicada a la comercialización de XXX producto, dividida en áreas y

cada área maneja información para la toma de decisiones o para la comercialización del
producto. Todos los sectores de la organización, accederían a la base de datos a solicitar
la información requerida. Si no fuera así y cada área tuviera los datos que necesita en
forma independiente, en cada sector se generaría el cliente que el área necesita sin
controlar que las otras áreas ya lo hubieran creado. Esto genera duplicación de la
información. No habría relación entre las distintas áreas de trabajo. Cada sector debería
realizar mantenimiento de los datos, etc.

Independencia de los datos

Esta se refiere a la libertad que pueda existir para modificar algunos de los esquemas
sin que exista la necesidad de rescribir los programas de aplicación.
Existen básicamente dos tipos de independencia:
a. INDEPENDENCIA FISICA.- Esta se presenta cuando es posible la modificación
del esquema físico sin afectar a los esquemas restantes. Las principales razones
para llevar a cabo una modificación del esquema físico serán un ajuste en el
hardware de almacenamiento o una redistribución de los datos en él.

b. INDEPENDENCIA LOGICA.- Ocurre cuando se modifica el esquema

conceptual sin afectar al resto de los esquemas. Básicamente se modifica el
esquema conceptual cuando cambian las características de los datos a almacenar.

Es relativamente más sencillo y probable lograr la independencia física puesto que una
modificación del esquema conceptual, (estructuras, ligas y demás) inevitablemente
requerirá de modificaciones el código para su manipulación.

Fases del Diseño de Bases de Datos

El diseño de una base de datos es un proceso complejo que abarca varias decisiones a
muy distintos niveles. La complejidad se controla mejor si se descompone el problema
en subproblemas y se resuelve cada uno de éstos independientemente, usando métodos y
técnicas específicas. El diseño de base de datos se descompone en el diseño conceptual,
diseño lógico y diseño físico, como lo muestra la siguiente figura:

12 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

El diseño de bases de datos representa un enfoque orientado a los datos para el

desarrollo de los sistemas de información: la atención completa del proceso de diseño se
centra en los datos y sus propiedades. Con este enfoque, primero se diseña la base de
datos luego las aplicaciones que la usan. Este método se desarrolló en la década de 1970,
con el establecimiento de la tecnología de bases de datos.

Diseño conceptual
El diseño conceptual parte de la especificación de requerimientos y su resultado es el
esquema conceptual de la base de datos. Un esquema conceptual es una descripción de
alto nivel de la estructura de la base de datos, independiente del software de DBMS que
use para manipularla. Un modelo conceptual es un lenguaje que se usa para describir
esquemas conceptuales. El propósito del diseño conceptual es describir el contenido de
información de la base de datos, más que las estructuras de almacenamiento que se
necesitarán para manejar esta información. En realidad, el diseño conceptual debe
hacerse aún cuando la implantación no use un DBMS, sino archivos convencionales y
lenguajes de programación.

Modelos Conceptuales: MER (modelo entidad relación), Modelos OO (orientado a

objetos), etc. En este curso se estudiara el MER el cual explicaremos en profundidad más
adelante.

Institución Cervantes 13
INSTITUCIÓN CERVANTES

Diseño lógico
El diseño lógico parte del esquema conceptual y da como resultado un esquema lógico.
Un esquema lógico es una descripción de la estructura de la base de datos que puede
procesar el software de DBMS. Un modelo lógico es un lenguaje utilizado para especificar
esquemas lógicos; los modelos lógicos más usados pertenecen a tres clases: relacional, de
redes y jerárquico. El diseño lógico depende de la clase de modelo de datos usado por el
DBMS, no del DBMS utilizado (en otras palabras, el diseño lógico se efectúa de la misma
forma para todos los DBMS relacionales porque todos utilizan el modelo relacional).

Modelos Lógicos: Relacional, de Redes, Jerárquico, Modelos OO.

Diseño físico
El diseño físico parte del esquema lógico y da como resultado un esquema físico. Un
esquema físico es una descripción de la implantación de una base de datos en la memoria
secundaria; describe las estructuras de almacenamiento y los métodos usados para tener
acceso efectivo a los datos. Por esta razón, el diseño físico se adapta a un sistema DBMS
específico. Hay una retroalimentación entre diseño físico y el lógico, porque las
decisiones tomadas durante el diseño físico para mejorar el rendimiento pueden afectar la
estructura del esquema lógico.

Modelos Físicos: Visual Basic, COBOL, FOX, etc.

Una vez completado el diseño físico de una base de datos, los esquemas lógico y físico
se expresan haciendo uso del lenguaje de definición de datos (DDL) del DBMS objetivo; la
base de datos se crea y se carga, y puede ser probada. Más que eso, las aplicaciones que
usan las bases de datos pueden especificarse, implantarse y probarse completamente. De
este modo la base de datos se vuelve paulatinamente operacional. La siguiente figura
resume la dependencia de los diseños conceptual, lógico y físico de la clase o tipo de
DBMS y del DBMS específico.

Dependencia del: El tipo de dbms Un dbms específico

Diseño conceptual No No
Diseño lógico Sí No
Diseño físico Sí Sí

14 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Concepto de Dato y Modelo de Dato

El significado de dato
La percepción del mundo puede ser descrita como una sucesión de fenómenos. Desde
el comienzo de los tiempos el hombre ha tratado de descubrirlos, ya sea que los entienda
completamente o no.

La descripción de estos fenómenos es llamada DATO. t13

Usualmente el dato y su significado son registrados juntos, ya que el lenguaje natural es

lo suficientemente poderoso para hacerlo. Por ejemplo "el kilo de pan cuesta $ 1,60 se
registra el valor (1,60) y su significado o semántica (valor del kilo de pan en pesos).

En ciertos casos los datos están separados de su semántica. Por ejemplo, una planilla
de notas es una tabla de datos. Su interpretación está implícita y se supone que quien la
lee conoce su significado.

El uso de la computadora para procesar datos, ha traído consigo una mayor separación
entre los datos y su interpretación. Mucha de la interpretación de los datos está explícita.
Consideremos por ejemplo un programa que calcula integrales definidas. Este programa
recibe valores de entrada y genera valores como salida. Sin embargo, el programa en si
no tiene conocimiento si el problema resuelto es de termodinámica o electromagnetismo.

Han habido dos razones para separar los datos de su significado:

las computadoras no manejan (bien) el lenguaje natural, que es la mejor forma de

dar interpretación y significado a un dato.

el almacenamiento del significado de los datos ocupa espacio, e inicialmente este era
escaso y costoso.

Así, tradicionalmente la interpretación de los datos se deja al usuario y al sistema

manual externo al computador.

En muchos sistemas la interpretación de datos se encuentra en los programas que

hacen uso de ellos, de modo que los datos pasan a ser una simple colección de valores.

Por otra parte, supongamos que algo de la semántica de los datos se codifica junto con
ellos. Así los datos no son solo valores, sino que también tienen una semántica, y los
datos están más cerca de la interpretación del mundo. Ellos forman una "vista" del
mundo, la que no es exacta ni concreta, sino que usualmente es bastante abstracta.

Los datos no son estáticos, y corresponden a un mundo que está en constante cambio.
La flexibilidad en la interpretación de los datos permite capturar los aspectos dinámicos
del mundo y al mismo tiempo, proveer una estructura estable para los datos. Esta
flexibilidad se puede tener de dos formas:

Institución Cervantes 15
INSTITUCIÓN CERVANTES

El sistema puede permitir que los mismos datos sean vistos de diferente forma. Por
ejemplo, diferentes aplicaciones puedan usar los mismos datos y dar su propia
semántica.

Diferentes datos pueden ser vistos de la misma forma. Por ejemplo, se quiere ver a
los gerentes, secretarias y empleados sólo como trabajadores de una organización, no
importando su cargo. Aquí la interpretación debe ser lo suficientemente abstracta
para que diferentes vistas del mundo se vean de la misma forma.

Modelamiento de Datos
La interpretación del mundo real es necesaria, ya que de este ambiente tomaremos las
bases para crear nuestro modelo. Además, debe ser suficientemente abstracta para que
no sea afectada por la dinámica del mundo (al utilizar elementos del mundo real, suelen
producirse pequeños cambios en él que pueden afectar nuestro modelo), y debe ser
suficientemente robusta para poder representar cómo los datos y el mundo real se
relacionan. Una herramienta como esta es llamada modelo de datos, el cual permite
representar en forma más o menos razonable alguna realidad. El modelo de datos
permite realizar abstracciones del mundo, permitiendo centrarse en los aspectos macros,
sin preocuparse de las particularidades; así nuestra preocupación se centra en generar un
esquema de representación, y no en los valores de los datos. En la unidad siguiente,
retomaremos el tema de abstracciones con mayor profundidad.

Los modelos de datos nos permiten capturar parcialmente el mundo, ya que es

improbable generar un modelo que lo capture totalmente.

Sin embargo, se puede tener un conocimiento relativamente completo de la parte del

mundo que nos interesa. Así, un modelo captura la cantidad de conocimiento tal que
cumpla con los requerimientos que nos hemos impuesto previamente.

DATO: la siguiente tupla: <nombre del objeto, propiedad del objeto, valor, tiempo>

Esta definición es correcta, ya que cada vez que se describe un fenómeno, éste se refiere
a un objeto (nombre del objeto) y ciertas características (propiedades del objeto) el cual
tiene un valor en un momento determinado (tiempo).

D Ejemplo
nombre:
El precio del pan es $1,60.
precio del pan
propiedades: (unidad, $), entero no negativo.
valor: 1,60
tiempo: hoy

En general, el modelar un objeto no se considera el tiempo, sino que éste se considera

implícito en la semántica de él.

16 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

D Ejemplo
nombre:
Consideremos el caso de una matriz:
matriz_coeficiente
propiedades: +, –, *, a[i,j] * R
valor: [1 2]
[3 4]

Esquema
Para una aplicación particular de un modelo de datos, el modelamiento de la realidad
se llama esquema.

Un esquema es una definición genérica que identifica categorías (ejemplo: libro, autor,
etc.), sus propiedades (nombre, título) y sus relaciones (escrito).

Por ejemplo, un modelo de datos simple es una archivo (tabla). Aplicando este modelo
a una situación particular se puede tener el siguiente esquema:

Persona (Nombre, Edad, Dirección), donde Persona es el nombre genérico de una

entidad, y Nombre, Edad y Dirección son nombres genéricos para los atributos.

Modelo de Datos: Introducción

Un modelo de datos define las reglas por las cuales los datos son estructurados. Esta
estructuración, sin embargo, no da una interpretación completa acerca del significado de
los datos y la forma en que serán usados. Las operaciones que se permiten efectuar a los
datos deben ser definidos.

D Ejemplo
Una lista puede ser tratada como pila o fila, dependiendo de las operaciones que se
permitan sobre ella.

Generalmente las operaciones están relacionadas con la estructura de los datos y tienen
validez en el contexto en que fueron definidos.

Todo modelo de datos debe poder capturar las propiedades estáticas y dinámicas de
una realidad. Las propiedades estáticas corresponden a lo que es relativamente
invariante en el tiempo, son siempre verdadero y no cambia en el tiempo.

D Ejemplo:
Que los precios se midan en $ es relativamente invariante.

Las propiedades dinámicas corresponden a la naturaleza evolutiva del mundo. Por

esto, para todo modelo debe ser posible capturar los dos tipos de propiedades.

Institución Cervantes 17
INSTITUCIÓN CERVANTES

Modelo de Datos
Se define el modelo de datos M consistente de dos partes:
G: un conjunto de reglas que lo generan.
O: un conjunto de operaciones.

El conjunto de reglas G expresan las propiedades estáticas de un modelo de datos y

corresponden a lo que se denomina generalmente Data Definition Language (DDL).
Este define las estructuras permitidas para el modelo de datos M.

El conjunto G se puede dividir en dos:

Gs: las estructuras permitidas.

Gc: las restricciones del modelo.

Así, Gs genera las categorías y estructuras para un modelo, y Gc las restricciones.

Utilizando esta última notación, un esquema S consiste de dos partes: una estructura
Ss y restricciones Sc t23 t33, donde Sc es una lista explícita de restricciones que no
deben ser violadas.

Por ejemplo, en la definición de la entidad persona, un atributo particular CI (Cédula

de Identidad) puede ser declarado como clave, esto es, en un instante dado no puede
haber dos personas con el mismo valor para CI. Ss no prohíbe dos ocurrencias, pero Sc
sí.

Las propiedades dinámicas de un modelo de datos son expresadas por un conjunto de

operaciones O, las que generalmente son llamadas Data Manipulation Language
(DML). Estas propiedades definen las acciones permitidas para una base de datos, tal
que transforme la ocurrencia Di en la ocurrencia Dj. t43

No todas las operaciones definidas en O causan cambios en la base de datos, pero si

causan un cambio en el estado de ella. El estado de una base de datos no es un objeto de
ella, pero está asociado a la base de datos, y cambia como resultado de una operación.

Ejemplo. Consideremos el modelo de datos tipo Tabla; este modelo tiene como una de
sus operaciones la operación "read", que permite recorrer la tabla en forma secuencial.
Esta operación no cambia el contenido de la Base, pero si su estado (cambia el registro
actual, que ahora es el siguiente).

18 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Autoevaluación
1. Describa brevemente que es un modelo de datos:
........................................................................................
........................................................................................
2. ¿Cuáles son las ventajas de trabajar con Bases de Datos y no con archivos?
........................................................................................
........................................................................................

3. ¿Qué diferencia existe entre esquema y modelo?

........................................................................................
........................................................................................

4. ¿Cuáles son los pasos necesarios para el diseño de una Base de Datos?
........................................................................................
........................................................................................

5. Explique dentro del diseño de un sistema de información, que función cumple el

diseño de una Base de Datos.
........................................................................................
........................................................................................

6. ¿Cuál es la diferencia entre una Base de Datos y un sistema de archivos

tradicional?
........................................................................................
........................................................................................

7. ¿Por qué se dice que las bases de datos son autodescriptivas?

........................................................................................
........................................................................................

8. Defina ahora, que entiende por Base de Datos y comente si el concepto que tenía
al iniciar el curso cambió o no.
........................................................................................
........................................................................................

9. Defina el término METADATO.

........................................................................................
........................................................................................

Institución Cervantes 19
INSTITUCIÓN CERVANTES

20 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Unidad II
Modelado de Datos

Objetivos

Conocer los distintos mecanismos de abstracción.

Adquirir los conceptos para realizar la construcción de esquemas conceptuales.

Comprender y reconocer las distintas etapas para el diseño de una base de datos.

Institución Cervantes 21
INSTITUCIÓN CERVANTES

En la unidad anterior, describimos que era modelar datos y que era el modelamiento.
Hablamos de que era necesario utilizar métodos abstractos para la descripción de la
realidad en cuestión. Recordemos el siguiente concepto: Los modelos de datos son
vehículos utilizados para describir la realidad.

Los programadores usan los modelos de datos para construir esquemas, los cuales son
representaciones gráficas de la realidad. La calidad de los esquemas resultantes depende
no sólo de la habilidad de los programadores, sino también de las características del
modelo de datos seleccionado.

El bloque de construcción común a todos los modelos de datos es una pequeña

colección de mecanismos de abstracción primitivos: Clasificación, agregación y
generalización. Las abstracciones ayudan al programador a entender, clasificar y modelar
la realidad.

Procesos de Abstracción en el
modelamiento de Datos
La abstracción es un proceso mental que se aplica al seleccionar algunas características
y propiedades de un conjunto de objetos y excluir otras no pertinentes. En otras palabras,
se hace una abstracción al fijar la atención en las propiedades consideradas esenciales de
un conjunto de cosas y desechar sus diferencias.

En el modelamiento de datos, se usan tres tipos de abstracciones: clasificación,

agregación y generalización.

1. Abstracción de clasificación: se usa para definir un concepto como una clase de

objetos de la realidad caracterizados por propiedades comunes. Por ejemplo,
tenemos que el concepto NOMBRE DE ALUMNO es la clase cuyos miembros son
todos NOMBRES (Juan, José, Luis, etc.).
Se representa gráficamente la clasificación como un árbol de un nivel, que tiene
como raíz la clase y como hojas los elementos de la clase; las ramas del árbol se
representan por líneas discontinuas. Cada rama del árbol indica que un nodo hoja
es un miembro de la clase que representa la raíz. Se pueden obtener clases con
diferentes elementos, y cada elemento puede pertenecer a varias clases.

Nombre de Alumno

Juan José ... Luis

Este mecanismo, es por lo general el primero que intuitivamente se utiliza, ya que

todas las personas somos capaces de reconocer a los objetos de la realidad por su
nombre y dirán ese es Juan, alumno del Instituto. O sea que Juan es
intuitivamente una propiedad del objeto reconocida. Este mecanismo es muy
utilizado por los programadores inexpertos o aquellos que están haciendo sus
primeros trabajos como profesionales de la informática.

22 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

2. Abstracción de agregación: Define una nueva clase a partir de un conjunto de otras

clases que representan sus partes componentes. Se representa por un árbol de un
nivel en el cual todos los nodos son clases; la raíz representa la clase creada por
agregación de las clases representadas en las hojas. Cada rama del árbol indica que
una clase hoja es una parte de (ES_PARTE_DE) la clase representada por la raíz.
Para distinguirla de la agregación de clasificación, las ramas dirigidas están
representadas por líneas dobles que van de los componentes a los objetos
agregados.

Persona

DNI nombre dirección teléfono

La clasificación y la agregación son las dos abstracciones básicas utilizadas para
construir estructuras de datos dentro de la base de datos y dentro de los lenguajes
convencionales de programación. La clasificación es el procedimiento utilizado
cuando, partiendo de elementos individuales de información, se identifican tipos de
campos o atributos. La agregación es el procedimiento mediante el cual se reúnen
tipos de campos relacionados en grupos como por ejemplo tipos de registros.

3. Abstracción de Generalización: Define una relación de subconjunto entre

elementos de dos o más clases. Cada generalización se representa con un árbol de
un nivel, en el que todos los nodos son clases, con la clase genérica como raíz y las
clases subconjunto como hojas; cada rama del árbol expresa que una clase hoja es
un (ES_UN) subconjunto de la clase raíz. Para distinguir la generalización de
otras abstracciones, se usa una flecha sencilla apuntando hacia la raíz. Esta
abstracción, a pesar de ser muy común e intuitiva, no se usa en muchos modelos de
datos. Sin embargo es muy útil por su cualidad fundamental de herencia: en una
generalización, todas las abstracciones definidas para la clase genérica son
heredadas por las clases subconjunto.

Persona

Negro Blanco

Los tres mecanismos son independientes: ninguno de ellos puede describirse en función
de los otros, y cada uno proporciona un mecanismo diferenciado en el proceso de
estructuración de la información. La independencia de las tres interrelaciones de
conceptos establecidas por las abstracciones: la clasificación corresponde a la membresía
(interrelación de pertenencia) (ES_PARTE_DE); y la generalización, a la inclusión
(interrelación de subconjunto) en conjuntos (ES_UN).

Institución Cervantes 23
INSTITUCIÓN CERVANTES

Propiedades de las correspondencias

entre las clases
Las abstracciones de agregación y generalización establecen correspondencias entre
clases. En los puntos subsiguientes veremos las características de estas correspondencias.
Primero se consideran las agregaciones binarias, que son agregaciones entre dos clases;
después se consideran las agregaciones n-arias o agregaciones entre n o más clases. Por
último, se consideran las generalizaciones.

1. Agregación Binaria: es una correspondencia o vínculo que se establece entre dos

clases. Se puede representar una correspondencia binaria entre dos clases como
sigue: se describe a las dos clases como conjuntos y se traza una línea desde un
elemento de un conjunto a un elemento del otro conjunto, cada vez que los dos
elementos estén agregados.

a1 p1
a2
a3 p2
a4
a5 p3

Automóviles Personas
Al observar la figura, se puede decir que la persona p1 posee los autos a1 y a2, la
persona p2 posee los autos a2, a4 y a5, mientras que la persona p3 no posee autos.
De esto último se puede observar que no es obligatorio que todas las personas
posean autos, pero al parecer todos los autos deben tener un dueño. Esta última
característica es propia de cada agregación, y se refieren a la cardinalidad de
correspondencia entre las clases.

a) Cardinalidad mínima (card-min): considérese una agregación entre las clases

C1 y C2. La cardinalidad mínima de C1 en A, denotada por card-mín (C1, A), es
el menor número de correspondencias en las que cada elemento de C1 puede
tomar parte. Asimismo, la cardinalidad mínima de C2 en A, representada como
card-min (C2, A), en el mismo número de correspondencias en las que cada
elemento de C2 puede participar.

Si consideramos las agregaciones USA y POSEE entre PERSONA Y

EDIFICIO:

Si se supone que cada persona usa al menos un edificio, entonces, card-min
(PERSONA, USA)=1.

Si se supone que algunos edificios no están habitados, entonces, card-min
(EDIFICO, USA)=0.

Si se supone que algunas personas no poseen un edificio, entonces, card-min
(PERSONA, POSEE)=0.

Si se supone que cada uno de los edificios debe pertenecer a una persona
entonces, card-min (EDIFICIO, POSEE)=1.

24 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Estos ejemplos muestran que los valores importantes de card-min (C1, A) son 0
y 1 respectivamente. La cardinalidad mínima raras veces toma valores diferentes.
Si card-mín (C1, A)=0, se dice que la clase C1, tiene una participación opcional
en la agregación, porque algunos elementos de la clase C1 pueden no tener
correspondencia en la agregación A con elementos de la case C2. Si card-mín (C1,
A) >0, se dice que la clase C1 tiene una participación obligatoria en la
agregación, ya que cada elemento de la clase C1 debe corresponder, al menos a un
elemento de la clase C2.

b) Cardinalidad máxima (card-máx): Considérese la agregación A entre las clases

C1 y C2. La cardinalidad máxima de C1 en A, que se representa como card-máx
(C1, A), es el mayor número de correspondencias en las que cada elemento de
C1 puede participar. Asimismo, la cardinalidad máxima de C2 en A, denotada
por card-máx (C2, A), es el mayor número de correspondencias en las que
puede participar cada elemento de C2.

a) b)
c1 d1 c1 d1
c2 c2
d2 d2
c3 c3

c4 d3 c4 d3

c) d)
c1 d1 c1 d1

c2 c2
d2 d2
c3 c3
c4 d3 c4 d3

a) Agregación Uno a Uno. Card(C,A)=(x,1) y Card(D,A)=(x,1), con x en

{0,1}.
b) Agregación Uno a Muchos. Card(C,A)=(x,n) y Card(D,A)=(y,1), con x
en {0,1,...,n} e y en {0,1}.
c) Agregación Muchos a Uno. Card(C,A)=(x,1) y Card(D,A)=(y,n), con x
en {0,1} e y en {0,1,...,n}.
d) Agregación Muchos a Muchos. Card(C,A)=(x,n) y Card(D,A)=(y,m),
con x e y en {0,1,...,n), n y m valores indefinidos mayores que uno.

Consideremos de nuevo las agregaciones USA y POSEE entre PERSONA y

EDIFICIO:

Si se supone que cada persona usa varios edificios, card-máx (PERSONA,
USA) = n. Tutor-5

Si se supone que cada EDIFICIO puede tener varios habitantes, entonces,
card-máx (EDIFICIO, USA)=n.
Institución Cervantes 25
INSTITUCIÓN CERVANTES

Si se supone que cada persona puede poseer varios edificios, entonces, card-
máx (PERSONA, POSEE)=n.

Si se supone que cada edificio pertenece sólo a una persona, entonces, card-
mín (EDIFICIO, POSEE)=1 y card-máx (EDIFICIO, POSEE).

Estos ejemplos muestran que los valores importantes para card-máx (C1, A) son
1 y n; n representa cualquier número e indica que cada elemento de C1 puede
pertenecer a un número arbitrariamente grande de correspondencias. Card-máx
pocas veces adopta un valor fijo.
Si card-máx (C1, A)=1 y card-máx (C2, A)=1, se dice que la agregación es de
uno a uno. Si card-máx (C1, A)=n y card-máx (C2, A)=1, la agregación de C2 a
C1 es de uno a muchos. Si card-máx (C1, A)=1 y card-máx (C2, A)=n, la
agregación de C2 a C1 es de muchos a uno; por último, si card-máx (C1, A)=m y
card-máx (C2, A)=n (donde m y n representa valores superiores a 1), la
agregación de C2 a C1 es de muchos a muchos.

2. Agregación n-aria: Es una correspondencia establecida entre tres o más clases. Se

mantienen las definiciones de cardinalidades máxima y mínima.

Cardinalidad Mínima. Consideremos una agregación A entre las clases C1,C2,...,

Cn. La cardinalidad mínima de Ci en A, denotada por card-min(Ci,A), es el
menor número de correspondencias en las que cada elemento de Ci puede tomar
parte.

Cardinalidad Máxima. Consideremos una agregación A entre las clases C1,C2,...,

Cn. La cardinalidad máxima de Ci en A, denotada por card-max(Ci,A), es el
mayor número de correspondencias en las que cada elemento de Ci puede tomar
parte.

Jerarquías de Generalización
Una abstracción de generalización establece una correspondencia entre la clase
genérica (raíz) y las clases subconjunto. Tomemos la clase PERSONA como una
generalización de las clases HOMBRE y MUJER; cada elemento de éstas corresponde
exactamente a un elemento de la clase PERSONA. En esta generalización, cada persona
corresponde también a un elemento de la clase HOMBRE o un elemento de la clase
MUJER; sin embargo, esto no ocurre en todas las generalizaciones. Estas observaciones
se refieren a las propiedades de cobertura de la generalización, que se describen
formalmente a continuación:

1. Cobertura Total o Parcial. La cobertura de una generalización es total (t), si

cada elemento de la clase genérica corresponde al menos a un elemento de las clases
subconjuntos; es parcial (p), si existe algún elemento de la clase genérica que no
corresponde a ningún elemento de las clases subconjunto.
2. Cobertura exclusiva o superpuesta. La cobertura de una generalización es
exclusiva (e), si cada elemento de la clase genérica corresponde, a lo máximo, a un
elemento de las clases subconjunto; es superpuesta (s) si, al contrario, existe algún

26 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

elemento de la clase genérica que corresponde a elementos de dos o más clases

subconjunto diferentes.

Ejemplos

Persona

Hombre Mujer

a) total, exclusiva. Todas las personas son Hombres o Mujeres, pero no ambos.

Empleado

Administrativo Docente

b) total, superpuesta. Todos los empleados son Administrativos o Docentes,

pudiendo haber empleados desempeñando ambas funciones.

Estudiante

Egresado Títulado

c) parcial, exclusivo. Algunos estudiantes son egresados, mientras que otros

están titulados, pero no hay ningún estudiante en ambas situaciones.

Estudiante

Ingeniería Postgrado

d) parcial, superpuesta. Algunos estudiantes son de Ingeniería y otros son de

postgrado, y hay algunos estudiantes que son de ingeniería y también participan en
postgrado.

Modelos de Datos
En la unidad anterior, hemos visto algunos conceptos que creo conveniente enunciar para
que los tengamos en cuenta: Dato, modelo, esquema y modelo de datos. Si estos conceptos no
se recuerdan en esta instancia, creo conveniente recomendarles que los repasen a fin de poder
continuar con los conceptos que a continuación analizaremos. Si están presentes, pues
adelante.

Institución Cervantes 27
INSTITUCIÓN CERVANTES

Un modelo de datos es una serie de conceptos que pueden utilizarse para describir un
conjunto de datos y operaciones para manipular los mismos. Cuando un modelo de datos
describe un conjunto de conceptos de una realidad determinada, se llama modelo conceptual
de datos. Los conceptos de un modelo de datos se construyen por lo regular usando
mecanismos de abstracción y se describen mediante representaciones lingüísticas y gráficas.

Hay dos tipos de modelos de datos: modelos conceptuales, usados en el diseño de bases
de datos, y modelos lógicos, apoyados por los sistemas de gestión de base de datos
(DBMS), que son grandes paquetes de software que crean, modifican y mantienen base
de datos.

Modelos Conceptuales: Son instrumentos para representar la realidad a un nivel alto

de abstracción. Utilizando los modelos conceptuales, podemos construir una descripción
de la realidad, fácil de entender e interpretar.

Modelos Lógicos: Estos apoyan descripciones de datos procesables por un

computador; incluyen el modelo jerárquico, el modelo codasyl (o de redes) y el modelo
relacional.

Estos modelos tienen una correspondencia sencilla con la estructura física de la base de
datos. Más adelante se volverá a hacer referencia a estos modelos, mostrando con un
ejemplo como funcionan.

En el diseño de bases de datos se usan primero los modelos conceptuales para lograr
una descripción de alto nivel de la realidad; después se transforma el esquema
conceptual en un esquema lógico. La razón de este enfoque radica en la dificultad de
abstraer la estructura de bases de datos complejas. Un esquema es una representación
de una parte específica de la realidad, creada utilizando un determinado modelo de
datos. Dicho con mayor propiedad, un esquema es un conjunto estático de
representaciones lingüísticas o gráficas, invariables en el tiempo, que describen la
estructura de los datos de interés, como por ejemplo los de una organización.

El modelo de entidades-interrelacionadas (ER)

Este es el modelo de datos más ampliamente usado para el diseño conceptual de bases de
datos. El modelo fue introducido por Peter Chen en 1976, y se ha hecho cada vez más popular.

Originalmente el modelo ER incluía sólo los conceptos de entidad, interrelación y

atributos; más tarde, otros conceptos, como los atributos compuestos y las jerarquías de
generalización, se agregaron como componentes de modelo ER mejorado.

Elementos básicos del modelo Entidad Relación

En 1976, Peter Chen publicó el modelo entidad relación, el cual tuvo gran aceptación
principalmente por su expresividad gráfica. Sobre esta primera versión han trabajado
numerosos autores, generando distintas extensiones de mayor o menor utilidad y de
aceptación variable en el medio académico y profesional. Muchas de estas extensiones

28 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

son muy útiles, pero poco difundidas debido principalmente a la ausencia de

herramientas automatizadas que apoyen su uso. A continuación se definen los
elementos del modelo entidad relación básico.

Los conceptos básicos provistos por el modelo ER son atributos, identificadores,

interrelaciones y entidades.

Entidades: las entidades representan clases de objetos de la realidad. Es un objeto

que existe y puede ser distinguido de otro objeto. Persona, hombre, mujer, empleado,
ciudad son ejemplos de entidades para una base de datos de personal. Las entidades se
representan gráficamente por medio de rectángulos, como se muestra a continuación.
Una entidad se distingue de otra porque posee ciertas características que la hacen
única. A estas características se les conoce como atributo.
Tipo de
Entidad

Atributos: Los atributos representan las propiedades básicas de las entidades o

interrelaciones. Toda la información extensiva es portada por los atributos.

Por ejemplo los atributos de una entidad persona pueden ser: <nombre>,
<numero_de_seguro>, <profesión, título>. Los atributos de una entidad ciudad pueden
ser: nombre, altitud, númerodehabitantes. El único atributo de <vive_en> es
<fecha_de_cambio_de_domicilio>, con la fecha en que la persona se mudó a la ciudad.
El único atributo de <nacido_en> es <fechadenacimiento>. La forma de representar a
los atributos es:

Nombre Atributo

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

Simples y Compuestos. Un atributo simple no está dividido en subpartes y un
atributo compuestos se pueden dividir es subpartes. Ej: nombre-cliente se puede
dividir en apellido-cliente y nombre-cliente, la fecha-nacimiento se puede dividir en
día, mes y año de nacimiento.

Univaluados y multivaluados. Los atributos que tienen un único valor para una
entidad concreta. Si consideramos un conjunto de entidades empleado con el
atributo nombre-subordinado, cualquier empleado puede tener 0, 1 o varios
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 atributo se llama multivaluado.

Atributos nulos: se usa cuando una entidad no tiene un valor para el atributo. Por
ejemplo si un empleado no tiene subordinados, el valor nombre-subordinado para
ese empleado será nulo.

Atributos derivados: son valores que se pueden derivar de otros atributos o
entidades. Por ejemplo: la entidad empleado que posee los atributos de fecha-
ingreso y antigüedad. El valor de antigüedad se puede derivar del valor de fecha-
ingreso y de fecha-actual. En este caso el atributo fecha-ingreso se puede referenciar
como atributo base.

Institución Cervantes 29
INSTITUCIÓN CERVANTES

Identificador de un tipo de entidad: Un atributo, posiblemente compuesto, de un tipo

de entidad TE, es un Identificador de TE si y sólo si satisface las siguientes 2 propiedades
independientes del tiempo.
a. Unicidad. En cualquier momento dado, no existen dos elementos en TE con el
mismo valor de I.
b. Minimalidad. Si I es compuesto, no será posible eliminar ningún atributo
componente de I sin destruir la propiedad de unicidad.

Tipo de Atributo identificador

Entidad

Tipo de
Interrelaciones o Relaciones: Los Tipos de
Entidad 1
interrelación representan agregaciones de dos
o más entidades (interrelaciones binarias o n-
arias) no necesariamente diferentes (como son
las interrelaciones recursivas).
Atributo 1
El Identificador de un Tipo de Interrelación, Tipo de
se forma a partir de los identificadores de los ...
Interrelación
tipos de entidad que relaciona. Atributo n

Las interrelaciones se representan

gráficamente con rombos como se representa en
la figura anterior. Las interrelaciones n-arias Tipo de
conectan más de dos entidades. Entidad 2

D Ejemplo
La relación dueño-de puede ser interpretada como un tipo de interrelación entre
dos tipos de entidades Persona y Auto.

Los anillos son interrelaciones binarias que conectan una entidad consigo misma. Se
conocen también como interrelaciones recursivas. Por ejemplo la interrelación dirige
de la figura siguiente conecta los directores con sus subordinados, ambos representados
por la entidad empleado. Para distinguir entre los dos papeles de la entidad de la
interrelación, se asocian dos rótulos con la entidad; en la figura siguiente los dos rótulos
son <director_de> y <subordinado_a>.

Cardinalidad de tipo de entidad con respecto a un tipo de interrelación: Para los tipos
de interrelación la cardinalidad máxima (mínima) establece el mayor (menor) número de
correspondencias en cada una de los tipos de entidad involucradas en la interrelación.
Se define la Cardinalidad del Tipo de Entidad TE con respecto al tipo de interrelación
R como:
Card(TE,R) = (mínimo, máximo), con mínimo, máximo ∈ {0,...,n} y
mínimo ≤ máximo.

30 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

donde toda ocurrencia de TE debe participar al menos mínimo veces, y a lo más

máximo veces en R.
(mínimo, máximo)
TE R

Los Mecanismos de abstracción en el modelo ER

(Entidad-Relación)
Abstracción de clasificación: Los tres conceptos básicos del modelo ER, se
desarrollan como aplicaciones de la abstracción de clasificación:

1. Una entidad es una clase de objetos del mundo real con propiedades comunes.
2. Una interrelación es una clase de hechos atómicos (elementales) que relacionan
dos o más entidades.
3. Un atributo es una clase de valores que representan propiedades atómicas de las
entidades o interrelaciones.

Abstracción de agregación: Tres tipos de agregaciones caracterizan al modelo ER:

1. Una entidad es una agregación de atributos.
2. Una interrelación es una agregación de entidades y atributos.
3. Un atributo compuesto es una agregación de atributos.

Abstracción de generalización: La abstracción de la generalización las encarnan las

jerarquías de generalización y los subconjuntos. Usualmente sólo se aplica a entidades,
aunque algunas ampliaciones del modo ER aplican la abstracción de generalización
también a interrelaciones o atributos.

Cualidades del modelo ER

Es cierto que el modelo ER no es muy sencillo. En particular, las propiedades de
cardinalidad e identificación son difíciles de entender y usar. Sin embargo, estos rasgos
son muy útiles para entender las propiedades estructurales de los esquemas de bases de
datos.

A pesar de las apariencias, el modelo ER es mínimo. Ningún concepto puede

sustituirse por otra combinación de conceptos, con la única excepción de los atributos
compuestos.

El modelo ER está definido formalmente, como se ha mostrado en esta unidad.

También es gráficamente completo: cada uno de los conceptos presentados en este
apartado puede representarse en un esquema.

Institución Cervantes 31
INSTITUCIÓN CERVANTES

Los diagramas del modelo ER son fáciles de leer, especialmente si uno observa sólo los
símbolos gráficos centrales (rectángulos para las entidades, círculos para los atributos,
rombos para las interrelaciones, flechas dobles para las jerarquías de generalización,
óvalos para los atributos compuestos). La legibilidad decrece si se incluye la cardinalidad
de las interrelaciones, la cobertura de las generalizaciones, los identificadores.

El esquema obtenido con este modelo, (el diagrama ER), es por lo general estático en el
tiempo, debido a que un correcto análisis del problema y a un planteo exacto de la
solución del mismo, evitará que el esquema deba sufrir retoques en el futuro. Una vez
obtenido el esquema, es muy difícil que varíe su estructura. Recordemos las distintas
etapas del diseño de una Base de datos: Conceptual, lógico y físico. De estas etapas, la
única estática es la conceptual, ya que como dijimos, no sufrirá alteraciones si se realizó
un buen trabajo de análisis. Las otras etapas, variarán según el modelo de
implementación utilizado, como se ve reflejado en el cuadro de la página 15 de este
módulo.

Por último, el modelo ER representa un buen término medio entre el poder de

expresión, la simplicidad y la minimalidad. Muchas Críticas al modelo, pueden deberse
a una presentación pobre de sus cualidades.

D Ejemplo

Tipos de entidades y atributos

Auto: Patente (identificador)
Año Fabricación
Color
Persona: DNI (identificador)
Nombre

Tipos de Interrelaciones
Dueño_de: Fecha

Diagrama MER

(1,n)
Persona (1,1) Auto
Dueño de
@ Dni @ Patente
Fecha
Nombre Color
(1,n): Una persona puede tener uno o más autos
(1,1): Un auto puede tener sólo un dueño.

D Ejercicio resuelto

Modelar un sistema de biblioteca que permita saber:

autor de un libro

32 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

libros de un autor

préstamos de un alumno.

materia de un libro

editorial de un libro

Desarrollo

Tipos de entidad

Autor
@ Código Autor
Nombre
Fecha Nacimiento (fecha)
Nacionalidad

Libro
@ Código Libro
Título
Año Publicación

Alumno
@ Matrícula
Nombre

Ejemplar
@ Código Ejemplar

Materia
@ Código Materia
Materia

Carrera
@ Código Carrera

Editorial
@ Código Editorial
Editorial

Tipos de Interrelaciones
Autor_de:
@ Código Libro
@ Código Autor

Estudia:
@ Matrícula
@ Código Carrera

Préstamo:
@ Código Ejemplar
Institución Cervantes 33
INSTITUCIÓN CERVANTES

@ Matrícula
Fecha_préstamo
Fecha_devolución

Editado_por:
@ Código Editorial
@ Código Libro

Ejemplar_de:
@ Código Ejemplar
@ Código Libro

Es_de:
@ Código libro
@ Código Materia

Diagrama MER

(1,n) (1,1) (0,3)

Carrera Estudia Alumno Préstamo

(0,1)
Autor
Materia
Ejemplar
(1,n)
(1,1)

Autor_de
(1,n)

(1,n)

Es_de Ejemplar_de
(1,n) Libro (1,n)

(1,1)

Editado_por Editorial
(1,n)

Lectura de las cardinalidades:

Un Alumno estudia una y sólo una Carrera.

Una Carrera es estudiada por uno o muchos Alumnos.

34 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Un Alumno puede tener en préstamo ninguno o a lo más tres Ejemplares.

Un Ejemplar puede no estar en préstamo o estar en Préstamo a lo más una vez.

Un Ejemplar corresponde a uno y sólo un Libro.

Un Libro tiene uno o muchos Ejemplares.

Un Autor es autor de uno o muchos Libros.

Un Libro fue escrito por uno o muchos Autores.

Un Libro es acerca de una o muchas Materias.

Una Materia es abordada por uno o muchos Libros.

Una Libro es editado por una y sólo una Editorial.

Una Editorial ha editado uno o muchos Libros.

Se puede apreciar en este ejercicio que las interrelaciones cumplen un rol muy
importante dentro del esquema construido. En alguna de ellas, aparecen atributos que
ya se encuentran en las entidades que se vinculan generando redundancia de datos física,
la cual no es perjudicial ya que la función de esta duplicación es la de mantener las
relaciones entre las entidades participantes. Este tipo de redundancia, es la que
habíamos hablado en la unidad anterior (introducción) que podía aparecer y que estaba
permitida. Este resultado (que estudiaremos más adelante como conseguirlo) se obtiene
mediante la transformación de esquemas, es decir el paso del esquema conceptual al
esquema lógico.

Cómo Modelar en MER

Para modelar en MER se sigue generalmente el siguiente orden:

a. Identificar los tipos de entidades.

b. Identificar los tipos de interrelaciones.
c. Encontrar las cardinalidades.
d. Identificar los atributos de cada tipo de entidad.
e. Identificar las claves de cada tipo de entidad.

La regla básica es distinguir tipos de entidades e interrelaciones de atributos. Así, los

atributos deben ser atómicos y característicos del tipo de entidad o interrelación que
describan.

También los atributos deben pertenecer al tipo de entidad o interrelación que describen
y no a otro tipo.

Otra diferencia entre tipo de entidad y atributo es que, por ejemplo, se puede tener el
tipo de entidad Empleado, que tiene como atributo el departamento al que pertenece.
En forma alternativa se pueden tener los tipos de entidades Empleado y Departamento, y
el tipo de interrelación Trabaja_en, que relaciona un empleado con el departamento
donde trabaja.

Esta segunda alternativa es mejor desde el punto de vista del modelamiento conceptual
y presenta una clara diferencia entre atributo y tipos de entidad.
Institución Cervantes 35
INSTITUCIÓN CERVANTES

Autoevaluación
1. Defina los mecanismos de abstracción. Para que se utilizan.
........................................................................................
........................................................................................
2. Qué entiende por el concepto de cardinalidad. Ejemplifique cada una.
........................................................................................
........................................................................................

3. Describa el proceso de modelar datos utilizando el modelo ER.

........................................................................................
........................................................................................

4. Explique las propiedades de la agregación y de la generalización entre clases.

........................................................................................
........................................................................................

5. Cuáles son los elementos básicos del modelo ER.

........................................................................................
........................................................................................

6. Qué cualidades del modelo ER cree conveniente destacar.

........................................................................................
........................................................................................

7. Señalar en una narración, entidades, los atributos y las relaciones entre las
mismas de un problema planteado por usted.
........................................................................................
........................................................................................

8. A partir de un diagrama ER que usted deberá crear, hacer la narración del mismo
proponiendo el problema.
........................................................................................
........................................................................................

36 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Unidad III
Arquitectura de las bases de datos

Objetivos

Reconocer las diferentes funciones de los actores en la administración física de una
base de datos.

Comprender el funcionamiento de los diferentes tipos de estructuras de datos.

Distinguir los diferentes tipos de estructuras de bases de datos.

Distinguir las diferentes capas de la arquitectura de una base de datos.

Institución Cervantes 37
INSTITUCIÓN CERVANTES

Estructuras de Bases de Datos

Todos los sistemas operativos proporcionan servicios de administración de datos. Sin
embargo, no son suficientes para las necesidades especializadas de un DBMS. Para
mejorar el rendimiento, los productos DBMS construyen y mantienen estructuras
especializadas de datos. Este mantenimiento de los datos, lo realiza el mismo MOTOR o
DBMS de la base de datos. Los procesos que veremos y estudiaremos a continuación,
son realizados por este componente, integrante fundamental de todo sistema de base de
datos.

Archivos Planos
Las estructuras de datos que manejan los DBMS, se conocen como archivos planos.

Un archivo plano es un archivo que no posee grupos repetidos. En la siguiente figura

aparece un archivo plano (A) y en (B) aparece un archivo que no es plano en razón del
campo que se repite, Ítem. Un archivo plano puede ser almacenado con cualquier
organización común de archivos como secuencial, secuencial indexada, o directa. Los
archivos planos han sido utilizados a lo largo de muchos años en el procesamiento de
datos comerciales. Son procesados en un orden predeterminado, en secuencia
ascendente sobre un campo clave o no.

Archivo Plano Archivo NO Plano

Registro de inscripción (A) Registro de Facturas (B)
NumEstudiante NumClase Semestre NumFactura Artículo(s)

Datos de muestra (A) Datos de Muestra (B)

200 70 88S 1000 10 20 30 20
100 30 89F 1010 50
300 20 89F 1020 10 20 30
200 30 1030 50 90
300 70 88S
100 20 88S

Como se interpreta esto: lo primero que debemos tener en cuenta y recordar son las
definiciones de archivo, registro y campo. Una vez que lo hayan recordado, tomaremos
el ejemplo de Inscripción que llamaremos A y el de Facturas, que llamaremos B. El
registro A es una estructura PLANA, debido a que en cada uno de sus registros la
cantidad de campos o columnas que lo integran, está siempre dentro del mismo rango, es
decir que a lo largo de todo el archivo, la cantidad de campos o columnas es siempre la
misma. Puede ser que el valor para alguna intersección (fila, columna) no este
disponible en ese momento, pero el lugar está reservado para recibir un valor en
cualquier instante. Observen la fila cuyos valores son (200, 30, blanco). El componente
o valor del semestre aun no ha sido ingresado, pero la estructura sigue manteniendo su
capacidad de recibir el dato, y además esa intersección ocupa un lugar en la estructura.
Es decir, no está el valor pero se conserva el espacio reservado.

En el caso de la estructura B (Facturas), los espacios no se conservan ni se reservan.

Aparecen lo que se conoce como grupos repetidos. Los grupos repetidos son aquellos

38 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

componentes de la estructura que pueden aparecer más de una vez en el mismo registro,
como por ejemplo el Artículo. En una factura pueden existir varios artículos facturados.
En este tipo de estructura, en un mismo registro, pueden guardarse varios artículos, pero
no en cada registro siempre se encontrará la misma cantidad de artículos ingresados.
Observen el caso B y verán la diferencia entre la cantidad de artículos del primer registro
y de los posteriores. Los grupos repetidos son pues, los artículos, ya que en una misma
factura puede haber varios de ellos que son los que formarán el grupo.

Procesamiento de Archivos Planos

Lista Secuencial
En ocasiones, los usuarios desean procesar los archivos de distintas maneras y necesitan
obtener de los datos, información ordenada de distintas maneras. Considere los registros
de INSCRIPCIÓN de la figura anterior. Para generar el listado de horarios de
estudiantes, deben procesarse según la secuencia u ordenamiento de NumEstudiante.
Para producir listados de clases, los registros deben ser procesados y ordenados según la
secuencia NumClase, no en ambos a la vez, ya que esto no es posible. La solución
tradicional al problema de procesar registros en órdenes distintos. Es clasificarlos
primero por estudiante y procesar o generar los horarios, a continuación poner los
registros en el orden de clases y producir las listas de clases.

Para algunas aplicaciones, como en un sistema de procesamiento por lotes (donde cada
registro se procesa uno a continuación del otro sin saltearse ninguno), esta solución
aunque torpe es eficaz. Suponga que ambos ordenamientos necesitan existir en forma
simultánea, porque dos usuarios necesitan manejar el mismo archivo pero en dos listas
distintas en los registros INSCRIPCION.

Una solución es crear dos copias del archivo INSCRIPCION y ordenarlas como se
muestra en la siguiente figura. Para generar cada una de estas copias del archivo,
deberán crearse sendos programas que permitan ejecutar el proceso necesario.

Num Num Num Num

Semestre Semestre
Estudiante Clase Estudiante Clase
100 30 88F 300 20 89F
100 20 88S 100 20 88S
200 70 88S 100 30 89F
200 30 88S 200 30 88S
300 20 89F 200 70 88S
300 70 88S 300 70 88S
(A) (B)

En vista de que los datos quedan listados en orden secuencial, tal estructura de datos a
veces se conoce como lista secuencial. Las listas secuenciales se pueden almacenar en
archivos secuenciales. Sin embargo, no se hace en productos DBMS, porque la lectura

Institución Cervantes 39
INSTITUCIÓN CERVANTES

secuencial de un archivo es un proceso lento, debido a que para poder recorrer el archivo
debo ir registro por registro hasta llegar al final del mismo. Los archivos secuenciales no
se pueden actualizar en la parte intermedia, sin escribir la totalidad del archivo. Si lo que
queremos es agregar un registro y que quede ordenado, primero se agrega el registro (el
cual es ingresado en la última posición) y luego se corren los procesos para reordenar las
listas. Esto deberá ejecutarse cada vez que se agregue, modifique o elimine algún
registro. El mantenimiento de varios órdenes conservando varias copias de la lista
secuencial es por lo regular poco eficaz porque las listas secuenciales duplicadas pueden
crear problemas de integridad de los datos, duplicación de datos y de espacio de
almacenamiento en disco. Otras estructuras de datos nos permiten procesar registros en
órdenes distintos y no requieren la duplicación de los datos. Estos casos veremos a
continuación.

Mantener un orden con listas vinculadas

Las listas vinculadas pueden ser utilizadas para mantener en orden lógico registros que
no están en orden físico. Para crear una lista vinculada, agregamos un campo a cada
registro de datos. El campo vínculo contiene la dirección del siguiente registro en
secuencia lógica. La siguiente figura muestra los registros INSCRIPCION que se han
expandido a fin de incluir la lista vinculada; tal lista mantiene los registros en el orden
NumEstudiante. Observe que el vínculo para el último estudiante numérico en la lista es
cero.

Nº de Num Num Semestre Vinculo de Vínculo de

registro relativo Estudiante Clase Estudiante Clase
1 200 70 88S 4 5
2 100 30 89F 6 1
3 300 20 89F 5 4
4 250 30 88S 3 2
5 350 70 88S 0 0
6 150 20 88S 1 3
Inicio de la lista de estudiantes = 2
Inicio de lista de clases = 6

La figura anterior muestra los registros INSCRIPCION con dos listas vinculadas: una
de ellas mantiene el orden NumEstudiante y la otra el orden NumClase. Se han
agregado dos campos de vinculación a los registros, uno por cada lista.
Voy a tratar de explicar como funciona esto:
1. La estructura original es:
Num Num Semestre
Estudiante Clase
200 70 88S
100 30 89F
300 20 89F
250 30 88S
350 70 88S
150 20 88S

40 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

2. Cada registro (fila) tiene asociado un número que indica la posición de registro
relativa (observen la primera columna).

Nº de registro Num Num Semestre

relativo Estudiante Clase
1 200 70 88S
2 100 30 89F
3 300 20 89F
4 250 30 88S
5 350 70 88S
6 150 20 88S

3. Luego se establece el menor valor o el valor inicial en la secuencia de

Num.Estudiante. Inicio de la lista de estudiantes = 2 ya que en la posición relativa
de registro (PRR) 2 se encuentra el valor más bajo de la columna. Una vez
establecido el inicio de la secuencia, se busca el valor siguiente que en el caso de
NumEstudiante sería el registro de posición relativa 6. En este punto se indica al
puntero de lectura que el siguiente registro en la secuencia es el que se encuentra
en la posición relativa 6. Cuál será el siguiente?

Nº de Num Num Semestre Vinculo de

registro relativo Estudiante Clase Estudiante
1 200 70 88S
2 100 30 89F 6
3 300 20 89F
4 250 30 88S
5 350 70 88S
6 150 20 88S
Inicio de la lista de estudiantes = 2

4. Volvamos a observar el cuadro. El siguiente valor en orden es el 200 que se

encuentra en la PRR 1. Por lo tanto el puntero se encamina hacia allí.

Nº de Num Num Semestre Vinculo de

registro relativo Estudiante Clase Estudiante
1 200 70 88S
2 100 30 89F 6
3 300 20 89F
4 250 30 88S
5 350 70 88S
6 150 20 88S 1
Inicio de la lista de estudiantes = 2

Institución Cervantes 41
INSTITUCIÓN CERVANTES

5. Los pasos sucesivos, se realizan de igual manera hasta completar el ordenamiento

deseado. El resultado final sería el indicado en el primer cuadro de este tema. El
último vínculo, apunta a la posición cero, esto quiere decir que el último registro
apunta al final del archivo. Este valor cero, indica que se ha llegado al final del
archivo. Indica EOF por ustedes visto en lenguajes de programación.
Como ejercitación o práctica, les propongo que traten de armar la misma lista para el
otro ordenamiento (vínculo clase).
Cuando se efectúan inserciones y supresiones, las listas vinculadas tienen una gran
ventaja sobre las listas secuenciales. Por ejemplo, para insertar un registro
INSCRIPCION, éste se agrega al extremo físico de la lista o sea al final, y sólo los valores
de los campos de vinculación necesitarían ser modificados para colocar el nuevo registro
en la secuencia correcta.

Cuando se suprime un registro en la lista secuencial, se crea un espacio vacío. En una

lista vinculada, se puede suprimir un registro modificando los valores del vínculo, o de
los campos del apuntador.

Existen muchas variaciones de las listas vinculadas. Podemos convertir la lista en una
lista circular, es decir en un anillo, modificando el vínculo del último registro de cero
hacia la dirección del primer registro de la lista. Ahora podemos llegar a todos los
elementos de la lista empezando por cualquiera de los elementos de la misma. La
siguiente figura muestra una lista circular para el orden NumEstudiante.

Nº de registro Num Num Semestre Vínculo

relativo Estudiante Clase NumEstudiante
1 200 70 88S 4
2 100 30 89F 6
3 300 20 89F 5
4 250 30 89S 3
5 350 70 88S 2
6 150 20 88S 1
Inicio de Lista = 2 Lista vinculada circular (a)

Una lista vinculada de dos direcciones posee vínculos en ambos sentidos (ascendentes
y descendente). En la figura siguiente se ha creado una lista vinculada en dos direcciones
para órdenes de Estudiante tanto ascendentes como descendentes.

Nº de registro Num Num Semestre Vínculo Vínculo

relativo Estudiante Clase Ascendente Descendente
1 200 70 88S 4 6
2 100 30 89F 6 0
3 300 20 89F 5 4
4 250 30 89S 3 1
5 350 70 88S 0 3
6 150 20 88S 1 2
Inicio de Lista Ascendente= 2 Lista vinculada en dos direcciones (b)
Inicio de Lista Descendente = 5

42 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Los registros ordenados utilizando listas vinculadas no pueden almacenarse en un

archivo secuencial porque se necesita de algún tipo de organización de archivo de acceso
directo a fin de utilizar los valores de enlace o de vínculo. Se requiere de una
organización secuencial indexada o de una organización de archivo directo para el
procesamiento de listas vinculadas.

Mantener un orden con índices

Un orden de registro lógico también puede ser mantenido utilizando índices o, también
conocidos como Listas Invertidas. Un índice es sólo una tabla que hace una referencia
cruzada con las direcciones de registro (PRR) de otro valor de campo. La figura siguiente
(A) muestra los registros INSCRIPCION almacenados sin ningún orden en particular, y
(B) muestra un índice sobre NumEstudiante. En este índice los NumEstudiante se
encuentran organizados en secuencia, con cada entrada de la lista apuntando a un
registro correspondiente de los datos originales.

Como se puede observar, el índice no es nada más que una lista ordenada de
NumEstudiante. Para procesar en secuencia INSCRIPCION en NumEstudiante,
procesamos el índice de esa manera, obteniendo los datos INSCRIPCION y leyendo los
registros indicados por los apuntadores. La figura (C) muestra otro índice para
INSCRIPCION, éste manteniendo un orden NumClase.

Nº de Num Num Semestre Num Nº de Num Nº de

registro Estudiante Clase Estudi registro Clase registro
relativo ante relativo relativo
1 200 70 88S 100 2 20 3
2 100 30 89F 150 6 20 6
3 300 20 89F 200 1 30 2
4 250 30 88S 250 4 30 4
5 350 70 88S 300 3 70 1
6 150 20 88S 350 5 70 5
(A) (B) (C)

Al utilizar un índice, los datos a ordenarse (aquí, INSCRIPCION) deben residir en un

archivo secuencial o directo indexado, aunque los índices pueden residir en cualquier
otro tipo de archivo. En la práctica, todos los productos DBMS conservan tanto los datos
como los índices en archivos directos.

Si se compara la lista vinculada con el índice, notará la diferencia esencial entre ambos.
En una lista vinculada, los apuntadores se encuentran almacenados junto con los datos.
Cada registro contiene un campo de vinculación, con un apuntador a la dirección del
siguiente registro relacionado. En el caso de un índice, los apuntadores se almacenan en
índices separados de los datos. Entonces los registros de datos mismos no contienen
apuntadores. Se utilizan ambas técnicas en los productos comerciales.

Institución Cervantes 43
INSTITUCIÓN CERVANTES

Bases de Datos Jerárquicas

El modelo jerárquico tiene dos conceptos básicos de estructuración: los tipos de
registros y los tipos de interrelaciones padre-hijo. Un tipo de registros es la definición de
un grupo de registros que almacenan información del mismo tipo. Un tipo de registros
tiene muchas ocurrencias, denominadas registros. Cada tipo de registros contiene una
colección de tipos de campos, que son elementos de datos con nombre. Cada tipo de
campos está definido como un número entero, real, cadena de caracteres, etc.
dependiendo de los tipos primitivos que trate el sistema. Un tipo de interrelaciones
padre-hijo (tipo IPH) es una interrelación de uno a muchos entre un tipo de registros
padre y un tipo de registros hijo.

Una ocurrencia de un tipo de interrelaciones padre-hijo consiste en un registro del tipo

de registros padre y muchas (cero o más) ocurrencias del tipo de registros hijos. En
adelante, se usará la palabra registro para designar el tipo o la ocurrencia, dependiendo
del contexto, lo mismo se aplica a las interrelaciones padre-hijo, solamente cuando haya
ambigüedad se usará específicamente el término tipo de registros, o tipo de interrelaciones
padre-hijo.

Un esquema de base de datos jerárquica contiene varias jerarquías; cada una (o el

esquema jerárquico completo) consiste en varios tipos de registros y tipos de IPH
colocados de manera que formen un árbol
Curso
NumCurso Título

Req Ofrecimiento
NumReq NumOfr Fecha Lugar

Profesor Estudiante
NumEmp Nombre NumEmp Nombre Calificacion

En el modelo jerárquico de la figura muestra un tipo de conjuntos y su ocurrencia en el

modelo de redes. En el modelo jerárquico, Curso y Ofrecimiento serán dos tipos de
registros, pero la interrelación padre-hijo con curso como padre y ofrecimiento como hijo
no tendrá nombre.

La siguiente figura muestra un esquema jerárquico con cuatro tipos de registros y tres
tipos de IPH.

44 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Podemos referirnos a los tipos de IPH como el par (tipo de registros padre, tipo de
registros hijo). Los tres tipos de IPH de la figura anterior son:

Departamento, Empleado

Departamento, Proyecto

Departamento
Num_Dep ....

Empleado Proyecto
ID_Empl .... Num_Proy ....

Equipo
ID_Equipo ....

Proyecto, Equipo

Aunque los IPH no tienen nombre, tienen asociado un significado; por ejemplo, en la
figura anterior, una ocurrencia del tipo IPH (Departamento, Proyecto) relaciona el
registro padre de un departamento a los registros de los proyectos que controla. A
diferencia de los modelos de redes, el modelo jerárquico sólo puede tener una
interrelación entre un par de tipos de registros; ésta es la razón por la que se puede dejar
sin nombre.

Propiedades de los esquemas

jerárquicos
Primero se definen dos términos: los tipos de registros raíz y los tipos de registros hoja
en un esquema jerárquico. La raíz de la jerarquía es el registro más alto de la misma; no
participa como tipo de registros hijo en ningún tipo de IPH. Un tipo de registros que no
participa como IPH como padre en ningún tipo de IPH se denomina hoja de la
jerarquía.

Un esquema jerárquico de tipos de registros y tipos de IPH debe tener las siguientes
propiedades:

1. Todo tipo de registros, excepto la raíz, participa como tipo de registros hijo en un
sólo tipo de IPH.
2. Un tipo de registros puede participar como registro padre en cualquier número
(cero o más) de tipos de IPH.

Institución Cervantes 45
 INSTITUCIÓN CERVANTES

3. Si un tipo de registros participa como padre en más de un tipo de IPH, sus tipos de
registros hijos están ordenados. El orden se muestra, por convenio, de izquierda a
derecha en un diagrama de esquema jerárquico.

Estas propiedades de un esquema jerárquico significan que cada tipo de registros

excepto la raíz tienen exactamente un tipo de registros padre. Sin embargo, un tipo de
registros puede tener varios tipos de registros hijos, que se ordenan de izquierda a
derecha.
13 SOFTWARE

21 Adam 10 Barnes 78 Grant . . . . . 15 Compilador 18 Ventanas

En el primer ejemplo empleado es el primer hijo de departamento y proyecto es el

segundo hijo. Estas propiedades limitan el tipo de interrelaciones que pueden estar
representadas en un esquema jerárquico. En particular, las interrelaciones de muchos a
muchos entre los tipos de registros no se pueden representar directamente, porque las
interrelaciones padre-hijo son interrelaciones de uno a muchos y un tipo de registros no
puede participar como hijo en dos o más interrelaciones distintas padre-hijo. Estas
limitaciones causan problemas cuando se intenta definir el esquema jerárquico de una
base de datos que contiene dichas relaciones no jerárquicas.

El Modelo de Redes
El modelo de datos de red representa de inmediato relaciones uno a muchos y, por lo
tanto, puede ser utilizado para representar todo tipo de objetos excepto objetos
compuestos muchos a muchos, tales objetos deben ser transformados a relaciones uno a
muchos. El modelo de datos de red de mayor importancia es el DBTG CODASYL
(Conference on Data System languajes, Data Basa Task Group).

Hay dos conceptos básicos de estructuras en el modelo de redes: tipos de registros y

tipos de conjuntos. Cada tipo de registros describe la estructura de un grupo de registros
que almacenan el mismo tipo de registros. Un tipo de conjuntos es una interrelación de
uno a muchos entre dos tipos de registros; cada registro representa alguna información
del mundo real de un grupo de elementos, denominados elementos de datos o atributos
de ese registro. Para un tipo de conjuntos dado, una ocurrencia del conjunto es una
colección de registros que contiene un registro del tipo de registros propietario, y muchos
registros del tipo de registro miembro.

La siguiente figura muestra dos tipos de registros, estudiante y curso, con el tipo de
conjuntos Se-Matricula entre ellos, con Estudiante como el tipo de registros propietario y
Curso como el tipo de registros miembro.

46 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

La figura anterior muestra dos tipos de registros Estudiante y Curso, con el tipo de
conjuntos Se_Matricula entre ellos, con Estudiante como el tipo de registros propietario y
Curso como el tipo de registros miembro. La representación diagramática en la que la
flecha va del registro propietario al registro miembro se denomina diagrama Bachman,

John Smith 19 Varón

CS347 Ceri CS311 Batini CS144 Navathe

(b) Una ocurrencia del tipo de conjuntos Se_Matricula

por Charles Bachman, que fue el primero en introducirla. Una base de datos puede
tener muchas ocurrencias del tipo de conjuntos <se_matricula>, una por estudiante.

Para distinguir un elemento de datos con valores múltiples, se encierra entre paréntesis.
El tipo de registros conductor incluye un grupo de repetición denominado Coches, que
es un tipo compuesto de los elementos de datos Num-Matrícula, Marca, Año y Color.
Puede haber varios coches dentro de un caso del registro Conductor, cada uno con
valores para los cuatro elementos de datos.

La noción de conjunto (o caso de conjunto) en el modelo de redes difiere de la noción

matemática de conjunto en dos aspectos importantes:

1. El caso de un conjunto tiene un elemento distinguido (el registro propietario),

mientras que en un conjunto matemático no hay distinción entre los miembros de un
conjunto.
2. Los registros miembros dentro de una ocurrencia de conjunto están ordenados en el
modelo de redes, mientras que el orden es indiferente en un conjunto matemático.
Por estas razones a veces se llama al conjunto del modelo de redes conjunto
acoplado al propietario o co-conjunto.
Calificaciones_Exámenes
Nombre_Estud. Num_Curso (Califc.)
Estudiante
Nombre Edad Sexo

Se_Matricula
Curso
Num_Curs Nombre_Instructor

(a) Un tipo de conjuntos (Se_Matricula)

(a) Tipo de registros Calificaciones_Exámenes, con el elemento de datos vector

Conductor
(Coches)
NSS Num_Lic_Conduc. Nº Colo
Marca Año
Matric r
(b) Tipos de registros Conductor, con grupo de repetición Coches

Institución Cervantes 47
INSTITUCIÓN CERVANTES

Los tres niveles de la arquitectura de una base

de datos
La arquitectura ANSI/SPARC se divide en tres niveles, denominados niveles interno,
conceptual y externo.

Nivel Externo (Vistas

individuales de los
usuarios)

Nivel Conceptual
(vista comunitaria de
los usuarios)

Nivel Interno (vista del

almacenamiento)

El nivel externo
Este nivel es el del usuario individual. Los usuarios pueden ser programadores de
aplicaciones o usuarios de terminales en línea, es decir, usuarios finales con cantidad de
variables de conocimientos de informática. El DBA (Administrador de la Base de Datos)
es un caso especialmente importante (pero, a diferencia de los usuarios ordinarios, el
DBA deberá interesarse también en los niveles conceptual e interno). Más adelante
hablaremos de cuáles son las características y funciones del DBA.

En el caso del programador de aplicaciones, dicho lenguaje será o bien uno de los
lenguajes de programación convencionales, o bien un lenguaje propio específico
para el sistema en cuestión.

Para el usuario final será o bien un lenguaje de consulta, o algún lenguaje de
aplicación especial, quizá manejado mediante formularios o menús, adaptado a los
requerimientos de ese usuario y apoyado por algún programa de aplicación en línea.

En lo que toca a este análisis, el aspecto importante de todos esos lenguajes es que
deben incluir un sublenguaje de datos, es decir, un subconjunto del lenguaje total que se
ocupe de manera específica de los objetos y operaciones de la base de datos (abreviado
DSL, data sublanguaje), está embebido (o inmerso) dentro del lenguaje anfitrión
correspondiente. Este último se encarga de varios aspectos no relacionados con la base de
datos, como por ejemplo variables locales (temporales), operaciones de cálculo, lógica
condicional, etc. Un sistema dado puede permitir el empleo de varios lenguajes
anfitriones y varios sublenguajes de datos.

48 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Nota: Un sublenguaje de datos en particular cuyo uso es posible en casi todos los
sistemas relacionales actuales es el lenguaje SQL. En casi todos estos sistemas SQL
puede utilizarse ya sea de manera interactiva como lenguaje de consulta interactiva o
embebido en otros lenguajes (Visual Basic, por ejemplo).

Toda vista externa se define mediante un esquema externo, que consiste básicamente en
definiciones de cada uno de los diversos tipos de registros externos en esa vista externa.

El nivel conceptual
La vista conceptual es una representación de toda la información contenida en la base de
datos, también (como el caso de la vista externa) en forma un tanto abstracta si se
compara con el almacenamiento físico de los datos. Además puede ser muy diferente de
la forma como percibe los datos cualquier usuario individual. A grandes rasgos, la vista
conceptual debe ser un panorama de los datos “tal como son”, y no como por fuerza los
perciben los usuarios debido a las limitaciones del lenguaje o el equipo específico
utilizado, por ejemplo.

La vista conceptual se define mediante un esquema conceptual (tema visto en la

unidad), el cual incluye definiciones de cada uno de los tipos de registro conceptual. El
esquema conceptual se escribe utilizando otro lenguaje de definición de datos, el DDL
conceptual. Si ha de lograrse la independencia de los datos, esas definiciones en DDL
conceptual no deberán implicar consideraciones de estructura de almacenamiento o
técnica de acceso. Deben ser sólo definiciones de contenido de información. Por tanto,
en el esquema conceptual no debe aludirse a representaciones de campos almacenados,
secuencia de registros almacenados, indexación, direccionamiento por dispersión,
apuntadores o cualquier otro detalle de almacenamiento y acceso. Si el esquema
conceptual se hace en verdad independiente de los datos de esta manera, entonces los
esquemas externos, definidos en términos de esquema conceptual, serán por fuerza
también independiente de los datos.

Así pues, la vista conceptual es una vista del contenido total de la base de datos, y el
esquema conceptual es una definición de esa vista. No obstante, sería engañoso sugerir que
el esquema conceptual es sólo un conjunto de definiciones similar a las sencillas definiciones
de registros encontradas hoy día (por ejemplo, en un programa en Cobol).

El nivel interno
El tercer nivel de la arquitectura es el nivel interno. La vista interna es una
representación de bajo nivel de toda la base de datos; se compone de varias ocurrencias de
varios tipos de registro interno. La vista interna, por tanto, está a un paso del nivel físico,
ya que no maneja registros físicos (llamados también páginas o bloques), ni otras
consideraciones específicas de los dispositivos como son los tamaños de cilindros o de
pistas. En esencia, la vista interna supone un espacio lineal infinito de direccionamiento.
Los detalles de correspondencia entre ese espacio de direccionamiento y el espacio físico
dependen en alto grado del equipo utilizado y se omiten en forma deliberada de la
arquitectura general.

Institución Cervantes 49
INSTITUCIÓN CERVANTES

La vista interna se define mediante el esquema interno, el cual no solo define los
diversos tipos de registros almacenados, sino también especifica qué índices hay, cómo se
representan los registros almacenados, etc. El esquema interno se escribe con otro
lenguaje más de definición de datos, el DDL interno.

Nivel Interno: Acceso a la Base de Datos

Antes de utilizar las estructuras de almacenamiento mismas, examinaremos de manera
breve los factores implicados en el proceso general de acceso a bases de datos. Localizar
un elemento de información específico en la base de datos y presentarlo al usuario en
varios niveles de programas para acceso a datos. Por supuesto, los detalles de estos
niveles varían en forma apreciable en los distintos sistemas, y lo mismo sucede con la
terminología, pero los principios son bastante generales y pueden explicarse a grandes
rasgos de la siguiente manera.

1. En primer término, el DBMS decide qué registro almacenado se necesita, y pide al

manejador de archivos que extraiga ese registro.
2. A su vez, el manejador de archivos (Disk Manager) decide qué página contiene el
registro deseado, y pide al manejador de disco que lea esa página. La página es la
unidad de E/S, es decir, la cantidad de datos transferidos entre el disco y la
memoria principal en un solo acceso a disco. Los tamaños usuales de las páginas
son de 1K, 2K o 4K bytes.
3. Por último, el manejador de disco (File Manager) determina la localización física
de la página deseada en el disco, y realiza la operación de E/S necesaria.

DBMS
Solicita Registro Devuelve Registro
almacenado almacenado
Disk Manager
Solicita Página Devuelve página
almacenada almacenada
File Manager
Datos Leídos del
Operación de
disco
E/S en disco

Base de datos
Almacenada

50 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Manejador de disco
(Disk Manager)
El manejador de disco es un componente del sistema operativo. Es el encargado de
todas las operaciones físicas de E/S. Como tal, es evidente que necesita conocer las
direcciones físicas en el disco. Todo disco está dividido en sectores y pistas. La dirección
física de cada archivo, está localizada en la FAT (tabla de asignación de archivos) de cada
disco. El manejador de disco, utiliza la FAT para poder localizar físicamente el archivo
solicitado. Es también el encargado de colocarle a cada página del disco un número
único, que no se vuelve a repetir en ese disco. Es como si armara el índice del libro que
queremos leer. En cada página tiene una información determinada y a su vez a esa
página le coloca un número. Luego arma el índice (FAT) y en el almacena los datos
necesarios para localizar la información sin tener que leer todo el disco. O sea, voy al
índice, busco el tema en cuestión, veo en que página está, y abro el libro.

Por otro lado, el usuario del manejador de disco o sea, el manejador de archivos, no
necesita conocer esa información. Para el manejador de archivos, el disco es tan sólo una
colección lógica de conjuntos de páginas, cada uno de los cuales se compone de un grupo
de páginas de tamaño fijo.

Manejador de archivos
(File Manager)
El manejador de archivos utiliza los recursos recién descriptos del manejador de disco
de manera tal que su usuario (el DBMS) puede percibir el disco como un conjunto de
archivos almacenados. Cada conjunto de páginas contendrá uno o más archivos
almacenados, esto es, que en una misma página pueden haber diferentes archivos
almacenados, tal como si fuera un libro; en una misma página de ese libro pueden haber
varios temas. El DBMS sí necesita saber que existen conjuntos de páginas, aunque no se
encarga de manejarlos en detalles. En particular, el DBMS necesita saber cuándo dos
archivos almacenados comparten el mismo conjunto de páginas o cuándo dos registros
almacenados comparten la misma página.

Cada archivo almacenado se identifica mediante un nombre de archivo o identificador

de archivo, único por lo menos dentro del conjunto de páginas que lo contiene, y cada
registro almacenado, a su vez, se identifica mediante un número de registro único al
menos dentro del archivo almacenado que lo contiene. Traten de pensar en el disco
como si fuera un libro: está lleno de páginas en las cuales se guarda información. Cada
página es única dentro del libro, tiene un índice para acceder más rápido, en una misma
página puede haber más de un tema, cada tema es un archivo. Para más información,
remitirse a la página 60 del libro de C.J.Date)

Agrupamiento o Clustering
La idea básica del agrupamiento es procurar almacenar juntos físicamente los registros
que tienen una relación lógica entre sí, o sea que pertenecen al mismo archivo. Las
páginas del disco tienen una cierta capacidad de almacenamiento, o sea que pueden

Institución Cervantes 51
INSTITUCIÓN CERVANTES

almacenar hasta cierta cantidad de información por página. Cuando la página se llena y
el archivo sigue creciendo, o sea que el archivo no entra en una sola página, la
información se debe seguir almacenando. Lo que el Sistema Operativo hace es buscar la
página más cercana y continúa con la actualización del archivo. Puede que esa nueva
página ya contenga información de otro archivo. Esta despaginación obliga al S.O. a
almacenar dos direcciones de página para el mismo archivo, que pueden o no ser
continuas. La FAT, tiene designada (como ustedes deben conocer) un cierto espacio de
almacenamiento. Si los archivos están muy fragmentados, el espacio utilizado en la
FAT, va creciendo. Además, para poder leer un archivo, el File Manager necesita
realizar operaciones de E/S por cada proceso. Al tener la información fragmentada, las
operaciones de E/S se incrementan, provocando un aumento en los tiempos de
búsqueda, desgaste mecánico y físico de los componentes, etc. Por lo tanto el
agrupamiento o defragmentación (tan conocidos en entornos Windows) lo que hacen es
tratar de agrupar la información respecto al mismo archivo, en la cantidad menor de
páginas posibles.

El agrupamiento físico de los datos es un factor de importancia extrema para el

desempeño y el rendimiento de las bases de datos. Desde luego, un archivo (o conjunto
de archivos) determinado puede agruparse físicamente en una y sólo una forma a la vez.

El DBMS puede hacer posible el agrupamiento, tanto dentro de un archivo como entre
varios archivos, si almacena los registros que tienen una relación lógica entre sí en la
misma página cuando sea posible y en las páginas adyacentes cuando no lo sea.

Cuando el DBMS crea un nuevo registro almacenado, el manejador de archivos debe

permitirle especificar el almacenamiento del registro “cerca” de algún registro ya
existente. El manejador de archivos, a su vez, hará lo posible por lograr que dos páginas
adyacentes lógicamente estén contiguas físicamente en el disco. Por supuesto el DBMS
sólo puede saber cuál agrupamiento se requiere si el administrador de la base de datos es
capaz de indicárselo. Un buen DBMS deberá permitir al DBA especificar diferentes
clases de agrupamiento para distintos archivos. También deberá permitir la modificación
del agrupamiento de un archivo determinado en caso de cambiar los requerimientos de
desempeño. Desde luego, si ha de lograrse la independencia de los datos, ninguno de
estos cambios en el agrupamiento físico deberá requerir cambios correspondientes en los
programas de aplicación.

Indexación
El objetivo principal de los índices es la agilización en la búsqueda y ordenación de
datos. Sin embargo, existe una desventaja, hacen más lenta la actualización de archivos.
Por ejemplo, cuando se añade un registro almacenado nuevo al archivo indexado, es
preciso agregar también una entrada al índice. En términos generales, la pregunta que se
debe responder cuando se estudia la posible indexación, según el campo dado, será: ¿Qué
es más importante, una eficiente recuperación de datos con base en los valores del campo
en cuestión, o el trabajo adicional de actualización requerido para lograr esa eficiencia?.

En esencia, los índices se pueden utilizar de dos maneras distintas. En primer término,
pueden servir para tener acceso secuencial al archivo indexado, (Tutor-7). Acceder
secuencialmente a un archivo indexado quiere decir: llegar a un valor de forma directa y

52 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

a partir de allí recorrer el resto de forma secuencial. Por ejemplo: acceder al apellido
Pérez y desde ahí recorrer uno por uno los Pérez hasta encontrar el buscado.

En segundo término, los índices pueden servir también para tener acceso directo a los
registros individuales del archivo indexado con base en un valor dado del campo
indexado. Ingresar directamente el valor del Legajo del Pérez que busco.

De hecho, las dos formas básicas recién delineadas de utilizar índices se pueden
generalizar un poco:

Acceso secuencial: El índice puede ser útil en consultas de intervalos, por ejemplo,
“hallar los proveedores cuya ciudad quede dentro de un cierto intervalo alfabético”
(digamos, que comience con una letra en el intervalo L-R).

Acceso directo: el índice puede ser útil también en consultas por listas, por ejemplo,
“hallar todos los proveedores cuya ciudad está en alguna lista especificada”.

Hay ciertas consultas –casi todas pruebas de existencia- que se pueden responder
empleando sólo el índice, sin leer en absoluto el archivo indexado. Como por ejemplo,
considérese la consulta “¿Hay proveedores en Atenas?” la respuesta a esa pregunta es
afirmativa si y sólo si existe una entrada para Atenas en el índice ciudad.

Un archivo almacenado puede tener muchos índices. Por ejemplo el archivo

almacenado de proveedores podría tener un índice ciudad además un índice situación.
Estos índices podrían utilizarse para lograr un acceso eficiente a los registros de
proveedor con base en cualquiera de los campos ciudad o situación o ambos.

Indexación densa y no densa

Como ya hemos mencionado anteriormente, el objetivo fundamental de los índices es
acelerar las búsquedas para la obtención de datos. Dicho de otra manera, reducir las
operaciones de E/S de disco necesarias para obtener el registro almacenado solicitado.
En lo básico, esto se logra por medio de apuntadores, y hasta ahora hemos supuesto que
estos apuntadores apuntan a registros. El mismo objetivo podría alcanzarse, si estos
apuntadores apuntaran a páginas de registros (es decir, a un número de página).

Institución Cervantes 53
INSTITUCIÓN CERVANTES

Se dice que un índice como el de la figura es no denso porque no contiene una entrada
para cada registro almacenado del archivo indexado. En cambio, todos los índices
estudiados hasta aquí han sido densos (apuntan a un registro almacenado). Una ventaja
de los índices no densos, es el reducido espacio de almacenamiento requerido en
comparación con un índice denso.

Arboles B (B-Trees)
Una clase de índices muy importante y de uso muy frecuente es el árbol B. Si bien es
cierto que no hay una estructura de almacenamiento óptima para todas las aplicaciones,
los árboles B ofrecen, al parecer, el mejor desempeño general. Por esta razón la mayor
parte de los sistemas relacionales incluyen árboles B como su forma principal de
estructura de almacenamiento, y en varios casos es la única.

Antes de explicar qué es un árbol B, será preciso presentar otra idea preliminar, el
concepto de índice multinivel o de estructura de árbol.

La razón para crear un índice, en primer lugar es obviar la necesidad de una revisión
física secuencial del archivo indexado. Sin embargo, sigue siendo necesaria una revisión
física secuencial del índice (recorrer el índice de forma secuencial). Si el archivo
indexado es de gran tamaño, el índice puede llegar a ser muy grande, y por tanto su
revisión secuencial, en sí, puede llegar a requerir bastante tiempo. La solución a este
problema es la misma de antes: tratar al índice como un archivo almacenado normal, y
crear un índice para él (un índice del índice). Esta idea puede llevarse a tantos niveles
como se desee (lo acostumbrado en la práctica son tres niveles; un archivo tendría que ser
enorme para requerir más de tres niveles de indexación).

Ahora podemos hablar de los árboles B. Un árbol B es un tipo especial de índice con
estructura de árbol. Los árboles B, como tales, fueron descriptos, por primera vez, en un
artículo de Baller y MacCreight en 1972. Desde entonces Baller y muchos otros
investigadores han propuesto gran cantidad de variaciones de la noción básica.

Como ya se mencionó, los árboles B de un tipo u otro son, hoy día, quizá, la estructura
de almacenamiento más común en los sistemas modernos de bases de datos. Aquí
describiremos la variación propuesta por Knuth. En la variación Knuth, el índice tiene
dos partes, el conjunto secuencia y el conjunto índice.
54 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

El conjunto secuencia consta de un índice de un solo nivel de datos reales; es un

índice que contiene una entrada por cada uno de los registros en el archivo. En
circunstancias normales, este índice es denso, pero podría ser no denso, si el archivo
indexado está agrupado según el campo indexado. Las entradas del índice están
agrupadas en páginas, y las páginas están encadenadas entre sí, de manera que el
orden lógico representado por el índice se obtiene siguiendo las entradas en orden
físico de la primera página de la cadena, seguidas de las entradas de orden físico de
la segunda página de la cadena, y así sucesivamente. De esta manera, el conjunto
secuencial permite un acceso secuencial rápido a los datos indexados.

El conjunto índice, a su vez, hace posible un acceso directo rápido al conjunto
secuencia (y por tanto también a los datos). Apunta a grupos de entradas dentro del
índice del conjunto de secuencia. El conjunto índice es en realidad un índice con
estructura de árbol del conjunto secuencia; de hecho, el conjunto índice es, en
términos estrictos, el árbol B. La combinación del conjunto índice y el conjunto
secuencia se denomina, en ocasiones, árbol “B más” (árbol B +) el nivel superior
del conjunto índice se compone de un solo nodo(es decir, una sola página, pero
desde luego con varias entradas de índice, como todos los demás nodos). Este nodo
superior recibe el nombre de raíz.

Un ejemplo de árbol B aparece en la figura de abajo. Observe que la hilera inferior de

la figura, el conjunto de secuencia es simplemente un índice. Contiene una entrada por
cada uno de los registros del archivo.

Un problema de las estructuras de árbol en general es que las inserciones y las

eliminaciones pueden desequilibrar el árbol. Un árbol está desequilibrado si los nodos
hoja no están todos en el mismo nivel, es decir, si diferentes nodos hojas están a
diferentes distancias del nodo raíz.

Como una búsqueda en el árbol requiere un acceso a disco por cada nodo visitado, los
tiempos de búsqueda pueden hacerse muy poco predecibles en un árbol desequilibrado.
La ventaja de los árboles B es que el algoritmo de inserción / eliminación garantiza en
todo momento el equilibrio del árbol (por esta razón se asegura, a veces, que la “B” del
nombre significa “Balanceado”).

70 140

1
10 70 72 130 141 250

2 5 9 11 15 47 51 58 68 135 136 139 142 180 249 251 256 270

Institución Cervantes 55
INSTITUCIÓN CERVANTES

1) Conjunto de Indices
2) Conjunto de Secuencias (Lista invertida apuntando a registros de datos)

Examinemos el ejemplo: la entrada superior contiene dos valores 70 y 140. Siguiendo

la vinculación más a la izquierda, podemos tener acceso a todos los registros cuyos
valores de campo clave son menores o iguales a 70; si seguimos el apuntador hacia el
medio, podemos tener acceso a todos los registros cuyos valores de campo clave sean
mayores a 70 e iguales o menores a 140. Si seguimos el apuntador más a la derecha,
podemos tener acceso a todos los registros cuyos valores de campo clave sean mayores a
140.

De forma similar, en el siguiente nivel existen dos valores y tres apuntadores en cada
entrada de índice. Cada vez que bajamos otro nivel, reducimos el ámbito de búsqueda
para un registro particular. Este método nos arrima al registro buscado por
aproximación. En el conjunto de secuencias, tendremos ya definida una entrada por
cada registro almacenado.

El Administrador de Bases de Datos

(DBA)
El administrador de datos es una persona que toma las decisiones estratégicas y políticas
con respecto a la información de la empresa, y el administrador de bases de datos (DBA) es
quien proporciona el apoyo técnico necesario para poner en práctica esas decisiones. Por
tanto, el DBA está encargado del control general del sistema en el nivel técnico.

Funciones del DBA

Definir el esquema conceptual: Es tarea del administrador de datos decidir con
exactitud cuál es la información que debe mantenerse en la base de datos, es decir,
identificar las entidades que interesan a la empresa y a la información que debe
registrarse acerca de esas entidades. Este proceso, por lo regular, se denomina
diseño lógico – a veces conceptual – de bases de datos.

Definir el esquema interno: El DBA debe decidir también cómo se representará
la información en la base de datos almacenada. A este proceso suele llamárselo
diseño físico de la base de datos. Una vez echo esto, el DBA deberá crear la
definición de estructura de almacenamiento correspondiente (es decir, el esquema
interno) valiéndose de DDL interno. Además deberá definir la correspondencia
pertinente entre los esquemas interno y conceptual. En la práctica, ya sea el DDL
conceptual o bien el DDL interno incluirán seguramente los medios para definir
dicha correspondencia, pero las dos funciones (crear el esquema, definir la
correspondencia) deberán poder separarse con nitidez. Al igual que el esquema
conceptual, el esquema interno y la correspondencia asociada existirán tanto en la
versión fuente como en la versión objeto.

Vincularse con los objetos: El DBA debe encargarse de la comunicación con los
usuarios, garantizar la disponibilidad de los datos que requieren y escribir – o
ayudar a los usuarios a escribir – los esquemas externos necesarios, empleando el
56 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

DDL externo aplicable. Además será preciso definir la correspondencia entre

cualquier esquema externo y el esquema conceptual. En la práctica, el DDL
externo incluirá con toda probabilidad los medios para especificar dicha
correspondencia, pero en este caso también el esquema y la correspondencia deberá
poder separarse con claridad. Cada esquema externo y la correspondencia asociada
existirán en ambas versiones, fuente y objeto. Otros aspectos de la función de enlace
con los usuarios incluyen las consultas sobre diseño de aplicaciones, la impartición
de instrucción técnica, la ayuda de localización y resolución de problemas, y otros
servicios profesionales relacionados con el sistema.

Definir las verificaciones de seguridad e integridad: Las verificaciones de
seguridad y de integridad pueden considerarse parte del esquema conceptual. El
DDL conceptual incluirá (o debería incluir) los medios para especificar dichas
verificaciones.

Definir procedimientos de respaldo y recuperación: Cuando una empresa se
decide a utilizar un sistema de bases de datos, se vuelve dependiente en grado sumo
del funcionamiento correcto de ese sistema. En caso de que sufra daño cualquier
porción de la base de datos, resulta esencial poder reparar los datos implicados con
un mínimo de retraso y afectando lo menos posible al resto del sistema. En teoría,
por ejemplo, la disponibilidad de datos no dañados no debería verse afectada. El
DBA debe definir y poner en práctica un plan de recuperación adecuado que
incluya, por ejemplo, una descarga o “vaciado” periódico de la base de datos en un
medio de almacenamiento de respaldo, y procedimientos para cargar otra vez la base
de datos a partir del respaldo más reciente cuando sea necesario.

Supervisar el desempeño y responder a cambios en los requerimientos: Es
responsabilidad del DBA organizar el sistema de modo que se obtenga el
desempeño que sea “mejor para la empresa”, y realizar los ajustes apropiados
cuando cambien los requerimientos. Por ejemplo, podría ser necesario reorganizar
la base de datos (es decir, descargarla y volverla a cargar) en forma periódica con el
fin de garantizar que los niveles de desempeño sigan siendo aceptables ya, que
cualquier modificación del nivel de almacenamiento físico (interno) del sistema
debe ir acompañado por el cambio respectivo en la definición de correspondencia
con el nivel conceptual, pues sólo así podrá permanecer constante el esquema
conceptual.

El sistema de administración de bases de datos

(DBMS o SMBD)
El sistema de administración de base de datos (DBMS) es por supuesto el conjunto de
programas que maneja todo acceso a la base de datos. Conceptualmente, lo que sucede
es lo siguiente:

1. El usuario solicita acceso, empleando algún sublenguaje de datos determinado (por

ej. SQL).
2. El DBMS interpreta esa solicitud y la analiza.
3. El DBMS inspecciona, en orden, el esquema externo de ese usuario, la
correspondencia externa/conceptual asociada, el esquema conceptual, la

Institución Cervantes 57
INSTITUCIÓN CERVANTES

correspondencia conceptual/interna, la definición de la estructura de

almacenamiento.
4. El DBMS ejecuta las operaciones necesarias sobre la base de datos almacenada.

Funciones del DBMS

Definición de datos: El DBMS debe ser capaz de aceptar definiciones de datos
(esquemas externos, el esquema conceptual, el esquema interno, y todas las
correspondencias asociadas) en versión fuente y convertirlas en la versión objeto
apropiada. Dicho de otro modo el DBMS debe incluir componentes procesadores
de lenguajes para cada uno de los diversos lenguajes de definición de datos (DDL).

Manipulación de datos: el DBMS debe ser capaz de atender las solicitudes del
usuario para extraer, y quizá poner al día, datos que ya existen en la base de datos, o
para agregar en ella datos nuevos. Dicho de otro modo, el DBMS debe incluir un
componente procesador de lenguaje de manipulación de datos (DML).
En general las solicitudes en DML pueden ser “planeadas” o “no planeadas”:

Una solicitud planeada es aquella cuya necesidad se previó mucho tiempo antes
de que tuviera que ejecutarse por primera vez. El DBA habrá afinado con toda
probabilidad el diseño físico de la base de datos a fin de garantizar un buen
desempeño para estas solicitudes.

Una solicitud no planeada, en cambio, es una consulta ad hoc, es decir, una
solicitud cuya necesidad no se previó, sino que surgió de improviso. El diseño
de la base de datos puede ser o no ideal para la solicitud específica de que se
trate. En general, el logro del mejor desempeño posible con solicitud en no
planeadas representa un reto considerable para el DBMS.

Seguridad e integridad de datos: El DBMS debe supervisar las solicitudes de los
usuarios y rechazar los intentos de violar las medidas de seguridad e integridad
definidas para el DBA.

Recuperación y concurrencia de datos: El DBMS – o en su defecto algún
componente de software relacionado con él, al que por lo regular se lo denomina
administrador de transacciones – debe cuidar del cumplimiento de ciertos controles de
recuperación y concurrencia.

Diccionario de datos: El DBMS debe incluir una función de diccionario de datos.
Puede decirse que el diccionario de datos es una base de datos por derecho propio
(pero del sistema, no del usuario). El contenido del diccionario puede considerarse
como “datos acerca de los datos” (los cuales reciben en ocasiones el nombre de
“metadatos”), es decir, definiciones de otros objetos en el sistema.

Desempeño: Por último el DBMS deberá ejecutar todas las funciones recién
identificadas en la forma más reciente posible.

En resumen, constituye la interfaz entre el usuario y el sistema de base de datos. La

interfaz del usuario puede definirse como una frontera del sistema, mas allá de la cual
todo resulta invisible para el usuario. Por definición, entonces, la interfaz del usuario
está en el nivel externo.

58 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

El administrador de comunicación de
datos
La solicitud de un usuario final dirigida a la base de datos, se transmite en la práctica
en forma de mensajes de comunicación. De manera similar, las respuestas al usuario,
(desde del DBMS y la aplicación en línea, de vuelta a la terminal del usuario) también se
transmite como mensajes de este tipo. Todas estas transmisiones se efectúan bajo el
control de otros sistemas de programas, el administrador de comunicación de datos
(administrador DC).

El administrador DC no es un componente del DBMS, sino un sistema autónomo. No

obstante, como es evidente que el manejador DC y el DBMS deben trabajar juntos y en
forma armónica, se los considera como socios equitativos en una empresa corporativa de
mayor nivel denominada Sistema de Base de Datos/Comunicación de Datos (sistema
DB/DC), en la cual el DBMS se encarga de la base de datos y el administrador DC, de
todos los mensajes que llegan a la base de datos y salen de ella.

Procesamiento Distribuido
Procesamiento distribuido significa que varias máquinas pueden conectarse entre sí,
para formar una red de comunicación, de manera que una sola tarea de procesamiento
de datos puede abarcar varias máquinas de la red (a veces se utiliza el término
“Procesamiento en Paralelo” con un significado idéntico). La comunicación entre las
diversas máquinas corre a cargo de algún tipo de programas de administración de redes,
quizá una extensión del administrador DC.

La siguiente figura es un ejemplo de lo que se ha llegado a llamar un sistema

“Cliente/Servidor” (la sección frontal es el cliente y la posterior es el servidor). Existen
muchos argumentos a favor de un sistema Cliente/Servidor.

El primero no es en esencia el argumento a favor del procesamiento en paralelo, a

saber: cómo se aplican varios procesadores a la tarea general, el procesamiento de la
sección posterior (base de datos) y de la sección frontal (aplicación) se realizan en
paralelo. El tiempo de respuesta y el rendimiento deberán mejorar en consecuencia.

Por añadidura, la máquina despachadora (sección posterior) podría estar construida
a propósito para una función DBMS (“una máquina de base de datos”) y el DBMS
podría así tener un mejor desempeño.

De manera similar, la máquina cliente (sección frontal) podría ser una estación de
trabajo personal, adaptada a las necesidades del usuario final y, por lo tanto capaz de
proporcionar a éste mejores interfases, alta disponibilidad, respuestas más rápidas, y
en general facilidad de uso.

Varias máquinas clientes diferentes podrían ser capaces (de hecho, probablemente
serán capaces) de acceder a la misma máquina servidora. Así, una sola base de datos
podría compartirse entre varios sistemas de sección frontal diferentes (y quizá muy
diferentes).

Institución Cervantes 59
INSTITUCIÓN CERVANTES

Además de los argumentos anteriores, puede mencionarse también que el arreglo

cliente/servidor concuerda con la forma real de operar de muchas empresas: es frecuente
que una sola empresa (un banco, por ejemplo) maneje muchas máquinas, de modos que
los datos de una parte de la empresa se almacenan en una sola máquina y los de otra
parte se almacenen en otra máquina. También sucede a menudo que los usuarios de
una máquina requieren acceso por lo menos ocasional a los datos de almacenamiento de
otra.

Obsérvese, por tanto, que la máquina de sección frontal podría tener datos propios de
sección posterior, y la máquina de sección posterior podría tener también aplicaciones
propias de sección frontal. Así, en general, cada máquina funcionará como servidor para
algunos usuarios y como cliente para otros; dicho de otro modo, cada máquina incluirá
un sistema completo de base de datos (siguiente figura).

60 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Por último, dejamos sentado que una sola máquina cliente podría ser capaz de acceder
a varias máquinas servidoras diferentes (lo opuesto del caso ilustrado en la figura
anterior). Esta posibilidad es conveniente porque las empresas, en general, tienden a
operar de tal manera, que el conjunto total de sus datos no está almacenado en una sola
máquina, sino más bien disperso entre varias máquinas diferentes, y las aplicaciones
necesitarán a veces poder acceder a datos de más de una máquina. Existen dos formas
básicas de permitir este acceso:

1. Una cierta aplicación de sección frontal podría tener acceso a cualquier cantidad de
sistemas por sección posterior, pero sólo a uno a la vez (es decir, cada solicitud
individual a la base de datos deberá ir dirigida a sólo una de las secciones
posteriores). No es posible, dentro de una misma solicitud, combinar datos de dos
o más secciones posteriores diferentes. Además, el usuario de un sistema así deberá
saber cual sección posterior contiene cuáles elementos de información.
2. La aplicación de sección frontal podría tener acceso a cualquier cantidad de
sistemas de sección posterior en forma simultánea (es decir, una sola solicitud a la
base de datos podría ser capaz de combinar datos de varias secciones posteriores).
En este caso, la sección frontal percibe a las distintas secciones posteriores como si
fueran en realidad un solo sistema (desde un punto de vista lógico), y el usuario no
necesita saber cuáles secciones posteriores contienen cuáles elementos de
información.

El segundo caso es un ejemplo de lo que suele llamarse sistema de bases de datos

distribuidas. Llevando a una conclusión lógica, un apoyo completo para las bases de
datos distribuidas implica que una sola aplicación deberá ser capaz de trabajar en forma

Institución Cervantes 61
INSTITUCIÓN CERVANTES

“transparente” con datos dispersos en varias bases de datos diferentes, administradas por
varios DBMS distintos, ejecutadas en varias máquinas diferentes, apoyadas por diversos
sistemas operativos y conectadas entre sí mediante varias redes de comunicación
distintas. El término “transparente” significa aquí que la aplicación trabajaría, desde un
punto de vista lógico, como si un solo DBMS, ejecutado en una sola máquina,
administrara todos los datos.

Sistemas de Teleprocesamiento
El método clásico de soportar un sistema de base de datos multiusuario es el
teleprocesamiento, que utiliza una computadora y una CPU. Todo el procesamiento es
efectuado por esta única computadora.

En la figura se muestra un sistema de teleprocesamiento típico. Los usuarios operan

terminales no Inteligentes (bobas); microcomputadoras que transmiten a la
macrocomputadora mensajes de transacciones y de datos. La porción de control de las
comunicaciones del sistema operativo recibe los mensajes y los datos y los envía al
programa de aplicación (AP) apropiado. El programa llama al DBMS solicitando
servicios, y el DBMS utiliza la porción de administración de datos del sistema operativo y
procesa la base de datos. Terminada la transacción, los resultados son devueltos a los
usuarios en las terminales, vía la porción de controles de comunicaciones del sistema
operativo.
La figura muestra n usuarios sometiendo transacciones procesadas por tres distintos
programas de aplicación. Dado que existe poca inteligencia en el extremo usuario ya que
las terminales son no inteligentes, todos los comandos para formato de la pantalla, deben
ser generados por la CPU y transmitidos por las líneas de comunicación. En estos
sistemas, por lo general, la interfaz de usuario está orientada a caracteres y es primitiva.
Cabe recordar que Teleprocesamiento proviene de: tele = distancia, o sea que
teleprocesamiento significa procesamiento a distancia.

Un ejemplo típico de este tipo de procesamiento, es el de los cajeros automáticos. En

estas terminales la posibilidad de procesamiento es limitada.

62 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Los sistemas de teleprocesamiento han sido la alternativa más común para sistemas de
base de datos multiusuario. Conforme se ha ido reduciendo la afinidad precio-
rendimiento de las computadoras y con el advenimiento de las microcomptadoras, han
empezado a ser utilizadas otras alternativas que requieren varias computadoras.

Sistemas Cliente / Servidor

En la figura aparece un esquema que muestra un sistema Cliente/Servidor. A

diferencia del teleprocesamiento que utiliza una sola computadora, los sistemas
cliente/servidor involucran varias computadoras conectadas en una red. Algunas
computadoras procesan programas de aplicación y se conocen como clientes. Otra
computadora procesa la base de datos y es designada como servidor. Los clientes y el
servidor están conectados utilizando una red de área local (LAN).

En este sistema, cada uno de los usuarios tiene su propia computadora de

procesamiento de aplicaciones. Cada usuario procesa los programas que le hacen falta a
él.

Institución Cervantes 63
INSTITUCIÓN CERVANTES

En esta figura se resumen los roles del cliente y del servidor. La computadora cliente
administra la interfaz de usuario, acepta datos del usuario, procesa la lógica de la
aplicación y genera solicitudes de servicios de la base de datos. Los clientes transmiten
esas solicitudes al servidor y reciben resultados, a los cuales se les da formato para el
usuario.

El servidor acepta las solicitudes de los clientes, las procesa, y devuelve una respuesta.
El servidor también lleva a cabo la verificación de integridad de la base de datos,
mantiene los datos generales de la base de datos, y proporciona control de acceso
concurrente.

Un sistema cliente/servidor coloca el procesamiento de la aplicación más cerca del

usuario. Además permite utilizar entornos gráficos en los clientes dado que estas ya
tienen posibilidad de procesamiento propio.

64 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Autoevaluación
1. Describa cómo funcionan los distintos tipos de estructuras de datos (Lista
invertida, vinculada). Cuáles son las diferencias entre unas y otras.
........................................................................................
........................................................................................

2. Describa los distintos niveles en la arquitectura de una base de datos. En cuál de las
capas interactúa el DBA. En cuál de las capas se encuentra el usuario de aplicaciones.
........................................................................................
........................................................................................

3. Qué función cumple el File Manager y Disk Manager.

........................................................................................
........................................................................................

4. Cuál es el objetivo del agrupamiento.

........................................................................................
........................................................................................

5. Cuáles son las funciones del DBA.

........................................................................................
........................................................................................

6. Cuáles son las funciones del DBMS.

........................................................................................
........................................................................................

7. Qué rol cumple el Comunicador de datos.

........................................................................................
........................................................................................

8. Qué tipos de sistemas de bases de datos distribuidos conoce. Describa cada uno
de ellos.
........................................................................................
........................................................................................

9. Mencione algunas de las ventajas del modelo Cliente/Servidor.

........................................................................................
........................................................................................

Institución Cervantes 65
INSTITUCIÓN CERVANTES

66 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Unidad IV
El Modelo de datos Relacional

Objetivos

Reconocer los diferentes componentes del modelo relacional de datos.

Reconocer la importancia del modelo para la construcción de estructuras de datos.

Comprender los principios para selección de claves.

Interpretar el rol que cumple cada componente del modelo dentro del mismo.

Institución Cervantes 67
INSTITUCIÓN CERVANTES

El modelo Relacional
El modelo relacional fue propuesto en 1970 por Codd, y la popularidad de este modelo
ha ido creciendo lenta pero firmemente, de manera que el término relacional ha llegado
a ser común entre los profesionales informáticos. El modelo relacional de datos es un
modelo simple, potente y formal para representar la realidad. También ofrece una base
firme para enfocar y analizar formalmente muchos problemas relacionados con la gestión
de base de datos, como el diseño de la base de datos, la redundancia, la distribución, etc.
El formalismo y una base matemática son las piedras angulares en el desarrollo de la
teoría de las bases de datos. La sencillez del modelo ha facilitado la construcción de
lenguajes de consultas e interfases para usuarios finales de fácil utilización, y ha resultado
en una productividad más alta de los programadores de base de datos. La gestión de
bases de datos relacionales será una tecnología muy útil durante varios años.

Vamos a dividir el estudio del modelo relacional en tres partes, las cuales se ocupan de
la estructura, la integridad y la manipulación de los datos, respectivamente. Cada una de
las partes tiene sus términos especiales. Los términos en cuestión son relación, tupla,
cardinalidad, atributo, grado, dominio y claves, los cuales veremos en la primera etapa
cuando hablemos de la estructura relacional. En esta materia, tocaremos solamente lo
referido a la estructura y a la integridad, la manipulación, es tema de otra asignatura.

Estructura de datos Relacional

Los DBMS relacionales, son los sistemas de bases de datos más populares actualmente
en minis y microcomputadoras. Una lista de productos comerciales de DBMS
relacionales incluiría INGRES, ORACLE, SYBASE, INFORMIX, SQL Server,
PROGRESS, etc. Estos DBMS relacionales, están disponibles en una amplia gama de
equipos y, alguno de ellos, bajo varios sistemas operativos o plataformas. En este
apartado, trataremos todo lo referente a la estructura relacional propiamente dicha.
Partiremos con un gráfico que nos representa las partes componentes del modelo.

C
Legajo Nombre Provincia Ciudad A
125 Salazar Cordoba Cordoba
R
Relación D
126 Jaime Santa Fe Rosario
Tupla
150 Almada Cordoba Cordoba
I
    N
A
Atributos
L

Grado 
I
D

Una relación corresponde a lo que hasta ahora hemos llamado en general tabla. A
D

Una tupla, corresponde a una fila de esa tabla.

Un atributo, corresponde a una columna de esta misma tabla.

Las claves son identificadores, es decir una columna o combinación de columnas
que permitan hacer un determinado ordenamiento o acceso a los datos.

68 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Dominio es una colección de valores, de los cuales uno o más atributos (columnas)
obtienen sus valores.

Término relacional formal Equivalentes informales

Relación Tabla o archivo
Tupla Fila o registro
Cardinalidad Número de filas
Atributo Columna o campo
Grado Número de columnas
Dominio Valores permitidos

El elemento básico del modelo es la relación, y un esquema de base de datos

relacional es una colección de definiciones de relaciones. El esquema de cada relación
es una agregación de atributos (recordemos el concepto de agregación visto en la unidad
de abstracción); el conjunto de todos los valores que puede adoptar un atributo en
particular se denomina dominio de ese atributo. Este es el punto de partida para el
estudio de nuestro modelo ya que es la menor unidad de información, la cual suponemos
es el valor de un dato individual (como número de legajo individual o el peso de una
pieza, etc.). Estos valores escalares, son la menor unidad debido a que estos son valores
atómicos; no poseen estructura interna (es decir no se pueden descomponer en unidades
más pequeñas) desde el punto de vista del modelo. Podemos decir entonces, que
“Dominio es un conjunto de valores escalares, todos del mismo tipo”.

Por ejemplo: el dominio de números de legajo es el conjunto de todos los números de

legajo posibles, el dominio de cantidades de envío es el conjunto de todos los números
enteros mayores que cero y menores que 10000, el dominio del campo tipo de documento
serán todos los valores permitidos (DNI, LE, CI, PAS, LC). Todo atributo debe estar
definido sobre un dominio.

A partir de este concepto de dominio, podemos definir el término de Relación:

“Una relación sobre un conjunto de dominios D1, D2,...., Dn (no necesariamente todos
distintos), se compone de dos partes, una cabecera y un cuerpo”.

La cabecera está formada por un conjunto fijo de atributos.

El cuerpo está formado por un conjunto de tuplas o filas, el cual varía con el tiempo.

A partir de esto, podemos interpretar que la cabecera de una relación es estática en el

tiempo, mientras que el cuerpo varía según se modifique el contenido de la relación.

Un caso de relación (llamado también extensión de la relación) es una tabla con filas y
columnas. Las columnas de las relaciones corresponden a los atributos o campos; las
filas, o tuplas, son colecciones de valores tomados de cada atributo, y desempeñan la
misma función que los casos individuales de entidades en el modelo ER. El grado de
una relación es el número de columnas que cada relación tenga; la cardinalidad de una
relación es el número de tuplas o filas que en un determinado instante tiene la relación.

Institución Cervantes 69
INSTITUCIÓN CERVANTES

La cardinalidad, a partir de la definición de relación, varía con el tiempo, pero el grado

no.

Propiedades de las relaciones

1. No existen tuplas repetidas.
Esta propiedad es consecuencia del hecho de que el cuerpo de la relación es un
conjunto matemático (es decir, un conjunto de tuplas), y en matemáticas los
conjuntos por definición no incluyen elementos repetidos.
Consideremos a la relación como un conjunto de individuos y llamemos individuo
a cualquier elemento (personas, máquinas, autos, etc.) perteneciente a un conjunto
de estos. Cada individuo es único dentro del mundo real, por lo tanto, si
consideramos que lo que tenemos en una relación son tuplas (filas o registros), y
cada registro hace referencia a un único individuo, por lo tanto cada individuo no
puede estar repetido en una relación. Expresado de otra manera, en una relación
no pueden haber individuos repetidos.
2. Las tuplas no están ordenadas (de arriba hacia abajo).
Esta propiedad también se desprende de que el cuerpo de una relación es un
conjunto matemático. Los conjuntos matemáticos no son ordenados.

Legajo Nombre Telefono

125 Juan 4551825
100 Pedro 4612533
255 Jose 4331528
180 Luis 4516799
240 Carlos 4221525

En la tabla, por ejemplo, las tuplas (filas) de la relación podrían haberse

presentado en la secuencia inversa, sería de todos modos la misma relación. Por
tanto, no puede hablarse de la quinta tupla, la tupla 97 o la primera tupla de una
relación, y tampoco existe la siguiente tupla; no existe el direccionamiento por
posición. Si lo viéramos como un conjunto matemático:

A B C

A
C
B

Observen ambos conjuntos: Son iguales a pesar de que lo único que los
diferencia es la ubicación dentro del círculo.

3. Los atributos no están ordenados (de izquierda a derecha).

70 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Esta propiedad se desprende del hecho de que la cabecera de una relación se define
también como un conjunto (es decir, un conjunto de atributos). Por la misma
razón que la propiedad anterior, si consideramos a la cabecera como un conjunto,
el orden no tiene importancia ya que siempre sería el mismo conjunto pero en
distinto orden.
4. Todos los valores de los atributos son atómicos.
Una forma más precisa de expresar esta propiedad es: “todos los valores de los
atributos simples son atómicos”. Esta propiedad, es una consecuencia del hecho de
que todos los dominios son a su vez simples; es decir, sólo contienen valores
atómicos.

Tipos de relaciones
Existen diferentes tipos de relaciones en un sistema relacional:

1. Relaciones base: (relaciones reales) Son aquellas relaciones cuya importancia es tal
que el diseñador de la base de datos ha decidido darle un nombre y hacerlas parte
directa de la base de datos en sí, a diferencia con otras relaciones cuya naturaleza es
más efímera, como por ejemplo el resultado de una consulta. Por ejemplo la
relación ALUMNO en la base de datos de la universidad sería un caso de relación
base.
2. Vistas: (relaciones virtuales) una vista es una relación derivada, con nombre,
representada dentro del sistema exclusivamente mediante su definición en términos
de otras relaciones con nombre; no posee datos almacenados propios. Un ejemplo
sería la presentación en pantalla de datos obtenidos de varias relaciones. En este
caso tenemos dos relaciones base: Clientes y Localidades. Al usuario solo le
interesa el nombre y la Localidad. Lo que se hace es una vista obtenida de los datos
almacenados físicamente en CLIENTES Y LOCALIDAD. La vista no se
almacena físicamente, solo se ejecuta una secuencia de instrucciones y se crea en
memoria RAM.

Relación Clientes Relación Localidades

NCli Nombre CP Localidad CP
11 Luis 5000 Málaga 5000
44 Ana 4000 Gijón 4000
55 José 3500 Valencia 3500
Salamanca 4500

Nombre Localidad
Vista Luis Málaga
Ana Valencia

Institución Cervantes 71
INSTITUCIÓN CERVANTES

Integridad en el modelo relacional

Restricciones de integridad en los esquemas

relacionales
Comencemos con un poco de filosofía. Cualquier base de datos se compone de alguna
configuración de valores de los datos, y desde luego suponemos que esa configuración de
valores refleja la realidad (suponemos que el modelo es una representación de algún
fragmento del mundo real). Ahora, algunos valores no tienen sentido en ese mundo real,
no representan a ningún valor posible dentro de la realidad. Por ejemplo, es imposible
que si hablamos de peso de una pieza, el valor sea negativo. Debido a estos motivos, es
necesario establecer ciertas reglas de integridad, cuyo propósito es informar al DBMS de
ciertas restricciones en el mundo real (como el caso de que los pesos no pueden ser
negativos).
La mayor parte de las bases de datos estarán sujetas a gran número de tales reglas de
integridad. Por ejemplo: supongamos la relación

PIEZAS(Nro, Nombre, Tipo, Color, Peso)

Los número de piezas deben tener el formato numérico 9999 (donde 9999
representa cuatro dígitos numéricos).

Los tipos de piezas deben provenir de cierta lista tipos.

Los colores de las piezas deben provenir de cierta lista colores.

Los pesos de las piezas deben ser mayores que cero.

Como pueden observar, la mayor parte de las reglas de integridad son específicas, en
cuanto a que se aplican a una base de datos específica. O sea, las que acabamos de
enumerar hacen referencia a la base de datos donde se encuentra PIEZAS. Sin embargo,
el modelo relacional incluye dos reglas generales de integridad: generales en el sentido de
que se aplican no sólo a una base de datos, sino más bien a todas las bases de datos. Estas
dos reglas se refieren a las claves primarias y a las claves ajenas.

Claves Primarias
En el modelo relacional, el concepto de clave está definido de una manera muy similar
al concepto de identificador en el modelo ER; una clave de una relación es un atributo o
conjunto de atributos de la relación que identifica de manera única cada tupla de cada
extensión de esa relación. Así, la única diferencia entre nuestro uso de identificadores y
claves en el modelo relacional sólo se acepta la identificación interna.

En general, una relación puede tener más de una clave o identificador único, y cada
clave se denomina clave candidata. Podemos decir, que una relación puede tener
varias claves candidatas (a ser primarias). Nosotros escogeremos una de esas claves
candidatas como clave primaria o principal y a las demás las llamaremos entonces claves
alternativas o secundarias.

Podemos definir entonces el término clave candidata:

72 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

“El atributo K (posiblemente compuesto o no Tutor-10) de la relación R es una

clave candidata de R si y solo si satisface:

1. Unicidad: en cualquier momento dado, no existen dos tuplas en R con el mismo

valor de K.
2. Minimalidad: si K es compuesto, no será posible eliminar ningún componente de
K sin destruir la propiedad de unicidad.

Toda relación tiene por lo menos una clave candidata, ya que como hemos
mencionado, las relaciones no contienen tuplas repetidas. En el caso de las PIEZAS,
podemos tener piezas con el mismo nombre, tipo, color y peso, a lo mejor porque son
provista por distintos proveedores, pero nunca tendrán el mismo número. Por ejemplo:
en una agencia de autos, los modelos son siempre los mismos y los autos que haya en
stock tendrán los mismos modelos, pero el numero de chasis de cada uno, distinguirá
uno del otro.

Ahora bien, del conjunto de claves candidatas se elige una y solo una como clave
primaria de esa relación, las demás, como dijimos, si existen serán claves alternativas.
Así, una clave candidata que no es clave primaria se convierte en clave alternativa.

A partir de lo que hemos visto, podemos expresar:

1. Toda relación tiene por lo menos una clave candidata y por fuerza, toda relación
una clave primaria SIN EXCEPCION.
2. El razonamiento para elegir la clave primaria en los casos donde hay varias claves
candidatas, queda fuera del alcance del modelo relacional en sí.
3. La clave primaria es la que tiene verdadera importancia; las claves candidatas y
alternativas son sólo conceptos surgidos en el proceso de definición de clave
primaria.

Entonces, ¿por qué son tan importantes las claves primarias? La respuesta a esta
pregunta es que es un requisito para el manejo de claves ajenas, concepto que veremos
un poco más adelante. Además, como hemos dicho anteriormente, las tuplas son únicas
dentro de la relación y cada tupla hace referencia a un individuo, y este individuo
pertenece al mundo real, por lo tanto cada individuo (de una misma especie) debe tener
como mínimo un valor de atributo que lo diferencia del resto y que lo haga único. A este
concepto de clave primaria única se conoce como principio de unicidad de la clave
primaria.

Ahora bien, ya vimos el concepto de clave primaria y ahora veremos las restricciones de
integridad que pueden ser especificadas en un esquema relacional. Se espera que tales
restricciones, una vez especificadas, se cumplan para cada caso de base de datos de ese
esquema. Sin embargo, en los productos comerciales de DBMS actuales no siempre
pueden ser especificadas todas esas restricciones. Además, aún especificadas, no obliga
automáticamente el cumplimiento de todas ellas. Se consideran tres tipos de
restricciones como parte del modelo relacional: restricciones de clave, de integridad de
entidades y de integridad referencial. Las restricciones de clave especifican las claves
candidatas de cada esquema de relación; los valores de las claves candidatas deben ser
únicos para cada tupla en cualquier caso de ese esquema de relación.
Institución Cervantes 73
INSTITUCIÓN CERVANTES

Las restricciones de integridad de entidades establecen que “ningún valor de la clave

primaria puede ser nulo”. Esto es porque el valor de la clave primaria se usa para
identificar las tuplas individuales de una relación; permitir valores nulos para la clave
primaria implica que no se puedan identificar algunas tuplas. Por ejemplo: si en nuestra
relación la clave primaria fuera LEGAJO no podría existir ningún alumno con valor de
legajo nulo ya que si ese alumno no tuviera asignado un legajo no sería alumno del
colegio. Nulo, debemos interpretar como que por alguna razón el valor de la
información falta. De este concepto surge que “en una base de datos relacional, nunca
registraremos información acerca de algo que no podamos identificar”. Por ejemplo, si
dos o más tuplas tuvieran un valor nulo como clave primaria, no podríamos distinguirlas.

Debemos tener en cuenta además, que en el caso de que la clave primaria fuera
compuesta (estuviera formada por más de un atributo), cada valor individual de la
clave primaria debe ser no nulo en su totalidad.

La regla de integridad de entidades se aplica solo para claves primarias, las claves
alternativas podrían contener valores nulos.

Claves Ajenas
Supongamos las siguientes relaciones:

ALUMNOS(Matricula, Nombre, Direcion, Codigo Postal)

CIUDAD(Codigo Postal, Nombre Ciudad, Cantidad Habitantes)

Los atributos Codigo Postal, tienen que estar, definidos para el mismo dominio en
ambas relaciones.

En donde Matricula es la clave primaria de ALUMNOS y Codigo Postal lo es de

CIUDAD. Ambos atributos, no permiten valores nulos debido a la regla de integridad de
entidades. Además, si observamos el ejemplo, veremos que existe una relación entre
ALUMNOS y CIUDAD del tipo agregación binaria donde un alumno vive en una
ciudad. Este tipo de relación es la que me permite mantener cohesión en los datos de la
base de datos y me permite evitar redundancias. En el ejemplo se ha aplicado la tercera
forma normal, concepto que veremos en la próxima unidad. Para que entiendan en
definitiva el concepto de clave ajena o foránea, necesitamos de un ejemplo como este. Al
atributo Codigo Postal de la relación ALUMNOS, se lo conoce como clave ajena.
Definimos entonces como clave ajena o foránea “como un atributo (quizá compuesto) de
una relación, cuyos valores deben coincidir o concordar con los valores de la clave
primaria de alguno otra relación”.

Podemos decir, que lo inverso no se requiere: es decir, la clave primaria

correspondiente a una clave ajena dada podría contener un valor que no aparezca de
momento como clave ajena. En nuestro ejemplo, podría existir alguna ciudad donde no
viviera ningún alumno de la escuela.

74 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Un valor de clave ajena, representa una referencia a la tupla donde se encuentra el valor
correspondiente de la clave primaria. Por lo tanto, el problema de garantizar que la base
de datos no incluya valores no válidos de clave ajena se conoce como el problema de la
integridad referencial.

Las restricciones de clave y de entidad se especifican en relaciones individuales. La

restricción de integridad referencial, en cambio, se especifica entre dos relaciones, y
se usa para mantener la congruencia entre las tuplas de dos relaciones. Informalmente la
restricción de integridad referencial establece que una tupla de una relación, que haga
referencia a otra relación, debe referirse a una tupla existente en esa relación.

En una base de datos de muchas relaciones, habrá normalmente muchas restricciones

de integridad referencial que correspondan a las interrelaciones de las entidades
representadas por las relaciones.

Reglas para claves ajenas

Es importante darse cuenta de que la regla de integridad referencial tal como se
presentó, se formula solo en términos de estados de la base de datos. Cualquier estado de
la base de datos que no satisfaga la regla será incorrecto por definición; pero ¿cómo
pueden evitarse tales estado incorrectos? La regla en sí no lo dice con exactitud.

Una posibilidad es que el sistema rechazara cualquier operación que en caso de

ejecutarse, produciría un estado ilegal. Pero en muchos casos una alternativa preferible
sería que el sistema aceptara la operación pero realizara ciertas operaciones de
compensación para garantizar un estado legal como resultado final. Por ejemplo, si el
usuario solicita eliminar una ciudad, debería ser posible hacer que el sistema elimine
también los alumnos sin necesidad de acciones adicionales por parte del usuario. Esto se
debe a que si no elimino los alumnos, estos quedarían sin correspondencia en la relación
ciudades.

En consecuencia, para cualquier base de datos, el usuario (diseñador de la base de

datos), deberá poder especificar cuáles operaciones han de rechazarse y cuáles han de
aceptarse. La idea es la siguiente: para cada clave ajena es necesario responder:

1. Puede aceptar nulos una clave ajena? Es necesario conocer la ciudad en la que
alumno vive? La respuesta en este caso es SI, pero podría suceder que la
respuesta fuera diferente. La respuesta a la pregunta no depende del capricho del
diseñador de la base de datos, sino más bien de las políticas vigentes en la porción
del mundo real supuestamente representada por la base de datos.
2. Qué deberá suceder si hay un intento de eliminar el objetivo de una referencia de
clave ajena? Por ejemplo, un intento de eliminar una ciudad del cual provienen
varios alumnos. Para dar una respuesta, veamos que operaciones son permitidas:

RESTRINGIDA. La operación de eliminación está restringida al caso en el
cual no existen alumnos de esa ciudad, en caso contrario se rechaza.

SE PROPAGA. La operación de eliminación se propaga en cascada
eliminando también todos los alumnos.

Institución Cervantes 75
INSTITUCIÓN CERVANTES

ANULA. Se asignan valores nulos a la clave ajena en todos los alumnos

correspondientes a esa ciudad y enseguida se elimina la ciudad.

3. Qué sucederá si hay un intento de modificar la clave primaria del objetivo de

referencia de clave ajena? por ejemplo se intenta modificar el código postal de
una ciudad. Consideremos como en el caso anterior:

RESTRINGIDA. La operación de modificación está restringida al caso en el
cual no existen alumnos de esa ciudad, en caso contrario se rechaza.

SE PROPAGA. La operación de modificación se propaga en cascada
modificando también todos los alumnos.

ANULA. Se asignan valores nulos a la clave ajena en todos los alumnos
correspondientes a esa ciudad y enseguida se modifica la ciudad.

Diseño lógico en el modelo relacional

El objetivo del diseño lógico es convertir el esquema conceptual de datos en un
esquema lógico ajustado específicamente al sistema de gestión de base de datos (DBMS)
que se tenga a disposición. El objetivo de esta etapa es obtener una representación que
use de la manera más eficiente posible los recursos para estructurar datos y modelar
restricciones disponibles en el modelo lógico. En este apartado, presentaremos una
metodología para el diseño lógico que tiene como objetivo el modelo relacional.

Suponemos que el punto de partida es un esquema ER similar a los vistos hasta aquí.
Este, consiste en un conjunto de definiciones de relaciones, en el cual cada relación tiene
una clave primaria. Las relaciones producidas por la transformación de esquemas,
corresponden a entidades o bien a relaciones y mantienen la misma forma normal. El
concepto de forma normal será tratado en la próxima unidad con mayor profundidad.

La metodología propuesta, convierte un esquema ER en un conjunto de entidades e

interrelaciones, tales que su correspondencia con el modelo relacional sea sencilla. Para
esto, deberán aplicarse los siguientes pasos:

1) Transformación de cada entidad del esquema en una relación.

2) Transformación de cada interrelación: las interrelaciones de muchos a muchos
requieren una relación individual, mientras que las relaciones de uno a uno o de uno
a muchos pueden ser modeladas añadiendo atributos a las relaciones existentes.

Transformación de Entidades
Este paso es bastante simple: se transforma cada entidad del esquema en una relación.
Los atributos y la clave primaria de la entidad, se convierten en los atributos y la clave
primaria de la relación. Por ejemplo:
Legajo
EMPLEADO
Nombre
Telefono

EMPLEADO( Legajo, Nombre, Telefono)

76 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Transformaciones de Interrelaciones de Uno a

Uno
Ahora, debemos tratar las interrelaciones. Se empieza por considerar las interrelaciones
binarias de una manera general. Se verán las interrelaciones de uno a uno, de uno a
muchos y de muchos a muchos de manera individual. El proceso de transformación es
también influenciado por las cardinalidades mínimas de las dos entidades que participan
en la interrelación.
En principio las dos entidades E1 y E2 que participan en la interrelación, producen
relaciones individuales; de otro modo se habrían fusionado durante el diseño lógico
independiente del modelo. Respecto a la interrelación, hay que distinguir si las dos
relaciones E1 y E2 tienen una participación total en la interrelación, o si una o ambas
tienen una participación parcial en la misma. Así, tenemos los siguientes casos:

Integración de una relación. Esta opción tiene sentido cuando la participación de

las entidades en la interrelación es total. Hay dos posibilidades:

Caso 1: Las dos entidades tienen las mismas claves primarias. Supóngase que tanto
Clientes como Info-Envio tienen la misma clave primaria NUM_CLIENTE. En este
caso, las dos relaciones correspondientes se integran en una relación combinando todos
los atributos e incluyendo la clave primaria sólo una vez.
(1, (1,
Cliente Con Info-Envio

Num_Cliente Nombre_Cliente Num_Cliente Direcci

on_

Envio_Cliente (Num_Cliente, Nombre_Cliente, Direccion_Envio)

Caso 2: Las dos entidades tienen claves primarias diferentes: Supóngase que Cliente e
Info_Envio tienen diferentes claves primarias, digamos Num_Cliente, y (Codigo_Postal,
Calle, Num_Casa), respectivamente. En este caso también se integran en una relación
combinando todos los atributos e incluyendo las claves primarias de ambas. Una de las
dos claves primarias será la clave primaria de la relación resultante; por ejemplo, en la
relación que sigue se escoge Num_Cliente.

Envio_Cliente (Num_Cliente, Nombre_Cliente, Num_Casa, Calle, Codigo_Postal).

Definición de una relación aparte. Esta opción se usa cuando una o las dos
entidades tienen una participación parcial. A continuación se muestra un caso de cada
una:

Caso 1: Una entidad con participación parcial. Esto se refiere, por ejemplo, a los
clientes de un banco, a los cuales el banco emite cero o una tarjetas de crédito. En la
figura anterior cada tarjeta de crédito debe pertenecer a un cliente, pero un cliente puede
no tener tarjeta de crédito. En este caso, las dos relaciones, Cliente y Tarjeta de crédito,
ya han sido creadas. Se define una relación adicional Posee_Tarjeta (Num_Cliente,
Tipo_Tarjeta, Num_Tarjeta) usando la clave primaria de las dos relaciones. Tanto
Institución Cervantes 77
INSTITUCIÓN CERVANTES

Num_Cliente como (Tipo_Tarjeta, Num_Tarjeta) son claves candidatas de

Posee_Tarjeta, y por consiguiente pueden ser declaradas como clave primaria. Obsérvese
que se puede usar la primera opción en este caso y representar todo en una sola relación
(0, (1,
Cliente Posee Tarjeta_Cred Lim
ite_

Num_Cliente Nombre_Cliente Tipo_Tarjeta Num_Tarjeta

integrada. En ese caso se debe escoger Num_Cliente como clave primaria de la relación
integrada; aquellos clientes que no posean tarjeta de crédito tendrán valores nulos de los
atributos Tipo_Tarjeta, Num_Tarjeta. No se puede seleccionar (Tipo_Tarjeta, y
Num_Tarjeta) como clave primaria de la relación integrada, porque en ese caso los
clientes sin tarjeta de crédito no podrían ser representados.

Cliente(Num_Cliente, Nombre_Cliente)
Tarjeta_Credito(Tipo_Tarjeta, Num_Tarjeta, Limite_Credito)
Posee_Tarjeta (Tipo_Tarjeta, Num_Tarjeta, Num_Cliente)

Caso 2: Las dos entidades con participación parcial. Considérese la interrelación

Matrimonio entre las entidades Varón y Mujer. En este caso ambas tienen una
participación parcial en la interrelación Matrimonio. Para evitar valores nulos y
representar tanto las entidades como la interrelación, se crea la relación Matrimonio
(Nss_Varon, Nss_Mujer, Fecha, Duración) además de las relaciones Varon y Mujer.
Fecha Duración

(0,1) (0,1)
Varon MatrimonioPosee Mujer

Nss_Mu Nombr
Varon (Nss_Varon, Nombre)
Mujer (Nss_Mujer, Nombre)
Matrimonio (Nss_Varon, Nss_Mujer, Fecha, Duracion)

Transformación de Interrelaciones uno a muchos

Considérese la interrelación R entre dos entidades, E1 y E2; supongamos que R es una
interrelación uno a muchos. En este caso, se dará cuenta de la interrelación incluyendo
la clave primaria de E1 en la relación correspondiente a E2 como uno o más atributos
simples. Obsérvese que ya se ha dado cuenta de los identificadores externos. Por
consiguiente, esta transferencia de la clave no tiene propósitos de identificación. Los
posibles atributos de la interrelación tienen que ser trasladados a la relación que modela
la entidad E2. Otra vez son posible dos casos:

78 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Caso 1: La entidad en el lado de ”muchos” tiene una participación obligatoria. En este

ejemplo, el lado de muchos sería: un estado muchas ciudades; o sea que el lado de
muchos es ciudades, ya que son muchas las ciudades que participan en la relación. En la
figura siguiente se ejemplifica, donde hay una interrelación de uno a muchos entre
Estado y Ciudad, Ciudad tiene una participación total en la interrelación; por tanto, la
clave primaria Nombre_Estado de Estado se incluye en la relación Ciudad.
Ciudad Nombres
Habitantes

(1,
Pertenece_a Participación Total

(1,
Nombre
Estado Gobernador
Habitantes

Ciudad (Nombre_Ciudad, Nombre_Estado, Habitantes)

Estado (Nombre_Estado, Gobernador, Habitantes)

Caso 2: La entidad en el lado de “muchos” tiene una participación parcial. En la

figura siguiente hay una interrelación entre Vendedor y Pedido.
Supóngase que los pedidos pueden hacerse por medio de los vendedores, en cuyo caso
se aplica una tasa de descuento, y también directamente sin vendedores, sin aplicar la
tasa de descuento. Así pues, existe la posibilidad de valores nulos de Nombre_ Vendedor
y Tasa_Descuento en la relación Pedido si se usan las siguientes correspondencias:

Vendedor (Nombre, Num_telefono)

Pedido (Num_Pedido, Nombre_Vendedor, Tasa_Descuento)

Si el número de esos pedidos es grande, y no puede admitir valores nulos, una mejor
alternativa sería establecer tres relaciones (lo cual es el caso más general):

Vendedor Nombre
Num_Telefono

(1,n
Tasa_Descuento Participación Parcial
Nombre

(0,1
Num_Pedido
Pedido
Fecha

Vendedor (Nombre, Num_telefono)

Pedido (Num_Pedido, Fecha)
Pedido_Ventas (Num_Pedido, Nombre_Vendedor, Tasa_Descuento)

Institución Cervantes 79
INSTITUCIÓN CERVANTES

Obsérvese que las dos relaciones, Pedido y Pedidos_Ventas contiene un sub conjunto
de todos los pedidos, aquellos hechos a través de vendedores. Así se tiene la restricción
adicional de que el conjunto de números de pedidos en Pedido_Ventas está siempre
incluído en el conjunto de números de pedidos de la relación Pedido. Esta interrelación
se denomina dependencia de inclusión de Num_Pedido en Pedido_Ventas respecto a
Num_Pedido en Pedido en el momento relacional.

Transformación de Interrelaciones de muchos a

muchos
En el caso de interrelaciones de muchos a muchos, la solución no depende de la
cardinalidad mínima de la interrelación. Supongamos que R es una interrelación de
muchos a muchos entre E1 y E2. Se crea una relación nueva que tiene como clave
primaria la combinación de atributos que constituyen las claves primarias, tanto de E1
como de E2, y que incluye como atributos los atributos de R. En el ejemplo de la figura,
una relación de muchos a muchos Matriculado_En entre Estudiante y Curso se modela
como una nueva relación Matriculado_En, que tiene como clave primaria el par
(Numero Estudiante, Numero_Curso), con Semestre y Nota como atributos. Obsérvese
que Numero_Estudiante y Numero_Curso son claves ajenas y tienen restricciones
referenciales respecto a las claves primarias correspondientes.
Numero_Estudiante
Estudiante Apellido
Indice_Promedio
(1,n)

Semestre
Matric_En
Nota

(1,n)
Numero_Curso
Curso
Nombre_Curso

Estudiante (Numero_Estudiante, Apellido, Indice_Promedio)

Curso (Numero_Curso, Nombre_Curso)
Matriculado_En (Numero_Estudiante, Numero_Curso, Semestre, Nota)

80 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Autoevaluación
1. Mencione los distintos componentes de la estructura del modelo relacional de datos.
........................................................................................
........................................................................................
........................................................................................
........................................................................................

2. ¿Cuál es la relación entre los términos formales y los términos relacionales?

........................................................................................
........................................................................................
........................................................................................
........................................................................................

3. ¿Qué tipos de claves maneja el modelo relacional? Defina y ejemplifique cada una.
........................................................................................
........................................................................................
........................................................................................
........................................................................................

4. ¿Qué reglas de integridad conoce? Defina y ejemplifique.

........................................................................................
........................................................................................
........................................................................................
........................................................................................

5. ¿Cuáles son los propiedades de las relaciones? Explique.

........................................................................................
........................................................................................
........................................................................................
........................................................................................

6. ¿Cómo transformaría de un diagrama ER una relación de uno a uno? Ejemplifique.

........................................................................................
........................................................................................
........................................................................................
........................................................................................

Institución Cervantes 81
INSTITUCIÓN CERVANTES

7. ¿Cómo transformaría de un diagrama ER una relación de uno a muchos?

Ejemplifique.
........................................................................................
........................................................................................
........................................................................................
........................................................................................

8. ¿Cómo transformaría de un diagrama ER una relación de muchos a muchos?

Ejemplifique.
........................................................................................
........................................................................................
........................................................................................
........................................................................................

9. ¿Cuál es el objetivo del diseño lógico?

........................................................................................
........................................................................................
........................................................................................
........................................................................................

10. En caso de definir una clave ajena, ¿qué consideraciones debemos tener en cuenta al
definirla? ¿por qué?
........................................................................................
........................................................................................
........................................................................................
........................................................................................

82 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Unidad V
Descomposición y Normalización

Objetivos

Adquirir una sólida base teórica y práctica en la teoría de la normalización.

Reconocer los distintos tipos de dependencias funcionales.

Obtener la capacidad de resolver problemas de anomalías de diseño en la estructuras
de datos.

Comprender el proceso de normalización de datos.

Institución Cervantes 83
INSTITUCIÓN CERVANTES

Normalización: Introducción
Los sistemas de bases de datos son propensos a volverse problemáticos a la hora de
diseñarlos. Las relaciones lógicas tienden a multiplicarse a medida que se agregan
nuevas aplicaciones y que los usuarios exigen que el sistema este capacitado para
responder a nuevas formas de interrogación utilizando los datos que almacena. El grado
de complejidad de muchas bases de datos parece crecer sin limites previsibles, a menos
que los diseñadores tengan un concepto muy claro de lo que está ocurriendo, esos
sistemas se transformaran en una maraña de datos e interrelaciones.

Es posible evitar el enmarañamiento a que dan lugar las estructuras ramificadas y plexo
recurriendo a una técnica que se llama normalización. Las técnicas de normalización
han sido ideas y recomendadas por E.F. Codd.

“Se entiende por normalización la descomposición o subdivisión de una relación en

dos o más relaciones para evitar la redundancia” (dividir una tabla en una o más tablas);
en definitiva, que “cada hecho este en su lugar”. (C.J.Date)

El proceso de normalización generalmente se utiliza en el enfoque relacional; sin

embargo, un modelo relacional se puede modificar para su implantación en un DBMS
jerárquico o de red.
Una de las maneras más naturales de representar datos para el usuario es el que se basa
en tablas bidimensionales (modelo relacional Unidad IV). El usuario esta familiarizado
con tal estilo de representación y lo comprende, visualiza y recuerda con facilidad ya que
lo hemos estudiado con anterioridad.
Las tablas o relaciones en cuestión, son matrices rectangulares que pueden ser descritas
matemáticamente. Las relaciones o tablas poseen algunas propiedades que creo sería
conveniente resaltar:

1. Cada entrada de la tabla represente un ítem de datos; no hay grupos repetitivos

(recordar que los valores de una entrado fila/columna son atómicos).
2. Son homogéneas por columnas, es decir los ítems de una columna son de la misma
clase. Si la columna almacena fechas, todos los ingresos validos serán fechas.
3. Cada columna tiene nombre propio, el cual no se repite dentro de la misma tabla.
4. Todas las filas son diferentes, no se admiten filas duplicadas.
5. Tanto las filas como las columnas pueden ser consideradas en cualquier secuencia y
en cualquier momento, sin afectar por ello ni el contenido de la información ni la
semántica de cualquier función que utilice la tabla.

La base de datos construida por medio de relaciones, es una base de datos relacional
(como vimos en la unidad anterior).

84 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Requerimientos del usuario

- Relación NO Normalizada

Eliminar grupos repetidos

1° Forma Normal
(1FN)

Eliminar Dependencias Parciales

2° Forma Normal
(2FN)
Eliminar Dependencias Transitivas

3° Forma Normal
(3FN)

Este proceso se conoce como Normalización debido a que todos los pasos deben
cumplir ciertas normas establecidas para lograr un buen diseño. Estos pasos deben
cumplirse uno a continuación de otro sin saltear ninguno, y los principios que cada uno
de ellos dictamina, deben cumplirse por cada etapa para poder pasar a la siguiente. Esto
quiere decir por ejemplo, si debo bajar del colectivo, primero debo saber cual es la parada
en la que lo haré. A continuación, tocaré el timbre y esperare a que el colectivo se
detenga. Una vez que todo esto paso, me bajo. Nunca podría bajarme si el colectivo se
encuentra aun en marcha, por ejemplo.
Utilizando el esquema, resumiremos el proceso genérico de normalización:
El proceso comienza con los requerimientos del usuario, los cuales nos llegan como
una maraña de información en una relación no normalizada. Toda la información
mezclada. Nuestra tarea, será la de encontrar la forma más óptima de almacenar los
datos; esto quiere decir: sin redundancias innecesarias.

La primera etapa es la de eliminación de grupos repetidos. Una vez eliminados los

grupos repetidos, las relaciones (tablas) se encuentran en primera forma normal (1FN).
Cuando todas las relaciones se encuentran en 1FN, se procede a la eliminación de las
dependencias parciales. Cuando ya se eliminaron estas, las relaciones se encuentran en
2FN. Cuando ya no existen más dependencias parciales, se eliminan las dependencias
transitivas y aquí ya se encuentran las relaciones en 3FN.

Esta tarea, debe realizarse cada vez que nos enfrentemos con una base de datos nueva.
Los pasos deben seguirse siempre y no puede faltar ninguno de ellos. Piensen en el
concepto de Normas (leyes); estas están dictadas para ser cumplidas siempre. Si no se
cumplen algo pasa, por ejemplo si la ley dice que no hay que robar y robaste, el castigo
será ir preso. Si las anomalías no se corrigen, o sea que por ejemplo queda alguna
dependencia transitiva sin corregir, el castigo será que la estructura de datos que estemos

Institución Cervantes 85
INSTITUCIÓN CERVANTES

creando provoque redundancia en los datos almacenados, entonces deberemos atenernos

a las consecuencias.
Empecemos por entender el concepto de dependencia funcional:

Dependencia Funcional
Las dependencias funcionales son una restricción al conjunto de relaciones legales.
Nos permiten expresar hechos acerca de lo que estamos modelando con la base de datos.

Existe una dependencia funcional (DF) entre dos atributos monovalentes, A1 y A2, de
una entidad E o de una interrelación R, si cada valor de A1 corresponde exactamente a
un valor de A2.

Estudiaremos esta propiedad con un ejemplo: Sean A1, A2 dos atributos de una
entidad E; supóngase que existe un caso de entidad E1 de E que tiene los valores a1 y a2
para A2:

<e1:...a1...a2...>

La dependencia funcional entre A1 y A2 implica que si existe otro caso de entidad, e2,
en el que A1 adopta el valor a1, entonces A2 debe adoptar el valor a2:

<e1:... a1... a2...>

En este punto podemos decir que en un esquema correcto, todos los identificadores
internos de las entidades, determinan funcionalmente a los otros atributos monovalentes.
El ejemplo de la figura muestra la entidad persona con dos identificadores internos,
Num-seg-soc y el par (Nombre, Fecha-de-Nacimiento). Otros atributos son Dirección,
Ciudad, Provincia y Codigo-Postal. Por tanto, tenemos las siguientes DF:

NUM-SEG-SOC
NOMBRE, FECHA-DE-NACIMIENTO, DIRECCIÓN, CIUDAD, PROVINCIA,

CODIGO-POSTAL

NOMBRE, FECHA-DE-NACIMIENTO

Nombre DIRECCION, CIUDAD, NUM-SEG-SOC, PROVINCIA,
Fecha-de- CODIGO-POSTAL
Nacimiento
Num-Seg-Soc
Persona
Dirección Decimos que A1 determina funcionalmente
Ciudad a A2, lo cual se denota también como A1
A2; el
Provincia atributo a la izquierda de la DF se llama el
Codigo-Postal determinante. Las DF se establecen de forma
similar entre conjuntos de atributos; por
ejemplo, A1, A2
A3 (el par de atributos [A1, A2] es, en este caso, el determinante) o
A1
A2,A3. Cuando el lado derecho de una DF es un conjunto S de n atributos, la DF
original es equivalente a n dependencias funcionales individuales, cada una con un
atributo sencillo de S como lado derecho. Por ejemplo la dependencia A1
A2,A3 es
equivalente a las dos DF A1
A2 y A1
A3 por separado. Las DF se establecen,
asimismo, entre atributos de interrelaciones, exactamente con la misma interpretación.

86 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Estas dependencias dicen que si se asigna el valor de los atributos determinantes, se

encontrará, en la base de datos, un valor de los atributos determinados. Esto es una
consecuencia trivial del hecho de que los identificadores son también determinantes.
Asimismo, se tiene una DF adicional, CODIGO-POSTAL
CIUDAD, PROVINCIA que
expresa la propiedad de que las personas con el mismo CODIGO-POSTAL viven en la
misma CIUDAD y PROVINCIA.
Num-de-Ped
Nombre-de-Pieza
Costo
Pedido
Cantidad
Fecha

Las dependencias funcionales nos permiten expresar restricciones que no pueden

expresarse por medio de superclaves. Considérese el esquema siguiente:
Num-de-Ped
Nombre-de-Pieza
Costo
Pedido
Cantidad
Fecha

Esquema (préstamo) = nombre-sucursal, numero-préstamo, nombre-cliente, cantidad.

Ejemplo: si un préstamo se hace a más de un cliente en este caso a marido/mujer,
entonces no esperaríamos que el atributo numero-préstamo fuera una superclave.

Anomalías de Actualización
Si bien las dependencias funcionales que corresponden a identificadores no causan
problemas, otras dependencias que pueden existir en una entidad pueden causar las
llamadas anomalías de actualización. El ejemplo de la figura, que describe pedido en
términos de números de pedidos, piezas pedidas, fecha de pedido, costo de cada pieza, y
cantidad pedida de cada pieza.

El identificador de la entidad está dado por el par (Num-Ped, Nombre-de-Pieza); de

aquí, se deduce la siguiente dependencia:

Num-Ped, Nombre-de-Pieza
Costo, Cantidad, Fecha

La entidad Pedido
01 1518 Bolígrafo 1.0 12 03/08/99
02 1518 Lapicero 0.5 15 03/08/99
03 1521 Lapicero 0.5 18 02/09/99
04 1407 Bolígrafo 1.0 15 02/06/99
05 1407 Borrador 0.2 28 02/06/99
06 1407 Pizarra 5.0 3 02/06/99
07 1407 Borrador 0.2 1 03/01/99
08 1729 Disquete 2.0 10 03/01/00
09 1729 Lapicero 0.5 15 03/01/00
Institución Cervantes 87
INSTITUCIÓN CERVANTES

Casos de la entidad pedido

Sin embargo, el costo de una pieza está determinado de manera única, por su número
de pieza; esto se afirma mediante la siguiente dependencia funcional:

Nombre-de-Pieza
Costo

Esta es la causa de la redundancia mostrada en los casos de la entidad; por ejemplo, el

costo de los lápices se repite tres veces. Más aún se reconocen las siguientes anomalías:

1. Anomalía de Inserción: No se puede indicar el costo de una pieza, a menos que

tenga algunos pedidos pendientes.
2. Anomalía de Eliminación: Cuando se borra el último pedido pendiente para una
pieza, también se borra la información para su costo.
3. Anomalía de Actualización: Si cambia el costo de algunas piezas, todos los
pedidos referentes a esas piezas cambian también; la operación de actualización se
propaga a varios casos de la entidad.

Todas estas anomalías se relacionan con la presencia de una dependencia funcional

indeseable, a saber, Nombre-de-pieza
Costo. Una anomalía semejante se debe a la
dependencia Num-Ped
Fecha. El proceso de normalización es una progresiva
detección y eliminación de esas dependencias no deseadas.

Normalización de Bases de Datos

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

El sistema de base de datos no sufra de anomalías de almacenamiento.

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, aún 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.

88 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

La normalización o descomposició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
Como vimos al comienzo de esta unidad, los pasos de la normalización son:

1. Descomponer todos los grupos de datos en registros bidimensionales. (Eliminar

grupos repetidos)
2. Eliminar todas las relaciones en la que los datos no dependan completamente de la
llave primaria del registro. (Eliminar dependencias parciales)
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.

Formas Normales
Es el conjunto de normas que nos ayudan a diseñar una estructura de Bases de Datos
óptima para su implementación, gestión y explotación desde distintas aplicaciones,
consiguiendo independencia de ellas (de las aplicaciones Tutor-12). El creador de estas
normas fue E.F.Codd, quién formulo las 3 primeras formas normales (1FN, 2FN y 3FN)
a las que siguieron otras (FNBC, 4FN y 5FN).

La razón de ser de las formas normales consiste en la estandarización de los conceptos

relacionados al diseño eficiente de las estructuras y esquemas de una base de datos.

Institución Cervantes 89
INSTITUCIÓN CERVANTES

Durante mucho tiempo se ha dependido en extremo de la experiencia y capacidad de

los analistas y diseñadores de bases de datos. Como es obvio, existirán discrepancias
entre los métodos que estos aplican para obtener un modelo eficiente. Las formas
normales permitirán la aplicación de un estándar de eficiencia en niveles ascendentes
mediante la aplicación de las mencionadas formas normales.
Se dice que una relación (tabla) está en una Forma Normal determinada si satisface
cierto conjunto especifico de restricciones.

Universo de Relaciones

Para avanzar de una Forma Normal a otra, deben verificarse las restricciones de la
actual y la nueva Forma Normal. Una de las herramientas más utilizadas para
alcanzar una nueva forma normal es la DESCOMPOSICIÓN. Esto proceso consiste
en tomar la relación NO normalizada entregada por el usuario y descomponerla
(desarmarla) en relaciones más pequeñas, las cuales, al ser más pequeñas, son más
estables y más fáciles de manejar. Esta debe presentar las siguientes características:

Debe realizarse sin perdida de datos

Deben mantenerse las dependencias funcionales

Se debe evitar o reducir hasta donde sea posible la redundancia.

Primera forma normal

Definición formal:

“Una relación R esta en primera forma normal (1FN) y si y solo si todos los dominios
subyacentes solo contienen valores atómicos”.

Un dominio es atómico si los elementos del dominio se consideran unidades invisibles

(a cada valor de campo solo se le asigna un único valor). Por ejemplo: El campo Edad
para el alumno Juan, será 25 y solo 25; puede ir variando con el tiempo, pero ese campo
siempre tendrá un solo valor asignado cada vez.

90 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Una relación R se encuentra en 1FN, si y solo si, cada intersección fila/columna

contiene valores atómicos.

Abreviada como 1FN, se considera que una relación se encuentra en la primera forma
normal cuando cumple lo siguiente:

Las celdas de las tablas poseen valores simples y no se permiten grupos ni arreglos
repetidos como valores, es decir, contienen un solo valor por cada celda.

Todos los ingresos en cualquier columna(atributo) deben ser del mismo tipo.

Cada columna debe tener un nombre único, el orden de las columnas en la tabla no
es importante.

Dos filas o renglones de una misma tabla no deben ser idénticas, aunque el orden de
las filas no es importante.

Por lo general la mayoría de las relaciones cumplen con estas características, así que
podemos decir que la mayoría de las relaciones se encuentran en la 1FN.

Para ejemplificar cómo se representan gráficamente las relaciones en primera forma

normal, consideremos la relación alumno cursa materia, cuyo diagrama E-R es el
siguiente:

Como esta relación maneja valores atómicos, es decir un solo valor por cada uno de los
campos que conforman a los atributos de las entidades, ya se encuentra en primera forma
normal, gráficamente así representamos a las relaciones en 1FN.

Segunda forma normal

Para definir formalmente la segunda forma normal (2FN), requerimos recordar el
concepto de dependencia funcional: Consiste en identificar qué atributos dependen de
otro(s) atributo(s).

Atributos Dependientes

Atributo que
determinante

Definición formal:

“Una relación R está en 2FN, si y solo si, está en 1FN y los atributos no primos
dependen funcionalmente o completamente de la clave primaria”. Tutor-8

Institución Cervantes 91
INSTITUCIÓN CERVANTES

Una relación se encuentra en 2FN, cuando cumple con las reglas de la 1FN y todos sus
atributos que no son claves llaves) dependen por completo de la clave.

De acuerdo con esta definición, cada tabla o relación que tiene una clave primaria
formada por un solo atributo, ya está en 2FN.

La 2FN es transgredida cuando un campo no clave es un dato sobre un subconjunto de

una clave primaria (compuesta) o depende parcialmente de una parte de la clave
primaria. t93

D Ejemplo

Consideremos el siguiente esquema propuesto para un registro de inventario.

ARTÍCULO BODEGA CANTIDAD DIRECCIÓN-BODEGA

Aquí, la clave está formada por (ARTÍCULO, BODEGA), o sea es una clave
compuesta.

Se puede observar fácilmente que DIRECCIÓN-BODEGA es un dato acerca de

BODEGA y no de ARTICULO, por lo que no se estaría cumpliendo con la 2FN.

Los problemas básicos de diseño son:

La dirección de la bodega se repite para cada artículo que se almacena en esa bodega
(redundancia).

Si la dirección de bodega cambia, cada registro que se refiera a un artículo
almacenado en esa bodega debe ser actualizado. Debido a la redundancia, los datos
pueden llegar a ser inconsistentes, con diferentes registros indicando diferentes
direcciones para la misma bodega (integridad).

Si en algún momento no hubiera partes almacenadas en alguna bodega, no habría
un registro para anotar la dirección de la bodega (anomalía).

Para satisfacer la segunda forma normal, el esquema anterior debe ser reemplazado por
el siguiente:

ARTÍCULO BODEGA CANTIDAD

BODEGA DIRECCIÓN

A partir del ejemplo, podemos decir, que si una relación o tabla tiene una clave
primaria simple (o sea formada por un solo atributo o campo) la relación ya se encuentra
en 2FN.

La segunda forma normal se representa por dependencias funcionales como:

92 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Nombre Nom_M
Control Clave
Esp. Creditos

Nótese que las llaves primarias están representadas con doble cuadro, las flechas nos
indican que de estos atributos se puede referenciar a los otros atributos que dependen
funcionalmente de la llave primaria.

Tercera Forma Normal

Para definir formalmente la 3FN necesitamos definir dependencia transitiva: En una
afinidad (tabla bidimensional) que tiene por lo menos 3 atributos (A, B, C), en donde A
determina a B, B determina a C, pero no determina a A.

Definición formal:

“Una relación R está en 3FN, si y solo si, está en 2FN y todos sus atributos no primos
dependen no transitivamente de la clave primaria”.

Consiste en eliminar la dependencias transitivas que queda en una 2FN, en pocas

palabras, una relación está en tercera forma normal si está en segunda forma normal y no
existen dependencias transitivas entre los atributos.
Nos referimos a dependencias transitivas cuando existe más de una forma de llegar a
referencias a un atributo de una relación.
Por ejemplo, consideremos el siguiente caso:

Tenemos la relación alumno-cursa-materia utilizada anteriormente, pero ahora

consideramos al elemento maestro, gráficamente lo podemos representar de la siguiente
manera:

Institución Cervantes 93
INSTITUCIÓN CERVANTES

Podemos darnos cuenta de que se encuentra graficado en 2FN, es decir que todos los
atributos llave están indicados en doble cuadro indicando los atributos que dependen de
dichas llaves, sin embargo en la llave Necono tiene como dependientes a 3 atributos, en el
cual el nombre puede Nombre Nom M
ser referenciado por dos
atributos: Necono y Control Clave
RFC (Existe
dependencia Esp. Creditos
transitiva), podemos
solucionar esto
aplicando la tercera
forma normal que Nombre

consiste en eliminar
Necono
estas dependencias
separando los atributos,
Plaza
entonces tenemos:

Necono Plaza

Otro ejemplo:
Nombr Nom M
e

Cont Clav
rol e

Esp. Credito
s

Nombr
e

Neco RFC
no

Plaza

NCLI NOMBRE LOCALIDAD CP

11 Luis Málaga 5000
44 Ana Gijón 4000
55 José Valencia 3500

Relación CLIENTES Relación LOCALIDADES

NCLI NOMBRE CP LOCALIDAD CP

11 Luis 5000 Málaga 5000
44 Ana 4000 Gijón 4000
55 José 3500 Valencia 3500
Salamanca 4500

94 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Forma Normal de Boyce Codd

Incluso las relaciones en 3FN, pueden tener anomalías. Considera la tabla ASESOR
de la figura. Suponga que los requerimientos de esta relación son que un estudiante
(LEG) pueda tener una o más especialidades, una especialidad pueda tener varios
miembros de la facultad (NomFac) como consejeros, y un miembro de la facultad
(NomFac) sólo imparte asesoría en un área de especialidad.

Puesto que los estudiantes pueden tener varias especialidades, LEG no determina
funcionalmente Especialidad (recuerden el concepto de dependencia funcional). Como
los estudiantes pueden tener varios asesores, LEG tampoco determina NomFac. LEG
por si mismo no puede ser una clave.

La combinación (LEG, Especialidad) determina NomFac y la combinación (LEG,

NomFac) determina Especialidad. Cualquiera de las combinaciones puede ser una
clave. De lo que vimos en la unidad anterior, deducimos que ambas combinaciones son
claves candidatas, esto es, que cualquiera de las dos puede ser clave primaria.

Además de las claves candidatas, hay otra dependencia funcional: NomFac determina a
Especialidad (cualquier miembro de la facultad asesora en sólo una especialidad, por lo
tanto si conozco NomFac se puede determinar Especialidad).

ASESOR está en 1FN. También está en 2FN pues cualquier atributo que no es clave
depende de toda la clave, sin importar cual clave candidata se seleccione. También está
en 3FN porque no tiene dependencias transitivas. A pesar de esto, existen anomalías de
actualización.

Suponga que el estudiante 300 deja la facultad. Si se quita la fila de estudiante 300 se
perderá el hecho de que Romero imparte asesoría de Matemáticas. Esta es una anomalía
de eliminación. En forma similar, cómo se almacena el hecho de que Toledo asesora en
Programación? No es posible hasta que un estudiante se inscribe en esa materia. Esta es
una anomalía de inserción.

ASESOR(LEG, Especialidad, NomFac)

Clave Primaria: (LEG, Especialidad)
Clave Candidata: (LEG, NomFac)
Dependencias Funcionales: NomFac Especialidad

LEG Especialidad NomFac

100 Matemáticas Rios
200 Programación Yudi
300 Matemáticas Rios
250 Programación Costa
300 Matemáticas Romero

Institución Cervantes 95
INSTITUCIÓN CERVANTES

NomFac Especialidad LEG NomFac

Rios Matemáticas 100 Rios
Yudi Programación 200 Yudi
Costa Programación 300 Rios
Romero Matemáticas 250 Costa
300 Riomer
Situaciones como esta, conducen a la definición de la
Forma Normal de Boyce-Codd (BNCF):

“Una relación R esta en FNBC (Forma Normal de Boyce Codd), si y solo si, cada
determinante es una clave candidata”.

La solución a esta anomalía es descomponer la relación ASESOR en dos relaciones

nuevas que no tengan anomalías. Por ejemplo, las relaciones ESTU-ASE(LEG,
NomFac), clave: LEG,NomFac; y ASE-MATERIA(NomFac, Especialidad), clave:
NomFac, Especialidad.

DEPENDENCIAS DE VALORES MULTIPLES (DVM).

El concepto de dependencia funcional nos ha llevado a descomponer las relaciones en

la 3FN y la forma de BOYCE-CODD, con lo que concluye el proceso de normalización.

A veces estas formas son insuficientes para eliminar la redundancia y las anomalías de
actualización si una relación contiene dependencias de valores múltiples, lo cual
conlleva una normalización adicional: la cuarta forma normal (4FN).

En la dependencia de valores múltiples (DVM), un valor atributo, A, determina un

conjunto de valores múltiples, B. Se expresa con doble flecha:

A B

Consideramos la relación ESTUDIANTE (NUM, CURSO, DEPORTE) que indica

su número, el curso donde está matriculado y los deportes que practica, como se muestra
en la siguiente figura:

NUM CURSO DEPORTE

10 Base de datos Baloncesto
10 Base de datos Natación
20 Base de datos Tenis
20 Física Baloncesto
Física Esgrima

Relación en la tercera forma con redundancia.

Los atributos CURSO y DEPORTE son dependientes multivalores de NUM, es decir,

cualquier valor de NUM determina una serie de valores de los atributos CURSO y
DEPORTE. Se puede expresar:

96 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

NUM CURSO o NUM

NUM DEPORTE
CURSO
DEPORTE
Existe una dependencia de valores múltiples cuando una relación tiene por lo menos
tres atributos, dos de los cuales poseen valores múltiples y sus valores dependen solo del
tercer atributo, en otras palabras, en la relación 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 C, y B y C son independientes entre sí.

Cuarta Forma Normal

Definición formal:

“Una relación se encuentra en 4FN si está en BCFN y no tiene dependencias de

valores múltiples (DMV)”.

Para entender mejor esto, consideremos una afinidad (tabla) llamada estudiante que
contiene los siguientes atributos: Clave, Especialidad, Curso tal y como se demuestra en
la siguiente figura:

Clave Especialidad Curso

S01 Sistemas Natación
S01 Bioquímica Danza
S01 Sistemas Natación
B01 Bioquímica Guitarra
C03 Civil Natación

Suponemos que los estudiantes pueden inscribirse en varias especialidades y en

diversos cursos. El estudiante con clave S01 tiene su especialidad en Sistemas y
Bioquímica y toma los cursos de natación y danza, el estudiante B01 tiene la especialidad
en Bioquímica y toma el curso de guitarra, el estudiante con clave C03 tiene la
especialidad de Civil y toma el curso de natación.

En esta tabla o relación no existe dependencia funcional, porque los estudiantes

pueden tener distintas especialidades, un valor único de clave puede poseer muchos
valores de especialidades al igual que de valores de cursos. Por lo tanto, existe
dependencia de valores múltiples. Este tipo de dependencias produce redundancia de
datos, como se puede apreciar en la tabla anterior, en donde la clave S01 tiene tres
registros para mantener la serie de datos, en forma independiente, lo cual ocasiona que al
realizarse una actualización se requiera de demasiadas operaciones para tal fin.

En la tabla anterior, Clave determina valores múltiples de especialidad y Clave

determina valores múltiples de curso, pero especialidad y curso son independientes entre
sí.

Las dependencias de valores múltiples se definen de la siguiente manera:

Institución Cervantes 97
INSTITUCIÓN CERVANTES

Clave
Especialidad y Clave
Curso; Esto se lee “Clave multidetermina a

Especialidad, y clave multidetermina a Curso”

Para eliminar la redundancia de los datos, se deben eliminar las dependencias de

valores múltiples. Esto se logra construyendo dos tablas, donde cada una almacena datos
para solamente uno de los atributos de valores múltiples.

Para nuestro ejemplo, las tablas correspondientes son:

Tabla Especialidad
Clave Especialidad
S01 Sistemas
B01 Bioquímica
C03 Civil
Tabla Curso
Clave Curso
S01 Natación
S01 Danza
B01 Guitarra
C03 Natación

Nota
8 Si una relación esta en 4FN, esta también en FNBC, la relación no es reciproca

Desnormalización
Debemos tener en cuenta, que la Normalización no es la panacea. Hay casos en que se
hace necesario realizar todo lo contrario. Un ejemplo de la desnormalización, la
encontramos en los sistemas DataWareHousing o Almacenes de Datos que se están
utilizando cada vez en mayor medida. Estos grandes almacenes de datos, se utilizan para
brindar a los usuarios (sobre todo a los niveles gerenciales) información para la toma de
decisiones. Los sistemas basados en tecnologías 4GL (lenguajes de cuarta generación)
como PROGRESS, INFORMIX u ORACLE, son grandes motores de bases de datos los
cuales cuentan entre sus herramientas con la posibilidad de crear este tipo de
almacenamiento. Otro tema interesante es la minería de datos, que sería productivo que
buscaran más información en Internet. La minería de datos es la herramienta que
permite localizar los datos buscados o solicitados por los usuarios a partir de un
requerimiento dentro del almacén de datos. Estos temas son muy interesantes y es la
tecnología que ya está aterrizando en los sistemas de información y de bases de datos.
Para que comprendan un poco el concepto de Almacén de Datos, les cuento más o
menos que son: es juntar toda la información en una gran bolsa; tomar todas las bases de
datos de la empresa y juntarlas en una sola. El hecho de juntar todas las bases de datos
genera un montón de redundancia, que como vimos, es perjudicial para los sistemas de
bases de datos relacionales. En estos motores de búsqueda, cuanto mayor redundancia,
mejor van a ser los resultados de las búsquedas. Las búsquedas en esta montaña de
información, se realizan utilizando herramientas propias de estos 4GL; a este proceso se

98 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

lo conoce como Minería de Datos (escarbar en la montaña para lograr encontrar la pepita
de oro).

Las relaciones normalizadas, evitan anomalías de modificación y se prefieren a las

relaciones no normalizadas. Valorada bajo otros criterios, algunas veces la normalización
no vale la pena. Consideremos esta relación:

CLIENTE(NroCli, NomCli, Ciudad, Provincia, CodPos)

Donde NroCli es la clave.

Esta relación no está normalizada porque contiene la dependencia funcional

CodPos (Ciudad, Provincia)

la cual no está implícita en la clave NroCli. Por lo tanto, existe una restricción que no
está implícita por la definición de clave.

Esta relación puede transformarse en:

CLIENTE(NroCli, NomCli, CodPos) donde la clave es NroCli

CODIGOS(CopPos, Ciudad, Provincia) donde la clave es CodPos

Estas dos relaciones están en la forma normal correcta, pero es muy probable que no
representen el mejor diseño. Tal vez sea mejor la tabla no normalizada, será más fácil de
procesar y no son muy importantes las desventajas de duplicar los datos de Ciudad y
Estado.

En resumen, algunas veces las relaciones se dejan a propósito no normalizadas o están

normalizadas y después desnormalizadas. Esto se hace para mejorar el funcionamiento.
Siempre que los datos deben combinarse de dos tablas separadas, el DBMS debe efectuar
un trabajo adicional. En la mayoría de los casos, se requieren cuando menos dos
lecturas, en vez de una.

Institución Cervantes 99
INSTITUCIÓN CERVANTES

Autoevaluación
1. Defina dependencia Funcional.

2. Defina Dependencia Parcial.

3. Defina Dependencia Transitiva.

4. Defina Dependencias de valores múltiples.

5. Qué es una anomalía de inserción.

6. Qué es una anomalía de eliminación.

7. Que es una anomalía de actualización.

8. Defina la 1FN. Proporcione un ejemplo de una relación en 1FN y no en 2FN.

9. Defina la 2FN. Proporcione un ejemplo de una relación en 2FN y no en 3FN.

10. Defina la 3FN. Proporcione un ejemplo de una relación en 3FN y no en BCFN.

11. Defina el término NORMALIZACION.

100 INSTITUCIÓN CERVANTES

 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Tutores
Dato
t1
Los datos corresponden al registro discreto (no continuo) de hechos acerca de
un fenómeno, con lo cual ganamos información (incremento del conocimiento
que puede ser inferido de los datos) acerca del mundo que nos rodea.

Restricciones Estáticas
t2
Reglas que restringen el conjunto de valores que la base de datos (estructura)
puede tomar. Por ejemplo, si el campo es numérico, sólo admitirá números.
Hacen referencia al DDL del modelo.

Restricciones Dinámicas
t3
Reglas que restringen las transiciones entre valores válidos de la base de datos
(estructura). Hacen referencia al DML del modelo.

Manipulación de los datos

t4
Definición de los procedimientos por los cuales la base de datos (estructura)
cambia de un valor (estado) a otro. Alta de un registro, baja de un registro,
modificación de datos, etc.

Por n se entiende “infinito” o “ilimitado”. El número estará en realidad limitado

t5
al número de ocurrencias de la clase EDIFICIO en la base de datos.

Semántica
t6
Los lenguajes son herramientas creadas por el hombre (u otros seres) con el fin
de comunicarse. Son imprescindibles para poder concebir modelos, pues uno
expresa a lo más lo que el lenguaje le permite. Además, los lenguajes son los que
permiten comunicar los modelos a otros (que comprenden dichos lenguajes),
validarlos, discutirlos y ampliar la percepción del otro sobre un mismo
fenómeno.
Para efectos de este curso, consideraremos los siguientes componentes de los
lenguajes.
1. La sintaxis. Es el conjunto de símbolos permitidos en el lenguaje. (por
ejemplo las letras del abecedario o todas las palabras del idioma español)
2. Una gramática. Son las reglas generadoras del lenguaje. (por ejemplo la
gramática del español)
3. La semántica. Es el significado asociado al lenguaje (por ejemplo, el
significado de las palabras y su interpretación dentro de un contexto dado.
Por ejemplo "el kilo de pan cuesta $ 460 se registra el valor (460) y su
significado o semántica (valor del kilo de pan en pesos).

Secuencial
t7
Acceso secuencial significa recorrer el archivo desde el principio y uno por uno
los registros sin saltear ninguno hasta llegar al registro deseado. En forma de
secuencia, uno a continuación de otro.

Institución Cervantes 101

INSTITUCIÓN CERVANTES

t8
Un atributo es no primo si no participa en la clave primaria.

“Dependencia parcial: dependencia funcional con una determinante que es

t9
PARTE de la clave (tabla con clave primaria compuesta: todos los atributos que
no forman parte de una clave primaria NO dependen de la totalidad de la clave
primaria)”

Claves Compuestas
t10
Las claves pueden ser simples o compuestas. Son simples cuando la clave está
formada por un solo atributo. Son compuestas cuando la clave está formada por
más de una atributo. Por ejemplo:
NOTAS(LEG, CODMAT, NOTA) la clave será compuesta LEG,CODMAT,
ambas y son indivisibles.
ALUMNOS(LEG, NOM, TE) la clave es simple ya que está formada por LEG
solamente.

Metadatos
t11
Son datos acerca de los datos presentes en la base de datos. Describen el
nombre que se les da, el tipo y la longitud asignada a cada dato elemental.

Independencia
t12
Recuerden el principio de independencia de los datos respecto de las
aplicaciones visto en la unidad I.

102 INSTITUCIÓN CERVANTES

 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Indice
Fundamentación ..................................................................... 1
Objetivos Generales ............................................................... 1
Mapa Conceptual ................................................................... 2
Programa ............................................................................... 3
Bibliografía y materiales de consulta ...................................... 4
Orientaciones Metodológicas .................................................. 4
Evaluación .............................................................................................................. 4
Evaluación Diagnóstico ........................................................... 6
U NIDAD I
Introducción al Diseño de Bases de Datos ............................... 7
Objetivos ............................................................................................................... 7
Introducción .......................................................................................................... 8
Introducción al Diseño de Bases de datos............................................................. 8
Ciclo de vida de un sistema de información........................................................ 10
Ventajas de las bases de datos frente a los ficheros clásicos ............................... 11
Independencia de los datos...................................................................................................12
Fases del Diseño de Bases de Datos ................................................................... 12
Concepto de Dato y Modelo de Dato .................................... 15
El significado de dato ........................................................................................... 15
Modelamiento de Datos...................................................................................... 16
Modelo de Datos: Introducción .......................................................................... 17
Autoevaluación .................................................................................................... 19
U NIDAD II
Modelado de Datos .............................................................. 21
Objetivos ............................................................................................................. 21
Procesos de Abstracción en el modelamiento de Datos .................................... 22
Propiedades de las correspondencias entre las clases ........................................ 24
Jerarquías de Generalización ...............................................................................................26
Modelos de Datos ............................................................................................... 27
El modelo de entidades-interrelacionadas (ER) .................................................. 28
Elementos básicos del modelo Entidad Relación ...............................................................28
Los Mecanismos de abstracción en el modelo ER (Entidad-Relación) ............................31
Cualidades del modelo ER................................................................................... 31
Cómo Modelar en MER....................................................................................... 35
Autoevaluación .................................................................................................... 36
U NIDAD III
Arquitectura de las bases de datos ....................................... 37
Objetivos ............................................................................................................. 37
Estructuras de Bases de Datos ............................................................................ 38
Archivos Planos.................................................................................................... 38
Procesamiento de Archivos Planos ..................................................................... 39
Lista Secuencial.....................................................................................................................39

Institución Cervantes 103

INSTITUCIÓN CERVANTES

Mantener un orden con listas vinculadas............................................................................ 40

Mantener un orden con índices ........................................................................................... 43
Bases de Datos Jerárquicas.................................................................................. 44
Propiedades de los esquemas jerárquicos........................................................... 45
El Modelo de Redes ............................................................................................. 46
Los tres niveles de la arquitectura de una base de datos .................................... 48
El nivel externo ..................................................................................................................... 48
El nivel conceptual................................................................................................................ 49
El nivel interno...................................................................................................................... 49
Nivel Interno: Acceso a la Base de Datos............................................................................ 50
Manejador de disco (Disk Manager).................................................................... 51
Manejador de archivos (File Manager)................................................................. 51
Agrupamiento o Clustering.................................................................................................. 51
Indexación ............................................................................................................................. 52
Indexación densa y no densa................................................................................................ 53
Arboles B (B-Trees)............................................................................................. 54
El Administrador de Bases de Datos (DBA) ........................................................ 56
Funciones del DBA .............................................................................................................. 56
El sistema de administración de bases de datos (DBMS o SMBD).................................. 57
Funciones del DBMS ........................................................................................................... 58
El administrador de comunicación de datos........................................................ 59
Procesamiento Distribuido................................................................................................... 59
Sistemas de Teleprocesamiento ........................................................................................... 62
Sistemas Cliente / Servidor .................................................................................................. 63
Autoevaluación .................................................................................................... 65
U NIDAD IV
El Modelo de datos Relacional ............................................... 67
Objetivos.............................................................................................................. 67
El modelo Relacional............................................................................................ 68
Estructura de datos Relacional............................................................................. 68
Propiedades de las relaciones.............................................................................. 70
Tipos de relaciones.............................................................................................. 71
Integridad en el modelo relacional ...................................................................... 72
Restricciones de integridad en los esquemas relacionales.................................................. 72
Claves Primarias................................................................................................... 72
Claves Ajenas ....................................................................................................... 74
Reglas para claves ajenas ...................................................................................................... 75
Diseño lógico en el modelo relacional................................................................. 76
Transformación de Entidades.............................................................................................. 76
Transformaciones de Interrelaciones de Uno a Uno ......................................................... 77
Transformación de Interrelaciones uno a muchos............................................................. 78
Transformación de Interrelaciones de muchos a muchos ................................................. 80
Autoevaluación .................................................................................................... 81
U NIDAD V
Descomposición y Normalización .......................................... 83
Objetivos.............................................................................................................. 83
Normalización: Introducción ............................................................................... 84
Dependencia Funcional........................................................................................ 86
Anomalías de Actualización ................................................................................. 87

104 INSTITUCIÓN CERVANTES

 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I

Normalización de Bases de Datos....................................................................... 88

Peligros en el diseño de bases de datos relacionales............................................................88
Pasos de la normalización.....................................................................................................89
Formas Normales................................................................................................ 89
Universo de Relaciones ......................................................................................................... 90
Primera forma normal........................................................................................................... 90
Segunda forma normal .........................................................................................................91
Tercera Forma Normal.........................................................................................................93
Forma Normal de Boyce Codd ............................................................................................95
Cuarta Forma Normal..........................................................................................................97
Desnormalización .................................................................................................................98
Autoevaluación .................................................................................................. 100
Tutores ............................................................................... 101

Material elaborado por Prof. Néstor Berasategui

2003 – AML 
27/05/2009 19:05:00 

Institución Cervantes 105

 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I – Actividades

Guía de Actividades

Actividad I – Unidad 1
1. Elabore un resumen de lo que entiende por Base de Datos.
2. Realice un análisis de los sistemas de almacenamiento tradicionales frente a las
bases de datos indicando las ventajas y desventajas de ambos.
3. Enumere las principales funciones realizadas por el DBMS.
4. La gerencia de la empresa Alas del Sur S.A., ha detectado falencias en la
información que está manejando la empresa. Ante esta situación, se lo ha
contratado para realizar la tarea de construcción y diseño de la base de datos
necesaria para resolver los problemas planteados. Para lograr este objetivo, usted
deberá crear un bosquejo de las etapas que deberá emprender para lograr tal fin y
presentarle el mismo al gerente para hacerle comprender los pasos que usted deberá
seguir para poder construir la base de datos.
5. Realice un cuadro comparativo entre las distintas etapas del diseño de una base de
datos.

Actividad II – Unidad 2
1. Cite al menos cinco ejemplos de cada uno de los mecanismos de abstracción.
2. Elija un tipo de objeto cualquiera (alumno, computadora, auto) y muestre cómo se
puede representar usando cada uno de los mecanismos de abstracción.
3. Reconocer entidades y relaciones, considerando cardinalidades.
a) Una factura se envía a un cliente y puede haber muchas facturas enviadas a un
mismo cliente.
b) Una persona trabaja en un departamento y hay muchas personas trabajando en
un departamento.
c) Un vehículo es posdo por una persona y una persona puede o no poseer
muchos vehículos.
d) Los estudiante cursan asignaturas. Cada asignatura puede ser cursada por
muchos estudiantes.
e) Un operador puede trabajar en muchas máquinas y cada máquina tiene
muchos operadores. Cada máquina pertenece a un departamento, pero un
departamento puede tener muchas máquinas.

4. La universidad de Salamanca, ha considerado la posibilidad de crear una base de

datos para la programación de aulas para los exámenes finales de cada una de las
carreras. A usted se le plantean dos soluciones posibles:
a) La base de datos podría ser modelada como un conjunto de entidades único:
examen, con atributos nombre-curso, numero-seccion, numero-aula y hora.

Institución Cervantes 1
INSTITUCIÓN CERVANTES

b) Alternativamente podrían definirse uno o más conjuntos de entidades

adicionales, junto con los conjuntos de relaciones para sustituir algunos de los
atributos del conjunto de entidades examen, como:
i) Curso con atributos nombre, departamento y numero-c.
ii) Sección con atributos numero-s, y matrícula, y depende de curso como un
conjunto de entidades débiles.
iii) Aula con atributos numero-a, capacidad y edificio.

Para estas dos alternativas de diseño:

c) Qué instrumentos utilizaría para crear la base de datos?
d) Justifique su elección de un modelo respecto al otro. Explicar que
características de la aplicación influirían en la decisión de incluir o no uno o
más de los conjuntos de entidades adicionales.

Actividad III
Diseñar el diagrama ER para las siguientes situaciones, completándolos, si considera
necesario, con las hipótesis adicionales que se crean razonables.

1. Queremos diseñar una base de datos para almacenar información sobre nuestros
Clientes y sus Pedidos. Los artículos comercializados por nuestra organización
tienen un código que los identifica unívocamente y una descripción. Algunos son
fabricados en factorías propias y otros han de adquirirlos en proveedores externos.
Cada cliente dispone de un crédito con un límite, un descuento por compras
masivas y un saldo, cuyo importe va variando conforme va pagando los pedidos
entregados. Los pedidos se entregan en una dirección de entre varias disponibles
para cada cliente. Son las direcciones de entrega del cliente. Además, un pedido
puede servirse en varias entregas, por lo que habrá que llevar un control de lo que
queda pendiente de entregar en cada momento. Los pedidos se componen en dos
partes: una cabecera de pedido y varias líneas de detalle. Se desea llevar, también,
un control de las necesidades de fabricación. Para ello, por cada fábrica propia se
guarda la cantidad disponible de cada artículo en el almacén de la fábrica y el nivel
mínimo de existencias a partir del cual hay riesgo de quedarse sin existencias.
2. El centro de estudiantes de la carrera de Ingeniería de Sistemas junto con la
jefatura de carrera, desean realizar una encuesta (de carácter anónima) de intereses
a los alumnos de la carrera para la planificación de actividades de la futura semana
de la Facultad. Para ello se han definido los siguientes datos básicos necesarios de
cada alumno: Año de ingreso a la carrera, edad, sexo (determinado por el
encuestador), comuna en que vive, ciudad, si vive con los padres, estado civil,
deporte(s) que practica, hobbies, temas de interés. Se le pide al curso de Diseño de
Bases de Datos I que determine los archivos a utilizar para el almacenamiento de
estos datos que no transgredan las formas normales. ¿Qué tipo de requerimiento
de información puede resolver esta encuesta?.
3. Una agencia de colocaciones dedicada a la búsqueda de directivos para empresas
desea diseñar una base de datos que incorpore datos de las personas de las que tiene
información, así como de los trabajos que oferta. De cada persona se desea poder
relacionarla con la ciudad en la que vive y con todas las ciudades en las que estar a
2 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I – Actividades

dispuesta a vivir, dándoles un orden de preferencia. Además, cada persona debe

estar relacionada con aquellas experiencias (tanto académicas como profesionales)
que posee, indicando los años durante los cuales las ha adquirido. Deben incluirse,
también, las empresas (tanto las que ofertan trabajo, como aquellas a las que
pertenecen o han pertenecido las personas de las que se tiene información) y deberá
relacionarse cada persona con su empresa actual y con todas aquellas en las que ha
trabajado, indicando, en este caso, la fecha de entrada, salida, motivo de la salida y
último puesto ocupado. Cada trabajo ofertado requiere de una o varias
experiencias y es para una sola empresa y en una única ciudad. Por último, al
comenzar el proceso de selección para un trabajo, se establece una relación entre el
trabajo y las personas que optan por él, de forma que en cada selección aparecen
varias personas y una persona puede estar implicada en varias selecciones a la vez.
4. El hotel BD tiene 400 habitaciones. Los tipos de habitaciones que tiene son
individuales, dobles y suites; algunas habitaciones tienen teléfono, televisión y/o
aire acondicionado. El hotel, a menudo, reserva habitaciones con un año de
anticipación. El precio de la habitación depende del tipo de huésped y se considera
que hay tres categorías de huésped: normal, comercial y gobierno. Cuando un
cliente hace una reserva para una fecha determinada, el conserje le pide los
siguientes datos: fecha de inicio de la estancia, nombre y dirección, tipo de la
habitación deseada, duración de la estancia, tarifa a la que se puede acoger. Si se
confirma la reserva, se abre una factura donde se anotan todos los servicios que el
huésped utiliza durante su estancia y que tendrá que abonar junto con su
habitación. Cada servicio tiene una única tarifa y queda claramente consignado en
la factura. El hotel quiere instalar un sistema que maneje las reservas de las
habitaciones y que contemple las siguientes facilidades:

Control del inventario de las habitaciones. El hotel debe conocer en cada
momento qué habitaciones están reservadas y cuáles están disponibles.

Mantenimiento y control de facturas. Se debe poder controlar todos los gastos
originados por el cliente y facturárselos debidamente.

Control de los clientes habituales. El hotel desea mejorar el trato dado a ese tipo
de clientes.

5. Se desea crear una base de datos para almacenar los menús de un hospital.

Cada menú tiene un único nombre y fue creado en una fecha determinada por
un dietista. Cada menú puede estar formado por cualquier número de platos,
cada uno de ellos con un único nombre. El orden de consumo del plato varía
para cada menú.

Se debe mantener una descripción del plato para cada plato almacenado. Cada
plato está hecho con cualquier cantidad de cualquier número de alimentos (por
ejemplo, el plato PLATO1 está hecho con 10 gr. de ternera, 20 gr. de papas y 5
gr. de tomates).

Cada alimento está perfectamente identificado y descrito en la base de datos.

Para poder obtener el valor nutricional de cada menú, los valores nutrientes se
asocian con cada alimento como sigue:

Cada nutriente se identifica con una clave, almacenándose la descripción del
nutriente y la unidad de medida.

Institución Cervantes 3
INSTITUCIÓN CERVANTES

Se conoce el contenido de nutriente en una cantidad estándar de alimento, para

cada nutriente en cada alimento (por ejemplo, 100 UI de Vitamina A en un litro
de leche).

A cada paciente del hospital se le asigna un menú cada día de su estancia en el
mismo. Sólo se asigna un menú a cada paciente por día, pero un paciente puede
tomar diferentes menús en diferentes días. Cada paciente está identificado y se
guarda cierta información sobre él.

6. Modificar el esquema obtenido en el apartado anterior para:

a) permitir que los platos puedan servirse directamente al paciente, llevando
cuenta del número de veces que un paciente toma un determinado plato y el
día en que lo hace.
b) permitir que los alimentos puedan servirse directamente al paciente, llevando
cuenta del número de cantidades estándar que toma del alimento y el día en
que lo hace.

Actividad IV – Unidad 3
1. Realice un cuadro comparativo entre los distintos tipos de estructura de archivos
planos.
2. Realice un cuadro comparativo entre los distintos tipos de bases de datos.
3. Realice un cuadro comparativo entre los distintos sistemas distribuidos de bases de
datos que conozca.
4. Cree un esquema que me permita seguir un índice utilizando el método de árbol B.
Describa cada una de las etapas.
5. Realice un esquema comparativo de cada uno de los niveles de la arquitectura de
una base de datos.

Actividad V – Unidad 4
Realizar un diagrama ER indicando cuáles son las claves y su tipo, las características de
cada una de las relaciones (uno a uno, uno a muchos, muchos a muchos) y, en caso de
existir integridad referencial, describir y justificar cada una de ellas para las siguientes
situaciones:

1. El gerente de personal de la empresa en la cual nos desempeñamos como ABD

(DBA), nos indica que la base de datos de personal de la compañía debe contener
información sobre las divisiones, departamentos y empleados de la misma. Cada
empleado trabaja en un departamento; cada departamento forma parte de una
división. Debemos proponer algunos datos de muestra que esbocen algunas
posibles estructuras de almacenamiento para ellos. En donde sea posible, debemos
explicarle, las ventajas relativas de cada una de esas estructuras, es decir, analizar la
forma como se manejarían, en cada caso, opciones representativas de recuperación
y actualización de datos.

4 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I – Actividades

2. Al realizar el relevamiento de la empresa ALA2, se ha obtenido la siguiente

descripción del problema: La compañía trata con pasajeros que son registrados en
diferentes vuelos en una clase y en un asiento determinado. De los pasajeros interesa el
nombre, la dirección y el numero de teléfono. De los vuelos es necesario almacenar el
numero de vuelo, la fecha, el origen, el destino, la hora de salida y la hora de llegada.
La compañía dispone de un conjunto de empleados de los cuales almacena información
referente al numero de emplead, el nombre, dirección y el salario que recibe cada uno.
Una parte de estos empleados son pilotos y solo ellos pueden piloteas aparatos. La
compañía dispone también de aviones de diferentes tipos. Para cada tipo de aparato
necesita registrar el constructor, el numero de modelo, el numero de asientos que posee y
la velocidad de crucero que alcanza. A los aviones se les asigna un número de serie e
interesa conocer el número de horas de vuelo que han cumplido cada uno. Cada vuelo
tiene asignado un avión concreto y varios empleados.

3. La AFA, necesita contar con la información acerca de los jugadores de fútbol, los
equipos para los que han jugado, su promedio de goles por temporada y las
posiciones en que han jugado durante su carrera deportiva. Las entidades son:

Jugadores con atributos nombre, lugar de nacimiento y fecha de nacimiento y

equipo.

Posiciones con atributos nombre, numero

Promedio de goles, conjunto de promedio de goles. Esta entidad tiene un único
atributo numérico.

Equipos, nombre, técnico, promedio para el descenso.

Con la información suministrada, debemos construir un esquema tal que permita

resolver el problema y nos brinde la posibilidad de crear la base de datos. Proponga e
identifique relaciones, atributos, identificadores, etc. Todo lo que considere necesario.

4. El dueño del almacén Don Chicho, nos ha solicitado que le hagamos un sistema
que sea capas de brindarle información acerca de los datos según el siguiente
informe surgido de un relevamiento previo:

Cada empleado está representado. Los datos a considerar de un empleado son

su número de empleado, nombre, dirección y el departamento para el que
trabaja.

Cada departamento está representado. Los datos a considerar de los
departamentos son su nombre, empleados, director, y productos que tiene
asignados.

Cada producto con que se trabaja está representado. Los datos a considerar de
los productos son nombre, fabricante, precio, número de modelo asignado por el
fabricante y el número de producto interno asignado por el almacén.

Cada fabricante se representa. Los datos son su nombre, dirección, productos
que suministra al almacén y su precio.
t23

Institución Cervantes 5
INSTITUCIÓN CERVANTES

5. La biblioteca de la Institución, necesita información acerca de los libros

departamentales y nos han solicitado que a partir de los requerimientos planteados
construyamos la base de datos:

Cada departamento puede adquirir anualmente y a un cierto precio cierto
número de ejemplares de un libro que pasan a ser de su propiedad y a los que
inmediatamente se les asigna un numero de registro general de biblioteca. De
cada libro interesa su titulo, autor, materia, editorial y año de publicación, así
como su número de código (ISBN) que lo identifica unívocamente.

Los ejemplares pueden ser tomados en calidad de préstamo (con fecha limite de
devolución) por los profesores del centro pertenezcan o no al centro

6. Realizar las transformaciones de esquema conceptual a esquema lógico de todas las

actividades planteadas hasta este punto donde usted crea que se pueden realizar.

Actividad VI – Unidad 5
Siendo usted el encargado del centro de cómputos del Hospital y responsable del
mantenimiento y administración de las bases de datos del mismo, deberá diseñar una
base de datos que contenga información referente a la planificación de las operaciones de
los cirujanos del hospital.

El hospital comprende un cierto número de servicios (con un código y un nombre) a

los que están adscritos los cirujanos.

Cada servicio dispone de habitaciones para la hospitalización de los enfermos. Estas
habitaciones, que tienen un número único sobre el conjunto del hospital, pueden
contener de uno a cuatro camas, según el caso. Cada cama está numerada de uno a
cuatro en la habitación.

Los informes concernientes a la hospitalización de los enfermos (número de
enfermo, nombre, fecha de nacimiento, fecha de hospitalización) se archivan
durante su estancia.

Cada cirujano tiene una especialidad, pero varios de ellos pueden tener la misma.
Las especialidades están codificadas y tiene un nombre.

Puede suceder que un enfermo deba sufrir varias operaciones durante una misma
hospitalización, en diferentes fechas y realizadas por cirujanos que pueden
pertenecer a un servicio diferente a aquel en el que están hospitalizados.

Con la información que se ofrece, realizar las tareas necesarias para la construcción de
la base de datos. Verifique si las relaciones obtenidas se encuentran en la forma normal
correcta. Justifique su respuesta explicando el proceso utilizado.

Actividad VII
Dada la siguiente descripción de un sistema de información (Aeropuerto
Internacional), obtenga el esquema conceptual del mismo utilizando el modelo E/R y su
correspondiente transformación a esquema lógico. Realice un control de la base de datos
6 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I – Actividades

obtenida aplicando los mecanismos de normalización y justifique el porque considera

que las relaciones están en la forma normal óptima.

a) Control de cada avión registrado en el aeropuerto (Nº Registro, matrícula,

antigüedad, fecha registro,...). Cada avión es de un tipo determinado, recogiéndose
de cada tipo su modelo, capacidad y peso.
b) Control de los hangares (Código hangar, capacidad y localización) donde se
estacionan aviones. Cada avión tiene designado un hangar.
c) Control de los propietarios de aviones (código, nombre, dirección, teléfono).
Relación N:M. Se registrará la fecha de compra de cada avión.
d) Control de pilotos (Num-licencia). Están cualificados para pilotar determinados
tipos de aviones (no todos los pilotos pueden pilotear todos los aviones, solamente
aviones de algún tipo)
e) Control de empleados de mantenimiento (salario). Cualificados para trabajar en
determinados tipos de aviones (ídem que los pilotos). Mantienen aviones
específicos (para cada acción de mantenimiento se registrará: fecha, horas, código
de trabajo).
f) Se registrará el Número de Documento, nombre, dirección, teléfono de todas las
personas (mecánicos, pilotos) de la BD.

Actividad VIII
1. La figura siguiente es una representación jerárquica (no normalizada) del conjunto
de datos que se va a grabar en una base de datos de personal de una empresa.

Departamento

Empleado Proyecto Oficina

Trabajo Teléfono

Historia de Salarios

La figura se debe leer así:

La empresa tiene un conjunto de departamentos.

Cada departamento tiene un conjunto de empleados, un conjunto de proyectos, y
un conjunto de oficinas.

Cada empleado tiene una historia de empleos (conjunto de trabajos que ha tenido el
empleado). Para cada empleo, también el empleado tiene una historia de salario
(conjunto de salarios recibidos mientras tenía ese empleo).

Cada oficina tiene un conjunto de teléfonos.
Institución Cervantes 7
INSTITUCIÓN CERVANTES

La base de datos debe contener la siguiente información.

Para cada departamento: número de departamento (único), presupuesto, y el
número de empleado del gerente del departamento (único).

Para cada empleado: número de empleado (único), número de proyecto actual,
número de oficina y número telefónico; además, el título de cada trabajo que ha
tenido el empleado, junto con la fecha y el salario para cada salario distinto recibido
en ese trabajo.

Para cada proyecto: número de proyecto (único) y presupuesto.

Para cada oficina: número de oficina (único), área en metros cuadrados, y números
de todos los teléfonos (único).
Diseñar un conjunto apropiado de relaciones normalizadas para representar esta
información.
Indicar cualquier suposición hecha acerca de las dependencias existentes.

Actividad IX

1. Una base de datos empleada en un sistema de recepción de pedidos debe contener

información acerca de clientes, artículos y órdenes. Debe incluirse la siguiente
información.

Para cada cliente:
Número de cliente (único)
Direcciones de envío (varias por cliente)
Saldo
Límite de crédito
Descuento

Para cada pedido:
Información de cabecera: número de cliente, dirección de envío, fecha
del pedido.
Renglones del detalle (varios por pedido): número de artículo,
cantidad ordenada.

Para cada artículo:
Número de artículo (único)
Plantas manufactureras
Cantidad existente en cada planta
Punto de reorden para cada planta
Descripción del artículo

Por razones de procesamiento interno, se asocia un valor de “cantidad pendiente” a cada

renglón de detalle de cada pedido. Este valor es, en un principio, igual a la cantidad
ordenada del artículo y se reduce (de manera progresiva) a cero conforme se hacen las
entregas parciales.

Diseñar una base de datos para esta información. Indicar cualquier suposición hecha
acerca de las dependencias.

8 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I – Actividades

2. Supongamos que en el ejercicio anterior, sólo un número muy reducido de clientes,

digamos el uno por ciento o menos, tienen más de una dirección de envío (esto
concuerda con las situaciones de la vida real, en las que muchas veces unas cuantas
excepciones -–casi siempre bastante importantes- no se ajustan a cierto patrón en
general.) ¿Puede detectar alguna deficiencia en la solución al ejercicio anterior?
¿Puede elaborar alguna mejora?

Actividad X
Dado el siguiente esquema realizar la normalización teniendo en cuenta las pautas
establecidas más abajo:

Planteo:
Se ha presentado para el Ministerio de Educación de la Provincia, la posibilidad de
crear una base de datos que le permita el control de los establecimientos educativos de la
provincia, los cuales presentan al inicio del ciclo lectivo los planes de estudio y los
alumnos que asistirán a cada curso. Se le encomendó al departamento Desarrollo de
Sistemas la tarea de crear el esquema correspondiente a la base de datos a implementar.
En una primera instancia, se ha conseguido el esquema que se muestra a continuación:

Pautas

Una escuela puede tener más de un plan de estudio aprobado.

Un plan de estudio consta de varias materias por división o año.

Un mismo plan de estudio puede dictarse en varios turnos.

Un alumno puede o no cursar materias.

Un cursante de materias puede asistir a más de una materia.

Se desea almacenar todas las notas de las materias (parciales, finales, etc) por
cursante.

Institución Cervantes 9
INSTITUCIÓN CERVANTES

Se desea mantener el legajo del alumno con la condición frente a la escuela y el

registro de todas las solicitudes de documentación.

Se desea controlar, también las fechas de inscripción a los exámenes finales.

Actividad XI
A pedido de la empresa constructora BRONSON, se realizó un relevamiento de la
información que necesita para el seguimiento de Obras. Cada obra está diferenciada por
un código de obra único. Tiene una fecha de inicio de obra, un costo y un cliente que es
el que encargó la obra. Cada cliente puede encargar más de una obra. Cada obra es
dirigida por un arquitecto quien es el encargado de ejecutar el proyecto. A su vez, existe
un inspector de obra quien es el responsable de controlar el seguimiento de la misma.

Las obras están determinadas o agrupadas por tareas que deben ser realizadas en un
tiempo establecido (fecha de inicio y de finalización de la tarea). Cada tarea tiene un
responsable o encargado de ejecutarla (por ejemplo: pisos tiene como responsable a
Pedro).

A raíz de este relevamiento, se obtuvo la siguiente relación no normalizada:

CODIGO DE OBRA
CODIGO ARQUITECTO DE LA OBRA
NOMBRE DEL ARQUITECTO
MATRICULA ARQUITECTO
COSTO DE LA OBRA
FECHA INICIO DE OBRA
SUPERFICIE DE OBRA
CLIENTE
NOMBRE DEL CLIENTE
DIRECCION DEL CLIENTE
TELEFONO DEL CLIENTE
INSPECTOR
NOMBRE DEL INSPECTOR
CODIGO DE TAREA
DETALLE TAREA
TIEMPO DE LA TAREA
FECHA INICIO DE LA TAREA
FECHA FINALIZACION DE LA TAREA
CODIGO ENCARGADO DE LA TAREA
NOMBRE DEL ENCARGADO

Construir la base de datos normalizada utilizando las herramientas que considere

necesarias.

10 INSTITUCIÓN CERVANTES
 Área Informática
INSTITUCIÓN CERVANTES Base de Datos I – Actividades

Actividad XII
La librería NN, nos ha entregado un listado del resumen de ventas por vendedores que
trabajan para la misma. A pedido de la misma, es nuestra tarea construir la base de datos
a partir de estos datos para la administración de las ventas de la librería.

NFAC NOMVEN NOMCLI LOCALIDAD CP NART ARTICULO CANT PU FECHA

FACTURA
1 PEDRO Luis Málaga 5000 A1 Papel 100 5 3/5/02
1 PEDRO Luis Málaga 5000 A3 Cinta 50 500 3/5/02
1 PEDRO Luis Málaga 5000 A9 Disco 25 200 3/5/02

3 PEDRO Ana Cordoba 5500 A4 Ojalillos 100 5 10/5/02

3 PEDRO Ana Cordoba 5500 A3 Cinta 50 500 10/5/02

NFAC NOMVEN NOMCLI LOCALIDAD CP NART ARTICULO CANT PU FECHA

FACTURA
2 JUAN Luis Málaga 5000 A1 Papel 100 5 13/5/02
2 JUAN Luis Málaga 5000 A5 Grapas 30 20 13/5/02

Actividad XIII
Investigar y documentar:

Para cada uno de los siguientes problemas deberá crear un modelo de datos conceptual
consistente de conjunto de entidades, interrelaciones, atributos y otros, que puedan
usarse para responder preguntas similares a las preguntas dadas. Indique las
cardinalidades.

Este modelo es para un entorno universitario

¿Cuántos alumnos del primer semestre del Instituto han sido asignado en cada uno
de los grupos formados para ellos?

¿Cómo se llaman los grupos?

¿Cómo se llaman los alumnos?

¿Quién es su docente de computación?

¿Quién es su docente de informática?

¿Cuántos de estos estudiantes son repetidores?

¿Cuántas materias cursa cada alumno?

Institución Cervantes 11
INSTITUCIÓN CERVANTES

Actividad XIV
Investigar y documentar:

Exponga un conjunto de argumentos para convencer a un directivo de una empresa, no

técnico en informática, de la conveniencia de que su empresa, que utiliza desde hace
años un sistema clásico orientado a archivos, cambie su enfoque hacia una base de datos
(haga la hipótesis que desee sobre el tipo de aplicaciones de la empresa)

¿Cuáles pueden ser las causas de que fracase un poyecto de creación de una base de
datos?

Entreviste a un DBA de una empresa local, determine si utiliza un sistema de

diccionario de datos. ¿Está integrado con el DBMS? De ser así ¿cuáles son sus ventajas y
desventajas? De lo contrario, por qué la empresa eligió ese tipo de diccionario de datos.

Entreviste a una persona que use una aplicación de base de datos. ¿Cuáles funciones
del negocio son atendidas? ¿Qué información se produce? ¿Qué objetos están
involucrados? ¿Es esta una aplicación personal, de grupos de trabajo o de una
organización?

Tutores

Sugerencia: Las limitantes “cada empleado trabaja en un departamento” y “cada

t1
departamento forma parte de una división” son ejemplos de interrelaciones de uno
a muchos”.

Nótese que alguna información puede ser representada por atributos y otra por
t2
relaciones.

Material elaborado por Prof. Néstor Berasategui

2003 – AML 
27/05/2009 19:06:00 

12 INSTITUCIÓN CERVANTES