Bases de Datos (Apuntes)

BASES DE DATOS –– APUNTES
 UNIDAD Nº 1: INTRODUCCIÓN A LAS BASES DE DATOS
1) Definición: Una BD es un conjunto de datos almacenados en conjunto, sin redundancias

perjudiciales o innecesarias.
Su finalidad es servir a una aplicación o más y los datos se almacenan de modo que resultan
independientes de los programas que los usan (James Martín).
En el enfoque de BD se mantiene un único almacén de datos que se define una sola vez y al cual tienen
acceso muchos usuarios.
Otra definición: Sistema de mantenimiento de registros basado en computadoras, cuyo interés es

almacenar y registrar información. Tal información está relacionada con cualquier cosa que sea
significativa para la organización donde el sistema opere (Date).
Una BD tiene las siguientes propiedades implícitas:

- Una BD representa algún aspecto del mundo real, llamadas minimundo o universo del
discurso. Las modificaciones del minimundo se reflejan en la base de datos.
- Una BD es un conjunto de datos lógicamente coherente, con cierto significado inherente, o
sea que no es un conjunto aleatorio. Una colección aleatoria de datos no puede considerarse
propiamente una base de datos.
- Toda BD se diseña, construye y se carga con datos para un propósito específico. Está
dirigida a un grupo de usuarios y tiene aplicaciones preconcebidas que interesan a dichos
usuarios.
2) Características del enfoque de BD
• Las BD son un único almacén al que tienen acceso varios usuarios y toman la información que
necesitan, lo cual da la ventaja de evitar la redundancia.
• Naturaleza auto descriptiva de los Sistemas de BD

El Sistema de BD no solo contiene la BD misma, sino también una definición o descripción
completa de la BD. Esta definición se almacena en el Catálogo del Sistema. La información
almacenada en el Catálogo se le denomina Metadatos, los cuales describen la estructura de la BD
primaria.
Ej. ALUMNO
- nombre
- apellido
- domicilio
- legajo
Si comparamos con los archivos, en éstos los datos se manejan desde el programa.
• Separación entre los programas y los datos, y abstracción de los datos

Facilita el mantenimiento. El mecanismo de abstracción me permite hacer esa separación entre
programas y datos.
En el procesamiento de archivos tradicional, la estructura de los archivos de datos viene integrada
en los programas de acceso así que cualquier modificación de la estructura de un archivo, puede
requerir la modificación de todos los programas que tienen acceso a dicho archivo.
En cambio los programas de acceso del SGBD se escriben de modo que sean independientes de
cualquier archivo específico. La estructura de los archivos de datos se almacena en el catálogo del
SGBD aparte de los programas de acceso.
1
La característica que hace posible la independencia con respecto a los programas y datos se
denomina abstracción de los datos. Un SGBD ofrece a los usuarios una representación conceptual
de los datos que no incluye muchos de los detalles de cómo se almacenan.
• Manejo de múltiples vistas de los datos

Es la parte de la base de datos que le interesa a cada usuario, a los fines de una aplicación en
particular, entendiéndose como aplicación a un subconjunto de ese sistema de información que
tiene software, hardware, recursos humanos, etc.
Una BD suele tener muchos usuarios, cada uno de los cuales puede requerir una vista diferente de
la mencionada BD. Una vista puede ser un subconjunto de la BD o contener datos virtuales que se
deriven de los archivos de la BD, pero que no estén almacenados explícitamente.
• Compartimiento de datos y procesamiento de transacciones multiusuario

Si los datos son compartidos, necesito un mecanismo de control de concurrencia.
Todo SGBD multiusuario, debe permitir a varios usuarios tener acceso simultáneo a la BD. El
SGBD debe incluir software de control de concurrencia para asegurar que cuando varios usuarios
intenten actualizar los mismos datos lo hagan de manera controlada para que el resultado de las
actualizaciones sea correcto. Una función fundamental del software del SGBD multiusuario es
asegurar que las transacciones concurrentes se realicen de manera correcta sin interferencias.
De todas estas características, las más importantes son las tres primeras.
2) Actores de una BD:

- Administradores de BD (ABD): se encargan de supervisar y controlar los recursos tales como la
BD, el SGBD y el software con él relacionado. El ABD se encarga de autorizar el acceso a la BD, de
coordinar y vigilar su empleo y de adquirir los recursos necesarios de software y hardware. Es
responsable cuando surgen problemas como violaciones a la seguridad o una respuesta lenta del
sistema.
- Diseñadores de BD: se encargan de identificar los datos que se almacenarán en la BD y de elegir

las estructuras apropiadas para representar y almacenar dichos datos. Son los que se comunican con
todos los futuros usuarios de la BD, a fin de comprender sus necesidades y de presentar un diseño
que satisfaga esos requerimientos.
- Usuarios finales: pueden ser:

Esporádicos: acceden a la BD de vez en cuando, pero es posible que requieran información
diferente en cada ocasión. Utilizan un lenguaje de consulta de BD avanzado para especificar sus
solicitudes.
Simples o Paramétricos: realizan consultas y actualizaciones constantes de la BD, utilizando tipos
estándar de estas operaciones, llamadas transacciones programadas.
Avanzados: ingenieros, científicos, analistas de negocios y otros, quienes conocen perfectamente
los recursos del SGBD para satisfacer sus complejos requerimientos.
• Sistema de gestión de Base de Datos (SGBD)

Un Sistema de Gestión de Base de Datos (SGBD) es un conjunto de programas que permite a los
usuarios crear y mantener una Base de Datos, por lo tanto, el SGBD es un sistema de software de
propósito general que facilita el proceso de definir, construir y manipular bases de datos para diversas
aplicaciones.
En otras palabras, es un software de propósito general cuya finalidad es crear, construir y
manipular una base de datos.
Crear: o sea definir la estructura a través de un lenguaje de definición de datos.
Construir: almacenar
2
Manipular: acceder a la información
Al conjunto formado por la base de datos y el software lo llamamos sistema de base de datos.
Usuarios/Programadores
Sistema de
Base de datos
Programas de aplicación
Soft del Software para procesar

SGBD consultas
Software para acceder a los

datos
Definición de la Base de datos

BD almacenada almacenada
(metadatos)
Definición de la estructura de Base Solo datos

datos independiente de los de datos
programas que se usan
• Características deseables de un SGBD
 Control de redundancia: se refiere a la redundancia en el almacenamiento de los datos. Este

control es necesario para evitar:
- Duplicar el trabajo, por ejemplo realizar una misma actualización lógica varias veces, una
vez en cada archivo en que se registren los datos con los que se trabaja.
- Desperdiciar espacio de almacenamiento al guardar los mismos datos en distintos lugares.
- Que los archivos sean inconsistentes porque a lo mejor una actualización se realiza por un
grupo de usuarios pero por otros no.
En el enfoque tradicional de archivos, cada grupo de usuarios mantiene sus propios archivos para
mantener sus aplicaciones de procesamiento de datos. Una buena parte de los datos se almacenaría
varias veces. Esta redundancia en el almacenamiento de los mismos datos provoca varios problemas.
En primer lugar, es necesario realizar una misma actualización lógica varias veces, una vez en cada
3
archivo en el que se registren los datos de los estudiantes por ejemplo. Esto implica una duplicación
del trabajo.
En segundo lugar, se desperdicia espacio de almacenamiento al guardar los mismos datos en varios
lugares, y este problema puede ser grave si las bases de datos son grandes.
En tercer lugar, es posible que los archivos que representan los mismos datos se tornen inconsistentes
tal vez porque una actualización se haya aplicado a ciertos archivos pero no a otros.
Para conservar la consistencia, debe crearse un diseño que almacene cada dato lógico en un solo lugar
de la Base de dato. Ello evita la inconsistencia y ahorra espacio de almacenamiento. En algunos casos
puede convenir la redundancia controlada.
 Restricción de los accesos no autorizados: cuando muchos usuarios comparten una misma base
de datos, es probable que no todos tengan la autorización para tener acceso a toda la información
que contiene. Puede ser que algunos usuarios tengan permiso para recuperar datos solamente,
mientras que a otros se les permita obtenerlos y actualizarlos. A los usuarios o grupos de usuarios
se les asignan números de cuentas protegidos por contraseña, los mismos sirven para tener acceso a
la BD. El SGBD debe contar con un subsistema de seguridad y autorización que permita al DBA
crear cuentas y especificar restricciones para ellas.
 Suministro de múltiples interfaces con los usuarios : en vista de que muchos tipos de usuarios
con distintos niveles de conocimientos técnicos utilizan las Bases de Datos, el SGBD debe ofrecer
diferentes interfaces.
 Representación de vínculos complejos entre los datos: una BD puede contener numerosos
conjuntos de datos que estén relacionados entre sí de muchas maneras. Es necesario que el SGBD
pueda representar diversos vínculos complejos de los datos y también obtener y actualizar con
eficiencia datos que estén mutuamente relacionados.
 Cumplimiento de las restricciones de integridad: la mayor parte de las aplicaciones de base de

datos tienen ciertas restricciones de integridad que deben cumplir los datos. El SGBD debe ofrecer
recursos para definir estas restricciones y hacer que se cumplan. La forma más simple de restringir
la integridad consiste en especificar un tipo de datos para cada elemento de información.
 Respaldo y recuperación: todo SGBD debe contar con recursos para recuperarse de fallos de
hardware o software. Para ello está el subsistema de respaldo y recuperación del SGBD. Por
ejemplo, si el sistema falla mientras se está ejecutando un programa de actualización, el subsistema
de recuperación se encargará de asegurarse de que la BD se restaure al estado en el que estaba
antes de que comenzara la ejecución del programa. Como alternativa el subsistema de recuperación
puede asegurarse de que el programa reanude su ejecución en el punto en que fue interrumpido, de
modo que su efecto completo se registre en la BD.
4
 UNIDAD Nº 2: ARQUITECTURA DE UN SISTEMA DE BASE DE DATOS
 Modelos de datos, esquemas y ejemplares:
Una característica fundamental del enfoque de BD es que proporciona cierto nivel de

abstracción de los datos al ocultar detalles de almacenamiento que la mayoría de los usuarios no
necesitan conocer.
Los modelos de datos son el principal instrumento para ofrecer dicha abstracción.
Un modelo de datos es un conjunto de conceptos que pueden servir para describir la estructura
de una BD.
Por lo general, los modelos de datos contienen además un conjunto de operaciones básicas para
especificar lecturas y actualizaciones de la BD.
Abstracción de datos Modelo de datos
Un modelo de datos es un instrumento que nos permite definir el minimundo. Es el conjunto de
conceptos que definen la estructura de la base de datos.
Los modelos pueden ser de distinto tipo:
- De alto nivel o conceptuales: definen conceptos muy cercanos a como el usuario percibe la
información.
- De bajo nivel o físicos: permiten describir detalles de cómo se almacenan los datos en el
computador, dando información como los formatos y ordenamientos de los registros y los
caminos de acceso.
- De representación o implementación: son modelos intermedios entre los dos anteriores.
Pueden ser entendidos por los usuarios finales aunque no sean demasiado alejados de la
forma en que los datos se organizan dentro del computador, ocultan algunos detalles de
cómo se almacenan los datos, pero pueden implementarse de manera directa en un sistema
de computador.
 De alto nivel o conceptuales: definen conceptos muy cercanos a como el usuario percibe la
información.
Los conceptos que definen son los siguientes:
• Entidades: objeto del cual queremos obtener información. Las del mismo tipo se
agrupan en tipos de entidades. Representan un objeto o concepto del mundo real almacenado
en la BD, como un empleado o un proyecto.
El objeto puede ser:
- abstracto como por ejemplo una cuenta bancaria o
- real como por ejemplo alumnos.
• Atributos: son características que nos permiten describir e identificar una entidad.
Representa alguna propiedad de interés que da una descripción más amplia, como el nombre o
el salario del empleado. ALUMNO
entidad
Nro. De legajo
DNI
atributos
Apellido y nombre
Fecha de nacimiento
Carrera
5
Los atributos pueden ser:
- simples: están compuestos por un atributo nada más. Ej. Día

- compuestos: formado por una concatenación de atributos simples
- multivaluados: pueden tomar muchos valores. Ej. Carrera

- monovaluados:
- almacenados: todos los atributos son almacenados.

- derivados: son los que se pueden obtener de los almacenados. Ej. Edad.
Aparte los atributos deben ser:
- de identificación unívoca: distinguen a uno de otro. Ej. Nro. Legajo, DNI. Puede haber más
de uno. Si hay dos y selecciono uno como clave principal, el otro queda como clave
alternativa.
Los atributos pueden separarse en dos grupos, de acuerdo al “rol” que desempeñan: por
ejemplo si hablamos de la entidad automóvil, algunos atributos son:
1. los que identifican a la entidad (como la patente)

2. los que describen a la entidad (como la marca, el color, etc.). Permiten brindar o aportan
más información sobre la entidad.
Los atributos pueden tomar un valor o múltiples valores, de un conjunto de valores posibles,
que se denomina dominio de valores. Por ejemplo, el dominio del atributo color es el conjunto
cerrado: rojo, azul, verde, amarillo, blanco. Para cada atributo se define un dominio de valores.
El valor nos permite instanciar
Ej. Legajo 100 - 3000
O sea que el atributo legajo debe tener un valor entre 100 y 3000. Esta es una restricción de
integridad.
Los dominios de diferentes atributos pueden parecer idénticos, cuando en realidad no lo son,
debido a que representan distintos roles. Por ejemplo el color interior y exterior de un
automóvil.
Tomando el siguiente ejemplo:

CURSO
entidad
atributos Profesor
Podemos dar el concepto de atributo multivaluado. Un curso puede ser dictado

alternativamente en un mismo período por tres profesores, en una secuencia determinada de
antemano.
Un atributo puede identificar unívocamente a cada miembro de la entidad, es un identificador

único. Esta entidad puede tener uno, varios o ningún identificador único. Normalmente, cuando
no existe un identificador único se crea uno artificial (como el código de proveedor), que recibe
el nombre de tag o etiqueta.
6
Uno de los identificadores únicos se elige como clave de la entidad.
• Vínculos: describen una interacción entre dos o más entidades, por ejemplo el vínculo de trabajo,
“trabaja en”, entre un empleado y un proyecto.
Los vínculos pueden ser de distinto tipo:
- Vínculos incondicionales
- Vínculos condicionales
VÍNCULOS INCONDICIONALES: Por ejemplo tenemos dos entidades A y B de alumnos. Cuando

las instancias de ambas entidades participan del vínculo binario incondicional.
UNO A UNO: cuando una instancia de A se relaciona con una y solo una instancia de B, y a cada
instancia de B una y solo una de A.
A B
1:1
UNO A MUCHOS: cuando a cada instancia de A le corresponde una o más de una instancia de B, y
cada instancia de B se relaciona con una instancia de A.
A B
1:M
MUCHOS A MUCHOS: cuando cada instancia de A se relaciona con una o más instancias de B y
cada instancia de B se relaciona con una o más instancias de A.
A B
M:M
7
VÍNCULOS CONDICIONALES: un vínculo binario es condicional cuando hay instancias en alguna
de las dos entidades que no participan en el vínculo.
UNO A UNO CONDICIONAL: cuando una instancia de A se relaciona con cero o una instancia de
B, y a cada instancia de B una y solo una de A.
A B
1:1c
UNO A MUCHOS CONDICIONAL: cuando cada instancia de A se relaciona con cero, una o
muchas instancias de B. Cada instancia de B se relaciona con una instancia de A.
A B
1:Mc
UNO CONDICIONAL A MUCHOS: cuando una instancia de A se relaciona con una o más
instancias de B y cada instancia de B se relaciona con cero o una instancia de A.
A B
1c:M
MUCHOS A MUCHOS CONDICIONAL: cuando cada instancia de A se relaciona con cero, una o
muchas instancias de B y cada instancia de B se relaciona con una o muchas instancias de A.
A B
M:Mc
8
VÍNCULOS BICONDICIONALES: cuando hay instancias de las dos entidades del vínculo que no
participan del vínculo.
UNO CONDICIONAL A UNO CONDICIONAL: cuando cada instancia de A se relaciona con cero
o una instancia de B, y cada instancia de B se relaciona con cero o una instancia de A.
A B
1c:1c
UNO CONDICIONAL A MUCHOS CONDICIONAL: cuando cada instancia de A se relaciona con

cero, una o muchas instancias de B, y cada instancia de B se relaciona con cero o una instancia de A.
A B
1c:Mc
MUCHOS CONDICIONAL A MUCHOS CONDICIONAL: cuando cada instancia de A se

relaciona con cero, una o muchas instancias de B y cada instancia de B se relaciona con cero, una o
muchas instancias de A.
A B
Mc:Nc
La cardinalidad representa las instancias (1:M, 1:M, etc.). La condición va siempre del lado del que
participa.
9
Vimos hasta ahora:
- ENTIDADES
- ATRIBUTOS
- VÍNCULOS
- VALORES
- DOMINIOS
A su vez, los vínculos pueden ser:
- n-ários
- binarios
- ternarios
A su vez, los vínculos binarios pueden ser:
- Individuales
- Condicionales
- Bicondicionales
La Cardinalidad puede ser:
1:1
1:M
M:M
 Esquemas y ejemplares:
Es importante distinguir entre la descripción de la BD y la BD misma.

La descripción se conoce como esquema de la BD, el cual se especifica durante el diseño y no
es de esperar que se modifique muy a menudo.
El esquema puede representarse mediante un diagrama denominado diagrama de esquema. Este

diagrama presenta la estructura de todos los tipos de registros pero no los ejemplares reales de los
registros, solo ilustra algunos aspectos del esquema, como los nombres de los tipos de registros y de
los elementos de información, y algunas clases de restricciones, no se especifican otros aspectos como
el tipo de datos de cada elemento de información ni los vínculos entre los diferentes archivos.
Los datos reales de la BD pueden cambiar con mucha frecuencia. Los datos que la BD contiene
en un determinado momento se denomina estado de la BD, conjunto de ocurrencias o ejemplares.
Cada vez que se inserta o elimina un registro, o que se modifica el valor de un elemento de
información, transformamos el estado de la BD en otro.
La distinción entre esquema y el estado de la BD es muy importante. Cuando definimos una

nueva BD solo especificamos su esquema al SGBD. En este momento el estado correspondiente de la
BD es el “estado vacío”, sin datos.
Cuando cargamos estos por primera vez, la BD pasa al “estado inicial”. De ahí en adelante cada
vez que se realice una actualización a la BD, tendremos otro estado.
BASE DE DATOS <> descripción de la BASE DE DATOS
Valores almacenados Catálogo de datos
10
- Esquema de una Base de Datos
ALUMNO MATERIA
* Nro. Leg. DNI Apellido Nombre * Cod. Mat. Nombre Reg. Prom Otro
- Base de datos almacenada
ALUMNO MATERIA
* Nro. Leg. DNI Apellido Nombre * Cod. Mat. Nombre Reg. Prom Otro
30110/03 32132055 Escobar Romina 020 Algebra I 0 --
30115/03 30256421 López Jorge 050 Sistemas I 1 --
30117/03 35042126 Morales Carlos 060 Lógica II 1 --
Romina, Jorge y Carlos son distintas instancias de la BD ALUMNOS.

Algebra I, Sistemas I y Lógica II son distintas instancias de la BD MATERIA.
Se puede representar también:
ALUMNO
* Nro. Leg. DNI Apellido Nombre
MATERIA
* Cod. Mat. Nombre Reg. Prom Otro
Entidades Atributos
Primero debemos definir el esquema.

Después debemos tratar de que el esquema no cambie con el tiempo, esto se debe garantizar,
debe ser lo más estático posible con respecto a la descripción de la BD. El relevamiento debe estar
hecho a conciencia. No debería olvidarme de ningún dato.
Lo que si cambia es el estado de la BD.

