Integrità referenziale

di il
25 risposte

25 Risposte - Pagina 2

  • Re: Integrità referenziale

    30/06/2023 - zoro82 ha scritto:


    Perdonatemi ma sto cercando di capire bene. Se voi siete già edotti mi dispiace che stiate buttando del tempo. Se però dovete percularmi meglio che non rispondete.

    Quello che chiedevo io non erano delle “regole per mettere l'integrità referenziale”. Ma degli esempi(appunto…non regole) in cui non era strettamente necessario usarla. Ho capito che le regole le devo stabilire io in progettazione…ma queste regole le devo stabilire con criterio.  

    Quello che faccio fatica a capire è l'espressione “ Non è complicato: hai una relazione che può non essere attivata per qualsiasi ragione che vuoi. E la stessa relazione può essere legata da integrità”

    Per me non ha senso avere una relazione e non attivarla….se c'è per me ha senso attivarla e garantire, a prescindere, che i dati siano integri sia in fase di inserimento che di aggiornamento o cancellazione. Quindi sarebbe più comodo/corretto metterla sempre e non lasciarla alla discrezionalita'  (progettuale) di una persona. Non trovo nessuna utilità pratica nell'avere, in una tabella, il cliente 46 che però non esiste nella corrispettiva anagrafica. 

    Ma che diciiiii????

    Con il sorriso abbiamo fatto degli esempi molto banali di come trattare le relazioni in funzione delle necessità del progetto 

    Come hai appena detto devi stabilire delle regole

    E sai che le regole son fatte per essere rispettate

    Access offre dei possibili schemi che puoi adottare e se sei rigido ad essi al 99% non hai problemi. 

    Puoi crearti delle regole personalizzate e che escono dalla normalizzazione. In questo caso ti sostituisci ad access e sarai tu in prima persona a validarle ogni volta che necessita

    Poi c’è chi non ne tiene conto di talune regole e il Db non sta in piedi

    Ecco, basta evitare questo… ma per capire meglio se e come fare e quali risultati ottieni e per essere sicuro di aver applicato o creato delle regole correttamente, fai delle simulazione e vedi se il risultato sarà quello da te desiderato. 

    Il sistema non è rigido ma consiglia di fare alcune cose in certi modi. Vedi la documentazione che abbiamo sopra citato della Microsoft  

    Se una chiave è facoltativa saranno ammessi i valori null e i valori chiave valide… questa è una possibilità 

    Se una chiave non deve ammettere valori null è richiesto il campo obbligatorio e il valore consentito deve essere una chiave valida, cioè esistente e questa è un altra possibilità che si ha  

    Nel secondo caso il sistema non ti permette di aggiornare o inserire record e lo fa in automatico  

    Mentre nel primo caso il sistema non è tenuto a controllare e/o impedire l’aggiornamento o l’inserimento di un record 

    Un altra possibilità è quella che garantisce di non eliminare una chiave che è stata utilizzata in relazione con altre tabelle e questo il sistema lo fa automaticamente perché hai referenziato  

    Come hai visto hai la possibilità di garantire l’integrità oppure no , ma come si diceva, dipende dalle regole che vai ad adottare   

    Ma tornando alla pizza e ai suoi ingredienti puoi decidere liberamente di adottare un criterio piuttosto che un altro, la cosa importante che il prodotto finito risulti così come lo vuoi  

  • Re: Integrità referenziale

    30/06/2023 - zoro82 ha scritto:


    Perdonatemi ma sto cercando di capire bene. Se voi siete già edotti mi dispiace che stiate buttando del tempo. Se però dovete percularmi meglio che non rispondete.

    Quello che chiedevo io non erano delle “regole per mettere l'integrità referenziale”. Ma degli esempi(appunto…non regole) in cui non era strettamente necessario usarla. Ho capito che le regole le devo stabilire io in progettazione…ma queste regole le devo stabilire con criterio.  

    Quello che faccio fatica a capire è l'espressione “ Non è complicato: hai una relazione che può non essere attivata per qualsiasi ragione che vuoi. E la stessa relazione può essere legata da integrità”

    Per me non ha senso avere una relazione e non attivarla….se c'è per me ha senso attivarla e garantire, a prescindere, che i dati siano integri sia in fase di inserimento che di aggiornamento o cancellazione. Quindi sarebbe più comodo/corretto metterla sempre e non lasciarla alla discrezionalita'  (progettuale) di una persona. Non trovo nessuna utilità pratica nell'avere, in una tabella, il cliente 46 che però non esiste nella corrispettiva anagrafica. 

    Nessuno sta prendendo in giro…

    Hai chiesto la differenza tra una relazione semplice ed una referenziata e ti è stata spiegata.

    In ogni caso, puoi lasciare in bianco il campo relazionato (forse il termine non attivare ti ha spiazzato). La relazione non si ativa ne tanto meno si dichiara. Se su due tabelle hai due campi della stessa natura e dimensione (esempio tabellaa campo1 striga 10 e tabellab campo5 stringa 10) puoi metterle in relazione. Se invece imposti (in questo caso lo dichiari) una integrita, allora prima di scrivere un valore sul campo devi accertarti che sull'altra tabella il campo relazionato abbia quello stesso valore.

    Seconda richiesta: devo mettere integrità?

    Nel tuo caso (comanda o ordine) no. Suppongo che col cartaceo appena consegni il prodotto butti via l'appunto della comanda. Quindi puoi benissimo cancellare l'ordine (fai spazio al db).

    Se, tuttavia, usi l'integrità, puoi crearti il cliente generico. 

    Dall'analisi del tipo di modus operandi del settore potresti semplicemente inserire un campo note o contatto dove inserirai il nominativo di chi ti sta facendo l'ordine ed un recapito, senza necessariamente passare da tabelle figlie.

    Non trovo nessuna utilità pratica nell'avere, in una tabella, il cliente 46 che però non esiste nella corrispettiva anagrafica

    No, se inserisci un valore significa che esiste anche nella figlia. La differenza sta proprio li, con l'integrità lasci che sia il db ad avvisarti che non esiste il cliente 46, senza integrità resta solo un valore lasciato li orfano ma se inserisci in un secondo momento un cliente 46, interrogando il db, ti viene fuori che quell'ordine lo ha fatto caio e non cesare com'era inizialmente…

    L'integrità ti avvisa che oltre al cliente devi eliminare anche l'ordine (non viceversa perche si parla di 1 a molti).

    Meglio di così non so spiegartelo. Ma nessuno sta deridendo. Ci siamo passati tutti.

  • Re: Integrità referenziale

    30/06/2023 - sihsandrea ha scritto:


    Dall'analisi del tipo di modus operandi del settore potresti semplicemente inserire un campo note o contatto dove inserirai il nominativo di chi ti sta facendo l'ordine ed un recapito, senza necessariamente passare da tabelle figlie.

    Per l'asporto anche una Data e Ora di consegna ?
    Poi potrebbe essere carino attingere dalle Mappe e calcolarsi la Distanza e i Tempi di Percorrenza

    Dato il tempo di Percorrenza sottratto dall'Ora di Consegna (volendo anche dal Tempo di Preparazione del Prodotto), 
    si calcola in automatico l'Ora di Preparazione.

    Questo consente di dare un tempo certo di consegna al Cliente e/o comunque avere  una sequenza temòporale di preparazione delle varie comande.


    Riflettevo sulla Tracciabilità e Ritracciabilità che avevi accennato nel post precedente.

    Poniamo che sti' Capperi che adoro… abbiano creato un problema a qualche Cliente … a questo punto, per come sopra esposto e come accennavi, risali automaticamente quando, dove, a chi e a quale ora, questo ingrediente è stato preparato e consegnato ai vari clienti.
    A questo punto sulla base della ritracciabilità sei in grado di emanare l'allerta tramite numero telefonico
    E con la tracciabilità sei in grado di risalire al lotto utilizzato per la preparazione

    Insomma, 'na cosa del genere.  ;)


    Detto questo e se è verosimile, il progetto dovrà tenere conto di tali aspetti e si dovrà condizionare e stabilire delle regole ferree che richiederanno di avere delle relazioni obbligatorie oppure no.

    Ovviamente solo un esempio   ;))

  • Re: Integrità referenziale

    30/06/2023 - By65Franco ha scritto:


    30/06/2023 - sihsandrea ha scritto:


    Dall'analisi del tipo di modus operandi del settore potresti semplicemente inserire un campo note o contatto dove inserirai il nominativo di chi ti sta facendo l'ordine ed un recapito, senza necessariamente passare da tabelle figlie.

    Per l'asporto anche una Data e Ora di consegna ?
    Poi potrebbe essere carino attingere dalle Mappe e calcolarsi la Distanza e i Tempi di Percorrenza

    Dato il tempo di Percorrenza sottratto dall'Ora di Consegna (volendo anche dal Tempo di Preparazione del Prodotto), 
    si calcola in automatico l'Ora di Preparazione.

    Questo consente di dare un tempo certo di consegna al Cliente e/o comunque avere  una sequenza temòporale di preparazione delle varie comande.


    Riflettevo sulla Tracciabilità e Ritracciabilità che avevi accennato nel post precedente.

    Poniamo che sti' Capperi che adoro… abbiano creato un problema a qualche Cliente … a questo punto, per come sopra esposto e come accennavi, risali automaticamente quando, dove, a chi e a quale ora, questo ingrediente è stato preparato e consegnato ai vari clienti.
    A questo punto sulla base della ritracciabilità sei in grado di emanare l'allerta tramite numero telefonico
    E con la tracciabilità sei in grado di risalire al lotto utilizzato per la preparazione

    Insomma, 'na cosa del genere.  ;)


    Detto questo e se è verosimile, il progetto dovrà tenere conto di tali aspetti e si dovrà condizionare e stabilire delle regole ferree che richiederanno di avere delle relazioni obbligatorie oppure no.

    Ovviamente solo un esempio   ;))

    Solo per completezza…

    1) Asporto non è domicilio, io ritiro e io so dove abito.

    2) la tracciabilità la fai quando prepari un prodotto e ne elenchi i lotti delle materie prime che hai utilizzato. Ovviamente tieni traccia di come ti è arrivato quel lotto.

    Per tracciare basta che al carico inserisci il lotto ricevuto con quale documento e chi era il corriere.

    Nella preparazione hai un foglio che per prodotto ti elenca i lotti utilizzati. Se fai vendita al banco di prodotti freschi ti fermi li. 

    Se fai prodotti a lunga conservazione e grande distribuzione allora potrebbe capitare che un lotto di biscotti prodotto 6 mesi fa, sia difettoso.

    Interviene la rintracciabilità (percorso inverso della tracciabilità)

    Ossia: l'ingrediente incriminato è la farina… 

    bene quel prodotto che lotto di farina è stato usato?

    Il lotto abc!

    Ok, con il lotto abc, quali altri prodotti hai creato? A chi li hai dati quei prodotti?

    Ritira dal mercato quei prodotti che hanno quel lotto di farina!

    La rintracciabilità si ferma al venditore finale. Se vai dal salumiere, il salumiere annota il lotto del salume usato quel giorno ma non traccia sullo scontrino il lotto venduto. Se stai male la ricerca la fai nei giorni (3-4) precedenti, ma se è un gelato confezionato prodotto 10 mesi fa, il lotto sulla confezione ti permette di risalire a tutti gli esercenti a cui hai fornito quel lotto e/o i prodotti che contengono l'ingrediente incriminato 

    In sostanza una query su più tabelle per lotto dell'ingrediente che restituisce n lotti di prodotti finiti fatti con quel lotto che restituisce n clienti con n documenti di vendia dei lotti fatti con quel lotto dell'ingrediente incriminato.

    Ma questo va oltre la necessità delle norme haccp del negozio, qui si parla di industria alimentare, farmaceutica, e dispositivi medici (in questo ultimo caso si parla di matricole dei componenti).

    3) in caso di alert, la query ti restituisce un elenco di clienti con il dettaglio dei lotti da ritirare. Tuttavia, data la complessità di solito si manda a tutti i clienti un elenco di lotti da verificare, escludere dalla vendita, inventariare e restituire al produttore, fermandosi solo a livello scheda di produzione. Trovati i prodotti che contengono l'ingrediente si elencano i lotti associati al prodotto finito.

    In questo caso l'analisi di cui parlavi ha rilevanza legale, un errore li e i nas mettono i sigilli.

    Si è capito che ci lavoro?

    In ultimo si verifica la scheda dei test a campione del biologo se e come sono stati effettuati, che disinfettanti e detergenti sono stati usati sul posto di lavoro, se sono stati eseguiti tamponi antibatterici ecc…

    Adesso godiamoci sta pizza!

  • Re: Integrità referenziale

    30/06/2023 - sihsandrea ha scritto:


    1) Asporto non è domicilio, io ritiro e io so dove abito.

    Giustissimo…. è che sono abituato a ordinare e poi vado a ritirare… per principio non mi piace la consegna a domicilio, magari solo in casi estremi.  ;-)

    Per il resto è materia delicata e da gestire bene come hai accennato. Concordo!

    Invece per i Capperi basta che non siano quelli conservati sotto aceto. ;-)
    e buona pizza a tutti.

    ;-))

  • Re: Integrità referenziale

    30/06/2023 - sihsandrea ha scritto:


    30/06/2023 - zoro82 ha scritto:


    Perdonatemi ma sto cercando di capire bene. Se voi siete già edotti mi dispiace che stiate buttando del tempo. Se però dovete percularmi meglio che non rispondete.

    Quello che chiedevo io non erano delle “regole per mettere l'integrità referenziale”. Ma degli esempi(appunto…non regole) in cui non era strettamente necessario usarla. Ho capito che le regole le devo stabilire io in progettazione…ma queste regole le devo stabilire con criterio.  

    Quello che faccio fatica a capire è l'espressione “ Non è complicato: hai una relazione che può non essere attivata per qualsiasi ragione che vuoi. E la stessa relazione può essere legata da integrità”

    Per me non ha senso avere una relazione e non attivarla….se c'è per me ha senso attivarla e garantire, a prescindere, che i dati siano integri sia in fase di inserimento che di aggiornamento o cancellazione. Quindi sarebbe più comodo/corretto metterla sempre e non lasciarla alla discrezionalita'  (progettuale) di una persona. Non trovo nessuna utilità pratica nell'avere, in una tabella, il cliente 46 che però non esiste nella corrispettiva anagrafica. 

    Nessuno sta prendendo in giro…

    Hai chiesto la differenza tra una relazione semplice ed una referenziata e ti è stata spiegata.

    In ogni caso, puoi lasciare in bianco il campo relazionato (forse il termine non attivare ti ha spiazzato). La relazione non si ativa ne tanto meno si dichiara. Se su due tabelle hai due campi della stessa natura e dimensione (esempio tabellaa campo1 striga 10 e tabellab campo5 stringa 10) puoi metterle in relazione. Se invece imposti (in questo caso lo dichiari) una integrita, allora prima di scrivere un valore sul campo devi accertarti che sull'altra tabella il campo relazionato abbia quello stesso valore.

    Seconda richiesta: devo mettere integrità?

    Nel tuo caso (comanda o ordine) no. Suppongo che col cartaceo appena consegni il prodotto butti via l'appunto della comanda. Quindi puoi benissimo cancellare l'ordine (fai spazio al db).

    Se, tuttavia, usi l'integrità, puoi crearti il cliente generico. 

    Dall'analisi del tipo di modus operandi del settore potresti semplicemente inserire un campo note o contatto dove inserirai il nominativo di chi ti sta facendo l'ordine ed un recapito, senza necessariamente passare da tabelle figlie.

    Non trovo nessuna utilità pratica nell'avere, in una tabella, il cliente 46 che però non esiste nella corrispettiva anagrafica

    No, se inserisci un valore significa che esiste anche nella figlia. La differenza sta proprio li, con l'integrità lasci che sia il db ad avvisarti che non esiste il cliente 46, senza integrità resta solo un valore lasciato li orfano ma se inserisci in un secondo momento un cliente 46, interrogando il db, ti viene fuori che quell'ordine lo ha fatto caio e non cesare com'era inizialmente…

    L'integrità ti avvisa che oltre al cliente devi eliminare anche l'ordine (non viceversa perche si parla di 1 a molti).

    Meglio di così non so spiegartelo. Ma nessuno sta deridendo. Ci siamo passati tutti.

    Forse non riesco a spiegarmi io:

    Ordine(id, data, fk_cliente, …..)

    dettaglioOrdini(id, fk_ordine, fk_prodotto, qta)

    Associo ordine.id con dettaglioOrdini.fk_ordine. Per me non c'è nulla da discutere sull'integrita' referenziale: va messa, punto.

    Poiché in dettaglioOrdini mi ritroverei, cancellando un ordine come dici tu, una fk_ordine con un valore che non esista in ordine. 

    Io non vedo molta discrezionalità o progettualità in questa decisione.

    Cosa mi sfugge?

  • Re: Integrità referenziale

    Ti sfugge l'essere un programmatore.

    Posso bypassare il db e farla io l'integrità.

    Suponi di avere la tabella prima nota.

    Id, tipo movimento, cliente_fornitore dare_avere importo

    Al cliente_fornitore metto id cliente se tioomovimento è attivo, se passivo metto id fornitore.

    Ora se ho integrità con clienti devo creare due campi su movimenti uno per clienti e uno per fornitori. Non mettendo l'integrità posso scegliere in base all'opzione attivo/passivo l'id cliente o l'id fornitore. Cosa che non potrei fare vincolando quel campo ad una sola tabella perche se ho il cliente 12345 ma non ho il fornitore 12345 non potrei mai inserire quel codice.

    Lo stesso in un registro di carico e scarico.

    Carico da ddt o fattura fornitori o reso da clienti e scarico da ddt o fatture a clienti o reso a fornitore.

    A scanzo di altre questioni, metti l'integrità tranquillamente, non succede nulla, non va in crash il sistema…

    Buon lavoro.

  • Re: Integrità referenziale

    Ah, tornando al carico e scarico, potrei avere un carico o scarico da inventario, senza clienti e fornitori… ergo campo a null.

  • Re: Integrità referenziale

    30/06/2023 - sihsandrea ha scritto:


    Ah, tornando al carico e scarico, potrei avere un carico o scarico da inventario, senza clienti e fornitori… ergo campo a null.

    Oppure invece di Null puoi avere un conto Cliente e Fornitore a tal fine. Uno per scaricare e uno per caricare . 
    Questo permetterebbe di non modificare la gestione standard dei Documenti e delle chiavi di relazione. E tutto rimane normalizzato. (quindi meno personalizzazioni)

    In tal caso sarà il tipo di documento classificato come Documento Inventariale. Stesse regole e composizione come un qualsiasi documento di vendita o di acquisto.

  • Re: Integrità referenziale

    Erano esempi di non integrità referenziale…

    Comunque si ragiona oer cicli attivi o passivi

    Dare o avere

    Un carico viene fuori da ddt o fattura fornitore ma anche da un reso o da una rettifica da inventario.

    Esattamente speculare il ciclo passivo.

    Se poi includi l'apertura (esistenza iniziale) e la chiusura (rimanenze finali) non hai ne cliente ne fornitore.

  • Re: Integrità referenziale

    30/06/2023 - sihsandrea ha scritto:


    Se poi includi l'apertura (esistenza iniziale) e la chiusura (rimanenze finali) non hai ne cliente ne fornitore.

    Esatto, basta avere i dovuti conti di contabilità.

    Insomma… dipende come è strutturato il ciclo tra documenti e contabilità e ci sono diversi approcci in questo ambito.


     Però ho l'impressione che il zoro82 non ci segue più…. può essere ?  ;-))  (scherzo)

Devi accedere o registrarti per scrivere nel forum
25 risposte