UTNianos

Básicamente lo que dice el título. Si alguno tiene la fotocopia y la puede compartir o contar mas o menos que fue lo que se tomó en el final de hoy.

Gracias

Yo estoy esperando que me cuenten. Lo unico que puedo agregar es que dieron 5 min para verlo e irse

Me sumo al pedido así la semana que viene ya lo despachamos para casa .

Hola

VOF:

1) La unica manera para asegurar unicidad de los campos es con una Primary Key o con UNIQUE
2) El orden de complejidad del AB es igual que el de ----------

Teoria:
1)Defina Niveles de Isolacion
2)Defina 2 objetos para implementar seguridad en una base de datos

Ejercicios

Tabla Habitaciones
numero
estado (Ocupada / Libre)

Tabla Reservaciones
nrohabitacion
fecha desde
fecha hasta

3a) Suponiendo que venga un cliente a pedir una habitacion ahora por 3 dias, realizar una consulta que traiga la primer habitacion que este disponible y cuyo tiempo entre que el cliente que llego y el tiempo de reserva sea menor sabiendo que toads las habitaciones tienen una reservacion a futuro.


3b)Desarrolle los triggers necesarios para emular una foreing key de resrevaciones a habitaciones sabiendo que ninguna posee constrains de ningun tipo


Recuerden agradecer e (?)

Agrego algunas cosas:

El 1b decía: "El orden de complejidad de un ABB (árbol binario de búsqueda) es similar al del Arbol-B"
El de niveles de aislamiento pedía definición, tipos y ejemplos de c/u.

Saludos!

Según tengo entendido los VoF son FALSOS los dos.

No se si era justificando o no pero se podría justificar así

A) FALSO, porque también se puede asegurar la unicidad de un campo creando un trigger que valide cada vez que se hace un update o insert

B) FALSO, porque el orden de complijidad del árbol binario de búsqueda es O(log n) y en el peor de los casos O(n) y el orden de complejidad de un árbol b es siempre O(log n). O sea si se da el peor de los casos no serian iguales. (igual en esta no estoy seguro si esta bien, si alguno me puede corregir mejor)

(25-02-2015 11:00)Nacho14 escribió: [ -> ]Según tengo entendido los VoF son FALSOS los dos.

No se si era justificando o no pero se podría justificar así

A) FALSO, porque también se puede asegurar la unicidad de un campo creando un trigger que valide cada vez que se hace un update o insert

B) FALSO, porque el orden de complijidad del árbol binario de búsqueda es O(log n) y en el peor de los casos O(n) y el orden de complejidad de un árbol b es siempre O(log n). O sea si se da el peor de los casos no serian iguales. (igual en esta no estoy seguro si esta bien, si alguno me puede corregir mejor)

El 1A seguro es falso por lo que vos dijiste.
El 1B no sabria porque no lo conteste.

Lo de niveles de isolation esta en todos lados, y respecto a la seguridad en la base yo puse con el Catalogo y con Vistas, es una pregunta que (Junto con asegurar integridad) se repite mucho en los finales, saludos!

(25-02-2015 11:36)Aoshido escribió: [ -> ]

(25-02-2015 11:00)Nacho14 escribió: [ -> ]Según tengo entendido los VoF son FALSOS los dos.

No se si era justificando o no pero se podría justificar así

A) FALSO, porque también se puede asegurar la unicidad de un campo creando un trigger que valide cada vez que se hace un update o insert

B) FALSO, porque el orden de complijidad del árbol binario de búsqueda es O(log n) y en el peor de los casos O(n) y el orden de complejidad de un árbol b es siempre O(log n). O sea si se da el peor de los casos no serian iguales. (igual en esta no estoy seguro si esta bien, si alguno me puede corregir mejor)

El 1A seguro es falso por lo que vos dijiste.
El 1B no sabria porque no lo conteste.

Lo de niveles de isolation esta en todos lados, y respecto a la seguridad en la base yo puse con el Catalogo y con Vistas, es una pregunta que (Junto con asegurar integridad) se repite mucho en los finales, saludos!

Respecto a la seguridad también se podrían agregar los SP y los triggers pero si hay que nombrar solo 2 creo que lo más acertado es lo que decís vos.

Para asegurar la integridad están

- los triggers
- transacciones
- constraints
- logical logs

---

Alguno pudo hacer los ejercicios?