Llamamos estado al conjunto de datos que conforman la BD en un momento dado. Cuando
recién creamos la BD, el estado es vacío. Cuando cargamos los datos por primera vez, el estado es
inicial.
Llamamos registro al conjunto de ejemplares, ocurrencias o instancias que hablan del estado de
la BD.
Llamamos aplicación al programa que pertenece al SI, más los usuarios, más el hardware, etc.
 Arquitectura de un SGBD:
Habíamos visto ya las características:
• Uso de un catálogo para definir datos. O sea que los datos se definen aparte.
• Empleo de múltiples vistas de usuarios. Una BD no satisface los requerimientos de una
única aplicación.
• Independencia entre datos – programas, que se da al emplear el catálogo.
Estas tres características son posibles con una estructura de tres niveles.
El objetivo de la arquitectura de tres esquemas consiste en formar una separación entre las
aplicaciones del usuario y la BD física.
Los esquemas se pueden definir en los tres niveles siguientes:
11
- Nivel Interno: Se refiere al almacenamiento, equipo, etc. Tiene un esquema interno, que
describe la estructura física de almacenamiento de la BD. El esquema interno emplea un
modelo físico de los datos y describe todos los detalles para su almacenamiento, así como
los caminos de acceso para la BD.
- Nivel Conceptual: tiene un esquema conceptual, el cual oculta los detalles de las
estructuras físicas de almacenamiento y se concentra en describir entidades, tipos de datos,
vínculos, operaciones de los usuarios y restricciones.
- Nivel Externo: incluye varios esquemas externos o vistas de usuario. Cada esquema
externo describe la parte de la BD que interesa a un grupo de usuarios determinado, y
oculta a ese grupo el resto de la BD.
Debe existir una transformación o mapeo entre el nivel externo al nivel conceptual y otro
mapeo entre el nivel conceptual y el nivel interno.
NIVEL Vista Externa 1 Vista Externa n

EXTERNO
Correspondencia externa/conceptual
ESQUEMA CONCEPTUAL
NIVEL
CONCEPTUAL
Correspondencia conceptual/interna
ESQUEMA INTERNO
NIVEL
INTERNO
Base de Datos
almacenada
Los tres esquemas no son más que descripciones de los datos, los únicos datos que existen
realmente están en el nivel físico.
En un SGBD basado en la arquitectura de tres esquemas, cada grupo de usuarios hace
referencia exclusivamente a su propio esquema externo, por lo tanto el SGBD debe transformar una
solicitud expresada en términos de un esquema externo o una solicitud expresada en términos del
esquema conceptual, y luego a una solicitud en el esquema interno que se procesará sobre la base de
datos almacenada.
El proceso de transformar solicitudes y resultados de un nivel a otro se denomina
correspondencia, transformación, o “mupping”.
Esta arquitectura nos permite dar dos conceptos muy importantes en una Base de Datos.
 Independencia respecto a los datos: se define como la capacidad de modificar el esquema en un

nivel del sistema de BD sin tener que modificar el esquema del nivel inmediato superior. O sea que
es la posibilidad de modificar un nivel de la arquitectura sin modificar los otros niveles, es decir sin
cambiar el esquema. Se pueden definir dos tipos de independencia con respecto a los datos.
12
 Independencia lógica
 Independencia física
- Independencia lógica: significa modificar el esquema conceptual sin modificar los

subesquemas externos. Con respecto a los datos, es la capacidad de modificar el esquema
conceptual sin tener que alterar los esquemas externos ni los programas de aplicación.
Podemos modificar el esquema conceptual para ampliar la BD o para reducir la BD.
- Independencia física: significa modificar el nivel interno sin necesidad de modificar el

nivel conceptual. Con respecto a los datos es la capacidad de modificar el esquema interno
sin tener que alterar el esquema conceptual (o los externos). Tal vez sea preciso modificar
el esquema interno por la necesidad de reorganizar ciertos archivos físicos con el fin de
mejorar el rendimiento de las operaciones de obtención o actualización. Dado que la
independencia física con respecto a los datos se refiere a la separación entre las aplicaciones
y las estructuras físicas de almacenamiento, es más fácil de lograr que la independencia
lógica.
La independencia con respecto a los datos se logra porque, al modificarse el esquema en algún
nivel, el esquema del nivel inmediato superior permanece sin cambios; solo se modifica la
correspondencia entre dos niveles. No es preciso modificar los programas de aplicación que hacen
referencia al esquema del nivel superior. Por lo tanto, la arquitectura de tres niveles puede facilitar el
logro de la verdadera independencia con respecto a los datos, tanto física como lógica.
 Lenguajes e interfaces de Bases de Datos:
• Lenguajes del SGBD
En muchos SGBD en los que no se mantiene una separación estricta de niveles, el ABD y los
diseñadores de la BD utilizan un mismo lenguaje, el lenguaje de Definición de Datos (DDL).
Cuando en los SGBD se mantenga una clara separación entre los niveles conceptual e interno, el
DDL servirá solamente para especificar el esquema conceptual. Se utiliza otro lenguaje, el Lenguaje de
Definición de Almacenamiento (SDL) para especificar el esquema interno.
Para una verdadera arquitectura de tres esquemas necesitaríamos un tercer lenguaje, el Lenguaje de
Definición de Vistas (VDL), para especificar las vistas del usuario y sus correspondencias con el
esquema conceptual.
Además los usuarios requieren de algún mecanismo para manipular la BD, el SGBD ofrece un
Lenguaje de Manipulación de Datos (DML).
En los SGBD actuales no se acostumbra distinguir entre los tipos de lenguajes mencionados, más
bien, se utiliza un amplio lenguaje integrado que cuenta con elementos para definir esquemas
conceptuales, definir vistas, manipular datos y definir su almacenamiento.
Un ejemplo representativo es el Lenguaje de BD relacionales SQL, que representa una
combinación de DDL, VDL, DML, y SDL.
• Interfaces de SGBD
Entre las interfaces amables con el usuario que pueden ofrecer los SGBD están las siguientes:
- Interfaces basadas en menús, las cuales presentan al usuario listas de opciones llamadas
menús, que guían al usuario para formular solicitudes. Los menúes hacen innecesario
memorizar las órdenes y la sintaxis específicas de un lenguaje de consulta, pues permiten
construir la solicitud paso por paso eligiendo las opciones de los menús que el sistema
presenta.
13
- Interfaces gráficas: suelen presentar al usuario los esquemas en forma de diagrama, y éste
puede entonces especificar una consulta manipulando el diagrama. Casi todas estas
interfaces se valen de un dispositivo apuntador, como el ratón para escoger ciertas partes
del diagrama de esquemas que se exhibe.
- Interfaces basadas en formas: presentan una forma para cada usuario. Este puede
entonces llenar todos los espacios de la forma para insertar datos nuevos, o bien llenar sólo
ciertos espacios, en cuyo caso el SGBD obtendrá los registros que coincidan con los datos
especificados.
- Interfaces de lenguaje natural: estas interfaces aceptan solicitudes escritas en inglés o en
algún otro idioma e intentan “entenderlas”. Suelen tener su propio esquema, similar al
esquema conceptual de la BD. La interfaz consulta las palabras de su esquema, y también
un conjunto de palabras estándar, para interpretar la solicitud. Si la interpretación tiene
éxito, la interfaz genera una consulta de alto nivel que corresponde a la solicitud en
lenguaje natural y la envía al SGBD para su procesamiento, en caso contrario, se inicia un
diálogo con el usuario para esclarecer la solicitud.
- Interfaz para usuarios paramétricos: los usuarios paramétricos a menudo tienen un
conjunto pequeño de operaciones que deben realizar repetidamente. Casi siempre se incluye
un conjunto reducido de ordenes abreviadas, con el fin de reducir al mínimo el número de
digitaciones. Con esto el usuario paramétrico puede trabajar con el menor número de
digitaciones posible.
 Clasificación de los SGBD:
El principal criterio que suele utilizarse para clasificar los SGBD es el modelo de datos en que se
basan.
Los SGBD se clasifican como:
- Relacionales
- De Red
- Jerárquicos
- Orientados a Objetos
- Otros
Un segundo criterio para clasificar los SGBD, es el número de usuarios a los que da servicio el
Sistema.
- Los Sistemas monousuario solo atiende a un usuario a la vez
- Los Sistemas multiusuario atienden a varios usuarios al mismo tiempo
Un tercer criterio es el número de sitios en los que está distribuida la BD, se clasifican en:
- Centralizados, es decir sus datos se almacenan en un solo computador.
- Descentralizados
Los SGBD pueden atender a varios usuarios pero el SGBD y la BD real y el software del SGBD
pueden estar distribuidos en varios sitios, conectados por una red de computadoras.
El modelo de datos relacional representa una BD como una colección de tablas, cada una de las cuales
se puede almacenar en forma de archivo individual.
El modelo de datos de Red representa los datos como tipos de registros y también represena un tipo
limitado de vínculos 1:N, llamado tipo de conjunto.
El modelo Jerárquico representa los datos como estructuras jerárquicas de árbol. Cada jerarquía
representa varios registros relacionados entre sí.
14
El modelo orientado a objetos define una BD en término de objetos, sus propiedades y sus
operaciones. Los objetos con la misma estructura y comportamiento pertenecen a una clase, y las
clases se organizan en jerarquías o grafos acíclicos. Las operaciones de cada clase se especifican en
términos de procedimientos predefinidos llamados métodos.
15
 UNIDAD Nº 3 : MODELO RELACIONAL
Modelo de representación:
• MODELO RELACIONAL:
 Conceptos Básicos:
Un Sistema es relacional si:
- La información se muestra a los usuarios como tablas de datos.

- Los operadores de acceso a los datos generan tablas como datos de salida a partir de tablas
como datos de entrada.
- La característica fundamental del modelo relacional es el formalismo matemático de
definición que proporciona un entorno relacional y la sencillez de sus operadores de
definición y la información.
- El modelo relacional define cómo se deberán diseñar los tres niveles de la arquitectura de
una BD.
 Elementos de un Modelo Relacional:
El modelo relacional se define a través de los elementos que lo forman. Podemos distinguir tres
tipos de elementos dentro del modelo.
- Elementos Estructurales: definen las estructuras de datos que soporta el modelo.

- Elementos Manipuladores: definen los operadores capaces de acceder y de modificar los
datos en una BD.
- Elementos Semánticos: definen un conjunto de restricciones y reglas de integridad que
deberán cumplir los datos.
a) Elementos estructurales:
La estructura fundamental de datos es una RELACIÓN que no es más que una tabla estructurada y
ordenada de datos.
Cada una de las filas de la relación se denomina TUPLA y representa a un determinado concepto u
objeto perteneciente al entorno de datos en uso.
Cada columna de la tabla se denomina ATRIBUTO y representa una propiedad que caracteriza a
cada objeto del entorno.
A1 A2 ... ... An
La estructura es una relación, es una tabla plana de doble entrada, en donde las filas se denominan
tuplas y las columnas atributos.
Los atributos son monovaluados y simples. Que sean monovaluados quiere decir que pueden
tomar un único valor (ej. Un solo color) y que sean simples quiere decir que tienen valores atómicos.
16
DNI Apellido Nombre Edad Puesto
laboral
32132055 Escobar Romina 20 Director
30256421 López Jorge 22 Ingeniero
35042126 Morales Carlos 25 Secretario
tuplas
atributo
Esta tabla o relación representa al conjunto de empleados de una empresa. Cada fila de la tabla
se corresponde con un empleado y cada columna con una característica de los empleados.
El número de atributos define el grado de una relación.

La cardinalidad de una relación está dada por el número de tuplas.
El nombre de la tabla R(A1, A2, ..., An), representa el esquema de relación
R = EMPLEADO
* Nro. Leg. DNI Apellido Nombre Fecha Nac.

100
101
102
200
Grado = 5, Cardinalidad = 4.
Los atributos toman valores de un dominio definido para ese atributo.

El dominio debe estar definido.
Habrá tantas tuplas como empleados.
La relación es un subconjunto de un producto cartesiano de una serie de conjuntos

denominados DOMINIOS. A cada uso particular de un dominio en una relación se le denomina
ATRIBUTO que, se corresponde con una característica o propiedad de un determinado objeto que se
pretende representar. Los valores permitidos para cada atributo son los que constituyen su dominio.
En el ejemplo el dominio del atributo DNI estaría formado por todos los números de DNI
válidos. Como cada atributo sólo puede tomar valores dentro de su dominio, la relación se puede
definir como:
r es un subconjunto del producto cartesiano (combinaciones posibles) de una serie de conjuntos
denominado dominio.
r ⊆ Dom(A1) x Dom(A2) x ... x Dom(An)

siendo r la relación y A1, A2, ..., An los atributos.
r = estado de la relación = conjunto de tuplas de la relación.
Una BD relacional consta en general de varias relaciones.

Una relación básica se define con independencia de las demás relaciones.
Una relación derivada se define como resultado de efectuar ciertas operaciones sobre otras
relaciones, básicas o derivadas.
Una tupla ti es una transformación de R a D, siendo D = a la unión con el dominio A1, unión
dominio A2, en general con el dominio An.
D = Dom(A1) U dom(A2) U ... U dom (An)
Las tuplas no necesariamente deben estar ordenadas, pero cuando se hace la implementación si,
de acuerdo a la clave que se elija.
17
b) Elementos semánticos:
Tiene que ver con el significado que tienen los datos. Están formados por las Dependencias entre
datos y por un conjunto de restricciones semánticas. Estos elementos proporcionan un mayor
contenido semántico a la relación, principalmente las dependencias de datos, al definir una serie de
restricciones existentes entre los datos que forman una relación.
 Dependencia funcional
 Restricciones de Integridad
El elemento semántico de mayor importancia del modelo relacional es la dependencia funcional.
Dependencias funcionales:
Una dependencia funcional es una sentencia de la forma X Y, que se lee “X implica Y”, o “Y
depende de X”, siendo X e Y subconjuntos del conjunto de atributos de la relación en la que se
incluyen las dependencias funcionales, llamados descriptores.
Si una dependencia funcional se cumple para una relación r, quiere decir que, independientemente
de las tuplas existentes en r, en un momento determinado, el valor de X determina unívocamente el
valor de Y. O dicho de otro modo, a cada valor de X le corresponde un único valor de Y.
Nro. Legajo dni/apell/nom/fnac/cod.dpto.

100 20.000.000
Apellido nombre
Apellido no determina el nombre
dni leg/apell/nom/fnac/cod.dpto.
El determinante puede no ser clave.
Nro. Legajo dni/apell/nom/cod.ciud./provincia
(fig. 1)
laboral
(fig. 2)
laboral
En el ejemplo de la fig. 1, si se determina que la dependencia funcional dni nombre, es

cierta. En cambio las tuplas de la fig. 2 no serían tuplas válidas, ya que a un mismo valor de dni le
corresponden dos valores distintos de nombre.
Las dependencias funcionales dependen intrínsecamente del significado de los atributos.
18
Las dependencias funcionales no se pueden interpretar como funciones, sino como restricciones
entre datos.
La dependencia dni edad, no se puede leer como “a partir del dni se obtiene la edad”,
sino que se debe interpretar exclusivamente como “para un valor de dni solo existe una edad asociada”
o “cada dni representa una sola persona y por lo tanto una sola edad”.
Esquema de Relación:
Esquema de relación es un par ordenado R(T,L), donde T es el conjunto de atributos y L es el

conjunto de dependencias funcionales.
T = nroleg/ ..... /fnac/coddpto.

El esquema de relación se debe mantener estable.
El conjunto de dependencias funcionales L, forma con el conjunto de atributos de una relación T,

un par llamado esquema de relación R(T,L).
Este esquema de relación define la estructura de cualquier tabla de datos definida sobre los mismos
atributos.
Una parte fundamental del proceso de construcción de una BD relacional es la determinación de su
esquema relacional. Sin embargo, resulta más conveniente obtener directamente el esquema relacional
a partir del estudio de necesidades que puedan existir en cada caso.
Se trata, en definitiva, de obtener el conjunto de atributos suficiente en cada entorno mediante una
serie de entrevistas con los usuarios y directivos de ese entorno. Posteriormente se obtendrá el
conjunto de dependencias funcionales analizando las restricciones existentes entre los atributos.
Conceptos relacionados con las dependencias funcionales:
A partir de un conjunto de dependencias funcionales se pueden deducir otras dependencias, las que
permiten deducir unas dependencias a partir de otras se denominan Axiomas y son las siguientes.
• Axioma de Reflexividad: V X, X Y
• Axioma de Aumentatividad: Si X Y, X’ Y V X’ ⊇ X
• Axioma de Proyectividad: Si X Y, X Y’ V Y’ ⊇ Y
• Axioma de Aditividad: Si X Y, U W entonces X U V YUW
• Axioma de Transitividad: Si X Y, Y Z entonces X Z
X y Y’ son subconjuntos de los atributos.
Un conjunto de dependencias inicial L, junto con todas las dependencias que de él se deducen,
por la aplicación de los Axiomas de Ammstrong se denomina cierre de L y se representa por L+.
Ej. Establecer una relación con las dependencias funcionales.
R = AUTOMOTOR
T= Pat, Tit, Marca, Mod, Color
L= Pat Titular/Marca/Mod/Color
19
Restricciones de Integridad:
Se pueden definir dos restricciones semánticas de integridad, que se deberán cumplir en

cualquier esquema de relación y, por lo tanto en cualquier BD relacional.
Se trata de dos restricciones que no dependen de la semántica de los atributos a los que afectan,
tratándose más bien de restricciones estructurales necesarias para el buen funcionamiento de toda BD
relacional.
Estas restricciones son:
- Restricciones de dominio o de integridad de entidad: ningún valor de la clave primaria de

una relación puede ser desconocido o tener algún componente desconocido. Es decir el
valor de cada atributo debe ser un valor extraído del dominio de valores definidos para ese
atributo. Debe además ser un valor atómico.
- Restricciones de integridad referencial: supongamos que un atributo a de una clave primaria
compuesta (con más de un atributo) de una relación r está definido sobre un dominio
primario. En este caso para cada valor “a” de A en r tiene que existir una relación básica
con clave primaria simple B, tal que “a” ocurre como un valor de B en S. Se especifica
entre dos relaciones y sirve para mantener la consistencia entre tuplas de las dos relaciones.
Establece que una tupla de una relación que haga referencia a otra relación deberá referirse
a una tupla existente en esa relación (clave externa).
superclave
Ejemplo:
EMPLEADO Nro. Leg. Nom, Apell. Fnac. Cod.Dpto.
100 Juan Pérez 5/1 0A

200 Pedro Ger 7/4 0A
...
...
600 Ana López 7/11 0B
Super clave: cada tupla es ≠ de las demás. O sea que la tupla
T1 {nro-leg, nom, apell, fnac, cd} ≠ T2 {nro-leg, nom, apell, fnac, cd}
T1 {nro-leg} ≠ T2 {nro-leg} siendo nro-leg la clave
Superclave
Ejemplo:
Cod.art. Color Talle Cant.

100 rojo 1 20
100 rojo 2 25
100 rojo 3 10
100 blanco 1
Ejemplo:

laboral
20
En este ejemplo, al ser DNI la única clave, será la clave primaria, y además es simple. Por lo
tanto, de acuerdo a la restricción de integridad de entidad, no podrá existir ninguna fila en la tabla con
valor desconocido para el atributo DNI.
Para ejemplificar la restricción de integridad referencial se necesita plantear una situación
ligeramente más compleja. Imagínese una BD que almacena todos los hombres y mujeres de una
determinada organización, así como las parejas establecidas entre ellos. Una posible representación en
la BD se realizaría a través de tres tablas o relaciones. Una para los hombres, cuya clave sería el DNI
(DNI-H), otra para las mujeres, cuya clave sería también su DNI (DNI-M), y otra tabla para
representar a los matrimonios, que almacenaría los DNI correspondientes a cada pareja, como se
muestra en la sig. Figura
DNI-H DNI-M
1723 4567
1934 2345
En esta tabla se pueden observar los datos correspondientes a dos parejas, la primera de las
cuales estaría formada por las personas con DNI 1723 y 4567.
Para este ejemplo, aplicando la definición de integridad referencial, se obtendría la siguiente
situación. La tabla de matrimonios estaría formada por los dos atributos que la integran DNI-H y DNI-
M.
Se tiene una clave primaria compuesta, donde cualquiera de los atributos, por ejemplo DNI-H
(equivale al A de la definición), está definido sobre un dominio primario, al ser clave simple (B) de la
tabla de hombres (s). Por tanto, todo valor de atributo DNI-H, tiene que aparecer en la tabla Hombres
como un valor del atributo DNI-H en esa tabla.
Esto parece lógico, si se piensa que no se podría definir un matrimonio si previamente no
hemos definido sus integrantes.
Restricciones de integridad:
• El valor de una clave primaria no puede ser nulo.

