[Disseny de bases de dades] PAC 1: Model E-R, model relacional i disseny físic de base de dades

DISSENY DE BASES DE DADES

Prova Teòrica d’Avaluació Continuada- PAC1

Jordi Llonch Esteve CC BY-NC-SA 1 de 18

Nom i cognoms: Jordi Llonch Esteve

• Cada resposta s'escriurà sota el seu enunciat.

• Renombra aquest arxiu amb el teu nom complet:

PAC1_ nom_alumne.doc

• A lliurar a la bústia "Lliurament d'activitats" de l'espai d’avaluació" de l'aula. Data límit de lliurament: 26 de març del 2012

Presentació i objectius. L'objectiu d'aquesta activitat és aprendre a realitzar un disseny conceptual, relacional i físic d'una base de dades, i reflexionar sobre els conceptes teòrics més importants relacionats amb aquests processos.

L'activitat es divideix en quatre parts:

A.- Treballar un diagrama E-R que reflecteixi les expectatives d'un enunciat.

B1.- Disseny d’un model E-R, relacionat amb el model realitzat a l’apartat A.

B2.- Transformació d’un subconjunt del model E-R en model relacional.

B3- Disseny físic de la base de dades.




A.- Treballar un diagrama E-R que reflecteixi les expectatives d'un enunciat.

Escull UNA de les següents 4 opcions (A, B, C o D) i presenta un model E-R que reflecteixi les expectatives de l’enunciat escollit.

1- Identifica al document les entitats presents, les seves relacions i cardinalitats. 2- Expressa breument els arguments per a la teva decisió relacionant-los amb

referències a l’enunciat.

3- Dissenya un diagrama E-R que il·lustri els conceptes i les funcionalitats de la base de dades.

EXEMPLE: Es vol crear una pàgina online de noticies per a difondre les noticies més rellevants de successos nacionals i internacionals. Les noticies es podran guardar sota un conjunt de categories donades, tals com “educació”, “política”, “economia”, “societat”. Per permetre als lectors una informació més catalogada, hi podrà haver subcategories, tals com “universitats”, “escoles bressol” i “recerca” dins de la categoria “educació”.

Les noticies presentades al portal online, podran ser votades pels lectors, de manera que les notícies més votades podran aparèixer a la portada principal del lloc web. Hi ha dos tipus de votacions, les positives i les negatives. Des del punt de vista de qui fa les votacions, també hi ha dues classificacions: votacions d’usuaris anònims, i votacions d’usuaris registrats. Per tal de poder calcular el valor final de la noticia, les votacions positives sumen +1 si l’usuari és anònim, i +2 si és registrat. De la mateixa manera, resten -1 si la votació és anònima negativa i -2 si és d’un usuari registrat. A part de contribuir a la valoració d’una noticia, de cada votació no anònima es vol emmagatzemar qui l’ha fet i quin ha estat el valor de la votació.

Els usuaris, a més de votar les noticies, en cas d’estar registrats poden comentar-la, de manera que es pugui crear una discussió sobre la noticia i poder aportar-li més informació en cas de que els usuaris ho creguin necessari. Per tal de que els comentaris segueixin unes pràctiques de tolerància, només els usuaris registrats poden crear comentaris a les noticies. Els comentaris, així com les noticies, poden tenir vots positius i vots negatius, però només d’altres usuaris registrats.

Si es donés el cas de que un usuari obtingues puntuacions negatives a molts dels seus comentaris, s’estudiarà el bloqueig del seu compte. L’acció de bloqueig de comptes només la podran realitzar els usuaris administradors. És a dir, dins del grup d’usuaris que poden comentar noticies, existeixen els usuaris registrats normals, i els usuaris administradors.

El portal, com es comentava al principi, té com objectiu la difusió de noticies, i és per això que el portal no té el contingut de les noticies, sinó que enllacen a la noticia original, ja sigui d’un Bloc, d’un diari online o d’una entitat pública, tal com seccions del BOE.




OPCIÓ A: GESTIÓ DE SINISTRES DE ROBATORI

Una companyia d’assegurances de la llar amplia les seves cobertures per incloure-hi “robatoris”. Per tal d’avaluar quines són les despeses que genera el nou producte (en pagaments a les víctimes) vol generar una aplicació on es reportin els robatoris generats i els valors dels productes robats. D’altra banda, la companya preveu treure en un futur un servei de vigilància i seguretat, pel que vol ampliar la informació dels robatoris amb detalls sobre com s’ha generat l’ esdeveniment.

L’aplicació haurà de disposar d’informació de la zona on s’ha registrat el robatori: lloc exacte (amb longitud i latitud), ciutat, barri, carrer, etc., així com poder diferenciar si el robatori s’ha registrat a una planta baixa, a alçada de carrer, o a un pis. Aquesta informació es farà servir per esbrinar si hi ha zones més perilloses que d’altres.

