Cosa fare quando non è possibile determinare un valore booleano?

Stiamo costruendo un'applicazione web per l'azienda, la cui amministrazione esisteva finora solo nei fogli Excel. Ormai abbiamo quasi finito, ma recentemente mi è stato assegnato un compito per importare tutti i loro dati da quei fogli nel nostro nuovo sistema. Il sistema è integrato in Java, ma poiché questa importazione è solo una volta, ho deciso di scrivere gli script in Python e importarli direttamente con query SQL. Ecco che arriva il problema. I nuovi modelli di dati contengono alcuni nuovi attributi, che non sono inclusi nei loro dati esistenti. Nella maggior parte dei casi, questo non è un problema, ho solo messo un null dove non riesco a trovare le informazioni. Ma poi ho incontrato alcuni attributi, che sono booleani e non possono essere NULL per impostazione predefinita. Per prima cosa ho provato a consentire solo null per quei campi nel nostro database, ma il mio senior dev mi ha detto di non farlo, in quanto causerebbe problemi nel nostro sistema in futuro. E ora non sono abbastanza sicuro di cosa fare. La soluzione ovvia è quella di impostare come falso ogni valore booleano sconosciuto, ma penso che sia sbagliato anche perché in realtà non so se sia falso.

Esempio: supponiamo che tu abbia un'entità Car che ha un parametro hasRadio. Ora è necessario importare i dati in questo modello di dati, ma nei dati ci sono solo le colonne "Modello" e "Colore", nulla di ciò che ha o non ha la radio. Cosa metti in una colonna "hasRadio", se non può essere nullo in base alla progettazione?

Qual è l'approccio migliore in questa situazione? Dobbiamo semplicemente dire alla società di compilare manualmente i dati mancanti? O predefinito su falso?

Questo è principalmente un problema di analisi dei requisiti e non ha nulla a che fare con il fatto che i dati in questione sono "booleani". Se devi inizializzare le tabelle in un database o in qualsiasi altro tipo di archiviazione dei dati e disponi di input incompleti per alcune colonne, devi prima scoprire quali utenti del sistema o il tuo cliente ritengono essere il giusto valore predefinito per quelle colonne, e devi scoprirlo per ogni singolo attributo , non esiste una risposta generalmente corretta.

Questo di solito porta a uno dei seguenti casi:

• esiste un buon valore predefinito per la colonna specifica, agli utenti non importa se il valore è inizialmente lo stesso per tutti i record, possono impostare facilmente i valori corretti successivamente quando necessario

• esiste una regola su come determinare il valore predefinito ideale da altre informazioni, quindi è possibile inserire questa regola nel codice

• gli utenti o il cliente estenderanno i dati di input e forniranno i valori mancanti (forse manualmente), prima che vengano importati nel database

• non esiste un buon valore predefinito per la colonna specifica e / o qualsiasi record, i dati devono essere importati o, ma gli utenti vogliono sapere per quale dei record il valore particolare è già inizializzato e per quale no. Quindi possono inserire il valore in un secondo momento e tracciare per quali record il valore è già impostato correttamente e per quali no.

L'ultimo caso richiede qualcosa come NULL per rappresentare lo stato non inizializzato o sconosciuto, anche per un valore booleano, se al tuo senior piace o no. Se c'è qualche oscuro motivo tecnico che vieta l'uso di un valore NULL per una colonna specifica, è necessario simulare lo stato "sconosciuto" in un modo diverso, sia introducendo una colonna booleana aggiuntiva (come hasRadioIsUnknown), sia usando un 3 enumerazione -valued invece di un valore booleano (come HasNoRadio=0, HasRadio=1, Unknown=2). Ma parla di nuovo con il tuo senior, dopo aver effettuato un'analisi approfondita dei requisiti, per assicurarti che tale soluzione alternativa sia davvero necessaria.

Questa non è una domanda tecnica; è una domanda sulle regole aziendali. Quindi, è necessario chiedere "l'azienda".

Contattare il proprietario del prodotto e / o le parti interessate e dire qualcosa come:

Abbiamo dati incompleti per uno dei campi richiesti nella domanda. Vuoi che usiamo un valore predefinito? Vuoi che aggiungiamo "sconosciuto" come valore valido? Oppure, desideri che qualcuno nel tuo team corregga i dati prima dell'importazione?

Probabilmente seguiranno alcune discussioni. Ma è praticamente tutto. La soluzione tecnica deriverà naturalmente dalle regole aziendali più raffinate.

Il problema generale è un'intera sottozona di programmazione chiamata pulizia dei dati che fa parte di una sottozona più ampia chiamata integrazione dei dati . Evitare questo tipo di problemi è probabilmente una grande parte del motivo della migrazione dai fogli di Excel e perché lo sviluppatore senior non vuole consentire che un campo diventi nulla. Non credo sia irragionevole affermare che questa è una delle maggiori fonti di complessità nelle migrazioni dei dati.

Scegliere semplicemente di utilizzare NULL ogni volta che è possibile è probabilmente la cosa sbagliata , per non parlare della modifica del modello di dati per rendere ancora più nulli i campi. Excel ha un controllo di integrità debole o assente che è probabilmente la causa di molti di questi problemi. La cosa sbagliata da fare è rimuovere il controllo di integrità nel nuovo database e scaricare la spazzatura in esso. Ciò perpetua il problema e aggiunge una notevole complessità alle integrazioni future che devono in qualche modo occuparsi di dati senza senso.

