• Non ci sono risultati.

3. Progettazione e sviluppo di Arpus

3.3 Progettazione e struttura del database Arpus

3.3.2 Fase di ristrutturazione

Lo schema prodotto durante la fase di progettazione concettuale necessita di una revisione in modo che il progetto venga semplificato e ottimizzato.

In questa fase andremo ad analizzare lo schema concettuale prodotto e a effettuare passo per passo, le eventuali modifiche [30].

La ristrutturazione di un modello concettuale prevede le seguenti fasi:

1. Analisi delle ridondanze.

2. Eliminazione delle gerarchie: nel modello relazionale non vengono rappresentate le gerarchie, che quindi vanno sostituite con entità, associazioni ed eventuali attributi.

3. Partizionamento/accorpamento di entità e associazioni.

4. Scelta degli identificatori principali: per le entità che ne hanno più di uno.

1. Analisi delle ridondanze:

in questa fase viene controllata la presenza di dati non necessari che possono essere derivati da altri. Tali dati possono essere attributi ricavabili da altre entità, da altri attributi o dal conteggio di occorrenze, oppure possono risultare ridondanti associazioni derivabili dalla composizione di altre in presenza di cicli.

All’interno dello schema concettuale prodotto non sono stati rinvenuti attributi ridondanti e quindi da eliminare.

2. Eliminazione delle gerarchie:

Come possiamo vedere dalla Figura 1, l’entità docente, ramifica in due entità deboli: indicizzato e non indicizzato. Quest’ultima non è essenziale al fine di rappresentare la realtà di interesse e quindi può essere eliminata; l’entità indicizzato invece, può essere sostituita da un attributo identificativo scopus all’interno di

Otteniamo così la semplificazione visibile all’interno della figura 2.

Figura 1 entità DOCENTE non semplificata

Dalla figura 3 possiamo analizzare un’altra gerarchia:

La gerarchia può essere semplificata, come possiamo vedere nella figura 4, eliminando le entità deboli che corrispondono alle tre fasce (FASCIA COMMISSARI, PRIMA

FASCIA e SECONDA FASCIA) e aggiungendo gli attributi di queste ultime all’entità

padre.

Figura 3

Analogamente alla figura 3 – 4, la gerarchia della figura 5 può essere eliminata, attribuendo gli attributi delle entità deboli, all’entità padre (vedi figura 6).

Figura 4 semplificazione dell’entità della Figura 3

Riguardo ai restanti punti per la ristrutturazione dello schema concettuale, ovvero: 3. Partizionamento/accorpamento di entità e associazioni

4. Scelta degli identificatori principali: per le entità che ne hanno più di uno.

Non sono state accorpate o partizionate entità e associazioni rispetto allo schema originale, mentre è stato scelto l’attributo ‘matricola’ per identificare tutti i docenti, anche quelli che possiedono un identificativo Scopus.

Lo schema ristrutturato può essere quindi tradotto nella seguente maniera, illustrando i vincoli di integrità referenziale che intercorrono tra le varie entità:

DOCENTE(matricola, scopus id*, e-mail,dipartimento,settore)

PUBBLICAZIONE ARPI (handle, eid, matricola, data, tipologia) matricola → DOCENTE(matricola)

eid → PUBBLICAZIONE SCOPUS(eid)

PUBBLICAZIONE SCOPUS (eid, autore, data, rivista, co-autori) autore → DOCENTE(scopus id)

QUARTILE(rivista, anno, categoria) rivista→ PUBBLICAZIONE SCOPUS

GRUPPO DI INDICATORI(autore, h-indexFC, h-indexF1, h-indexFC, numero articoli FC, numero articoli F1, numero articoli F2, numero di citazioni FC, numero di citazioni F1, numero di citazioni F2)

autore → DOCENTE (scopus id)

SOGLIE SSD (ssd, soglia h-indexFC, soglia h-indexF1, soglia h-indexFC, soglia numero articoli FC ,soglia numero articoli F1, soglia numero articoli F2, soglia numero di citazioni FC, soglia numero di citazioni F1, soglia numero di citazioni F2)

