GUIA DE CASOS

Para Ejercitar el Diseño Conceptual y lógico

de Base de Datos

Marzo de 2023
Versión 5

AUTORES:

Ernesto Chinkes
Lucas Coronel
Gustavo Schneider
Franco Niz
Carolina Zorko
María Laura Moreno
 INDICE

Contenido
INDICE 1

INTRODUCCIÓN 2

CASOS CON RESOLUCIÓN 4

CASO DE EJEMPLO - JURASSIC PARK: DESCRIPCION 5
CASO DE EJEMPLO - JURASSIC PARK: SOLUCION PROPUESTA 6
CAMPERITA S.A. 8
CASO SIMPSON S.A. 9
PROYECTOS LIBERTADORES S.A. 10
TEATRO MORRISON 11
MILLONARIO UNA PASIÓN S.A. 13
SECRETARÍA DE INVESTIGACIÓN 14

CASOS ADICIONALES 16
MAFALDA S.A. 17
UNIVERSIDAD APRENDETODO 18

SOLUCIONES PROPUESTAS 20
CAMPERITA S.A. 20
SIMPSON S.A. 22
TEATRO MORRISON 25
PROYECTOS LIBERTADORES S.A. 24
MILLONARIO UNA PASIÓN S.A. 25
SECRETARÍA DE INVESTIGACIÓN ¡Error! Marcador no definido.

Página 2 de 27
INTRODUCCIÓN

La presente guía tiene como objetivo apoyar la práctica del diseño conceptual y lógico de
las bases de datos.

No contempla la explicación de los conceptos teóricos que dicha temática necesita, y que
deben ser adquiridos en forma previa, sino plantea la ejercitación sobre una serie de casos,
donde puedan aplicarse dichos criterios de diseño aprendidos.

Es por ello que esta guía presenta un conjunto de enunciados que describen problemáticas
organizacionales (casos) de instituciones de diversos rubros, sobre los cual deben aplicarse
las decisiones de diseño.

Cada caso tiene un sistema objeto a representar, están orientados a ser resueltos
considerando que la solución final será en una base de datos que responda al modelo
relacional.

Por otra parte se contempla que puedan definirse y trabajarse los siguientes conceptos:

● Entidades y sus atributos

● Relaciones, donde se analice y defina su cardinalidad y tipo de relación (Identidad
– No identidad)
● Uso de Diagramas Entidad-Relación (DER)

Cada caso tiene asignado un nivel de dificultad, para que pueda ir ejercitándolos de menor
a mayor.

En primera instancia tendrá una sección un caso de ejemplo, donde luego de la descripción
del mismo, se le explicará cuál es el tipo de resolución que se pretende que trabaje con los
casos.
Luego, se detallan un conjunto de descripciones de casos, y al final se proponen soluciones
de diseño para cada uno de los casos.

En este último aspecto es importante mencionar que son soluciones propuestas, ya que
pueden existir otras formas de resolver los casos que también pueden ser adecuadas.

Página 3 de 27
CASOS CON RESOLUCIÓN

Página 4 de 27
CASO DE EJEMPLO - JURASSIC PARK: DESCRIPCION
La empresa Jurassic Park S.A. es la propietaria de un parque de recreación donde el
público visita animales prehistóricos. Dicha empresa tiene un área (VISITAS
PREHISTÓRICAS) que se encarga de ofrecer visitas guiadas para escuelas.

El área Visitas Prehistóricas vende a las escuelas visitas guiadas al parque para sus
alumnos. Las escuelas realizan reservas telefónicas de las visitas que van a realizar, y se
les cobra el día que realizan la visita, en el momento de ingresar (según los tipos de
visitas que realicen).

Las escuelas en el momento de realizar la reserva informan, día, hora, tipos de visitas,
cantidad de alumnos por visita. Pueden en una misma reserva contratar distintos tipos de
visitas, para distintos grados de la escuela. En caso de que la escuela sea la primera vez
que realiza una reserva se le piden su domicilio y teléfono(s).