• Restricción de entidad referencial se especifica entre dos relaciones y sirve para tener consistencia
entre tuplas de ambas relaciones.
 Formas de modelizar vínculos binarios en el Modelo Relacional:
Incondicional.
A B
1:1
Cómo se representa?
Esposo Esposa
dni-esposo dni-esposa
... ...
... dni-esposo
21
Atributo de vinculación o clave externa. Se puede poner en cualquiera de las dos.
10.000.000 20.000.000
Juan ...
... ...
... 10.000.000
A B
1:M
La clave externa va en el lado muchos.
DUEÑO AUTOS
dni 10.000.000 nro.-pat.
nom modelo
apell color
... dni 10.000.000
A B
M:N
En este caso no se puede representar la relación muchos a muchos. Lo que se hace es reducir el vínculo
en dos relaciones 1:M y crear una nueva relación.
PROFESOR MATERIAS
*nro.leg. *cod.mat.
nombre nom.mat.
apell. ...
domic. nro.leg.
CATEDRA relación asociada o

*nro.leg tabla de correlación
*cod.mat.
dia datos de
hora intersección
22
10 Algebra 100 A
Juan Análisis I 101 B
Pérez Análisis II 102 C
10
Algebra 20
30
tuplas
10 10 10
100-A 101-B 102-C
estos datos se denominan datos de intersección.
Ver como se modelizan los 4 condicionales y los 3 bicondicionales.
Hemos visto:
- Elementos estructurales
- Elementos semánticos
- Elementos de manipulación
- Elementos semánticos:
• Restricciones de dominio
• Restricciones en la clave
• Integridad de entidades
• Integridad referencial
La restricción referencial establece que una tupla de una relación que haga referencia a otra
relación deberá referirse a una tupla existente en la misma.
Para dar una definición más formal de integridad referencial, debemos definir primero el
concepto de Clave Externa. Las condiciones que debe satisfacer una clave externa especifican una
restricción de integridad referencial entre dos esquemas de relación R1 y R2.
Se utiliza entonces el concepto de clave externa que es el atributo de vinculación.
Si existe una vinculación entre dos relaciones R1 y R2, el conjunto de atributos CE en R1 es
una clave externa de R1 si satisface:
1º Los atributos CE tienen el mismo dominio de la clave primaria CP de otra relación R2; se
dice que los atributos CE hacen referencia o se refieren a la relación R2.
2º Un valor de CE en una tupla t1 del estado actual r1(R1) coincide con un valor de CP en
alguna tupla t2 del estado actual r2(R2), o bien es nulo. En el primer caso t1{CE} = t2 {CP} y decimos
que la tupla t1 hace referencia a la tupla t2.
Una clave externa puede hacer referencia a su propia relación.
DEPARTAMENTO (cod.dpto., denom, ...)
EMPLEADOS (nro.leg., nom, ape, ..., cod.dpto.)

AV o CE
EMPLEADOS (nro.leg., nom, ape, ..., nro.leg.sup.)
Modelización de los condicionales:
23
1:1c ASIENTO PASAJERO
*codas *codpas
... ...
codas (CE)
1:Mc CLIENTES PRESTAMOS

*codcli *codpre
dni monto
ape ...
codcli (CE)
1c:M DEPARTAMENTO C EMPLEADO

*coddep *codemp
... ...
en este caso creamos otro atributo

DPTO-EMP. relación o tabla de correlación
*coddep
*codemp
Otros
Mc:Nc PROFESOR c MATERIA c

*nroleg *codmat
... ...
... ...
PROF-MAT
*nroleg
*codmat
categoría dato de intersección
c) Elementos de manipulación:
Son los elementos manipuladores de la información, es decir los operadores que dan acceso a la
información contenida en la BD. Son los operadores que permiten el acceso a la información
contenida en la BD.
El modelo relacional define un conjunto de operadores que forman el álgebra relacional.
Esta Algebra permite la realización de cualquier acceso a la información contenida en la BD. Los
operadores de esta Algebra, denominados operadores relacionales, toman como entrada una o más
relaciones y proporcionan como resultado otra relación.
Los operadores binarios surgen de la Teoría de Conjuntos
 UNIÓN:
La unión toma dos relaciones R y S como entradas y obtiene como resultado una única relación
denominada R U S constituida por el conjunto de tuplas que pertenecen a R, a S o a ambas. Solo se
aplica a relaciones del mismo grado y definidas sobre los mismos atributos, relaciones que tienen la
misma cabecera, que además será la de la relación unión.
R U S es una relación que incluye todas las tuplas de R y todas las tuplas de S. R y S deben tener
definidos sus atributos en el mismo dominio.
R (A1, A2, ..., An)
24
S (B1, B2, ..., Bn)
Dom (A1) = Dom (B1)
Dom (A2) = Dom (B2)
...
...
Dom (An) = Dom (Bn)
R y S se definen sobre la misma cabecera.
R S RUS
A B C A B C A B C
1 2 3
1 2 3 3 5 8
4 5 6
4 5 6 1 2 3
9 5 1
9 5 1 3 5 8
 INTERSECCIÓN:
R ∩ S es una relación que incluye las tuplas que están tanto en R como en S.
R S R∩S
A B C A B C A B C
1 2 3 1 2 3
3 5 8
4 5 6 1 2 3
9 5 1
 DIFERENCIA:
R – S es una relación que incluye todas las tuplas que están en R pero no en S.
R S R-S
A B C A B C A B C
1 2 3 3 5 8 4 5 6
9 5 1
4 5 6 1 2 3
9 5 1
25
 PRODUCTO CARTESIANO:
R x S es una operación binaria donde R y S no necesitan ser compatibles. Se usa para combinar
tuplas de 2 relaciones. R x S se define como una relación de grado m+n constituida por todas las
combinaciones de tuplas de R y S, es decir, por todas las tuplas de grado m+n en las que los
primeros m valores coinciden con una tupla de R y los n últimos con una tupla de S. Se asume que
al menos un atributo es común entre R y S.
R S RxS
A B C C D A B CR CS D
7 2 3 3 8 7 2 3 3 8
4 1 8 1 4 7 2 3 1 4
8 5 1 4 1 8 3 8
4 1 8 1 4
8 5 1 3 8
8 5 1 1 4
Operaciones relacionales:
 SELECCIÓN:
Sea R una relación y F una fórmula que puede incluir los siguientes elementos:
• Operandos que son nombres de atributos de la relación R.
• Operadores aritméticos de comparación (<, >, =)
• Operadores lógicos (and, or, not)
La selección de la relación R en función de la fórmula F, ϑ F(R) es el conjunto de tuplas de R que

cumplen la fórmula F. Por lo tanto la selección, al contrario de la proyección, modifica el número de
tuplas de R pero no su cabecera. Se representan como ϑ F(R) = conjunto de tuplas de R que satisfacen
la fórmula F.
Ejemplo: dada la relación R se tratará de seleccionar las tuplas de R que tienen en el atributo A un
valor superior a 4 y en el atributo D un valor inferior a 8.
R ϑ (A>4, D<8)
R
A B C D A B C D
7 2 3 4 7 2 3 4
4 1 6 9 8 5 1 0
2 6 8 3
8 5 1 0
Otro ejemplo
26
EMPLEADO
Apellido Nombre Salario Año Ingreso
Pérez Carlos 1.000 94
Azar Juan 2.000 95
Vera José 1.500 95
Sánchez Manuel 1.800 93
F = salario < 2.000 and Año Ingreso < 95
ϑ (EMPLEADOS)
salario < 2.000 and año ingreso < 95
Pérez Carlos 1.000 94

Sánchez Manuel 1.800 93
 PROYECCIÓN:
La proyección de una relación R sobre un descriptor (conjunto de atributos) X ∏ x(R), donde R es una
relación definida sobre un conjunto de atributos T y X ⊆ T, es una relación constituida por las columnas
de R correspondientes a los atributos de X. Por lo tanto, la proyección es un operador que no cambia el
número de tuplas de la relación resultado, eliminando simplemente algunos atributos de la relación
inicial. Junto con el operador de selección forman el grupo de operadores más genuinamente
relacionales.
Si definimos ∏ apellido, nombre, ingreso(EMPLEADOS), la resultante será:
Pérez Carlos 94
Azar Juan 95
Vera José 95
Sánchez Manuel 93
 UNIÓN NATURAL:
También llamada reunión, o JOIN, la unión natural de R y S, R*S se utiliza para combinar tuplas
relacionadas de dos relaciones en una única relación.
R de grado m
S de grado n
Definidas sobre un conjunto de atributos cuya intersección es no vacía, la unión natural R*S es una
relación de grado m+n que tiene una tupla por cada combinación de tuplas de R y de S, siempre que la
combinación satisfaga la condición de reunión.
La unión natural se calcula del siguiente modo:
1) Se calcula el producto cartesiano RxS. Los atributos a comunes a R y a S se diferencian en la

cabecera de RxS denotándolos como AR y AS.
2) Para cada atributo A perteneciente a TR ∩ TS se seleccionan las filas en las que el valor de AR
coincide con el valor de AS.
3) Realizada la selección, eliminar las columnas correspondientes a los atributos AS.
Ejemplo:
Sean R y S
27
R
S
A B C
C D
7 2 3
3 8
4 1 8
1 4
8 5 1
Primero calculo RxS
RxS
A B CR CS D
7 2 3 3 8
7 2 3 1 4
4 1 8 3 8
4 1 8 1 4
8 5 1 3 8
8 5 1 1 4
Luego selecciono las tuplas donde los valores de los atributos CR y CS coincidan.
RxS
A B CR CS D
7 2 3 3 8
Eliminamos los atributos CS
R*S
A B C D
7 2 3 8
28
 UNIDAD Nº 4: NORMALIZACIÓN
Conceptos introductorios:
La teoría de la normalización tiene como fundamento el concepto de formas normales. Se dice

que una relación esta en una determinada forma normal si satisface un cierto conjunto de restricciones.
Es una técnica introducida por un autor llamado Codd cuya finalidad es permitir trabajar con
estructuras de datos eficientes.
Una estructura de datos es eficiente:
- Cuando no existen dependencias de inserción, eliminación o modificación entre los datos
de la estructura.
- Cuando no existe redundancia.
- Cuando se reduce la necesidad de reestructuración de la base de datos ante la inclusión de
nuevos datos.
Procedimiento de Normalización:
La normalización de los datos puede considerarse como un proceso durante el cual los
esquemas de relación insatisfactorios se descomponen repartiendo sus atributos entre esquemas de
relación más pequeños que poseen propiedades deseables.
Un objetivo del proceso de normalización es garantizar que no ocurran las anomalías de

actualización.
Las formas normales proveen a los diseñadores de BD lo siguiente:
- Un marco formal para analizar los esquemas de relación con base en sus claves y en las
dependencias funcionales entre sus atributos.
- Una serie de pruebas que pueden efectuarse sobre esquemas de relación individuales de
modo que la BD relacional pueda normalizarse hasta el grado deseado. Cuando una prueba
falla, la relación que provoca el fallo debe descomponerse en relaciones que
individualmente satisfagan las pruebas de normalización.
Los diseñadores de BD no deben normalizar hasta la FN más alta posible. Las relaciones
pueden dejarse en FN inferiores por razones de rendimiento.
EMPLEADO
NombreE NSS FechaNac Dirección NumD
CP CE
DEPARTAMENTO
NombreD NumD NSSGteD
CP CE
EMP-DEPTO
NombreE NSS FechaNac Dirección NumD NombreD NSSGteD
Silva, José 12345 ... ... 5 Investig 33344
Vizcarra, Federico 33344 ... ... 5 Investig 33344
Zapata, Alicia 99988 ... ... 4 Administ 98765
Valdéz, Jazmín 98755 ... ... 4 Administ 98765
Nieto, Ramón 66688 ... ... 5 Investig 33344
Si una consulta requiere información relativa al departamento de un simple conjunto con los
atributos del empleado, el esquema EMP-DEPTO, puede servir como relación base (aún con las
anomalías de actualización).
29
Es el proceso con el cual una relación en cierta forma normal (ej. 2FN) se puede convertir en
un conjunto de relaciones en una forma más deseable (ej. 3FN). Este proceso es reversible porque
siempre es posible tomar la salida del proceso (por ejemplo el conjunto de relaciones en 3FN) y
convertirlo otra vez en la entrada (relación en 2FN por ejemplo).
Esa reversibilidad es importante porque significa que no se pierde información durante el
proceso de normalización.
La normalización es útil para el proceso de diseño de BD. La idea general de normalización es
que el diseñador de la BD deberá poner su mira en relaciones en forma normal “final” (3FN). Sin
embargo en ocasiones hay buenas razones para descartar los principios de normalización. El
requerimiento rígido es que las relaciones estén por lo menos en 1FN.
Esta técnica comenzó a usarse con BD relacionales, pero se puede trabajar con otras.
Tomamos como base 3 formas normales que se llaman:
- Primera forma normal 1FN
- Segunda forma normal 2FN
- Tercera forma normal 3FN
La aplicación de la 2FN supone la aplicación primero de la 1FN, y la 3FN de la 2FN.
Vemos las formas normales con un ejemplo
FACTURA (nrofac, fecha, codprov, nomprov, direcprov, monto, productos: codp, desc, cant, precio)
El problema en este caso que no es una tabla plana. Tiene datos multivaluados.
PRODUCTO
nro.fac. ... 1 2 5 9
Se debe hacer lo siguiente:
nro.fac. producto
100 1
100 2
100 5
100 9
Ahora no tiene datos multivaluados, es una tabla plana pero existe redundancia.
UNA RELACIÓN ESTA EN 1FN si no contiene items repetitivos y los dominios de todos sus
atributos son simples y contienen valores atómicos.
FACTURA (nro.fac., fecha, codprov, nomprov, direcprov, monto)

FACT-PROD (nro.fac., cod.prod, desc, cant, precio)
Ya está en 1FN, pero que pasa ahora?

100 1 yerba 10 3
100 2 azúcar 5 2,5
100 3 leche 10 2
200 1 yerba 8 3
300 1 yerba 5 3
500 1 yerba 10 3
500 4 te 5 2
30
Hay mucha redundancia. Si tengo que dar de baja 500, borro la información del producto, esto es por
la dependencia de inserción, eliminación, etc.
PRIMERA FORMA NORMAL: Una relación está en 1FN si incluye solo valores atómicos (simples,
indivisibles) y que el valor de cualquier atributo en una tupla es un valor individual proveniente del
dominio de ese atributo.
Así la 1FN prohibe tener conjuntos de valores, una tupla de valores o una combinación de
ambos como valor de un atributo para una tupla individual. Prohibe las “relaciones dentro de
relaciones” o las “relaciones como atributo de tuplas”.
Ejemplos:
- Cuando uno de los atributos es un conjunto de valores:
DEPARTAMENTO (NomD/NumD/NSSGteD/LugaresD)
El dominio de LugaresD contiene conjuntos de valores, porque cada departamento puede tener varios
lugares, entonces no está en 1FN. Para normalizar sería:
DEPARTAMENTO (NomD/NumD/NSSGteD) se quita el atributo LugaresD y se lo descompone en:

LUGARES-DEPTOS (NumD/LugarD)
- Cuando un atributo es un atributo compuesto que por si mismo es multivaluado. Este tipo
de atributos se denominan relaciones anidadas porque cada tupla puede tener una relación
dentro de sí.
EMP-PROY (NSS/NomE/Proy:(NumP/Horas))
Proy, es un atributo multivaluado, es una relación dentro de otra relación, entonces EMP-PROY no
está en 1FN.
NSS es la clave primaria de EMP-PROY y NumP es la clave primaria parcial de cada relación anidada,
es decir que en cada tupla, la relación anidada debe tener valores únicos de NumP. Para normalizar
hacemos:
EMP-PROY (Nss/NomE)
EMP-PROY1(NSS/NumP/Horas)
Se pasan los atributos de la relación anidada a otra relación. La clave primaria de la nueva relación
combinaría la clave parcial con la clave primaria original.
UNA RELACIÓN ESTA EN 2FN si y solo si está en 1FN y todo atributo no primo de dicha relación
depende funcionalmente de manera total de la clave primaria de la relación.
Dependencia Funcional:
Dada una relación R y siendo X e Y subconjuntos del conjunto de atributos de R, se dice que el
atributo Y de R depende funcionamente del atributo X de R (X Y), si y solo sí:
- el valor de X determina unívocamente el valor de Y;

- a cada valor de X le corresponde sólo un valor de Y, no siendo posible que el mismo valor
de X aparezca en dos tuplas con dos valores distintos de Y.
- Un solo valor Y de R está asociado a cada valor X en R y los atributos X e Y pueden ser
compuestos.
En otras palabras, una dependencia funcional de la forma X Y, es total si la eliminación de

cualquier atributo A de X hace que la dependencia deje de ser válida.
31
X
nro.fact, cod.prod. descripción

cantidad
A A precio
100 1 yerba
200 1 yerba
en este caso la dependencia es solo de una parte de la clave, ya que descripción, cantidad y precio
dependen de cod.prod.
PROD (cod.prod, desc, precio)
FACT-PROD (nro.fac, cod.prod, cant)
Vemos otro ejemplo de dependencia funcional.
Ejemplo: si se determina la dependencia funcional DNI Nombre, las tuplas de la siguiente tabla
no serían válidas
DNI Apellido Nombre

32132055 Escobar Romina
32132055 López Jorge
Si el atributo X es una clave candidata de R (en particular si es clave primaria), entonces todos los
atributos Y de R deben por fuerza depender funcionalmente de X.
Dada una relación R, el atributo Y de R depende funcionalmente del atributo X de R si y solo sí,
siempre que dos tuplas de R concuerden en su valor de X, deben por fuerza concordar en su
valor de Y.
Aplicamos la 2FN cuando la relación ya está en 1FN y tiene clave doble. Si tiene clave simple
no aplicamos 2FN porque ya está en 2FN.
Los atributos no primos, es decir los que no son parte de la clave, dependen de la clave
completa.
FACTURA PROD
FACT-PRODUCTO
FACTURA
nro.fact. Fecha cod.prov. nom.prov. domic.prov. monto
100 10-11-05 A001 Juan Pérez Salta 285 100
300 05-10-05 A002 Carlos Paz Jujuy 300 800
Si quiero eliminar el nro.fact. 300, no puedo, hay dependencia de eliminación y además

