Problema dopo il collasso verso il basso

di il
5 risposte

Problema dopo il collasso verso il basso

Ciao a tutti,
ho un problema derivante da un collasso verso il basso.

Vi spiego:

Avevo una gerarchia di nome Fornitore, che si divedeva in Grossista e Privato.
Dato che un collasso verso l'alto avrebbe comportato troppi campi facoltativi (In caso il fornitore fosse stato un grossista, avrei avuto un record con 6 campi vuoti) e dato che c'era un'associazione che collegava solo Grossista a un'altra entità, ho preferito optare per il collasso verso il basso.

Il problema è che, ad esempio, Fornitore era collegato ad "Acquisto". Dopo il collasso ho dovuto quindi collegare sia Privato che Grossista ad "Acquisto".
Quindi ora, nella tabella "Acquisto", mi ritrovo sia "codiceGrossista" che "codicePrivato".
Ovviamente, quando aggiungo un record a "Acquisto" non posso riempire sia "CodiceGrossista" che "CodicePrivato", in quanto la presenza di uno esclude quella dell'altro.

C'è un modo per impedirlo in SQL?
Se sì, il controllo va fatto durante la INSERT INTO, o durante la CREATE TABLE?

Oppure, dato che i dati da inserire mi vengono dati dall'utente, è un controllo che può essere fatto solo ed unicamente dall'applicazione?

Vi ringrazio in anticipo per le risposte.

5 Risposte

  • Re: Problema dopo il collasso verso il basso

    Io non so cosa sia il "collasso" verso il basso o alto.
    Potresti elencare i campi di tutte le tue tabelle e relative relazioni?
  • Re: Problema dopo il collasso verso il basso

    Collasso verso il basso vuol dire che si parte da una cosa del genere:



    Dovendolo trasformare in tabelle, invece di fare una tabella "Dipendente" che ha sia i campi di "Impiegato" che i campi di "Dirigente" , si splitta facendo invece due tabelle (Impiegato e Dirigente), che ereditano i campi di "Dipendente"


    Nel mio caso è venuta fuori una roba del genere:
    GROSSISTA(codFornitore, P.IVA, ragioneSociale, telefono, sede....)
    PRIVATO(codFornitore, codiceFiscale, nome, cognome, telefono, indirizzo)

    ACQUISTO(codiceAcquisto, data, importo, codGrossista[0/1]: GROSSISTA, codPrivato[0/1]: PRIVATO)

    (Ho rinominato le chiavi esterne in codGrossista e codPrivato, perchè lasciare cosFornitore sarebbe stato ambiguo)
    Con [0/1] intendo che quel campo è falcoltativo, quindi può essere NULL.

    In un acquisto devo indicare il fornitore. Se questo è un grossista devo riempire il campo "codGrossista" e lasciare NULL il campo "codPrivato", altrimenti devo fare viceversa.

    La mia domanda è: In CREATE TABLE, o da qualche altra parte, posso mettere questo vincolo?

    Oppure è una cosa che non può essere fatta tramite l'SQL e sarà l'applicazione a fare questo controllo?

    PS: Qui spiega i collassi:
  • Re: Problema dopo il collasso verso il basso

    Hobbyte ha scritto:


    Dovendolo trasformare in tabelle, invece di fare una tabella "Dipendente" che ha sia i campi di "Impiegato" che i campi di "Dirigente" , si splitta facendo invece due tabelle (Impiegato e Dirigente), che ereditano i campi di "Dipendente"
    No. Dirigenti, Impiegati, Dipendenti sono tutti Persone con medesimi campi Cognome, Nome, Indirizzo ecc...altri campi tipicamente anagrafici. Potresti aggiungere un campo di discriminazione in cui specifichi che si tratta di Dirigente, Impiegato, Dipendente.

    Hobbyte ha scritto:


    Nel mio caso è venuta fuori una roba del genere:
    GROSSISTA(codFornitore, P.IVA, ragioneSociale, telefono, sede....)
    PRIVATO(codFornitore, codiceFiscale, nome, cognome, telefono, indirizzo)
    Idem. I campi sono simili/uguali. Grossisti e Privati possono stare in un'unica tabella.

    Direi che per "fare" quello che avresti pensato, dovresti servirti di opportune query che filtrano secondo quelle "qualifiche", quindi puoi lavorare con esse.
  • Re: Problema dopo il collasso verso il basso

    1) si chiama modello E/R (Entita'/Relazione): cerca della documentazione, ne trovi quanta ne vuoi. Preferisci quella messa a disposizione dalle universita (sono usate per i corsi)
    2) tra piu' possibili soluzioni scegli SEMPRE quella piu' semplice
    3) EVITA come la peste campi multipli per rappresentare lo stesso tipo di informazione: usare 'codGrossista' e 'codPrivato' nella stessa tabella e' ASSOLUTAMENTE sbagliato
    4) cerca documentazione su 'modello relazionale dei dati'

    E' ragionevole avere due tabelle, una per le aziende ed una per le persone fisiche: in questo caso, come eccezione alla regola, nulla ti vieta avere una persona che fa da fornitore/grossista inserita in entrambe le tabelle, perche' anche se e' la stessa persona, viene interpretata come due entita' con caratteristiche diverse

    Il termine 'colasso' (corrispondente a 'collapse') e' usato in modo collocquiale, ma avresti dovuto scrivere e' qualcosa del genere:

    'come trasformare una gerarchia del modello E/R nel modello Relazionale'
  • Re: Problema dopo il collasso verso il basso

    Solo una precisazione: il termine "collasso" si usa tutti i giorni, nelle università (e imprese) italiane.

    Sul resto francamente faccio fatica a capire (iniziando da 6 campi vuoti, ma che ti frega?).
    Neppure questa frase la capisco "Quindi ora, nella tabella "Acquisto", mi ritrovo sia "codiceGrossista" che "codicePrivato" (anche perchè è priva di logica)

    Infine non ti consiglio di usare identificativi maiuscoli e minuscolo: in certi casi (esempio: mysql) può funzionare oppure no a seconda del sistema operativo che utilizzi (Windows-Linux-altro).

    Quindi rilassati, lascia stare le sciocchezze-ungheresi (inutili pure per i programmi, figuriamoci per SQL), metti tutto in minuscolo e buonanotte.
Devi accedere o registrarti per scrivere nel forum
5 risposte