Jurassic Park S.A. desea desarrollar un sistema de informático que le ayude en un

eficiente desempeño y control del área mencionada. Necesita obtener del mismo, todos
los días, para la boletería del parque (en el momento en que ésta lo solicite) un listado con
las visitas que haya reservadas para el día siguiente, de manera de que la misma sepa a
quienes debe dejar entrar y cuanto cobrarles.

El listado debe contener (para cada reserva del día pedido): Número de reserva de visita,
Hora, Código de la escuela, Nombre de la escuela, y por cada tipo de visita de la reserva:
Código de tipo de visita, Descripción de tipo de visita, Arancel por alumno del tipo de
visita,
Cantidad de alumnos y grado(s).

Al final del día boletería debe informar la cantidad real de ingresantes que fueron por cada
reserva.

También se debe entregar todos los días un listado con las visitas reservadas para el día
siguiente para el Supervisor de Guías, cuando el mismo lo solicite. El supervisor debe, en
base al listado, asignar las distintas visitas a su personal a cargo. El listado debe contener
(para cada visita del día pedido): Número de reserva de visita, Hora, Código de la
escuela, Nombre de la escuela, y por cada tipo de visita de la reserva: Código de tipo de
visita, Descripción de tipo de visita, grado(s).

Al final del día el supervisor informa los guías que se encargaron de cada tipo de visita en
cada reserva.

El gerente del área desea poder pedir, en cualquier momento, un listado con la cantidad
de alumnos (reales) que ingresaron. Dicha información debe salir discriminada día por día
para el periodo de tiempo que él determine, y por cada día discriminado por tipo de visita.
Y otro listado donde pueda observar que cantidad de cada uno de los grados reservaron,
entre dos fechas a determinar, cada una de los tipos de visitas que existen.

El sistema debe permitir, además, permitir que el responsable de Recepción de reservas,

consulte quienes fueron los guías (Código de guía, y Nombre de guía), que participaron en
una reserva específica, teniendo identificado cual fue el guía responsable por cada tipo de
visita de la misma, ya que puede existir una queja de alguna escuela. Además se desea poder
realizar un mailing, con Nombre, Domicilio y Teléfono(s), de todas las escuelas que alguna vez
realizaron una reserva.

Página 5 de 27
CASO DE EJEMPLO - JURASSIC PARK: SOLUCION PROPUESTA
El resultado final al que debería llegar es el siguiente:

Página 6 de 27
Como puede ver, necesitamos que defina cada una de las entidades del modelo que
podrán soportar las necesidades de información planteadas en el caso.

Para cada una de ellas deben quedar definidos en el diagrama:

● Los atributos que representan las propiedades que deben representarse de dichas
entidades.
● Las claves primarias de cada entidad.
● Las claves foráneas de aquellas entidades que las tenga.
● Las relaciones, expresando la cardinalidad con mínimos y máximos.
● Los tipos de dependencias que generan las relaciones (identidad, no identidad,
generalización/especialización).

Las entidades del modelo final, deben cumplir las reglas de las formas normales, evitando
al máximo la redundancia, siempre y cuando ello no implique pérdida de información o
disminuya posibilidades de generar restricciones (conservar dependencias). Por otra parte
se espera que en el diseño intente maximizar los criterios que permitan un diseño
semánticamente claro, que maximice la representación de la información, y mejore su
posterior mantenimiento.

Para llegar a este modelo puede trabajar con una estrategia de arriba/abajo o de abajo
arriba, o un intermedio.

Aquí le recomendamos que realice inicialmente una estrategia de abajo/arriba cercana a la

entidad universal. Es decir una entidad muy representativa del sistema objeto desea
representar y que incluya todos los atributos (en este caso podría ser la entidad reserva). Y
luego ir descomponiendo la misma, según se vayan aplicando las distintas reglas de la
normalización.

