Estructura de Datos - Normalizacion

_________________________________________________________________________
UNIVERSIDAD DE BUENOS AIRES

FACULTAD DE CIENCIAS ECONMICAS
TECNOLOGA DE LA INFORMACIN

Gua Unificada de Trabajos Prcticos

para cursos regulares

4 Ctedra.

Titular: Dr: Jose Seoane

Autores (por orden alfabtico):

Prof. Gonzlez Bosque, Marcelo
Prof. Mortara, Lucila
Prof. Regueiro Prez, Mara Alejandra
Prof. Rodrguez Sebedio, Mariana

UBA FCE Tecnologa de la Informacin. Gua de trabajos prcticos.
2

ndice:

Parte Terica

Estructura de Datos. Normalizacin

SQL

Diagramacin Lgica

Parte Practica Normalizacin

Ejercicios Normalizacin
Ejercicio 1: Caso: MuyFacil Sociedad de hecho
Ejercicio 2: Caso: Pottery Dolls.com.
Ejercicio 3: Expedientes Digitales
Ejercicio 4: Caso: Drawings Consulting
Ejercicio 5: Caso: Salsipuedes
Ejercicio 6: Caso: NotadePedido
Ejercicio 7: Caso: Biblioteca
Ejercicio 8: Caso: Videoclub
Ejercicio 9: Caso: Cotizacin de una ferretera
Ejercicio 10: Caso: Informe de Servicio tcnico
Ejercicio 11: Caso: Orden de pago
Ejercicio 12: Caso: Presupuesto

Parte Practica Proyectos

Ejercicio 13: Caso: Construccin de un sitio WEB

3
Parte Practica SQL

Ejercicio 14: Caso: Ejercicios SQL
Ejercicio 15: Caso: Mas Ejercicios SQL

Parte Practica Diagrama de Lgica

Ejercicio 16: Caso: Publicaciones

Ejercicio 17:Caso : Medicina Prepaga

Ejercicio 18: Caso: Comercializacin de botas

Ejercicio 19:Caso:: Recaudacin de impuestos

Ejercicio 20:Caso: Casa de comidas rpidas

Ejercicio 21:Caso: Almacenes

Ejercicio 22:Caso: Videoclub

4

Estructura de Datos.
Metodologa para resolver los
ejercicios de normalizacin

Por Lic. Marcelo Gonzlez Bosque

La Normalizacin es una tcnica que nos permite introducir los datos en las tablas y disear
las mismas de tal manera de hacer mas eficientes las bsquedas de datos y las consultas de
informacin. Los ejercicios pueden provenir presentados como un formulario, o como un
texto. El primer paso para la resolucin consiste en extraer los datos relevantes que van a
formar parte de nuestra base de datos e ignorar la informacin irrelevantes y clculos que no
nos sirven para ser guardados. Como ejemplo de estos tenemos al nombre de la propia
empresa. Generalmente debemos suponer que la empresa no guarda su propio nombre en una
base de datos, o que si lo hace se trata de otro sistema aparte. Los clculos tampoco deben ser
guardados sino los datos fuente. La computadora se puede ocupar de reconstruir el valor a
partir de los datos fuente. Ejemplos tpicos son los "totales", "subtotales" etc. Si tenemos los
datos originales, la maquina puede sumarlos
Veamos el siguiente ejemplo:
Ejercicio Tema: Empresa de Medicina Laboral.
En el ejemplo que desarrollaremos a continuacin, el campo Empresa significa la empresa
Cliente, o sea que la empresa que contrata el servicio, no el nombre de la propia empresa.
Veamos el siguiente formulario:

5

Paso 1: Extraccin de los datos relevantes:
Los mismos son:
Fecha, Empresa, Apellido, Nombre, Atendidoen, Hora, Informe, Deambula, Trabaja,
Trabajadia, Citadodia, citadohora.
Llamaremos a estos datos ARCHIVO PLANO. El archivo plano ser la base para
confeccionar nuestra base de datos.
Paso 2. Identificar los campos codificables.
Los campos codificables son aquellos en los cuales los valores que se van a colocar estn
acotados a una serie de respuestas finitas. Ejemplo: En una base donde aparezca el campo
"Color", la respuesta podr ser solo "blanco", "azul", "rojo", es decir nombres de colores, pero
no puede ser "rugoso", "hmedo" o "1234". En otras palabras, la respuesta est acotada a los
nombres de los colores y nada mas que los nombres de los colores.
No podramos codificar un campo "Comentarios", ya que las respuestas dadas sern tan
dispares y no frecuentes que en la practica cada registro tendr una respuesta diferente.
Volviendo al campo codificable "Color" Podramos tener entonces una tabla como la
siguiente. El numero de registro no es el cdigo, sino una numeracin dada automticamente
por la computadora a medida que se crea un nuevo registro.

N
Registro
COLOR
1 rojo
6
2 rojo
3 violeta
4 Violeta
5
verde
azulado
6
verde
azulado
7
verde
asulado
8 Escarlata
9 Escarlata

Observando detenidamente, tenemos que:
a) Cuando tenemos que escribir el valor completo en vez de un cdigo, podemos cometer
errores (verde asulado). Para la computadora, este error hace que el dato sea tratado
como un dato diferente en vez de un error. Si le pedimos que cuente cuantos registros
hay de color "verde azulado", contara solo 2, porque el registro "verde asulado" no
ser considerado como "verde azulado".
b) Por otro lado, generalmente existen sinnimos de los datos, que en definitiva provocan
el mismo error que si fuera una falta de ortografa. Por mas que rojo y escarlata son lo
mismo, si le pedimos a la maquina que nos diga cuantos registros "rojos" hay nos dir
2 en vez de cuatro. Tambin se puede dar el caso opuesto o sea el tener homnimos
(datos que parecen iguales pero son distintos). En cambio, si usamos las tablas
codificadas, tendremos:

Tabla Nro 1 Tabla Nro 2
Cantidades Colores
N Registro Color Codigo Nombre
1 1 1 rojo/escarlata
2 1 2 violeta
3 2 3 verde azulado
4 2
5 3
6 3
7 3
8 1
9 1

Vemos que por el hecho de codificar los colores, obtenemos los siguientes efectos:
7
a) Es mucho mas difcil equivocarse. El operador puede llegar a cargar "2" en vez de "1",
pero este error es mucho mas difcil de hacer que escribir el nombre del color con
algn tipo de error de ortografa.
b) La carga de datos es mas rpida. No es lo mismo escribir "1" que "rojo/escarlata"
c) Se evita el problema de los sinnimos. "Rojo" es "1", lo mismo que "escarlata" y no
se generan problemas de interpretacin con los sinnimos
d) La maquina no se equivoca. Si le pedimos saber cuantos registros rojos hay,
responder "4". Por ende, hay que identificar los campos codificables que existan en la
lista de campos que hemos extrado del punto anterior. Aqu tenemos dos
posibilidades:
a. Que los campos ya estn codificados
b. Que no lo estn: En este caso el analista debe crear cdigos para los mismos.
Volviendo al ejercicio de Medicina Laboral, tenemos que el listado de campos es:
Fecha, Empresa, Apellido, Nombre, Atendidoen, Hora, Informe, Deambula, Trabaja,
Trabajadia, Citadodia, citadohora.
Vamos a trabajar con Apellido y nombre como si fueran un solo campo llamado nombre ya
que no tiene sentido el tener separado al nombre del apellido. Podemos observar que los
campos empresa y nombre son codificables, pero que no tienen cdigo, por lo que hay que
crearlo. Por otro lado, el formulario mismo no esta codificado. Una buena norma de control
interno de circuitos administrativos, (aplicable en este caso al anlisis de sistemas,) indica que
los formularios o documentos deben estar prenumerados a los efectos de su mejor control.
Por ende, procederemos tambin a prenumerar el equivalente electrnico del formulario. Nos
quedan entonces:
Nro de formulario, Codigo de Empresa, Nombre de Empresa, Fecha, Legajo, Nombre,
Atendidoen, Hora, Informe, Deambula, Trabaja, Trabajadia, Citadodia, citadohora.

Paso 3. Establecer claves primarias, secundarias , dependencias y dar nombre a las
tablas.

Si tenemos una hipottica tabla con los campos

Legajo Apellido Nombre Sueldo
1 Gmez Juan $1000
2 Snchez pedro $500
3 Rodrguez Alberto $400
4 Snchez Juan $200
5 Snchez Juan $300