És important saber si l’entrada pel robatori s’ha perpetrat per una porta principal, una secundaria, una finestra, etc. També és rellevant disposar d’informació sobre si la entrada s’ha realitzat forçant (la porta o finestra), trencant, obrint o per un altre mecanisme. També s’haurà de notificar quina ha estat la via de sortida dels lladres, per saber si hi ha més d’una zona que caldria tenir vigilància.

Hi haurà més informació que estarà relacionada amb evidències del robatori, tals com empremtes digitals, petjades, calaixos oberts, etc. de manera que es puguin estudiar patrons de comportament dels lladres.

Sobre els productes robats, caldrà disposar informació sobre el tipus de producte, marca i model. Hi ha models que tenen variants diferents, com per exemple els colors d’un rellotge, corretges de rellotges, materials, etc. Per tant, s’haurà d’emmagatzemar aquesta informació si fos necessari. Per ampliar la informació, la víctima podrà donar una descripció de l’article robat, ja que podria ser que tingués un gravat, o similars. Per poder calcular el cost del robatori, s’haurà de registrat valor inicial de compra del producte, així com el valor actual del producte al mercat. A més, l’assegurat haurà de donar el valor per el qual desitja ser recompensat per a cada producte. Per exemple, un rellotge Lotus X231 de color negre “que tenia un gravat que deia: Sempre t’estimaré” es podria haver comprat per un valor equivalent a 60 € fa 15 anys, tenir un valor actual al mercat de 130€, però que l’assegurat desitgi recuperar 45€ per la seva pèrdua.

Finalment, com a requeriment d’última hora, s’ha demanat que es registri quan s’ha realitzat el robatori (l’hora del robatori i d’altre informació més genèrica - si s’ha realitzat durant el matí, tarda, nit, en període de vacances... -) i sota quines condicions climatològiques (sent un dia de sol, plujós, ennuvolat, ...). Aquesta informació podria ajudar en un futur a valorar si les zones més perilloses podrien disposar d’un servei de vigilància, i durant quines temporades i hores haurien de ser més freqüents els guàrdies.




OPCIÓ B: GESTIÓ D’ESDEVENIMENTS AL MWC

Després d'assistir al Mobile World Congress i a un munt de trobades de desenvolupadors, un grup d'ells, pertanyents a diferents comunitats mínimament organitzades, han decidit ajuntar-se per a crear una aplicació que els permeti unir-se a l'hora de planificar esdeveniments, xerrades o maratons de programació (conegudes com a hackatons). El fet de que durant aquests quatre dies s'hagin realitzat un gran nombre de quedades crea la necessitat de distribuir-les eficientment per tal d'aconseguir que hi assisteixi el nombre més gran de gent possible.

El que es vol aconseguir amb aquesta aplicació és que no coincideixin trobades i així permetre a un mateix desenvolupador, poder moure's ràpidament d'una a l'altra en cas que dos o més coincideixin en el mateix dia o saber quines es realitzen al mateix edifici, etc... Per a això caldrà guardar la localització (amb longitud i latitud) del lloc on es realitzi cada esdeveniment, a quin pavelló es fa, així com l'hora i el dia en que es realitza, i quina és la comunitat que l'organitza (com ara poden ser CatDroid, Appcelerator Barcelona, etc...).

Per tal de que els assistents puguin tenir informació sobre les comunitats que organitzen les reunions es vol guardar algunes dades de cada comunitat, com són el seu nom, el nom i cognoms del seu responsable, la localització de la seva seu (amb longitud i latitud), i els entorns i plataformes amb els que treballa. Un exemple d'això seria: la comunitat d'Appcelerator treballa amb l'aplicació Titanium i genera aplicacions per a les plataformes Android i iOS. Un altre exemple d'això seria: la comunitat de desenvolupadors d'aplicacions per Android treballa amb entorns de desenvolupament com ara Eclipse, Titanium, etc... Cal tenir en compte que les comunitats poden ser part d’altres comunitats més grans, per exemple la comunitat catalana de desenvolupadors de Ruby On Rails podria ser una branca de la comunitat espanyola de Ruby on Rails. L'objectiu de les quedades pot ser molt divers, així doncs una comunitat pot planificar un dia una xerrada de presentació d'aplicacions i un altre dia una marató de codificació. S'haurà de poder veure quins esdeveniments hi ha en un mateix dia i on es realitzen.

Per tal de controlar l’assistència als esdeveniments es vol enregistrar les persones que han assistit a cada esdeveniment, emmagatzemant per cadascuna d’elles: el seu nom, el seu correu electrònic, l’empresa a on treballa i amb quin càrrec, i les comunitats a on pertany.

