Introducción Al Modelo Relacional

BD_I
Bases de Datos para Emprendedores

Lic. Juan Ravera (MC) - 2001
Clase Nmero 1
ndice
Presentacin
Qu es una base de datos?
Niveles de aproximacin
Fsico
De Visin
Conceptual
Los Componentes
Entidades
Atributos
Valores
Presentacin
Bienvenido al mundo de las bases de datos. En esta primer clase comenzaremos a conocer
qu son realmente estas herramientas a las que llamamos "bases de datos", en qu se
diferencian de las manipulaciones que hacemos con otras herramientas dentro del computador y
en particular, con planillas electrnicas y procesadores de texto.
Estamos acostumbrados a operar ordenadores, nos son familiares los procesadores de palabras,
planillas electrnicas, herramientas de dibujo, generadores de presentaciones. Todas estas
herramientas tienen un denominador comn: su funcionamiento bsico se nos manifiesta en
forma casi intuitiva. Cuando nos enfrentamos por primera vez a un procesador de palabras, tal
vez no sabamos de qu forma centrar un ttulo o ajustar un margen o imprimir, pero lo que s
estaba claro era que la pantalla representaba una hoja de papel y que nosotros debamos escribir
en ella. En el caso de las planillas electrnicas sucede algo similar. An recuerdo mi primer
contacto con .... "Visi Calc" sobre una Apple IIc. Recuerdo no tener la menor idea de como fijar
una columna, realizar unas pocas cuentas sencillas o imprimir en estas herramientas casi
prehistricas; pero no haba ninguna duda que ella estaba hecha para manipular nmeros
ordenados bajo la forma de filas y columnas, que adems estn all a nuestra vista para
revisarlos todas las veces que quisiramos. Cosas similares ocurren con casi todas las
herramientas de escritorio que comnmente tenemos en nuestros computadores excepto con ese
engendro diablico al que llamamos "Access".
"Access" la base de datos de escritorio de Microsoft se ha convertido en un convidado de piedra

de una buena parte de las instalaciones del conjunto de programas integrados llamado "Microsoft
file:///E|/DESK/Educacin/Educacin a Distancia/Cur...ndedores/Mdulo 1 Introduccin/Clase 1/Bde_0101.htm (1 of 9) [12/11/2001 15:12:57]

BD_I
Office", del que ya estamos disfrutando su versin 2.000. Su presentacin si bien es atractiva,
dispone de una multitud de asistentes (que por supuesto debo saber utilizar) que me ayudarn a
construir las aplicaciones sencillas, muy vistosas, tiles para comenzar a comprender la
herramienta, pero de muy escasa utilidad prctica. Adems, qu sucede cuando quiero realizar
alguna modificacin a las aplicaciones construidas por el asistente o lo que es peor an, creo que
los datos con los que trabajan las pantallas que veo no se adecuan exactamente a mis
necesidades? En ese momento me cae encima la supuesta complejidad de Access que da por
tierra con mis mejores intenciones de construir mi aplicacin de bases de datos y vuelvo a buscar
el refugio de la planilla electrnica, an teniendo que soportar todos sus riesgos de operacin y
limitaciones que algunas horas antes me hicieron pensar en pasar mi trabajo a una base de
datos.
Comenzaremos pues definiendo de una forma totalmente prctica a las bases de datos:
Qu es una base de datos?

No es ocioso decir que una buena definicin del objeto de estudio nos ayuda a aprehender su
esencia y funcionamiento. He aqu una definicin a nuestro entender correcta de lo que es
una Base de Datos:
"Es una coleccin de datos interrelacionados almacenados en

conjunto sin redundancias perjudiciales o innecesarias; su
finalidad es la de servir a una aplicacin o ms, de la mejor
manera posible; los datos se almacenan de modo que resulten
independientes de los programas que los usan; se emplean
mtodos bien determinados para incluir datos nuevos y para
modificar o extraer los datos almacenados".
JAMES MARTIN op. cit. Pgina 19
Analicemos cada uno de los componentes de esta definicin, que dado lo avanzado de su edad
(data de la segunda mitad de la dcada del 70) ya pocas personas se molestan en discutir. Datos
interrelacionados almacenados en conjunto, es decir, que no slo me interesar el agrupamiento
de datos vinculados a un mismo problema, sino que procurar establecer las adecuadas
relaciones entre ellos de forma de optimizar su utilizacin (Access me ayudar mucho en esto).
Esto es esencial a la hora de comprender la esencia del modelo de datos utilizado por Access
("Modelo Relacional de Datos" propuesto por Codd op. cit. pg. 64). Por ejemplo, si en una
planilla electrnica tengo una lista clientes con sus respectivas compras, una fila de la planilla
tendr normalmente a la izquierda una columna con los nombres de los clientes y a la derecha
un conjunto de columnas con los datos vinculados a stos que me interese registrar. La relacin
entre ellos est dada justamente por pertenecer todos los datos relacionados a un cliente a la
misma fila de la planilla.

BD_I
Note que las cifras que aparecen bajo los meses de Enero, Febrero y Marzo, son asociadas en
forma intuitiva a los clientes en su respectiva fila. Los US$ 548 de celda B4 pertenecen para
nosotros a la firma "Alonso & Mario", justamente porque sta est nombrada en la fila 4, en
ningn momento se nos ocurre pensar que dicho monto pertenece a la firma "Bravo, Enrique"
que se encuentra en la fila 7. Veremos ms adelante que en un ambiente de bases de datos,
muy probablemente los clientes y sus montos de compra se encuentren en estructuras diferentes
y ser por lo tanto necesario encontrar alguna forma de relacionar a stos con aquellos.
Siguiendo con nuestro anlisis de la definicin, vemos las palabras "sin redundancias
perjudiciales o innecesarias", esto es, si bien las cosas se almacenan una sola vez, habr algunos
datos que necesitar repetir para mantener las relaciones entre las diferentes colecciones de
datos. A modo de ejemplo y como adelanto, si en el ejemplo anterior separamos la lista de
clientes en una estructura y la de sus compras en otra, ser necesario agregar a la lista de
compras algn dato que nos informe qu cliente fue el que compr, puesto que las cifras de
compra por s mismas no nos dicen nada. De esta forma guardaremos el nombre de nuestros
clientes una sola vez y buscaremos sus datos cada vez que los necesitemos, pero agregando
algn identificador del tipo de "Nmero de Cliente" para poder relacionarlo con las compras que
nos ha realizado, los cheques que nos ha emitido o los pedidos que nos ha enviado. De esta
forma se podr cumplir con la parte de la definicin que pide "servir a una aplicacin o ms".
Luego un aspecto fundamental de las bases de datos: "los datos se almacenan de modo que
resulten independientes de los programas que los usan", lo cual quiere decir que cuando
diseamos una base de datos debemos (hasta cierto punto) hacer abstraccin de la utilizacin
final que haremos en ese momento de los datos y debemos pensar de una forma ms genrica,
en trminos de la empresa o departamento en el que nos encontramos, para que luego esos
mismos datos puedan ser utilizados para otras funciones. La ltima parte de la definicin apunta
a indicarnos que debemos ser sumamente prolijos a la hora de describir las cosas que hemos
hecho en la base de datos y por qu lo hemos hecho. Pocas cosas son ms engorrosas de
resolver (si ello es posible) en un ambiente de oficina que una coleccin de datos inconsistentes.
En general este trabajo supera con mucho el esfuerzo utilizado en almacenar dichos datos, por lo
que siempre ser poco el esfuerzo que hagamos en este sentido.
El logro de estos loables objetivos que se expresan en la definicin es alcanzable a partir que las
empresas desarrollaron productos de mercado que permitan llevarlos a la prctica. En particular,

BD_I
todo se reduce a la creacin de una capa de programacin a la que llamamos "Administrador de

la Base de Datos" cuya funcin es independizar a los usuario del mantenimiento de los datos y
las relaciones entre ellos, as como su integridad y control.
La siguiente figura es un esquema general del funcionamiento de un Administrador de Bases de

Datos (como por ejemplo "Access").
Niveles de aproximacin al modelo de

Bases de Datos
Describimos las bases de datos modernas en tres niveles de abstraccin:
Nivel Fsico
Nivel de Visin
Nivel Conceptual
Cada uno de ellos aporta una parte de la concepcin del modelo que pasaremos a ver a
continuacin:
Nivel Fsico
Es el nivel ms bajo de abstraccin, en el que se describe cmo se almacenan realmente los

BD_I
datos. En este nivel

se describen en
detalle las
estructuras de datos
complejas y sus
relaciones a nivel
fsico.
Es en este nivel
donde se describen
y mantienen las
estructuras bsicas
de cualquier modelo
de bases de datos:
LAS TABLAS. En
siguientes captulos
veremos cmo
definirlas y
relacionarlas de
forma que nuestro
modelo de datos
sea a la vez slido y
flexible.
Nivel de visin:
Comprende las vistas que cada uno de los usuarios tiene del sistema. Este nivel incluye lo que el
usuario ve de la Base de Datos, as como las herramientas o programas que utiliza para su
trabajo. Las vistas renen datos de varias tablas (y/o otras vistas), pero no consumen espacio
adicional. Guardar una vista es algo as como guardar una frmula de seleccin de datos que se
aplicar cada vez que yo ejecute la vista. En ambiente Access, las vistas se llaman CONSULTAS y
es as como las llamaremos en adelante. Note que una tabla en el repositorio puede (y de hecho
es lo que normalmente hace) aportar datos a ms de una vista en forma simultnea. Es el propio
Access quin se encargar de mantener la integridad de la informacin mostrada.
Por ejemplo, una

biblioteca lleva un
registro de los
estudiantes que
retiran libros y de
los libros mismos en
dos tablas que son
estructuras
independientes en el
nivel fsico de la
base de datos. Una

BD_I
vez al da la
bibliotecaria
encargada de
prstamos emite un
listado que eleva a
la Direccin
conteniendo la lista
de aquellos alumnos
que teniendo libros
prestados se
encuentran en
situacin de mora.
Este listado, cuyo contenido vara da a da, no se almacena como tal en el computador, sino
como una vista o CONSULTA que se ejecutar a los efectos de proporcionar la informacin
actualizada cada vez. La consulta rene informacin de las tablas de LIBROS y ESTUDIANTES,
selecciona aquellos estudiantes que se encuentran en situacin de mora comparando la fecha de
devolucin de los libros que an tienen en su poder y la fecha actual (almacenada en el
computador) y con todos estos datos genera la consulta correspondiente que ser la entrada de
datos (input) del listado a emitirse.
Nivel Conceptual
Comprende
el conjunto
de documentos
y
especificaciones
que describen la
estructura y
funcionamiento
del sistema, as
como todas sus
modificaciones y
actualizaciones.
En proyectos de
mediano porte
este nivel
consume ms del 50% de los recursos aplicados al mismo.
Estamos realizando aqu una ampliacin al concepto tradicional de "nivel conceptual" procurando
hacer evidente para usted la importancia que tiene la descripcin de las decisiones de diseo que
se toman en el funcionamiento futuro de la base de datos. En nuestro ejemplo de la biblioteca, si
uno de los datos guardados en la base de datos es la fecha de devolucin y esto se realiz
creando un lugar en ella llamado: DEVOLUCIN, luego que pasen algunos meses y tal vez
cambie el personal encargado del mantenimiento, a qu se refiere la palabra DEVOLUCIN, a la
fecha en la que el libro debe ser devuelto, a aquella en la que realmente se devolvi, a la nueva
fecha pactada luego de incurrir en mora, o indica que el libro puede ser prestado y por tanto no
es exclusivamente de lectura en sala, o...
Esta lista de opciones se puede alargar tanto como se quiera para cada dato que se almacene,
casi sin importar el cuidado que se haya puesto al nombrarlo. Solamente una cuidadosa
descripcin de su contenido, los rangos de valores que puede adoptar, el tipo de datos que
contendr, la fecha y responsable de su creacin, el propsito para el que fue creado, y la
anotacin de cada una de las modificaciones que se le hagan, asegurarn razonablemente que

BD_I
los modelos de datos que se construyan sern utilizables en el mediano y largo plazo. Esta
informacin se guarda en un documento al que llamamos "Diccionario de Datos" y cuya
estructura tomaremos de la propuesta que nos hace Access.
En este momento ha recibido usted la informacin necesaria para comenzar con el proceso de
diseo de una base de datos. Este proceso tiene dos etapas claramente diferenciadas:
Definir el problema a resolver (especificarlo formalmente)
Resolverlo (construir la base de datos, las tablas, las relaciones, las pantallas de ingreso de
datos, los listados y reportes, ...)
Los componentes del modelo de Bases de Datos

Abordaremos un problema cualquiera para resolverlo en una base de datos, analizando su
realidad en trminos de
ENTIDADES
ATRIBUTOS
VALORES
Las ENTIDADES
Llamaremos ENTIDADES a cualquier coleccin de objetos del mundo real que sean
razonablemente similares entre s cuya presencia sea relevante en el mbito del problema
que estoy resolviendo. Por lo tanto, utilizaremos el mecanismo de la definicin de las ENTIDADES
para establecer cules son las colecciones de objetos relevantes que luego tendr que considerar
en mi diseo de datos. Cuando lleguemos a Access, las ENTIDADES se convertirn en TABLAS
dentro de la base de datos. Es de destacar que para la descripcin de una ENTIDAD o coleccin
de objetos, a veces es necesaria ms de una tabla. Veremos esto en detalle ms adelante.
Son ejemplos de entidades:
personas
artculos
facturas
terrenos
automviles
pasajes
Note que la calidad de "entidad" aparece cuando hay un conjunto o una coleccin de elementos
como los antes descriptos. La entidad "terrenos" existir para una empresa inmobiliaria que
comercializa espacios en una nueva urbanizacin, mientras que si en uno de ellos se instala un
comercio de venta de ropa para nios, el terreno ya no ser considerado como una entidad,
puesto que ha perdido el carcter de miembro de una coleccin para esta nueva situacin. Para
este comercio, las entidades sern del tipo de clientes, artculos y facturas.

BD_I
Es de gran importancia encontrar la totalidad de las colecciones necesarias para el trabajo de

base de datos en el que est embarcado desde el comienzo del anlisis. Considere siempre que
cuando subsanamos un olvido o imprevisin siempre pagamos el costo de arreglar lo ya hecho
para que acepte el nuevo agregado y siga funcionando. Imagine por ejemplo que una fbrica de
automviles lanza un nuevo modelo al mercado y en el momento de su revisin final al primero
de una larga fila de autos para la venta, el encargado de calidad se percata que el auto .... se
construy sin sistema de refrigeracin para el motor. Ms all que en este ejemplo a todas vistas
exagerado los gerentes y supervisores involucrados estarn buscando trabajo en menos tiempo
de lo que se tarda en decirlo, la reparacin del error hubiese sido mucho menos costosa si el
olvido se hubiese notado antes que la lnea de montaje comenzara a producir, y lo habra sido
an menos si se hubiera notado en el momento del diseo y construccin del prototipo, y an
menos si se hubiese notado durante la confeccin de los planos. Por supuesto que esta funcin
del automvil debi haber estado presente desde el primer boceto preliminar, y con ello su costo
de construccin sera el mnimo posible. Con las bases de datos sucede algo similar, el momento
ms barato para incorporar un requerimiento nuevo o una modificacin de diseo es al comienzo
del proyecto, y si ello no llegara a ocurrir, pues entonces en cuanto se detecte, para que su
impacto sobre lo ya construido o diseado sea el mnimo posible.
Como contraparte a lo antes mencionado, es necesario que no definamos ms entidades de las