Desde ya que también podrá usar similar criterio, pero en lugar de hacerlo desde una única,
podrá hacer dicho ejercicio desde una serie de entidades que considere relevantes, y
aplicar el mismo criterio, pero siempre considerando no olvidar que en caso que existan
relaciones entre dichas entidades deben disponer de atributos en ambas entidades que
permitan establecer una relación entre la clave primaria y la foránea.

Página 7 de 27
CAMPERITA S.A.

Dificultad: Baja

La empresa Camperita S.A. que se dedica a la fabricación de camperas desea un sistema

informático que le ayude en mejorar el desempeño de la gestión del área de compras y de
producción. José Camperetti, gerente de compras, es quien se encarga de realizar las
compras de materias primas a los distintos proveedores. El mismo requiere que el sistema
le permita, cuando él lo necesite, obtener:

● Un listado con las materias primas cuyo stock se encuentran por debajo del stock
Crítico (determinado para cada una de las materias primas). El listado debe
contener: Código de materia prima, Descripción de materia prima, Stock actual de
la materia prima, Stock crítico de la materia prima, Diferencia entre stock crítico y
actual.

● Por cada uno de los proveedores a los que se les ha comprado con anterioridad la
materia prima: Código de proveedor, Nombre proveedor, Ultimo precio unitario al
que se le compró, y la Cantidad comprada (unidades).

● Un listado, sobre el proveedor que en el momento de solicitarlo determine, las

distintas materias primas compradas al mismo, detallando para cada una de ellas:
Código de materia prima, Descripción de materia prima. A su vez, para cada una
de las compras realizadas: Fecha de compra, Cantidad comprada, proveedor y
precio unitario.

Por otro lado, a Roberto Camperon, gerente de producción, le interesa poder obtener del
sistema la siguiente información:

● Un listado que le detalle cual es la composición de cada uno de los productos que
fabrica la empresa. El listado debe detallar por cada producto: Código de producto,
Descripción de producto; y por cada una de las materias primas que los
componen: Código de materia prima, descripción de materia prima, y la cantidad
usada para el producto de dicha materia prima.

Observaciones:
● Un proveedor puede proveer a la empresa de varias materias primas distintas.
● Una materia prima puede ser provista por más de un proveedor.
● Una materia prima puede ser usada por más de un producto.
● Las compras a los proveedores se identifican por un número de compra que se
genera al registrarlas al sistema.
● Las compras son por proveedor, es decir, una compra está asociada a un solo
proveedor.

Alternativa:
Indique como cambiaría el modelo si no se trabajara con un número de compra y la
consigna dijera:

● Las compras a los proveedores se identifican por su número de factura y su código

de proveedor (dos proveedores podrían enviar una factura con el mismo número).

Página 8 de 27
CASO SIMPSON S.A.

Dificultad: Baja

La empresa Simpson S.A. es una organización que ofrece un servicio a empresas y

organizaciones. La prestación consiste en la venta de material de lectura especializado, a
precios rebajados, para los empleados de las empresas que contraten el servicio.

Los libros son vendidos directamente en las locaciones de las empresas cliente. Para ello,
Simpson SA tiene un plantel de unos 50 vendedores que se encargan de realizar visitas a
las organizaciones. Adicionalmente, también se ofrece el servicio de venta a domicilio,
donde el vendedor se acerca directamente al domicilio de los empleados de las
organizaciones cliente.

Las organizaciones que contratan el servicio deben entregar un listado con los datos de
todos sus empleados (Número de legajo, número de documento, nombre, teléfono(s) y
domicilio). Todos los meses deben informar sobre las nuevas contrataciones y las
desvinculaciones correspondientes.

El gerente de ventas, Homero, requiere un sistema que le asista en la asignación y

seguimiento de sus vendedores y de las visitas realizadas.

Homero desea que el sistema tenga registrados a todos los vendedores y a todos los
empleados que trabajen en las distintas empresas u organismos cliente. A fines de cada
semana utilizará el sistema para coordinar las visitas de la semana siguiente, indicando
para cada visita el vendedor, organización cliente y empleado. El vendedor tiene la libertad
de organizar su semana, mientras que cumpla con todas las visitas asignadas. Para ello
deberá poder imprimir una ficha por cada visita que tenga asignada.

Ejemplo de ficha de visita:

VENDEDOR: Código: 20 / Nombre y apellido: Bart Simpson

EMPLEADO:
Nombre: Smithers Pedro
Número de legajo: 100511
Teléfono particular: 55-5452
Domicilio particular: Av. Los Andes 45 5º "B"
EMPRESA:
Código de empresa: 50
Nombre: Planta Atómica S.A.
Teléfono empresa: 664-2554
Domicilio empresa: Av. San Martín 5544
VISITA:
Semana asignada:
Desde el: 01/06/94
Hasta el: 07/06/94
Fecha visita: __/__/__
Respuesta: 1) Venta
2) Volver otro día
3) No interesa el producto
4) No visitó

Página 9 de 27
Al finalizar la semana cada vendedor deberá ingresar al sistema los resultados de cada
visita.

Para el seguimiento de las visitas, Homero desea poder imprimir un listado con un detalle
de visitas asignadas a un vendedor determinado en un período de tiempo, también
determinado.

El listado deberá tener el siguiente formato

Listado de visitas por vendedor entre XX/XX/XX y XX/XX/XX:

VENDEDOR: Código: XX / nombre y apellido: xxxxxxxx
Fecha visita Legajo Empresa(código-nombre) ----------------------------------------------

Visitas con respuesta: 1-Venta

Fecha Visita Legajo Organización(Código y nombre)
XX/XX/XX XXXX XX-XXXXXXXXX
---------
Total de visitas con respuesta 1-Venta: X visitas

Visitas con respuesta: 2-Volver otro día

Fecha Visita Legajo Organización(Código y nombre)
XX/XX/XX XXXX XX-XXXXXXXXX
---------
Total de visitas con respuesta 2-Volver otro día: X visitas
---------------------------------------------------------
TOTAL VISITAS EN EL PERÍODO INDICADO: 40

Observaciones:

* Todos los empleados de las organizaciones cliente tienen legajo. Los números de legajos
pueden repetirse entre empleados de distintas empresas, pero no dentro de una misma.

* Las empresas tienen la misma dirección y teléfono para todos los empleados que en ella
trabajan.

* Los posibles resultados que puede tener la visita están codificados, existiendo más que
las cuatro que se muestran en la ficha del ejemplo.

* Una persona puede ser asignada a más de una visita, pero con un máximo de una visita
por semana. Todas las visitas asignadas a una persona no tienen que ser del mismo
vendedor.

Página 10 de 27
PROYECTOS LIBERTADORES S.A.

Dificultad: Media

Proyectos Libertadores S.A. es una consultora que asesora empresas en proyectos de

sistemas de información. Necesita llevar una administración controlada de los proyectos,
por lo que decide contratar sus servicios para el desarrollo e implementación de un sistema
que le permita administración de los mismos.
La empresa cuenta con aproximadamente 50 consultores. Los mismos son asignados a los
distintos proyectos que emprenden los clientes de la consultora.

Cuando una empresa necesita de los servicios de la consultora, se realiza una entrevista
con el Lic. Russo, director de proyectos y se confecciona una propuesta de proyecto (en la
cual se indican entre otras cosas fecha de comienzo, finalización y precio estimado). Si el
cliente acepta la propuesta, se registra la fecha de aprobación y se acuerda un precio, una
fecha de inicio real y una fecha de finalización estimada.

El Lic. Palermo, responsable de asignaciones, es quien se encarga de indicar los días y la

