Una “discusión” sobre un parcial

Primero como para ponernos en órbita, explico de qué se trata esto. Ayer (Martes) rendí el primer y único parcial de Gestión de datos. No pude estudiar mucho por algunas cuestiones personales en cuanto a discrepancia con los docentes de la materia y no tenía mucho ánimo. Por suerte algo de SQL sabía porque lo había estudiado por mi cuenta en otra oportunidad.

Luego de salir del parcial, me fui contento a mi casa porque me había ido, a mi modo de ver las cosas: bastante bien. Como siempre, esto no quiere decir que apruebe ni nada por el estilo, y mucho menos si considero la bronca que me tienen los docentes por hacer preguntas en clases.

Dejando de lado todo esto, hoy tuve clase de práctica y un amigo me preguntó algo sobre un ejercicio que me hizo poner en duda. Aproveché y le pregunté a la profesora sobre esto. Escribo abajo el diálogo completo (transcripción que realicé desde un OGG).

Pero antes, explico más o menos como era el enunciado del problema. Había un diagrama entidad-relación el cuál nosotros teníamos que pasar a tablas SQL pero sin escribir las sentencias CREATE TABLE y demás. Sino que con algunos dibujos y explicando cuales eran claves primarias y foráneas estaba bien. El diagrama era como este (lo único que le falta son algunos atributos a foto que no recuerdo, pero es para mostrar la idea):

El enunciado decía más o menos así: “Un usuario puede tener 0 o n fotos y una foto puede tener como máximo un dueño. Además un usuario puede tener n cuentas de email. NOTA: cant_fotos es un atributo calculable.”

Yo hice tres tablas, una para Usuario, otra para Foto y otra Usuario_Email en la que indicaba el email y el usuario, de modo que pueda tener muchos emails un mismo usuario. En ningún lado puse cant_fotos ya que en el enunciado decía que era un atributo calculable. Aunque antes de leerlo igualmente pensaba que no debería estar ya que sale con un SELECT COUNT. Asique no lo puse en ningún lado. Ahora viene lo que hablamos con la profesora hoy. El primero que hablar (“A”) es un amigo, y luego paso a ser yo (“M”). “P” es la profesora:

A: En la que teníamos que armar las tablas: a mí me quedaron tres, Usuario, Correo y Foto. Además había un atributo que era calculable.

P: Si, eso es porque estaba en el modelo.

A: Claro, yo no lo puse en ninguna tabla.

P: No, pero eso tiene que estar en la tabla Usuario.

A: ¿Tiene que estar?

P: Si obvio.

A: Pero si se puede calcular.

P: El contenido después lo verán, se supone que si lo estás haciendo en la vida real el contenido lo calcularás por código o lo que sea. ¿Pero dónde lo vas a almacenar? Tenés que tener creado el campo dentro de la tabla.

M: Pero eso se calcula desde la tabla de fotos. Hacés un SELECT COUNT de la tabla de fotos y sabés cuantas fotos tiene ese usuario. No es necesario guardarlo.

P: Bueno, está bien. Lo óptimo sería no guardarlo, sino que ir calculando e ir mostrándolo. Sino que así como estaba en el modelo se necesitaba tener ese atributo en la tabla.

M: ¿Porqué? No entiendo…

P: Y porque es un atributo de Usuario. Después el contenido lo vas calculando y, osea, lo que se entiende es que si está en el modelo es porque se necesita tenerlo almacenado en algún lado, entonces lo almacenás como un atributo en la tabla de Usuario. Igual, si no lo pusieron se les bajará unos puntitos nada más. Osea, sólo por no haber puesto el atributo N-Fotos no van a salir mal.

M: No, está bien, no es la cuestión salir bien o salir mal. El tema es que no entiendo porqué está mal no ponerlo, a eso me refiero. Si justamente el enunciado decía “el atributo es calculable”

P: Si, en realidad en el enunciado estaba como una aclaración para que no pregunten “¿Qué es ese atributo que esta con líneas puntadas?” Puede ser que eso los confundió digamos y que pensaban que había que hacer algo o no almacenarlos.

