si, veo que zafaroni tiene sus apuntes propios

yo uso los del grupo de gestion de datos, pero tienen muchas menos cosas

---

podras precisamente subir ese apunte? tengo algunos de zaffaroni que consegui, pero ese justo no =(

---

en un V o F pusieron que una funcion no puede modificar el contenido de una tabla, y pusieron que es F, que si puede



no es verdadero? las functions no pueden usar insert, delete y update

como modificas una tabla?

Una funcion no puede modificar una tabla,

pusieron falso porque decia "es la unica diferencia" con un SP

no pusieron eso aca

(20-12-2011 15:00)pablosreitano escribió:  

(08-12-2011 21:29)Alejandro escribió:  

Cita:1.b) En PL-SQL, la única diferencia entre una función y un store procedure es que puede retornar valores.
F. El estore procedure puede retornar valores por parametros.

otras diferencias

La función también puede ejecutarse en un SELECT.
La función no puede modificar contenido de las tablas.(Falso, si si puede)

Cita:1.b) Un índice en una base de datos relacional es una restricción al modelo físico.
V.

Espero sirva el aporte!

Saludos, PABLITO R

Esto yo decia q es correcto q sea falso:
En PL-SQL, la única diferencia entre una función y un store procedure es que puede retornar valores.


Ahora eso q pusieron q una funcion puede modificar contenido, está mal, no puede!!

alguien tiene el pdf de zafaroni que habla de introduccion al datawarehousing? el de reinosa es una poronga..

Listo

Les dejo tres V o F que estoy en duda:

El método de Árbol B es más rápido que Hashing para la creación de índices.
Se me hace que es VERDADERA porque con el Hashing uno tiene que aplicar la función de Hash y si hay colisiones tiene que rehashear o no en caso de que se esté usando hash encadenado.
Siempre es conveniente tener una tabla indexada por su primary key.
Que las PKs estén indexadas mejora la perfomance a la hora de los joins, pero si no me falla la memoria recuerdo que Zaffaroni nos aconsejó que indexar las columnas en las que intervienen frecuentemente los filtros también, así que es FALSA?
Si se desea ocultar columnas de una tabla a una aplicación el mejor objeto de la base de datos que podemos utilizar es un sinónimo.
Es FALSA porque (al menos en SQL Server) el sinónimo puede servir para las tablas, pero no para las COLUMNAS de la misma.

(18-07-2013 21:56)NathanDrake escribió:  Si se desea ocultar columnas de una tabla a una aplicación el mejor objeto de la base de datos que podemos utilizar es un sinónimo.
Es FALSA porque (al menos en SQL Server) el sinónimo puede servir para las tablas, pero no para las COLUMNAS de la misma.

falsa. lo mejor para eso es una vista que tenga solo las columnas que quieras mostrarle a la apicacion

Hola!!

yo diría que:
El método de Árbol B es más rápido que Hashing para la creación de índices.
Falso. Si dijera que es para el acceso a datos, sería V

Siempre es conveniente tener una tabla indexada por su primary key.
Verdadero. Porque podes tener por filtros tambien,pero el motor por default indexa por pk, por eso creo q es conveniente

Si se desea ocultar columnas de una tabla a una aplicación el mejor objeto de la base de datos que podemos utilizar es un sinónimo.
Falsa. Es mejor una vista

Dejo estas que tengo dudas:

La técnica de Hash abierto puede generar muchas lecturas secuenciales para un valor "clave hash" cuando hay alto grado de repetición de claves de usuario

El método de hashing es menos perfomante que el método del Arbol B para el manejo de claves duplicadas

La única estructura de datos estática capaz de representar cualquier grafo es una matriz

gracias!!

(08-12-2011 19:11)guidoakd escribió:  

(20-09-2011 22:29)Ziggy escribió:  1.a) Un árbol binario con cuatro nodos nunca puede ser completo.
V. Un árbol binario completo de altura h ≥ 0 contiene al menos 2^h nodos y a lo sumo 2^(h+1) −1 nodos.

Para mi es falsa. Si tenés:

------A-----
---B-----C--
D-----------

Son 4 nodos y es completo y binario.. a no ser que con nodo no se refiera a raiz y hojas.
Además con la formula que pusiste, si la altura fuese 2 (4 nodos), contiene al menos 2 al cuadrado nodos, osea 4 para ser completo.

Ese árbol no es completo.
Def: "Un árbol es completo cuando todos sus nodos NO MAXIMALES (aka "los que no son hojas") tienen igual grado de salida".

En tu ejemplo, el nodo A tiene grado de salida = 2, y el nodo B tiene grado de salida = 1.
Como g(A) != g(B) --> El árbol no es completo.