D'altra banda, un dels avantatges de generar una comunitat és que les empreses que produeixen eines per a desenvolupar hi confien i les patrocinen. Òbviament és una estratègia de marketing, però sovint es creen dinàmiques que permeten a les comunitats una millor organització, oferir uns continguts més interessants en les seves quedades o fins i tot repartir premis. Per tal de tenir controlat les empreses que han donat suport als esdeveniments es vol saber quines empreses han patrocinat esdeveniments, i per cadascuna d’elles, l’esdeveniment que han patrocinat, els entorns pels que treballen (Android, iOS,...), la seva persona de contacte, i la quantitat del seu patrocini.




OPCIÓ C: GESTIÓ DE CALENDARIS AL MWC

Aprofitant el Mobile World Congress una petita empresa vol donar una empenta al seu negoci i està concertant una sèrie de reunions amb contactes de diferents empreses que hi seran presents. El problema és que els comercials de l'empresa i els directius que assisteixen al congrés tenen molt poc temps per trobar-se amb una gran quantitat de gent i necessiten organitzar-se de forma eficient.

Per aquest motiu han demanat al departament d'informàtica que els desenvolupi una petita aplicació que els permeti veure, en un calendari, les diferents reunions que tenen previstes. L’aplicació haurà de permetre accedir ràpidament a les cites, de manera que els comercials puguin veure amb quines persones han de trobar-se, de quina empresa, i en quin pavelló i stand. Amb aquestes dades, i per organitzar millor les cites, es podrà veure, per exemple, quines empreses estan en el mateix pavelló per tal de repartir-se les cites més eficaçment, evitant que un mateix empleat hagi d'anar de punta a punta del recinte innecessariament.

Per a fer útil l'aplicació es vol mantenir, per cada companyia amb la que es concerten reunions, el nom de l'empresa, el de la persona de contacte, juntament amb el seu càrrec, correu electrònic i telèfon del contacte. De la companyia també volem emmagatzemar el telèfon principal, la seva adreça física, i una breu descripció del que fa i perquè és interessant per l’empresa, con ara per exemple “Són una plataforma de pagament a través de codis QR”.

A més serà necessari guardar d'alguna manera el pavelló i estand on s’exposen, tot i que s'ha de tenir en compte que algunes d'elles, per ser prou importants, es troben repartides en diferents pavellons. Per cada estand es vol emmagatzemar la seva localització (via latitud i longitud), els metres quadrats, l’empresa que el té llogat i el pavelló on es troba. La base de dades també haurà d’emmagatzemar el temps necessari per anar d’un estand a un altre.

Cada cita doncs, haurà de guardar informació del pavelló i estand on es realitzarà, quin dia i a quina hora, quin(s) empleat(s) han d'assistir i, per descomptat, amb quina empresa ens hem de reunir i qui es la nostra persona de contacte.

Cada usuari de l'aplicació haurà de poder veure la fitxa dels seus companys (i la seva pròpia) on s'indicarà el nom i cognoms, càrrec dins l'empresa, correu electrònic i telèfon i, un llistat de les cites a les que ha d'assistir. També volem que l’aplicació tingui en compte, per cada treballador, quins col·legues els poden substituir. Aquesta informació serà molt útil en cas de que un dels treballadors no pugui assistir a una reunió, facilitant trobar un substitut per la mateixa.

Finalment, per portar un control de les diferents persones amb qui s’han trobat, quines d’elles són potencialment rellevants pel negoci i les idees que s’han treballat, l’aplicació haurà de permetre que els treballadors creïn un fitxa on puguin dir, per cada reunió i persona que ha assistit, els temes rellevants de feina que s’han tractat i si té sentit contactar amb aquella persona en un futur o no.




OPCIÓ D:

En Pere, dietista de professió i informàtic d’afició s’ha proposat fer una aplicació web per donar suport a la gent a l’hora d’escollir la dieta que millor s’adiu a les seves necessitats i a realitzar-ne el seguiment.

L’aplicació web permetrà que els usuaris creïn el seu perfil d’accés, donant el nom, adreça, direcció de correu electrònic i clau d’accés. Els usuaris podran escollir quin tipus de dieta volen seguir. Inicialment, en Pere té pensades els següents tipus de dieta: diabètic, sobrepès, problemes_colesterol, musculatura, problemes_ronyó.

Un cop escollida la tipologia de la dieta, els usuaris podran veure diferents plats que s’aconsellen pel seu tipus de dieta. Per cada plat es mostraran fotos, un petit text que descriu com preparar-lo, les seves virtuts i els ingredients que el composen. D’altra banda, la web ha de donar informació sobre els ingredients aconsellables per cada tipus de dieta i els ingredients que cal evitar. Així doncs, per una dieta de tipus “problemes_colesterol” s’aconsellarà peix blau i verdures i es desaconsellarà el llom de porc, el xai... A continuació es mostren alguns exemples de dietes i ingredients aconsellats:

Diabetes – fruites, verdures, llobarro, bledes, mongeta tendra, espinac, ous, vedella, porc.

Sobrepes – verdures, poma, pera, kiwi, maduixa, taronja, peix, pollastre, vedella.

Problemes de Colesterol – sardina, verdures, llet descremada, formatge descremat, oli d’oliva, pollastre.

Musculatura – vedella, pollastre, ous, complement dietètics, pasta, arròs, plàtans, raïm, meló, figues.

Problemes de ronyó – fruites, verdures, truita de riu, ous, pollastre.

Per a portar un seguiment dels plats menjats, i ajudar a tenir un menú variat, el lloc web permetrà als usuaris registrar els plats que ha menjat cada dia i a cada àpat (esmorzar, dinar, berenar, sopar, snack). Aquí un exemple: Usuari: Pere Perez

(Musculatura)

Pollastre Dinar 2012-03-01 14.00

Llenties Sopar 2012-03-01 21.00

Ous Sopar 2012-03-01 21.00

Per tal d’obtenir finançament i facilitar el sortir a menjar fora als usuaris, en Pere ha contactat amb diferents restaurants i en fa promoció en la seva pàgina web. La informació que es té en compte de cada restaurant és: la seva localització (via latitud i longitud), la ciutat on està, el tipus de dieta pel que s’aconsella, i els plats que ofereix. L’aplicació també vol treure profit de la filosofia 2.0, i permet que els usuaris comparteixin opinions sobre els plats i els restaurants. Els usuaris podran posar un comentari per a plats que hagin menjat o per a restaurants on hagin estat, donant una petita ressenya i una valoració de 0 a 5 estrelles.




Entitats, relacions i cardinalitats presents a l’opció D. Usuari: relacionat amb Dieta (n:1), amb Registre (1:n), amb Plat (n:1 de grau 3) i amb Restaurant (n:1 de grau 3). Dieta: relacionat amb Usuari (1:n), amb Plat (1:n), amb Restaurant (1:n) i amb ingredient (n:n). Registre: relacionat amb Usuari (n:1) i amb Plat (n:n). Plat: relacionat amb Dieta (n:1), amb Restaurant (n:n), amb Ingredient (n:n), amb Registre (n:n) i amb Usuari (1:n de grau 3). Restaurant: relacionat amb Usuari (1:n de grau 3), amb Dieta (n:1) i amb Plat (n:n) Expressa aquí breument els arguments per a la teva decisió relacionant-los amb referències a l’enunciat i amb les entitats i relacions a presentar al model E-R. Usuari està relacionat amb Dieta perquè segons l’enunciat: “Els usuaris podran escollir quin tipus de dieta volen seguir.”

Usuari està relacionat amb Registre perquè segons l’enunciat: “L’aplicació web permetrà que els usuaris creïn el seu perfil d’accés...”

Usuari està relacionat amb Plat perquè segons l’enunciat: “el lloc web permetrà als usuaris registrar els plats que ha menjat...” i “L’aplicació [...] permet que els usuaris comparteixin opinions sobre els plats...”

Usuari està relacionat amb Restaurant perquè segons l’enunciat: “L’aplicació [...] permet que els usuaris comparteixin opinions sobre els plats i els restaurants.”

Dieta està relacionat amb Plat perquè segons l’enunciat: “...els usuaris podran veure diferents plats que s’aconsellen pel seu tipus de dieta.”

Dieta està relacionat amb Restaurant perquè segons l’enunciat: “La informació que es té en compte de cada restaurant és: [...] el tipus de dieta pel que s’aconsella...”

Dieta està relacionat amb Ingredients perquè segons l’enunciat: “la web ha de donar informació sobre els ingredients aconsellables per cada tipus de dieta i els ingredients que cal evitar.”

Registre està relacionat amb Usuari perquè segons l’enunciat: “L’aplicació web permetrà que els usuaris creïn el seu perfil d’accés...”

Registre està relacionat amb Plat perquè segons l’enunciat: “el lloc web permetrà als usuaris registrar els plats que ha menjat cada dia i a cada àpat (esmorzar, dinar, berenar, sopar, snack).”

Plat està relacionat amb Ingredient perquè segons l’enunciat: “...la web ha de donar informació sobre els ingredients aconsellables per cada tipus de dieta i els ingredients que cal evitar.”

Plat està relacionat amb Restaurant perquè segons l’enunciat: “La informació que es té en compte de cada restaurant és: [...] el tipus de dieta pel que s’aconsella i els plats que ofereix.”




Posa aquí la teva solució gràfica detallada del model E-R elegit:

(utilitza alguna eina de disseny, com Omnigraffle, inserció de Formes a Microsoft Word, MySQL WorkBench)