Parte della differenza è probabilmente dovuta alla mancata corrispondenza del modello di dati. Affrontare questo è in gran parte una questione di familiarità (intima) con entrambi i modelli di dati e sapere come mappare quello vecchio a quello nuovo. Finché il nuovo è in grado di catturare quello vecchio. (In caso contrario, è probabile che il tuo team abbia un grosso problema.) Ciò può facilmente richiedere più lavoro rispetto alla semplice copia di colonne. Darkwing fornisce un eccellente esempio di questo (oltre al perché l'inserimento cieco di NULL è la cosa sbagliata da fare). Elaborandolo, se il vecchio modello aveva un ReceivedDatee un InProgresspo 'e il nuovo modello ha un StartDatee ProcessingEndTime, dovrai decidere se e come impostare il ProcessingEndTime. A seconda di come viene utilizzato, una scelta ragionevole (ma arbitraria) potrebbe essere quella di impostarla come la stessaStartDate (o poco dopo se ciò potrebbe causare problemi).

Tuttavia, una parte della differenza è probabilmente dovuta ai dati che "dovrebbero" essere mancanti o danneggiati. (Molto probabilmente a causa di errori di immissione dei dati o migrazioni passate o bug scarsamente gestiti nei sistemi di elaborazione dei dati.) Se nessuno nel tuo team lo ha anticipato, allora (collettivamente) ti sei impegnato a spendere il 20% del tempo del progetto " quasi fatto. (Era un numero inventato, ma può essere lontanopeggio di così, o meglio. Dipende da quanti dati non sono corretti, da quanto è importante, da quanto sia complessa, da quanto sia facile ottenere il coinvolgimento dei responsabili dei dati e da altri fattori.) Una volta stabilito che i dati "dovrebbero essere "lì ma manca. Di solito tenterai di determinare l'entità del problema interrogando le vecchie origini dati. Se si tratta di dozzine o centinaia di voci, allora probabilmente sono errori di immissione dei dati e i clienti responsabili dei dati dovrebbero risolverli manualmente (cioè dirti quali dovrebbero essere i valori.) Se sono milioni di voci (o una frazione significativa dei dati) , potrebbe essere necessario riconsiderare se hai correttamente identificato che "dovrebbe essere" lì. Ciò potrebbe indicare un errore di modellazione nel nuovo sistema.

Ad esempio, immagina una fattura con quantità e totali per articolo (ma non prezzo unitario), tranne per il fatto che alcune delle quantità erano inspiegabilmente mancanti. Parlare con la persona che elabora tali fatture potrebbe produrre uno (o più) dei seguenti scenari: 1) "oh, una quantità vuota significa una quantità di 1", 2) "oh, so che quegli articoli costano circa $ 1.000, quindi chiaramente questo è un ordine per 2 ", 3)" quando ciò accade, io cerco il prezzo in questo altro sistema e lo divido e giro ", 4)" lo cerco in un altro sistema ", 5)" non sono dati reali ", 6)" mai visto prima ".

Come suggerito, questo può indicare alcuni modi per risolvere automaticamente la situazione, ma devi stare attento che la soluzione si applichi a tutti i casi. È comune coinvolgere altri sistemi che possono effettuare controlli incrociati dei dati, e questa è una buona cosa. Tuttavia, spesso è una cosa negativa in quanto può essere difficile ottenere l'accesso e integrarsi con questi sistemi per eseguire il controllo incrociato, e spesso viene alla luce che i sistemi sono in conflitto tra loro non solo perché mancano alcuni dati. Spesso è necessario un intervento manuale e, a seconda della scala, potrebbe essere necessario creare strumenti e interfacce specificamente per l'attività di pulizia dei dati. Spesso ciò che viene fatto è che i dati vengono parzialmente importati ma le righe con dati mancanti vengono inviate a una tabella separata dove possono essere riviste.

Cambia il modello di dati.

Puoi normalizzare l'hashradio e quindi non avrai più null.

Se non riesci a determinare un valore booleano, non utilizzare un valore booleano.

Consentendo a un valore booleano di diventare nullo, smette di essere un valore booleano. Un booleano può avere 2 stati: Falso, Vero.

Ciò di cui hai bisogno sono 3 stati: falso, vero, sconosciuto.

Hai la possibilità di cambiare il modello di dati?

(E un'altra cosa a cui ho pensato, se in Python o Java recuperi i dati dal tuo database. Recuperi il record, controlli il campo hasradio, cosa succederà se controlli se è vero o falso e succede che sia nullo?)

Come altri hanno sottolineato, quello che hai qui è un valore booleano che non è veramente booleano e il problema è costringerlo a essere booleano o gestirlo in altro modo.

Quello che potresti fare è, invece di avere un singolo risultato booleano, avere due risultati booleani. Questi potrebbero essere d'accordo o in disaccordo. Se sono d'accordo, allora hai un risultato vero / falso.

Se, tuttavia, non sono d'accordo, allora hai un risultato indeterminato e hai la possibilità, a seconda delle circostanze in cui si presenta, di decidere come gestirlo. In alcuni casi un risultato indeterminato potrebbe essere meglio interpretato come vero, mentre in altri lo stesso risultato indeterminato potrebbe essere interpretato come falso, secondo l'opzione più sicura.

Ciò consentirebbe comunque di riportare il risultato come indeterminato, quindi questa ulteriore sfumatura del valore non andrebbe completamente persa, fino al punto in cui il valore può essere definitivamente risolto e ripristinato.