Estimados, les dejo el final que tomaron el martes pasado en Gestión de Datos (que gracias a Jebus aprobé). No se zarparon con el contenido, pero dieron una hora para resolverlo. Nuevamente mas que evaluar conocimiento parece una carrera contra reloj que lo único que logra es que uno escriba como electrocardiograma para llegar a cubrir los puntos, ni hablar de los 40 grados que hacia en el aula sin ventiladores que nos asigno Bedelía y que desbordaba de alumnos... se ve que especulaban con el tema de que se vaya gente con los 5 minutos para ver el examen y decidir si quedarse o no, pero... se quedaron todos, eramos dos por banco (tema único)...

Éxitos para los que rindan!

- -

Gracias por el aporte !

La verdad era bastante accesible..que bronca!

(17-02-2012 02:32)Kurt escribió:  ...dieron una hora para resolverlo. Nuevamente mas que evaluar conocimiento parece una carrera contra reloj que lo único que logra es que uno escriba como electrocardiograma para llegar a cubrir los puntos, ni hablar de los 40 grados que hacia en el aula sin ventiladores que nos asigno Bedelía y que desbordaba de alumnos

yo todavía no fui a rendir éste final pero casi todos los posts vienen acompañados de éstos comentarios sobre el tiempo y los exámenes "inhacibles", coincido totalmente con el tema de que no evalúan conocimientos porque esas condiciones no predisponen a buenos resultados, simplemente a joderte una fecha y hasta desanimarte si tenés que dar otra

Felicitaciones xq aprobaste y gracias por el aporte!

Buenas gente, por el último punto, yo uso T-SQL e implementaría una FK que tenga ON DELETE CASCADE de la siguiente manera:

alter table Det_fact
add constraint FK_DetFact_nFact
foreign key(n_fact) references Cab_fact(n_fact)
on delete cascade;

Y con esto le peleo a muerte que usé el Objeto de BD "Foreign Key".

Alguno fue a rendir este examen? surgió alguna discusión por esto?

Saludos !!

Fede.-

Me parece acertada tu solución, ya que en el examen pedían indicar el motor de base de datos y en ningún momento decía (a diferencia de otros exámenes que vi) que estaba prohibido alterar la tabla. Por lo que observe Zafaroni tenia a mano una notebook para probar el código en aquel motor que los profesores no tengan practica, y Fabricio labura sobre SQLSERVER así que seguramente esa solución iba a ser considerada correcta y sino la podes pelear tranquilamente. Igualmente sigo opinando que codificación o programación se debería rendir en un laboratorio con un motor real y no en un papel.

Saludos.

No surgió discusión (no había tiempo ), pero está perfecto. Lo único que dijeron fue "objeto de DB" dejando abierto, que había varias maneras de hacer lo mismo; podía ser con ese constraint o bien negro con un trigger.

Saludos!