M: Es que está almacenado, porque si vos sabés cuantas fotos hay en la base de datos, ese
atributo ya lo tenés. A eso es lo que voy yo.

P: Sí, pero cuando vos hacés el cálculo lo obtenés.

M: Claro, de hecho si lo guardás puede quedar inconsistente la base de datos porque te quedan 5 fotos y tiene 10.

P: Está bien, y es así como vos me decís. De hecho puede ser que no esté el atributo en
la vida real y no lo tengas que guardar, pero en este caso del modelo sí porque aparecía. Si
no fuese necesario diréctamente no aparece en el modelo y por código lo obtenés. Y listo.

M: Bueno, entonces que sea calculable y que no sea calculable es indistinto.

P: Si, en este caso es lo mismo.

M: No puede ser.

P: ¿Cómo que no? Cuando nosotros hicimos la guía había cosas que te pedía la guia y que en modelo no se reflejaban. Bueno en este caso es al revés, si estaba en el modelo era porque después al transformarlo lo ponías como un atributo en tu tabla. Igualmente todo es discutible, cuando después vos empieces a trabajar podés ir a preguntarle al usuario que te está mandando hacer el trabajo si lo va a querer tener almacenado o no. Y le vas a decir que no hace falta porque lo vas a poder calcular y lo podés hacer por código, etc etc… Y seguramente no lo vas a tener. En este caso del modelo si.

… me imagino preguntándole al cliente: “Señor, ¿Quiere que guarde el atributo X o lo calculamos al momento de mostrarlo? ¿Usted que opina?”…