Accedeix al diagrama amb més qualitat a https://www.lucidchart.com/documents/view/46e8-db10-4f59db59-8a93-014c0a443d8b

https://www.lucidchart.com/documents/view/46e8-db10-4f59db59-8a93-014c0a443d8b

https://www.lucidchart.com/documents/view/46e8-db10-4f59db59-8a93-014c0a443d8b




B1.- Disseny conceptual de la base de dades (Model E-R).

El tema de la base de dades és de lliure elecció, però estarà relacionat amb la temàtica de l’exercici anterior. Cal tenir en compte el patró de l'enunciat i els seus paràmetres bàsics com a objectius obligatoris, ja que estarà orientada de cara al desenvolupament de l'aplicació final amb la PRA2.

1- El model base ha d'encaixar amb el patró que es presenta a la següent imatge: quatre entitats (A, B, C, D), tres relacions (R1, R2, R3), dos tipus de correspondències (N : N i N : 1). Encara que no estiguin mostrades en la imatge, recorda que el model E-R ha de presentar els atributs simples, compostos, multivalorats, derivats i de clau.

2- L'entitat principal serà A i descriurà un objecte de l’exercici anterior que pugui ser georeferenciat en un mapa mitjançant la seva latitud i longitud. Així doncs, podrà ser el lloc d’un robatori, la seu d’un esdeveniment, un estand o un restaurant en funció si heu triat l’opció A, B, C o D en l’exercici anterior. Més endavant, en la PRA2, la informació de la base de dades serà posicionada a Google Maps.

3- La resta d’entitats (B, C i D) les podreu treure de la solució de l’exercici anterior o us les podeu inventar. No obstant, hauran d’estar relacionades amb l’enunciat de l’exercici que hagueu triat (robatoris, esdeveniments, reunions o dietes).

4- El disseny lògic de la base de dades ha de tenir els següents paràmetres obligatoris.

• Cada entitat haurà de tenir un mínim de 3 atributs (incloent l'atribut subratllat per indicar l'atribut de clau).

• Els atributs seran simples i compostos0F

1. No s'haurà d'incloure atributs que actuen com a claus externes (aquesta característica es resoldrà en la següent part de l'exercici amb el Model relacional).

1 Els atributs compostos són els atributs que es poden dividir en subparts (és a dir, en altres atributs). Per exemple, nom-alumne podria estar estructurat com un atribut compost consistent en nom, primer cognom i segon cognom. No confonguis aquest concepte d'atribut compost amb el d'atribut multivalorat.

D




• Una de les entitats tindrà a més un atribut descriptiu de valor únic (unique key), restricció que indica que no hi pot haver dos valors iguals. Nota: Observa les diferencies entre atribut de clau i atribut de valor únic

• Una de les entitats tindrà un atribut derivat 1F

2, el valor es podrà fer derivar dels valors d'altres atributs d'aquesta o de les altres dues entitats relacionades.

• Una de les quatre entitats tindrà un atribut multivalorat, és a dir un atribut que podrà contenir valors múltiples2F

3.

Posa aquí la teva solució gràfica detallada del model E-R dissenyat:

(utilitza alguna eina de disseny, com Omnigraffle, inserció de Formes a Microsoft Word, MySQL WorkBench)

Accedeix al diagrama amb més qualitat a https://www.lucidchart.com/documents/view/47e7-bff0-4f5dca3a-9a61-72d10a443d8b

2 Un atribut derivat és aquell que no està explícitament emmagatzemat perquè pot ser calculat a partir dels valors d'altres atributs. Per exemple, un empleat podria tenir com a atributs data-començament i antiguitat, que representen el primer dia en què l'empleat va començar a treballar i el temps total que l'empleat porta treballant. El valor d'antiguitat es pot derivar del valor de data de començament i de la data actual. 3 Al manual de l'assignatura es diu clarament que en el model relacional no es permeten atributs compostos o de valors múltiples, però els diagrames E-R estan destinats per a ús humà i aquestes característiques addicionals permeten captar més el significat de l'aplicació. Per exemple, un client podria tenir més d'un telèfon emmagatzemat; un altre exemple, el color d'un peix pot estar compost per una sèrie de colors diferents (vermell, blanc, blau). Per tant, un atribut de valors múltiples ha de donar cabuda a una o més característiques d'un conjunt de valors.

https://www.lucidchart.com/documents/view/47e7-bff0-4f5dca3a-9a61-72d10a443d8b

https://www.lucidchart.com/documents/view/47e7-bff0-4f5dca3a-9a61-72d10a443d8b




Completa a manera de redacció els següents apartats descriptius amb la informació de la teva base de dades.

a) Nom de la base de dades: “DBDietes”

b) Omple les caselles buides de la taula amb la informació que falta:

Entitats Nom Funció3F

4 Atributs4F

5