Alguien resolvió el punto 3a? Y el 1b?
Acá dejo mi resolución del 3a para comparar:
create view vistaAños (AÑO, [code=sql]FECHAMINIMA,FECHAMAXIMA,CANTUNICOS,CANTUNIDADES,SUMAPRECIOS)
as
select year(cf.f_fact) as AÑO,
(select min(f_fact)
from cab_fact
where year(f_fact) = year(cf.f_fact))as FECHAMINIMA,
(select max(f_fact)
from cab_fact
where year(f_fact) = year(cf.f_fact))as FECHAMAXIMA),
(select count(*)
from det_fact df inner join cab_fact cf2 on df.n_fact = cf2.n_fact
where year(cf2.f_fact) = year(cf.f_fact)
group by cf2.n_fact
having count(distinct df.c_articulo) = 1) as CANTUNICOS,
(select sum(df.cantidad)
from det_fact df inner join cab_fact cf2 on df.n_fact = cf2.n_fact
where year(cf2.f_fact) = year(cf.f_fact) as CANTUNIDADES,
(select sum(df.i_precio)
from det_fact df inner join cab_fact cf2 on df.n_fact = cf2.n_fact
where year(cf2.f_fact) = year(cf.f_fact) as SUMAPRECIOS
from cab_fact cf
group by year(cf.f_fact)
having sum (select (df.i_precio)
from det_fact df inner join cab_fact cf2 on df.n_fact = cf2.n_fact
where year(cf2.f_fact) = year(cf.f_fact)) > 300000

Tomé el i_precio como el precio por unidad en vez de precio total, pero es lo mismo para el caso.

CREATE VIEW VistaAnios
(
Anio,
FechaMinima,
FechaMaxima,
Unicos,
Unidades,
Total
)
AS
SELECT
DATEPART(year, CF.f_fact),
MIN(CF.f_fact),
MAX(CF.f_fact),
COUNT(DISTINCT DF.n_item),
SUM(DF.cantidad),
SUM(DF.cantidad * i_precio)
FROM
Cab_fact CF INNER JOIN Det_fact DF ON CF.n_fact = n_fact
GROUP BY
DATEPART(YEAR, CF.f_fact)
HAVING
SUM(DF.cantidad * i_precio) > 300000

(25-02-2012 22:10)yakultmon escribió:  Tomé el i_precio como el precio por unidad en vez de precio total, pero es lo mismo para el caso.

CREATE VIEW VistaAnios
(
Anio,
FechaMinima,
FechaMaxima,
Unicos,
Unidades,
Total
)
AS
SELECT
DATEPART(year, CF.f_fact),
MIN(CF.f_fact),
MAX(CF.f_fact),
COUNT(DISTINCT DF.n_item),
SUM(DF.cantidad),
SUM(DF.cantidad * i_precio)
FROM
Cab_fact CF INNER JOIN Det_fact DF ON CF.n_fact = n_fact
GROUP BY
DATEPART(YEAR, CF.f_fact)
HAVING
SUM(DF.cantidad * i_precio) > 300000

Tal cual.. no hace falta ningún subselect..
El distinct creo que no va, porque no es los que se vendieron solo 1 vez, sino los que se vendieron AL MENOS una vez (osea todos los que aparecen). Eso lo preguntaron ahí en el final y contestaron eso.

Cita:El distinct creo que no va, porque no es los que se vendieron solo 1 vez, sino los que se vendieron AL MENOS una vez (osea todos los que aparecen). Eso lo preguntaron ahí en el final y contestaron eso.

El FROM devuelve 1 registro por cada detalle de factura. Es posible que en dos facturas se venda el mismo artículo (Botella Coca Cola), entonces si no usamos el DISTINCT, el COUNT contaría los repetidos, aunque sea la misma clase de artículo (si se venden 2 botellas, contaría 2 en vez de 1).

El DISTINCT no filtra por única ocurrencia (y descarta lo demás), sino que cuenta todas las ocurrencias como una única.

(26-02-2012 20:37)yakultmon escribió:  

Cita:El distinct creo que no va, porque no es los que se vendieron solo 1 vez, sino los que se vendieron AL MENOS una vez (osea todos los que aparecen). Eso lo preguntaron ahí en el final y contestaron eso.

El FROM devuelve 1 registro por cada detalle de factura. Es posible que en dos facturas se venda el mismo artículo (Botella Coca Cola), entonces si no usamos el DISTINCT, el COUNT contaría los repetidos, aunque sea la misma clase de artículo (si se venden 2 botellas, contaría 2 en vez de 1).

El DISTINCT no filtra por única ocurrencia (y descarta lo demás), sino que cuenta todas las ocurrencias como una única.

Es que los repetidos me parece que si hay que contarlos.. vah digo, como decía "al menos 1 vez", si se vendio 2 veces sin el distinct los contaba. Eso decía yo.

che una pregunta si alguien sabe ...

SNOWFLAKE y STAR .. la diferencia entre ambos radica en que en SNOWFLAKE las tablas de dimensiones estan normalizadas, y en STAR no ..

ahora, de todos modos, SNOWFLAKE no se considera NORMALIZADO, no ?? porque la tabla de hechos está en ambos modelos, lo que hace que ambos sean DESNORMALIZADOS ...

alguien me corrige eso por favor !?!?!?

Hola.

Snowflake Schema: Es un esquema de representación derivado del esquema en estrella, en el que las tablas de dimensión se normalizan en múltiples tablas.

=> Si, la diferencia entre ambos radica en que en SNOWFLAKE las tablas de dimensiones estan normalizadas, y en STAR no.

Saludos.

(27-02-2012 03:53)Kurt escribió:  Hola.

Snowflake Schema: Es un esquema de representación derivado del esquema en estrella, en el que las tablas de dimensión se normalizan en múltiples tablas.

=> Si, la diferencia entre ambos radica en que en SNOWFLAKE las tablas de dimensiones estan normalizadas, y en STAR no.

Saludos.

confirmado entonces .. gracias !