cantidad de horas, para esos días, en los que deberá trabajar cada consultor en cada
proyecto. Esto se realiza a principios de cada mes. A su vez los consultores, semanalmente,
informan para cada asignación, la cantidad de horas reales trabajadas.

Cuando un proyecto finaliza, se registra la fecha de finalización real.

Palacio, quien es el encargado de decidir la información que la consultora necesita, indica

que requiere los siguientes informes:

1. ¿Cuáles son los proyectos en los que se encuentra trabajando la consultora?: Por cada
uno necesita saber: código de proyecto, descripción, fecha de inicio, fecha planificada
de finalización y empresa cliente. También se desea conocer todos los contactos que
tiene cada proyecto.
2. ¿Cuáles son los proyectos que ya finalizaron? ¿Qué diferencias hubo entre las fechas
de finalización reales y las estimadas?
3. ¿Cuáles son todas las empresas clientes de la consultora? (se considera todas aquellas
empresas que alguna vez solicitaron consultoría). Para cada una de las empresas
necesita saber: código empresa, nombre, domicilio y contactos que tenga registrados.
Para cada contacto, se requiere nombre, teléfono(s) y sus internos, nombre y cargo.
4. Cuáles son los distintos consultores que trabajan o trabajaron en un proyecto
determinado: Necesita saber: nombre del proyecto, empresa cliente y horas totales
asignadas a ese proyecto. Por cada uno de los consultores que participó: número de
legajo, nombre, apellido, cargo, cantidad de horas reales de consultoría por mes
dedicadas al proyecto y especialidad o especialidades que tenga el consultor.

Observaciones:
• Un consultor puede estar asignado a más de un proyecto en la misma fecha.
• Un cliente puede tener más de un proyecto y los contactos de distintos proyectos de
un mismo cliente pueden no ser las mismas personas.

Página 11 de 27
TEATRO MORRISON

Dificultad: Alta

El teatro “Morrison” tiene tres salas donde se llevan a cabo funciones de distintas obras
teatrales. El dueño desea desarrollar un sistema que le permita realizar la operatoria que
se describe a continuación:

a) Reserva de entradas por Internet: Los potenciales asistentes podrán chequear la

disponibilidad de asientos de una función, y si lo desean, realizar una reserva. La reserva
puede comprender varios asientos para una función, y así mismo asientos para distintas
funciones. Para realizar la reserva debe seleccionar las distintas funciones y asientos que
desea incluir, para que el sistema le muestre el importe total, y el cliente confirme la misma.
La reserva tiene fecha de vencimiento a las 48 horas. Por lo tanto si no es pagada antes de
dicho lapso la misma queda sin efecto.

b) Venta de entradas reservadas: El cliente podrá pagar la reserva en efectivo, tarjeta débito
o tarjeta de crédito.

c) Descriptivo de Obras Teatrales: el sistema también debe permitir cargar los autores y
actores de las obras, así como sus directores y la descripción de las mismas. Está
información también le será mostrada a las personas que consulten la página del teatro por
Internet.

Observaciones:
● Una función se refiere a una obra en una fecha y horario específico, que tiene
asignada una sala.
● El precio de los asientos, depende solamente de su sector y de la obra que se esté
dando (no importan los datos de la función). Un asiento se identifica con un número
de fila y un número de columna y el sector al que corresponde.
● Las reservas deben quedar guardadas en la base de datos por más que hayan
quedado sin efecto, fruto de que pasaron las 48 horas sin ser pagadas.

Página 12 de 27
La persona responsable del proyecto, ha iniciado el desarrollo del sistema, sin embargo
tiene dudas y no está seguro del modelado de datos y DER realizados:

Página 13 de 27
MILLONARIO UNA PASIÓN S.A.

Dificultad: Alta

Millonario una pasión S.A. es una empresa dedicada a la comercialización de equipamiento

para la actividad médica. Cuenta con un plantel de vendedores encargados de realizar las
ventas directas a médicos.
Debido al gran crecimiento de los últimos años, la empresa se encontró con la necesidad
de obtener un sistema informático que asista al departamento de ventas, brindando
información sobre potenciales clientes.
Para conocer las necesidades se entrevistó a Enzo (Gerente de Ventas) y a otros usuarios
potenciales del sistema y se detectó todo lo detallado a continuación:
Se desea tener registros sobre los médicos con los siguientes datos: código interno,
apellido, nombre, teléfono(s), domicilio de su consultorio particular, instituciones en las que
trabaja, equipos que posee, sub-especialidad/es a la/s que se dedica, asociación
profesional a la que pertenece y CUIT.

A partir de estos registros, se desea obtener listados de médicos según:

● Código postal del consultorio particular.
● Sub-especialidad/especialidad.
● Institución en la que trabajan.
● Asociación profesional a la que pertenecer.
● Equipos que tienen a disposición (ya sea en su consultorio o en las instituciones en
las que trabajan).
● Cantidad de compras que han realizado.
También se requiere poder obtener información sobre las distintas instituciones: código
interno, nombre, teléfono(s), domicilio, equipos que posee, sub-especialidades a las que se
dedica, nombre del director y CUIT.

Además se solicita registrar y obtener información acerca de las ventas realizadas en

función de:
● Número, fecha, monto y equipos vendidos en cada factura emitida entre dos fechas.
● Monto vendido entre dos fechas.
● Todas las ventas realizadas por un vendedor determinado entre dos fechas.
● Cantidad de equipos incluidos en una venta.
● Precio unitario de los equipos.
Observaciones:
● Una Sub-Especialidad es una subclasificación dentro de una Especialidad. Una sub-
especialidad corresponde a una y solo una especialidad.
● Los médicos y las instituciones pueden dedicarse a una o más sub-especialidades.
No pueden dedicarse a una especialidad directamente.
● Un profesional puede pertenecer a más de una Asociación profesional.
● Los equipos que poseen los médicos o las instituciones que el sistema tiene
registrados, pueden ser o no comercializados por la empresa.
● Una venta puede realizarse a un médico o a una institución, pero siempre a uno y
sólo uno de ellos.

Página 14 de 27
SECRETARÍA DE INVESTIGACIÓN

Dificultad: Alta

La Secretaría de Investigación y Doctorado de la Facultad de Ciencias Económicas ha

solicitado un sistema informático que la ayude en su tarea de control y administración de
los investigadores, nombrados mediante una resolución, y que de ella dependen.

En la actualidad cuenta con 150 investigadores repartidos en 5 institutos (Instituto de

investigaciones administrativas, Instituto de investigaciones en historia económica y social,
Instituto de investigaciones económicas, Instituto de investigaciones contables, Instituto de
investigaciones de estadística y matemática actuarial).

Todo investigador es asignado solo a un instituto y designado con una categoría, pudiendo
ser:
● Docente
o Titular
o Asociado
o Adjunto
o Jefe de trabajos prácticos
o Ayudante de primera
o Ayudante de segunda
o Visitante
● Becario
o Estudiante
o Graduado de iniciación
o Graduado de perfeccionamiento
o Ayudante de investigación
Todo becario tiene, como director, a otro investigador que sea de categoría docente (jefe
de trabajos prácticos o superior).

Los investigadores pueden proponer proyectos a la secretaría. Si son aprobados, se les

asigna una fecha de inicio y una de fin. La aprobación del proyecto y sus fechas se deben
comunicar al investigador. Cuando finaliza, la secretaría es la encargada de evaluar los
resultados considerándolos satisfactorios o no satisfactorios.

Además del investigador que propone el proyecto (que trabaja como director del mismo),
es posible que otros investigadores sean asignados al proyecto para cumplir distintos roles
(Sub-Director, Investigador Formado e Investigador en Formación)

La secretaría desea obtener en cualquier momento los siguientes reportes:

● Listado de investigadores: Nombre, Instituto, Categoría y Subcategoría.
● Información de un investigador: Nombre, Número de legajo, Teléfono(s), Domicilio,
Nacionalidad, Número de documento, Estado civil, Fecha de nacimiento, Número
de resolución (designación), Lugar de trabajo (Instituto), Categoría, Investigador/es
a cargo (si es director de beca), Proyecto que dirige, Proyectos dirigidos
anteriormente.
● Proyectos: Título, Fecha iniciación, Fecha finalización, Resultado informe final,
investigadores participantes (indicando el rol que cumplen).

Página 15 de 27
CASOS ADICIONALES

Página 16 de 27
MAFALDA S.A.

La empresa Mafalda S.A., se dedica a la realización de congresos, conferencias y cursos sobre

nuevas tendencias tecnológicas. Debido a la gran cantidad de eventos que realiza y a la gran
concurrencia que tienen los mismos necesita un sistema que lo ayude en la gestión de ellos.

La empresa tiene información sobre posibles asistentes a sus cursos (Nombre, Domicilio,
teléfonos, Profesión, y Tema/s de su interés), dicha información la obtiene respecto de los
asistentes a cursos anteriores, y a recolección de información que cotidianamente va obteniendo
en colegios profesionales, asociaciones, y promociones en las cercanías de otros congresos,
conferencias.

Cuando la empresa está por realizar un evento, manda invitaciones a los posibles asistentes, la
selección de a quien mandar las invitaciones se hace según la profesión y los temas de interés
que se tienen guardados de las personas. Aquellas personas que les interese concurrir al
evento, se deberán inscribir, hasta una semana antes de la realización del mismo. Solo se podrá
inscribir personas hasta colmar la capacidad máxima de asistentes del evento.

El día de realización del evento, cuando las personas llegan y se quieren acreditar, se deberá
verificar que dicha persona se encuentre inscripta en el evento, y si ese es el caso se le debe
emitir y entregar la tarjeta de ingreso. En este momento, se registra en el sistema la asistencia
al evento.

Cuando el evento abarca más de un día, se debe poder sacar una listado de personas inscriptas
al evento (código y nombre de la personas, y profesión), que permita luego tomar lista de los
asistentes de ese día. Cuando el evento dura solo un día la asistencia se obtiene por las
personas que se acreditaron.

Una semana posterior a la finalización del evento se debe enviar al domicilio de todos los
asistentes los diplomas de asistencia al evento.

Es de vital importancia para Felipe, el gerente general, poder obtener información sobre un
evento. La información que requiere es: Código y Nombre del evento, tema, Cantidad de
personas invitadas, cantidad de inscriptos, y cantidad de asistentes.

De igual manera es de sumo interés para Guille, encargado de atención al cliente, poder saber
para una persona determinada a qué eventos fue invitada y en qué fecha, en cuales se inscribió
y en qué fecha, y a cuales asistió.

OBSERVACIONES

• Una persona puede tener más de un tema de interés, dichos temas son una lista de temas en
que la empresa ha catalogado, la cual puede ir variando en el tiempo.
• Una persona es considerada asistente, si asistió por lo menos a uno de los días en que se
realiza el evento.
• Un evento puede tratar sobre más de un tema de interés.

Página 17 de 27
UNIVERSIDAD APRENDETODO

La Universidad APRENDETODO de la ciudad de Estudiamucho agrupa todas las materias, que

en ella se dictan en departamentos académicos (actualmente son 10 departamentos). A la
cabeza de cada departamento se encuentra un director. Por fuera de los departamentos, en la
Universidad existe una oficina que tiene por función asistirlos. Esta oficina se llama Oficina de
Asistencia a Directores, también denominada OAD.