A Restaurant Lloc on es pot anar a dinar i sopar

id: atribut de clau.

latitud i longitud: coordenades geogràfiques.

adreça: atribut compost (carrer i número)

obertura: data en que s’inaugura el restaurant.

temps obert: atribut derivat (data actual – obertura).

B Plat Plat que es pot triar per menjar id: atribut de clau.

nom: atribut descriptiu de valor únic.

foto: imatge del plat.

preparació: indicacions pas a pas per preparar el plat en un document de text.

C Dieta Tipus de dieta ofert id: atribut de clau.

tipus: atribut multivalorat que inclou els tipus de dietes.

D Taula Taules disponibles a cada restaurant

id: atribut de clau.

persones: número de persones que poden seure a la taula.

número taula: número de la taula.

Relacions

R1 ofereix Quins plats ofereix cada restaurant.

id restaurant

id plat

R2 pertany A quina dieta pertany cada plat. id plat

id dieta

R3 conté Quantes taules té cada restaurant.

id restaurant

id taula

4 Explica breument la funció de l'entitat o la relació (segons sigui el cas) en el model de dades. 5 Subratlla l'atribut de clau. Llista els noms dels altres atributs amb una breu explicació sobre el seu significat. Recorda no incloure atributs que actuen de clau externa.




c) Explica el valor funcional dels atributs de clau:

Serveixen per evitar que hi hagi dos registres amb el mateix identificador.

d) Explica la funció i l'aplicació de l'atribut de valor únic (unique key) que has triat:

L’atribut descriptiu de valor únic escollit es troba dins de l’entitat “Plat” i s’anomena “nom”. És el nom del plat, per la qual cosa, serà impossible que hi hagi dos plats iguals. En l’hipotètic cas que això passés, estaríem davant del mateix plat.

e) Explica la funció i com s'obtindrà l'atribut derivat:

Ja que un atribut derivat és un valor obtingut a partir d’altres atributs o entitats relacionades, el meu atribut derivat “temps en marxa” s’obtindrà de restar la data de posada en marxa a la data actual.

f) Explica la funció i l'aplicació de l'atribut multivalorat:

Les dietes es dividiran en funció del seu tipus, ja siguin per a diabètics, per a persones amb sobrepès, amb problemes de colesterol, amb problemes de ronyó o per fomentar la musculatura.

g) Explica com funcionen les tres relacions del teu model 5F

6, és a dir, les correspondències entre entitats:

R1: Cada restaurant pot oferir una sèrie de plats diferents. Per això la relació és n:n.

R2: Cada dieta està formada per un conjunt de plats, però aquests plats no poden compartir dietes. Per això la relació és n:1.

R3: Cada restaurant pot tenir un número indefinit de taules. Per això la relació és n:n.

B2.- Transformació del model E-R en Model Relacional.

Transforma el model E-R de la teva base de dades en un Model Relacional tenint en compte els següents paràmetres obligatoris.

• Cada entitat tindrà la seva pròpia taula. La primera columna de cada taula serà per a l'atribut de la clau primària. Anomena aquesta columna ID (identificador o codi de

6 El tipus d'una relació és el nombre d'entitats participants. Per exemple, una relació binària és aquella en la qual intervenen dues entitats. La major part de les relacions trobades en aplicacions de bases de dades són binàries, és a dir de grau dos, però ocasionalment es pot trobar una relació de grau superior. Una relació ternària és de grau tres i intervenen tres entitats




tupla) i posa-hi, sempre que sigui possible (si et convé), valors numèrics amb auto-increment (1,2,3,…n).

• Totes les claus externes es posaran a l'última columna de les taules dependents en cas necessari. Sempre que sigui possible, anomena aquesta columna amb la següent nomenclatura: ID_[nom de la taula pare].

• Posa a l'encapçalament de la columna de l'atribut derivat el seu nom, seguit de la fórmula literal de càlcul; sota, en cada fila, els valors del resultat d'aquest càlcul.

• Els valors de l'atribut de valors múltiples se separarà amb comes.

• Les relacions amb correspondència N:N també hauran de tenir la seva pròpia taula, amb la seva clau primària en la primera columna (si cal) i les claus externes en les següents columnes, per enllaçar les tuples de les entitats involucrades. Aquest tipus d'entitat de relació també podria arribar a tenir els seus propis atributs.

• Posa, com a mínim, deu registres de dades a les taules d'entitats i vuit en les relacions.

Exemple de taula:

TAULA “AULES Grau Multimèdia” ID NOM ESPAIS NOMBRE ALUMNES

compta alumnes matriculats per aula i assignatura

ID_ASSIGNATURA

1 Disseny de Bases de Dades tauler, fòrum 60 1

2 Arquitectura tauler, fòrum, debat 20 6

3 Interfícies per a sistemes multimèdia