CONFRONTO SOGLIE(ssd , autore, soglie superate, soglie non superate) ssd → SOGLIE(ssd)

autore →GRUPPO DI INDICATORI (autore)

Il database utilizzato all’interno del progetto è costituito dalle seguenti tabelle:

• docenti

Contiene l’elenco dei docenti dell’ateneo, scopus id, e-mail, dipartimento, settore, consenso al trattamento dati, servizio di aggiornamento tramite e-mail. Da questo database vengono prelevati gli scopus id per l’aggiornamento della tabella pubb.

L’aggiornamento di questo elenco non avviene in maniera automatica, ma tramite il caricamento di un file CSV scaricato da Arpi e caricato da un utente amministratore, attraverso l’apposita sezione nella pagina ‘DATI AGGREGATI’.

• pubb

Contiene tutte le pubblicazioni dei docenti indicizzati su Scopus e i relativi metadati ( i principali sono: anno di pubblicazione, co-autori, rivista dove è stata pubblicata, eid della pubblicazione, issn, numero complessivo di autori, tipo di pubblicazione).

• estrazioni

Al suo interno viene registrata la data in cui è stato aggiornato il database delle pubblicazioni. Questa data viene visualizzata anche sopra la tabella delle pubblicazioni dei singoli docenti.

• handle

La tabella contiene gli Handle Arpi delle pubblicazioni, anno e tipo di pubblicazione e la matricola dell’autore.

I Dati vengono incrociati con quelli contenuti in pubb, per calcolare gli indicatori ASN Arpi e confrontare i dati Scopus con quelli Arpi, andando a vedere se esistono pubblicazioni in Scopus non pubblicate su Arpi e viceversa.

• indicatori

Contiene gli indicatori ASN calcolati con i dati delle pubblicazioni Scopus e con quelli di Arpi.

Inizialmente non era prevista nel progetto una tabella, ma gli indicatori venivano calcolati dinamicamente al momento del caricamento della pagina. Questo aveva dei vantaggi per quanto riguarda la Privacy (non conservare in un database i dati di tutti i docenti), ma rallentava il caricamento della pagina MEDIANE, in cui vengono mostrati gli indicatori di coloro che hanno acconsentito al trattamento dei propri dati.

soglie

Contiene le soglie per ciascun settore scientifico disciplinare per gli indicatori ASN.

• soglieSuperate

al suo interno vengono registrati i docenti e il suepramento (o meno) delle soglie per i concorsi per commissari, prima e seconda fascia.

• scimago

Dati estratti dallo Scimago Journal & Country Rank [28].

I dati sono stati scaricati in formato CSV, anno per anno e modificati in maniera tale da renderli idonei per gli scopi prefissati: in ciascun file contenente una

classifica delle riviste su base annuale, è stato inserito l’attributo Year, in maniera tale da poter riconoscere l’anno una volta importati in phpmyadmin all’interno della tabella Scimago.

La tabella è utilizzata all’interno dell’applicazione per calcolare il numero di pubblicazioni dei docenti classificate come Q1, incrociando i dati di Scopus con questi ultimi; sono stati utilizzati inoltre per mostrare nella tabella delle pubblicazioni, le categorie per cui tale rivista è stata classificata come Q1.

• Quartile

In questa tabella sono riportati i dati estratti da Scimago incrociati con la tabella

pubb grazie al codice issn delle riviste; i dati contenuti sono: eid, rivista, anno e

quartile.

sottoinsieme

La tabella viene riempita con i dati nel momento in cui viene si vuole utilizzare

il software con un sottoinsieme dei docenti. É possibile infatti caricare un file contenente un insieme ridotto di docenti dell’Università dalla pagina Home. I dati visualizzati nelle pagine infatti, non faranno più riferimento alla tabella

docenti, ma a quest’ultima, visualizzando così grafici, tabelle e informazioni su

3.5 Struttura del Software

Documenti correlati