realmente necesarias, pues en ese caso estaremos aumentando en forma no despreciable el
presupuesto de nuestro proyecto, su cantidad de funciones, su riesgo de fallas, sin que por ello
aumenten las ventajas que el sistema final nos brinde.
Los ATRIBUTOS
Una vez que hemos determinado cuales son las colecciones o "ENTIDADES" necesarias para
construir mi base de datos, deberemos dedicarnos a analizar de cada una de ellas. Para ello
determinaremos cules son las caractersticas de esos objetos que nos interesan para registrar
en mi futuro modelo de datos. Es a estas caractersticas a las que llamaremos "ATRIBUTOS".
Definimos ATRIBUTOS como aquellas caractersticas o cualidades de las ENTIDADES que

aparecen como relevantes al problema que estoy tratando. Debe haber aqu un proceso
cuidadoso de seleccin de caractersticas; hay que evitar la tentacin del "ya que estamos...".
Este paso es necesario para determinar cules de todos los adjetivos aplicables a un objeto son
relevantes para resolver o administrar el problema que estoy resolviendo. Aqu hay situaciones
obvias por s mismas como por ejemplo queda claro que en una coleccin de
FACTURAS
sern relevantes atributos tales como:
NUMERO_DE_FACTURA
FECHA_DE_EMISION
y no su:
TIPO_DE_PAPEL
PIE_DE_IMPRENTA
pero, no olvidemos que tambin hay casos no tan evidentes que tendremos que analizar con ms
cuidado. Si suponemos que quin est realizando el anlisis es el empresario que utilizar las

BD_I
facturas como herramienta de trabajo de su negocio, lo anterior el perfectamente vlido. Ahora,

si suponemos que el que est trabajando es el dueo de la imprenta haciendo un modelo de
datos para los trabajos de sus clientes, entonces tal vez los atributos descartados tengan
importancia y sea necesario incorporarlos.
Tal es el caso de, por ejemplo una coleccin de LIBROS en la cual habr que resolver si se
incorporan ATRIBUTOS como cantidad de pginas, o tipo de papel, en el caso en que se vayan a
tomar precauciones para su adecuada conservacin.
Tmese como criterio base para la eleccin de los atributos el que sean necesarios para
la menos una de las operaciones que se realizarn con las ENTIDADES a las que
pertenecen.
Los VALORES
Entendemos por VALORES las instancias de datos reales para un ATRIBUTO. Por ejemplo el
dato "Lpez, Anbal" es el VALOR que toma el ATRIBUTO "NOMBRE_CLIENTE" para el cliente
1243. Aqu es importante destacar que una vez que se define un ATRIBUTO, es necesario que los
valores que en l se almacenen sean del mismo tipo. Si tengo definido el atributo TELFONO
para una ENTIDAD CLIENTES y de un cliente determinado no dispongo de su telfono, sino de su
e-mail, entonces, o bien me falt definir un ATRIBUTO en CLIENTES, llamado E_MAIL o no pongo
nada pero NUNCA ... repito .... N U N C A mezclo valores que correspondan a clases de datos
diferentes dentro de un mismo ATRIBUTO.
Una de las cosas ms desagradables con las que nos solemos encontrar cuando analizamos
modelos de datos que se encuentran trabajando desde a veces mucho tiempo es la falta de
cuidado en el llenado de los valores en los distintos atributos. Desde faltas menores, aunque
ciertamente de correccin engorrosa como cambiar los lugares del nombre y el apellido de las
personas hasta errores conceptuales graves como utilizar el atributo telfono para guardar por
ejemplo la direccin de e-mail, o el telfono celular.
Uno podra decir ... y al fin y al cabo qu me importa si cambio algunos contenidos? Y bueno, si
no se har ms que consultar estos datos en pantalla y alguna vez imprimirlos, vaya y pase, la
cosa camina sin problemas. Pero cuando estamos en una situacin de empresa, no sera raro que
el empresario o responsable de marketing, procurara por ejemplo realizar alguna campaa
telefnica a clientes que viven en determinada zona de la ciudad y una de las mejores formas de
"zonificar" clientes es el tratamiento automtico de sus nmeros de telfono. Claro, esto se
puede hacer slo si he sido prolijo a la hora de ingresar dichos VALORES en mi base de datos.
Fin de la Clase 1

BD_I
Bases de datos para emprendedores

Clase Nmero 2
ndice
Resumen Mdulos
Presentacin de Access 2000 Favoritos
Creando nuestra primer base de datos Lista de componentes
Los componentes de la ventana de base de datos
Hoja de Relaciones
de Access 2000
Opcin Abrir Definicin de tablas en una B. Datos
Opcin Diseo Base de Datos
Opcin Nuevo Tabla
Tablas Campo
Consultas Claves
Formularios Clave Primaria
Informes Claves Alternativas
Pginas Claves Secundarias
Macros Resu
Este captulo le presentar una introduccin a Access 2000 comenzando con los aspectos prcticos del
curso. No se preocupe si recibe demasiada informacin en una sola clase, sta le servir luego como
referencia para construir nuestras aplicaciones.
Presentacin de Access 2000
Access 2000 es la herramienta de bases de datos de Microsoft para pequeas aplicaciones.

Actualmente lo de pequeas aplicaciones es relativo, puesto que podemos en ella soportar sin problemas
bases de datos de ms de un milln de registros, cantidad ms que suficiente para la mayora de las
aplicaciones que necesitemos.
Desde el punto de vista de su estructura, Access 2000 cuenta con un conjunto de herramientas de diseo
y programacin que le permitirn con mnimos conocimientos realizar un sinnmero de aplicaciones en su
empresa. Como toda herramienta de bases de datos, Access trabaja con archivos que almacena en el
disco duro de su computador. En su caso cada vez que usted crea una base de datos, Access le solicita un
nombre que deber tener extensin ".mdb" (Microsoft Data Base):
miBaseDeDatos.mdb
Este archivo es el que contiene toda la informacin referente a nuestro trabajo. La figura 1 muestra un
esquema de su contenido, el que ser descripto ms adelante en esta clase.
file:///E|/DESK/Educacin/Educacin a Distancia/Cu...dedores/Mdulo 1 Introduccin/Clase 2/Bde_0102.htm (1 of 18) [12/11/2001 15:14:07]

BD_I
Creando nuestra primer Base de Datos
Lo primero que debemos hacer es responder a la solicitud de Access sobre la base de datos a abrir o
crear, dicindole que queremos construir una nueva base de datos. Para ello tomamos la opcin: "Base de
datos de Access en blanco" y aceptamos
Una vez aceptada la opcin, creamos una carpeta en el disco duro llamada "CursoBD" en la que
colocaremos los trabajos que vayamos realizando. Una de las formas de crear dicha carpeta es mediante
el botn "Crear nueva carpeta" que nos presenta la ventana.

BD_I
Corresponde ahora que aceptemos la creacin de la carpeta "CursoDB" y que luego creemos con el botn
"Crear" la nueva base de datos.
Una vez realizado sto, estamos en condiciones de comenzar a utilizar Access. Notemos que esta no es
una herramienta como Word o Excel que nos permiten comenzar a trabajar con una hoja en blanco y con
un nombre genrico. Aqu tenemos que crear fsicamente en el disco duro la base de datos para poder
comenzar a utilizarla.
Para esta primera etapa y dependiendo de cmo est configurado Access, ste le presentar al comienzo y
sobrepuesta a la ventana principal, una ventana a la que llama "Cuadro de dilogo de Inicio" que le
permite abrir una aplicacin ya construida o iniciar un nuevo trabajo. En caso que no le aparezca esta
ventana lo que debe usted hacer es sencillamente seguir la siguiente secuencia desde el men principal de
Access:
Una vez que haya hecho esto, en la parte inferior de la ventana busque el cuadro combinado "Nombre del
archivo:" y sustituya el que le ofrece Access (por ejemplo "bd1.mdb") por otro que nos recuerde con ms
precisin el contenido de dicha base:
miBaseDeDatos.mdb
Finalmente presione el botn "Crear" y Access crear una base de datos vaca con ese
nombre en el lugar elegido. La nueva base creada queda abierta y Access nos muestra la ventana de
trabajo con ella. Esta ventana es parte de la interfaz de Access y nos iremos acostumbrando a ella durante
el curso.
Una vez creada, la base de datos est preparada para contener una serie de objetos que utilizaremos para
trabajar y que iremos definiendo puntualmente. Un detalle de los nombres y ubicacin de cada uno de
estos objetos puede verse en la figura 1

BD_I
Los componentes de la ventana de base de datos de Access

2000
En primer lugar daremos un vistazo a los componentes de la ventana principal de una base de datos
Access.
Lo que nos queda en pantalla es lo siguiente:
Lo general de la pantalla: en la ventana llamada "Base de Datos" (la interior) se encuentran ubicados
todos los elementos que van a formar parte de la base de datos. Esta ventana est dividida en tres
sectores, a saber:
un menu superior de opciones
un panel izquierdo para la eleccin de los componentes
un panel derecho (blanco) para mostrar la lista de los componentes.
VENTANA DE BASE DE DATOS

BD_I
Analicemos ahora uno a uno cada elemento relevante:
1 Opcin Abrir
Utilizaremos esta opcin para poner en funcionamiento o ver el contenido de

un objeto de la base de datos. Por ejemplo, si pedimos abrir un formulario, lo
veremos funcionando en pantalla, si pedimos abrir una tabla, veremos sus datos
en la forma en la que fueron ingresados y si pedimos ver un informe, veremos una
vista previa del listado que hayamos seleccionado. Para que la opcin "Abrir" est
habilitada, es necesario que hayamos previamente seleccionado un objeto
cualquiera.
2 Opcin Diseo
Todos los objetos que forman parte de una base de datos se pueden ver en
dos modalidades, lo que llamaramos modo funcionamiento, representado por la
opcin anterior "Abrir" y el llamado modo "Diseo" mediante el cual somos
capaces de modificar la estructura del objeto que estamos seleccionando en ese
momento. A modo de ejemplo, si coloco en modo diseo una tabla, puedo agregar
o eliminar un campo, cambiar el nombre de uno o varios de stos, agregar o
eliminar claves, entre otros. Al igual que la opcin "Abrir" la opcin "Diseo" se
activa o desactiva automticamente dependiendo de si puede ser utilizada o no. A
este tipo de comportamientos se los conoce como "sensibles al contexto".

BD_I
3 Opcin Nuevo
Es la opcin a travs de la cual creo nuevos objetos dentro de la base de datos. Esta opcin siempre
est habilitada, debido a que siempre es posible agregar un nuevo objeto a la base de datos. El tipo de
objeto que se agregar depende del panel en el que me encuentre en ese momento y siempre pueden ser
insertados mediante el men "Insertar" de Access.
La opcin "Nuevo" me coloca ante la posibilidad de utilizar o no un asistente para la creacin del objeto.
Los "Asistentes" son ayudantes automticos para la creacin de tablas, consultas, formularios, informes.
Debemos de ir contestando a sus requerimientos, y ellos nos darn como resultado el objeto que estamos
buscando. La utilizacin de los asistentes es sumamente prctica al comienzo del aprendizaje, dado que
permite avanzar con nuestras aplicaciones en forma rpida y confiable, aunque a medida que vayamos
adquiriendo experiencia, veremos que cada vez con ms frecuencia necesitamos de los objetos cosas que
sus "Asistentes" no nos pueden proveer, por lo tanto asumiremos la poltica de utilizarlos junto con la
modalidad diseo de forma de completar nuestro panorama de destrezas en la herramienta.
4 Tablas
Seleccionando esta opcin, logramos que el panel derecho, (lista de componentes; opcin 12) nos
muestre la totalidad de las tablas que tenemos definidas en nuestra base de datos. Aqu podemos utilizar
las opciones de ver el contenido de una tabla, crear una nueva, o modificar el contenido de una ya
existente. Como ya hemos visto, las tablas son los elementos bsicos de almacenamiento de datos en una
Base de Datos, por lo que es de sumo inters que utilicemos correctamente estos objetos. Cada tabla
podr tener un nombre de hasta 64 caracteres de largo. No obstante ello, le
recomendamos ser prudente a la hora de nombrar las tablas, dado que le resultar
ms fcil recordar nombres ms bien cortos que largos.
5 Consultas
Las consultas son un componente tpico del nivel de visin de la BD. Son las
estructuras que permiten que muchos usuarios distintos tengan visiones diferentes
de los mismos datos. Una consulta nos servir para mostrar juntos datos de varias
tablas en el orden que nosotros deseemos. Lo ms importante de las consultas es
que en realidad no almacenan datos, sino que solo guardan las especificaciones
que nosotros pedimos y recogen los datos cada vez que las ejecutamos. Esto
reporta dos ventajas importantes: no consumen espacio adicional y los datos en
ellas siempre estn actualizados, pues se toman de las tablas cada vez. Como
contraparte, dado que la consulta se construye en el momento que se la solicita,
es posible que el tiempo de respuesta crezca en forma significativa.
6 Formularios
Los formularios o ventanas son los objetos de nuestra aplicacin que me permitirn
acceder a los datos almacenados en la base de datos tanto para consultar, como para
agregar, modificar o borrar datos dentro de ella. Una pantalla que permite por ejemplo el
ingreso de datos de un nuevo cliente a una base de datos, es una suerte de ventana o
camino de acceso hacia los datos almacenados en la tabla de "Clientes" de forma de
permitir su actualizacin. La siguiente figura es una aclaracin o detalle de lo mostrado
en la figura 1.

BD_I
7 Informes
Los informes o listados operan en forma anloga a los formularios. En ellos no es

posible modificar datos pero s acceder a cualquier combinacin de datos de la base de
datos. La figura 3 muestra en detalle el acceso a datos de un informe.

BD_I
8 Pginas
Utilizaremos esta opcin para la creacin de pginas web que nos permitan
colocar parte de nuestra aplicacin disponible para que otros usuarios la consulten
desde la Internet. Por ejemplo se pueden colocar listas de precios, formularios de
compra, registros de afiliacin, entre otros.
9 Macros
Las "Macros" podemos verlas como herramientas que se encuentran en medio
de la utilizacin especializada de un programa cualquiera (Access, Word, Excel) y
el entrar ya de lleno en temas de programacin en Visual Basic. Nos sern de gran
utilidad a la hora de asignar funciones que deban ser realizadas al apretar botones
y otras que veremos a lo largo del curso. Para aquellos que gustan de las
definiciones, una macro sera algo as como: una cierta tarea que resume un
conjunto de digitaciones o pulsaciones del ratn y que pueden ser ejecutadas en
forma de "lote" mediante la invocacin de su nombre.
10 Mdulos
Los mdulos son porciones de cdigo de programacin escritos en Visual Basic.

Representan la unin entre Access y Visual Basic. En este curso realizaremos una
introduccin a estas tcnicas mediante la construccin de los ejemplos y
aplicaciones en su forma ms avanzada.

BD_I
11 Favoritos
Es una ventana muy prctica puesto que en ella almacenamos "accesos directos" los
mismos de Windows que hacen referencia a los objetos contenidos en las otras ventanas.
Le colocamos datos simplemente arrastrando un objeto cualquiera, (tabla, formulario,
informe, mdulo, macro, consulta) desde su lugar de origen hacia la etiqueta "Favoritos"
sobre el sector izquierdo de la ventana. De esta forma cada vez que queramos trabajar con
un subconjuntos de objetos de nuestra aplicacin, podemos fcilmente reunirlos todos
aqu y trabajar con ms comodidad. De ms est deicr que cuando borro algo de la
ventana de "Favoritos" no elimino el objeto en s, sino que simplemente deja de estar
clasificado como "Favorito".
12 Lista de componentes
La lista de componente o panel derecho de la ventana de base de datos, nos permite