Hola Aoshido! Gracias por publicar! Como te fue?
(o la parte practica la estoy entendiendo mal o es un re quilombo... es UNA reserva o pueden ser varias reservas a futuro?)
Te hago una pregunta... que no terminé de entender, a las vistas de catalogo de seguridad te referis? Cuando hablas de herramientas para asegurar integridad?

(25-02-2015 19:43)coolerking escribió: [ -> ]Hola Aoshido! Gracias por publicar! Como te fue?
(o la parte practica la estoy entendiendo mal o es un re quilombo... es UNA reserva o pueden ser varias reservas a futuro?)
Te hago una pregunta... que no terminé de entender, a las vistas de catalogo de seguridad te referis? Cuando hablas de herramientas para asegurar integridad?

Hola!
No te enquilombes al pedo, dentro de todas las consulta que te piden en los ultimos finales era una de las mas sencillas estas. Para limitar la cantidad de resultados podes usar "TOP" (Select top 1 * from habitaciones) si estas en MSSQL o LIMIT (Select * from habitaciones limit 1) si estas en otros motores .
A mi me fue bien, saque un 4 miseria a pesar de saber todo pq estaba terriblemetne nervioso entregue rapido e hice un solo trigger para la Foreing key.

Te dejo un poco en Pseudocodigo como son las cosas que yo creo qeu hay que hacer

 Select h.numero from habitaciones

left join reservas r on (r.nrohabitacion = h.nrohabitacion and datediff(h.desde,getdate('today'))>=3)

where h.estado = libre

order by r.desde asc

limit 1

(al final nada de pseudocodigo ese es el ejercicio entero jajaja)

Y en el otro tenes que hacer 3 triggers
Uno para BEFORE INSERT en RESERVAS (que no te deje insertar un nrohabitacion que no exista en habitaciones)
Uno para BEFORE UPDATE en RESERVAS (que no te deje modificar un nrohabitacion que no exista en habitaciones)
Uno para BEFORE DELETE en HABITACIONES (Que no te deje borrar una haitacion que esta siendo referneciada en resrevas)

Las vistas y el Catalogo son 2 objetos distintos.
Las vistas buscalas en google como "Views" Y el catalogo es el que tiene todos los datos necesarios para representar una BD ademas de las relaciones (Que eso estan en las tablas corrrespondientes)
Por ejemplo en el catalago tenes tablas con los usuarios que pueden acceder a la base de datos, tablas que te dicen que permisos tienen esos usarios en la base y demas.
Un ejemplo mas concreto seria (me imagino, nunca vi un catalogo...)

USERS
ID----Nombre
1----- Aoshido

Permissions
IDUSER IDTABLE "PERMISOS"
1--------- 1--------- TODOS

TABLES
1 --- Ejemplo

Eso seria que el Usuario Aoshido en la tabla "Ejemplo" tiene todos los permisos (Insert update delete drop etc)

Cualquier cosa pregunten, saludos!

a mi se me ocurrió algo así


CREATE TRIGGER chequeoForeingKey
ON reservas
AFTER UPDATE, INSERT
AS
BEGIN

IF (SELECT 1 FROM INSERTED WHERE INSERTED.nrohabitacion NOT IN (SELECT numero FROM HABITACIONES) = 1)
raiserror ('el numero de habitacion que intenta agregar / modificar no se encuentra en la tabla habitaciones')
rollback

END


CREATE TRIGGER chequeoForeingKey
ON habitaciones
AFTER DELETE
AS
BEGIN

IF (SELECT 1 FROM DELETED WHERE DELETED.numero IN (SELECT nrohabitacion FROM RESERVAS) = 1)
raiserror ('el numero de habitacion que intenta borrar tiene una referencia en la tabla reservas')
rollback

END

(25-02-2015 22:27)Aoshido escribió: [ -> ]

(25-02-2015 19:43)coolerking escribió: [ -> ]Hola Aoshido! Gracias por publicar! Como te fue?
(o la parte practica la estoy entendiendo mal o es un re quilombo... es UNA reserva o pueden ser varias reservas a futuro?)
Te hago una pregunta... que no terminé de entender, a las vistas de catalogo de seguridad te referis? Cuando hablas de herramientas para asegurar integridad?

