Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | |||
|
teme:tema_de_casa_3 [2015/12/28 11:53] Andrei Roșu-Cojocaru |
teme:tema_de_casa_3 [2015/12/28 15:36] (current) Andrei Roșu-Cojocaru |
||
|---|---|---|---|
| Line 31: | Line 31: | ||
| Întrucât numărul de înregistrări stocat în baza de date relaţională determină ca timpul de răspuns pentru operaţiile de raportare (ce implică volume mari de date, istorice) să nu respecte constrângerea cu privire la operarea în timp real a unei aplicaţii integrate pentru întreprinderi, la nivelul executiv al unui lanț de restaurante s-a luat decizia migrării spre o soluţie distribuită, pentru care a decis achiziţionarea unui cluster format din maşini larg disponibile în comerț (având un cost redus, fără performanțe deosebite). | Întrucât numărul de înregistrări stocat în baza de date relaţională determină ca timpul de răspuns pentru operaţiile de raportare (ce implică volume mari de date, istorice) să nu respecte constrângerea cu privire la operarea în timp real a unei aplicaţii integrate pentru întreprinderi, la nivelul executiv al unui lanț de restaurante s-a luat decizia migrării spre o soluţie distribuită, pentru care a decis achiziţionarea unui cluster format din maşini larg disponibile în comerț (având un cost redus, fără performanțe deosebite). | ||
| - | Se doreşte monitorizarea activității medicilor care oferă servicii medicale în cadrul lanțului de policlinici în vederea evaluării oportunității continuării colaborării cu aceștia. Criteriile avute în vedere sunt numărul de servicii medicale oferite, numărul de pacienți care apelează la cadrul medical respectiv precum și veniturile încasate pe baza consultațiilor / investigațiilor oferite. Acestea vor fi analizate pe baza rapoartelor medicale completate pentru fiecare programare realizată de un pacient în cadrul unității sanitare. | + | Pentru generarea rapoartelor statistice, în baza de date distribuite vor fi reținute informații istorice cu privire la meniurile disponibile pentru fiecare dată calendaristică, precum și cu privire la comenzile realizate de utilizatori.\\ Astfel, pentru fiecare dată calendaristică se reține meniul, identificat printr-o denumire și o descriere. Un meniu este format din mai multe feluri de mâncare. Un fel de mâncare este caracterizat - pe lângă denumire și descriere - de un tip (aperitiv, fel principal, desert) și de un preț. Un utilizator (identificat în mod unic prin combinația dintre nume și prenume) poate plasa comenzi pentru diferite meniuri. O comandă poate conține unul sau mai multe meniuri (de tipuri diferite), pentru fiecare dintre acestea specificându-se și cantitatea (pentru un meniu de același tip). |
| - | De asemenea, va fi investigat, pentru fiecare specialitate, numărul de medici care activează în cadrul acesteia și sumele de bani pe care le-au generat. | + | Pe baza informațiilor din bazele de date distribuite, se vor genera următoarele rapoarte: |
| - | În acest sens, vor fi generate două rapoarte sub forma unor fişiere text: | + | 1. **un raport cu privire la activitatea utilizatorilor**, astfel încât să se realizeze fidelizarea acestora; pentru fiecare utilizator se va determina valoarea comenzilor înregistrate în sistemul informatic precum și numărul de meniuri achiziționate, indiferent de tipul acestora; rezultatul va fi plasat în cadrul unui fișier din sistemul distribuit de fișiere HDFS: |
| - | * raportul detaliat va surprinde activitatea fiecărui medic pe baza rapoartelor medicale completate de acesta; | + | |
| - | * raportul sintetic va oferi informații cu privire la fiecare specialitate pentru care au fost oferite servicii medicale. | + | |
| - | Un **raport detaliat** conţine numele şi prenumele medicului, numărul de pacienți unici pentru care acesta a completat rapoarte medicale, numărul de servicii medicale distincte oferite în cadrul policlinicii precum și venitul pe care acesta l-a generat, pentru toate consultațiile / investigațiile medicale: | + | <file text raport_utilizatori> |
| - | + | NUME UTILIZATORk, Prenume Utilizatork = valoare_comenzi, numar_meniuri | |
| - | <note>Un pacient va fi luat în considerare o singură dată chiar dacă are mai multe programări la medicul în cauză, respectiv dacă a contractat mai multe servicii medicale realizate de acesta. În cazul în care un pacient se programează pentru servicii medicale la mai mulți medici, el va fi contorizat pentru fiecare dintre aceștia, chiar dacă serviciile medicale sunt identice.</note> | + | |
| - | + | ||
| - | <note>Pentru evaluarea numărului de servicii medicale distincte se vor însuma acele consultații / investigații pentru care există înregistrări în cadrul rapoartelor medicale, nu a tuturor serviciilor medicale corespunzătoare specialităților / competențelor pe care le deține.</note> | + | |
| - | + | ||
| - | <file text raport_detaliat> | + | |
| - | NUME MEDICk Prenume Medick = număr_pacienti, numar_servicii_medicale, venit | + | |
| </file> | </file> | ||
| - | Un **raport sintetic** conţine denumirea fiecărei specialități pentru care au fost oferite servicii medicale în cadrul lanțului de policlinici, numărul de medici care le-au oferit precum și venitul generat. | + | 2. **un raport cu privire la adresabilitatea unui fel de mâncare**, astfel încât pe baza acestora să se creeze meniuri în funcție de cerințele utilizatorilor; pentru fiecare fel de mâncare, se va determina suma generată, pe baza comenzilor; raportul va conține și tipul pentru fiecare fel de mâncare, rezultatul fiind de asemenea plasat în cadrul unui fișier din sistemul distribuit de fișiere HDFS: |
| - | + | ||
| - | <note>În situația în care un medic are mai multe specialități și a oferit servicii medicale unor specialități diferite, el va fi contorizat în cadrul fiecareia dintre acestea. Dacă un medic nu a realizat consultații / investigații pentru nici o specialitate, el nu va fi luat în considerare, deși activează în cadrul lanțului de policlinici.</note> | + | |
| - | <file text raport_sintetic> | + | <file text raport_feluri_de_mancare> |
| - | Specialitatek = număr_medici, venit | + | fel de mancarek, tip fel de mancarek = suma generată |
| </file> | </file> | ||
| Line 67: | Line 57: | ||
| Nu este permisă utilizarea unui obiect de tip [[https://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/Scan.html|org.apache.hadoop.hbase.client.Scan]] decât ca parametru pentru clasele care realizează sarcini de tip MapReduce, întrucât operaţiile realizate de acesta, în contextul unei singure maşini, implică resurse de procesare şi memorie care depreciază timpul de execuţie al unei aplicaţii. | Nu este permisă utilizarea unui obiect de tip [[https://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/Scan.html|org.apache.hadoop.hbase.client.Scan]] decât ca parametru pentru clasele care realizează sarcini de tip MapReduce, întrucât operaţiile realizate de acesta, în contextul unei singure maşini, implică resurse de procesare şi memorie care depreciază timpul de execuţie al unei aplicaţii. | ||
| - | În raport vor fi omise informaţiile nule, în cazul în care .... | + | Într-o anumită dată calendaristică, pot fi definite unul sau mai multe meniuri. Un utilizator nu poate comanda feluri de mâncare individuale, ci numai meniuri. O comandă poate conține numai meniuri din cadrul aceleiași date calendaristice. Coerența informațiilor stocate în baza de date distribuite va fi controlată numai prin intermediul script-ului prin care va fi realizată instalarea tabelelor (creare + populare) și nu va fi verificată în cadrul codului sursă. |
| ===== Barem de corectare și notare ===== | ===== Barem de corectare și notare ===== | ||
| ^ PUNCTAJ ^ CRITERII DE ACORDARE ^ | ^ PUNCTAJ ^ CRITERII DE ACORDARE ^ | ||
| - | | 1,25 p | reproiectarea bazei de date conform modelului distribuit\\ ♦ definirea tabelelor şi a structurii statice: 30%\\ ♦ populare adecvată: 70% | | + | | 3 p | proiectarea bazei de date conform modelului distribuit\\ ♦ definirea tabelelor şi a structurii statice: 30%\\ ♦ populare adecvată: 70% | |
| - | | 3,50 p | generarea rapoartelor\\ ♦ raport detaliat: 50%\\ ♦ raport sintetic: 50% | | + | | 2,50 p | generarea raportului referitor la valoarea totală a comenzilor unui utilizator\\ ♦ generare rezultate intermediare (prima sarcină map-reduce): 70%\\ ♦ generare rezultate finale (a doua sarcină map-reduce): 30% | |
| - | | 0,25 p | modularizare\\ ♦ structura aplicaţiei şi lizibilitatea codului: 50%\\ ♦ comentarii, README: 50% | | + | | 3,50 p | generarea raportului referitor la adresabilitatea unui fel de mâncare\\ ♦ generare rezultate intermediare (prima sarcină map-reduce): 70%\\ ♦ generare rezultate finale (a doua sarcină map-reduce): 30% | |
| + | | 1 p | modularizare\\ ♦ structura aplicaţiei şi lizibilitatea codului: 50%\\ ♦ comentarii, README: 50% | | ||
| **BONUS**. Se pot obţine punctaje suplimentare, astfel: | **BONUS**. Se pot obţine punctaje suplimentare, astfel: | ||
| - | * 0,25p – predarea temei până la 18.01.2016, ora 23:55; | + | * 0,50p – predarea temei până la 18.01.2016, ora 23:55; |
| - | * 0,75p – . | + | * 0,25p – filtrarea rezultatelor (pentru ambele rapoarte) în funcție de un interval de timp, precizat printr-o dată de început sau printr-o dată de sfârșit; datele calendaristice respective pot fi precizate sub formă de constante în codul sursă sau pot fi preluate din linia de comandă; |
| + | * 0,50p - definirea unei sarcini map-reduce distincte, pentru determinarea celui mai profitabil fel de mâncare din fiecare tip, astfel încât pe baza acesteia să se definească meniul care are cea mai mare probabilitate de a genera mai multe vânzări; rezultatul va fi plasat într-un fișier care va conține tipul felului de mâncare precum și felul de mâncare precum și suma generată; | ||
| + | * 0,25p - modificarea rapoartelor, astfel încât rezultatele să fie plasate în cadrul unor tabele dintr-o bază de date distribuită (în loc de fișiere plasate în contextul sistemului distribuit de fișiere HDFS). | ||
| ===== Condiții de realizare și predare ===== | ===== Condiții de realizare și predare ===== | ||