11 pensamientos en “Una “discusión” sobre un parcial

  1. Nacho dice:

    je, bueno. Lo único que te puedo decir es que al tratarse de un modelo, vos deberías dejar plasmado de alguna forma que atributos van a estar disponibles en la entidad. Es decir cuales se van a ver. Quizá luego decidas que esa entidad vaya a persistir el atributo, o que será calculable, pero eso ya sería un detalle de implementación (calcularlo al hacer un insert en fotos, un trigger que haga esto, o alguna otra opcion).
    Creo que había una forma de indicar que un atributo que modelabas era derivable o calculable, para que luego cuando se crean las tablas no lo agregue el tipito SQL.
    Me parece, no recuerdo bien, que la notación para estos era envolver el atributo con un circulo con rayitas (dashed circle). Navathe explica algo de esto.
    Por supuesto que todo esto es muy distinto a lo que te respondieron.

  2. Nacho dice:

    Al presionar enviar se cargo la imagen del DER. Ese es el atributo derivado al que me refería.🙂

  3. Gastón Ramos dice:

    Me parece que la profesora sabe muy poco de bases de datos y muy poco de programación en general, es muy triste que una persona con tan pocos conocimientos llegue a dar cátedra en una universidad.

  4. Pablo dice:

    Luego de leer la discusión pensé “esa es mi profesora” discute lo indiscutible, usa repetidas veces “digamos”, “o sea” , pero yo estudié en La Matanza, así que no es, pero … “es igual!”🙂. Que triste que haya profesores/as así.

  5. Daniel dice:

    jajaja, me parece que como en la mayoria de las catedras, la profesora tiene la razon!!!.
    Igual lo triste gaston es que no haya nadie controlando a esos profesores, no se si pasa en tu facultad, pero en la UTN. Ultimamente viene utilizandose la modalidad de poner un “profesor” profesional, como “cara” de la catedra y alumnos “ayudantes” que son los que terminando “dando clase”.
    Te invito a concurrir a algunas de las clases, obvio lleva pañuelos!!!

  6. Esteban dice:

    La profesora puede no tener mucha idea… pero la idea del modelo creo que es la siguiente, lo ejemplifico.

    Imaginense que tienen un sitio como Flicker o Picasa, donde la gente puede tenes N cantidad de fotos, y el sitio puede tener N cantidad de usuarios, siendo N una cantidad muy grande. Si por cada usuario tiene que hacer un ‘select count’, se te cae toda la performance de los servers!! Se entiende?
    O sea si cada vez que el usuario agrega o saca una foto uno precalcula el cant_fotos, el sistema ya no depende de un ‘select count’ si no que el numero ya esta en el modelo.

    Vuelvo a decir que quizas el modelo se diseño con esto en cuenta y la profesora no sabe una goma…

    Just my 2 cents…

  7. Nubis dice:

    Al dojo vacio le preocupa tu educación 3 ordenes de magnitud menos que a vos… ‘news at eleven’, y no solo aca en Argentina
    http://www.lambdassociates.org/blog/hackers.htm

    saludos
    —-nubis🙂

  8. guille dice:

    que haces, manuel.

    no puede ser mas comico lo que terminas de contar.

    yo pensaba que solo teniamos burros como docentes en la utn de san francisco, pero ustedes no se quedan atras. debe ser una constante en gestion de datos, nuestra profe es igual de desastrosa.

    que desastre los profe que tenemos y que triste. espero que alguna vez podamos cambiar esta situacion.

    dos años atras habiamos creado un blog para contar estos detalles de nuestros profe, pero lo dimos de baja porque habia mucho material para escribir y nos zarpabamos en los comentarios.

    nos vemos.

  9. C dice:

    Me haces acordar del primer parcial de paradigmas. Me bajaron 22 puntos porque no se dieron cuenta que la mitad del ejercicio estaba del otro lado de la hoja.
    Cuando se avivaron de la cagada que se habían mandado, me dijeron que ese modelo no era “actualizable a futuro”.

    Hay cada uno.

  10. Santiago dice:

    Primero:
    Conceptualmente la manera de establecer si un atributo es calculable es poniendolo con un ovalo punteado, si no está, es porque el atributto o caracteristica no va a ser considerada en el sistema, no importa la implementación que hagas, justamente para eso están los atributos calculables en la notación, implica que en algún reporte o pantalla ese dato va a ser requerido y como citaron varios de los “comentaristas” en el diseño se establece la manera en que ese dato será calculado. O sea, ponerlo en el diagrama conceptual es decir que cosas y en el diseño el como (error muy habitual para los que solo son programadores). Yo creo que si fue dada la notación para atributos calculables durante la cátedra, el examen tiene un error, si la notación no está dada, podría considerarse correcto.
    Segundo:
    Con respecto a que si los profesores saben mucho o poco, yo soy docente, en la UTN, coincido que algunos de mis colegas por orgullo prefieren no admitir que no saben, o a veces no saben como explicarse (aunque a algunos dan ganas de matarlos), tengan en cuenta que dar clases (yo tengo + de 6 años) es super dificil, y más materias como Análisis y Diseño (yo soy docente en ellas), donde uno lucha contra alumnos sin ganas de estudiar, contra programas super largos, con alumnos alergicos a leer libros, con materias básicas atocigadoras, con una base pésima en programación, algoritmia, OO, con lo cual se hace cuesta arriba y lo peor, los diocentes ganamos muy poco con respecto al trabajo que hay que realizar, es fácil quejarse, quisiera verlos dar clases y despues vemos….

  11. gmgo dice:

    Jajaja, me pasa lo mismo😛

    Igualmente mis 2 centavos:

    Cómo tu dices, almacenar los atributos calculables es por definición redundante. En el ejemplo, la cantidad de fotos por usuario está implicitamente almacenado. Desde este punto de vista, estaría correcto NO guardar dicha información.

    SIN EMBARGO, no siempre es malo tener información redundante, quizás no sea bueno el ejemplo, pero imagina que tienes pocos usuarios, muchas fotos y muchas consultas de cantidad de fotos p/usuario. No almacenar ese dato implicaría obtenerlo ante cada consulta, lo que significa que almacenar dicho dato podría beneficiar el procesamiento (a costa de almacenamiento). Entonces, hay que analizar que realmente conviene hacer, a partir de cualse serán tus prioridades.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: