Progettazione ERP sportivo

di il
6 risposte

Progettazione ERP sportivo

Ho un dubbio. Sto ridisegnando e ampliando il mio gestionale dei miei allenamenti di ciclismo. Finora l'ho sempre usato non in maniera corretta, usando una sola tabella.
Ho l'abitudine di segnare non solo quando esco, ma anche quando non esco. In questo modo alla fine della stagione so quante uscite ho saltato e perché.
Il database è pronto, ma mi è venuto il dubbio che abbia usato un approccio ridondante.
Poiché tutto parte dalla registrazione della singola attività - sia che esca, sia che non esca - ho creato la prima tabella chiamandola Attività con questi campi.

IDUscita
IDNonUscita
IDAttivita (chiave primaria)
Data

A cui seguono le tabelle Uscite(semplifico)

IDUscita (chiave primaria)
IDAttivita
IDTipoAttivita (tutti le eventuali motivazioni per cui posso essere uscito o non uscito)
Giorno
DettaglioGiorno
KmEffettuati
Tempo
...

E la tabella NonUscite

IDNonUscita (chiave primaria)
IDAttivita
IDTipoAttivita
Note

Il dubbio è che potrei fare direttamente così, partendo direttamente dalle tabella Uscite e tabella NonUscite:

Uscite

IDUscita (chiave primaria)
IDAttivita (tutti le eventuali motivazioni per cui posso essere uscito o non uscito)
Data (campo prima assente)
Giorno
DettaglioGiorno
KmEffettuati
Tempo
...

NonUscite

IDNonUscita (chiave primaria)
IDAttivita
Data (campo prima assente)
Note

Attivita
IDUscita
IDNonUscita
IDAttivita (chiave primaria)
TipoAttivita
CategoriaAttivita

In questo modo eliminerei una tabella CategorieAttivita e farei confluire nella tabella Attivita tutti i campi relativi alle attività.

Spero di essere stato chiaro.

