UTNianos

Versión completa: Final GDD 21/02/2018
Actualmente estas viendo una versión simplificada de nuestro contenido. Ver la versión completa con el formato correcto.
Buenas, les dejo el final que tomaron en Febrero.

[attachment=16460]

Saludos
1) VOF

a - Falso: Es un arbol equilibrado porque, todos los nodos maximales se encuentran en el mismo nivel
b - Falso: Dado que tiene un mayor alcance de lockeo de los registros, se verá afectada la performance. Es recomendable un nivel mas permisivo como read commited o read uncommited

2)

a - Las vistas son objetos de las bases de datos. Son conjuntos de columnas, ya sean reales o virtuales, que no ocupan (allocan) espacio de almacenamiento, no contienen datos almacenados, sino que están definidas por una consulta que implica una o varias tablas. Se utilizan para suministrar un nivel adicional de seguridad restringiendo el acceso a un conjunto de datos, ocultar complejidad de datos, simplificar sentencias. Al crear una view el usuario debe tener permisos de select sobre las columnas de las tablas involucradas. No se puede adicionar a una view las cláusulas de order by o union, tal como tampoco se pueden definir triggers sobre una vista.
Se pueden utilizar para casos en los que se ven involucradas tablas con información sensible. Por ejemplo tengo la tabla cliente que tiene el nombre, numero de cuenta bancaria, cuanto dinero dispone en ella y su sucursal principal; y otra tabla que tiene la información de las sucursales. Si yo quisiese que un grupo de usuarios puedan ver que clientes tienen asignadas ciertas sucursales, podría crear una vista que se encargue de traer esta información ocultado los datos sencibles. Obteniendo asi que los usuarios consulten sobre la vista, y sobre ella puedan hacer sus sub busquedas siendo que en ningun momento ellos tuvieron conocimiento de la información sensible ni la logica o complejidad que hubo por detras para obtener dicha información.
-ejemplo asi nomas, pero se entiende-

b - El dominio son todos los valores reales posibles que pueden tomar los registros.
Integridad de Entidad: es usada para garantizar que los datos pertenecientes a una misma tabla tienen una única manera de identificarse. Que tenga una primary key única y no nula. Se valida unicidad y existencia.
Integridad Referencial: es usada para garantizar que la coherencia entre datos de dos tablas. El uso de foreign keys hace que dado una o mas columnas se estará referenciando a la primary key de otra. Si vos queres borrar un registro que esta siendo referenciado por otra tabla, ocurrira un error.
Integridad Semantica: es usada para garantizar el sentido y configuración de los datos que vamos a almacenar, y que estos respeten las restricciones de dominio o sobre los atributos. Ej, DATA TYPE, DEFAULT, UNIQUE, NOT NULL, CHECK

3 )
a - Yo crearia dos triggers
(Cero performante, pero es sencillo de entender lo que hago)


GO
CREATE TRIGGER tr_nuevaProv ON Provincia
FOR INSERT, UPDATE
AS

IF NOT EXISTS( SELECT * FROM CIUDAD c, INSERTED i WHERE c.idpcia = i.idpcia )
BEGIN
UPDATE Provincia SET habitantes = null where idpais in (select idpcia from inserted)
END
ELSE
BEGIN
IF ( (select habitantes from inserted) <= 0 )
BEGIN
RAISERROR('hab deben ser mayor a 0',1,1)
ROLLBACK TRANSACTION
END
END

GO
CREATE TRIGGER tr_nuevaCiu ON Ciudad
AFTER INSERT
AS
IF EXISTS( SELECT * FROM Provincia p, INSERTED i WHERE i.idpcia = p.idpcia )
BEGIN
DECLARE @hb int;
SELECT @hb = ISNULL(habitantes,0) FROM Provincia -- esta logica la intento yo como para hcer algo, no se si habria que ponerlo
UPDATE Provincia SET habitantes = @hb+1 where idpais in (select idprov from inserted)
END
GO


b - Para mi ninguna opcion, para mi trae de cada pais que tenga provincias , el id de la provincia que tiene mas habitantes, en caso de que dos provincias del mismo pais tengan la misma cantidad y esta sea maxima, te traera los dos ids, ordenado de modo asc por la cantidad de habitantes de las proviencias

Es algo que respondo, pero si ven algo mal corrijan sin problema!
De la 1)a) para mi es Verdadera:

Un Árbol principal derecho balanceado es un árbol que cumple dos condiciones a la vez:

1- Árbol Balanceado: todas sus hojas tienen el mismo nivel.
2- Árbol principal derecho: todos los nodos no-principales tienen un único padre y el nodo principal es el minimal del árbol (llamado raíz) y es único.

La condición 2 se cumplen para TODOS los árboles binarios.

De la 1)b) Concuerdo que es Falsa:

Al tener un mayor alcance de lockeo en los registros, puede verse afectada la performance, por lo que para alta concurrencia, sería recomendable el nivel de aislamiento uncommitted read(teniendo en cuenta que en este hay lecturas no repetibles, lecturas sucias y lecturas fantasmas), o committed read (teniendo en cuenta que en este SI hay lecturas repetibles, lecturas sucias y lecturas fantasmas), dependiendo lo que considere más adecuado el DBA.
El 3a arme el trigger de esta manera:

CREATE TRIGGER regla_negocio ON provincia INSTEAD OF INSERT,UPDATE
AS
BEGIN

DECLARE @id_pcia INTEGER,@id_pais INTEGER, @habitantes INTEGER

DECLARE cursor_prov CURSOR FOR
SELECT id_pcia,id_pais,habitantes FROM inserted;

OPEN cursor_prov
FETCH NEXT FROM cursor_prov INTO @id_pcia,@id_pais,@habitantes
WHILE @@FETCH_STATUS=0
BEGIN
IF (@habitantes>0) AND (SELECT COUNT(*) FROM ciudad c WHERE id_pcia=@id_pcia) > 0
BEGIN
INSERT INTO provincia (id_pcia,id_pais,habitantes) VALUES (@id_pcia,@id_pais,@habitantes)
END
ELSE
BEGIN
INSERT INTO provincia (id_pcia,id_pais,habitantes) VALUES (@id_pcia,@id_pais,0)
END
FETCH NEXT FROM cursor_prov INTO @id_pcia,@id_pais,@habitantes
END
CLOSE cursor_prov
DEALLOCATE cursor_prov
END

Para hacer las pruebas en SQL SERVER:

Spoiler: Mostrar
CREATE TABLE pais
(id_pais INTEGER PRIMARY KEY,
detalle VARCHAR(20)
)

CREATE TABLE provincia
(id_pcia INTEGER PRIMARY KEY,
id_pais INTEGER FOREIGN KEY REFERENCES pais(id_pais),
habitantes INTEGER
)

CREATE TABLE ciudad
(id_ciudad INTEGER PRIMARY KEY,
id_pcia INTEGER FOREIGN KEY REFERENCES provincia(id_pcia),
nombre VARCHAR (20)
)

INSERT INTO pais (id_pais,detalle) VALUES (1,'Argentina');
INSERT INTO provincia (id_pcia,id_pais,habitantes) VALUES (1,1,2000);
INSERT INTO ciudad (id_ciudad,id_pcia,nombre) VALUES (1,1,'San Martin');

SELECT * FROM pais;
SELECT * FROM provincia;
SELECT * FROM ciudad;

INSERT INTO provincia (id_pcia,id_pais,habitantes) VALUES (3,1,1000);
INSERT INTO ciudad (id_ciudad,id_pcia,nombre) VALUES (3,1,'Lomas de Zamora')

DROP TRIGGER regla_negocio
DELETE FROM provincia WHERE id_pcia=2
con respecto a la integridad que se puede decir de las vistas?
(09-02-2019 11:27)lukies escribió: [ -> ]con respecto a la integridad que se puede decir de las vistas?
la vista la relaciona con la seguridad
(09-02-2019 11:27)lukies escribió: [ -> ]con respecto a la integridad que se puede decir de las vistas?

En los apuntes solo dice que están relacionadas por el "WITH CHECK OPTION" que por lo que tengo entendido es un limitante para modificar la tabla involucrada en una view. Para poder modificarla tiene que cumplir la condición (CHECK).
(10-12-2018 15:37)Smitten1994 escribió: [ -> ]El 3a arme el trigger de esta manera:

CREATE TRIGGER regla_negocio ON provincia INSTEAD OF INSERT,UPDATE
AS
BEGIN

DECLARE @id_pcia INTEGER,@id_pais INTEGER, @habitantes INTEGER

DECLARE cursor_prov CURSOR FOR
SELECT id_pcia,id_pais,habitantes FROM inserted;

OPEN cursor_prov
FETCH NEXT FROM cursor_prov INTO @id_pcia,@id_pais,@habitantes
WHILE @@FETCH_STATUS=0
BEGIN
IF (@habitantes>0) AND (SELECT COUNT(*) FROM ciudad c WHERE id_pcia=@id_pcia) > 0
BEGIN
INSERT INTO provincia (id_pcia,id_pais,habitantes) VALUES (@id_pcia,@id_pais,@habitantes)
END
ELSE
BEGIN
INSERT INTO provincia (id_pcia,id_pais,habitantes) VALUES (@id_pcia,@id_pais,0)
END
FETCH NEXT FROM cursor_prov INTO @id_pcia,@id_pais,@habitantes
END
CLOSE cursor_prov
DEALLOCATE cursor_prov
END

Para hacer las pruebas en SQL SERVER:

Spoiler: Mostrar
CREATE TABLE pais
(id_pais INTEGER PRIMARY KEY,
detalle VARCHAR(20)
)

CREATE TABLE provincia
(id_pcia INTEGER PRIMARY KEY,
id_pais INTEGER FOREIGN KEY REFERENCES pais(id_pais),
habitantes INTEGER
)

CREATE TABLE ciudad
(id_ciudad INTEGER PRIMARY KEY,
id_pcia INTEGER FOREIGN KEY REFERENCES provincia(id_pcia),
nombre VARCHAR (20)
)

INSERT INTO pais (id_pais,detalle) VALUES (1,'Argentina');
INSERT INTO provincia (id_pcia,id_pais,habitantes) VALUES (1,1,2000);
INSERT INTO ciudad (id_ciudad,id_pcia,nombre) VALUES (1,1,'San Martin');

SELECT * FROM pais;
SELECT * FROM provincia;
SELECT * FROM ciudad;

INSERT INTO provincia (id_pcia,id_pais,habitantes) VALUES (3,1,1000);
INSERT INTO ciudad (id_ciudad,id_pcia,nombre) VALUES (3,1,'Lomas de Zamora')

DROP TRIGGER regla_negocio
DELETE FROM provincia WHERE id_pcia=2




Smitten en el enunciado dice "si no posee ciudades el campo habitantes debe ser nulo" cosa que vos le asignas 0 de una.. no soy gorra pero es lo que dice el enunciado y te pueden poner como que no cumpliste esa regla cry
el resto me parece genial la respuesta y super entendible thumbup3
(17-10-2019 09:04)Diesel escribió: [ -> ]
(10-12-2018 15:37)Smitten1994 escribió: [ -> ]El 3a arme el trigger de esta manera:

CREATE TRIGGER regla_negocio ON provincia INSTEAD OF INSERT,UPDATE
AS
BEGIN

DECLARE @id_pcia INTEGER,@id_pais INTEGER, @habitantes INTEGER

DECLARE cursor_prov CURSOR FOR
SELECT id_pcia,id_pais,habitantes FROM inserted;

OPEN cursor_prov
FETCH NEXT FROM cursor_prov INTO @id_pcia,@id_pais,@habitantes
WHILE @@FETCH_STATUS=0
BEGIN
IF (@habitantes>0) AND (SELECT COUNT(*) FROM ciudad c WHERE id_pcia=@id_pcia) > 0
BEGIN
INSERT INTO provincia (id_pcia,id_pais,habitantes) VALUES (@id_pcia,@id_pais,@habitantes)
END
ELSE
BEGIN
INSERT INTO provincia (id_pcia,id_pais,habitantes) VALUES (@id_pcia,@id_pais,0)
END
FETCH NEXT FROM cursor_prov INTO @id_pcia,@id_pais,@habitantes
END
CLOSE cursor_prov
DEALLOCATE cursor_prov
END