Hola!
No te enquilombes al pedo, dentro de todas las consulta que te piden en los ultimos finales era una de las mas sencillas estas. Para limitar la cantidad de resultados podes usar "TOP" (Select top 1 * from habitaciones) si estas en MSSQL o LIMIT (Select * from habitaciones limit 1) si estas en otros motores .
A mi me fue bien, saque un 4 miseria a pesar de saber todo pq estaba terriblemetne nervioso entregue rapido e hice un solo trigger para la Foreing key.

Te dejo un poco en Pseudocodigo como son las cosas que yo creo qeu hay que hacer

 Select h.numero from habitaciones

left join reservas r on (r.nrohabitacion = h.nrohabitacion and datediff(h.desde,getdate('today'))>=3)

where h.estado = libre

order by r.desde asc

limit 1

Compilar y ejecutar código

(al final nada de pseudocodigo ese es el ejercicio entero jajaja)

Y en el otro tenes que hacer 3 triggers
Uno para BEFORE INSERT en RESERVAS (que no te deje insertar un nrohabitacion que no exista en habitaciones)
Uno para BEFORE UPDATE en RESERVAS (que no te deje modificar un nrohabitacion que no exista en habitaciones)
Uno para BEFORE DELETE en HABITACIONES (Que no te deje borrar una haitacion que esta siendo referneciada en resrevas)

Las vistas y el Catalogo son 2 objetos distintos.
Las vistas buscalas en google como "Views" Y el catalogo es el que tiene todos los datos necesarios para representar una BD ademas de las relaciones (Que eso estan en las tablas corrrespondientes)
Por ejemplo en el catalago tenes tablas con los usuarios que pueden acceder a la base de datos, tablas que te dicen que permisos tienen esos usarios en la base y demas.
Un ejemplo mas concreto seria (me imagino, nunca vi un catalogo...)

USERS
ID----Nombre
1----- Aoshido

Permissions
IDUSER IDTABLE "PERMISOS"
1--------- 1--------- TODOS

TABLES
1 --- Ejemplo

Eso seria que el Usuario Aoshido en la tabla "Ejemplo" tiene todos los permisos (Insert update delete drop etc)

Cualquier cosa pregunten, saludos!

GENIO gracias. Sabes que habia entendido?
Que en la tabla reservaciones, tenias por cada reserva una fila osea podias tener
Habitacion Desde Hasta
1 12/12/14 13/12/14
1 16/12/14 17/12/14
2 13/12/14 19/12/14
...
Y en base a eso tenias que calcular cuando estaba libre una habitación... jajaj gracias!

Hola, muchas gracias por subir el final e ir tirando las resoluciones.

Quería consultarles porque me queda una duda con el ejercicio de los triggers 3b. Por que no tomaron en cuenta el trigger para el Update en la tabla de habitaciones??

Me parece que también se tendría que validar el caso en que me hagan un Update a un numero de habitación si existen reservas para esa habitación.

En el codigo de Nacho14:
"CREATE TRIGGER chequeoForeingKey
ON habitaciones
AFTER DELETE,UPDATE"

Saludos.

Porque harían un update del número de Habitación? ya que es la PK de esa tabla.
Incluso en el enunciado te dice que la Foreign Key está en Reservas, por lo que no es necesario el update del IdHabitacion de la tabla de Habitaciones.
"Desarrolle los triggers necesarios para emular una foreing key de resrevaciones a habitaciones sabiendo que ninguna posee constrains de ningun tipo"

Lo único que se está actualizando es el estado de la habitación que en este caso no se involucra en las validaciónes para la FK.

(28-02-2015 21:29)Martin. escribió: [ -> ]Porque harían un update del número de Habitación? ya que es la PK de esa tabla.
Incluso en el enunciado te dice que la Foreign Key está en Reservas, por lo que no es necesario el update del IdHabitacion de la tabla de Habitaciones.
"Desarrolle los triggers necesarios para emular una foreing key de resrevaciones a habitaciones sabiendo que ninguna posee constrains de ningun tipo"

Lo único que se está actualizando es el estado de la habitación que en este caso no se involucra en las validaciónes para la FK.

Me parece tiene razon Wolframp.
El enuncidado decia claramente que ninguna de las dos tablas tenian constraints de ningun tipo, asi que habitaciones no tiene nada (PK) que me impida borrar/updatear un numero de habitacion.

Off-topic:

Igual creo que en este caso ambos casos estarian bien, seria la diferencia entre un bien y un bien menos.