Preguntes i respostes de l'examen final de DBDA
Nota: Aquest post està específicament pensat per a que els meus estudiants de Disseny de Bases de DAdes puguin veure les preguntes i les respostes de l'examen final que van fer el 19/6/2008.
1.- Com traduirieu a una base de dades la classe Data? Es materialitzaria en forma de taula? Quins són els seus efectes en la resta de taules del model? (1 punt)
Es transformaria en una columna de la taula emissions. El tipus d'aquesta columna seria algun dels que ens permet representar una data (long, Date...). Aquesta columna hauria de formar part de la clau primària de la taula emissions.
2.- En quin cas tindria sentit definir un índex sobre l’atribut (columna) data de la classe (taula) emissió? Justifica clarament la resposta (1 punt. Per a la resposta no cal que tingueu el diagrama, penseu en quan val la pena tenir un índex sobre un camp de tipus data)
Tindria sentit en el cas en què les consultes que contiguéssin a la clàusula WHERE condicions de comparació amb una data fossin freqüents. En qualsevol cas, s'hauria de verificar que el temps de la consulta es redueix fent proves de rendiment
3.- Per al cas anterior s’ha decidit posar un índex de tipus hash estàtic. Després d’un any d’ús, intensiu de la base de dades s’ha vist que el rendiment de les consultes ha baixat molt. Quines poden ser les causes? (1 punt)
La causa més habitual és que el Hash hagi degenerat. La solució seria regenerar el hash o canviar el tipus d'índex
4.- Quin seria el millor tipus d’índex que podriem fer per fer consultes sobre el resultat de fer una join? I si volguéssim fer consultes per a un determinat intèrval de valors? (1 punt)
Join -> Índex cluster. Intèrval -> B+
5.- Com recuperaríeu la jerarquia (herència) que s’estableix entre tema i subtema? (1 punt, veieu el model següent)
En realitat, en aquest model no hi ha cap herència, donat que a la taula TEMES no hi ha més atributs a part del seu nom. El que s'estableix és una relació TEMES 1 : N SUBTEMA, que es pot recuperar fent una join per nomTema. En cas que hi hagués més atributs a la taula TEMES (i tinguéssim, per tant, una herència real) s'hauria de recuperar fent servir una left-outer join entre les dos taules
6.- Quin seria el resultat d’aplicar la vostra solució a la pregunta 2 a les taules anteriorment definides per extensió? (1 punt)
El resultat de fer la join.
7.- Hi hauria algun aventatge sobre la solució actual si, enlloc de fer l’herència descrita anteriorment, es desnormalitzèssin les dos taules i quedés només la taula de subtemes? Hi hauria algun inconvenient? Justifica la resposta (1,5 punts)
La desnormalització del model aconseguiria que les consultes anéssin una mica més ràpid, donat que no s'hauria de calcular la join cada cop que es vulguéssin recuperar dades de la taula SUBTEMES. Per contra, no es garantiria la integritat referencial en cas que es permetés introduir manualment el nom del tema quan es vulgués donar d'alta un nou subtema. Donat que no tenim una taula TEMES, les dades dels noms dels temes no podrien ser recuperades d'enlloc, així que no es podria fer servir una solució que mostrés un desplegable (tag select - option de l'HTML) per a evitar el problema anterior. La solució més aventatjosa en aquest cas seria eliminar la foreign key que va de SUBTEMES cap a TEMES, però deixar la taula TEMES. Així, els noms dels temes es podrien recuperar i mostrar com un desplegable (el control de la integritat referencial es passa cap al programa) al formulari que donés d'alta un nou SUBTEMA. En el moment de consultes contra la base de dades, l'SGBD no hauria de calcular la join.
En qualsevol cas, no es recomana desnormalitzar aquestes taules, excepte en sistemes que requereixin un molt alt rendiment.
8.- A partir de la següent text extret de l’examen parcial:
[Friker Jiménez]: Hi ha un tema per cada secció i després un tema general del programa. I a més, per cada secció, hem de guardar el material de suport. És a dir: els vídeos, les fotos, els audios... i on estan a l’arxiu de la casa.
[Consultor Senior]: Vale. Entrem ara més en detall. Dels col·laboradors, quines dades vols guardar?
[Sots-Drectora]: Amb el nom i el número de compte corrent en tenim prou.
[Consultor Júnior]: I dels temes i subtemes i tot això?
[S.D.]: Dels temes el nom i dels subtemes... un nom i una descripció.
[ConsSr]: S’afegeixen molts temes i molts subtemes normalment? Canvien molt?
[S.D.]: Sí, de tant en tant en posem de nous.
[ConsSr]: D’acord. Una última cosa. Depenent del tipus de secció tindreu sempre els mateixos materials?
[F.J.]: Interessant pregunta. Mmmmm... jo diria que no. Els materials tenen un codi intern, que això no us ho haviem dit, però no. Cada secció pot tenir uns materials o uns altres, però els materials que tindrem no depenen de si la secció és un reportatge o una entrevista.
Digues si és certa o falsa la següent afirmació i justifica la teva resposta.: “una de les taules on és més clar que cal un índex és sobre la taula de materials. En concret, l’atribut sobre el que es posaria l’índex és sobre localització”. (1,5 punts)
Segurament és falsa. No s'ha descrit cap procés en què es vulgui obtenir els materials que estan enmagatzemats en una determinada ubicació del magatzem, així que sembla que no té sentit. Segons els processos descrits, no hi hauria d'haver cap altre índex que no fos l'associat a la primary key de la taula.
9.- Quan acabéssiu de dissenyar la base de dades, hauríeu d’escriure un informe al seu futur administrador. Quin seria el seu contingut segons el que heu respost a aquest examen (1 punts. Nota: es valorarà la consistència de la resposta a aquesta pregunta en relació amb les respostes anteriors)
Model conceptual i la seva transformació al model relacional. Script de creació de la base de dades i inserció de les dades estàtiques, si hi hagués. Desnormalitzacions aplicades i justificació de les mateixes. índexos creats, els seus tipus i la política que cal seguir per a regenerar-los, si és necessari. Password d'administrador de la base de dades. Polítiques de recuperació i reconstrucció de la base de dades...
1.- Com traduirieu a una base de dades la classe Data? Es materialitzaria en forma de taula? Quins són els seus efectes en la resta de taules del model? (1 punt)
Es transformaria en una columna de la taula emissions. El tipus d'aquesta columna seria algun dels que ens permet representar una data (long, Date...). Aquesta columna hauria de formar part de la clau primària de la taula emissions.
2.- En quin cas tindria sentit definir un índex sobre l’atribut (columna) data de la classe (taula) emissió? Justifica clarament la resposta (1 punt. Per a la resposta no cal que tingueu el diagrama, penseu en quan val la pena tenir un índex sobre un camp de tipus data)
Tindria sentit en el cas en què les consultes que contiguéssin a la clàusula WHERE condicions de comparació amb una data fossin freqüents. En qualsevol cas, s'hauria de verificar que el temps de la consulta es redueix fent proves de rendiment
3.- Per al cas anterior s’ha decidit posar un índex de tipus hash estàtic. Després d’un any d’ús, intensiu de la base de dades s’ha vist que el rendiment de les consultes ha baixat molt. Quines poden ser les causes? (1 punt)
La causa més habitual és que el Hash hagi degenerat. La solució seria regenerar el hash o canviar el tipus d'índex
4.- Quin seria el millor tipus d’índex que podriem fer per fer consultes sobre el resultat de fer una join? I si volguéssim fer consultes per a un determinat intèrval de valors? (1 punt)
Join -> Índex cluster. Intèrval -> B+
5.- Com recuperaríeu la jerarquia (herència) que s’estableix entre tema i subtema? (1 punt, veieu el model següent)
En realitat, en aquest model no hi ha cap herència, donat que a la taula TEMES no hi ha més atributs a part del seu nom. El que s'estableix és una relació TEMES 1 : N SUBTEMA, que es pot recuperar fent una join per nomTema. En cas que hi hagués més atributs a la taula TEMES (i tinguéssim, per tant, una herència real) s'hauria de recuperar fent servir una left-outer join entre les dos taules
6.- Quin seria el resultat d’aplicar la vostra solució a la pregunta 2 a les taules anteriorment definides per extensió? (1 punt)
El resultat de fer la join.
7.- Hi hauria algun aventatge sobre la solució actual si, enlloc de fer l’herència descrita anteriorment, es desnormalitzèssin les dos taules i quedés només la taula de subtemes? Hi hauria algun inconvenient? Justifica la resposta (1,5 punts)
La desnormalització del model aconseguiria que les consultes anéssin una mica més ràpid, donat que no s'hauria de calcular la join cada cop que es vulguéssin recuperar dades de la taula SUBTEMES. Per contra, no es garantiria la integritat referencial en cas que es permetés introduir manualment el nom del tema quan es vulgués donar d'alta un nou subtema. Donat que no tenim una taula TEMES, les dades dels noms dels temes no podrien ser recuperades d'enlloc, així que no es podria fer servir una solució que mostrés un desplegable (tag select - option de l'HTML) per a evitar el problema anterior. La solució més aventatjosa en aquest cas seria eliminar la foreign key que va de SUBTEMES cap a TEMES, però deixar la taula TEMES. Així, els noms dels temes es podrien recuperar i mostrar com un desplegable (el control de la integritat referencial es passa cap al programa) al formulari que donés d'alta un nou SUBTEMA. En el moment de consultes contra la base de dades, l'SGBD no hauria de calcular la join.
En qualsevol cas, no es recomana desnormalitzar aquestes taules, excepte en sistemes que requereixin un molt alt rendiment.
8.- A partir de la següent text extret de l’examen parcial:
[Friker Jiménez]: Hi ha un tema per cada secció i després un tema general del programa. I a més, per cada secció, hem de guardar el material de suport. És a dir: els vídeos, les fotos, els audios... i on estan a l’arxiu de la casa.
[Consultor Senior]: Vale. Entrem ara més en detall. Dels col·laboradors, quines dades vols guardar?
[Sots-Drectora]: Amb el nom i el número de compte corrent en tenim prou.
[Consultor Júnior]: I dels temes i subtemes i tot això?
[S.D.]: Dels temes el nom i dels subtemes... un nom i una descripció.
[ConsSr]: S’afegeixen molts temes i molts subtemes normalment? Canvien molt?
[S.D.]: Sí, de tant en tant en posem de nous.
[ConsSr]: D’acord. Una última cosa. Depenent del tipus de secció tindreu sempre els mateixos materials?
[F.J.]: Interessant pregunta. Mmmmm... jo diria que no. Els materials tenen un codi intern, que això no us ho haviem dit, però no. Cada secció pot tenir uns materials o uns altres, però els materials que tindrem no depenen de si la secció és un reportatge o una entrevista.
Digues si és certa o falsa la següent afirmació i justifica la teva resposta.: “una de les taules on és més clar que cal un índex és sobre la taula de materials. En concret, l’atribut sobre el que es posaria l’índex és sobre localització”. (1,5 punts)
Segurament és falsa. No s'ha descrit cap procés en què es vulgui obtenir els materials que estan enmagatzemats en una determinada ubicació del magatzem, així que sembla que no té sentit. Segons els processos descrits, no hi hauria d'haver cap altre índex que no fos l'associat a la primary key de la taula.
9.- Quan acabéssiu de dissenyar la base de dades, hauríeu d’escriure un informe al seu futur administrador. Quin seria el seu contingut segons el que heu respost a aquest examen (1 punts. Nota: es valorarà la consistència de la resposta a aquesta pregunta en relació amb les respostes anteriors)
Model conceptual i la seva transformació al model relacional. Script de creació de la base de dades i inserció de les dades estàtiques, si hi hagués. Desnormalitzacions aplicades i justificació de les mateixes. índexos creats, els seus tipus i la política que cal seguir per a regenerar-los, si és necessari. Password d'administrador de la base de dades. Polítiques de recuperació i reconstrucció de la base de dades...