6 Risposte

  • Re: Progettazione ERP sportivo

    Le due tabelle "Uscita" e "NonUscita" non hanno senso di esistere. Ne basta una in cui alcuni campi saranno inutili, e un banale flag (KmPercorsi=0 ad esempio) puo' essere usato per separarei due casi.

    Tra l'altro hai anche "Attivita" che potrebbe avere anche l'attivita' "NonUscita" e magari "NonUscitaMalDiPancia", "NonUscitaPiove", "NonUscitaMangiatoPIzza"

    Se non lo hai gia' fatto, in Wikipedia cerca:
    "Teoria Relazionale dei Dati"
    "Forma Normale"
    "Modello E/R"
    "Normalizzazione Database"
  • Re: Progettazione ERP sportivo

    migliorabile ha scritto:


    Le due tabelle "Uscita" e "NonUscita" non hanno senso di esistere. Ne basta una in cui alcuni campi saranno inutili, e un banale flag (KmPercorsi=0 ad esempio) puo' essere usato per separarei due casi.
    Ma così è come ce l'ho adesso.
    Solo che mi sembra un pastrocchio.
  • Re: Progettazione ERP sportivo

    Fabriziog ha scritto:


    Ma così è come ce l'ho adesso.
    Solo che mi sembra un pastrocchio.
    Spiega cosa non ti convince nel concreto.
    Qual è la problematica pratica che riscontri con la tua struttura attuale e che ti ha fatto venire il dubbio?
  • Re: Progettazione ERP sportivo

    Premessa: tutti i software che registrano le attività sportive registrano solo le uscite. Se vuoi sapere quanti giorni hai perso per la pioggia non puoi estrarre i dati. Io registro anche quando non esco. In questo modo in ogni momento so quanti giorni ho saltato e perché.
    Detto ciò, finora ho sempre pensato che il punto di partenza del database fosse la registrazione di un'attività. Nel senso: registro quando esco, registro quando non esco, registro quando compro qualcosa, registro quando faccio manutenzione, eccetera eccetera.
    Partendo da qui ho sempre pensato che la tabella da cui partire fosse quella in cui bisognasse inserire una data. Tabella a cui collegare le altre tramite relazioni e per non creare un elenco del telefono tipo Excel fosse necessario suddividere le informazioni a seconda che registrassi un'uscita, registrassi una mancata uscita e così via.
    Guardando meglio mi è venuto il dubbio che questo mio modo di ragionare risultasse complicato. Forse, anziché partire dalla registrazione che metteva al centro la data, potevo far partire il database dalle categorie delle registrazioni. Un po' come avviene nei gestionali (le fatture hanno un loro percorso, i DDT un altro, gli ordini un altro ancora...).
    E la data, anziché essere unica, essere replicata in ogni tabella relativa al tipo di registrazione da effettuare.
    E la categorizzazione delle attività venisse subito dopo (non so se riesco a spiegarmi) e servisse le due tabelle principali, quella delle uscite e quella delle non uscite. In questo modo potrei riunire nella tabella Attività (in cui sono elencate tutte le attività sportive e non sportive) non solo che uscita ho fatto (allenamento, uscita solitaria, uscita di gruppo, gara...), ma per quale motivo non sono uscito (maltempo, impegni personali, malattia, infortunio...) e aggiungere un campo che specifichi ulteriormente se l'attività è fatta all'aperto o all'interno, per esempio i rulli o seduta di palestra.
  • Re: Progettazione ERP sportivo

    Fabriziog ha scritto:


    Premessa: tutti i software che registrano le attività sportive registrano solo le uscite.
    Questo credo sia ovvio: in genere, sono quelle le attività che si vogliono tracciare.

    E' come avere un registro degli eventi e salvare al suo interno "quando non succede nulla": sarebbe un agglomerato enorme di dati, di cui sarebbe difficile definire una granularità ideale, che fornirebbero informazioni sostanzialmente inutili, poiché a tutti interessa avere evidenza di qualcosa che succede, non di qualcosa che non succede.

    Diverso è invece dire "avrebbe dovuto succedere", poiché in quel caso si registra il fallimento di un evento che avrebbe dovuto avere luogo, che è un esempio che si può utilizzare anche nel tuo caso.

    Fabriziog ha scritto:


    Io registro anche quando non esco. In questo modo in ogni momento so quanti giorni ho saltato e perché.
    Mi sembra limitativo. Se si presuppone che si esca una volta al giorno, ti basta scandire le attività effettivamente eseguite per conoscere in pochissimi istanti quanti giorni hai saltato, senza andare singolarmente a salvarti per ogni giorno il fatto che non hai eseguito l'attività.

    E' più corretto non salvare questa impostazione: in questo modo, se cambi al volo la frequenza passando da una attività al giorno a due attività, ottieni in un secondo il calcolo aggiornato, che non sarebbe invece possibile se tu ti basassi solo sui record che hai inserito.

    Fabriziog ha scritto:


    Detto ciò, finora ho sempre pensato che il punto di partenza del database fosse la registrazione di un'attività.
    E fin qui non ci vedrei nulla di male, anzi direi che è un buon punto di partenza: la fattorizzazione deve seguire dopo quando vedi che, aggiungendo informazioni o tipologiche, è necessario normalizzare la base dati perché ti rendi conto che stai ridondando troppi dati (es. ripetendo più volte un campo "Tipo attività" che potrebbe essere censito in un'altra tabella e collegato alla tabella principale delle "Attività" tramite un ID).

    Fabriziog ha scritto:


    Partendo da qui ho sempre pensato che la tabella da cui partire fosse quella in cui bisognasse inserire una data. Tabella a cui collegare le altre tramite relazioni e per non creare un elenco del telefono tipo Excel fosse necessario suddividere le informazioni a seconda che registrassi un'uscita, registrassi una mancata uscita e così via.
    Questa commistione di riflessioni su ciò che devi memorizzare in generale e come i dati sono strutturati va eliminata: sono due contesti completamente separati, poiché il salvataggio di una attività con tutti i suoi dati annessi è l'inserimento di uno o più record aggregati che vanno distribuiti sulla base dati per evitare ridondanza.

    La base dati non cambia in base al punto di partenza o in base a ciò che consideri "principale" o "secondario", ma dipende solo da quali e quanti dati salvi, quanto vengono ripetuti (da cui si rende necessaria una normalizzazione) e dalle relazioni che esistono tra gli stessi (se stiamo parlando di RDBMS).

    Fabriziog ha scritto:


    Guardando meglio mi è venuto il dubbio che questo mio modo di ragionare risultasse complicato.
    Cosa c'entra il modo di ragionare? La base dati va progettata per bilanciare il recupero ottimale delle informazioni che servono al software evitando il più possibile ridondanza dei dati (o permetterla dove serve per questioni di performance).

    La complessità del ragionamento non c'entra nulla.

    Fabriziog ha scritto:


    Forse, anziché partire dalla registrazione che metteva al centro la data, potevo far partire il database dalle categorie delle registrazioni.
    Come predetto, non c'è un "mettere al centro" né un inizio o una fine.

    Banalmente, il discorso da fare è questo: se le attività che fai possono appartenere a diverse categorie, e ha senso distinguerle, avrai una tabella "Categorie" che le elenca tutte, ciascuna con un proprio ID identificativo, e nella tabella "Attività" avrai un campo "CategoriaID" che referenzia la categoria a cui appartiene quella attività, in modo da evitare ridondanza di dati (la ripetizione delle informazioni sulle categorie, come la descrizione) e l'eventuale possibilità di scegliere in seguito una categoria per filtrare tutte le attività che appartengono a quel tipo.

    Fabriziog ha scritto:


    Un po' come avviene nei gestionali (le fatture hanno un loro percorso, i DDT un altro, gli ordini un altro ancora...).
    Sbagli. Molti gestionali hanno una tabella unica per tutti i documenti, e una tabella per le righe dei documenti, a prescindere dalla loro tipologia, e tutt'al più possiedono un campo sulla tabella principale dei documenti che definisce la tipologia di appartenenza dello stesso documento (es. DDT, fattura, ordine, ecc.) che potrebbe essere un tipo descrittivo composto da un codice (es. DT, FT, OR) o da un ID di una tabella tipologica correlata.

    In genere è così, a prescindere dalla tipologia, perché spesso i documenti hanno caratteristiche in comune ed è inoltre più facile in questo modo generare l'uno a partire dall'altro, copiando banalmente i dati del record di testata e dei record delle relative righe.

    Fabriziog ha scritto:


    E la data, anziché essere unica, essere replicata in ogni tabella relativa al tipo di registrazione da effettuare.
    Non ne vedo il motivo pratico.

    Fabriziog ha scritto:


    E la categorizzazione delle attività venisse subito dopo (non so se riesco a spiegarmi) [...]
    Direi di no, perché secondo me c'è molta confusione riguardo a cosa si intende per "normalizzazione di un DB".
    Prima di procedere, darei uno sguardo alle risorse che ti sono state suggerite per approfondire questo argomento perché avviare un progetto basato su una struttura dati non ottimizzata o difficile da manutenere costituisce un ostacolo al buon fine di qualsiasi implementazione.

    Ciao!
  • Re: Progettazione ERP sportivo

    Allora il dubbio non ha ragione di essere, perché il database va bene così com'è. Ho già messo in pratica i tuoi suggerimenti.
Devi accedere o registrarti per scrivere nel forum
6 risposte