redundancia.
32
SEGUNDA FORMA NORMAL:
Si una entidad está en 1FN y tiene una clave simple, entonces está en 2FN.
Una relación está en 2FN si y sólo sí está en 1FN y todos los atributos no clave dependen por completo
de la clave primaria.
- Un atributo no clave es cualquier atributo que no participa en la clave primaria de la
relación en cuestión.
- Dependencia funcional completa o total: una dependencia funcional X Y es una
dependencia funcional total si la eliminación de cualquier atributo A ∈X, hace que la
dependencia deje de ser válida, es decir para cualquier atributo A ∈ Y, (X – {A}) Y.
- Una dependencia funcional X Y es una dependencia funcional parcial si es posible
eliminar un atributo A ∈X de X y la dependencia sigue siendo válida, es decir para algún A
∈X, (X – {A}) Y.
Ejemplo:
EMP-PROY
NSS Nro.Proy Horas NomE NombreP LugarP
Df1
Df2
Df3
{NSS, Nro.Proy} Horas es una dependencia funcional total porque no se cumple que
NSS Horas ni
Nro.Proy Horas
{NSS, Nro.Proy} NomE es una dependencia funcional parcial porque NSS NomE.
Si un esquema de relación no está en 2FN, se lo puede normalizar a varias relaciones en 2FN en la que
los atributos no clave estén asociados solo a la parte de la clave primaria de la que dependan
funcionalmente de manera total.
Ejemplo: así las dependencias funcionales Df1, Df2 y Df3 originan la descomposición de EMP-PROY
en los tres esquemas de relación EP1, EP2 y EP3.
EP1
NSS Nro.Proy Horas
EP2
NSS NomE
EP3
Nro.Proy NombreP LugarP
PREGUNTA DE EXAMEN ¡!!:
Demuestre con un ejemplo la importancia de trabajar con una relación que NO VIOLA LA 2FN
EMP-PROY (NSS/Nro.Proy/Horas/NomE/NomP/LugarP) viola la 2FN
33
NSS, Nro.Pro Horas
NSS, Nro.Pro NomE; NSS NomE
NSS, Nro.Pro NomP,LugarP; Nro.Proy NomP y Nro.Proy LugarP
EMP-PROY
1234 1 10 Silva, José X Belén
1034 1 20 Estero, José X Belén
2037 1 15 Caceres, Juan X Belén
6001 1 100 Paz, Mario X Belén
Al trabajar con esta relación que viola la 2FN, hay redundancia de datos (para cuatro empleados
distintos se repiten todos los datos del mismo Proyecto).
Además, al presentar las anomalías de actualización: de inserción (si se quiere insertar un nuevo
empleado que aún no pertenece a ningún proyecto, o un nuevo proyecto que aún no tiene empleado),
de eliminación (si se quiere eliminar la tupla de un empleado que es el último empleado de un cierto
proyecto) y de modificación(si se quiere modificar el valor de uno de los atributos de un proyecto
dado, tendrá que actualizar las tuplas de todos loe empleados de ese proyecto).
Luego, es importante trabajar con relaciones que no violen la 2FN.
El proceso de reducción de 1FN a 2FN consiste en sustituir la relación en 1FN por proyecciones
apropiadas (se descompone la relación aplicando el operador de proyección). El conjunto de
proyecciones obtenido es equivalente a la relación original, ya que la relación original se puede
recuperar efectuando la “unión natural” de esas proyecciones, de manera que no se pierde información
con la reducción.
La 3FN se basa en el concepto de dependencia transitoria.
UNA RELACIÓN ESTA EN 3FN si y solo sí está en 2FN y todo atributo no primo es dependiente
no transitivamente de la clave primaria.
A B y B C ⇒ A C
Nro.fact. cod.prov. nom.prov./domic.prov.
Creamos una nueva relación llamada proveedor.
PROVEEDOR (cod.prov., nom.prov., domic.prov.)
FACTURA (nro.fac., fecha, codprov, monto)
Luego la estructura normalizada queda
FACTURA (nro.fac., fecha, codprov, monto)
FACT-PROD (nro.fac., cod.prod, cant.)
PROVEEDOR (cod.prov., nom.prov., domic.prov.)
PROD (cod.prod, desc, precio)
34
FACTURA
PROD
PROVEEDOR FACT-PRODUCTO
Ejercicio:
Dada la siguiente relación, aplique la o las formas normales que sean necesarias para que la misma esté
normalizada.
EMPLEADO (legajo, apellido, nombre, domicilio, proyecto: cod.proy, nom.proy, direct.proy, descrip,
horas.proy)
Considere que un empleado puede trabajar en más de un proyecto.
- Aplico 1FN
EMPLEADO (legajo, apellido, nombre, domicilio)

EMP-PROY (legajo, cod.proy, nom.proy, direct.proy, descrip, horas.proy)
Hay dependencia de inserción y modificación
PROYECTO (cod.proy, nom.proy, direct.proy, descrip, horas.proy)

EMP-PROY (legajo, cod.proy)
EMPLEADO PROYECTO
EMP-PROY
Dependencia Funcional Completa:
Se dice que el atributo Y de la relación R es por “completo” dependiente funcionalmente del

atributo X de la relación R si depende funcionalmente de X y no depende funcionalmente de ningún
subconjunto propio de X.
Es decir que no existe un subconjunto propio de atributos componentes de X tales que Y sea
funcionalmente dependiente de ese subconjunto.
Ejemplo:
• PARTES
cod.part / nom.part. / color.part. / ciudad
• PROV-PARTES
nro.prov / cod.part / cant.
Son dependencias funcionales completas: cod.part nom.part

cod.part. color.part.
(nro.prov, cod.part) cant
35
Si consideramos:
• PROV-PARTES
nro.prov / cod.part / cant. / ciudad
en este caso (nro.prov, cod.part) ciudad de una dependencia funcional pero no es completa
ya que nro.prov ciudad.
Pautas informales de diseño para los esquemas de relaciones:
Se hará un análisis de algunos criterios para distinguir los esquemas de relación buenos y
malos. Son 4 medidas informales de la calidad para el diseño de esquemas de relación. Estas medidas
son:
a) Semántica de los atributos
b) Reducción de los valores redundantes en las tuplas
c) Reducción de los valores nulos en las tuplas
d) Prohibición de tuplas espurias
a) Semántica de los atributos de una relación:

Siempre que agrupemos atributos para formar un esquema de relación, supondremos que hay un
cierto significado asociado a los atributos.
Este significado o semántica, especifica cómo se han de interpretar los valores de los atributos
almacenados en una tupla de la relación.
Dicho de otro modo, qué relación hay entre los valores de los atributos de una tupla. Cuanto más
fácil sea explicar la semántica de la relación, mejor será el diseño del esquema correspondiente.
Ejemplo:
EMPLEADO
CP CE
El significado del esquema de relación EMPLEADO, es muy sencillo. Cada tupla representa un
empleado, con valores para su nombre (NombreE), número de seguro social (NSS), fecha de
nacimiento (FechaNac) y domicilio (Dirección) y para el número de Departamento al que
pertenece (NumD), el cual es una clave externa que representa un vínculo implícito entre
EMPLEADO y DEPARTAMENTO.
DEPARTAMENTO
NombreD NumD NSSGteD LugaresD
CP CE
PROYECTO
NombreP NumP LugarP NumD
CP CE
La semántica de DEPARTAMENTO y la semántica de DEPARTAMENTO y PROYECTO,

también es eficiente, cada tupla de DEPARTAMENTO representa una entidad departamento y
cada tupla PROYECTO, representa una entidad en proyecto.
LUGARES-DEPTOS
NumD LugarD
CE
CP
36
TRABAJA_EN
NSS NumP Horas
CE CE
CP
La semántica de LUGARES-DEPTOS y TRBAJA_EN, es un poco más compleja, cada tupla de
LUGARES-DEPTOS contiene un número de departamento y una de las ubicaciones del departamento.
Cada tupla de TRABAJA_EN contiene el número de seguro social de un empleado, el número de uno
de los proyectos en los que ese empleado trabaja, y el número de horas por semana que el empleado
trabaja en el proyecto.
No obstante ambos esquemas tienen su significado bien definido. LUGARES-DEPTOS representa un
atributo multivaluado de DEPARTAMENTO, en tanto que TRABAJA_EN, representa un vínculo de
M:N entre EMPLEADO y PROYECTO.
La pauta 1 sería diseñar un esquema que sea fácil de explicar su significado.
b) Reducción de valores redundantes en las tuplas y anomalías de actualización:
EMPLEADO
Silva, José 12345 ... ... 5
Vizcarra, Federico 33344 ... ... 5
Zapata, Alicia 99988 ... ... 4
Valdéz, Jazmín 98755 ... ... 4
Nieto, Ramón 66688 ... ... 5
DEPARTAMENTO
NombreD NumD NSSGteD
Investig 5 33344
Administ 4 98765
Direc 1 88866
EMP-DEPTO
Silva, José 12345 ... ... 5 Investig 33344
Vizcarra, Federico 33344 ... ... 5 Investig 33344
Zapata, Alicia 99988 ... ... 4 Administ 98765
Valdéz, Jazmín 98755 ... ... 4 Administ 98765
Nieto, Ramón 66688 ... ... 5 Investig 33344
Uno de los objetivos del diseño es minimizar el espacio de almacenamiento que ocupan las relaciones
base (archivos). La agrupación de archivos en esquemas de relación tiene un efecto significativo sobre
el espacio de almacenamiento.
Por ejemplo, basta con comparar el espacio de almacenamiento utilizado por las relaciones base
EMPLEADO y DEPARTAMENTO con el espacio de la relación base EMP-DEPTO que es el
resultado de la reunión natural entre EMPLEADO y DEPARTAMENTO.
En EMP-DEPTO, los valores de los atributos pertenecientes a un departamento en particular se repiten
para cada empleado que trabaja en ese departamento, en cambio la información de cada departamento
aparece solo una vez en la relación DEPARTAMENTO. Solo el número de departamento se repite en
la relación EMPLEADO, para cada empleado que pertenece al departamento.
El problema grave que surge al emplear relaciones como EMP-DEPTO como relaciones base, es el de
las anomalías de actualización. Estas pueden clasificarse en:
37
- Anomalías de Inserción
- Anomalías de Eliminación
- Anomalías de Modificación
• Anomalías de Inserción:
- Si queremos insertar la tupla de un nuevo empleado en EMP-DEPTO, debemos incluir los
valores de los atributos del departamento al que pertenece o bien nulos (si el empleado no
pertenece a ningún departamento todavía). Para insertar una nueva tupla de un empleado
que pertenece al departamento 5, debemos introducir correctamente los valores del
departamento 5 para que sean congruentes con los valores del departamento 5 en otras
tuplas de EMP-DEPTO. En los esquemas EMPLEADO y DEPARTAMENTO no tenemos
este problema de congruencia ya que solo introduciremos el número de departamento en la
tupla del empleado, todos los demás atributos del departamento 5 se registrarán una sola
vez en la BD de la relación DEPARTAMENTO.
- Sería difícil insertar en la relación EMP-DEPTO un nuevo departamento que todavía no
tenga empleados. La única forma de hacerlo sería colocando valores nulos en los atributos
de empleado y esto es un problema porque el NSS es la clave primaria y se supone que cada
tupla representa a un empleado y no a un departamento.
• Anomalías de Eliminación:
- Si eliminamos de EMP-DEPTO una tupla de empleado que sea el último empleado
perteneciente a un cierto departamento, la información concerniente a ese departamento se
perderá de la BD.
• Anomalías de Modificación:
- En EMP-DEPTO, si alteramos el valor de uno de los atributos de un departamento dado,
debemos actualizar las tuplas de todos los empleados que pertenecen a ese departamento, de
lo contrario, la BD se volverá inconsistente.
Pauta 2: diseñar los esquemas de las relaciones básicas de modo que no haya anomalías de
inserción, eliminación y modificación. Sin embargo hay ocasiones en que es necesario violar esta
pauta para mejorar el rendimiento de ciertas consultas, en ese caso hay que señalarlas con
claridad para que los programas de actualización de BD operen correctamente y no se
produzcan inconsistencias.
c) Valores nulos en las tuplas:
En ocasiones se agrupan muchos atributos para formar una relación “gruesa”. Si muchos de los
atributos no se aplican a todas las tuplas de la relación acabaremos con un gran número de nulos en
las tuplas. Esto puede originar un gran desperdicio de espacio en el nivel de almacenamiento y
posiblemente dificulte el entendimiento del significado de los atributos. Además los nulos pueden
tener múltiples interpretaciones como:
- el atributo no se aplica a esta tupla
- se desconoce el valor del atributo para esta tupla
- el valor se conoce pero está ausente, es decir aún no se ha registrado
38
d) Prohibición de tuplas espurias:
EMP-PROY
1234 1 32 Silva, José PX Belén
1234 2 7 Silva, José PY Sacra
4533 3 40 Nieto, Tomás PZ Higueras
4534 1 20 Estero, José PX Belén
4334 2 30 Estero, José PY Sacra
3334 2 10 Vizgarra, Fer PY Sacra
3334 3 10 Vizgarra, Fer PZ Higueras
LUGARES-EMP
NomE LugarP
Silva, José Belén
Silva, José Sacra
Nieto, Tomás Higueras
Estero, José Belén
Estero, José Sacra
Vizgarra, Fer Sacra
Vizgarra, Fer Higueras
EMP-PROY1
NSS Nro.Proy Horas NombreP LugarP
1234 1 32 PX Belén
1234 2 7 PY Sacra
4533 3 40 PZ Higueras
4534 1 20 PX Belén
4334 2 30 PY Sacra
3334 2 10 PY Sacra
3334 3 10 PZ Higueras
Consideremos los dos esquemas de relación LUGARES-EMP y EMP-PROY1, que podríamos usar en
vez de la relación EMP-PROY. Una tupla de LUGARES-EMP significa que el empleado con el
nombre “NomE” trabaja en algún proyecto ubicado en LugarP.
Una tupla en EMP-PROY1 significa que el empleado con el número de seguro social NSS trabaja
“Horas” por semana en el proyecto cuyo nombre, número y ubicación son: NombreP, Nro.Proy, y
LugarP.
Si EMP-PROY1 y LUGARES-EMP son las relaciones base en vez de EMP-PROY, se produce un

diseño de esquema insatisfactorio porque no es posible recuperar la información contenida
originalmente en EMP-PROY, a partir de EMP-PROY1 y LUGARES-EMP.
Si se aplica una operación unión natural con estas dos relaciones, obtenemos muchas más tuplas
espurias porque representar información errónea que no es válida. Por lo tanto la descomposición de
EMP-PROY en EMP-PROY1 y LUGARES-EMP no es satisfactoria y esto se debe a que LugarP es el
atributo de vinculación entre LUGARES-EMP y EMP-PROY1 y LugarP no es ni clave externa ni
clave primaria en cualquiera de estas dos relaciones.
Ej. Unión natural entre EMP-PROY1 y LUGARES-EMP
EMP-PROY1
39
NSS Nro.Proy Horas NombreP LugarP NomE
1234 1 32 PX Belén Silva, José
*1234 1 32 PX Belén Estero, José
1234 2 7 PY Sacra Silva, José
*1234 2 7 PY Sacra Estero, José
*1234 2 7 PY Sacra Vizgarra, Fer
4533 3 40 PZ Higueras Nieto, Tomás
*4533 3 40 PZ Higueras Vizgarra, Fer
4534 1 20 PX Belén Estero, José
*4534 1 20 PX Belén Vizgarra, Fer
*4334 2 30 PY Sacra Silva, José
4334 2 30 PY Sacra Estero, José
*3334 2 10 PY Sacra Vizgarra, Fer
*4334 2 30 PY Sacra Silva, José
3334 3 10 PY Sacra Vizgarra, Fer
*3334 3 10 PZ Higueras
3334 3 10 PZ Higueras Vizgarra, Fer
* tuplas espurias
TERCERA FORMA NORMAL:
Un esquema de relación está en 3FN si y solo sí está en 2FN y ningún atributo no clave
depende transitivamente de la clave primaria.
Es decir elimina la repetición innecesaria de datos.
Una dependencia funcional X Y en un esquema de relación R, es una dependencia
transitiva si existe un conjunto de atributos Z que no sea un subconjunto de cualquier clave de R y se
cumplen tanto X Z como Z Y.
EMP-DEPTO
La dependencia NSS NSSGteD es transitiva a través de NumD, porque se cumplen las dos
dependencias NSS NumD y NumD NSSGteD, y NumD no es un subconjunto de la
clave de EMP-DEPTO.
La dependencia NSS NombreD también es transitiva a través de NumD.
Para normalizar EMP-DEPTO se descompone en dos esquemas de relación ED1 y ED2 que están en
3FN y representan hechos independientes acerca de las entidades EMLEADOS y
DEPARTAMENTOS. Si se aplica unión natural a ED1 y ED2 se recupera la relación original EMP-
DEPTO.
ED1
ED2
NumD NombreD NSSGteD
40
Las relaciones que violan la 3FN como EMP-DEPTO, se presenta el inconveniente de la redundancia
de datos y la anomalías de actualización. Con ED1 y ED2 ya no existe redundancia ni anomalías de
actualización.
41
 UNIDAD Nº 5: DISEÑO DE BASES DE DATOS
Diseñar la estructura lógica y física de la BD para atender necesidades de información de los

usuarios para un conjunto de aplicaciones.
La función principal del diseñador de sistemas no es crear una estructura de información, sino
explicitar aquella estructura existente implícitamente en la realidad.
Cuando se trata de diseñar una BD, lo que se pretende es modelizar la realidad. Es precisamente la
realidad la que define la BD.
Como una forma de simplificar el manejo de situaciones en un mundo real, esencialmente
complejo, se construyen sistemas o modelos de información.
La Tecnología de BD permite almacenar la información de un modelo en la forma estructurada
requerida por este. Frecuentemente se menciona bajo la denominación BD tanto el “recipiente”
(hardware y software) como el “contenido” de información de la misma. Nuestro propósito es estudiar
la BD desde el punto de vista de su contenido.
Requisitos: Metas:
- Satisfacer requisitos de información

- Proveer estructuración de la BD natural y fácil de entender
- Apoyar de procesamiento, rendimiento, tiempo de respuesta, etc.
Etapas en la implementación de un sistema de información:

1.- Obtención y análisis de requerimientos
2.- Diseño conceptual
a) Diseño del esquema conceptual (modelo de datos de alto nivel)
b) Diseño de transacciones
3.- Elección del SGBD (costos)
4.- Diseño lógico
5.- Diseño físico
6.- Implementación
1.- OBTENCIÓN Y ANÁLISIS DE REQUERIMIENTOS: consiste en identificar las principales áreas

de aplicación y transacciones. En un comercio, compras, ventas, pagos, etc.
Los requerimientos se expresan en Entrada, Proceso, Salida.
Esta etapa es realizada por los expertos, analistas, etc, para hacerlo usan herramientas. Hay una serie
de pautas que se deben cumplir. Una BD forma parte de un proceso de desarrollo de un SI.
DISEÑO IMPLEMENTACIÓN
CONCEPTUAL CONCEPTUAL (3)
Independiente de la Dependiente de la
implementación (1) implementación (SGBD,
computador, etc.)
MODELO
CONCEPTUAL (2)
(1) Independiente de cómo los datos van a ser procesados y de los mecanismos de hardware y software
que se utilizarán para el almacenamiento y tratamiento de los datos.
(2) Compuesto de los siguientes modelos: modelo de datos, modelo de eventos y modelo de
transacciones.
(3) Incluye el diseño e implementación de la BD, los programas, los procedimientos.
42
Diseño conceptual:
Para describir la organización de la información se usan los “mapas” o “esquemas”. Se

distinguen dos niveles de esquemas:
- Esquema conceptual
- Esquema de Implementación
El Modelo conceptual, se describe y formaliza a través del esquema conceptual y la Implementación

conceptual se describe y formaliza a través del Esquema de Implementación.
Los esquemas de implementación describen la organización de la información en la BD.
- Esquema lógico: es el mapa que describe una BD completa
- Subesquema lógico o esquema externo: es el mapa que describe las partes de una BD que
están accesibles para un usuario o un programa de aplicación.
Para describir la organización de la

información, se usa el
DISEÑO CONCEPTUAL ESQUEMA CONCEPTUAL
Se representa
MODELO CONCEPTUAL
Se describe a través de
MAPA DE INFORMACIÓN
Modelo de Datos
Modelo de Transacciones
Modelo de Eventos
IMPLEMENTACIÓN CONCEPTUAL ESQUEMA DE IMPLEMENTACIÓN
Diseño Lógico Esquema Lógico, Subesquema