La OAD recibe los distintos requerimientos que son dirigidos a los directores de departamento
(los requerimientos se realizan a través de expedientes). Dichos expedientes son entregados al
departamento correspondiente para que los directores se encarguen de resolverlos en lo que a
ellos concierna.

Una vez que el director del departamento ha finalizado el tratamiento del expediente, lo entrega
a la OAD para que haga seguir el curso del mismo, direccionándolo donde corresponda.

Los expedientes tienen un número (que los identifica unívocamente), que es otorgado por la
universidad cuando el iniciador del expediente quiere dar comienzo al mismo. Quien lo inicia y
lo presenta en la OAD, es el iniciador (que puede una persona, organismo, otro departamento,
etc.). Los motivos del expediente pueden ser por ejemplo el nombramiento de un docente, una
denuncia, remoción de un docente, pedido de equivalencias de un alumno. Los mismos están
tipificados por la OAD.

Otra actividad propia de los directores de departamento es la organización de reuniones

periódicas a donde invitan a todos los docentes de las materias que pertenecen al
departamento. Y es la oficina antes mencionada la encargada de realizar las invitaciones a los
docentes correspondientes.

Se le pide a Ud., que realice el análisis de un sistema de información para la OAD, ya que se
quiere implementar uno que ayude a dicha oficina en su gestión.

El sistema debe cumplir las siguientes demandas de los directores, cuando ellos lo exijan:

1. Cuáles son los expedientes que tuvo el departamento sobre un determinado motivo.
Necesita saber por cada uno de los expedientes: número de expediente, fecha de inicio,
iniciador, motivo, solución adoptada, destino y fecha en que se entregó al destino.
2. Cuáles son todos los expedientes para su departamento iniciados con posterioridad a
una determinada fecha y que aún no han sido resueltos. Necesita de cada uno: número
de expediente, fecha de inicio, iniciador, motivo.
3. Cuáles son los expedientes de su departamento que sean de un determinado iniciador,
hayan sido o no resueltos. Necesita saber por cada uno de los expedientes: número de
expediente, motivo, y solución adoptada (si es que ya fue resuelto).
4. Una lista de todos los docentes que hayan confirmado su asistencia a una reunión por
él citada. Necesita saber por cada uno de los docentes: Nºlegajo del docente, nombre
del docente, fecha en que aceptó.
5. Cuáles son todas las reuniones que organizó en un determinado periodo. Necesita saber
por cada reunión: código de reunión, tema, día, hora, lugar de reunión.

Página 18 de 27
Además el sistema debe permitir que la OAD obtenga una lista con todos los docentes que
pertenecen a un determinado departamento. Necesitan por cada uno de los docentes:
Nombre, teléfono, materia, domicilio.

Finalmente, el sistema a diseñar debe permitir dar respuesta ante el requerimiento de un

iniciador sobre el avance de su expediente. Permitiendo informarle si el mismo está en poder
del director de departamento, o si ya ha sido entregado a otro destino; y en el segundo de
los casos informarle a quien y en qué fecha.

OBSERVACIONES:

● Una materia pertenece a un y solo un departamento.

● No existe expediente que sea tratado por más de un departamento.
● Un Docente puede pertenecer a más de un departamento, según las materias que
dicte.

Página 19 de 27
SOLUCIONES PROPUESTAS

Página 20 de 27
CAMPERITA S.A.
Dificultad: Baja

Página 21 de 27
CAMPERITA S.A. (Alternativa)
Dificultad: Baja

Página 22 de 27
SIMPSON S.A.
Dificultad: Baja

Página 23 de 27
PROYECTOS LIBERTADORES S.A.
Dificultad: Media

Página 24 de 27
TEATRO MORRISON
Dificultad: Alta

Página 25 de 27
MILLONARIO UNA PASIÓN S.A.
Dificultad: Alta

Página 26 de 27
SECRETARÍA DE INVESTIGACIÓN
Dificultad: Alta

Página 27 de 27