ver los objetos que existan del tipo que tengamos seleccionado del lado izquierdo. Por
ejemplo si tenemos elegida la opcin 6 "Formularios", entonces aqu tendremos la lista
completa de los formularios definidos en la base de datos. Es sobre el formulario que
tengamos seleccionado que se aplicarn los botones mencionados en 1 y 2, "Abrir" y
"Diseo" respectivamente.
13 Hoja de relaciones
Es la hoja o ventana de Access en la que se construyen las relaciones entre las tablas.
Su funcionamiento, que ser visto en detalla ms adelante, asegura que podremos
establecer todas las relaciones necesarias entre los datos de nuestras "Entidades". Una vez
que tengamos construidas las relaciones entre los distintos almacenamientos, Access ser
el responsable de mantener la integridad de las mismas permitiendo slo las operaciones
con los datos que no violen ninguna de las relaciones establecidas.
Definicin de tablas en una base de datos.
Hasta ahora hemos hablado en forma genrica de lo que son las bases de datos. En la clase pasada,
aprendimos la forma de aproximarnos al modelo de bases de datos a travs de la definicin de
ENTIDADES, ATRIBUTOS y VALORES. En esta sesin veremos la forma en la que estos conceptos se
trasladan a una base de datos real como es el caso de Access.
En primer lugar retomemos la idea que ya manejamos, comparando una base de datos con una planilla
electrnica. En el caso de una planilla como la anterior disponemos de una gran libertad para ordenar los
datos de la forma que nos plazca dentro de la grilla. Poco le importa a la planilla si el ttulo del libro de F.
G. Lorca "La Zapatera Prodigiosa" se encuentra en la fila 5 columna A o en cualquier otra parte, dado que
para el procesamiento de los datos slo le alcanza con que la informacin pueda ser referenciada a travs
de direcciones de celdas. Adems en una planilla electrnica (en general) yo tengo todos los datos que
necesito para el proceso que voy a realizar sean stos principales o secundarios.

BD_I
Realizamos estas aclaraciones dado que en el modelo de bases de datos, la informacin se almacenar
tambin en forma tabular como en la planilla, la siguientes figura nos muestra los mismos datos de la
planilla anterior almacenados en una base de datos. Esta forma de almacenamiento tiene algunas
caractersticas diferentes que pasamos a sealar.
En primer lugar el nombre, en una base de datos se definen estructuras tabulares a las que llamamos
"TABLAS" que contienen los datos almacenados en ellas. La figura anterior es ejemplo de una tabla que
contiene los mismos datos que la planilla primera. La zona oscura por detrs de la tabla representa el
hecho que una base de datos contiene no solamente muchas tablas, sino adems otras estructuras que
iremos viendo en forma paulatina. Esto es, aprenderemos a construir e interrelacionar estructuras
independientes con un mismo fin.
Como vemos tambin en la figura anterior, las tablas tienen una nomenclatura especfica que vale la pena
definir:
file:///E|/DESK/Educacin/Educacin a Distancia/C...edores/Mdulo 1 Introduccin/Clase 2/Bde_0102.htm (10 of 18) [12/11/2001 15:14:07]