lógico o esquema externo
Diseño Físico Esquema Físico
DISEÑO CONCEPTUAL:
1.1. MODELO CONCEPTUAL
La construcción del modelo conceptual es una de las etapas más importantes en el diseño del
Sistema de Información de una organización.
En el diseño del modelo conceptual es conveniente partir de un conjunto de “visiones de usuario”
y “visiones de contexto” expresadas en nuestro lenguaje natural (castellano).
El problema principal del diseño conceptual del modelo de datos se encuentra en la identificación
de la entidades, sus atributos, sus vinculaciones, etc.
Para resolverlo se hace uso de visiones de usuario y de visiones de contexto, y del conocimiento
general del diseñador.
Visiones de usuario: es una descripción lógica de la información requerida para contestar una
pregunta, tomar una decisión y/o proveer conocimiento. Un usuario puede tener múltiples visiones y
múltiples usuarios pueden compartir sus visiones.
Visiones de contexto: se refiere a una serie de sentencias que describen a la organización, sus
recursos y su modo de operación. Complementan a las visiones de usuario, aportando
fundamentalmente conocimiento sobre la estructura de datos, ya que explican las vinculaciones entre
los mismos.
43
El Modelo Conceptual involucra tanto aspectos estáticos como dinámicos de la realidad. Se
construye con un propósito preestablecido. Para el logro de ese propósito no es necesaria toda la
información del sistema real, sino solo la parte relevante de ella.
Es justamente el propósito quien controla el proceso de abstracción (selección de la información a
incorporar en el modelo).
En una aplicación, se abstraen aquellos aspectos de la “realidad considerados relevantes y se

ignora el resto”. La realidad es quien define el Modelo Conceptual.
El Modelo Conceptual está compuesto por:

• Modelo de Datos
• Modelo de Eventos
• Modelo de Transacciones
1.2. Modelo de Datos:
Interviene un modelo de datos de alto nivel que manejan conceptos muy parecidos al lenguaje del
usuario, independiente del SGBD para poder interactuar con el usuario y poder ver si se satisfacen sus
necesidades.
El Modelo de Datos captura principalmente los aspectos “estáticos” del Modelo Conceptual,
aunque se ocupa también de algunos aspectos “dinámicos” del mismo.
Los Modelos de Datos pueden ser:
- semánticos
- no semánticos
Modelo de Datos Semántico: reconoce los roles que desempeñan en el sistema real las entidades y
asociaciones.
Modelo de Datos No Semántico: tiene una capacidad limitada de captura de información sobre el
significado de los datos. Reconoce las siguientes clases de objetos en el sistema real.
- entidades y asociaciones
- atributos
- vinculaciones
- valores de atributos
- dominio de valores
1.2.1. Elementos primitivos para la construcción de un Modelo de Datos:

Los elementos primitivos a partir de los que se pueden construir estructuras de mayor nivel en
los Modelos de datos son:
- datos elementales
- vinculaciones
Un dato elemental es la pieza mas elemental de información, no puede ser subdividida en elementos
más pequeños sin perder su significado para los usuarios. No es de gran utilidad por si solo. Es útil
solo cuando está “vinculado” con otros datos elementales.
Un dato o elemento de información tiene sentido en la medida en que se relaciona con un objeto
calificándolo o especificándolo. No se puede concebir información independiente de un objeto. El
conjunto de información relacionada con un objeto está definida por una serie de atributos, cada uno
con un determinado valor. Genéricamente se llama entidad a una familia de objetos con los mismos
atributos, no necesariamente con el mismo valor.
ENTIDADES: es algo sobre lo que nos interesa obtener y almacenar información. Pueden ser tangibles
o intangibles. Ej. Clientes, proveedores, ordenes de compra, etc.
44
ATRIBUTOS: son datos elementales de interés para el usuario y forman parte de la entidad. Son
propiedades de la entidad. Los atributos pueden separarse en grupos de acuerdo al rol que desempeñan:
1 – Los que identifican la entidad: Atributos de identificación
2 – Los que describen la entidad: Atributos descriptivos
3 – Los que vinculan entidades: Atributos de vinculación
VALORES DE ATRIBUTOS Y DOMINIOS DE VALORES: un atributo puede tomar un valor de

entre un conjunto de valores posibles que se denomina su dominio de valores.
IDENTIFICADOR ÚNICO: atributo que puede identificar unívocamente a cada miembro de una
entidad. Una entidad puede tener uno, varios (o ningún) identificadores únicos. Si no tiene ninguno se
lo crea artificialmente (Ej. El número de empleado o código de identificación) y recibe el nombre de
“tag” o “etiqueta”. El valor del tag para cada miembro de una entidad puede ser asignado manualmente
o automáticamente por el sistema.
CLAVES: normalmente se usa uno de los identificadores únicos como identificador principal o clave
primaria de la entidad para facilitar la referencia y procesamiento de datos. Cada entidad debe tener
una clave con la cual puedan sus miembros ser identificados. La clave debe poseer dos propiedades:
a) Identificación unívoca: el valor de su clave debe identificar unívocamente
a cada miembro de la entidad.
b) No redundancia: ningún atributo de la clave puede ser desechado sin
destruir la propiedad de identificación unívoca.
CLAVES CANDIDATAS: más de un atributo que cumplen con las propiedades de identificación
única. Conjunto de atributos que cumplen con las propiedades de identificación unívoca y no
redundancia.
VINCULACIONES O RELACIONES: podemos diferenciar dos niveles:

- Vinculaciones entre datos, “dentro” de una entidad (vinculación entre sus atributos)
- Vinculaciones entre entidades, que se establecen mediante atributos de vinculación que
pueden ser de tres tipos: 1:1, 1:M, M:N.
1.3. Relaciones o vinculaciones jerárquicas entre entidades:
Algunas entidades pueden estar vinculadas entre sí conformando una jerarquía. Es posible hablar
entonces de:
a) Entidades primarias o independientes
b) Entidades secundarias o dependientes
• Una entidad dependiente puede tener entidades dependientes de sí (jerarquía de varios niveles).
• Una entidad dependiente no puede existir sin las entidades de mayor nivel jerárquico vinculadas
con ella.
• Una entidad dependiente se vincula con una primaria a través de los atributos de vinculación que
toman valores que se corresponden con valores de identificadores únicos en la entidad superior.
La existencia de vinculaciones jerárquicas es posible establecer:

• Caracterización o agregación
• Clasificación
• Generalización
Y en el caso de entidades dependientes de más de una entidad primaria:
• Clasificación Múltiple
45
• Caracterización Múltiple o Asociación
Caracterización o agregación:
Roles: los miembros de la entidad dependiente caracterizan o describen a los miembros de la entidad
superior. Un miembro de la entidad dependiente se dice que es un componente “part-of” de un
miembro de la entidad superior. Un miembro de la entidad superior se dice que es una composición de
miembros de la entidad dependiente.
Ejemplos: Empleados Cursos
Historia
Materias
laboral
En general, en la entidad dependiente el atributo de vinculación forma parte de la clave porque

la identificación unívoca de un miembro de la entidad dependiente está estrechamente
relacionada con la identificación unívoca del miembro de la entidad superior al que caracteriza.
Otro ejemplo:
padre PROVEEDOR
DJ1 • nro.fact.
hijo cod.proveedor
FACTURA padre importe total
DJ2
• nro.fact. (AV)
hijo • nro.item
ITEMS - FAC cantidad
En una caracterización se dice que los miembros de la entidad dependiente caracterizan a los
miembros de la entidad superior. EL ATRIBUTO DE VINCULACIÓN FORMA PARTE DE LA
CLAVE.
Clasificación:
Esta vinculación enfatiza una propiedad o atributo de la entidad dependiente.

Roles: los miembros de la entidad dependiente son miembros (instance of) de los miembros de la
entidad superior. Un miembro de la entidad superior se dice que es una clasificación de miembros de la
entidad dependiente.
En general, en la entidad dependiente el atributo de vinculación no forma parte de la clave ya que la
identificación unívoca de un miembro de la entidad dependiente es propia. Es decir no depende de la
identificación unívoca del miembro vinculado con la entidad superior.
Ejemplo:
País de origen Fabricantes
Pilotos de
Motores
competición
46
La identificación unívoca de un miembro de la entidad dependiente es propia, es decir, no depende de
la identificación unívoca del miembro vinculado en la entidad superior. Pero para el primer ejemplo, la
clave sería cod.pais (para la entidad superior) y cod.piloto y cod.pais (para la entidad dependiente). Si
bien cod.pais no forma parte de la clave, es un atributo de vinculación, por ello está presente.
País de origen cod.pais
cod.piloto
Pilotos de
...
competición
...
...
cod.pais (AV)
En una clasificación los miembros de la entidad dependientes son instancias de los miembros de la
entidad superior.
Generalización:
La entidad dependiente se dice que es una categoría o especialización de la entidad superior. La

entidad superior es una generalización de las entidades dependientes.
Cada miembro de la entidad dependiente es también miembro de la entidad superior (es una
extensión de ésta).
Las entidades dependientes, si bien tienen distintas propiedades o atributos, heredan las
propiedades o atributos de la entidad superior. La entidad superior representa la unión de las entidades
dependientes.
En la entidad dependiente, el atributo de vinculación constituye el identificador único ya que un

miembro de la entidad dependiente es una extensión de un miembro de la entidad superior. El atributo
de vinculación es la clave.
Ejemplo:
Empleados
Empleados de Empleados fuera Operarios

convenio de convenio
Otro ejemplo:
Persona * dni
Alumno Docentes No Docentes
* dni * dni * dni
El atributo de vinculación es la clave.
47
Clasificación Múltiple: estamos vinculando más de dos entidades. Los atributos de vinculación no
forman parte de la clave de la entidad dependiente. La entidad dependiente tiene un identificador único
propio.
Ejemplo:
* cod.fab. Fabricantes Tipos * tipo
Motores * nro.motor
...
...
tipo (AV)
cod.fab. (AV)
Caracterización Múltiple o Asociación: la entidad dependiente permite caracterizar o describir una

vinculación entre entidades que se asocian para el logro de un fin y recibe el nombre de “asociación”.
Estas entidades son muy importantes en la representación del mundo real. Los atributos de vinculación
concatenados forman la clave de la asociación, pues esta entidad, en general carece de un identificador
único propio.
Las asociaciones son útiles también para representar en una BD las vinculaciones M:N
descomponiéndolas en dos vinculaciones 1:M y 1:N y una nueva entidad (la asociación). En una
asociación cada una de las entidades vinculadas juega un rol específico, fijo y definido en el marco de
la asociación.
Ejemplo:
* cod.prof. Profesor Cursos * cod.curso
Prof-Curso * cod.prof.
* cod.curso
DATOS INTERSECCIÓN: son los atributos de la asociación.
REFERENCIA CRUZADA: Asociación que no contiene datos de intersección.
1.4. Mapa de Información:
Es el esquema conceptual para describir el modelo de datos. Está compuesto por:

• Un diagrama que muestra las entidades y sus vinculaciones
• Una lista por cada entidad que muestra los atributos que la identifican y
los que la describen
• Una lista por cada dominio de valores de los valores que la componen
VISIONES: el problema principal del diseño conceptual del modelo de datos se encuentra en
identificar las entidades, sus atributos, sus vinculaciones, etc. Para resolverlo se hace uso de “visiones
de usuario” y “visiones de contexto” y del conocimiento general del diseñador.
VISIONES DE USUARIO: son los requerimientos de información de los usuarios. Es una descripción
lógica de la información requerida para contestar una pregunta, tomar una decisión y/o proveer
48
conocimiento. Un usuario puede tener múltiples visiones y varios usuarios pueden compartir sus
visiones.
VISIONES DE CONTEXTO: se refiere a una serie de sentencias que describen a la organización, sus
recursos y sus modos de operación. Son un complemento de las visiones de usuario, aportando
fundamentalmente conocimiento sobre la estructura de datos, que explican las vinculaciones entre los
mismos.
FORMA CANÓNICA: es un esquema conceptual de estructura mínima. Tiene la menor cantidad de

entidades, atributos y vínculos que permitan satisfacer las necesidades de información.
Es un modelo de estructura mínima (formado por la menor cantidad posible de entidades) al que se le
han eliminado todas las vinculaciones redundantes entre las entidades que lo componen.
También se han eliminado datos redundantes de manera que ninguna entidad tenga atributos que sean
sumarizaciones de valores de atributos de otras entidades, o que puedan obtenerse contando la cantidad
de miembros de otras entidades.
En la definición anterior, el término entidad incluye también a las asociaciones.
En el diseño conceptual puede ser muy difícil especificar el modelo de datos directamente, en un solo
paso, por lo que es necesario proveer un procedimiento de síntesis que permita llegar en sucesivos
pasos a la forma canónica.
El modelo de datos debe terminarse con un mapa de información en forma canónica.
En todos los casos en que sea posible, debería hacerse una implementación conceptual del modelo de
datos en su forma canónica sin cambios, es decir, igualando el esquema lógico al esquema conceptual.
Ventajas:
1.- Al usuario le resulta completamente natural la estructuración de la información puesto que el
modelo residente en la BD se corresponde exactamente con el mundo real que se quiere representar.
2.- Permite una mayor velocidad de adaptación cuando es necesaria la reestructuración de la
información para responder a los cambios del negocio.
3.- Minimiza la probabilidad de tener que modificar los programas de aplicación.
4.- La mayoría de las BD implementadas inicialmente en forma no canónica, cuando deben ser
ampliadas para contemplar la incorporación de datos adicionales, tienden naturalmente hacia la forma
canónica.
5.- Posibilita el tratamiento relacional de la BD.
Desventajas:
1.- Una relativamente baja perfomance que podría resultar un problema crítico en algunas
aplicaciones.
2.- Debido a problemas de perfomance en sistemas de alta actividad implementados sobre SGBD sin
esquemas físicos, o con esquemas físicos poco desarrollados, algunas veces es necesario implementar
esquemas lógicos no canónicos que se orientan a maximizar la perfomance del sistema.
3.- Cuando se agreguen nuevas aplicaciones sobre la BD, la nueva perfomance global puede no ser la
óptima.
4.- El alejamiento de la forma canónica debe ser controlado, en caso de que sea necesario.
“PARTIENDO DE LAS VISIONES DE USUARIO Y DE CONTEXTO, SE ESTRUCTURA EL

MODELO DE DATOS EN LA FORMA CANÓNICA”
1.5. Modelo de Eventos:
En el mundo real ocurren cambios constantemente (de estados, de niveles, de flujo, etc.).
Se denomina evento a la ocurrencia de un cambio en un punto del tiempo cuando se satisfacen
ciertas condiciones.
49
En un modelo conceptual, un evento se manifiesta como la ocurrencia de un cambio en los valores
de atributos y/o vinculaciones de los miembros de una o más entidades del modelo de datos.
Los eventos determinan el comienzo, el final, o un cambio en las vinculaciones entre miembros de
las entidades.
Los modelos ponen en movimiento acciones y a su vez las acciones producen eventos en el
sistema real. Las acciones pueden ser observar o cambiar los estados del sistema.
El modelo de eventos es una descripción de las cadenas de eventos que ocurren en el sistema real
y que son relevantes para los propósitos del modelo conceptual.
Cuando un evento, o una secuencia de eventos, en el mundo real requiere un intercambio de
información entre éste y el SI, dicho intercambio se denomina mensaje.
1.6. Modelo de Transacciones:
Es el conjunto de acciones que se desencadenan cuando ocurre un evento.

Es una descripción de cómo los eventos incluidos en el modelo de eventos producen cambios en el
modelo de datos, así como la naturaleza de dichos cambios.
Como esquema conceptual para describir el modelo de datos se utiliza un mapa de información
compuesto por: 1) un diagrama que muestra las entidades y sus vinculaciones; 2) una lista por cada
entidad que muestra los atributos que la identifican y los que la describen y, 3) una lista por cada valor
de valores que lo componen.
Los resultados obtenidos en esta etapa del diseño conceptual son los datos para la etapa de diseño
lógico de la BD.
3.- Elección del SGBD (costos)

4.- Diseño lógico: Implementación conceptual
Diseño lógico: El diseño lógico es relativamente complejo porque significa lograr una solución de
compromiso entre diversos factores. Alguno de ellos son:
- Flexibilidad vs. Perfomance: un modelo flexible a los cambios es el que está totalmente
normalizado, pero a mayor reestructuración decrece el rendimiento, se van formando
entidades dependientes.
- Otro aspecto a considerar es el SGBD existente, que puede no ser el más adecuado para el
sistema en cuestión. Por eso a veces se utilizan más de un SGBD.
- En algunos casos puede resultar conveniente descomponer un modelo de información en
varios submodelos de manera de reducir la complejidad operativa del sistema. En estos
casos, cada submodelo debería estar asociado a una función principal de la organización.
- Deben tenerse en cuenta visiones relacionadas con la consulta y la actualización de
información.
Desafortunadamente, con la tecnología actual, existe una incompatibilidad básica de perfomance entre
las consultas a la BD y las actualizaciones (altas y bajas) a la misma.
Por ejemplo, la decisión de beneficiar la perfomance de consulta, sacrificando la perfomance de
actualización, dependerá directamente del grado de volatilidad de la información involucrada.
La primer cuestión que el diseñador del esquema lógico debe verificar es si el SGBD que utilizará
permite implementar un esquema lógico y un esquema físico independientes.
No es posible comenzar el diseño lógico si no se conoce en profundidad el grado de independencia
entre esquemas lógicos y físicos provistos por el SGBD.
Si el SGBD no ofrece un adecuado grado de independencia, el diseñador se verá obligado a unificar las
etapas de diseño lógico y físico, produciendo como resultado un “esquema lógico-físico”. Como
consecuencia de esto, surgirá la necesidad de apartarse de la forma canónica por razones
exclusivamente inherentes al diseño físico.
50
Objetivos del diseño lógico:
La etapa de diseño de modelo de datos concluye con la obtención de la forma canónica. Dicho modelo
es independiente del SGBD y fue realizado sin considerar la frecuencia de los procesos que
interactuarán con la BD, las prioridades, los tiempos de respuesta requeridos para los mismos, etc.
Cuando múltiples usuarios a través de múltiples procesos de diferentes características interactúan con
una misma BD, pueden resultar situaciones de conflicto o de incompatibilidad en los aspectos de
rendimiento, de seguridad y de integridad de datos.
La solución de dichos conflictos es uno de los objetivos del diseño lógico.
Mapa del esquema lógico:

En un esquema lógico, las flechas en las vinculaciones indican trayectorias de acceso necesarias para
efectuar algún proceso.
La existencia de alguna vinculación del esquema canónico dentro del esquema lógico se traducirá en
una trayectoria física de acceso a la información.
Si se implementa el esquema canónico como esquema lógico habrá tantas trayectorias bidireccionales
en el esquema lógico como vinculaciones en el esquema canónico.
La implementación de las trayectorias se hará teniendo en cuenta los procesos que se efectuarán sobre
la BD.
Un SGBD puede clasificarse según el tipo de tratamiento para el cual está orientado:
- Tratamiento Navegacional
- Tratamiento Relacional
Tratamiento navegacional: supone realizar operaciones sobre la BD (almacenamiento, consulta,

borrado), accediendo a los registros lógicos a través de las trayectorias de acceso implementadas para
dicha fase.
Tratamiento relacional: en este tratamiento no se utilizan trayectorias de acceso sino las vinculaciones
entre datos representados exclusivamente mediante valores de atributos tomados de un dominio
común.
Cualquier tipo de SGBD puede ser tratado relacionalmente a través de una interfase directa (si las
relaciones representadas están normalizadas) o a través del concepto de super esquema, con mayor o
menor eficiencia, según sea el caso.
Cualquier estructura de información puede reducirse a un grupo de relaciones normalizadas,
obteniéndose una BD relacional.
La flexibilidad de las BD relacionales provienen de la facilidad con que las relaciones pueden ser
manejados. La teoría relacional define una variedad de operadores a través de los cuales las relaciones
pueden ser manipuladas (las operaciones son: proyección, selección, unión, etc.).
Prioridades en el diseño lógico:
Como el diseño lógico debe lograr el compromiso de factores, alguno de ellos contrapuestos, es
necesario establecer prioridades.
Un esquema de prioridades generalmente aceptado es:
1.- Satisfacción del usuario final
2.- Satisfacción de las necesidades del negocio
3.- Flexibilidad frente a cambios y crecimiento (normalización)
4.- Integridad (confiabilidad en cuanto a la disponibilidad de información)
5.- Seguridad (confiabilidad de la información)
6.- Perfomance global del sistema costo-operativo
7.- Facilidad de operación
8.- Rendimiento
Esta lista de prioridades apunta a maximizar la usabilidad de la información contenida en la BD.
51
Etapas en el diseño lógico:
1.- Determinar las características físicas de cada atributo (longitud, tipo, etc.)
2.- Determinar la frecuencia de uso de cada visión de usuario.
3.- Determinar la cantidad de miembros que van a componer cada entidad o asociación.
4.- Determinar la cantidad de hijos por padre que contendrá cada vinculación.
5.- Mediante visiones de usuarios y los puntos anteriores, determinar las trayectorias necesarias
y los puntos de entrada a la estructura.
6.- Verificar que los procesos de altas y bajas puedan ser efectuados adecuadamente, mediante
simulación.
7.- Establecer el orden de prioridades para el diseño.
8.- De acuerdo a la prioridades ofrecidas por el sistema de gestión, determinar las trayectorias
que podrán ser implementadas.
9.- Simular el acceso a cada visión de usuario, determinando si el tiempo de respuesta es el
adecuado. Si es necesario, apartarse de la forma canónica.
10.- Al finalizar el diseño verificar que se han respetado las prioridades previamente
establecidas.
Apartándonos de la forma canónica:
Se consideran:
- tiempo de respuesta
- frecuencia de uso de las vistas de usuario
Cuando el SGBD no permite implementar un esquema lógico.

Para favorecer el rendimiento de la BD, es decir para optimizar la perfomance, es posible apartarse de
la forma canónica. Para ello, existen 2 maneras de hacerlo:
A – Sin desnormalizar entidades y asociaciones existentes,
- Introduciendo datos redundantes o
- Introduciendo entidades y asociaciones adicionales denominadas “range” y adecuando las
vinculaciones afectadas.
B – Desnormalizar entidades y asociaciones existentes
Ejemplo: apartándonos de la forma canónica, desnormalizando entidades o asociaciones existentes.
PERSONAS (nombre/otros datos) VUELOS(Nºvuelo/origen/destino/fecha/...)
RESERVACIONES (nombre/Nºvuelo/cant.plazas)
repetitivo
Si la mayor actividad de consulta es por nombre de la persona, podríamos violar la 1FN introduciendo
grupos repetitivos.
PERS-RESER(nombre/otros datos/Nºvuelo/cant.plazas)
VUELOS(Nºvuelo/origen/destino/fecha/...)
Puede verse que al orientar el esquema lógico se ha perdido la posibilidad de acceder en forma directa
a todas las personas que tienen reservas para un determinado vuelo. Para poder responder a este
interrogante con el último esquema será necesario realizar una búsqueda sobre toda la relación
personas reservas.
52
Para solucionar este problema sería posible introducir un grupo repetitivo en VUELOS conteniendo
los nombres de las personas que tienen reservas efectuadas.
Si este es el caso podríamos observar que mediante la introducción de información redundante
podemos lograr mejorar los accesos de consulta pero estaremos deteriorando la perfomance de
actualización (estamos introduciendo una anomalía de actualización).
Una decisión de este tipo sería apta para un sistema de alta actividad y baja volatilidad de la
información almacenada.
También podríamos violar la 2FN introduciendo una dependencia funcional incompleta.
PERS-RESER(nombre/Nºvuelo/cant.plazas/otros datos de la persona)
En general puede verse que cuando nos apartamos de las formas normales nos encontramos con
anomalías tanto en las altas como en las bajas de información.
Cuando y cómo desnormalizar?

a) Cuando una trayectoria de hijo a padre es muy utilizada, es posible incorporar en el hijo los
datos del padre violando la 2FN o la 3FN, según sea el caso. (para la 2FN incorporando una
dependencia funcional incompleta).
b) Cuando una trayectoria de padre a hijo es muy utilizada es posible incorporar datos de los
hijos en el padre, violando la primera forma normal al introducir un grupo repetitivo en el
padre.
Una desnormalización provocará, en la mayoría de los casos, que al usuario le resulte menos
“natural” su interacción con la Base.
Es conveniente consultar con los usuarios aquellas soluciones de compromiso que puedan
afectar, la facilidad de uso, los tiempos de respuesta, etc.
En el caso de violar la 2FN introduciendo una dependencia funcional incompleta, tendríamos:
PERS-RESER(nombre/Nºvuelo/cant.plazas/otros datos de la persona)
En este esquema es necesario que las consultas a PERS-RESER se hagan mediante la clave doble
nombre+NºVuelo, lo cual puede resultar un inconveniente. Sería posible crear un índice secundario
para PERS-RESER que permita el acceso por nombre (recordar que una persona puede tener varias
reservaciones para diferentes vuelos).
Otro ejemplo:
PROYECTO
EMPLEADOS
a) “Dado un empleado, el nombre del proyecto en el que trabajó”
b) “Dado un proyecto, el nombre de los empleados”
PROYECTO Cod.Proy./Nom.Proy./LugarProy.
EMPLEADOS Dni/apell/nom/Cod.Proy.(AV)
53
Violando la 2FN
PROYECTO Cod.Proy./ LugarProy.
EMPLEADOS Dni/Cod.Proy/apell/nom/Nom.Proy.
Violando la 1FN
PROYECTO Cod.Proy./Nom.Proy./LugarProy./Empleados:dni
EMPLEADOS Dni/apell/nom/Cod.Proy.(AV)
Determinación de costos de accesos lógicos:
Se entiende por costo de accesos lógicos al número de accesos a registros lógicos para realizar
una operación en la BD, mediante una “navegación” a través de trayectorias lógicas potencialmente
disponibles.
Determinar este costo:
- ayuda a determinar potenciales situaciones de baja perfomance o de tiempos de respuesta
inadecuados
- posibilita comparar el funcionamiento de diseños alternativos
La determinación del costo se realiza a nivel de “accesos lógicos” con independencia de la

cantidad de “accesos físicos” que aquellos pudieran demandar.
Un acceso lógico puede demandar uno, varios o ningún acceso físico (si el registro fue
accedido anteriormente).
Como la perfomance final depende de la cantidad de accesos físicos, el resultado es una
aproximación suficientemente buena del costo de accesos real.
Determinación de las trayectorias a implementar:
Para determinar trayectorias a implementar hay que encontrar las vinculaciones utilizadas por
cada visión de usuario y las trayectorias a través de las que hay que navegar para acceder a la
información requerida.
Cuando para satisfacer a una visión de usuario hay más de una alternativa posible, es decir más
de una entrada a la estructura, es conveniente tomar aquella que corresponde a la navegación más
corta, es decir la que resulta tener un menor costo de accesos lógicos.
DISEÑO FÍSICO:
El diseño físico consiste en determinar la estrategia de almacenamiento óptima para cada

componente de la estructura.
1) Minimizar los tiempos de acceso

- mediante una óptima distribución de los archivos físicos que componen la BD, en el
almacenamiento secundario
- cuando el SGBD lo permita agrupando juntos registros lógicos relacionados en el menor
número posible de áreas o páginas o archivos físicos.
54
2) Minimizar la cantidad de accesos requeridos al almacenamiento secundario mediante un adecuado
dimensionamiento de buffers en el almacenamiento principal.
3) Optimizar el uso de almacenamiento secundario por la BD. Esta optimización puede resultar
parcialmente anulada cuando múltiples BD comparten un mismo eje de discos y son procesados
concurrentemente por varios programas.
El diseño físico supone también lograr un compromiso entre factores contrapuestos. No es posible
definir una forma óptima, en términos absolutos de organización física.
El diseñador tratará de optimizar el diseño físico para la mezcla de procesos considerada también
en la etapa de diseño lógico.
El diseño físico termina con un LDA (lenguaje de descripción de almacenamiento).
FASES DEL DISEÑO DE UNA BASE DE DATOS SEGÚN ELMASRI/NAVATHE
El problema de diseño de bases de datos puede expresarse así: diseñar la estructura lógica y física
de una o más bases de datos para atender las necesidades de información de los usuarios en una
organización para un conjunto definido de aplicaciones.
Podemos identificar seis fases principales del proceso de diseño de bases de datos:
1. Recolección y análisis de requerimientos.
2. Diseño conceptual de la base de datos.
3. Elección de un SGBD.
4. Transformación al modelo de datos (llamado también diseño lógico de la base de datos).
5. Diseño físico de la base de datos.
6. Implementación del sistema de base de datos.
Fase 1 – Recolección y análisis de requerimientos:
Antes de poder diseñar eficazmente una base de datos, debemos conocer las expectativas de los
usuarios y los usos que se piensa dar a la base de datos con el mayor detalle posible. El proceso de
identificar y analizar los usos propuestos se denomina recolección y análisis de requerimientos. Para
especificar los requerimientos, primero debemos identificar las demás partes del sistema de
información que van a interactuar con el sistema de base de datos. Entre ellas están los usuarios y las
aplicaciones nuevas y ya existentes. Una vez hecho esto, se reunirán y analizarán los requerimientos de
dichos usuarios y aplicaciones.
Fase 2 – Diseño conceptual de la BD:
La segunda fase implica dos actividades paralelas, que son:

- Diseño del esquema conceptual, examina los requerimientos de datos resultantes de la fase
1 y produce un esquema de base de datos conceptual.
- Diseño de transacciones, examina las aplicaciones de base de datos analizadas en la fase 1 y
produce especificaciones de alto nivel para estas transacciones.
Diseño del esquema conceptual: El esquema conceptual que resulta de esta fase suele estar contenido
en un modelo de datos de alto nivel independiente del SGBD, de modo que no puede usarse
directamente para implemenar la base de datos.
La meta del diseño del esquema conceptual es un entendimiento completo de la estructura, el
significado (semántica), los vínculos y las restricciones de la base de datos. Lo mejor es lograr esto
independientemente de un SGBD específico porque todos los SGBD suelen tener peculiaridades y
restricciones que no deben influir sobre el diseño del esquema conceptual.
55
El esquema conceptual es muy valioso como una descripción estable del contenido de la base
de datos. La elección del SGBD y las decisiones de diseño posteriores pueden cambiar sin alterar el
esquema conceptual independiente del SGBD.
Un buen entendimiento del esquema conceptual es decisivo para los usuarios de la base de
datos y los diseñadores de aplicaciones. Por ello es sumamente importante el empleo de un modelo de
datos de alto nivel que sea más expresivo y general que los modelos de datos de los SGBD
individuales.
Enfoque para el diseño de esquemas conceptuales: Para diseñar un esquema conceptual
debemos identificar los componentes básicos del esquema: los tipos de entidades, los tipos de vínculos
y sus atributos. También debemos especificar los atributos clave, la cardinalidad y las restricciones de
participación en vínculos.
Diseño de transacciones: El propósito es diseñar las características de las transacciones conocidas en la

base de datos con independencia del SGBD. Cuando se está diseñando un sistema de base de datos, los
diseñadores están conscientes de muchas aplicaciones conocidas (o transacciones) que se ejecutarán en
la base de datos una vez que se implemente. Una parte importante del diseño de bases de datos es
especificar las características funcionales de estas transacciones en una etapa temprana del proceso de
diseño.
Una técnica común para especificar transacciones en un nivel conceptual es identificar su
comportamiento de entrada/salida y funcional.
Fase 3 – Elección del SGBD:
La elección del SGBD depende de varios factores, algunos de ellos técnicos, otros económicos
y otros más relativos a las políticas de la organización. Los factores técnicos tienen que ver con la
idoneidad del SGBD para la tarea en cuestión. Lo que debemos considerar aquí son el tipo de SGBD
(relacional, de red, jerárquico, orientado a objetos, o de otra clase), las estructuras de almacenamiento
y caminos de acceso que maneja el SGBD, las interfaces de usuario y programador disponibles, los
tipos de lenguajes de consulta de alto nivel, etc.
Fase 4 – Diseño lógico de la BD – Transformación al modelo de datos:
Esta etapa consiste en crear un esquema conceptual y esquemas externos en el modelo de datos
del SGBD elegido. Esto se logra transformando los esquemas conceptual y externos producidos en la
fase 2 del modelo de datos de alto nivel al modelo de datos del SGBD.
La transformación puede hacerse en dos etapas:
1. Transformación independiente del sistema: EN este paso, la transformación al modelo de
datos del SGBD no considera las características específicas o casos especiales que se
aplican a la forma como el SGBD implementa el modelo de datos. Realizamos la
transformación del ER a un esquema relacional, orientado a objetos, jerárquico o de red,
independiente del SGBD.
2. Adaptación de los esquemas a un SGBD específico: Los diferentes SGBD implementan un
modelo de datos con características y restricciones de modelado específicas. Tal vez sea
preciso ajustar los esquemas obtenidos en el paso 1 para adaptarlos a las características de
implementación específicas de un modelo de datos en el SGBD seleccionado.
El resultado de esta fase debe consistir en enunciados DDL escritos en el lenguaje del SGBD
elegido que especifiquen los esquemas a nivel conceptual y externo del sistema de base de datos. Sin
embargo, si los enunciados DDL contienen algunos parámetros de diseño físico, la especificación
completa en DDL deberá esperar hasta que se haya concluido la fase de diseño físico.
56
Fase 5 – Diseño Físico de la base de datos:
El diseño físico de la base de datos es el proceso de elegir estructuras de almacenamiento y

caminos de acceso específicos para que los archivos de la base de datos tengan un buen rendimiento
con las diversas aplicaciones de la base de datos. Una vez seleccionado un SGBD específico, el
proceso de diseño físico se reduce a elegir las estructuras más apropiadas para los archivos de la base
de datos entre las opciones que ofrece ese SGBD.
Fase 6 – Implementación del sistema de base de datos:
Una vez completados los diseños lógico y físico, podemos implementar el sistema de base de
datos. Se compilan los enunciados escritos en el DDL (lenguaje de definición de datos) y en el SDL
(lenguaje de definición de almacenamiento) del SGBD seleccionado, y con ellos se crean los esquemas
de la base de datos y sus archivos (vacíos). En seguida ya puede cargarse la base de datos.
57
 UNIDAD Nº 7 : MODELO DE DATOS JERÁRQUICO
Definición: El modelo de datos jerárquico representa organizaciones jerárquicas en forma directa y

natural y puede ser la mejor opción en algunas situaciones, aunque presentará problemas cuando
representa situaciones con vínculos que no sean jerárquicos.
Estructuras de Bases de Datos Jerárquicas
• Vínculos Padre-Hijo y Esquemas Jerárquicos

El modelo jerárquico utiliza dos conceptos principales de estructuración de datos: Registros y
Vínculos Padre-Hijo.
Registro: es una colección de valores de campos que proporcionan información sobre una entidad o un
ejemplar de vínculo. Los registros del mismo tipo se agrupan en Tipos de Registros. Cada Tipo de
Registro recibe un nombre y su estructura se define en términos de una colección de campos. Cada
campo tiene un cierto tipo de datos, como entero, real o cadena.
Tipo de Vínculos Padre-Hijo: es una vinculación 1:N entre dos tipos de registros. El tipo de registros
del lado 1 se denomina tipo de registros Padre y el del lado N se llama tipo de registro Hijo del tipo
VPH. Una ocurrencia del tipo de VPH consiste en un registro del tipo de registros Padre y varios
registros (0 o más) del tipo de registros Hijo.
Un esquema de BD jerárquica consiste de varios esquemas jerárquicos. Cada esquema jerárquico

comprende varios tipos de registros y tipos de VPH.
Ej. de un esquema jerárquico
DEPARTAMENTO
NOMD NUMD NOMGTE FECH
EMPLEADO PROYECTO
NOME NSS FECHAN DIRE NOMP NUMP LUGARP
• Propiedades de los Esquemas Jerárquicos

Un esquema jerárquico de tipos de registros y tipos de VPH debe tener las siguientes propiedades:
1. La raíz del esquema jerárquico, no participa como tipo de registros hijo en ningún tipo de VPH.
2. Todo tipo de registros, con excepción de la raíz, participa como tipo de registros hijo en uno y
sólo un tipo de VPH.
3. Un tipo de registro puede participar como tipo de registros padre en cualquier cantidad (0 o
más) de tipos de VPH.
4. Un tipo de registros que no participa como tipo de registros padre en ningún tipo de VPH se
denomina hoja del esquema jerárquico.
5. Si un tipo de registros participa como padre en más de un tipo de VPH, entonces sus tipos de
registros hijo están ordenados. Por convención se ordenan de izquierda a derecha.
58
Estas propiedades significan que “todos los nodos excepto la raíz tienen uno y solo un nodo padre.
No obstante un nodo puede tener varios nodos hijo, y en tal caso están ordenados de izquierda a
derecha”.
Estas propiedades limitan los tipos de vínculos que se pueden presentar en un esquema jerárquico.
Los vínculos M:N no pueden representarse directamente porque los vínculos padre-hijo son 1:N y
un tipo de registros no puede participar como hijo en dos o más VPH distintos.
En el modelo jerárquico es posible manejar los vínculos M:N si se pueden duplicar los ejemplares
de registros hijo.
Por ejemplo consideremos un vínculo M:N entre EMPLEADO Y PROYECTO, donde un proyecto
puede tener varios empleados que trabajan en él, y un empleado puede trabajar en varios proyectos.
Podemos representar el vínculo como un tipo de VPH (PROYECTO, EMPLEADO) como se
muestra en la figura b. En este caso, un registro que describa al mismo empleado puede duplicarse si
aparece una vez debajo de cada uno de los proyectos en los que ese empleado trabaje. Como
alternativa, podemos representar el vínculo como un tipo de VPH (EMPLEADO, PROYECTO) como
se muestra en la figura c, en cuyo caso podremos duplicar los registros de proyectos.
Proyecto Empleados que trabajan

PROYECTO EMPLEADO
en el Proyecto
A E1, E3, E5 Fig. b Fig. c
B E2, E4, E6
C E1, E4
EMPLEADO PROYECTO
D E2, E3, E4, E5
Si estos ejemplares se almacenan empleando el esquema jerárquico de la fig. b, habrá cuatro

ocurrencias del tipo VPH (PROYECTO, EMPLEADO), una por cada proyecto. En cambio los
registros de los empleados E1, E2, E3 y E5 aparecerán dos veces cada uno como registros hijo porque
cada uno de estos empleados trabajan en dos proyectos. El registro del empleado E4 aparecerá tres
veces, una vez por cada uno de los proyectos B, C y D.
Alguno de los valores de los campos de datos en los registros de empleados pueden depender
del contexto, es decir, dichos valores dependerían tanto de EMPLEADO como de PROYECTO. Estos
datos podrían diferir en cada ocurrencia de un registro de empleado duplicado porque también
dependerían del registro de proyecto padre.
Un ejemplo sería un campo con el número de horas por semana que un empleado trabaja en el
proyecto. Sin embargo, la mayor parte de los valores de campos en los registros de empleados, como el
nombre del empleado, su número de seguro social y su salario, sin duda se duplicarían en cada
proyecto al cual perteneciera el empleado.
A fin de evitar tal duplicación, contamos con una técnica con la cual podemos especificar
varios esquemas jerárquicos en el mismo esquema de BD jerárquica. Así podemos definir los vínculos
como el tipo de VPH anterior entre esquemas jerárquicos, lo que permite superar el problema de
duplicación. Esta técnica denominada de “vínculos virtuales” (para representar vínculos M:N), se
aparta del modelo jerárquico estricto.
• Arboles de ocurrencias Jerárquicos

