Piccolo progetto di studio - Intranet aziendale

di il
11 risposte

Piccolo progetto di studio - Intranet aziendale

Buongiorno a tutti,
premetto che sono nuovo nella progettazione software e sto cercando di sbrogliare un problema di progettazione del database per me nuovo.
Ho delle entità quali:

Nazioni
Città
Sedi
Uffici
Progetti
Task
Persone


Vorrei astrarre queste entità a una classe generica chiamata Oggetti in quanto vorrei, con una certa flessibilità, applicare delle funzionalità quali Community, Condivisione Documenti, Messaggistica ed altro, senza doverle riprogrammarle per ognuno di essi.

Vorrei proporre una relazione Molti a Molti tra ognuno di questi oggetti (laddove non sia consigliato vorrei inibirlo a livello di codice).

Ognuno di questi oggetti ha naturalmente degli attributi completamente diversi.

Pensavo di fare una tabella Oggetti con il solo ID e ENTITA, mentre le altre Entità avrebbero una chiave esterna che riprende l'oggetto. In seguito, il resto delle tabelle riguardanti le funzionalità aggiuntive, le legherei con una chiave esterna sull'oggetto e non sulla singola entità.

Ho qualche dubbio sull'associazione molti a molti tra gli oggetti in quanto richiederebbe il traversing con parecchie funzioni ricorsive. Ho sentito parlare della struttura Closure Table per gestire gerarchie multi padre ma non trovo molta documentazione o informazioni sulla reale efficacia.

Sono sulla buona strada? avete qualcosa da consigliarmi?

11 Risposte

  • Re: Piccolo progetto di studio - Intranet aziendale

    Ma stai parlando di database o di modellazione ad oggetti?
    I due mondi non sono incompatibili, ma nemmeno anime gemelle.

    In generale conviene modellare i dati nel modo piu' naturale per il database, perche' e' l'oggetto meno flessibile, e l'algebra relazionale (su cui i db relazionali sono basati) ha le sue regole.

    C'e' una soluzione alternativa, ovviamente: l'utilizzo di database NON RELAZIONALI.
    Ad esempio i database ad oggetti, che si sposano 1:1 con un modello ad oggetti del problema.
    Oppure i database basati sul concetto di documento (gerarchico) XML o JSON.

    Fanno tutti parte di una nuova categoria di database detti NONSQL

    Su wikipedia trovi un po' di documentazione
  • Re: Piccolo progetto di studio - Intranet aziendale

    Sto parlando di modellazione del database, il principale dubbio è sulla creazione delle gerarchie ... se usare una relazione molti a molti o una closure table o qualche altra tecnica che mi sfugge.
    Ho già uno schema relazionale e un diagramma ER .. Magari faccio una scansione e li condivido.

    Grazie mille
  • Re: Piccolo progetto di studio - Intranet aziendale

    Nel diagramma ho chiamato gli Oggetti , Elementi
    Naturalmente gli attributi non sono completi, mi spiace se non ho utilizzato l'annotazione standard per il diagramma..

    https://www.dropbox.com/s/e2d67vf0ylvo95c/S22BW-414030710550.pdf
  • Re: Piccolo progetto di studio - Intranet aziendale

    Ciao,

    non mi e' chiaro tra quali entita' vorresti creare la relazione molti a molti.
  • Re: Piccolo progetto di studio - Intranet aziendale

    Self Reference su Elementi, per creare una gerarchia di tutte le entità collegate
  • Re: Piccolo progetto di studio - Intranet aziendale

    Giusto per capire,

    tu hai le seguenti entita :
    Nazioni
    Città
    Sedi
    .....

    e vuoi "astrarle" in una entita chiamata OGGETTI

    In Oggetti hai (Id, Entita)
    e nelle altre entita sovra citate una foreign key all'entita oggetti.

    Detto cio qual'e il problema?
  • Re: Piccolo progetto di studio - Intranet aziendale

    Il problema è che non so se usare una relazione molti a molti o se sarebbe meglio usare una closure table, sulla quale trovo molta teoria ma pochi casi pratici

    Inoltre mi chiedevo se il metodo di "Astrazione" valido per la modellazione ad oggetti (class table inheritance), l'ho applicato in maniera corretta anche a livello di database.
    Lo chiedo in quanto di solito ho usato strutture statiche, dove ogni entità si relazionava direttamente ad un' altra senza nessun tipo di astrazione.
    Questa volta volevo creare una struttura dinamica in grado di farmi aggiungere nuove entità derivanti da Oggetti/Elementi in grado di utilizzare il resto delle funzionalità del software

    Grazie mille per l'aiuto
  • Re: Piccolo progetto di studio - Intranet aziendale

    Non capisco perche parli di molti a molti...

    nella tabella Oggetti avresti qualcosa del tipo:

    id , Entita
    1 , nazione
    2 , citta
    3 , sedi

    Invece, ad esempio nella Tabella Nazione avresti(dati...., 1) dove 1 rappresenta il riferimento (la foreign key) alla tabella Oggetti.

    dunque , la relazione che si forma sara 1:N in quanto, ad esempio una nazione avra un solo riferimento in oggetto mentre oggetto potra avere piu nazioni.
  • Re: Piccolo progetto di studio - Intranet aziendale

    In realtà la tabella Elementi conterrà qualcosa tipo:
    ID, Tipo
    1, Nazione
    2, Nazione
    3, Citta
    4, Sede
    5, Nazione
    6, Persona

    La tabella Nazioni invece potrebbe essere del tipo (il campo ID è sia PK che FK verso il campo ID di Elementi
    ID, Nome
    1, Italia
    2, Spagna
    5, Francia

    Idem per la tabella Persona
    ID, Nome, Cognome, etc..etc...
    6, Paolo, Rossi


    In questo modo potrei relazionare Elementi con altri Elementi per creare la gerarchia.
  • Re: Piccolo progetto di studio - Intranet aziendale

    Mettendo nella tabella elementi 2 volte Nazione non ottieni nulla.

    Piuttosto nella tabella elementi io metterei 'Italia','spagna','francia'... ed eventualmente anche il riferimento alla tabella Nazione
  • Re: Piccolo progetto di studio - Intranet aziendale

    Però sarei in grado di aprire l'id corretto del record nella tabella nazione, no ?
    L'id 5 del record in Elementi corrisponde all'id 5 nel record Nazioni. in questo modo riesco a mantenere l'univocità. Evidentemente gli Id del record nazioni non sarebbe un autoincrementale ma direttamente la chiave esterna verso Elementi.
    In altre parole a livello di codice, instanziando un oggetto di tipo Elemento, utilizzerei un Factory per restituirmi l'oggetto corretto del tipo Nazione o Sede o Persona etc etc... Il tutto vincolato dall'attributo tipo nella tabella Elementi.
Devi accedere o registrarti per scrivere nel forum
11 risposte