PERO si hubieras hecho esto...
--------A-----
-----B-------
---C-----------
-D------------

Ahí tenés un árbol binario donde todos sus nodos no-maximales tienen grado de salida = 1.
Como C B y A tienen el mismo grado --> Es un árbol binario completo.
Dado este contraejemplo, podría concluir que la afirmación es FALSA.

(08-12-2011 21:29)Alejandro escribió:  

Cita:1.a) Un vector es una representation computacional estatica que puede almacenar un arbor.
V.

¿posta? ¿cómo haces para meter un arbol en un vector? nunca lo vi

Según palabras del mismo Zaffaroni (me lo explicó personalmente varias veces, posta me parecía un flash) en Heapsort se utiliza un Vector como estructura física, y dentro de ese vector se va almacenando un árbol "lógico", que no existe, que no se implementa como estructura, sino que el mismo vector es quien contiene el árbol.

(20-05-2013 00:14)MSC escribió:  otra:
"La reexpresión de caracteres al aplicar Huffman implica la disminución de 8 bits para la expresión de todos los caracteres"
no entiendo esta afirmacion?
pienso q es falso porque en la teoria no lei que disminuya eso, pero alguien tiene mas informacion sobre eso??

Cada caracter en ASCII ocupa una cierta cantidad de bits que es fija (8 bits por char), en cambio con Huffman tenés una cantidad variable de bits por char... algunos pueden ocupar 3 bits, otros 4, otros 5, etc....
Esta afirmación por ende es FALSA, ya que cada caracter reduce su cantidad de bits dependiendo su frecuencia dentro del string/mensaje a enviar.

(21-05-2013 14:04)gonnza escribió:  alguien tiene el pdf de zafaroni que habla de introduccion al datawarehousing? el de reinosa es una poronga..

Conseguiste el apunte introduccion al datawarehousing?? Lo pasas porfa!, o si alguien lo tiene lo puede subir?

Gracias!!

(14-12-2014 23:09)NaiaraAcosta escribió:  

(21-05-2013 14:04)gonnza escribió:  alguien tiene el pdf de zafaroni que habla de introduccion al datawarehousing? el de reinosa es una poronga..

Conseguiste el apunte introduccion al datawarehousing?? Lo pasas porfa!, o si alguien lo tiene lo puede subir?

Gracias!!

Va adjunto.

(18-07-2013 21:56)NathanDrake escribió:  Siempre es conveniente tener una tabla indexada por su primary key.
Que las PKs estén indexadas mejora la perfomance a la hora de los joins, pero si no me falla la memoria recuerdo que Zaffaroni nos aconsejó que indexar las columnas en las que intervienen frecuentemente los filtros también, así que es FALSA?

No siempre!
Tambien hay que considerar la cantidad de registros que posee y la longitud de los campos. A veces agregar un indice a una tabla "chica" termina ocupando mas espacio el indice que la tabla.
Saludos!

Cita:1.a) Para representar grafos irrestrictos son más perfomantes las representaciones dinámicas que las estáticas.

Yo diria que esta es Falsa,
Un resumen dice:

Cita:• Grafos Restrictos: son aquellos en los cuales la relación modelizada no debe cumplir las
propiedades de reflexivididad, simetría y transitividad.
• Grafos Irrestrictos: son aquellos que pueden modelizar cualquier relación
independientemente de las propiedades que cumpla o no.

Entonces, suponiendo que yo tenga un grafo que consta de un nodo que se referencia a si mismo 100 veces, si lo represento dinamicamente tendria una lista de 100 elementos, en cambio si lo represento estaticamente en la matriz de adyacencia tendria una tabla de 1x1 con un solo valor "100".

Igual tambien se me ocurren ejemplos para justificarla como verdadera, alguien tiene un poco mas de insight sobre esto?

Off-topic:

Acabo de ver que la ultima respuesta es mia de hace como 1 mes atras, alguien lee esto?

(09-01-2015 00:15)Aoshido escribió:  

(18-07-2013 21:56)NathanDrake escribió:  Siempre es conveniente tener una tabla indexada por su primary key.
Que las PKs estén indexadas mejora la perfomance a la hora de los joins, pero si no me falla la memoria recuerdo que Zaffaroni nos aconsejó que indexar las columnas en las que intervienen frecuentemente los filtros también, así que es FALSA?

No siempre!
Tambien hay que considerar la cantidad de registros que posee y la longitud de los campos. A veces agregar un indice a una tabla "chica" termina ocupando mas espacio el indice que la tabla.
Saludos!

El motor de base de datos no indexa siempre por primary key?