tauler, fòrum, debat 50 5

4 Uso de Bases de Datos tauler, fòrum 55 1

TAULA “RESTAURANT”

ID LATITUD LONGITUD NOM ADREÇA OBERTURA

TEMPS OBERT

1 41.30496 2.00563 Major 36 Major, 36 03/07/85 -

2 41.30475 2.00437 Les Brases Sant Pere, 24 30/07/86 -

3 41.30632 2.00628 La Taberna de la Rambla Rambla de Maria Casas, 86 14/02/90

4 41.30544 2.00760 Miguel Rojo Bernabeu Rambla de Joaquim Vayreda, 52 22/02/84

5 41.30631 2.00457 Los Soprano Salvador Lluch, 30 29/06/01

6 41.30735 2.00573 Racó d’en Madu Concòrdia, 39 27/12/92

7 41.30810 2.00189 Jardín de Oro Sant Nicasi, 88 13/03/04

8 41.30103 2.00579 Martí Vallribera Santa Creu de Calafell, 96 18/09/80

9 41.30090 1.99972 Dinapoli2 Joanot Martorell, 33 30/01/09

10 41.29931 1.98132 Masia Can Llonch Sentiu, SN 21/11/03




TAULA “PLAT” ID NOM FOTO PREPARACIÓ ID_DIETA

1 Arròs amb xampinyons Arròs xampinyons.jpg Arròs xampinyons.txt 1

2 Gaspatxo Gaspatxo.jpg Gaspatxo.txt 1

3 Lluç amb patates Lluç patates.jpg Lluç patates.txt 2

4 Amanida verda Amanida verda.jpg Amanida verda.txt 2

5 Crepes sense colesterol Crepes sense colesterol.jpg

Crepes sense colesterol.txt 3

6 Croquetes d’arròs Croquetes arròs.jpg Croquetes arròs.txt 3

7 Conill a la brasa amb seques Conill brasa.jpg Conill brasa.txt 4

8 Cabrit a la brasa amb patates Cabrit brasa.jpg Cabrit brasa.txt 4

9 Sopa d’api Sopa api.jpg Sopa api.txt 5

10 Suc de fruites Suc fruites.jpg Suc fruites.txt 5

TAULA “TAULA” ID PERSONES NÚMERO-TAULA

1 4 12

2 3 1

3 6 4

4 12 2

5 2 5

6 1 9

7 5 2

8 23 8

9 5 10

10 4 16

TAULA “R1” ID_R1 ID_RESTAURANT ID_PLAT

1 10 7

2 5 4

3 6 6

4 2 3

5 8 9

6 9 1

7 1 8

8 3 6

TAULA “R3” ID_R3 ID_RESTAURANT ID_TAULA

1 4 1

2 3 5

3 7 4

4 10 9

5 3 8

6 2 10

7 5 4

8 4 9




B3.- Disseny físic de la base de dades.

Per dur a terme el disseny físic de la base de dades serà necessari saber administrar el servidor MySQL amb els seus programes clients (mysql.exe, MySQLWorkbench, phpMyAdmin, etc.). Per posar en marxa la teva base de dades hauràs de completar els punts que es descriuen a continuació (enganxa les sentències SQL sota els seus respectius apartats en format text).

• Crea la base de dades relacional en el teu sistema local donant suport a taules transaccionals del tipus InnoDB i al conjunt de caràcters amb UTF-8.

• Resol la integritat referencial de les relacions existents entre les taules, enllaçant les claus foranes amb la restricció CASCADE per l'esborrat i actualització de la taula pare.

• Defineix a la taula escollida la restricció de l'atribut de valor únic.

• Recorda que no cal definir explícitament la columna de l'atribut derivat perquè aquest podrà ser calculat amb una sentència SQL a partir dels valors d'altres atributs o fins i tot amb alguna funció de MySQL.

Completa els següents apartats amb les sentències SQL (còpia i enganxa les definicions LDD de les taules que has creat amb MySQL).

a) Posa la sentència SQL de creació de la base de dades:

CREATE SCHEMA IF NOT EXISTS `DBDietes` DEFAULT CHARACTER SET utf8 ; USE `DBDietes` ;

b) LDD Taula entitat A:

CREATE TABLE IF NOT EXISTS `DBDietes`.`restaurant` ( ìdrestaurant` INT NOT NULL , `latitud` DECIMAL(6) NULL , `longitud` DECIMAL(6) NULL , `nom` VARCHAR(45) NULL , àdreça` VARCHAR(45) NULL , òbertura` DATE NULL , `temps-obert` DATE NULL , PRIMARY KEY (ìdrestaurant`) ) ENGINE = InnoDB;

c) LDD Taula entitat B:

CREATE TABLE IF NOT EXISTS `DBDietes`.`plat` ( ìdplat` INT NOT NULL , `nom` VARCHAR(45) NULL , `foto` VARCHAR(45) NULL , `preparació` VARCHAR(45) NULL , PRIMARY KEY (ìdplat`) , UNIQUE INDEX `nom_UNIQUE` (`nom` ASC) ) ENGINE = InnoDB;




d) LDD Taula entitat C:

CREATE TABLE IF NOT EXISTS `DBDietes`.`dieta` ( ìddieta` INT NOT NULL , `tipus` VARCHAR(45) NULL , PRIMARY KEY (ìddieta`) ) ENGINE = InnoDB;

e) LDD Taula entitat D:

CREATE TABLE IF NOT EXISTS `DBDietes`.`taula` ( ìdtaula` INT NOT NULL , `persones` VARCHAR(45) NULL , `número-taula` INT NULL , PRIMARY KEY (ìdtaula`) ) ENGINE = InnoDB;

f) LDD Taula relació R1:

CREATE TABLE IF NOT EXISTS `DBDietes`.`R1` ( `restaurant_idrestaurant` INT NOT NULL , `plat_idplat` INT NOT NULL , PRIMARY KEY (`restaurant_idrestaurant`, `plat_idplat`) , INDEX `fk_restaurant_has_plat_plat1` (`plat_idplat` ASC) , INDEX `fk_restaurant_has_plat_restaurant` (`restaurant_idrestaurant` ASC) , CONSTRAINT `fk_restaurant_has_plat_restaurant` FOREIGN KEY (`restaurant_idrestaurant` ) REFERENCES `DBDietes`.`restaurant` (ìdrestaurant` ) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT `fk_restaurant_has_plat_plat1` FOREIGN KEY (`plat_idplat` ) REFERENCES `DBDietes`.`plat` (ìdplat` ) ON DELETE CASCADE ON UPDATE CASCADE) ENGINE = InnoDB COMMENT = 'ofereix';

g) LDD Taula relació R3:

CREATE TABLE IF NOT EXISTS `DBDietes`.`R3` ( `restaurant_idrestaurant` INT NOT NULL , `taula_idtaula` INT NOT NULL , PRIMARY KEY (`restaurant_idrestaurant`, `taula_idtaula`) , INDEX `fk_restaurant_has_taula_taula1` (`taula_idtaula` ASC) , INDEX `fk_restaurant_has_taula_restaurant1` (`restaurant_idrestaurant` ASC) , CONSTRAINT `fk_restaurant_has_taula_restaurant1` FOREIGN KEY (`restaurant_idrestaurant` ) REFERENCES `DBDietes`.`restaurant` (ìdrestaurant` ) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT `fk_restaurant_has_taula_taula1` FOREIGN KEY (`taula_idtaula` ) REFERENCES `DBDietes`.`taula` (ìdtaula` ) ON DELETE NO ACTION ON UPDATE NO ACTION) ENGINE = InnoDB COMMENT = 'conté';




Introdueix dades en les diferents taules i a continuació resol els següents exercicis enganxant les corresponents sentències SQL.

h) Posa aquí la inserció d'un nou registre seguint el patró INSERT INTO taula VALUES (...):

insert into DBDietes.taula values (null,‘4’,‘12’) ;

i) Posa aquí la inserció d'un nou registre seguint el patró INSERT INTO taula (lista de columnas) VALUES (llista de valors):

insert into DBDietes.taula (id_taula,‘persones’,‘número-taula’)vàlues(null,’4’,‘12’) ;

j) Modifica el registre d'una taula amb la sentència UPDATE SET … WHERE …

update plat set nom =‘Gaspatxo’ where nom =‘Gaspacho’;

k) Escriu una sentència SELECT que mostri informació de l'atribut derivat. Utilitza un àlies de columna per assignar un nom a la fórmula del càlcul a la taula de resultats:

select a.restaurant from DBDietes.restaurant a;

select a.longitud,concat(a.latitud,a.longitud) restaurant from DBDietes.restaurant a;

l) Escriu una sentència SELECT que mostri informació de les taules A i B després de unir-les mitjançant R1:

select r.latitud, r.longitud, r.nom, r.adreça, r.obertura, r.temps-obert, p.nom, p.foto, p.preparació, from DBDietes.restaurant r, DBDietes.plat p, DBDietes.relacio1 r1 where p.id_plat = r1.id_plat and r.id_restaurant = r1.id_restaurant order by r.titol;

Finalment fes una copia de seguretat (backup) de la teva base de dades. Anomena a aquest arxiu nom_db.sql i lliura'l amb la solució d'aquest exercici a la bústia "Lliurament d'activitats"

[Disseny de bases de dades] PAC 1: Model E-R, model relacional i disseny físic de base de dades

Documents

Transcript of [Disseny de bases de dades] PAC 1: Model E-R, model relacional i disseny físic de base de dades