8
Si queremos ubicar una persona determinada, podemos buscar por apellido, pero tambin
podemos llegar al mismo si sabemos el numero de legajo. En otras palabras, Se puede buscar
los datos del Sr. Rodrguez pero tambin los del numero de legajo 3. Observando bien los
datos vemos aqu un caso de Homnimos: Hay tres Sres. Snchez. El Sr. Snchez de legajo
Nro 2 no es el mismo del legajo 4. Si buscamos "Snchez" por nombre nos encontraremos con
tres registros. Si buscamos "Juan Snchez", igual nos encontramos con dos personas
diferentes. Vemos aqu el caso que buscar gente por el nombre puede dar lugar a
ambigedades (encontrar mas de una persona), porque puede haber varias personas que se
llamen igual. Si queremos saber cual es el sueldo de "Juan Snchez", buscando por nombre y
apellido, eso no es posible ya que no sabemos si nos referimos al de $200 o al de $300. Para la
mayora de las operaciones computacionales, es necesario el poder ubicar exactamente el
registro necesario, o sea al Sr. Snchez requerido. Para ello se necesitan determinados campos
que me permitan identificar el registro (la fila de datos) sin ambigedades. Estos campos
reciben el nombre de "Claves primarias" del registro, y coinciden generalmente con alguna
de los cdigos acerca de los que estbamos hablando en el punto anterior. Las claves pueden
ser de un campo ("Nombre"), en donde se llaman claves simples, o de varios campos
("Nombre" + "apellido"), en donde se llaman claves concatenadas. En ejemplos mas
complejos, adems de la clave primaria pueden aparecer otras claves, que reciben el nombre
de claves secundarias o de seleccin. Las claves secundarias dependen de la clave primaria.
Los campos que no son clave, reciben el nombre de campos "dependientes" de la clave. Es
decir, si se va a buscar por numero de legajo, para averiguar el nombre, apellido y sueldo,
estos campos "dependen" del numero de legajo para ser identificados. La dependencia,
entonces es una propiedad que poseen todos los campos que no son clave, con respecto a la
misma. En este ejemplo, ni "Nombre" ni "Apellido" ni "Nombre+apellido" son buenas claves
primarias. En cambio "Legajo" es una buena clave primaria, ya que identifica a las personas
sin ambigedades. Se presupone que cada empleado tiene un nico numero de legajo. Si se
busca entonces el sueldo del legajo Nro 5, el resultado es $300. La clave primaria se puede
denotar subrayando el campo o con un asterisco Tenemos entonces una tabla:
LEGAJO,NOMBRE,APELLIDO,SUELDO, donde legajo es la clave primaria.
Es conveniente dar un nombre aglutinante a los campos de las tablas. Cualquier nombre que
represente la idea de lo que contiene la tabla es apropiado. El analista debe poner nombre a las
tablas. Una vez que hemos nombrado a las tablas, se exponen las mismas en el siguiente
formato: PERSONAL(LEGAJO,NOMBRE,APELLIDO,SUELDO) En donde PERSONAL es
el nombre de la tabla, los campos estn entre parntesis y el campo subrayado es la clave
primaria.
Por ende, tenemos que:
Legajo: Clave Primaria
Nombre, apellido, sueldo: Dependen de Legajo
Volviendo al ejemplo principal Medicina Laboral, tenemos que habamos llegado a:
Nro de formulario, Codigo de Empresa, Nombre de Empresa, Fecha, Legajo, Nombre,
Atendidoen, Hora, Informe, Deambula, Trabaja, Trabajadia, Citadodia, citadohora.
El nico campo que me permite recuperar el registro sin ambigedades ni repeticiones es el
Nro de formulario, por lo que ser nuestra clave primaria. Podemos darle un nombre a este
archivo plano, en concordancia con lo antes visto, con lo que nos queda:
9
Archivo Plano Medicina Laboral (Nro de formulario, Cdigo de Empresa, Nombre de
Empresa, Fecha, Legajo, Nombre, Atendidoen, Hora, Informe, Deambula, Trabaja,
Trabajadia, Citadodia, citadohora.)
El siguiente paso (opcional) es construir un cuadro, al que denominaremos "Cuadro de
Dependencias General", que resuma la informacin antes dicha:

Cuadro de Dependencias General
Nro de formulario clave primaria
Codigo de Empresa clave secundaria
Nombre de Empresa depende de Codigo de Empresa
Fecha depende de Nro de formulario
Legajo clave secundaria
Nombre
depende de Codigo de Empresa
+ Legajo
Atendidoen depende de Nro de formulario
Hora depende de Nro de formulario
Informe depende de Nro de formulario
Deambula, depende de Nro de formulario
Trabaja depende de Nro de formulario
Trabajadia depende de Nro de formulario
Citadodia depende de Nro de formulario
citadohora depende de Nro de formulario

Paso 4. Aplicar las Formas Normales.
El archivo plano todava no esta optimizado. La Normalizacin es una tcnica que se usa para
optimizar el tamao y rendimiento de los archivos. Para hacerlo se aplican las llamadas
"Formas normales" elaboradas por los autores Boyce y Codd en ladcada de los 1970s

Identificacin de las Formas normales segn el mtodo de Boyce y Codd

Se parte de un archivo plano (por definicin no normalizado) con sus claves identificadas y
sus relaciones de dependencia discriminadas. En nuestro caso el archivo plano lo tenemos al
final del punto anterior.
Los autores identifican varios efectos, pero en la practica de usan los tres primeros, a los que
se llaman Primera, segunda y tercera forma normal. (1FN, 2FN y 3FN)
La primera forma normal requiere identificar grupos repetitivos y separarlos del archivo
plano.
10
Ejemplo de grupo repetitivo :
En la tabla:

Legajo Nombre Apellido Nombre Hijos
1 Juan Gomez Carlos
2 Pedro Suazo Piero
3 Perico Juarez Alicia
4 Silvia Quiroga Juan
4 Silvia Quiroga Pedro
4 Silvia Quiroga Lucho
4 Silvia Quiroga Pucho
4 Silvia Quiroga Cucho

Vemos que el legajo 4 tiene 5 hijos, lo que obliga a crear registros en blanco solo para poner
el nombre de los hijos. Esto esta visto por la teora como un efecto indeseable en una tabla que
debe ser optimizado ya que hace mas lentos a los procesos de la tabla y genera problemas para
buscar/recuperar los datos. Un grupo repetitivo es un campo que puede tener varios valores
para un mismo registro. (una persona tiene un legajo, un nombre y apellido, pero puede tener
varios hijos)
Entonces la 1FN nos dice que partiendo del archivo plano:
PERSONAL(LEGAJO,NOMBRE,APELLIDO,NOMBRE HIJOS), lo dividamos en:
PERSONAL(LEGAJO,NOMBRE,APELLIDO) HIJOS(LEGAJO,NOMBRE HIJOS)

En forma conceptual: Si tenemos una tabla:
TABLA(1,2,3,4), donde 1 es la clave primaria y 4 es un campo que puede tener varias
ocurrencias por cada una de los dems campos, se separa el grupo repetitivo de los dems
campos. Nos queda:
TABLA(1,2,3) TABLA2(1,4)
Ntese que ambas tablas comparten el campo 1, el cual es la clave primaria de la primera
tabla, y forma parte de la clave primaria concatenada de la segunda. En este punto, las tablas
estn en Primera forma Normal 1FN

11

TABLA(1,2,3,4)= Archivo Plano no normalizado

TABLA(1,2,3) TABLA2(1,4)= Tablas luego de aplicar 1FN

Volviendo al ejemplo de Medicina Laboral, no se encuentran grupos repetitivos, por lo que
por el momento no hay que hacer nada. Esto es as porque cada formulario esta hecho para un
solo paciente. Si el formulario pudiera abarcar a mas de un paciente tendramos grupos
repetitivos. Un archivo plano que no tiene grupos repetitivos pasa automticamente a estar en
1FN, y deja de llamarse archivo plano, para llamarse "Tabla".
Medicina Laboral(Nro de formulario, Cdigo de Empresa, Nombre de Empresa, Fecha,
Legajo, Nombre, Atendidoen, Hora, Informe, Deambula, Trabaja, Trabajadia, Citadodia,
citadohora.)= Esta en 1FN

La segunda forma normal se da en casos en que exista una clave primaria concatenada (ver
definicin en los prrafos precedentes) y requiere identificar campos que no dependan
totalmente de la clave concatenada y separarlos de las tablas.
La segunda forma normal nos pide identificar y separar los campos que dependan
completamente de la clave primaria concatenada y los que no dependan.
En este ejemplo, al no haber una clave primaria concatenada, podemos decir que la tabla est
en segunda forma normal 2FN.
Para ampliar la explicacin veamos un ejemplo conceptual:
Supongamos una tabla de asignacin de tareas por da. A cada legajo se le asigna solo una
tarea diferente por cada da.

Tareasxdia(Legajo, dia, nombre_empleado, tarea)

Dado que cada tarea varia cada da, no es suficiente con el legajo solo para ubicar a la tarea
especifica, sino que es la tarea que un legajo tiene en un da determinado. La clave primaria es
"Legajo+dia". Tarea depende de la clave primaria Legajo+dia. Hasta aqu no hay
problema. Sin embargo, "nombre_empleado" solo depende del numero de legajo, no tiene
nada que ver con da.
Tenemos entonces que se separa el campo nombre y queda:

Tareasxdia(Legajo, da, tarea) Legajos(Legajo, nombre_empleado)
12

En forma conceptual: Si tenemos una tabla:

TABLA(1,2,3,4), donde 1+2 es la clave primaria y 4 es un campo que no depende totalmente
de ella, (depende solo de 1) se separa el campo de la tabla.

TABLA(1,2,3) TABLA2(1,4)

Ntese que ambas tablas tienen distinta clave primaria, aunque comparten el campo comn
1 en ambas claves. En este punto, las tablas estn en Segunda forma Normal 2FN

TABLA(1,2,3) TABLA2(1,4) = Tablas luego de aplicar 2FN

La tercera forma normal se da en casos en que existan claves secundarias (ver definicin en
los prrafos precedentes) y campos que dependan de estas claves secundarias. La operatoria
requiere identificar los campos que dependan de las claves secundarias y separarlos de la/s
tabla/s. Las claves secundarias pueden ser simples o concatenadas. En otras palabras, la/s
tabla/s se dividen de tal manera de extraer los campos que dependen de las claves secundarias.

Partiendo de :

Medicina Laboral(Nro de formulario, Codigo de Empresa, Nombre de Empresa, Fecha,
Legajo, Nombre, Atendidoen, Hora, Informe, Deambula, Trabaja, Trabajadia, Citadodia,
citadohora.)

En donde:
Nro de formulario: clave primaria
Codigo de Empresa: clave secundaria
Nombre de Empresa: depende de Codigo de Empresa
Fecha: depende de Nro de formulario
13
Legajo: clave secundaria
Nombre: depende de Codigo de Empresa + Legajo
Atendidoen: depende de Nro de formulario
Hora :depende de Nro de formulario
Informe: depende de Nro de formulario
Deambula: depende de Nro de formulario
Trabaja: depende de Nro de formulario
Trabajadia: depende de Nro de formulario
Citadodia: depende de Nro de formulario
Citadohora: depende de Nro de formulario

Tenemos que "Nombre" depende de "Cdigo de Empresa + Legajo" como clave secundaria
concatenada, pero esta clave depende de "Nro de formulario" que es la clave primaria.
Aplicamos tercera forma normal y nos queda:

Empleados x Empresa(Codigo de Empresa, Legajo, Nombre)

Medicina Laboral(Nro de formulario, Codigo de Empresa, Nombre de Empresa, Fecha,
Legajo, Atendidoen, Hora, Informe, Deambula, Trabaja, Trabajadia, Citadodia, citadohora.)

Tenemos tambin el campo Nombre de Empresa que depende de Codigo de Empresa, que es
una clave secundaria simple que a su vez depende de la clave primaria.

Aplicando la tercera forma normal para este caso, nos queda:

Empleados x Empresa(Codigo de Empresa, Legajo, Nombre)

Medicina Laboral(Nro de formulario, Codigo de Empresa, Fecha, Legajo, Atendidoen,
Hora, Informe, Deambula, Trabaja, Trabajadia, Citadodia, citadohora.)

14
Empresas Clientes( Codigo de Empresa, Nombre de Empresa)

Como no encontramos mas campos que normalizar, podemos decir que las tablas estn
normalizadas.

Nuestra solucin del ejercicio es entonces:

1. Empleados x Empresa(Codigo de Empresa, Legajo, Nombre)

2. Medicina Laboral(Nro de formulario, Codigo de Empresa, Fecha, Legajo, Atendidoen,

3. Empresas Clientes( Codigo de Empresa, Nombre de Empresa)

Estas tres tablas constituyen nuestra base de datos del sistema.

En forma conceptual:
Partiendo de TABLA(1,2,3,4), donde 1 es la clave primaria, 3 una clave secundaria y 4 es un
campo que depende de la clave secundaria 3, se separan los campos que dependen de la clave
secundaria de la tabla principal

TABLA(1,2,3,) TABLA2(3,4)

Ntese que si bien ambas tablas comparten el campo 3, el mismo no forma parte de la clave
primaria de la primer tabla, a diferencia de la 1FN en la que las tablas tienen en sus claves
primarias un campo en comn.

En este punto, las tablas estn en Tercera forma Normal 3FN

15

TABLA(1,2,3,4)= Tabla antes de 3FN
TABLA(1,2,3) TABLA2(3,4)= Tablas luego de aplicar 3FN. Tablas normalizadas

Paso 5: Diagrama de Entidad Relacin. (DER). Mapa de Relaciones.

Una vez obtenidas las tablas normalizadas, resta realizar el diagrama de entidad relacin.
(DER), originado en la metodologa del autor Yourdon. Vamos a explicar aqu la modalidad
conocida como Mapa de Relaciones. La misma parte de la base de que las tablas las tablas
normalizadas. Volviendo al ejemplo nos quedaban tres tablas. Aqu las llamaremos Entidades:
Por ende, la primera parte que es identificar las entidades ya la tenemos resuelta al tener las
tablas normalizadas.

Empleados x Empresa

Medicina Laboral

Empresas Clientes

La segunda parte consiste en identificar las relaciones entre las tablas. Esto tambin se obtiene
de las tablas normalizadas. Las tablas que tengan una clave o campo en comn, sern las que
tengan relaciones.
De la observacin de los campos de las tablas se manifiesta que:
Empleados x Empresa se relaciona con Medicina Laboral por medio de su clave codigo de
empresa +legajo con los campos equivalentes de Medicina Laboral.
Empresas Clientes se relaciona con Medicina Laboral por medio de su clave codigo de
empresa con el campos equivalente de Medicina Laboral.
Nuestro mapa de relaciones hasta el momento es el siguiente:

16
Empleados x Empresa Medicina Laboral Empresas Clientes

El DER requiere adems que se especifique el tipo de relacin entre las entidades.

Las relaciones validas entre dos entidades pueden ser:

De 1 a 1
De 1 a muchos (o muchos a 1)

Desde el punto de vista terico, si una relacin es de muchos a muchos, delata que la
normalizacin no se ha hecho correctamente. La misma debe ser reconsiderada como dos
relaciones, una de uno a muchos y otra de muchos a uno.

Ejemplo de nomenclatura de relacin 1 a 1

Entidad 1 ||----------||

Entidad 2

Ejemplo de nomenclatura de relacin 1 a muchos (Entidad 1 con Entidad 2) y muchos a 1
(Entidad 2 con Entidad 3)

Entidad 1 ||----|< Entidad 2 >|----||

Entidad 3

Las relaciones (1 a 1) o (1 a muchos) dependen de las caractersticas de cada sistema y son
relativas al comportamiento de los registros de las tablas. En el caso de la relacin 1 a 1
significa que un registro de la tabla 1 estar relacionado con slo 1 registro de la tabla 2. En el
caso de la relacin 1 a muchos, significa que un registro de la tabla 1 podr estar relacionado
con mas de un registro de la tabla 2.

17
Volviendo al ejercicio de Medicina Laboral, tenemos que:

Cada formulario tiene espacio para una sola persona. No se pueden poner datos de mas de una
persona por formulario. Esto implica que cada registro de la tabla Medicina Laboral, que
contiene los datos del formulario solo podr estar relacionado con un registro de la tabla
Empleados x Empresa, pero cada empleado puede haber estado enfermo varias veces, por lo
que cada registro puede estar relacionado con muchos registros de Medicina Laboral.
Si suponemos que cada empleado trabaja en una sola empresa a la vez (lo que seria lo mas
lgico), cada registro de la tabla Medicina Laboral, que contiene los datos del formulario slo
podr estar relacionado con un registro de la tabla Empresas Clientes o sea la empresa en que
trabaja el paciente de cada formulario, pero una empresa seguramente va a tener varios
empleados enfermos a lo largo del tiempo, por lo que cada registro de Empresas Clientes
puede estar relacionado con muchos registros de Medicina Laboral,
Se vuelve a hacer hincapi que el tipo de relacin vara de sistema en sistema y debe ser
averiguado por medio del relevamiento en campo y del uso del sentido comn.

En este ejemplo entonces nos queda que:

Empresas Clientes ||----|< Medicina Laboral >|----||

Empleados x Empresa

18

Introduccin al SQL.
Instrucciones usuales

Por Lic. Marcelo Gonzlez Bosque

El SQL (siglas en ingles de Structured Query Language - Lenguaje de Consultas
Estructurado) es un medio estandarizado de realizar operaciones en las bases de datos, ya que
esta soportado (implementado) en la mayora de los programas modernos.
Como ejemplo, todos los programas de la plataforma Microsoft(*) como Access, SQL Server,
Visual Basic, ASP etc. lo han incorporado, por lo que su difusin es global y masiva.
Esto quiere decir que simplemente teniendo acceso a alguno de estos programas, tendremos la
oportunidad de poder utilizar este lenguaje.

Caractersticas:

A los efectos de este trabajo, se tomar como base el programa Microsoft Access, pero esto no
implica en modo alguno que su utilizacin sea mejor a otros software de compaas
diferentes.
Existen dos maneras de introducir el cdigo SQL.
1) De modo directo
2) Utilizando un programa generador de codigo
El Access nos permite elegir entre ambas modalidades.
___________________________________________________________________________

Introduciendo Instrucciones SQL mediante un generador de Cdigo

Partiendo de una base de datos, compuesta por varias tablas normalizadas, nosotros podemos
efectuar consultas de la siguiente manera:

19
Paso 1: Entrar al programa Access. La pantalla que aparecer ser similar a la expuesta a
continuacin. La misma cambia segn la versin que tengamos, pero mantiene los
componentes principales. Dentro de esta pantalla, se deber seleccionar la opcin "Consultas"
aqu sealada como un texto recuadrado en el men de la izquierda. Una vez en ese lugar
observamos que en el men de arriba existen dos opciones, una llamada "Nuevo" para
efectuar nuevas consultas y una llamada "diseo" para modificar las ya hechas.

Paso 2: Al presionar el men "Nuevo", aparece la siguiente pantalla.

Seleccionamos la opcin "Vista diseo" y aparece la siguiente pantalla:
20

La misma nos pide seleccionar las tablas (que deben haber sido creadas anteriormente). Por
ejemplo, seleccionamos una de las tablas llamada "payroll", que contiene los campos:
Payroll(ID,orden,legajo,nombre,sit_revista)
La pantalla se convierte en:

Esta es una pantalla generadora de cdigo, es decir que ayuda al operador a generar
automticamente el cdigo SQL respectivo.
Todo lo que debemos hacer es poner el nombre de los campos que queramos consultar en la
fila llamada "Campos" y el nombre de la tabla en la segunda fila. En este ejemplo le estamos
21
pidiendo al Access que haga una consulta SQL del cuil, el nombre y la situacin de revista de
la tabla "payroll"
Una vez llena la tabla con los datos nos queda lago similar a:

La tercera fila llamada "Orden" sirve para ordenar el listado resultante cualquiera de los
campos podemos ingresar las palabras "Ascendente" o "Descendente". Por ejemplo, si
ingresramos la palabra "Descendente" en la columna nombre obtendramos como resultado el
listado ordenado inversamente de la Z a la A.
LA cuarta fila "Mostrar" sirve para identificar que campos se quiere ver y cuales no en el
resultado. En el ejemplo se ve que en realidad se pide que solo se visualice el cuit y el nombre
pero no la situacin de revista.
LA ultima fila "Criterios" sirve para establecer un filtro al listado. Vemos entonces que
justamente el campo "situacin de revista" no se muestra pero es utilizado para establecer un
filtro. En este caso el filtro es "Todos los registros que incluyan el texto "92/95".
Haciendo un resumen general, el programa generara la orden SQL que me permita hacer un
listado de los campos cuil y nombre de la tabla payroll, sin orden en especial, pero solamente
aquellos registros que incluyan el texto "92/95" en el campo Sit_revista.
Para activar (ejecutar) esta consulta hay que presionar el icono del signo de admiracin. En la
imagen siguiente el mismo aparece en el men de la parte superior. Es el penltimo icono de
la fila.

22
Una vez ejecutada la consulta obtendremos similar a una hoja "Excel" con dos columnas, cuit
y nombre, con los datos anteriormente descriptos.
___________________________________________________________________________

Introduciendo Cdigo SQL mediante teclado (tipeo manual)

No todos los programas tienen un generador de cdigo como el anteriormente descrito. En
estos casos debemos utilizar la segunda opcin que es la introduccin manual del cdigo SQL.
Si observamos la imagen anterior, veremos que el primer icono, dice simplemente "SQL". El
mismo sirve justamente para cambiar el modo de introducir el cdigo, ya sea con ayuda del
generador como sin el mismo.
Si lo presionamos obtendremos lo siguiente:

He aqu el cdigo SQL que el generador ha creado para nosotros.

#
#
Cuit de Organismo: Consulta de Seleccin
Select payroll.CUITCUIL, payroll.NOMBRE FROM payroll WHERE
(((payroll.SIT_REVISTA) Like *92/95*));

La instruccin de la imagen superior es equivalente a la consulta realizada usando el
generador.

Examinemos los componentes detenidamente:

Una consulta SQL comienza con la instruccin "SELECT", seguida por los nombre de los
campos. Es opcional escribir solamente el campo o ingresarlo en el formato [tabla.campo]
cuando hay una sola tabla. En opciones mas avanzadas, es obligatorio el uso de este segundo
formato.
En otras palabras: Select CUITCUIL, NOMBRE es igual a poner: Select payroll.cuitcuil,
payroll.nombre

A continuacin de los campos, la sintaxis SQL prosigue con la sentencia "FROM" y el
nombre de la tabla.

23
Tenemos entonces hasta aqu que la orden para obtener un listado del cuit y en nombre de la
tabla payroll es:

SELECT Cuitcuil, nombre from payroll

Esta es una orden SQL completa y funciona perfectamente.

Para establecer el filtro, debemos aadir la orden "WHERE" seguida del nombre de un campo
y una condicin.

Para pedirle a la computadora un listado del cuit y nombre de la tabla payroll solamente de
aquellos registros que tengan el texto "92/95" en el campo sit_revista, deberemos ingresar:

SELECT Cuitcuil, nombre from payroll WHERE sit_revista LIKE "*92/95*"

Esta es la orden SQL final, la cual es equivalente a haberla ingresado con el generador de
cdigo.

___________________________________________________________________________

OPERACIONES BASICAS:

CONSULTAS: VARIANTES PARA ESTABLECER CONSULTAS:

Si quisiramos que el listado hubiese estado ordenado por nombre, en orden alfabtico,
deberamos incluir la orden SQL "ORDER BY" y el campo.
La instruccin quedara entonces como:
SELECT Cuitcuil, nombre from payroll WHERE sit_revista LIKE "*92/95*" ORDER BY
nombre

Tambin podramos haber utilizado el operador igual en vez de LIKE. La orden quedara
como:
24

SELECT Cuitcuil, nombre from payroll WHERE sit_revista = "92/95" ORDER BY nombre

Notese que cuando usamos LIKE encerramos el texto entre asteriscos y cuando usamos " = "
no.

La diferencia entre LIKE e = es que LIKE busca todas las ocurrencia en donde el texto se
encuentre en el campo, aunque haya mas texto, mientras que igual solo busca las
concurrencias en donde el texto coincida exactamente.

Ejemplos:

El Texto: 92/95 ser verdadero (ser encontrado) tanto para LIKE como para =

El texto: ABC 92/95 ser encontrado por LIKE pero no por =, ya que este requiere una
coincidencia exacta entre lo buscado y el dato del campo.

El texto: 092/950 ser encontrado por LIKE pero no por =, ya que este requiere una
coincidencia exacta entre lo buscado y el dato del campo.

Si quisiramos filtrar por todos los registros que NO tengan el texto "92/95", podemos usar el
operador "distinto" que se escribe <>

La orden quedara entonces como:

SELECT Cuitcuil, nombre from payroll WHERE sit_revista <> "92/95" ORDER BY nombre

Finalmente, si quisiramos que el orden fuera revertido, es decir que sea de Z a A, deberamos
escribir:

SELECT Cuitcuil, nombre from payroll WHERE sit_revista <> "92/95" ORDER BY nombre
DESC
25

FILTROS POR MAS DE UN CAMPO:

Si quisiramos filtrar por mas de un campo a la vez debemos incluir el operador AND ("Y"
lgico) o el operador OR ("O" lgico).

Ejemplo: Si quisiramos filtrar todos los registros que NO tengan el texto "92/95" y con
nombre igual a "Gomes",la orden quedara como:

SELECT Cuitcuil, nombre from payroll WHERE sit_revista <> "92/95" AND
nombre="GOMES" ORDER BY nombre.

En este caso se deben dar ambas condiciones a la vez. La situacin de revista no debe
contener el texto 92/95 y en nombre debe ser igual a Gmez.

Finalmente, si quisiramos que me diera cualquiera de los dos, es decir todos los que se
llamen Gmez o se llamen Rodrguez, ordenado por nombre, deberamos escribir:

SELECT Cuitcuil, nombre from payroll WHERE nombre="GOMEZ" OR
nombre="RODRIGUEZ" ORDER BY nombre

RELACIONES ENTRE TABLAS:

Dos o mas tablas pueden relacionarse en una base de datos (relacional) siempre que tengan
algn campo en comn.

De esta manera, se puede establecer una consulta que abarque datos de ambas tablas a la vez.

Supongamos que tenemos tres tablas, una con datos de las empresas, otra con la codificacin
de los pases y otra con un listado de los pases en que cada empresa tiene sucursales.

1. Empresas(Cdigo, Nombre, direccin, telfono)

26
2. Pases (Cdigo, Nombre)

3. Sucursales( Cdigo empresa, Cdigo pas)

Si quisiramos tener un listado de: Cdigo de empresa, nombre de la empresa y cdigo de pas
en que tienen sucursales debemos establecer una relacin entre las tablas "Empresas" y
"Sucursales".
La Orden SQL "Inner Join" se encarga de realizar esta operacin.
La sintaxis general es:
SELECT campo,campo2 FROM tabla1 INNER JOIN tabla2 ON campo en comun de tabla 1
= campo en comun de tabla 2;
Nuestro ejemplo nos queda entonces como:
SELECT Empresas.Codigo, Empresas.Nombre, Sucursales.CodigoPais FROM Empresas
INNER JOIN Sucursales ON Empresas.codigo = Sucursales.CodigoEmpresa;
Ntese que solo podemos consultar el cdigo de pas porque el nombre se encuentra en la
tabla "pases".
Si quisiramos tener un listado de: Cdigo de empresa, cdigo de pas y el nombre del pas en
que tienen sucursales debemos establecer una relacin entre las tablas "Pases" y "Sucursales".
Nuestro ejemplo nos queda entonces como:

SELECT Paises.Codigo, Paises.Nombre, Sucursales.CodigoEmpresa FROM Paises INNER
JOIN Sucursales ON Paises.codigo = Sucursales.CodigoPais;
Ntese que solo podemos consultar el cdigo de empresa porque el nombre se encuentra en la
tabla "empresas".
Finalmente podramos querer algo mas complejo: Una relacin entre las tres tablas, para
obtener: Cdigo de empresa, nombre de la empresa, cdigo de pas, nombre del pas.
Debemos establecer una relacin entre las tablas "Empresas", "Pases" y "Sucursales". En este
caso debemos usar dos clusulas INNER JOIN. La primera la encerramos entre parntesis
para mayor claridad.

SELECT Empresas.codigo, Empresas.nombre, Paises.codigo, paises.nombre FROM
(Empresas INNER JOIN Sucursales ON Empresas.codigo = Sucursales.CodigoEmpresa)
INNER JOIN Paises ON Sucursales.CodigoPais = Paises.Codigo;

27

Ntese que no es posible establecer una relacin directa entre Empresas y Pases ya que no
tienen ningn campo en comn. Por ende, se necesita hacer una triangulacin utilizando la
tabla Sucursales como medio de unin entre ambas.

INSERCION DE DATOS EN LOTE (MODO BATCH):
Supongamos que tenemos una tabla de clientes. Sbitamente nos llega en una nueva tabla un
listado de nuevos clientes a los que hay que anexar a nuestra tabla.
Tendremos entonces:

a) Clientes(Codigo, Nombre, direccion, telefono)

b) NuevosClientes(Codigo, Nombre, direccion, telefono)

Nuestra Orden SQL para esta tarea es :

INSERT INTO Tabla (campo de la tabla en la que se inserta) SELECT (campo a insertar)
FROM Tabla2 (la tabla desde la cual se inserta)

Nos quedaria:

INSERT INTO Clientes (Codigo, nombre, direccion,telefono) SELECT
NuevosClientes.Codigo, NuevosClientes.nombre,NuevosCLientes.direccion,
NuevosCLientes.telefono FROM NuevosCLientes

BORRAR DATOS EN LOTE (MODO BATCH):

Volviendo a nuestro ejemplo anterior:

a) Empresas(Codigo, Nombre, direccion, telefono)

b) Paises (Codigo, Nombre)
28

c) Sucursales( CodigoEmpresa, CodigoPais)

Si quisieramos borrar todas las empresas que pertenezcan al pais codigo "XX" debemos usar
la orden SQL "DELETE". Recordemos que el uso del asterisco * implica todos los campos de
una operacion SQL. Si utilizamos el asterisco aqui estamos significando que queremos borrar
todos los campos de la tabla

La sintaxis es la siguiente:

DELETE Tabla.* FROM Tabla INNER JOIN Tabla2 ON (campo en comun1) = (campo en
comun 2) WHERE campo="valor";

Para nuestro ejemplo:

DELETE Empresas.* FROM Empresas INNER JOIN Sucursales ON Empresas.Codigo =
Sucursales.CodigoEmpresa WHERE Sucursales.CodigoPais="XX";

Este ejemplo borra solo los registros de la tabla empresas, pero no los de la tabla sucursales.
Si quisieramos borrar al mismo tiempo los registros relacionados de ambas tablas, estariamos
en el caso de un borrado en cascada (llamado tambien borrado con respeto a la integridad
referencial)

La orden seria entonces:

DELETE Empresas.*, Sucursales.* FROM Empresas INNER JOIN Sucursales ON
Empresas.Codigo = Sucursales.CodigoEmpresa WHERE Sucursales.CodigoPais="XX";

ACTUALIZAR DATOS EN LOTE (MODO BATCH):

Volviendo a nuestro ejemplo de clientes, supongamos ahora que tenemos nuestra tabla de
clientes y nos mandan una nueva tabla con las direcciones modificadas. Lo que se pretende es
modificar (actualizar) las direcciones de los clientes que se encuentram en la tabla nuevas
direcciones:
29

a) Clientes(Codigo, Nombre, direccion, telefono)

b) NuevasdireccionesClientes(Codigo, direccion)

Nuestra Orden SQL para esta tarea es :

UPDATE tabla INNER JOIN tabla2 ON (campo en comun 1) = (campo en comun 2) SET
(campo a actualizar) = (campo con los datos nuevos);

Para nuestro ejemplo:

UPDATE clientes INNER JOIN NuevasdireccionesClientes ON clientes.codigo =
NuevasdireccionesClientes.direccion SET clientes.direccion =
NuevasdireccionesClientes.direccion;

(*) Todas las marcas que aparecen en este trabajo ej:Microsoft, Excell, Access, Visual Basic,
etc. son marcas registradas de sus respectivas empresas.
30

Diagramacin Lgica

Por Prof. Lucila Mortara

Sabemos que el computador es incapaz de procesar nada por s solo; es una necesidad
indicarle en forma completa, precisa y secuencial la totalidad de lo que debe hacer. Es por
esto que cuando se desea hacer uso de un computador se debe planificar detalladamente lo
que se pretende que sea procesado. El trazado de un Diagrama de Lgica facilitar captar
el problema en una simple observacin y la definicin del procedimiento para el computador.

Un Diagrama de Lgica es un diagrama de flujo detallado que representa el comienzo y el fin del
tratamiento de un proceso, las operaciones, las decisiones y la secuencia especfi ca en que ests se
deben cumplir. Todos los procesos pueden reducirse a unas pocas funciones bsicas (mover datos,
realizar operaciones aritmticas bsicas, realizar operaciones de lectura y salida, realizar
comparaciones) que son las que se representarn en el diagrama.

Para realizar el proceso puede resultar necesario almacenar datos temporariamente en la memoria
de la mquina. Para representar la informacin contenida en la memoria se utilizan variables, que son
espacios de la memoria a los que se les da un nombre para poder trabajar ms facilmente, sin referirse
a las posiciones numricas de la memoria. Las variables pueden contener cualquier tipo de datos:
letras, nmeros, caracteres. Dentro de las variables numricas existen dos tipos particulares d e
variables: los acumuladores y los contadores.

Los acumuladores permiten almacenar una serie de datos que se incrementan en forma
variable. Por ejemplo, si se quiere calcular un promedio de una serie de valores, se
debern sumar todas las cantidades. Esta suma es variable, ya que no se incrementa
uniformemente por cada registro analizado. En cambio a la cantidad de registros utilizada
como divisor para el clculo del promedio siempre se le adiciona un valor fijo (1), por lo
que la variable utilizada para almacenar este dato se denomina contador.

acumulador + valor acumulador
contador + 1 contador

Para facilitar el armado del diagrama se recomienda utilizar nombres de variables cortos y que
permitan identificar claramente lo que van a contener.

SIMBOLOGA
Smbolo Concepto representado Ejemplos
Comienzo o fin del procedimiento detallado
en el diagrama

Ingreso de datos o salida de informacin

Implica un proceso que realiza el
computador, como una operacin aritmtica
bsica o una transferencia (carga de valor a
una variable)

Implica una comparacin lgica, que ser
siempre dicotmica (SI o NO; = o < ; = o > ;
= o ? )

COMIENZO FIN
LEER
TARJETA
IMPRIMIR
SALDO
0 SUMA
0 CONTADOR
SUMA PROMEDIO
CONTADOR
COD : 1
=
?
31

Determina la secuencia de las operaciones

Se usa al solo efecto de la diagramacin,
permitiendo conectar el diagrama cuando se
usa ms de una hoja

Cuando se requiere especificar con mayor detalle el soporte de datos se utilizan smbolos especiales
para cada uno, entre los que se encuentran los detallados en la tabla siguiente.
SMBOLOS ESPECIALES DE INGRESO Y SALIDA DE DATOS

Implica una salida por medio de un
formulario impreso

Implica una operacin de lectura o grabacin
en una tarjeta perforada

Implica una lectura o grabacin en una cinta
magntica

Implica una lectura o grabacin en discos
magnticos, tambores magnticos, tarjetas
magnticas

Para asegurar la comprensin del di agrama se complementa con un diagrama de sistema, la
definicin de la estructura de registro y la especificacin de la condicin de fin del proceso.

Diagrama de sistema: es un diagrama que representa el proceso en un nivel menos detallado que
el diagrama de lgica. Dentro del mismo se incluye solamente la especificacin de la/s entrada/s al
proceso y de la salida o salidas del mismo con sus correspondientes formatos.

Ejemplo: si se cuenta con un proceso que lee un archivo de existencias de productos de una cinta
magntica, calcula la suma de las existencias totales y la guarda en un archivo e imprime un reporte
con ese dato, el diagrama de sistema sera el expuesto a continuacin.

Estructura de registro del soporte de datos: Especificacin de los campos en que se dividen los
registros que estn almacenados en el soporte de datos de entrada, y de los datos que contienen. Los
nombres expuestos en la estructura de registro sern los que se utilizarn en el diagrama de lgica para
referirse a la informacin contenida en los mismos dentro de cada soporte de entrada y posteriormente
a la operacin de lectura del mismo, por lo que se recomienda utilizar nombres cortos y aclarar en
detalle en la definicin de la estructura de registro los datos que contienen.
A + B C
IMPRIMIR
C
LEER
CINTA
GUARDAR
SALDO
LEER
TARJET
IMPRIMIR
SALDO
LEER
CINTA
GUARDAR
SUMA
IMPRIMIR
SUMA
PROCESO
32

Ejemplo: el registro de la cinta magntica dentro del ejemplo anterior debera contener al menos los
siguientes campos:
ESTRUCTURA DE REGISTRO
CODPROD: codigo del producto
CANTEX: cantidad de unidades del producto en existencia

Condicin de fin del proceso: Especificacin de la condicin que en el caso de cumplirse determinar
el final del proceso en cuestin.

Ejemplo: en el ejemplo de la suma de existencias, la cinta magntica podra tener almacenado un
codigo de producto 0 en el ultimo registro almacenado.

CONDICION DE FIN: CODPROD = 0
Operaciones realizables

Tipo de
operacin
Sintaxis
Funcin

Ejemplo
LEER
soporte_de_datos
Lee el soporte de datos
especificado
LEER tarjeta
IMPRIMIR variable
Imprime el contenido de las
variables especificadas
IMPRIMIR
promedio
Entrada
y
salida
GUARDAR variable
Guarda en el soporte de datos el
contenido de las variables
especificadas
GUARDAR saldo
Transferencia valor variable
Asigna valor a la variable
especificada
0 suma
Aritmticas + - * /
Suma, resta, multiplicacin,
divisin
suma + valor
suma
variable/campo :
valor
Compara el contenido del campo o
la variable contra el valor
especificado
suma : 0
Comparaciones
ES BLANCO / ES
FIN
Analiza si el registro est en blanco
o se lleg al fin del archivo
ES FIN?

Ejemplo completo: Imprimir el promedio de edades de alumnos contenidas en una tarjeta magntica.
La ultima tarjeta tiene un cero en la edad.

Estructura de registro

EDAD: contiene la edad del alumno

Condicin de fin: EDAD = 0

Diagrama de sistema

LEER
TARJETA
PROCESO
IMPRIMIR
PROMEDIO
33

INICIO
0 suma
0 cant
0
promedio
LEER
TARJETA
EDAD : 0
suma/cant
promedio
FIN
IMPRIMIR
PROMEDIO
suma + EDAD suma

cant + 1 cant
DIAGRAMA DE LGICA
34

Ejercicios Prcticos:

35
Caso: Muy fcil, Sociedad de Hecho

Luego de ser despedidos de la fabrica ms grande de caramelos del pas, debido a la recesin
imperante, los ex empleados Juan Gmez y Jos Garca se asocian y ponen un quiosquito de
venta de cigarrillos para subsistir llamado Muy fcil.
Jos tiene una computadora laptop que compr en pocas mejores y plantea el poder usarla
para administrar el quiosco.
Ellos compran cigarrillos y golosinas a los proveedores, as que se les ocurre hacer un listado
de proveedores con sus nombres, direcciones, telfono, y los artculos que le compran a cada
uno. Juan asume la responsabilidad administrativa as que se encarga de cargar todos los
datos.
Tambin quieren tener una lista de precios de cada proveedor por artculo , y la lista de venta
al publico, as como saber el inventario que tienen de cada cosa. Jos asume la
responsabilidad comercial quiere poder consultar las listas de proveedores, la lista de precios
del quiosco y las direcciones de los proveedores.

Se pide: a) Identificar los campos pertinentes b) crear el archivo plano c) normalizar
36

Caso Pottery Dolls .com

La empresa Pottery Dolls se dedica a la comercializacin de muecas antiguas de cermica y porcelana
y marfil, especialmente muecas chinas antiguas, y occidentales del siglo XIX y de las primeras dcadas del siglo
XX.
Sus clientes son en su mayora c oleccionistas, museos, instituciones y aficionados que abonan
generosamente por la posesin de una antigedad de este tipo. Hay coleccionistas que compra -venden piezas
(es decir que tanto compran como venden).
Los museos solamente compran, pero no venden. ltimamente la empresa ha decidido instalar un sitio
WEB, llamado www.Pottery Dolls.com con objeto de tener un STORE ON -LINE (punto de venta en lnea).
Tambin desean facilitar su operatoria comercial con clientes y proveedores de esta manera.

La empresa posee un inventario de artculos, en el que tienen cargado: Cdigo de Artculo, Descripcin,
Ao aproximado de confeccin, cdigo de pas de procedencia, nombre del pas de procedencia, material de
confeccin (cermica, porcelana, marfil, etc.), precio u nitario de venta.

Tambin posee varias fotos digitalizadas de cada pieza, las cuales se piensa publicar en la pagina.

Al ser artculos de coleccin, se van llevando registros de bitcoras (logs) de los nombres de los
coleccionistas (los dueos) anteriore s de los objetos, y las fechas de las sucesivas ventas a fin de tener
catalogada la historia de cada pieza, lo cual contribuye a los fines de verificar la antigedad y legitimidad de las
mismas. (La lista transparente de anteriores dueos garantiza que las piezas no han sido robadas, por ejemplo)

La empresa desea que estos datos puedan ser visibles en la pagina de INTERNET para que los
visitantes puedan consultar las existencias y los precios de venta. El responsable de introducir los datos es el
empleado administrativo del Ente.

Por otro lado, la empresa recibe constantemente ofertas de compra y de venta de piezas por parte de
coleccionistas de todo el mundo. Solamente se compran los artculos que se consideran "gangas", es decir, cuyo
precio de venta es bajo.

Finalmente, la empresa desea instalar un formulario en la pagina, en donde los clientes que deseen
comprar algn artculo del inventario on -line puedan dejen sus datos personales y los de la pieza, a los fines de
poder mandarles la misma por deliv ery (entrega a domicilio).
Para ello, los datos del formulario se incorporaran en una tabla que contendr: Nombre del comprador,
domicilio, localidad, pas, cdigo postal, telfono, e -mail, cdigo de pieza por la que esta interesado. (OJO: un
comprador puede estar interesado en mas de una pieza).

Se pide: a) Identificar los campos pertinentes b) crear el archivo plano c) normalizar

37

Caso Expedientes Digitales

El estudio jurdico XX ha implantado un sistema computarizado para la ejecucin de las tar eas.
Se pretend que los profesionales puedan resolver los casos utilizando la computadora, sin necesidad de
estar continuamente moviendo papeles.
Los clientes acuden al estudio planteando sus casos. El estudio les toma los datos y e empleado
administrat ivo los anexa a una tabla de clientes donde consta el nombre, la direccin, el telfono, el mail y la
causa que plantea. Tambin carga los datos del expediente.

Cada nuevo caso genera un expediente, el cual se pretende que se maneje en forma computadoriz ada.
Cada expediente consta de varias notas. Un cliente puede tener varios casos en proceso, por lo que puede haber
varios expedientes de un mismo cliente

Ejemplo de Expediente:

Nro..
Expediente
Causa Cliente Direccion Nro..
nota
Abogado Expte
Iniciado
el
1100-000-1101 Gomez vs
Fernandez
Pepe Gomez rivadavia 1234 1100/1 Ramirez 11/2/99
1100-000-1101 Gomez vs
Fernandez
1100-000-1101 Gomez vs
Fernandez
1100-000-1101 Gomez vs
Fernandez

2200-200-2201 Gimenez vs
Hernandez
Juan Gimenez honduras 2345 2200/1 Bermudez 12/3/99
2200-200-2201 Gimenez vs
Hernandez
2200-200-2201 Gimenez vs
Hernandez
2200-200-2201 Gimenez vs
Hernandez

A su vez las causas (cada causa es un expediente) se le asignan a un abogado particular. Un abogado
puede tener mas de una causa. La secretaria tiene un registro de sus abogados, en donde consta su nombre,
direccion, telfono y mail.

Las notas se acumulan en una tabla.
Ejemplo de la tabla de notas :

Numero de
Nota
Descripcion Texto Expediente Fecha de
la nota
Observaciones
1100/1 Actuacin
Inicial
Aqu va el texto
de la nota
1100-000-1101 14/3/99 no hay
1100/2 Pericia
psicolgica de
Gmez
Aqu va el texto
de la nota
1100-000-1101 15/3/99 se necesita otra
opinin
1100/3 Prueba
testimonial
Aqui va el texto
de la nota
1100-000-1101 14/4/99 Hay audiencia el
martes

Las causas pueden cambiar de profesional a cargo, lo que se denomina "pases". Una causa puede
pasarse a uno o varios profesionales, pero solo la tiene en su poder uno p or vez. El primer pase es el abogado
original a cargo. Los pases los realiza el jefe administrativo.

Ejemplo de pases:

Nro..
Expediente
Causa Cliente Fecha del Pase Pasado al
Abogado
1100-000-1101 Gomez vs
Fernandez
Pepe Gomez 11/3/99 Ramirez
1100-000-1101 Gomez vs
Fernandez
Pepe Gomez 20/5/99 Hernandez
38
1100-000-1101 Gomez vs
Fernandez
Pepe Gomez 18/7/99 Ramirez
1100-000-1101 Gomez vs
Fernandez
Pepe Gomez 21/8/99 Bermudez

Cualquier empleado del estudio puede consultar el estado de los clientes, las causas, los expedientes o
los pases. (Nota: Tratar esta consulta como si fuera una sola consulta unificada)

Se pide:

Identificar los campos y exponer las tablas normalizadas

39

Caso Salsipuedes

Analice el siguiente Remito y lleve a cabo los pasos necesarios para obtener la Base de Datos
en 3ra. forma normal.

X

SALSI PUEDES S.A. REMITO N 65875

Av. De los Corrales 1354 Fecha: 19/06/02
(5687) Cap. Fed. CUIT: 30-25489433-8
Ing. Brutos: 101-456896-4

Sres: Marcelo Scoccia Nro de Cuenta: 54698
Av. San Juan 1235
Villa Tecnologa

Gua de Transporte N: 456
Empresa de Transporte: 33 - Transportes La Academia
Chofer: 96 - Hugo Toss
Zona de Entrega: 78 - Avellaneda

Artculo Descripcin Cantidad Precio [$] Volumen [m
3
]
4856 Camisetas de Ftbol 11500 65 450
3685 Banderas Albicelestes 4000 8 200
5698 Pelotas de Ftbol Nro. 5 1500 18 80

TOTALES 806500 730

Capacidad mxima del Transporte: 3000 m
3
100 %
Capacidad Ocupada: 730 m
3
24.33 %
Capacidad Ociosa: 2270 m
3
75.67 %

Recargo por capacidad ociosa
De 0 a 25 % $150 De 51 a 75 % $250
De 26 a 50 % $200 De 76 a 100 % $300
Imprenta: "El Cilindro" CUIT: 30-23546871-2 Fecha de impresin: 4/3/98

40
Caso: Nota de pedido

N
pedido
Fecha
pedido
Cod
Proveedor
Nombre
Proveedor
Domicilio
Proveedor
Cod
artculo
Descripcin
artculo
Cant Precio
Unitario
Precio
Total
15 20/10/02 150 Molino PP La Habana 540 3 Harina de Trigo
0
10 0.75 7.50
000
150 0.85 127.50
00
50 0.80 40.00
16 21/10/02 16 Molino JCJ Arcos 3654 5 Harina de Trigo
000
200 0.65 130

Normalice esta estructura de Base de Datos de forma tal que cumpla con las condiciones de
Tercera Forma Normal

Caso: Catlogo de prstamos de Biblioteca

Una ficha del catlogo de prstamos de una biblioteca registra los siguientes datos

Codigo de libro: Cdigo unico que identifica a cada libro
Numero de ejemplar: Nmero que identifica el ejemplar en los casos en que haya
ms de uno por libro, dato que se debe almacenar.
Ttulo: Ttulo del libro
Autor: Autor del libro
Tema: Tema general dado al libro para su categorizacin, en base a una lista ya
armada
Ao: ao de la primera edicin del libro
Codigo de socio: codigo que identifica a cada socio
Nombre Socio: nombre y apellido del socio
Fecha prstamo: fecha en la que el ejemplar fue prestado
Fecha devolucin: fecha en la que el ejemplar fue devuelto

A los efectos de informatizar esta registracin, se le solicita el armado de una estructura de
Base de Datos en Tercera Forma Normal que le permita optimizar al mximo el
almacenamiento, reduciendo la redundancia.

*Un socio no puede retirar ms de un ejemplar del mismo libro en el mismo da.

Caso: Movimientos de un videoclub

num
mov
Fecha tipo
operacion
cod tipo
producto
Tipo
producto
cod_prod Ttulo Gnero cdigo
socio
nombre socio
1 03/01/02 A V Video 100 El Rey Len Infantil 10 Juan Perez
2 05/01/02 D D DVD 895 Shreck Infantil 15 Cristina
3 05/01/02 D V Video 100 El Rey Len Infantil 10 Juan Perez
4 06/01/02 D V Video 150 Martes 13 Terror 10 Juan Perez

Disee la estructura de datos en tercera forma normal que sirva como base para la
automatizacin de los movimientos (A: alquiler, D: devolucin) del videoclub, teniendo en
cuenta que se debe almacenar el director y el ao de cada pelcula y el domicilio y uno o ms
telfonos de cada socio.

41
Caso: Cotizacin de una ferretera

Analice el siguiente formulario de Cotizacin y lleve a cabo los pasos necesarios para obtener la Base
de Datos en 3ra Forma Normal, teniendo en cuenta los siguientes datos:

- Los datos referidos a cada cotizacin enviada a un cliente debern ser guardados en la Base
de Datos con la mayor eficiencia posible y de modo que permitan realizar bsquedas por
cliente, fecha, forma de pago, localidad, y plazo de entrega.

- Las formas de pago posibles son:
1 Efectivo 2 Cheque 3 Tarjeta 4 Cuenta Corriente 5 Otros
medios de pago

- Cada cotizacin podr ser pagada mediante UNA de estas formas de pago, y llegar al
cliente por UN solo medio.

- Los plazos de entrega son: 7 das, 10 das, 15 das o 30 das.

- Los plazos de validez de las ofertas se miden en cantidad de semanas a partir de la fecha de
cotizacin.

- Los precios de los productos se asumen fijos en el tiempo, teniendo cada producto asociado
un porcentaje de descuento que se aplica solo a los clientes de tipo 1.

FECHA COTIZACION: 25/10/2002 COTIZACION N: 45687
EMPRESA: Ferretera RA TIPO CLIENTE: 1- Grande
DIRECCION: Av. Pueyrredon 1000 LOCALIDAD: Capital Federal
C.P.: 1650
NUMERO/S FAX: 4312-1515

COD CANT DESCRIPCION PRECIO UNIT ($) DESCUENTO (%) TOTAL ($)
1234 2000 Clavos Fischer 0.10 15 170.00
4321 5 Soldadoras 45.00 2 220.50

TOTAL: 390.50

Estos Precios no incluyen IVA
Forma de Pago: 1 Efectivo
Plazo de Entrega: 10 das
Validez de la oferta: 2 semanas

Esta cotizacin llegar al cliente por medio de:
1 - Cadete 2 -
Vendedor
X 3 -
Correo
4 -
Retira
5-
Fax

42

Caso: Informe de Servicio Tcnico

Analice el siguiente formulario de Cotizacin y lleve a cabo los pasos necesarios para obtener la Base de Datos
en 3ra Forma Normal

HIGH TECH
Consulting S.R.L.

INFORME DE SERVICIO TECNICO AL CLIENTE N: 0015534
Av. Carabobo 1327 -
Cap. Fed. (A2871GXY)
Tel/Fax. 4905-6418/5220
N CLIENTE: 128 FECHA VISITA TECNICA : 18/02/2003
NOMBRE: Autoservicio El trbol de Parque Patricios
DOMICILIO: Rondeau 931 T.E.: 4328-1715 / 2054
LOCALIDAD: Cap. Fed. C.P.: C6358AMX

TIPO CLIENTE: ___ Abonado con repuestos
_X_ Abonado sin repuestos
___ No abonado

SOLICITANTE: Ricardo Nogueira. SECTOR: Administracin
TAREAS SOLICITADAS: Reparacin de Equipo Terminal. Chequeo integral de la red.
TCNICO: Fernando Uriarte.

HORA: LLEGADA: ___:_____
SALIDA: ___:_____
TAREAS REALIZADAS:

REPUESTOS UTILIZADOS:
CONFORME CLIENTE: ___________________ COD. REP. DESCRIPCIN CANTIDAD
ACLARACIN: ___________________
FIRMA TCNICO: ___________________

Todo el software utilizado en el presente servicio fue proporcionado por el cliente, salvo
aclaracin en contrario.
En caso de quejas o dudas con el servicio efectuado, comunicarse con el departamento de
atencin al cliente.

HT
43

Caso: Orden de Pago

Analice el siguiente formulario y lleve a cabo los pasos necesarios para obtener la Base de Datos en 3ra Forma
Normal

ORDEN DE PAGO N: 00973

FECHA : 23-02-03
Cuenta N : 127
Proveedor : IMPRENTA RAWSON de Svori Hnos.
Alberdi 2868 Cap. Fed.
LIBER
PLAST
S.R.L.
4327-5172/5173/5114

Detalle de imputaciones :
Comprobante
Tipo Nmero
Fecha Vencimiento Importe
A 0002-00000483 12-12-02 12-01-03 $1771,13

Subtotal Imputaciones : $1771,13

Valores :
Tipo
valor
Nmero
interno
Nmero valor Banco Cuenta Fecha Importe
TERCEROS 139 09944751 GALICIA 122789-
029/1
15/03/03 $500
DIFERIDO 259 1180324129 BANKBOSTON 0971-
281315
25/02/03 $1271,13

Subtotal Valores : $1771,13

Total Orden de Pago : $1771,13

44
Caso: Presupuesto

Analice el siguiente formulario de Presupuesto y lleve a cabo los pasos necesarios para obtener la
Base de Datos en 3ra Forma Normal, teniendo en cuenta las siguientes aclaraciones:

- Las formas de pago posibles son: 1 - Efectivo 2- Cheque 3-Tarjeta 4-Cta. Cte. 5- Otros medios
- Cada cotizacin podr ser pagada mediante UNA de estas formas de pago, y llegar al cliente por
UN solo medio.
- Los precios de los productos se asumen fijos en el tiempo y cada cliente tiene asociado un
porcentaje de descuento.

DISTRIBUIDORA EL CRISOL S.A.
Ruta 8 Km 22,5 CUIT: 30 -2879166-7
Pilar (A2871GXY) INGRESOS BRUTOS: 91523421 -8
Tel/Fax. 02322 -490564 INICIO DE ACTIVIDADES: 05/08/1997

X

DOCUMENTO NO VALIDO COMO FACTURA
FECHA : 22/04/2003 PRESUPUESTO N: 45687
CLIENTE: Ferretera El triunfo COD. CLIENTE: 355
DOMICILIO: Av. Santa F 2327 TIPO CLIENTE: 1- Mayorista
LOCALIDAD: Cap. Fed. C.P.: C6358AMX
TELEFONO(S) : 4328-1715 / 2054

COD. ART. CANT UNID. DESCRIPCION PRECIO UNIT ($) DESCUENTO TOTAL ($)
12348 3000 Tuercas 0.10 10 % 270.00
74321 5 Taladros 45.00 10 % 202.50

TOTAL: 472.50
Estos Precios no incluyen IVA
Plazo de Entrega : 10 das
Forma de Pago : 1- Efectivo
Esta cotizacin llegar al cliente por medio de:
1
Cadete
2 Ej.
d e Cta.
X
3
Correo
4
E-mail
5
Fax

Este presupuesto tiene una vigencia de 30 das a partir de su fecha de emisin. Transcurrido
este plazo los precios y las condiciones de pago pueden sufrir modificaciones.

45
Caso tema : Proyectos: Construccin de un sitio we b

La empresa XX ha contratado sus servicios para implementar un sitio web con informacin
institucional de la empresa, y adems permita consultar un catlogo en lnea. Como lder del
proyecto, usted debe administrar el tiempo, el costo y los recursos, sabiendo que debe llevar a
cabo las tareas que se detallan a continuacin, y la duracin de las mismas.

A su vez usted cuenta con los siguientes recursos:

N
Recurso
Descripcin Capacidad de
Trabajo
1 Analista 8 hs. diarias
2 Programador Diseador Grfico 8 hs. diarias
3 Data entry 8 hs. diarias
4 Lder de Proyecto 8 hs. diarias
5 PC (del programador) Total
6 PC (del data entry) Total

Se pide:

1. Crear un diagrama de Gantt
2. Crear un diagrama Pert.
N Tarea Duracin (das) Antecesor
1 Comienzo del proyecto 0 -
2 Relevamiento de la informacin 2 1
3 Anlisis 2 2
4 Diseo conceptual del sitio 4 3
5 Diseo detallado 5 4
6 Programacin del mdulo institucional 7 5
7 Contratacin del servicio de hosting 3 1
8 Registracin del dominio 2 7
9 Pruebas 1 8
10 Implementacin del sitio 2 7 - 8 - 9
11 Fin del proyecto - 1 9
46

Caso: Ejercicios SQL

1. Dadas las siguientes tablas, sacadas del ejercicio de Medicina Laboral, explicado en este apunte:

1. Empleados x Empresa(Codigo de Empresa, Legajo, Nombre)

2. Medicina Laboral(Nro de formulario, Codigo de Empresa, Fecha, Legajo, Atendidoen,

3. Empresas Clientes( Codigo de Empresa, Nombre de Empresa)

Establecer las ordenes SQL para:

*Hacer una consulta de todas las empresas clientes, ordenado por cdigo de empresa
*Hacer un listado de todos los empleados de la empresa pitufo SA que recibieron nuestros servicios
*De que empleado hace mencin el formulario 341?
*Que dia fue citado el empleado Jun Gomez, legajo 222 de la empresa papapitufo SRL?
*En donde se atendieron los empleados de la empresa gargamel SA?

47

Caso: Mas Ejercicios SQL

1. Dadas las siguientes tablas, sacadas del eje rcicio de Drawings Consulting explicado en este apunte,
establezca las siguientes instrucciones SQL:

1) Clientes( cdigo, nombre, direccin, telfono, e -mail, cdigo localidad)
2) Personal ( numero de legajo, nombre y apellido, fecha de nacimiento, TE, cd igo categora laboral. )
3) Categoras Laborales( cdigo, nombre, facturacin por hora )
4) Localidades(Cdigo, nombre)
5) Presupuestos1( numero de presupuesto, Cdigo de cliente, cdigo de tarea, fecha de inicio
presupuestada)
6) Presupuestos2 (numero de presupuesto, leg ajo, horas programadas, desde fecha, hasta fecha)

*Hacer una consulta de todos los clientes , ordenado alfabticamente
*Listado de personal, ordenado por numero de legajo
*Cuanto factura por hora la categora junior?
*Cuando se inicia el presupuesto 2 00?
*Listado de los presupuestos del cliente Gomez, Jorge

48

Diagramacin Lgica:

Caso Publicaciones

Una empresa dedicada a la comercializacin de publicaciones desea conocer cual fue la participacin
en los volmenes de ventas de las lneas textos y revistas, as como las zonas en las que se realizaron
las ventas.

Para ello se ingresan los comprobantes de ventas, que presentan, entre otros, los siguientes conceptos:

Importe
Zona (1 - bonaerense / 2 - resto del pas)
Lnea (t =texto r = revista)

El listado deber presentar la siguiente informacin:

Monto total de ventas zona bonaerense: 999999999
Monto total de ventas resto del pas: 99999999
% de participacin textos: 99
% de participacin revistas: 99

Se pide: confeccionar el diagrama de lg ica que contemple la salida detallada precedentemente, y que verifique
que el ingreso de la zona de venta y de la lnea sean correctos.

Caso : Medicina Prepaga

En una empresa de Medicina Prepaga, cada afiliado que concurre al servicio tiene una T arjeta
Magntica, con los siguientes datos:

Nmero de Afiliado
Plan de Asistencia Medica, con los cdigos A y C
Apellido y Nombre
Grupo Familiar
Sexo: con los cdigos M y V
Ao de ingreso o afiliacin: fecha de alta
Ultimo mes pago.
Fecha de Nacimiento.

Para ser atendido necesita estar al da con los pagos. En Recepcin existe una PC en Red con un
lectograbador de Tarjetas Magnticas. Se solicita la siguiente informacin, por el proceso diario.

A)
Cantidad de Afiliados que concurrieron para atencin medi ca
Cantidad de Afiliados rechazados por mora
Cantidad de Afiliados atendidos por tipo de PLAN, sea A o C
Cantidad de afiliados atendidos, Menores de 21 aos, y Mayores
Cantidad de Mujeres Atendidas
B)
49
Cantidad de Afiliados que concurrieron para atencin medica
Cantidad de Afiliados rechazados por mora
Cantidad de Afiliados atendidos con altas anteriores al 2000, y posteriores
Cantidad de afiliados menores de 21 aos que sean mujeres

Se pide: realizar separadamente, los diagramas de lgica que permitan obtener la informacin
solicitada en cada caso, y el correspondiente diagrama de sistemas.

Caso: Comercializacin de botas

En CLEO un local dedicado a la venta de botas, diariamente se requiere obtener entre otros los siguientes
informes:

Monto total de ventas.
Cantidad total de botas bajas vendidas en efectivo.
Cantidad total de botas bajas vendidas con tarjeta de crdito.
Cantidad total de botas bajas vendidas.
Porcentaje que representa el monto total facturado a extranjeros sobre el monto total facturado.

Las transacciones del da se registran en un archivo que almacena entre otros los siguientes datos:

N de factura.
Cdigo medio de pago. (E: efectivo, T: tarjeta de crdito).
Cdigo nacionalidad del cliente (1: argentino, 2: extranjero).
Cdigo de tipo de producto (B: botas bajas, A: botas altas).
Precio unitario del producto.
Cantidad de producto.

Supuestos:

Cada venta posee un solo tipo de producto.
Cada venta es abonada con un solo medio de pago.

Condicin de fin:

Fin de archivo.

Realice:

1. Estructura de registro.
2. Diagrama de lgica.

Caso:: Recaudacin de impuestos

El Ente Recaudador de Impuestos desea implementar un sistema que realice una verificacin mensual
de aquellos contribuyentes que presentaron sus declaraciones juradas f uera de trmino, y que imprima
50
automticamente el reclamo correspondiente que ser enviado por correo a dichos contribuyentes. Para
ello ha contratado sus servicios profesionales para disear el nuevo programa.
El programa deber controlar un archivo, que almacena, entre otros, los siguientes datos:

Nmero de cuit del contribuyente.
Fecha de vencimiento de la presentacin de la declaracin jurada.
Fecha de presentacin de la declaracin jurada.

Si la declaracin jurada est presentada despus del vencimiento indicado, se deber imprimir
automticamente una intimacin al contribuyente.

A su vez, deber imprimir un informe que contenga:

la cantidad de reclamos realizados.
el porcentaje de contribuyentes que recibieron reclamos.
el monto de las multas que el Ente Recaudador est en condiciones de cobrar, si a cada cliente
que recibe un reclamo se le cobran $100.

Se pide:

1. Indicar la estructura del registro que el programa debe procesar.
2. Seleccionar una condicin de fin.

Realizar el diagrama de lgica que satisfaga el requerimiento detallado.

Caso: Casa de comidas rpidas

En Mc Burger, un local de comidas rpidas, luego de las transacciones diarias, se requiere un
informe impreso que contenga:

a) El monto total facturado.
b) La cantidad de unidades vendidas del men N1
c) El porcentaje sobre el monto total facturado, que representa el monto de ventas del men N2.
d) La cantidad de facturas pagadas en efectivo.
e) El promedio de ventas efectuadas con vales de almuerzo.

y adems, un archivo en el que se guarden los registros errneos. Se consideran errneos aquellos
registros donde el importe facturado es negativo o mayor a $999. -. El resto de los campos ya ha sido
validado en un proceso anterior.

Del archivo de facturacin diario se conoce:

a) N de Ticket
b) Cdigo de medio de pago: (E - Efectivo / V - Vales de almuerzo / D Tarjeta de dbito)
c) Cdigo de Productos: (M1- Men 1 / M2- Men 2)
d) Importe facturado

Supuestos:
En cada factura se vende un solo tipo de men, una sola unidad del mismo y es ab onada con
un solo medio de pago.

51

Realice:
1. Estructura de registro, indicando condicin de fin.
3. Tabla de pruebas.

Caso: Almacenes

En una empresa comercial, el sistema de manejo de inventario de sus dos almacenes, realiza
una verificacin sobre el archivo de actualizaciones diarias, para informar si en este se
encuentran errores.

El archivo de actualizacin diaria contiene los siguientes datos:

Cdigo de artculo
Cdigo de movimiento: E si es una entrada (casos de compra s, devoluciones de clientes,
etc.) o S si son salidas.
Cantidad de artculos involucrados en el movimiento.
Nmero que identifica al almacn de origen o destino (1 o 2 segn corresponda)

El final del archivo de actualizaciones se indica con un 0 en el nmero de almacn.

Durante el proceso de verificacin se debe generar un archivo magntico de errores con los
movimientos en los que la cantidad sea invlida (es decir, que sea una cantidad negativa). El resto de
los datos se verificaron y corrigieron en un proceso anterior.

Al finalizar el proceso se debe generar un listado impreso que contenga los siguientes datos:

cantidad de movimientos con errores,
cantidad de artculos entrados al almacn 1
promedio del total de salidas desde los dos almacenes.

Se solicita:

1) Definir la estructura de registro del archivo de actualizaciones diarias, y la condicin de fin del
proceso
2) Realizar el diagrama de sistema del proceso de verificacin
3) Realizar el diagrama de lgica del proceso de verificacin
4)

Caso: Video Club

Una cadena de video clubs dedicada a la venta y alquiler de pelculas en video y DVD, desea que cada
gerente de sucursal obtenga al final de cada da, un listado impreso con la siguiente informacin sobre
la operatoria diaria de su local:

Cantidad de facturas emitidas
Monto total facturado.(pelculas en video y DVD vendidas y alquiladas)
Cantidad de pelculas en video alquiladas.
Cantidad de pelculas en DVD alquiladas.
52
Monto total en pesos de las pelculas en DVD vendidas.
Porcentaje sobre el monto total de facturado que representan las ventas de DVD.

Partiendo de los datos almacenados en el archivo de facturacin del da, que contiene entre otros, los
siguientes:

Nmero de factura

Cdigo de tipo de producto: 1. VIDEO
2. DVD
Cdigo de tipo de operacin: A. ALQUILER
V. VENTA
Importe (de cada tem)

Se pide confeccionar:

1. Diagrama de sistemas

Observaciones.

El proceso finaliza cuando se llega al fin de archivo, indicado por el nmero de factura 0 .

Estructura de Datos - Normalizacion

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Estructura de Datos - Normalizacion

Cargado por

Copyright:

Formatos disponibles

_________________________________________________________________________

UNIVERSIDAD DE BUENOS AIRES

También podría gustarte