Cada ocurrencia jerárquica, llamada también árbol de ocurrencia, es una estructura de árbol cuya
raíz es un solo registro del tipo de registros raíz.
El árbol de ocurrencia contiene todas las ocurrencias del tipo de registros raíz, todas las ocurrencias
de registros hijo dentro de los VPH de cada uno de los registros hijo del registro raíz, y así
sucesivamente, hasta los registros de los tipos de registros hoja.
En el árbol de ocurrencia, cada nodo es una ocurrencia de registro, y cada arco representa un
vínculo padre-hijo entre dos registros.
Podemos definir los árboles de ocurrencia usando la terminología de las estructuras de árbol. En
una estructura de árbol, se dice que la raíz tiene nivel cero. El nivel de un nodo no raíz es el nivel de su
59
nodo padre más uno. Un nodo descendiente de un nodo N es un nodo conectado a N a través de uno o
más arcos, de tal modo que el nivel de D es mayor que el de N. Un nodo N y todos sus nodos
descendientes forman un subárbol del nodo N. Ahora podemos definir un árbol de ocurrencia como el
subárbol de un registro cuyo tipo es del tipo de registros raíz.
La raíz de un árbol de ocurrencia es una sola ocurrencia de registro del tipo de registros raíz. Puede
haber un número variable de ocurrencias de cada tipo de registros no raíz, y cada una de ellas debe
tener un registro padre en el árbol de ocurrencia, es decir cada una de esas ocurrencias debe participar
en una ocurrencia de VPH.
Nivel 0: D
DEPARTAMENTO
NOMD NUMD NOMGTE FECH
Nivel 1: E EMPLEADO P PROYECTO

T TRABAJADOR
Nivel 2: N DEPENDIENTE S SUPERVISADO
NOM NSS HORAS
NOMDE SEX FECHNAC NOM NSS
Fig. d. Esquema jerárquico de una parte de la BD COMPAÑÍA.

D Administración
E Zapata E Valdéz E Jabbar P Automatización P Nuevasprestaciones
N Abdiel S Zapata S Jabbar T Vizcarra T Zapata T Jabbar T Zapata T Valdéz T Jabbar
Fig. e. Ocurrencia jerárquica (Árbol de ocurrencia) del esquema jerárquico de la figura d.
Forma linealizada de una ocurrencia jerárquica
La estructura de almacenamiento más simple para los árboles de ocurrencia jerárquicos es el

registro jerárquico: un ordenamiento lineal de los registros en un árbol de ocurrencia en el recorrido en
preorden del árbol. Este orden produce una secuencia de ocurrencias de registros denominada
secuencia jerárquica del árbol de ocurrencia.
D Administración
E Zapata
E Valdéz
N Abdiel
S Zapata
S Jabbar
E Jabbar
P Automatización
T Vizcarra
T Zapata
T Jabbar
P Nuevasprestaciones
T Zapata
T Valdéz
T Jabbar
Fig. f. Secuencia jerárquica del árbol de ocurrencia de la fig. e.
60
Vínculos virtuales padre-hijo
El modelo jerárquico tiene problemas cuando se modelan:

1. Vínculos M:N
2. El caso en que un tipo de registros participa como hijo en más de un tipo de VPH
3. Vínculos n-arios con más de dos tipos de registros participantes
El caso 1 puede representarse como un tipo de VPH a expensas de duplicar ocurrencias de registros del
tipo de registros hijo.
El caso 2 puede representarse en forma similar, con más duplicación de registros.
El caso 3 es problemático porque el VPH es un vínculo binario.
La duplicación de registros, además de desperdiciar espacio de almacenamiento, dificulta el

mantenimiento de copias consistentes del mismo registro.
La idea es incluir más de un esquema jerárquico en el esquema de la BD jerárquica y usar apuntadores
de los nodos de un esquema jerárquico al otro para representar los vínculos.
Un tipo de registro virtual o apuntador HV es un tipo de registros con la propiedad de que cada uno de
sus registros contiene un apuntador a un registro de otro tipo de registros PV, HV siempre desempeña
el papel de “hijo virtual” y PV el del “padre virtual” en un “vínculo virtual padre-hijo”.
Cada ocurrencia de registros h de HV apunta a una y solo una ocurrencia de registro p de PV. En vez
de duplicar el registro p en el árbol de ocurrencia, incluimos el registro virtual h que contiene un
apuntador a p. Varios registros virtuales pueden apuntar a p, pero sólo se almacenará una copia de p en
la BD.
Para el vínculo M:N entre EMPLEADO y PROYECTO, podemos usar los registros virtuales
APUNTE y APUNTP.
PROYECTO EMPLEADO EMPLEADO PROYECTO
Fig. g Fig. h
APUNTE APUNTP
Fig. g. Representación del vínculo M:N con padre virtual EMPLEADO.

Fig. h. Representación del vínculo M:N, con padre virtual PROYECTO.
Cada registro del tipo de registro HV contiene un apuntador a un registro del tipo de registro PV. Cada
ocurrencia del registro Hijo Virtual apunta a una y solo una ocurrencia del registro Padre Virtual.
En vez de duplicar el registro P en el árbol de ocurrencias, se incluye el registro virtual h que tiene un
apuntador a P. Varios registros virtuales pueden apuntar a P, pero solo se almacenan una copia de P en
la BD.
El problema con el tipo de vínculo N:M son:

- desperdicio de almacenamiento
- el mantenimiento de copiar el mismo registro
Solución:
- incluir más de un esquema jerárquico en la BD y usar apuntadores de los nodos de un
esquema al otro para apuntar los vínculos.
Beneficios:
- una sola copia de cada registro hijo y varios registros pueden apuntar al nuevo registro hijo.
61
Restricciones de integridad en el Modelo Jerárquico
1. Ninguna ocurrencia de registro, con excepción de los registros raíz, pueden existir si no está
relacionada con una ocurrencia de registro padre. Esto implica:
a. Ningún registro hijo puede insertarse si no está enlazado a un registro padre.
b. Un registro hijo se puede eliminar independientemente de su padre; pero la eliminación de un
padre causa automáticamente la eliminación de todos sus hijos.
c. Las reglas anteriores no se aplican a los registros hijo y padres virtuales. La regla en este caso
es que un apuntador en un registro hijo virtual debe apuntar a una ocurrencia real de un registro
padre virtual. No debe permitirse la eliminación de un registro en tanto existan apuntadores a él
en registros hijo virtuales, lo que lo convierte en un registro padre virtual.
2. Si un registro hijo tiene dos o más registros padre del mismo tipo de registros, el registro hijo debe
duplicarse una vez bajo cada registro padre.
3. Un registro hijo que tenga dos o más registros padre de diferentes tipos de registros solo puede
tener un padre real, todos los demás deben representarse como padres virtuales.
P A
P B Y EP1 Y EP2 Y EP3 E1 E
P C Y EP4 Y EP5 Y EP6 E2 E
Y EP7 Y EP8 E3 E
P D
E4 E
EP9 Y EP10 Y EP11 Y EP12

E5 E
E6 E
Aquí solo hay una copia de cada registro EMPLEADO, varios registros virtuales pueden apuntar al
mismo registro EMPLEADO. Así la información almacenada en dicho registro no se duplicará. La
información que dependa tanto de los registros pare como hijo, como las horas por semana que un
trabajador dedica a un proyecto se incluirá en el registro apuntador virtual.
 UNIDAD Nº 6 : MODELO DE RED
Estructura de una Base de Datos en red:
62
Hay dos estructuras de datos básicas en el modelo de Red:
- Registros
- Conjuntos
Registros, tipos de registros y elementos de información:
Los datos se almacenan en registros, cada registro consiste en un grupo de valores de datos
relacionados entre sí. Los registros se clasifican en tipos de registros, cada uno de los cuales describe
la estructura de un grupo de registros que almacenan el mismo tipo de información. Damos un nombre
a cada tipo de registro y también damos un nombre y un tamaño (tipo de datos) a cada elemento de
información (atributo) del tipo de registros.
La fig. (a) muestra un tipo de registros ESTUDIANTE con los elementos de información: NOM, NSS,
DIR, DPTOCA y FENAC, y también el tipo de datos de cada elemento de información.
Tipo de registros ESTUDIANTE

Fig. (a) ESTUDIANTE
NOM NSS DIR DPTOCA FENAC
Nombre de elemento de información Formato

NOM CHAR 30
NSS CHAR 9
DIR CHAR 40
DPTOCA CHAR 10
FENAC CHAR 9
También es posible definir elementos de información virtuales o derivados, cuyos valores no se

almacenan realmente en los registros, en vez de ello se derivan de los elementos de información reales
mediante algún procedimiento definido específicamente para tal fin.
Por ejemplo, se puede declarar un elemento de información virtual edad para el tipo de
registros ESTUDIANTE y escribir un procedimiento que calcule la edad a partir de la fecha de
nacimiento de cada registro.
Para representar los vínculos entre los registros, el modelo de red proporciona la construcción
de modelado llamada TIPO DE CONJUNTO.
Conjuntos:
Tipos de Conjuntos:
Un tipo de conjuntos es una descripción de un vínculo 1:N entre dos tipos de registros. Cada
definición de tipo de conjuntos consta de tres elementos básicos:
- un nombre para el tipo de conjuntos
- un tipo de registros propietario
- un tipo de registros miembro
En la BD habrá muchas ocurrencias de conjunto que corresponderán a un tipo de conjuntos.

cada ejemplar relaciona un registro del tipo de registros propietarios con el conjunto de registros del
tipo de registros miembro relacionado con el.
Tipo de registros DEPTO-CARRERA
63
Fig. (b)
DEPARTAMENTO
NOMD ... ... ... ...
DEPTO-CARRERA
ESTUDIANTE
En este ejemplo DEPARTAMENTO es el tipo de registros propietario y ESTUDIANTE es el

tipo de registros miembro.
Así cada ocurrencia de conjunto se compone de:
- Un registro propietario
- Varios registros miembro relacionados (0 o más)
Un registro del tipo de registros miembro no puede existir en más de una ocurrencia de
conjunto de un tipo de conjuntos particular. Esto mantiene la restricción de que un tipo de conjuntos
representa un vínculo l:N.
Como cada ejemplar de conjunto debe tener un registro propietario pero puede tener cualquier
número de registros miembro (0 o más), casi siempre se hace referencia a un ejemplar de conjunto por
su registro propietario. Las ocurrencias pueden representarse también mediante listas enlazadas.
Fig. (c). Dos ejemplares de conjunto del tipo de conjuntos DEPTO-CARRERAS.
DEPARTAMENTO
registro propietario Ciencias de la computación ... Matemáticas ...
Manuel Rivera ... Juan del Valle ...
Guillermo Silva ... Roberto Borja ...

ESTUDIANTE
registros miembro
Juana Velasco ... Eduardo Soto ...
Ramón Paredes ...
Un ejemplar de conjunto no es idéntico al concepto matemático de conjunto. Sus principales

diferencias son dos:
- El ejemplar de conjunto tiene un elemento distinguido – el registro propietario. En un
conjunto matemático no hay distinción
Registro DEPARTAMENTO alguna
Ciencias entre los elementos.
de la computación ...
- En el modelo de red los registros miembro están ordenados, mientras que en un conjunto
matemático no.
A continuación mostramos otra

Manuel Rivera ... representación “enlazada” de un ejemplar del conjunto
DEPTO-CARRERA.
Guillermo Silva ...
Registros EMPLEADOS Juana Velasco ...
64
Ramón Paredes ...
Tipos especiales de Conjuntos:
- Conjuntos SINGULARES o PROPIEDAD del Sistema

- Conjuntos MULTIMIEMBRO
- Conjuntos RECURSIVOS
• Conjuntos SINGULARES o PROPIEDAD del Sistema: son conjuntos sin tipo de registros
propietario, en este caso, el sistema es el propietario. Podemos considerar al Sistema como un tipo
de registro propietario “virtuales” especial en el que sólo hay una ocurrencia de registro. Se
denomina conjunto singular porque sólo hay una ocurrencia en ese conjunto.
Los conjuntos propiedad del sistema tienen dos funciones principales en el modelo de red:
- Proveen puntos de entrada a la BD a través de los registros del tipo de registros miembro
especificado.
- Pueden servir para ordenar los registros de un tipo de registros dado mediante las
especificaciones de ordenamiento del conjunto. Si un usuario especifica varios conjuntos
propiedad del sistema para el mismo tipo de registros, puede tener acceso a sus registros en
diferentes órdenes.
Conjunto Singular SISTEMA
Fig. (e) TODOS_DEPTOS
DEPARTAMENTO
Esta es una representación diagramática del conjunto propiedad del sistema TODOS-DEPTOS, que
permite tener acceso a los registros DEPARTAMENTO en orden según cierto campo, por ejemplo
NOM, con una especificación apropiada de ordenamiento de conjunto.
• Conjunto MULTIMIEMBRO: se utilizan en casos en que los registros miembro de un conjunto

pueden pertenecer a más de un tipo de registros. Los registros miembro en una ocurrencia de
conjuntos multimiembro pueden contener registros de cualquier combinación de tipos de registros
miembro. La restricción de que cada registro miembro pueda aparecer en una ocurrencia de
conjunto, como máximo, sigue siendo válida, a fin de imponer la naturaleza 1:N del vínculo.
DEPARTAMENTO
EMP_DEPTO
EMP_ADMVO EMP_TECNICO EMP_GERENCIAL
65
• Conjuntos RECURSIVOS: es un tipo de conjuntos en el que el mismo tipo de registros desempeña
el papel tanto de propietario como de miembro.
Un ejemplo de vínculo recursivo 1:N que se puede representar con un conjunto recursivo es el
vínculo SUPERVISIÓN, que relaciona un empleado supervisor con la lista de empleados a los que
supervisa directamente. El registro EMPLEADO sesempeña ambos papeles, el de tipo de registro
propietario (el empleado supervisor) y el de tipo de registros miembros (los empleados
supervisados).
En el caso de los conjuntos recursivos, el mismo registro puede ser propietario de una ocurrencia
de conjunto y miembro de otra, si ambas ocurrencias de conjunto son del mismo tipo de conjuntos.
Por este problema, se acostumbra representar los conjuntos recursivos en el modelo de red con un
tipo de registros de enlace (o ficticio) adicional. La misma técnica se utiliza para representar
vínculos M:N.
En la figura se muestra la representación del vínculo SUPERVISIÓN empleando dos tipos de

conjuntos y un tipo de registros de enlace. El tipo de conjuntos SUPERVISOR en realidad es un
vínculo 1:1, es decir, hay cuando más un tipo de registros SUPERVISIÓN miembro en cada
ocurrencia del conjunto SUPERVISOR. Podemos considerar cada registro de enlace
SUPERVISIÓN como la representación de un empleado en el papel de supervisor.
PROYECTO EMPLEADO
SUPERVISOR SUPERVISADO
APUNTE
Fig. (h) – Representación prohibida
de un conjunto recursivo
Fig. (g) – Conjunto recursivo SUPERVISIÓN representado mediante un
tipo de registro de enlace.
Casi ninguna implementación de SGBD de red permite al mismo tipo de registros participar como
propietario y como miembro en el mismo tipo de conjuntos.
Empleo de Conjuntos para representar vínculos 1:1 y M:N:
Un tipo de conjuntos representa un vínculo 1:N entre dos tipos de registros. Esto significa que
un registro del tipo de registros miembro solo puede aparecer en una ocurrencia del conjunto.
Si queremos representar un vínculo 1:1 entre dos tipos de registros con un tipo de conjuntos,
debemos hacer que cada ocurrencia de conjunto solo pueda tener un registro miembro. El modelo de
red no cuenta con mecanismos para imponer automáticamente esta restricción, por lo que el
programador debe comprobar que no se viole esta restricción cada vez que se inserta un registro
miembro en una ocurrencia de conjunto.
Si queremos representar un vínculo M:N entre dos tipos de registros no puede representarse con
un solo tipo de conjuntos. El método correcto para representar éste vínculo es utilizar dos tipos de
conjuntos y un tipo de registros adicional denominado tipo de registros de enlace o ficticio. Cada
registro del tipo de registros enlace sirve para relacionar dos registros propietarios.
EMPLEADO PROYECTO
P_T
E_T
TRABAJA EN
66
HORAS
Fig. (i) – Representación de un vínculo M:N mediante conjuntos, empleando un tipo de registros de enlace.
La fig. (i) representa el vínculo TRABAJA_EN entre EMPLEADOS y PROYECTOS.

Suponemos que un empleado puede trabajar en varios proyectos al mismo tiempo y que un proyecto
casi siempre tiene varios empleados que trabajan en él.
El registro adicional o ficticio para el ejemplo es el registro TRABAJA_EN. Cada registro del
tipo de registros TRABAJA_EN debe ser propiedad de un registro EMPLEADO a través del conjunto
E_T y de un registro PROYECTO a través del conjunto P_T.
TRABAJA_EN
EMPLEADOS T1 PROYECTOS
(E2,P1,30)
T2
(E2,P1,30)
P1
E1 T3
(E2,P1,30)
P2
E2 T4
(E2,P1,30)
T5
E3 (E2,P1,30) P3
T6
(E2,P1,30)
E4 P4
T7
(E2,P1,30)
Fig. (j) – Representación de algunas ocurrencias de un vínculo M:N con ocurrencias enlazadas.
Restricciones en el Modelo de Red:
Existen ciertas restricciones de “comportamiento” que se aplican a los miembros de los

conjuntos cuando se realizan operaciones de inserción, eliminación y actualización con esos conjuntos.
Podemos especificar varias restricciones sobre la pertenencia a un conjunto, y estas suelen dividirse en
dos categorías principales, llamadas opciones de inserción y opciones de retención.
• Restricciones de inserción en conjuntos:
Las restricciones de inserción sobre la pertenencia a conjuntos especifican lo que sucede
cuando se inserta en la BD un registro nuevo que es de un tipo de registros miembro. Hay dos opciones
de inserción:
- Automática: el nuevo registro miembro se conecta automáticamente a una ocurrencia de
conjunto apropiada cuando se inserta el registro.
- Manual: el nuevo registro no se conecta a ninguna ocurrencia de conjunto. Si el
programador lo desea, puede conectar después manualmente a una ocurrencia de conjunto,
mediante la orden connect.
• Restricciones de retención en conjuntos:
67
Las restricciones de retención especifican si un registro de un tipo de registros miembro pueden
existir en la BD por sí solo o si siempre debe estar relacionado con un propietario como miembro de
algún ejemplar de conjunto. Hay tres opciones de retención:
- Opcional: un registro miembro puede existir por si solo sin ser miembro de ninguna
ocurrencia del conjunto. Se le puede conectar y desconectar de las ocurrencias de conjuntos
a voluntad con las órdenes connect y disconnect.
- Obligatoria: ningún registro miembro puede existir por si solo, siempre debe ser miembro
de una ocurrencia de conjunto del tipo de conjuntos. Se le puede reconectar en una sola
operación de una ocurrencia de conjunto a otra mediante la orden reconnect.
- Fija: al igual que en la obligatoria, ningún registro miembro puede existir por si solo. Por
añadidura, una vez insertado en una ocurrencia de conjunto queda fijo, no se le puede
reconectar a otra ocurrencia de conjunto.
 UNIDAD Nº 8 : OTRAS TECNOLOGÍAS
 ¿QUE ES UNA BDOO?
68
Una BDOO es una base de datos que incorpora los conceptos importantes del paradigma de
objetos:
- Encapsulación: propiedad que permite ocultar la información al resto de los objetos,

impidiendo así accesos incorrectos o conflictos.
- Herencia: propiedad a través de la cual los objetos heredan comportamientos dentro de una
jerarquía de clases.
- Polimorfismo: propiedad de una operación mediante la cual puede ser aplicada a distintos tipos
de objetos.
En una BDOO, los usuarios pueden definir operaciones sobre los datos como parte de una
definición de la base de datos.
Una operación (llamada función) se especifica de dos partes.
- La interfaz (o signatura) de una operación incluye el nombre de la operación y los tipos de