BD_I
Base de Estructura macro que contiene la totalidad de los objetos que conforman una
datos aplicacin o conjunto de aplicaciones informticas.
Estructura de tipo tabular que almacena datos de una coleccin de objetos
Tabla del mismo tipo como parte de un modelo de base de datos. Las tablas se
corresponden con las "ENTIDADES" del modelo
Es parte de la estructura interna de las tablas. Cada registro almacena la
totalidad de los datos de cada uno de los objetos que la tabla contiene. Esto
Registro
es, todo lo que a mi se me ocurra registrar en la tabla sobre "Yerma" estar
guardado en el mismo rengln o "registro"
La coleccin de registros de una tabla tiene adems idntica estructura
interna. Esta estructura interna se conforma con un conjunto de unidades
menores a las que llamamos "Campos". Los campos (cuyo nombre figura al
comienzo de la tabla, tal cual si fuesen cabezales de columna) determinan a
su vez columnas dentro de la tabla que deben contener informacin
Campo
consistente entre s. Si como en el ejemplo anterior el primer campo
corresponde a ttulo y el segundo a la fecha de compra de cada libro,
entonces no tendremos ningn nombre de autor en el primer campo ni
ninguna fecha de edicin en el segundo. Los campos se corresponden con los
"ATRIBUTOS" del modelo
Datos Es la informacin almacenada en cada campo de cada registro. Los datos
individuales individuales de Access se corresponden con los "VALORES" del modelo
Veamos ahora el significado de los trminos que utilizamos en el ejemplo anterior:
BASE DE DATOS
En ambiente Access la base de datos se almacena en el disco duro del computador como un nico
archivo que tiene el nombre que yo haya elegido ms la extensin .MDB (Microsoft Data Base)
miBaseDeDatos.MDB
El propio Windows nos sugiere que este nombre incluye la aplicacin completa cuando en el explorador
nos muestra "Aplicacin Microsoft Access" en la columna de tipo de archivo.
Cuando usted comience a trabajar con una base de datos cualquiera, ver (si simultneamente utiliza el
explorador para observar la carpeta sobre la cual est trabajando que Access crea un nuevo archivo que
tiene el mismo nombre que su base de datos pero con extensin .LDB (Locking Data Base)
miBaseDeDatos.LDB
No debe usted preocuparse por l dado que es el lugar dnde Access almacena la informacin sobre lo que
se llama control de concurrencia (lock de registros). Esta funcin previene que un usuario cambie un
registro en una tabla mientras otro lo est utilizando. Este archivo no existe cuando usted comienza a
utilizar la aplicacin. Access lo crea durante el trabajo y lo borra al finalizar el mismo. Si se est
trabajando en un entorno multiusuario, el archivo es eliminado slo cuando el ltimo de los usuarios ha
abandonado el trabajo.
TABLA
Las tablas son las estructuras bsicas de almacenamiento de datos en cualquier base de datos.
Pueden tener hasta 255 campos distintos. Tienen una estructura tabular, dnde las filas son llamadas

BD_I
"Registros" y las columnas son llamadas "Campos". Se entiende que en una fila tengo todos los datos que
necesito de cada objeto de una coleccin. Por ejemplo, en una tabla de "CLIENTES", cada registro tendr
la informacin completa de UN CLIENTE, mientras que por ejemplo en la columna "DIRECCIN" tendr la
totalidad de las direcciones de los clientes. Obtener los datos de un cliente, esto es seleccionar filas, recibe
el nombre de seleccin, mientras que obtener todas las direcciones de mis clientes, se dice que es una
funcin de proyeccin. En principio voy a asociar a cada ENTIDAD definida en mi modelo con una tabla,
aunque como veremos en la prxima clase a veces son necesarias ms de una tabla para poder describir
en forma completa una entidad cualquiera.
CAMPO
Cada uno de los atributos que encontramos en nuestra entidad termina convirtindose en un campo
de la TABLA. Una de las ventajas que las bases de datos tienen sobre otras clases de almacenamiento, es
que controlan sin necesidad de intervencin por nuestra parte, la clase de datos que se ingresa en cada
campo. Este mecanismo, que por supuesto tiene limitaciones, nos permite simplemente definiendo un
campo como de tipo "numrico", evitar que en l se ingresen otra cosa que no sean nmeros y los signos
de ms (+) o menos (-). Por ejemplo puedo definir un campo como de tipo "fecha" y con ello evito que se
ingresen en l fecha incorrectas, como por ejemplo un mes 13 o un 29 de febrero de un ao no bisiesto.
Por supuesto que no puedo evitar los errores totalmente si lo que quera ingresar el el 22/3/2000 e
ingres 22/3/1999 para la definicin del tipo de datos, ambas fechas son correctas, de modo que si
quisiera resolver este problema, necesitara colocar reglas adicionales como ms adelante veremos. Estas
especificaciones referidas al tipo o clase de datos que pueden almacenar son llamadas "Tipos de datos".
Los campos aceptarn slo datos del tipo que se le haya especificado en su definicin.
Access reconoce los siguientes tipos de datos:
Texto
Memo
Numrico
Fecha/Hora
Moneda
Autonumrico
Si/No
Objeto OLE
Hipervnculo
Asistente para bsquedas

Texto. Permite ingresar texto libre, letras, nmeros y signos o caracteres especiales. No
se puede en principio realizar clculos sobre l. Su largo mximo es de 255 caracteres y
una vez fijado, cada registro que se ingresa tiene esta cantidad de espacio reservada, se
utilice o no.
Memo. Igual que el anterior pero con ms capacidad. Permite almacenar hasta 65.535
caracteres. A diferencia de los campos de tipo texto, el campo memo no ocupa lugar
(salvo el mnimo necesario para su definicin que son 4 caracteres o bytes) si no se
utiliza, de modo que en este sentido hace un uso ms eficiente del espacio que aquellos.

BD_I
Numrico. Se usan en campos que almacenan nmeros. Su tamao depende de una

sub clasificacin que se analizar en los ejercicios. Access permitir en ellos el ingreso de
dgitos numricos solamente con la opcin de precederlos de los signos de (+) o (-) en
caso de ser necesario. El signo de ms (+) es la opcin por defecto de modo que no
necesitamos utilizarlo, simplemente con ingresar el nmero, Access entiende que ste es
positivo.
Fecha/Hora. Almacena fechas y horas desde el ao 100 hasta el 9.999.
Moneda. Es un campo numrico que agrega automticamente el signo monetario.
Permite guardar nmero de hasta 15 cifras significativas ms 4 cifras decimales.
Autonumrico. Otro campo numrico. En este caso Access me proporciona
automticamente un nuevo valor cada vez que agrego un registro nuevo. Este nuevo
valor puede ser aleatorio o secuencial (su uso ms comn). En este ltimo caso lo que
tengo es un "contador". Este "contador" siempre devuelve el nmero siguiente al ltimo
dado, por ejemplo, si en una tabla de socios tengo un nmero de socio definido como
contador e ingreso un total de 100 socios a la lista, mi contador me dar
secuencialmente todos los nmeros entre 1 y 100. Ahora bien, si en determinado
momento se me ocurre borrar la totalidad de la lista, esto es, dejo la tabla de socios
vaca y luego voy a ingresar uno nuevo, este nuevo socio ser el nmero 101. Los
nmeros ya utilizados por un campo de tipo "Autonumrico" no se recuperan.
Si/No. Permite almacenar solamente dos valores del tipo: "verdadero/falso", "si/no". Su
tamao es de un Byte o carcter y se utiliza para por ejemplo, marcar registros como
impresos o no, o determinar sobre un objeto cualquier cualidad que pueda slo estar
presente o no (sin matices). Por ejemplo:
est vacunado? (Si/No)

compra por primera vez? (Si/No)
fue impreso? (Si/No)
present certificado? (Si/No)
.......
Objeto OLE. Permite almacenar objetos como datos de la base de datos. Un objeto
puede ser una imagen, un sonido, un video, una planilla Excel, un documento Word, un
grfico, etc. Son utilizados por ejemplo para colocar en la pantalla de datos de un
cliente, su fotografa o una imagen de su firma capturada mediante un "scanner".
Hipervnculo. Texto o combinacin de texto y nmeros que vincula ese campo con una
direccin de Internet, un correo electrnico, o la direccin de un archivo en un
sistema de red de computadoras.
Asistente para bsquedas. No es ste en realidad un tipo de datos, a pesar que se
encuentra entre ellos. Aqu lo que tenemos es una funcin a la que Access tambin llama
"Bsqueda", que me permite desplegar como parte de un campo una lista con los
valores vlidos del campo. A continuacin un ejemplo de ello para los tipos de prstamo
de libros en una biblioteca:

BD_I
Claves
El concepto de clave es fundamental cuando trabajamos con bases de datos. Cuando disponemos de
una lista (y como hemos visto una tabla lo es) que tiene datos sobre una coleccin de objetos, es
razonable pensar que en algn momento querremos identificar a cada no de esos objetos (registros en el
caso de las tablas) de una forma precisa, sin ningn tipo de ambigedad, o que querremos verlos en un
determinado orden que no sea necesariamente aqul en el cual los datos fueron ingresados.
Pobre papel jugaran las bases de datos en el mercado si cuando les solicito una lista de clientes me
devolvieran un listado de stos en el orden en el que ingresaron como tales a la empresa. Como adems
es muy probable que dependiendo del trabajo que est realizando necesite diferentes rdenes para los
mismos datos, al construir una base de datos deber prestar atencin preferencial a la definicin de las
llamadas "claves" para el acceso a los datos.
Vamos a definir el concepto de "clave" en una tabla como: un conjunto de uno o ms campos de la
tabla por los cuales ordenar a sta. Cuidado, no quiere esto decir que voy a repetir o duplicar los
datos de la tabla, sino que mantendr una lista ordenada por el criterio que yo elija. La forma fsica de
almacenamiento de este tipo de listas no es parte de este curso. Una introduccin al tema para aquellos
que se sientan especialmente motivados por este tipo de precisiones tcnicas se encuentra en la
bibliografa que acompaa a este curso. A modo de ejemplo, hace algunos aos eran muy comunes en las
oficinas los ficheros de tarjetas de cartulina en los que se registraba informacin relacionada con los ms
diferentes asuntos. Estos ficheros estaban ordenados de tal modo que al empleado encargado de su
mantenimiento le resultase fcil dar con un asunto en particular. Este orden poda diferir entre por
ejemplo: Fecha de inicio del asunto, Oficina dnde se produce, Tema que trata, etc. Queda claro que la
ficha de cartulina contena la mnima informacin necesaria para la ubicacin del asunto, y no deca nada
adicional sobre ste que no fuese estrictamente necesario para su ubicacin por el criterio establecido.
Una dificultad que tena este tipo de archivo es que para cada orden era necesario realizar un trabajo
manual de registro. Era muy comn que el orden por fecha del asunto se llevara en un cuaderno de
"Asuntos" y que el fichero se reservase para algn otro orden como por ejemplo "Tema que se trata".
La informtica y en particular las bases de datos facilitaron esto en forma dramtica permitiendo el
mantenimiento de muchos criterios de orden distintos simultneamente sobre una misma tabla, todos
ellos mantenidos en forma automtica por la base de datos. Access nos permite la definicin de ms de
300 renglones en la hoja de definicin de claves (cada una de ellas puede tener hasta un mximo de 10
campos). Por lo tanto si pensamos que normalmente una clave no tiene ms de tres campos, esta

BD_I
estructura nos permitira definir hasta 100 rdenes o claves diferentes para una misma tabla. Realmente
suficiente!
Estas claves se diferencian por la funcin que cumplen y la forma en la que clasifican los registros.
Clave Primaria
Tambin conocida como Clave Principal (denominacin que utiliza Access), es la ms importante de la
tabla.
Definicin:
Definimos clave primaria como aquel dato o conjunto de datos
(o campos) que nos permiten identificar a cada uno de los
elementos del conjunto de una forma precisa, cualquiera sea la
cantidad de elementos del grupo en la actualidad o en el
futuro.
Hay algunas claves primarias que son clsicas en el diseo de sistema, a saber: el nmero de Documento
Nacional de Identidad para las personas, el nmero de Factura para las facturas de una empresa o la
matrcula para un automvil. Estos nmeros estn administrados de forma tal que el organismo
responsable de su asignacin nos asegura que no habr repeticin de los mismos ni ahora ni en ningn
futuro previsible.
De lo anterior se debe notar que todos los ejemplos que dimos son ejemplos numricos, dado que los
nmeros nos permiten obtener la diferenciacin del mayor nmero de componentes de un conjunto con el
menor nmero de caracteres. Imaginemos si no, lo dificultoso que sera obtener una identificacin nica
de personas utilizando solamente sus nombre y apellidos. No slo esto sera casi seguramente imposible,
sino que adems en caso de lograrlo la cantidad de caracteres necesarios para realizar la clasificacin sera
seguramente mucho mayor que un nmero de diez cifras por persona.
De manera que por la facilidad en el manejo y por el ahorro de espacio en el disco duro, utilizaremos
siempre claves numricas para la definicin de claves primarias en las tablas de nuestro modelo.

BD_I
En la figura anterior vemos la definicin de la Clave Principal de la tabla de libros de nuestro ejemplo.
Notemos que en la barra de ttulo de la ventana dice "ndices: Libros" esto es, la lista de claves que
aparece abajo corresponde a la totalidad de claves definidas para la tabla de libros.
En el dibujo aparece definida solamente la clave principal indicada adems con el dibujo de una pequea
llave a su izquierda (recurdelo, este es un smbolo caracterstico de Access). La lista contiene tres datos,
a saber:
Nombre del ndice: en este caso "PrimaryKey" es el nombre que por defecto Access coloca a una clave
cuando le pido que sta sea la clave principal. Este nombre nos servir para establecer el orden en el
futuro. Establecer significa en este caso elegir un orden determinado para trabajar con la tabla en un
momento cualquiera, de entre el conjunto de rdenes o claves existentes.
Nombre del campo: Este es el campo por el cual se ordenar la tabla. Puede ser uno o ms campos
como ya veremos.
Orden: El campo de orden elegido, puede ser ordenado tanto en forma ascendente como descendente y
aqu se toma esta decisin.
Adems de estos datos, en la parte de abajo de la ventana aparecen tres indicaciones ms que nos sern
de gran utilidad al realizar nuestras aplicaciones:
Principal: Puede tener valor de S o No y establece que sta es la clave principal de la tabla. Es lo mismo
que la llave que mencionamos antes. Una tabla puede tener solamente una clave principal definida.
nica: Independientemente de la clave principal que se haya definido, puede haber otros campos dentro
de la tabla que nos resulten de inters para definirlos como claves y que adems cumplan con las
propiedades de identificacin nica de la clave principal. Como no es posible definir ms de una clave
principal, segn ya dijimos, se utiliza esta opcin para dar el carcter de clave nica a la clave
seleccionada. Un ejemplo de esto es la identificacin por cdigo de barras de los artculos en un comercio
que muchas veces coexiste con una numeracin o codificacin de artculos propia de la empresa. En este
caso se utilizan dos campos para colocar ambos nmeros, y se definen dos claves, una ser la principal y
la otra tendr establecido como "Si" este valor de "nica". Cul de ellos elegimos para clave principal y
cul para clave nica es indiferente en este caso, dado que su comportamiento ser igual en todos los
sentidos.
Ignorar Nulos: Toda lista de atributos o datos dentro de un campo en una tabla corre el riesgo de quedar
incompleta porque me faltan los valores correspondientes a algunos de los elementos contenidos en ella.
Por ejemplo, si yo carezco del nmero de Documento Nacional de Identidad de un cliente, no lo elimino de
la lista de clientes, dejo ese valor vaco para llenarlo ms adelante a la primer oportunidad que se me
presente. Como la nada es un concepto no definido en un computador, es necesario establecer un valor
que indique la ausencia de valor. A este valor se le llama "Nulo" o "Null" en ingls. En nuestro ejemplo, lo
que sucedera al definir la clave primaria es que el valor de la clave sera realmente nico para aquellos
clientes que tuviesen registrado en mi tabla el nmero de Documento Nacional de Identidad, pero para
todos aquellos casos en los que yo careciera de dicho valor ste sera establecido como "Nulo" por el
computador, y dicho valor "Nulo" se repetira ms de una vez con lo que obtendra un error en la
generacin de mi clave primaria. Esta opcin es la que nos permite resolver el problema, dicindole a
Access que tome en cuenta para la generacin de la clave solamente aquellos valores del campo que NO
contengan el carcter "Nulo". IMPORTANTE: si tomo esta opcin, en el momento en el que solicite ver la
tabla ordenada por esta clave, no aparecern los clientes que tengan valor "Nulo" en dicho campo, por lo
que debe manejarse con gran cuidado.
Claves Alternativas
Llamaremos "Claves Alternativas" a aquellas claves que tienen las cualidades de la clave primaria,
pero que no han sido elegidas como tales por nosotros. Este concepto aparece porque en una misma tabla
puede aparecer ms de un campo que tenga las caractersticas de una clave primaria. Por ejemplo en una
tabla de "Clientes" es posible que coexistan campos tales como "Documento Nacional de Identidad" y
"Nmero de Cliente". En este caso como cualquiera de los dos campos puede ser considerado como clave

BD_I
primaria en forma independiente lo que hacemos es elegir uno cualquiera de ellos como "Clave Primaria"
dejando el otro como "Clave Alternativa". Desde el punto de vista de Access, una "Clave Alternativa" no es
ms que una clave o ndice al que se le asignan las propiedades de:
Principal = NO
nica = SI
En el ejemplo anterior, nos encontramos con que el campo "NroBoletaPrestamo" que se encuentra definido
como clave primaria (PrimaryKey), identifica tanto a cada uno de los prstamos de un libro como la
concatenacin de los campos "NroLibro" y "NroEstudiante" y "FechaPrestamo". Esta segunda clave llamada
"LibroEstudianteKey" es tambin nica debido a que un libro no puede ser prestado a un estudiante ms
de una vez en una misma fecha.
Claves Secundarias
El resto de las claves que se definen para una tabla son conocidas como "Claves Secundarias". En el
ambiente de trabajo de Access se las conoce como No Principales. En general se utilizan para obtener
diferentes rdenes de acceso a los datos que no correspondan con el orden con el cual han sido ingresados
stos. Por ejemplo se puede obtener una clave secundaria para obtener todas las boletas de prstamo que
se tengan de un mismo estudiante a travs de una clave del tipo "EstudianteKey"
Tambin es posible construir aqu claves concatenadas. En el ejemplo siguiente se muestra una clave

BD_I
secundaria que permite obtener listas ordenadas de estudiantes por los campos "Apellido" y "Nombre"
Note que el apellido del estudiante se coloca primero en la clave para que el orden tenga sentido para
nosotros.
En este momento ha recibido usted la informacin necesaria para comenzar con el proceso de diseo de
una base de datos. Este proceso tiene dos etapas claramente diferenciadas:
Definir el problema a resolver (especificarlo formalmente)

Resolverlo (construir la base de datos, las tablas, las relaciones, las pantallas de ingreso de datos,
los listados y reportes, ...)
Fin de la Clase 2

BD_I

Clase nmero 3
Resumen
Introduccin
El Primer Diseo
Ventajas
Desventajas
Recomendaciones
Manos a la obra
Crear nueva B. Datos
La primer tabla
Trabajos
Resumen
En esta clase realizar usted su primer diseo de base de datos. Ser un ejercicio sencillo para que
comience a conocer el producto y nos ir preparando para la construccin de modelos ms complejos y
funcionalmente completos.
Introduccin
A partir de este punto comenzaremos a analizar la construccin de los llamados "Modelos de Datos". Toda
aplicacin de bases de datos tiene, como hemos visto en la clase anterior un conjunto de
almacenamientos fsicos dnde se guardan los datos relativos a determinado problema o situacin, que
luego son utilizados como insumo para los procesos tanto de operaciones como de gestin de la empresa.
Nuestra preocupacin ser a partir de ahora la construccin de estos modelos teniendo en cuenta que los
datos y sus relaciones deben responder a las necesidades de una empresa o situacin determinada de la
mejor forma posible y con el menor costo posible.
Definicin: Un "Modelo de Datos" es un tipo de abstraccin de datos
utilizado para proporcionar una representacin conceptual de la realidad
que analizamos. Este "Modelo de Datos" utiliza conceptos lgicos como
los objetos, sus propiedades y relaciones que permiten comprender ms
fcilmente los mecanismos de almacenamiento de datos dentro del
computador. Debido a ello el "Modelo de Datos" oculta aquellos aspectos
que no son relevantes para los usuarios de la base de datos.

BD_I
EL PRIMER DISEO
Continuemos con nuestro ejemplo de los libros, supongamos que queremos formalizar un modelo de
datos para una biblioteca. En primer lugar ser necesario ocuparnos de lo que nuestro modelo NO VA A
TRATAR. Por ejemplo excluiremos en este modelo todos aquellos contenidos de la biblioteca que no sean
libros (revistas, mapas, folletos, casetes, software, ...). Excluiremos tambin al menos de momento, todo
lo relacionado con prstamos, compras, cantidad de ejemplares por volumen, y toda otra consideracin
que nos distraiga de nuestro objetivo principal: REGISTRAR NUESTROS LIBROS.
Planteadas las cosas de esta forma, resulta bastante claro determinar cul es la entidad que nos va a
ocupar: LIBROS. Claro que podramos haberla llamado de otra forma: OBJETOS, POSESIONES,
INVENTARIO, y hasta tal vez LECTURAS. Lo que hay que considerar aqu es la simplificacin del nivel
conceptual ya vista y tratar que los nombres reflejen lo ms fielmente posible la descripcin de la
coleccin que estamos nombrando.
Resuelto el asunto de la entidad, veamos cules son los atributos que nos interesan. Para este caso
elegiremos los siguientes: ttulo, autor o autores, editorial, ao de edicin, resumen del contenido, fecha
de compra, ISBN. En este proceso hemos descartado al menos en esta etapa otros atributos posibles
como: nmero de pginas, nmero de edicin, tipo de encuadernacin, idioma de la versin original,
traductor o traductores, etc. Hemos hecho este descarte no porque los elementos descartados no sean
atributos propios de la coleccin, sino porque dichos atributos no son relevantes en el mbito de problema
en que nos encontramos.
Esta es una distincin sobre la que siempre es bueno hacer hincapi. CADA ATRIBUTO INNECESARIO QUE
USTED AGREGUE A SU MODELO DE DATOS O BIEN LUEGO NO ES LLENADO O BIEN SE REQUERIR DE
TRABAJO PARA MANTENERLO AL DA. EN CUALQUIERA DE ESTOS CASOS ESTAR USTED PERDIENDO
ESPACIO EN SU COMPUTADOR, TIEMPO PARA CONSIDERARLO, SALARIOS PARA MANTENERLO Y EN
DEFINITIVA ... DINERO.
Ahora bien para poder pasar a formato ACCESS estas consideraciones, debemos analizar cmo se
traducen los conceptos de entidades, atributos y valores dentro de una base de datos real.
Consideremos ahora nuestra entidad LIBROS y coloqumosla en forma de tabla de base de datos.
Analicemos ahora lo que hemos hecho en la hoja anterior (Figura "Modelo Inicial"). En primer lugar hemos
armado nuestra entidad LIBROS de acuerdo con los atributos que nos habamos fijado (eliminando
algunos slo por razones de espacio) y hemos creado una estructura de tipo tabular que est formada por
filas y columnas.

BD_I
Cada una de estas columnas contiene la informacin (valores) correspondientes a un atributo, mientras
que cada una de las filas, a las que tcnicamente se les denomina "tuplas" o simplemente "registros",
contiene toda la informacin correspondiente a un libro.
Este diseo, si bien contempla algunos elementos muy importantes del modelo de bases de datos,
presenta ventajas e inconvenientes que pasamos a analizar:
Ventajas:
Toda la informacin referida a cada uno de los objetos de la coleccin se encuentra agrupada en un
registro ("Tupla"), lo que me permite, ubicado un libro, tener automticamente disponible todos los
datos que de l tengo almacenados.
Toda la informacin referida a un atributo est en una misma columna, por lo que yo puedo
"interrogar" a la base de datos con preguntas del tipo: Cuntos libros fueron comprados desde el
1/1/1997?.
Los registros o Tuplas pueden estar ordenados fsicamente de cualquier forma sin que ello le
importe a la base de datos. El orden fsico no le aporta ningn significado a la tupla.
Desventajas
Presenta algunas dificultades para las consultas, puesto que la base de datos no tiene como darse
cuenta que "SXXI" y "Siglo XXI" son en realidad la misma editorial y que por lo tanto para consultas
por editorial deben ser consideradas como la misma cosa.
El autor "Federico Garca Lorca" se encuentra identificado con dos nombres que para el computador
son diferentes, a saber: "F.G. Lorca" y "GARCIA LORCA", lo que seguramente nos dar algunos
dolores de cabeza al tratar de encontrar todas las obras de su produccin.
No tengo en principio una forma fcil de encontrar a la autora D. Sellers, dado que su presencia se
encuentra enmascarada por el autor David Cook
Recomendaciones:
Este balance de ventajas y desventajas, nos lleva hacia el establecimiento de algunas reglas para la
construccin de tablas en una base de datos que tendremos que respetar si queremos evitar problemas
de mantenimiento futuro.
Los datos estarn almacenados una sola vez.
Si nos hemos tomado la molestia de registrar en nuestra base de datos al autor de un libro,
pues entonces cada vez que necesitemos el nombre u otros datos de ese autor los iremos a
buscar al lugar dnde ya estn. Para ello, para irlos a buscar, asociaremos a cada datos que lo
necesite un cdigo (tambin llamado nmero o identificador o id) que lo identifique con
absoluta precisin, y que luego utilizaremos en el resto de las tablas para que Access a travs
de l busque el valor que necesita. A este concepto se le llama de "redundancia mnima" y
significar que los nombres de los autores estarn almacenados en forma independiente de
los datos de los libros.
Toda coleccin de objetos debe ser identificable mediante una clave primaria, la que ser
preferentemente numrica.
Access nos ofrece para esto el tipo de datos auto numrico, que facilita la realizacin de
codificaciones automticas. Dado que no nos es posible ir y preguntarle a David Cook cul es
su documento nacional de identidad, pues entonces lo que hacemos es asignarle un nmero
de autor en forma automtica en nuestra base de datos.
Las nicas repeticiones de datos que nos permitiremos en los modelos que veremos sern

BD_I
aquellas que nos permitan referenciar datos de una tabla en otra.
Cuando tengo necesidad de referirme a objetos de una coleccin en otra tabla (por ejemplo
mencionar la Editorial en la tabla de libros) coloco en la tabla en la que necesito la referencia,
un identificador nico del registro que necesito de la tabla referenciada (en general coloco la
clave primaria). A este identificador se le denomina "clave fornea", dado que es en realidad
clave en otra tabla (en la de Editoriales). Esta es la nica redundancia permitida en el modelo
de datos relacional. Nos estamos refiriendo claro est a la repeticin de la clave primaria de
una tabla en otra para lograr la referencia mencionada.
Todo atributo deber contener un solo valor en cada registro.
En el ejemplo anterior D.Cook & D.Sellers son en realidad dos valores distintos almacenados
en un mismo campo. Esto es muy grave, dado que en realidad, para Access la secuencia
"D.Cook & D.Sellers" es un valor nuevo y diferente de cada uno de los autores mencionados.
Es recomendable que la mayor cantidad posible de valores en cada atributo est lleno con
los datos correspondientes.
Esto, que es claro si pensamos en una lista de personas donde no pueden faltar sus nombres.
Pero supongamos que estamos ante una lista de artculos y tenemos definido un atributo
llamado descripcin. Este atributo consume un cierto espacio de almacenamiento para cada
artculo definido y es deseable que la mayora de ellos (si no todos) tenga ingresada una
descripcin adecuada. A este concepto se le llama "dispersin" de los datos. Es muy comn en
bases de datos hechas con poco cuidado que algunos atributos estn prcticamente vacos en
las tablas. Esto que puede ser un problema de ingreso, tambin es posible que sea una falla a
la hora de definir el problema y tal vez alguien deba pensar si ese atributo es realmente
necesario.
Cuando defina los valores posibles para un atributo o campo, defina y distinga los
conceptos de "no dispongo del dato" y "el objeto no tiene este atributo"
A modo de ejemplo si est usted realizando una base de datos en la que registra encuestas de
opinin. No es lo mismo para un atributo que almacena la respuesta a determinada pregunta
(por ejemplo " Qu partido piensa votar en las prximas elecciones ?") contestar el partido
A, B o C, que negarse a contestar y que no realizar la pregunta (por ejemplo si el encuestado
es extranjero).
Siempre que sea posible asigne a los objetos de su base de datos nmeros que sean de
alcance nacional.
Por ejemplo, si tiene usted una lista de clientes, procure utilizar como identificador elementos
tales como Documento de identidad, Nmero de empresa ante Hacienda, Nmero de seguro
social. Por el contrario, procure evitar (salvo que no tenga ms remedio) definir cosas tales
como un "Nmero de cliente" que sea interno a su empresa. Esta solucin si bien es inmediata
y nos da mucho menos trabajo de llenado impide que nuestra base de datos sea utilizable en
forma automtica junto con otras listas de clientes de otras empresas. No olvide que para que
una base de datos tenga por s misma valor comercial, es necesario que su informacin sea
accesible en forma eficaz por otras organizaciones.
Estas reglas no son obligatorias, y de hecho en los desarrollos profesionales de bases de datos muchas
veces algunas de ellas se rompen siguiendo el paso a algunas metodologas. Esta etapa es llamada
"desnormalizacin" de la base de datos y se llega a ella cuando se trata de hacer que un cierto diseo que
tericamente es correcto, presenta dificultades a la hora de ser implantado en un sistema computacional
especfico. Pueden ocurrir problemas de tamao de la aplicacin, de tiempo de respuesta, o se
complejidad del proyecto que hacen que los tcnicos tomen estas opciones como una forma de
resolverlos. En nuestra opinin, en realidad lo que estn haciendo es retrasando la aparicin de los
problemas, o la elevacin de los costos y sin duda aumentando la complejidad del modelo, lo que a la
larga es siempre perjudicial para la organizacin que utiliza el producto. Nuestro consejo es simple:
RESPETE LAS REGLAS, seguramente al comienzo deba trabajar ms, pero a la postre nos lo agradecer.

BD_I
Manos a la obra
Creacin de una nueva base de datos
Con lo que hemos aprendido hasta ahora estamos en condiciones de crear nuestra nueva base de datos
con informacin de nuestros libros en Access.
Lo primero que haremos ser utilizar la carpeta o directorio en Windows que creamos en la clase anterior.
Nos referimos a "CursoDB". En l colocaremos nuestra aplicacin. A continuacin ejecutamos Microsoft
Access. Dado que este es un curso esencialmente prctico, no lo agobiaremos con interminables
secuencias de pantallas que le muestren cada una de las diferentes opciones de digitacin que se le
produzcan. Por el contrario, le explicaremos las opciones ms comunes y ser usted el encargado de
recorrerlas. Recuerde que si de aqu en adelante se le presentan problemas puede recurrir de inmediato a
la asistencia del docente mediante correo electrnico.
La Primer Tabla
Para construir nuestra primer tabla elegiremos la ventana de "Tablas" en la nueva base de datos creada.
Esta ventana debera estar la elegida, aunque en caso contrario bastar con pulsar un clic izquierdo del
ratn en el Objeto "Tablas" de la ventana principal.
Una vez hecho esto elegimos la opcin "Crear una tabla en vista diseo" y nos aparecer la siguiente
pantalla:

BD_I
Veamos ahora el significado de cada componente de esta ventana:

Nmero Funcin
1 Sobre la izquierda de la barra de ttulos de la ventana vemos el
siguiente texto "Tabla1: Tabla" que refiere a lo siguiente: "Tabla1" es el
nombre por defecto que Access coloc a nuestra nueva tabla, dado que
nosotros todava no le hemos asignado uno. Este nombre es
automtico y en caso de repeticiones se incrementa automticamente
como Tabla2, Tabla3, etc. La segunda parte "Tabla" se refiere al tipo de
estructura que estamos definiendo. Recordemos que Access dentro del
archivo .MDB almacena varias estructuras diferentes que ya hemos
visto, y por lo tanto nos informa en cada caso con cul de ellas
estamos trabajando.
2 Botn para minimizar la ventana.
3 Botn para maximizar la ventana
4 Botn para cerrar la ventana. Como siempre en cualquier aplicacin
Windows, Access nos preguntar si descartamos los cambios en caso
que la versin a cerrar sea diferente de la ya guardada en disco.

BD_I
5 En esta columna llamada "Nombre del Campo" vamos a colocar todos

los campos o atributos que hayamos definido para nuestra tabla. Lo
haremos incluyendo un slo campo por rengln y cada uno de ellos
dar lugar a una nueva columna en la tabla a crearse. Recordemos que
los campos pueden tener hasta 64 caracteres de largo y en ellos se
pueden utilizar cualquier tipo de caracteres (incluso espacios en blanco)
excepto los siguientes: un punto (.), un signo de admiracin (!), un
acento grave (`) y corchetes ([ ]). Adems, los nombres no pueden
contener espacios a la izquierda ni caracteres de control (valores ASCII
desde 0 hasta 31).
Recomendaciones
No le recomendamos incluir espacios en nombres de objetos si

luego har referencia a ellos frecuentemente en expresiones o en
el cdigo de Visual Basic.
Tambin debemos evitar el uso de nombres extremadamente

largos porque es difcil recordarlos y referirse a ellos.
No coloque acentos en los nombre de campo. Si toma sto como
norma, nunca dudar luego si coloc el acento o no.
6 Ya hemos visto las caractersticas de los diferentes tipos de datos. En
esta columna, elegiremos el tipo de datos adecuado al atributo que
estamos considerando. Lo podemos elegir mediante la escritura de la
letra que aparece en maysculas en la lista, o mediante el cuadro
combinado que se despliega haciendo un clic izquierdo sobre la parte
derecha de la columna. El valor por defecto para el tipo de datos es
"Texto" de 50 caracteres de ancho.
7 La columna "Descripcin" no es de llenado obligatorio. Lo que nosotros
escribamos all, aparecer (si as lo deseamos) como un comentario en
la lnea de mensajes en la parte inferior de la ventana cuando estemos
trabajando con ese campo en un formulario cualquiera. La acotacin de
"si as lo deseamos" viene porque esta descripcin puede ser como
veremos ms adelante manipulada por nosotros en otros momentos del
desarrollo.
8 La pestaa "General" de las propiedades del campo nos permite
manipulas las caractersticas especiales de cada uno de los tipos de
datos elegidos. De esta forma, su aspecto vara dependiendo de el tipo
de datos elegido. Podemos aqu variar el ancho de un campo de texto,
la capacidad de un campo numrico, si su ingreso ser o no obligatorio,
y muchos otros que veremos enseguida en "Propiedades de los datos
creados"
9 La pestaa "Bsqueda" se auto configura con datos solamente en los
campos de tipo: Lgico, Numrico y Texto. Lo que nos permite es elegir
entre distintas formas de mostrar los posibles contenidos de un campo.
Una vez elegida la forma de mostrar las posibles opciones de datos
para un campo, se activan diferentes opciones de bsqueda.
Profundizaremos en estas opciones cuando comencemos a construir
nuestra aplicacin.
10 Finalmente, esta zona de la ventana contiene una pequea ayuda
adaptada a la tarea que dentro de la ventana estamos utilizando. Es
muy til que hasta que estemos entrenados en el manejo de la ventana
la leamos cada vez que cambia, pues brinda informacin til para la
creacin de la tabla.
Finalmente estamos en condiciones de construir nuestra primer tabla, la que deber quedar armada de la
siguiente forma:

BD_I
Notemos en primer lugar que la tabla ahora tiene un nombre puesto por nosotros, ha pasado de ser
"Tabla1" a "Libros". Esto lo podemos realizar de varias maneras, entre ellas:
En el momento de salvar el diseo con el botn si lo estamos haciendo por primera vez y si el
nombre es un nombre por defecto de Access, entonces se nos ofrecer el cambio del nombre
mediante la ventana:
Otra forma es, una vez creada la tabla, modificar su nombre mediante la tecla F2 o con el
apuntador del ratn sobre el nombre viejo presionar botn derecho y opcin "Cambiar nombre".
Otro elemento importante a tener en cuenta es que hemos definido ya la clave primaria de la tabla.
Notamos que a la izquierda del nombre del primer campo (IdLibro), aparece la figura de una pequea
llave, indicador que ese campo es clave primaria de la tabla. Para lograrlo, nos posicionamos sobre el
nombre del campo y pulsamos el botn estando en la vista "Diseo". Si quisisemos definir una
clave primaria que contuviera ms de un campo, simplemente deberamos seleccionar (manteniendo la
tecla control [Ctrl] presionada) la totalidad de los campos que deseemos y una vez hecho esto presionar
el botn . Quedar entonces definida UNA CLAVE PRIMARIA compuesta por ms de un campo.

BD_I
Trabajos
Para completar esta clase construya las siguientes tablas adems de la tabla de libros, justificando sus
decisiones con el docente:
Editoriales
Autores
Temas
Fin de la Clase 3

BD_I

Clase nmero 4
El mundo de las relaciones (1 a n)
Indice
Relaciones 1 a N
Cmo encontrar una relacin de 1 a n?
Algo para recordar...
Relaciones 1 a N
Hasta ahora hemos transitado por el mundo de las entidades y los atributos. Hemos encontrado las ENTIDADES o colecciones
de objetos relacionadas con un problema y las hemos colocado en tablas ACCESS para representar estos modelos en el
computador. Ahora es cuando se nos presenta el problema de tratar estas colecciones que se encuentran fsicamente separadas
entre s como un slo conjunto armnico de datos que me permita realmente resolver los problemas que me llevaron a su diseo.
Ha llegado entonces el momento de relacionar la informacin de las diferentes entidades o tablas de forma de trazar caminos para
obtener a partir de ciertos datos toda la informacin que necesitemos de nuestra aplicacin. Veamos ahora algunos
inconvenientes que son realmente importantes a la hora de realizar un diseo o modelo de datos para su uso profesional.
Vea la Figura 1 e imagine una persona que quisiera realizar una consulta sobre los libros que se tengan sobre una editorial
cualquiera, por ejemplo "Espasa Calpe". Aqu nuestra base de datos no tiene inconvenientes en presentarle como respuesta a la
consulta el registro correspondiente al "IdLibro" 91 correspondiente a "Para esta noche" de Juan Carlos Onetti. Ahora bien si por el
contrario hacemos la misma consulta pero para la Editorial "Siglo XXI", entonces tenemos problemas, pues dependiendo de cmo
escriba el nombre de la editorial obtendr respuestas diferente: si consulto por "Siglo XXI" entonces recibir como respuesta "La
zapatera prodigiosa", mientras que si pregunto por "S. XXI" recibir como respuesta "Canto General" y si pregunto por cualquier
otra construccin como por ejemplo "Siglo 21" entonces la base de datos me dir que no tiene libros de esa editorial. Lo que
estamos diciendo es que una base de datos es dependiente de su capacidad de comparar caracteres o nmeros a la hora de
encontrar datos dentro de ella. No podemos pensar en resolver esta situacin sobre la base de obligar a quienes deban ingresar
los datos hacerlo siempre, siempre, ... SIEMPRE, de la misma forma, dado que lograramos enormes cantidades de renuncias o
empleados enfermos por la cantidad de revisaciones y sobre revisaciones que deberan de estar haciendo en forma permanente.
Una buena solucin para el problema anterior es lo que en la jerga de las bases de datos se llama "codificar" las editoriales. Esto
es, dado que no podemos asegurar que un nombre de editorial (o de cualquier otra cosa) ser escrito siempre de la misma forma,
pues entonces hagamos una lista nica de editoriales, dnde cada una de ella aparezca una sola vez, mantengamos esta lista
permanentemente revisada y aprobada y finalmente asignemos en ella un nmero a cada editorial. Lo que haremos entonces con
los libros es colocar el nmero correspondiente a la Editorial en lugar de su nombre y procurar que la base de datos nos muestra
en forma automtica el nombre para que nos resulte fcil su ubicacin.
Veamos en la figura 2 cmo queda la estructura de datos luego de este cambio:

BD_I
En la Figura 2 hemos separado el nombre de las editoriales y hemos construido con l una nueva tabla (a la que podramos llamar
Tabla: EDITORIALES) donde nos aseguraremos que habr una sola ocurrencia de registro por cada editorial. Agregado ahora a las
dos estructuras de datos incluimos una misma columna de datos o "Atributo" al que llamamos NRO_EDITORIAL (Nmero de
Editorial). Es a travs de este cdigo del que estableceremos la relacin entre los dos conjuntos de datos. Analicemos ahora el
efecto de este nuevo Atributo sobre las tablas:
NRO_EDITORIAL en la coleccin o tabla de EDITORIALES es un nmero nico. Cada editorial de la lista actual o a ingresarse
tendr un valor de NRO_EDITORIAL diferente. Cuando tenemos en una estructura de estas un Atributo (veremos ms adelante
que podra ser un conjunto de varios Atributos) cuyos valores me garantizan la individualizacin de los datos en forma absoluta
para cualquier rengln actual de la lista o cualquiera a agregarse en el futuro, entonces estamos ante lo que en bases de datos se
denomina CLAVE PRIMARIA.
NRO_EDITORIAL en la coleccin o tabla de "LIBROS" representa en cada rengln el nmero o cdigo de editorial que corresponde
a la empresa editora de cada libro en particular. Es importante destacar que en este caso NRO_EDITORIAL no es ni puede ser
nunca (sola) CLAVE PRIMARIA, puesto que basta que compremos para la biblioteca dos libros de la misma editorial para que dicho
valor se repita (por ejemplo el caso de "Canto General" de Pablo Neruda y "La Zapatera Prodigiosa" de Federico Garca Lorca,
ambas editadas por Siglo XXI y que figuran con el nmero 150.
NRO_EDITORIAL permite entonces establecer una RELACIN entre las dos colecciones de la Figura 2. Esta relacin se denomina
de 1 a n (infinito) por el atributo NRO_EDITORIAL y se representa con una flecha que tiene punta simple en el extremo del 1 y
punta doble en el extremo de n (infinito).
Ser ahora problema del nivel de visin de la base de datos, mostrarme la lista como aparece en la figura 1 pero almacenando los
datos como se muestra en la figura 2. A travs de este nivel obtendremos una vista de los datos donde figure en la lista de los
libros el nombre de la editorial, pero llevado all por efecto de la relacin que acabamos de definir.

BD_I
Vemos que si bien la ENTIDAD sobre la que hemos estado trabajando es la de "LIBROS", su representacin en ACCESS nos ha
llevado a la construccin de dos tablas, una para representar los libros y otra para agrupar en una nica lista a todas las
editoriales que tengo registradas. No nos interesa entrar en la discusin de si en realidad tenemos una entidad "LIBROS" descripta
por dos tablas o una entidad "LIBROS" y otra "EDITORIALES". Este punto queda para los que gusten de profundizar en los temas
de esta disciplina. Nosotros llamaremos a la tabla de "EDITORIALES" con el nombre de "Tabla Auxiliar" en el entendido que su
aparicin es debida a la necesidad de ordenar en una nica lista las editoriales que editan los libros para evitar los errores que ya
hemos visto.
Ntese lo antes dicho: para poder establecer una relacin entre dos tablas es necesario: INTRODUCIR DATOS REDUNDANTES.
Esto es, repetir datos en los dos conjuntos de forma tal que obtenido ese dato en uno de ellos pueda luego ir a buscarlo al otro
conjunto y de esta forma encontrar la relacin entre los diferentes registros.
Esta necesidad de repetir datos para establecer relaciones es la que nos ha llevado a los informticos a la casi obsesin por
codificarlo todo. En este caso lo que hemos hecho fue codificar las EDITORIALES. Codificar significa asignarle un nmero (en
nuestro caso arbitrario) a cada una de las editoriales que tengamos registradas a los efectos de poder de una forma sencilla
establecer una relacin entre dos conjuntos de registros.
Cmo encontrar una relacin de 1 a n?
Hasta ahora hemos visto cmo resolvemos en el caso concreto de la relacin entre LIBROS y EDITORIALES. Pero, cmo es
que se razona para saber si entre dos colecciones diferentes existe una relacin de tipo 1 a n? Aqu es necesario que nos
realicemos algunas preguntas y tomemos algunas precauciones.
En primer lugar tomamos un objeto de la coleccin de EDITORIALES y nos preguntamos si una EDITORIAL (durante
toda su vida como empresa) puede editar ms de un libro. Esto es nos preguntamos si es posible que en la coleccin
de LIBROS haya ms de un registro con un mismo nmero de editorial. Si a esta pregunta respondemos que s,
entonces en la relacin que hay entre LIBROS y EDITORIALES, hay un "n" del lado de los LIBROS.
Luego nos hacemos la pregunta inversa e indagamos acerca de un objeto de la coleccin de LIBROS preguntando si
un libro en particular puede ser editado por ms de una EDITORIAL. Est claro que esta pregunta puede ser
respondida afirmativamente si pensamos en un libro en forma abstracta. Por ejemplo "La Divina Comedia" de Dante
Aligieri est editada por muchas editoriales. Sin embargo yo me hago la pregunta sobre un objeto libro en
particular de la coleccin que tengo. Digo: este objeto libro en particular, puede estar editado por ms de una
editorial. Aqu la respuesta es claramente "no", debido a que un determinado libro puede ser editado slo por una
editorial. De aqu que deducimos que la relacin existente entre libros y editoriales tiene un valor de "1" del lado de
las EDITORIALES.
Algo para recordar...

BD_I
Los datos que se almacenan bajo el "modelo relacional" carecen de

referencias temporales. Cuando me pregunto si un determinado
objeto puede asumir determinada propiedad, lo hago desde la
perspectiva que la asuma a lo largo de toda su vida como objeto.
Por ejemplo, si me estoy preguntando si un terreno puede ser
vendido ms de una vez, me refiero al perodo en que el terreno
exista como una unidad vendible y no al hecho de que no pueden
ocurrir sobre l dos ventas simultneas.
Una regla prctica para determinar si el extremo de una relacin es

de tipo 1 o n (a esto le llamamos "cardinalidad") es verificar si la
relacin apunta a una clave primaria o clave alternativa y en este
caso siempre estamos frente a un extremo de tipo 1. Por supuesto
la situacin contraria tambin es vlida, si el extremo de la
relacin NO APUNTA a una clave primaria o alternativa, entonces
estamos frente a un extremo de tipo "n". Es necesario hacer notar
aqu que los extremos de tipo "n" pueden estar apuntados a PARTE
de una clave primaria o alternativa sin variar su funcin, como
veremos ms adelante.
Fin de la clase nmero 4

Las relaciones de 1 a n son con mucho las ms comunes en los diseos de bases de datos

Clase nmero 5
El mundo de las relaciones (1 a 1)
ndice
Introduccin
Veamos el problema
Podemos solucionarlo
Veamos ahora la relacin
Introduccin
En nuestra clase pasada vimos las posibilidades que se agregan a nuestro modelo de bases de
datos cuando establecemos relaciones entre diferentes tablas. En particular nos dedicamos a
analizar el tipo ms comn de relaciones, las llamadas relaciones de 1 a N. Estas, si bien son las
ms comunes no son las nicas que puede soportar el modelo relacional, en esta clase veremos un
segundo tipo que si bien aparece con bastante menos frecuencia no por ello es menos importante.
Nos referimos a las relaciones: 1 a 1.
Veamos el problema
Para poder analizar este nuevo tipo de relaciones debemos agregar alguna complejidad a la
"letra del problema" que venimos analizando. Para ello imaginemos que nuestra biblioteca dispone
adems de libros comunes unos cuantos cdices (libros antiguos manuscritos) muchos de los cuales
fueron adquiridos en subastas y otros por donacin. Los cdices en tanto manuscritos tienen
algunos atributos comunes con el resto de los libros y otros que les son propios, as como los libros
tienen atributos que no son aplicables a un cdice (por ejemplo: EDITORIAL o ISBN). Los cdices
por su parte tienen atributos tales como: AO DE LA COPIA, COPISTA, datos histricos sobre el
lugar donde la copia se realiza, historia de los sucesivos dueos del cdice, restauraciones o
alteraciones a las que pudo haber estado sujeto. El manejo que hace a su vez una biblioteca de un
cdice, es diferente del que realiza con un libro comn. Por ejemplo, los cdices no pueden ser
retirados en prstamo, no pueden ser ledos en sala si no es mediante una autorizacin especial de
la Direccin de la Biblioteca y se les asigna un lugar especial para ser ledos.
Notemos ahora que si agregamos al registro de libros todos o parte de los atributos que acabamos
de incorporar, estaremos ante un enorme desperdicio de espacio, puesto que estos atributos
estarn vacos en todos aquellos registros correspondientes a los libros comunes (seguramente
muchos ms que los cdices). A su vez los cdices desperdician en sus respectivos registros los
lugares correspondientes a ISBN o EDITORIAL. Esto sin mencionar el hecho que deberamos
agregar alguna clase de codificacin que me asegurara el reconocimiento de los cdices como tales,
puesto que de otra forma, enfrentado a un registro que tuviese vacos los atributos propios de los
cdices, me quedara la duda entre si es realmente un libro comn o es un cdice del que se omiti

el ingreso de algunos datos. Esta serie de complicaciones debe hacerme reflexionar sobre las
caractersticas de la coleccin que hasta ahora hemos visto como uniforme: LIBROS
Veamos ahora en forma grfica el ejemplo:
Lo primero que encontramos en la tabla de la Figura 1 (a la que estaramos tentados en seguir llamando tabla: LIBROS) es,
como ya hemos dicho un gran desperdicio de espacio. La columna de datos correspondiente al "Copista" as como cualquier
otra que sea exclusiva de los cdices quedar irremisiblemente vaca a la hora de ingresar datos de libros.
Podemos solucionarlo
Reflexionemos entonces sobre el conjunto de elementos que estamos considerando. Este conjunto de objetos de lectura al
que originalmente llamamos libros, resulta que ahora est compuesto por dos sub conjuntos a saber: el sub conjunto de libros
(ahora con una definicin ms restrictiva que antes) y el sub conjunto de cdices. Ahora bien, asumamos que para obtener un
diseo de datos que respete las reglas que ya hemos dado en las primeras clases vamos a considerar ambos conjuntos como
entidades o tablas diferentes a la hora de pasar su diseo a Access. Esto significa que estamos pensando en dividir la tabla de
la Figura 1 en dos tablas diferentes llamadas respectivamente "LIBROS" y "CDICES". Pero si hacemos esto, entonces
vamos a generar en cada uno de estos conjuntos campos o atributos que van a tener conceptualmente lo mismo. Nos referimos
por ejemplo a los campos de "Ttulo", "FechaCompra", "Autor" y cualquier otro que se nos ocurra que pueda ser comn a
ambos materiales. Esto ltimo representa un problema a la hora de consultar a la base de datos por estos criterios comunes y
por lo tanto debemos buscar una solucin que los agrupe en una sola tabla. Para comenzar probemos a separar los campos que
son comunes a los dos sub conjuntos y luego los que son propios de cada uno de ellos:

Notemos que para resolver este problema hemos utilizado en la Figura 2 tres sub conjuntos de
datos que se convertirn luego en tres tablas diferentes. Ahora bien, si analizamos el contenido de
estos sub conjuntos notamos que nada dice en el sub conjunto al que hemos rotulado como "Datos
exclusivos de los cdices" que el Monje Eusebio escribi el Codex Sinaiticus, ni en los "Datos
exclusivos de libros" que Garca Lorca escribi "La Zapatera Prodigiosa". Esto quiere decir que
hemos perdido informacin al realizar la divisin en sub conjuntos. Para resolver el problema lo que
hacemos es agregar algn dato que sea comn a los tres grupos que me permita reconocer la
relacin entre sus distintos registros, y el nico atributo que es comn a los tres y que me asegura
la identificacin nica de cada registro es el "IdLibro". Ahora que hemos decidido mantener la
divisin en tres tablas para asegurar la calidad del modelo de datos, veamos algunos ajustes
necesarios:
Debemos primero dar nombre a los tres subconjuntos. Los datos exclusivos de libros y cdices se
terminarn por supuesto llamando tabla "LIBROS" y tabla "CDICES" y debemos inventar un
nombre de carcter genrico que abarque los dos conceptos anteriores y que hemos definido como
tabla "VOLMENES" que contendr los datos comunes a ambos subconjuntos.
El cambio anterior nos lleva de la mano hacia otro que es de fcil resolucin. Ahora debemos dar
tambin generalidad a dos nombres de campo que quedaron en la futura tabla de "VOLMENES" y
que se refieren slo a libros, nos referimos a los campos de "IdLibro" y "TtuloLibro", que
cambiaremos por "IdVolumen" y "Titulo" respectivamente. Veamos entonces en la figura 3 como
nos quedan las tablas:

Notemos adems que la totalidad de los datos o atributos que guardo sobre un determinado libro se
encuentra almacenados utilizando las tablas de "VOLMENES" y de "LIBROS", mientras que los
datos de los cdices estn almacenados en las tablas de "VOLMENES" y de "CDICES". Tambin
es necesario notar que para conservar la integridad de los datos (esto es saber sin lugar a dudas a
qu objeto de la realidad describe cada valor de la base) nos vimos en la necesidad de repetir el
campo de "IdVolumen" en las tres tablas. Esta repeticin es la mnima que me asegura la
conservacin de la antes mencionada integridad y por lo tanto recibe el nombre de "Redundancia
Mnima"
Llamaremos "Redundancia Mnima" al menor conjunto de

campos que, repetidos en ms de una tabla me asegura la
integridad de la base de datos.
A partir de ahora, la totalidad de los datos de libros estn almacenados por lo tanto en dos tablas
(VOLMENES y LIBROS), ocurriendo lo mismo con la totalidad de los datos de los cdices
(VOLMENES y CDICES).
Note que la tabla de "VOLMENES" es utilizada en forma indistinta para almacenar los datos de los
libros y los cdices y que ambos comparten un mismo atributos: "IdVolumen". Este atributo
compartido funciona como un nmero identificador nico o clave primaria de cada ejemplar; no
tiene repeticiones.
Cmo se produce el ingreso de un nuevo ejemplar a la biblioteca? Para realizar un ingreso nuevo a
la biblioteca, en el momento de la grabacin de los datos se asigna al ejemplar un nuevo
"IdVolumen" que ser el siguiente al ltimo nmero dado en la tabla de "VOLMENES" y bajo ese
nmero se dan de alta los datos en la tabla de "VOLMENES" y (dependiendo si se est ingresando
un libro o un cdice) en la tabla de "LIBROS" o "CDICES". De aqu deducimos que la tabla de

"VOLMENES" contendr la totalidad de los valores de "IdVolumen" generados, mientras que las
otras dos tablas ("LIBROS" y "CDICES") tendrn solamente los nmeros que correspondan
respectivamente a libros o a cdices.
Veamos ahora la relacin
Una consecuencia inmediata del procedimiento que acabamos de seguir es que el campo
"IdVolumen" es clave primaria en las tres tablas, dado que no tiene valores repetidos en ninguna de
ellas.
Es entonces este campo "IdVolumen" el que nos permitir establecer la relacin entre las tablas de
"VOLMENES" y "LIBROS", as como entre "VOLMENES" y "CDICES". La particularidad de esta
relacin es que en cualquiera de los dos casos estamos ante una relacin que apunta a campos que
son clave primaria (o alternativa) en las dos tablas involucradas. Por ejemplo si ubico el ejemplar
"Para esta noche" que tiene el "IdVolumen" 91 y nos vamos a buscar los datos particulares de la
novela en las otras tablas, nos encontramos que slo encontraremos datos en una de las dos tablas
(en este caso la tabla de "LIBROS") y que en ella slo habr un registro con dicho nmero. A este
tipo de relaciones que vinculan tablas a travs de campos que no contienen repeticiones entre sus
valores las llamamos relaciones de 1 a 1:
Este tipo de relaciones, si bien menos frecuentes que las anteriores son tambin muy usadas dado
que nos permiten realizar una gran economa de espacio en nuestro almacenamiento y nos permite
tener ordenados nuestros datos creando estructuras que los agrupan en forma totalmente anloga
a como los concebimos en el mundo real.
Cmo razonamos ahora el funcionamiento de la relacin de la figura 4. Lo veremos en dos casos:

cuando estamos trabajando con un libro y cuando estamos trabajando con un cdice.
Cuando estamos trabajando con un libro decimos:
Dado un "IdVolumen" que identifica en forma
nica a un libro en la tabla de "VOLMENES",
existe uno y un slo registro en la tabla de
"LIBROS" con igual valor en "IdVolumen" que
completa la descripcin del libro
seleccionado.

nica a un libro en la tabla de "LIBROS",
existe uno y un slo registro con igual valor
en "IdVolumen" en la tabla de "VOLMENES"
al que ste se refiere.
Cuando estamos trabajando con un cdice decimos:

nica a un cdice en la tabla de
"VOLMENES", existe uno y un slo registro
en la tabla de "CDICES" con igual valor en
"IdVolumen" que completa la descripcin del
cdice seleccionado.

nica a un cdice en la tabla de "CDICES",
existe uno y un slo registro con igual valor
en "IdVolumen" en la tabla de "VOLMENES"
al que ste se refiere.
Fin de la clase 5

BD_I
Clase 6
El mundo de las relaciones (n a n)

ndice
Introduccin
Presentacin
Entremos al
problema
La relacin
Resolucin
Introduccin
Hemos analizado ya en las clases anteriores los dos tipos de relacin entre datos en tablas
que una base de datos relacional es capaz de manejar. Nos referimos a las relaciones de tipo 1 a
n y 1 a 1. Sin embargo no son estas las nicas que existen en el mundo de los modelos de
datos. Es muy comn tambin encontrarnos con un tercer tipo de relacin que a diferencia de las
otras no puede ser resuelto por una herramienta del tipo de Access en forma directa, nos
referimos por supuesto a las relaciones n a n. Este tipo de relaciones se caracteriza por la
inexistencia de campos en comn que sean adecuados para establecer la relacin entre las tablas
involucradas y por lo tanto deben ser resueltas con una estrategia diferente.
Presentacin
Es comn encontrarnos en el mundo real con conjuntos que se encuentran relacionados por
alguna funcin especfica y cuyos elementos no tienen ni es razonable que tengan atributos o
campos en comn. Nos referimos por ejemplo a la situacin de un cliente comprando un artculo.
En este ejemplo, tal vez el ms comn entre los ms comunes, una coleccin de clientes de una
empresa compra una coleccin de artculos. Estas dos colecciones est claro que no tienen entre
s atributos en comn, el cdigo o nmero del artculo no es, ni es razonable que sea parte de los
datos del cliente, ni el nmero de cliente puede estar incluido dentro de los atributos del artculo.
No obstante ello, est claro que los clientes compran artculos y los artculos son comprados por
clientes. La Administracin resolvi este problema mucho antes que existiesen las computadoras
realizando la facturacin de los artculos vendidos. Qu es la factura, si no un documento en
donde constan juntos los datos del cliente y los artculos por ste comprados?. La factura permite
establecer una relacin entre los clientes y los artculos de forma tal de saber qu artculos
compr determinado cliente y que clientes han comprado determinado artculo.
Entremos al problema

BD_I
Algo anlogo sucede con el caso de los Autores y los Libros en el ejemplo que venimos
desarrollando, puesto que nuestra biblioteca tendr seguramente ms de un libro escrito por el
mismo autor y asimismo libros escritos por varios autores.
Pero vayamos al detalle, veamos ahora que nos sucede cuando queremos aplicar los conceptos
que ya vimos a los autores. Observemos ahora la Figura 1:
"El autor "Federico Garca Lorca" se encuentra identificado con dos nombres que para
el computador son diferentes, a saber: "F.G. Lorca" y "GARCIA LORCA", lo que
seguramente nos dar algunos dolores de cabeza al tratar de encontrar todas las obras
de su produccin."
"No tengo en principio una forma fcil de encontrar a la autora D. Sellers, dado que su
presencia se encuentra enmascarada por el autor David Cook"
Presentado as el problema, intentemos resolverlo de la misma forma que lo hicimos en el caso

de las editoriales. Para ello lo que en primer lugar hacemos es modificar el campo "AUTOR" de la
tabla "LIBROS" de la Figura 1 y convertirla en una tabla independiente en la que cada registro
contiene un solo autor y cada autor por supuesto se encuentra una y una sola vez en la lista. A
esta tabla independiente le llamamos "AUTORES" y le agregamos un identificador nico para
diferenciarlos claramente an en el caso de autores diferentes con el mismo nombre. Veamos
como quedara

BD_I
Establecidas las cosas de la forma en que sugiere la Figura 2, tenemos ahora que plantearnos el
problema de cmo relacionar a cada libro con su o sus respectivos autores. Aqu lo que en
principio queda claro es que un libro puede ser escrito por muchos autores y que adems un
autor puede escribir muchos libros. Note que la forma en la que hemos resuelto el problema nos
permite ubicar solamente a los autores en los casos en que hayan escrito los libros en forma
individual, puesto que en "Inicie su negocio en el Web" no tenemos lugar para escribir los
nmeros de los dos autores. Otra solucin sera numerar o codificar los libros, agregando dicho
nmero a la tabla de Autores, lo que repite el problema anterior cuando es un mismo autor el
que escribe ms de un libro. Vemos en la Figura 3 que a partir de las consideraciones que hemos
hecho necesitaramos registrar algunos datos adicionales que en forma provisoria hemos reunido
en la lista que llamamos "Lo que necesito conocer". Esta lista describe en forma completa la
informacin que las tablas de "LIBROS" y "AUTORES" no pueden describir dada su restriccin de
un objeto por registro (o rengln).
La relacin
Este tipo de relaciones son conocidas como relaciones de N a N, o sea aquellas en las que
cualquier registro de una de las tablas se corresponde con cualquier cantidad de registros de la
otra y viceversa.

BD_I
Esta dificultad es mucho ms que una elaboracin terica, ninguna base de datos relacional y en
particular "Microsoft Access" que es la que utilizaremos nosotros permite la creacin de este tipo
de relaciones, mientras que si construye y controla las dos anteriores.
Resolucin
Note que la lista que llamamos "Lo que necesito conocer" contiene en realidad siempre dos
datos en cada registro (o rengln) el nmero de libro primero y el nmero de autor en segundo
lugar. Estos nos sugiere la creacin de una tabla compuesta por dos campos diferentes que ya
tenemos identificados en las otras dos tablas y que son "IdLibro" e "IdAutor" respectivamente.
Siendo un poco ms formales, decimos que las relaciones de N a N se resuelven mediante la

creacin de una nueva tabla que contiene las claves primarias (o alternativas) de las dos tablas
que se van a relacionar. Veamos como queda:
Hemos convertido entonces la lista "Lo que necesito conocer" en una nueva tabla a la que
llamamos "AutoresPorLibro" y que contiene la pareja de campos que identifica con total precisin
la participacin de cada autor posible en cada libro de mi biblioteca.

BD_I
Fin de la Clase 6

BD_I
Clase 7
Caso prctico nmero 1

ndice
Introduccin
Metodologa
El Caso: "Centro Musical"
Descripcin
Requerimientos
Restricciones
Se Pide
Resolucin
Paso 1: Identificacin de las entidades
Paso 2: Construir el primer modelo de relaciones

Paso 3: Comencemos la eliminacin de las relaciones n a n
Paso 4: Continuemos con la eliminacin de relaciones n a n

Paso 5: Ahora los atributos
Paso 6: Construyamos el modelo final
Introduccin
En el transcurso de las clases anteriores hemos visto los principios del modelado de
datos en los sistemas de bases de datos estndar de la industria. A partir de ahora
comenzaremos a ocuparnos de pequeos problemas tomados de la vida real que nos
permitan acercarnos a un diseo adecuado de las situaciones que la vida empresarial nos
presenta da a da. Durante esta clase y la prxima resolveremos algunos problemas
concretos que nos permitirn aplicar los conceptos y tcnicas vistos en las clases anteriores,
como una condicin necesaria para abordar luego la construccin de sistemas completos en
el computador.
Metodologa
Trabajaremos de la siguiente forma: en primer lugar lea atentamente la descripcin del

BD_I
caso de estudio que sigue y al que hemos llamado "Centro Musical". A partir de all le iremos
mostrando detalladamente cules son los pasos que es necesario seguir para lograr un
modelo de datos que responda a las necesidades planteadas en el caso. Una vez culminada
esta etapa, le propondremos algunas ampliaciones al caso que deber resolver usted con el
apoyo del docente.
El Caso: Centro Musical
Descripcin:
"Centro Musical" es un pequeo comercio dedicado a la venta de discos compactos y

DVDs se encuentra dedicado a la mejora de su sistema de facturacin. Su propietario
necesita mejorar la informacin que dispone sobre las ventas que realiza de forma de, a su
vez optimizar sus compras, pues ha tenido sobrantes de compactos de algunos artistas que
si bien son muy vendidos a nivel nacional, no lo son tanto en la zona de influencia de su
comercio.
Para ello lo contrata a usted como consultor en sistemas de informacin a efectos que le
proponga un modelo de sistema que le solucione estos problemas y que adems le permita
realizar la facturacin de su negocio.
Requerimientos
Este sistema deber responder, entre otras, a las siguientes preguntas:

Cuntos compactos me ha comprado un determinado cliente en el
ltimo ao
Cuntos compactos se han vendido de un determinado ttulo.
Cuntos compactos se han vendido de determinado artista.
Qu tipo de msica se vende ms en el verano
Deber adems permitir la realizacin de todas las operaciones relativas a una
facturacin sencilla.
Restricciones:
A efectos de mantener los parmetros del problema dentro de un ejercicio de

iniciacin en las tcnicas de modelado de datos, se fijan las siguientes
restricciones:
El sistema no tomar en cuenta las ventas con tarjeta de crdito o
con otros medios de pago distintos del contado efectivo.
No se llevar un control de proveedores, sino simplemente de los
artculos disponibles para la venta.
Se pide:

BD_I
Diseo de Tablas
Claves primarias y alternativas
Relaciones completas
Resolucin
Bueno, ahora ... manos a la obra!!!

Paso 1: Identificacin de las entidades
El primer paso para la construccin de un modelo de datos consiste en la Clase 3 en la

determinacin de las colecciones necesarias para la situacin ante la que nos encontramos.
En este problema podemos determinar en principio que nuestras colecciones sern:
Compactos
Artistas
Clientes
Facturas
Gneros
Musicales
Compactos
Es la primer ENTIDAD o coleccin que nos surge a la hora de elegir. Podramos haberla
llamado tambin "ARTCULOS". Lo importante es que representa la coleccin de objetos que
"Centro Musical" vende y sobre los cuales necesita realizar el control mencionado. Note que
esta coleccin es el equivalente de la "Lista de Precios" de la empresa, no la coleccin de
cada uno de los objetos individuales que son comercializados (para sto necesitaramos una
coleccin de "STOCK")
Artistas
Dado que uno de los factores sobre los que ser necesario obtener datos para luego tomar
decisiones de compra en "Centro Musical" es la cantidad de compactos por artista que se
han vendido, es conveniente, segn ya hemos visto con el ejemplo de las "EDITORIALES" en
el modelo de biblioteca, tener los nombres de stos ordenados en una lista con su
correspondiente cdigo para que sean tratables en forma automtica.
Clientes
"Centro Musical" tiene inters en realizar un seguimiento de las compras realizadas por cada
cliente, por lo que stos son una coleccin tan relevante como para considerarlos como una
ENTIDAD.

BD_I
Facturas
Naturalmente, dado que "Centro Musical" es una empresa de venta al pblico, las facturas
que se emiten con cada venta representan una coleccin que ser necesario manejar en el
modelo.
Gneros Musicales
Dado que el caso menciona la existencia de sobrantes de stock que luego deben ser
vendidos bajo la forma de liquidacin a muy bajo precio, la clasificacin de los compactos
por el gnero msical que contienen representa un dato de valor a la hora de realizar
anlisis para las compras. Por lo tanto decidimos convertir la coleccin de tipos de msica
que pueden aparecer en una entidad que trataremos en forma particular.
Una forma eficiente de ubicar con rapidez las entidades es buscar
dentro de lo que se nos ha dicho o los documentos que tenemos,
todas aquellos nombres que representan colecciones. Casi
seguramente, estos nombres u otros parecidos terminarn
convirtindose en las entidades de nuestro modelo.
Es una sana costumbre usar plurales para dar nombre a las

entidades. Nos ayuda a pensar en ellas en trminos de
colecciones.
Paso 2: Construir el primer modelo de relaciones
Con lo que ya hemos avanzado, podemos ahora pensar en cmo se relacionan entre s
las entidades que acabamos de encontrar.
Comencemos por las relaciones vinculadas con los COMPACTOS. Est claro que los
compactos contienen interpretaciones de ARTISTAS que a su vez interpretan GNEROS
MUSICALES

BD_I
Por otra parte, es tambin evidente que los compactos sern comprados por los clientes. Las
relaciones mostradas en la figura 1 se justifican de la siguiente forma:
Veamos primero la relacin entre "Clientes" y "Compactos":
En nuestro modelo decimos que un cliente puede ser comprador de muchos
compactos (n en "Compactos"), mientras que un compacto tambin puede ser
comprado por una cantidad indeterminada de clientes (n en "Clientes"). Note
nuevamente que cuando nos referimos a "compactos" nos estamos refiriendo a la
lista de los compactos disponibles y no a cada disco compacto en particular.
En cuanto a la relacin entre "Compactos" y "Artistas"
Aqu notamos tambin que un artista puede grabar muchos compactos (n en
"Compactos"), as como un compacto puede contener temas de muchos artistas
(n en "Artistas").
Con respecto a las "Facturas"
Vemos que las facturas tienen de hecho una relacin tanto con los clientes como
con los compactos. De hecho es la coleccin que me permite conocer qu clientes
han adquirido determinado compacto y qu compactos han sido adquiridos por
determinado cliente.
En relacin con los "GnerosMusicales"
Aqu en realidad lo que vemos es que el gnero musical, es ms del tema
interpretado que del compacto que lo contiene, lo que nos hace sospechar que
deberemos seguir trabajando con la coleccin de "Compactos".
Paso 3: Comencemos la eliminacin de relaciones n a n
La primer tarea ahora consiste en eliminar del modelo las relaciones de tipo n a n, dado
que stas no pueden ser representadas en una base de datos relacional. Los siguientes
pasos del ejercicio estn entonces orientados en este sentido.
De acuerdo con lo que ya hemos visto en la clase sobre relaciones n a n, stas se resuelven
mediante la inclusin de una tabla entre las dos colecciones que deseamos relacionar. En el
caso particular de la relacin entre "Compactos" y "Clientes" necesitamos una coleccin que
contenga los datos identificatorios de cada venta de compactos para resolverla. Aqu ya
tenemos una coleccin que nos est esperando para relacionar a ambas: la coleccin de
"Facturas". Esto no es una casualidad, dado que la necesidad de relacionar a los clientes con
los productos que compran es un problema que la administracin se ha planteado desde
mucho antes que existiesen los ordenadores. Veamos cmo queda en la Figura 2

BD_I
Veamos cmo funciona la coleccin de facturas:

Por un lado decimos que un compacto puede aparecer vendido en una gran
cantidad de facturas (n en "Facturas") y por otra parte que en una factura figurar
la referencia a ese compacto slo una vez (1 en "Compactos"). Ntese que el
hecho que un compacto figure una sola vez en una factura no quiere decir que se
haya vendido un solo ejemplar, pues en caso que se hayan vendido ms de uno
en la misma factura, se realizar la indicacin correspondiente en un atributo que
se llamar por ejemplo "CantidadVendida".
La relacin entre las "Facturas" y los "Clientes" es an ms clara, dado que a un
mismo cliente probablemente se le emitan ms de una factura (n en "Facturas"),
mientras que una determianda factura pertenece a un slo clientes (1 en
"Clientes").
Paso 4: Continuemos con la eliminacin de relaciones n a n
Pasemos ahora a estudiar la relacin entre los "Compactos" y los "Artistas". Como ya
sabemos una relacin de n a n debe ser resuelta mediante la inclusin de una nueva tabla.
Ahora bien, cul es la coleccin de objetos que puede existir entre los artistas y los
compactos que stos graban. Parece claro que en medio de estas dos colecciones se
encuentran los "Temas", que los artistas graban dentro de los compactos.
Si vemos las cosas de esta forma, entonces concluiremos que un compacto contiene a
muchos temas, mientras que un tema se encuentra grabajo en un compacto y por otro lado
un artista graba muchos temas, pero un tema pertenece a un solo artista. Veamos cmo
quedan las cosas en el modelo

BD_I
De acuerdo con lo que nos muestra la figura 3, hemos en principio resuelto la relacin entre
los artistas y los compactos y (de paso) logramos resolver el problema de qu hacer con los
gneros musicales. Estos ltimos, en realidad describen a cada uno de los temas que se
encuentran grabados. La relacin sera vista entonces como: un gnero musical puede serlo
de muchos temas (n en "Temas") mientras que un tema tiene un slo gnero musical que lo
representa (1 en "GnerosMusicales").
Somos concientes que estamos dejando pendientes de resolucin, algunos aspectos de la
realidad del mercado de los discos compactos musicales que alteraran el razonamiento que
acabamos de hacer. Nos referimos en particular al hecho que un mismo tema muchas veces
en interpretado por distintos artistas, los que le aportan su impronta particular, incluso
variando el gnero musical original. Por otra parte un mismo artista puede tener grabado el
mismo tema en ms de un compacto diferente, como por ejemplo la versin de estudio y la
unplugged.
Esto nos muestra que todo modelo de datos, en tanto es un modelo de una situacin que
ocurre en el mundo real, es de hecho una simplificacin de la misma. Tengamos presente
que ser posible incluir estas consideraciones dentro de nuestro modelo de entidades y
relaciones aunque a costa de un aumento en la complejidad del mismo. Este aumento en la
complejidad (que por otra parte crece en forma exponencial ms que lineal) trae aparejado
un aumento (tambin exponencial) en los costos de desarrollo, por lo que cada vez que se
nos presente una situacin de este tipo en la vida real deberemos evaluar con mucho,
muchsimo cuidado la conveniencia o no de incluir dichas prestaciones adicionales en
nuestro proyecto, o directamente resolver esas situaciones especiales de otra forma (por
ejemplo en una hoja de clculo).
No obstante, estas particularidades sern estudiadas ms adelante cuando profundicemos
en las variantes posibles del ejercicio.
Paso 5: Ahora los atributos
Veamos ahora los atributos necesarios para poner a funcionar el modelo anterior. Cada
una de las entidades descriptas hasta ahora, tienen un conjunto de atributos propio que
iremos ubicando a continuacin.

BD_I
Compactos
Consideremos como atributos de la entidad "Compactos" los siguientes:
NombreCompacto
SelloGrabador
AoGrabacion
y por supuesto una clave primaria para la tabla que estamos creando, que, cmo el nombre
del compacto puede perfectamente repetirse y adems recordemos que no es buena
prctica colocar como claves primarias datos de tipo texto, dado que son suceptibles de
errores ortogrficos o imperfecciones que luego dificultan la ubicacin del objeto. Nos
inclinamos entonces por un Identificador de Compacto, al que convertiremos en clave
primaria.
IdCompacto
Artistas
En cuanto a los artistas solamente nos preocupa mantener la unicidad en cuanto a los
nombres de stos, asociados por supuesto a una clave primaria. Realizaremos la distincin
entre nombres y apellidos slo a efectos de facilitar un futuro ordenamiento alfabtico de
stos.
IdArtista
ApellidoArtista
NombreArtista
Clientes
En relacin a los clientes, "Centro Musical" tiene inters almacenar datos ms completos
para sus campaas de marketing o ventas. Tomaremos las ms importantes:
IdCliente
ApellidoCliente
NombreCliente
DireccionCliente
TelefonoCliente

BD_I
E_MailCliente
etc...
Gneros Musicales
Aqu tambin la lista de gneros slo nos previene del riesgo de escribir el mismo gnero de
distinta forma en diferentes ocasiones, por lo que definiremos solamente un atributo para la
descripcin del gnero (por ejemplo "Jazz") y otro para numerar la lista obteniendo de esta
forma la clave primaria.
IdGenero
DescripcionGenero
Temas
Los Temas que forman parte de cada compacto merecen alguna atencin especial, puesto
que hemos creado esta entidad a partir de la necesidad de eliminar o resolver la relacin de
tipo n a n existente entre las entidades "Compactos" y "Artistas". Por lo tanto esta tabla de
"Temas" es el objeto asociativo de la mencionada relacin y como tal necesita contener las
claves primarias de las dos tablas que relaciona. Nos referimos por supuesto a los campos
de "IdArtista" e "IdCompacto" que necesariamente estarn presentes en la tabla de "Temas"
adems de los necesarios para la descripcin de cada uno de ellos, de los que hemos
agregado dos a modo de ejemplo:
IdCompacto
NroTema
IdArtista
IdGenero
NombreDelTema
DuracionDelTema
Entendemos como NroTema, la posicin del tema dentro del compacto (tema 1, tema 2,
tema 3, ...). No estamos pensando aqu en numerar automticamente la totalidad de los
temas registrados (cosa que ciertamente podramos hacer) debido a que nos interesa
mejorar nuestro conocimiento y manejo del funcionamiento de las claves en una
herramienta de bases de datos.
Con relacin a la eleccin de la clave primaria, hemos colocado la unin de dos campos para
llegar a la misma. Ello es debido a la necesidad de encontrar un identificador nico para
cada uno de los temas en cada compacto, y para hacerlo razonamos de la siguiente forma:
el campo IdCompacto es necesario pero no suficiente, debido a que nos identifica al

BD_I
subconjunto de temas que forman parte de un mismo compacto. Pero si a l le agregamos

el nmero de orden del tema dentro del compacto, entonces para cada uno de los
compactos de la coleccin habr un tema 1, tema 2, tema 3, con lo que cada uno de ellos
queda perfectamente diferenciado.
Cuando en una tabla colocamos campos que son las claves

primarias de otras a efectos de obtener una relacin entre ellas,
se dice que estamos colocando una "clave fornea" dentro de la
tabla. Por ejemplo el campo "IdArtista" e "IdGenero" en la tabla
de "Temas" son dos claves forneas que permiten la vinculacin
de sta con las tablas de "Artistas" y "GenerosMusicales"
respectivamente.
Facturas
El caso que nos queda ahora por resolver es tal vez el que requiera nuestra mayor atencin.
Est claro que las facturas operan como el objeto asociativo entre las tablas o entidades de
"Clientes" y "Compactos". Pero a su vez dentro de cada factura individual pueden ser
vendidos varios compactos. Aqu se nos plantea un problema similar al de los "Autores" y los
"Libros" del primer ejercicio. Tenemos un documento llamado "Factura" que tiene datos que
son nicos para cada una de ellas (datos del cliente, nmero de factura, fecha de emisin,
total facturado, y otros) y datos que son no slo variables sino acumulativos como los
diferentes compacto que en cada venta se comercializan. Por lo tanto la representacin fsica
de la entidad "Facturas" no puede realizarse en una sla tabla, sino que deben de ser dos, a
saber: una en la que colocaremos todos los datos que aparecen u ocurren una sla vez en
cada factura y otra que contendr el grupo repetitivo de las ventas hechas en cada factura.
Para usar un estndar de desarrollo muy extendido a nivel de los sistemas comerciales,
llamaremos a estas tablas:
Facturas
RenglonesFacturas
en el entendido que ambas tablas describen a la misma entidad llamada "Facturas"
La descripcin de atributos o campos de estas tablas queda como sigue:
Facturas
NroFactura
FechaFactura
IdCliente
TotalFactura
etc...
RenglonesFacturas

BD_I
NroFactura
NroRenglon
IdCompacto
ImporteUnitario
Cantidad
ImporteTotal
etc...
Repetimos el razonamiento para hallar la clave primaria en cada una de las tablas. En el
caso de la tabla "Facturas" la clave primaria ser lgicamente el nmero de factura
"NroFactura" que adems ya se encuentra preimpreso en la misma, lo que nos facilita
mucho las cosas. Con respecto a la tabla de "RenglonesFacturas" el campo "NroFactura"
utilizado slo no es suficiente, dado que nos identifica al conjunto de renglones de venta que
forman parte de una factura y no a cada rengln en particular. Es por ello que para la
definicin de la clave primaria le agregamos el nmero de rengln "NroRengln" de forma de
lograr as la identificacin nica de cada rengln de venta.
Por supuesto que la relacin entre la tabla de "Facturas" y "RenglonesFacturas" est dada
por el campo "NroFactura" y es del tipo de 1 a n con el 1 hacia la tabla de Facturas (dado
que all es clave primaria) y el n hacia la tabla de RenglonesFacturas puesto que all no lo
es.
Cuando tenemos una clave primaria formada por ms de un

campo, entonces la propiedad de identificar en forma nica a
cada elemento o registro de la tabla es del conjunto de los
campos y NO de cualquiera de ellos en forma independiente.
Veamos ahora como queda finalmente el diagrama o modelo de entidad-relacin

finalmente:

BD_I
Paso 6: Construyamos el modelo final
Y mostrando la estructura de campos que ya hemos definido antes con sus

correspondientes claves primarias, nos queda:

BD_I
Fin de la Clase 7

Introducción Al Modelo Relacional

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Introducción Al Modelo Relacional

Transféré par

Droits d'auteur :

Formats disponibles

BD_I

Bases de Datos para Emprendedores

"Access" la base de datos de escritorio de Microsoft se ha convertido en un convidado de piedra

file:///E|/DESK/Educacin/Educacin a Distancia/Cur...ndedores/Mdulo 1 Introduccin/Clase 1/Bde_0101.htm (1 of 9) [12/11/2001 15:12:57]

Qu es una base de datos?

"Es una coleccin de datos interrelacionados almacenados en

file:///E|/DESK/Educacin/Educacin a Distancia/Cur...ndedores/Mdulo 1 Introduccin/Clase 1/Bde_0101.htm (2 of 9) [12/11/2001 15:12:57]

file:///E|/DESK/Educacin/Educacin a Distancia/Cur...ndedores/Mdulo 1 Introduccin/Clase 1/Bde_0101.htm (3 of 9) [12/11/2001 15:12:57]

todo se reduce a la creacin de una capa de programacin a la que llamamos "Administrador de

La siguiente figura es un esquema general del funcionamiento de un Administrador de Bases de

Niveles de aproximacin al modelo de

file:///E|/DESK/Educacin/Educacin a Distancia/Cur...ndedores/Mdulo 1 Introduccin/Clase 1/Bde_0101.htm (4 of 9) [12/11/2001 15:12:57]

datos. En este nivel

Por ejemplo, una

file:///E|/DESK/Educacin/Educacin a Distancia/Cur...ndedores/Mdulo 1 Introduccin/Clase 1/Bde_0101.htm (5 of 9) [12/11/2001 15:12:57]

file:///E|/DESK/Educacin/Educacin a Distancia/Cur...ndedores/Mdulo 1 Introduccin/Clase 1/Bde_0101.htm (6 of 9) [12/11/2001 15:12:57]

Los componentes del modelo de Bases de Datos

Son ejemplos de entidades:

file:///E|/DESK/Educacin/Educacin a Distancia/Cur...ndedores/Mdulo 1 Introduccin/Clase 1/Bde_0101.htm (7 of 9) [12/11/2001 15:12:57]

Es de gran importancia encontrar la totalidad de las colecciones necesarias para el trabajo de

Como contraparte a lo antes mencionado, es necesario que no definamos ms entidades de las

Definimos ATRIBUTOS como aquellas caractersticas o cualidades de las ENTIDADES que

file:///E|/DESK/Educacin/Educacin a Distancia/Cur...ndedores/Mdulo 1 Introduccin/Clase 1/Bde_0101.htm (8 of 9) [12/11/2001 15:12:57]

facturas como herramienta de trabajo de su negocio, lo anterior el perfectamente vlido. Ahora,

file:///E|/DESK/Educacin/Educacin a Distancia/Cur...ndedores/Mdulo 1 Introduccin/Clase 1/Bde_0101.htm (9 of 9) [12/11/2001 15:12:57]

Bases de datos para emprendedores

Presentacin de Access 2000

Access 2000 es la herramienta de bases de datos de Microsoft para pequeas aplicaciones.

file:///E|/DESK/Educacin/Educacin a Distancia/Cu...dedores/Mdulo 1 Introduccin/Clase 2/Bde_0102.htm (1 of 18) [12/11/2001 15:14:07]

Creando nuestra primer Base de Datos

file:///E|/DESK/Educacin/Educacin a Distancia/Cu...dedores/Mdulo 1 Introduccin/Clase 2/Bde_0102.htm (2 of 18) [12/11/2001 15:14:07]

file:///E|/DESK/Educacin/Educacin a Distancia/Cu...dedores/Mdulo 1 Introduccin/Clase 2/Bde_0102.htm (3 of 18) [12/11/2001 15:14:07]

Los componentes de la ventana de base de datos de Access

Lo que nos queda en pantalla es lo siguiente:

VENTANA DE BASE DE DATOS

file:///E|/DESK/Educacin/Educacin a Distancia/Cu...dedores/Mdulo 1 Introduccin/Clase 2/Bde_0102.htm (4 of 18) [12/11/2001 15:14:07]

Analicemos ahora uno a uno cada elemento relevante:

Utilizaremos esta opcin para poner en funcionamiento o ver el contenido de

file:///E|/DESK/Educacin/Educacin a Distancia/Cu...dedores/Mdulo 1 Introduccin/Clase 2/Bde_0102.htm (5 of 18) [12/11/2001 15:14:07]

file:///E|/DESK/Educacin/Educacin a Distancia/Cu...dedores/Mdulo 1 Introduccin/Clase 2/Bde_0102.htm (6 of 18) [12/11/2001 15:14:07]

Los informes o listados operan en forma anloga a los formularios. En ellos no es

file:///E|/DESK/Educacin/Educacin a Distancia/Cu...dedores/Mdulo 1 Introduccin/Clase 2/Bde_0102.htm (7 of 18) [12/11/2001 15:14:07]

Los mdulos son porciones de cdigo de programacin escritos en Visual Basic.

file:///E|/DESK/Educacin/Educacin a Distancia/Cu...dedores/Mdulo 1 Introduccin/Clase 2/Bde_0102.htm (8 of 18) [12/11/2001 15:14:07]

La lista de componente o panel derecho de la ventana de base de datos, nos permite

Definicin de tablas en una base de datos.

file:///E|/DESK/Educacin/Educacin a Distancia/Cu...dedores/Mdulo 1 Introduccin/Clase 2/Bde_0102.htm (9 of 18) [12/11/2001 15:14:07]

file:///E|/DESK/Educacin/Educacin a Distancia/C...edores/Mdulo 1 Introduccin/Clase 2/Bde_0102.htm (10 of 18) [12/11/2001 15:14:07]

Veamos ahora el significado de los trminos que utilizamos en el ejemplo anterior:

file:///E|/DESK/Educacin/Educacin a Distancia/C...edores/Mdulo 1 Introduccin/Clase 2/Bde_0102.htm (11 of 18) [12/11/2001 15:14:07]

Access reconoce los siguientes tipos de datos:

Asistente para bsquedas

file:///E|/DESK/Educacin/Educacin a Distancia/C...edores/Mdulo 1 Introduccin/Clase 2/Bde_0102.htm (12 of 18) [12/11/2001 15:14:07]

Numrico. Se usan en campos que almacenan nmeros. Su tamao depende de una

est vacunado? (Si/No)

file:///E|/DESK/Educacin/Educacin a Distancia/C...edores/Mdulo 1 Introduccin/Clase 2/Bde_0102.htm (13 of 18) [12/11/2001 15:14:07]

file:///E|/DESK/Educacin/Educacin a Distancia/C...edores/Mdulo 1 Introduccin/Clase 2/Bde_0102.htm (14 of 18) [12/11/2001 15:14:07]

file:///E|/DESK/Educacin/Educacin a Distancia/C...edores/Mdulo 1 Introduccin/Clase 2/Bde_0102.htm (15 of 18) [12/11/2001 15:14:07]

file:///E|/DESK/Educacin/Educacin a Distancia/C...edores/Mdulo 1 Introduccin/Clase 2/Bde_0102.htm (16 of 18) [12/11/2001 15:14:07]

file:///E|/DESK/Educacin/Educacin a Distancia/C...edores/Mdulo 1 Introduccin/Clase 2/Bde_0102.htm (17 of 18) [12/11/2001 15:14:07]

Definir el problema a resolver (especificarlo formalmente)

file:///E|/DESK/Educacin/Educacin a Distancia/C...edores/Mdulo 1 Introduccin/Clase 2/Bde_0102.htm (18 of 18) [12/11/2001 15:14:07]

Bases de datos para emprendedores

file:///E|/DESK/Educacin/Educacin a Distancia/Cur...ndedores/Mdulo 1 Introduccin/Clase 3/Bde_0103.htm (1 of 9) [12/11/2001 15:15:03]