Para hacer las pruebas en SQL SERVER:

Spoiler: Mostrar
CREATE TABLE pais
(id_pais INTEGER PRIMARY KEY,
detalle VARCHAR(20)
)

CREATE TABLE provincia
(id_pcia INTEGER PRIMARY KEY,
id_pais INTEGER FOREIGN KEY REFERENCES pais(id_pais),
habitantes INTEGER
)

CREATE TABLE ciudad
(id_ciudad INTEGER PRIMARY KEY,
id_pcia INTEGER FOREIGN KEY REFERENCES provincia(id_pcia),
nombre VARCHAR (20)
)

INSERT INTO pais (id_pais,detalle) VALUES (1,'Argentina');
INSERT INTO provincia (id_pcia,id_pais,habitantes) VALUES (1,1,2000);
INSERT INTO ciudad (id_ciudad,id_pcia,nombre) VALUES (1,1,'San Martin');

SELECT * FROM pais;
SELECT * FROM provincia;
SELECT * FROM ciudad;

INSERT INTO provincia (id_pcia,id_pais,habitantes) VALUES (3,1,1000);
INSERT INTO ciudad (id_ciudad,id_pcia,nombre) VALUES (3,1,'Lomas de Zamora')

DROP TRIGGER regla_negocio
DELETE FROM provincia WHERE id_pcia=2




Smitten en el enunciado dice "si no posee ciudades el campo habitantes debe ser nulo" cosa que vos le asignas 0 de una.. no soy gorra pero es lo que dice el enunciado y te pueden poner como que no cumpliste esa regla cry
el resto me parece genial la respuesta y super entendible thumbup3

Opino igual que Diesel. Habria que ponerle "NULL" en vez de 0.

También añadiría que contrario como dijeron más arriba, a las vistas si se les puede incluir la clausula UNION y UNION ALL, siempre y cuando ambas consultas respeten cantidad, orden y tipo de las columnas.
En el 3a tengo una duda

- Se crea un trigger para PROVINCIA (insert, update)
-- Si no existen ciudades de esa provincia, le fuerzo NULL al valor habitantes y lo inserto.
-- Si tiene ciudades, valido que el valor enviado no sea NULL y no sea menor o igual a cero. Lo inserto.

Ahora que pasa si luego de agregar una provincia, agrego una ciudad?

El valor en provincia esta en NULL, pero le acabo de agregar una ciudad, ya deberia dejar de ser NULL. Pero que valor le pongo?

Mauro_bilo, te arrobo porque lo visto hoy, gracias!
Buenas!

Despues de darle algunas buenas al 3B, creo que la rta es la B.

Si bien en la consulta ni se menciona a la ciudades, hay una situación que hace que en el resultado aparezcan solamente paises que tengan habitantes. Y para tener habitantes, tienen que tener al menos una ciudad.
Lo tuve que probar para terminar de darme cuenta, pero la clave está en que en la sub query se usa un "="


WHERE pro.habitantes =


Entonces, si para algun pais ninguna de sus provincias tuviese habitantes (lo cual significa que la columna habitantes tiene el valor NULL para todas esas provincias), entonces el MAX(pro2.habitantes) va a retornar un NULL para ese pais
Entonces, como decia más arriba, para ese caso terminaria quedando un WHERE pro.habitantes = NULL.
Y como los NULL solamente cumplen la condición si se escribe con la sintaxis IS NULL, entonces las provincias con valor habitantes=NULL se descartan de la query principal. Por lo tanto, en la query principal se terminan teniendo en cuenta solamente los paises que tengan habitantes. Y como decia antes, para tener habitantes tienen que tener al menos una ciudad. Esto último lo sé por haberme cruzado con varios finales en donde aparece este dominio.

Otra cosa para aclarar es que en la Opción B dice "Como mínimo 1 registro por pais". Esto es porque un mismo pais podria tener dos provincias con la misma cantidad de habitantes. Si eso ocurriese, apareceria ese pais dos veces en el resultado final de la query.

Estoy un poco quemada ya, asi que ojalá se haya entendido. Si algo de lo que dije no está bien avisenme por fas.

Saludos wave
URLs de referencia