datos de sus argumentos (o parámetros).
- La implementación (o método) de la operación se especifica separadamente y puede
modificarse sin afectar la interfaz.
Los programas de aplicación de los usuarios pueden operar sobre los datos invocados a dichas
operaciones a través de sus nombres y argumentos, sea cual sea la forma en la que se han
implementado. Esto se denomina independencia entre los programas y operaciones.
Está diseñada para ser eficaz, desde el punto de vista físico, para almacenar objetos complejos.
Evita el acceso a los datos; esto es mediante los métodos almacenados en ella. Es más segura ya que no
permite tener acceso a los datos (objetos); esto debido a que para poder entrar se tiene que hacer por
los métodos que haya utilizado el programador.
Una BDOO almacena objetos. Los datos se almacenan junto a los métodos que procesan dichos
datos. Las BDOO toman la idea de bases inteligentes de datos a su conclusión lógica. No se tiene
acceso a dato alguno si no es a través de los métodos almacenados en la base de datos. Estos métodos
están listos para entrar en acción al momento en que reciben una solicitud. Los datos de todos los
objetos quedan entonces encapsulados, esto es porque todas las operaciones que un usuario pueda
aplicar están predefinidas.
Además las BDOO combinan las mejores cualidades de los archivos planos, las bases
jerárquicas y relacionales; proporcionan una estructura flexible con acceso ágil, rápido, con gran
capacidad de modificación. Estás permiten el desarrollo y mantenimiento de aplicaciones complejas ya
que se puede utilizar un mismo modelo conceptual y así aplicarlo al análisis, diseño y programación,
esto reduce el problema entre los diferentes modelos a través de todo el ciclo de vida, con un costo
significativamente menor.
Ofrecen un mejor rendimiento de la máquina que las bases de datos por relación, para
aplicaciones ó clases con estructuras complejas de datos. Sin embargo, las BDOO coexistirán con las
bases de datos por relación como una forma de estructura de datos dentro de una BDOO.
La diferencia principal respecto a las otras bases de datos es la no positividad de los datos. En
efecto, con una base de datos tradicional las operaciones que se tienen que efectuar en los datos se les
piden a las aplicaciones que los usan. Con una BDOO los objetos memorizados en la base de datos
contienen tanto los datos como las operaciones posibles con tales datos. En cierto sentido, se podrá
pensar en los objetos como en datos a los que se les ha puesto una inyección de inteligencia que les
permite saber cómo comportarse, sin tener que apoyarse en aplicaciones externas.
69
 CARACTERISTICAS
• Mejor rendimiento que el de la bases de datos relacionales.

• Bases de dato activas.
• Bases de dato con conocimiento.
• Objetos binarios de gran tamaño (sonido, video, etc).
• Tipos de datos abstractos.
El modelo relacional no se basa en un paradigma para la estructuración de los datos, sino en

ciertos fundamentos matemáticos. Las bases de datos con conocimiento utilizan marcos, que son
objetos con un conjunto de reglas asociadas. Objetos binarios de gran tamaño requieren el
almacenamiento y utilización de BDOO, debido a que soporta tipos de datos más variados que las
simples tablas relacionales.
En una base de datos orientada a objetos, cualquier cosa es un objeto y se manipula como tal.
Un objeto es una instancia que responde a mensajes activando un método.
Los objetos soportan una serie de características:
• Se agrupan en tipos denominados clases

• Contienen datos internos que definen su estado actual
• Soportan ocultación de datos
• Pueden heredar propiedades de otros objetos
• Pueden comunicarse con otros objetos enviando o pasando mensajes
• Tienen métodos que definen su comportamiento
Las clases son una colección de objetos con propiedades similares, compartimiento común,
relaciones comunes a otras clases.
La instancia es un objeto con propiedades definidas en su descripción de la clase.
El mensaje es una clase que debe tener un método correspondiente. Un mensaje puede ser
enviado a un objeto a ejecutar una acción.
El método es una lista de instrucciones detalladas que definen cómo responde un objeto a un
mensaje en particular.
La superclase es la clase que deriva a otra clase.
La subclase es la clase derivada de una superclase.
La liga expresa compatibilidad de relaciones entre las clases.
Los objetos heredan las características de su clase y de todas las clases de nivel superior a la
que pertenecen.
Estos principios y técnicas hacen que las BDOO estén adecuadas a aplicaciones que implican
tipos de datos complejos, tales como documentos compuestos o de diseño asistidos por computadora
que combinan texto, gráficos y hojas de cálculo.
Las Bases de Datos proporcionan un modo natural de representar las jerarquías que aparecen en
los datos complejos. La jerarquía de clases permite a la Base de Datos seguir la pista del tipo de cada
objeto en el documento. Finalmente, el mecanismo de mensajes ofrece soporte natural para una
interfaz de usuarios gráfica.
 PROPIEDADES
70
• El objetivo principal es el encapsulado, que permite almacenar datos y métodos. Los datos solo
pueden utilizarse mediante los métodos, los datos están diseñados para ser utilizados por esos
métodos.
• Los objetos son activos, las solicitudes hacen que los objetos ejecuten sus métodos, algunos
pueden ser complejos como aquellos que utilizan un motor de inferencias.
• Las clases son diseñadas para una alta utilización y son rara vez modificadas, pudiendo ser
reorganizadas sin modificar su forma de uso.
• Las estructuras de datos son complejas, esto es transparente al usuario, debido a que estos están
encapsulados.
• Los datos están ligados entre si, de modo que los métodos logren un mejor entendimiento.
• No se busca obtener datos no redundantes, sino métodos no redundantes utilizando el
encapsulado y la herencia.
• Las solicitudes al objeto provocan la ejecución de sus métodos.
 TRES ENFOQUES DE CONSTRUCCIÓN DE BASES DE DATOS OO
Las BDOO se pueden construir mediante alguno de los tres enfoques siguientes:
 El Primero: se puede utilizar el código actual altamente complejo de los sistemas de

administración de las bases de datos, de modo que una BDOO se implante más rápido sin tener
que iniciar de cero. Las técnicas orientadas a objetos se pueden utilizar como medios para el
diseño sencillo de sistemas complejos. Los sistemas se construyen a partir de componentes ya
probados con un formato definido para las solicitudes de las operaciones del componente.
 El Segundo: considera a la BDOO como una extensión de la tecnología de las bases de datos
por relación. De este modo, las herramientas, técnicas, y vasta experiencia de la tecnología por
relación se utilizan para construir un nuevo SABD. Se pueden añadir apuntadores a las tablas
de relación para ligarlas con objetos binarios de gran tamaño. La base de datos también debe
proporcionar a las aplicaciones clientes un acceso aleatorio y por partes a grandes objetos, con
el fin de que sólo sea necesario recuperar a través de la red la parte solicitada de los datos.
 El Tercero: reflexiona sobre la arquitectura de los sistemas de bases de datos y produce una
nueva arquitectura optimizada, que cumple las necesidades de la tecnología OO. Las
compañías como Versant, Objectivity, Itasca, etc. Utilizan esté enfoque y afirman que la
tecnología de relación es un subconjunto de una capacidad más general. Además que las
BDOO no de relación son aproximadamente dos veces más rápidas que las bases de datos por
relación para almacenar y recuperar la información compleja. Por lo tanto, son esenciales en
aplicaciones como CAD y permitirían que un depósito CASE fuera una facilidad de tiempo real
en vez de una facilidad por lotes.
 ARQUITECTURA
Las primeras BDOO se diseñaron como una extensión de los LOO como C++ o Smalltalk,
donde el DML y el DDL constituyen un lenguaje OO común.
Muchos de los elementos de bases relacionales son importantes en BDOO, entre ellos el
bloqueo para acceso concurrente, recuperación, compromiso de dos fases, seguridad, integridad de
datos, distribución de datos y herramientas de bases de datos.
 DESARROLLO UNIFICADO
71
El desarrollo tradicional de sistemas, utiliza cuatro modelos conceptuales diferentes. El análisis
genera matrices que asocian funciones con entidades. El diseño utiliza diagramas de flujo, tablas de
estructura y diagramas de acción. Los lenguajes tienen un modelo conceptual del código distinto. Y las
bases de datos relacionales utilizan otro modelo conceptual diferente a los anteriores.
Por el contrario el enfoque OO utiliza el mismo modelo de objetos en las fases de análisis,
diseño, programación y BDOO.
Este modelo unificado tiene las siguientes ventajas:

- Mayor productividad, se evita la traducción entre modelos.
- Menos errores, que surgen durante la transición entre modelos.
- Mejor comunicación entre analistas, implantadores y usuarios.
- Mejor calidad y mayor flexibilidad.
 VENTAJAS DE LAS BDOO
- flexibilidad y soporte para el manejo de tipos de datos complejos
- manipula datos complejos en forma rápida y ágil
 POSIBLES DESVENTAJAS
- Al considerar la adopción de la tecnología orientada a objetos, la inmadurez del mercado de
BDOO constituye una posible fuente de problemas por lo que debe analizarse con detalle la
presencia en el mercado del proveedor para adoptar su producto en una línea de producción
sustantiva.
- El segundo problema es la falta de estándares en la industria orientada a objetos.
 RENDIMIENTO
Las BDOO permiten que los objetos hagan referencia directamente a otro mediante
apuntadores suaves. Esto hace que las BDOO pasen más rápido del objeto A al objeto B que las BDR,
las cuales deben utilizar comandos JOIN para lograr esto. Incluso el JOIN optimizado es más lento que
un recorrido de los objetos. Así, incluso sin alguna afinación especial, una BDOO es en general más
rápida en esta mecánica de caza-apuntadores.
 ¿QUE ES UNA BDD?
Una Base de Datos Distribuida (BDD) es un conjunto de múltiples bases de datos lógicamente
relacionadas las cuales se encuentran distribuidas entre diferentes sitios interconectados por una red de
comunicaciones.
Un Sistema de Base de Datos Distribuida (SBDD) es un sistema en el cual múltiples sitios de

bases de datos están ligados por un sistema de comunicaciones, de tal forma que, un usuario en
cualquier sitio puede acceder los datos en cualquier parte de la red exactamente como si los datos
estuvieran almacenados en su sitio propio.
Un Sistema de Manejo de Base de Datos Distribuida (SMBDD) es aquel que se encarga del
manejo de la BDD y proporciona un mecanismo de acceso que hace que la distribución sea
transparente a los usuarios. Transparente significa que la aplicación trabajaría como si un solo SMBD
ejecutado en una sola máquina, administrara esos datos.
72
Un Sistema de Base de Datos Distribuida (SBDD) es entonces el resultado de la integración
de una base de datos distribuida con un sistema para su manejo.
Dada la definición anterior, es claro que algunos sistemas no se pueden considerar como
SBDD. Por ejemplo, un sistema de tiempo compartido no incluye necesariamente un sistema de
manejo de base de datos y, en caso de que lo haga, éste es controlado y administrado por una sola
computadora. Un sistema de multiprocesamiento puede administrar una base de datos pero lo hace
usualmente a través de un solo sistema de manejo de base de datos.
Finalmente una base de datos la cual reside en un solo sitio de una red de computadoras y que
es accesada por todos los nodos de la red, no es una base de datos distribuida. Este caso se trata de una
base de datos cuyo control y administración esta centralizada en un solo nodo pero se permite el
acceso a ella a través de la red de computadoras.
 PRINCIPIOS FUNDAMENTALES
Es posible expresar lo que podría considerarse como el principio fundamental de las BDD.
Desde el punto de vista del usuario, un sistema distribuido deberá ser idéntico a un sistema no
distribuido. Los usuarios del sistema distribuido deberán comportarse exactamente como si el sistema
no estuviera distribuido. A esto es lo que llamamos “la regla cero” de los sistemas distribuidos. Esta
conduce a varios objetivos o reglas secundarias; ellas son:
1.- Autonomía local

2.- No dependencia de un ciclo central
3.- Operación continua
4.- Independencia con respecto a la localización
5.- Independencia con respecto a la fragmentación
6.- Independencia de replica
7.- Procesamiento distribuido de consultas
8.- Manejo distribuido de transacciones
9.- Independencia con respecto al equipo
10.- Independencia con respecto al sistema operativo
11.- Independencia con respecto a la red
12.- Independencia con respecto al Manejo de Sistemas de Bases de Datos Distribuidas
 CARACTERÍSTICAS
• Los datos se pueden colocar físicamente en el lugar donde se accesan más frecuentemente,
haciendo que los usuarios tengan control local de los datos con los que interactúan. Esto resulta en
una autonomía local de datos permitiendo a los usuarios aplicar políticas locales respecto al tipo de
accesos a sus datos.
• Mediante la replicación de información, las bases de datos distribuidas pueden presentar cierto
grado de tolerancia a fallas haciendo que el funcionamiento del sistema no dependa de un solo
lugar como el caso de las bases de datos centralizadas.
 VENTAJAS
Los SMBDD tienen múltiples ventajas.
• Los datos son localizados en un lugar más cercano, por lo que el acceso es más rápido.
73
• El procesamiento es rápido debido a que varios nodos intervienen en el procesamiento de una
carga de trabajo.
• Nuevos nodos se pueden agregar fácil y rápidamente.
• La comunicación entre nodos se mejora.
• Los costos de operación se reducen.
• Son amigables al usuario.
• La probabilidad de que una falla en un solo nodo afecte al sistema es baja y existe una autonomía e
independencia entre los nodos.
 DESVENTAJAS
• La principal desventaja se refiere al control y manejo de los datos. Dado que éstos residen en
muchos nodos diferentes y se pueden consultar por nodos diversos de la red, la probabilidad de
violaciones de seguridad es creciente si no se toman las precauciones debidas.
• La habilidad para asegurar la integridad de la información en presencia de fallas no predecibles

tanto de componentes de hardware como de software es compleja. La integridad se refiere a la
consistencia, validez y exactitud de la información.
• Dado que los datos pueden estar replicados, el control de concurrencia y los mecanismos de
recuperación son mucho más complejos que en un sistema centralizado.
• Mayor tiempo extra de procesamiento: el intercambio de mensajes y los cálculos adicionales son
una forma de tiempo extra que no existe en los sistemas centralizados.
 DISEÑO DE BASES DE DATOS DISTRIBUIDAS
El problema de diseño de BDD se refiere a hacer decisiones acerca de la ubicación de datos y

programas a través de los diferentes sitios de una red de computadoras. La decisión de donde colocar a
las aplicaciones tiene que ver tanto con el software del SMBDD como con las aplicaciones que se van
a ejecutar sobre la base de datos
Cuando se trabaja con BDD se tienen que considerar los siguientes problemas:
1. El Diseño de la fragmentación. Este se determina por la forma en que las relaciones globales
se subdividen en fragmentos horizontales, verticales o mixtos.
2. El Diseño de la asignación de los fragmentos. Esto se determina en la forma en que los

fragmentos se mapean a las imágenes físicas, en esta forma, también se determina la solicitud
de fragmentos.
 ENFOQUES AL PROBLEMA DE DISEÑO DE BDD
Existen dos estrategias generales para abordar el problema de diseño de BDD:
1. El enfoque de arriba hacia abajo (top-down): Para aplicaciones nuevas. Consiste en

partir desde el análisis de requerimientos para definir el diseño conceptual y las vistas de usuario.
A partir de ellas se define un esquema conceptual global y los esquemas externos necesarios. Se
prosigue con el diseño de la fragmentación de la BD, y de aquí se continua con la localización de
74
los fragmentos en los sitios, creando las imágenes físicas. Luego, se completa ejecutando en cada
sitio, “el diseño físico” de los datos, que se localizan en éste.
2. El diseño de abajo hacia arriba (botton-up): Se utiliza particularmente a partir de

bases de datos existentes, generando a partir de ellas bases de datos distribuidas. El diseño
botton-up de una BDD requiere de la selección de un modelo de bases de datos común para
describir el esquema global de la base de datos. Esto se debe a que es posible que se utilicen
diferentes SMBD. Después se hace la traducción de cada esquema local en el modelo de datos
común y finalmente se hace la integración del esquema local en un esquema global común.
El diseño de una Base de Datos Distribuida, cualquiera sea el enfoque que se siga, debe
responder satisfactoriamente las siguientes preguntas: ¿Porqué hacer una fragmentación de datos?,
¿cómo realizar la fragmentación?, ¿qué tanto se debe fragmentar?, ¿cómo probar la validez de una
fragmentación?, ¿cómo realizar la asignación de fragmentos?, ¿cómo considerar los requerimientos de
la información?
75

Bases de Datos (Apuntes)

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Bases de Datos (Apuntes)

Загружено:

Авторское право:

Доступные форматы

BASES DE DATOS –– APUNTES

 UNIDAD Nº 1: INTRODUCCIÓN A LAS BASES DE DATOS

1) Definición: Una BD es un conjunto de datos almacenados en conjunto, sin redundancias

Otra definición: Sistema de mantenimiento de registros basado en computadoras, cuyo interés es

Una BD tiene las siguientes propiedades implícitas:

2) Características del enfoque de BD

• Naturaleza auto descriptiva de los Sistemas de BD

• Separación entre los programas y los datos, y abstracción de los datos

• Manejo de múltiples vistas de los datos

• Compartimiento de datos y procesamiento de transacciones multiusuario

2) Actores de una BD:

- Diseñadores de BD: se encargan de identificar los datos que se almacenarán en la BD y de elegir

- Usuarios finales: pueden ser:

• Sistema de gestión de Base de Datos (SGBD)

Soft del Software para procesar

Software para acceder a los

Definición de la Base de datos

Definición de la estructura de Base Solo datos

• Características deseables de un SGBD

 Control de redundancia: se refiere a la redundancia en el almacenamiento de los datos. Este

 Cumplimiento de las restricciones de integridad: la mayor parte de las aplicaciones de base de

 Modelos de datos, esquemas y ejemplares:

Una característica fundamental del enfoque de BD es que proporciona cierto nivel de

Los modelos pueden ser de distinto tipo:

Los conceptos que definen son los siguientes:

- simples: están compuestos por un atributo nada más. Ej. Día

- multivaluados: pueden tomar muchos valores. Ej. Carrera

- almacenados: todos los atributos son almacenados.

1. los que identifican a la entidad (como la patente)

El valor nos permite instanciar

Ej. Legajo 100 - 3000

Tomando el siguiente ejemplo:

Podemos dar el concepto de atributo multivaluado. Un curso puede ser dictado

Un atributo puede identificar unívocamente a cada miembro de la entidad, es un identificador

Los vínculos pueden ser de distinto tipo:

VÍNCULOS INCONDICIONALES: Por ejemplo tenemos dos entidades A y B de alumnos. Cuando

UNO CONDICIONAL A MUCHOS CONDICIONAL: cuando cada instancia de A se relaciona con

MUCHOS CONDICIONAL A MUCHOS CONDICIONAL: cuando cada instancia de A se

A su vez, los vínculos pueden ser:

A su vez, los vínculos binarios pueden ser:

La Cardinalidad puede ser:

Es importante distinguir entre la descripción de la BD y la BD misma.

El esquema puede representarse mediante un diagrama denominado diagrama de esquema. Este

La distinción entre esquema y el estado de la BD es muy importante. Cuando definimos una

BASE DE DATOS <> descripción de la BASE DE DATOS

Valores almacenados Catálogo de datos

- Base de datos almacenada

Romina, Jorge y Carlos son distintas instancias de la BD ALUMNOS.

Se puede representar también:

Primero debemos definir el esquema.

Lo que si cambia es el estado de la BD.

Habíamos visto ya las características:

NIVEL Vista Externa 1 Vista Externa n

 Independencia respecto a los datos: se define como la capacidad de modificar el esquema en un

- Independencia lógica: significa modificar el esquema conceptual sin modificar los

- Independencia física: significa modificar el nivel interno sin necesidad de modificar el

 Lenguajes e interfaces de Bases de Datos:

• Lenguajes del SGBD

 Clasificación de los SGBD:

Un Sistema es relacional si:

- La información se muestra a los usuarios como tablas de datos.

 Elementos de un Modelo Relacional:

- Elementos Estructurales: definen las estructuras de datos que soporta el modelo.

El número de atributos define el grado de una relación.