ブール値を決定できない場合はどうすればよいですか？
これまではExcelシートにしか存在していなかった企業向けのWebアプリケーションを構築しています。これでほぼ完了ですが、最近、それらのシートからすべてのデータを新しいシステムにインポートするタスクが割り当てられました。システムはJavaで構築されていますが、このインポートは1回限りのものなので、代わりにPythonでスクリプトを記述し、SQLクエリで直接インポートすることにしました。ここで問題が発生します。新しいデータモデルには、既存のデータに含まれていないいくつかの新しい属性が含まれています。ほとんどの場合、これは問題ではなく、情報を見つけられない場所にnullを配置するだけです。しかし、いくつかの属性に遭遇しました、これはブール値であり、デフォルトではNULLにすることはできません。最初に、データベース内のこれらのフィールドにnullを許可しようとしましたが、将来のシステムで問題が発生するため、シニア開発者からは許可しないように言われました。明らかな解決策は、すべての不明なブール値をfalseにデフォルト設定することですが、私は実際にはfalseかどうかわからないので、それも間違っていると思います。
例：hasRadioパラメータを持つエンティティCarがあるとします。次に、このデータモデルにデータをインポートする必要がありますが、データには列「モデル」と「色」のみがあり、ラジオの有無は関係ありません。 「hasRadio」列は、意図的にnullにできない場合、何を入れますか？
この状況での最良のアプローチは何ですか？不足しているデータを手動で入力するように会社に指示する必要がありますか？または、デフォルトでfalseになっていますか？
これは主に要件分析の問題であり、関係するデータが「ブール値」であるという事実とは関係ありません。データベースまたはその他の種類のデータストレージでテーブルを初期化する必要があり、一部の列に不完全な入力がある場合は、最初にシステムのユーザーまたは顧客が適切なデフォルト値と考えるものを見つける必要があります。これらの列について、これを見つける必要がありますすべての単一の属性について、一般的にはありません正解があります。
これは通常、次のいずれかのケースにつながります。
特定の列には適切なデフォルト値があり、ユーザーは最初にすべてのレコードで値が同じであるかどうかを気にせず、後で必要に応じて簡単に正しい値を設定できます
他の情報から理想的なデフォルト値を決定する方法があるので、このルールをコードに入れることができます
ユーザーまたはお客様は、データベースにインポートされる前に、入力データを拡張し、欠損値（おそらく手動）を提供します
特定の列やレコードに適切なデフォルト値がない場合、データもインポートする必要がありますが、ユーザー知りたい特定の値がすでに初期化されているレコードと、ない。したがって、値後でを入力して、値がすでに正しく設定されているレコードとそうでないレコードを追跡できます。
最後のケースでは、ブール値の場合でも、シニアが好むと好まざるとにかかわらず、初期化されていない状態または不明な状態を表すためにNULLのようなものが必要です。特定の列にNULL値の使用を禁止するあいまいな技術上の理由がある場合は、追加のブール列（hasRadioIsUnknownなど）を導入することにより、「不明」状態を別の方法でシミュレートする必要があります、またはブール値の代わりに3値の列挙を使用する（HasNoRadio=0、HasRadio=1、Unknown=2など）。しかし、徹底した要件分析を行った後、そのような回避策が本当に必要であることを確認するために、もう一度上司に話してください。
これは技術的な質問ではありません。それはビジネスルールの質問です。それで、あなたは「ビジネス」に尋ねる必要があります。
製品の所有者や利害関係者にアプローチし、次のように言います。
アプリケーションでリクエストしたフィールドの1つに不完全なデータがあります。デフォルト値を使用しますか？ 「不明」を有効な値として追加しますか？または、インポートの前にチームの誰かにデータを修正してもらいたいですか？
いくつかの議論が続くだろう。しかし、それは基本的にです。技術的なソリューションは、より具体的なビジネスルールから自然に流れます。
一般的な問題は、 データ統合 と呼ばれるより大きなサブエリアの一部である データクレンジング と呼ばれるプログラミングのサブエリア全体です。この種の問題を回避することは、Excelシートからの移行の理由の大部分であり、上級開発者がフィールドをnull可能にしたくない理由です。これがデータ移行の複雑さの大きな原因の1つであると言っても不合理ではないと思います。
可能な場合は常にNULLを使用することを選択するだけで、間違ったことになる可能性が高く、データモデルを変更してさらに多くのフィールドをNULL可能にすることは言うまでもありません。 Excelには整合性チェックが弱いかまったくないため、これらの問題の多くの原因である可能性があります。間違っているのは、新しいデータベースの整合性チェックを削除して、ゴミをデータベースにダンプすることです。これは問題を永続させるだけであり、無意味なデータを処理する必要がある将来の統合にかなりの複雑さを追加します。
データモデルの不一致が原因の可能性があります。これに対処するには、主に両方のデータモデルに（親密に）精通していることと、古いモデルを新しいモデルにマップする方法を知っていることが重要です。新しいものが古いものを取り込むことができる限り。 （そうでない場合は、チームに非常に大きな問題がある可能性があります。）これには、列をコピーするだけではなく、より多くの作業が必要になる場合があります。ダークウィングは、これの優れた例を示します（また、盲目的にNULLを挿入することが間違っている理由と同じです）。詳しく説明すると、古いモデルにReceivedDateビットとInProgressビットがあり、新しいモデルにStartDateとProcessingEndTimeがある場合、次のことを決定する必要があります。 ProcessingEndTimeを設定する場合とその方法。使用方法によっては、StartDateと同じになるように設定するのが合理的（ただし恣意的）です（または、問題が発生する場合は、その後すぐに）。
ただし、一部の違いは、存在するはずのデータが存在しないか破損しているためである可能性があります。 （データ入力エラーまたはデータ処理システムの過去の移行またはバグの処理が不十分である可能性が高いです。）チームの誰もがこれを予期していなかった場合、プロジェクトの時間の20％を費やすことに（集合的に）しました。ほぼ完了しました。 （これは架空の数値でしたが、それよりもfar悪い、またはより良い場合があります。データの量がどれだけ間違っているか、どれほど重要かによって異なりますそれは、それがどれほど複雑であるか、データの責任者が関与するのがどれほど簡単か、およびその他の要因です。）データがそこに「あるはずである」が欠落していると判断したら。通常は、古いデータソースをクエリして、問題の程度を特定します。それが数十または数百のエントリである場合、それはおそらくデータ入力エラーであり、データを担当する顧客は手動でそれを解決する必要があります（つまり、値が何であるかを伝えます）。数百万のエントリ（またはデータのかなりの部分）の場合の場合、そこに「あるはず」であることを正しく識別したかどうかを再検討する必要がある場合があります。これは、新しいシステムのモデリングエラーを示している可能性があります。欠落しているデータについてデータを使用している人々に尋ねると、彼らはしばしばそれをいくらか知っていて、それに対処するための臨時の方法を持っています。
たとえば、一部の数量が不足していることを除いて、数量とアイテムごとの合計（ただし単価ではない）がある請求書を想像してみてください。そのような請求書を処理する人と話すと、次のシナリオの1つ（または複数）が生成される可能性があります。明らかにこれは2の注文です。3）「その場合、この別のシステムで価格を調べて、四捨五入して四捨五入します」、4）「別のシステムで調べます」、5）「実際のデータではありません"、6）"これまでに見たことがない "。
提案されているように、これは状況を自動的に解決するいくつかの方法を示している可能性がありますが、ソリューションがすべてのケースに適用されるように注意する必要があります。データをクロスチェックできる他のシステムが関与することは一般的であり、これは良いことです。ただし、クロスチェックを実行するためにこれらのシステムにアクセスして統合することが難しい場合がある場合、それはしばしば悪いことであり、システムがデータを欠落しているだけでなく、システムが互いに競合していることがしばしば明らかになります。多くの場合、手動による介入が必要であり、規模によっては、データクレンジングタスク専用のツールとインターフェースを作成する必要がある場合があります。多くの場合、データは部分的にインポートされますが、データが欠落している行は別のテーブルに送信され、そこで確認できます。多くの場合、これは新しいシステムで一貫性を保つために適切な粒度で行う必要があります（つまり、ほとんどのラインアイテムが特定の請求書で問題なくても、個々のラインアイテムではなく請求書を拒否します）。 tクライアントをインポートすると、そのクライアントの請求書をインポートできません）。
データモデルを変更します。
Hasradioを正規化すれば、ヌルはなくなります。
ブール値を決定できない場合は、ブール値を使用しないでください。
ブール値をnullにできるようにすることで、ブール値でなくなります。ブール値には、False、Trueの2つの状態があります。
必要なのは、False、True、Unknownの3つの状態です。
データモデルを変更するオプションはありますか？
（そして、私が考えた別のことは、pythonまたはJavaの場合、データベースからデータを取得します。レコードを取得し、hasradioフィールドを確認してあなたがそれが真か偽かをチェックし、それがたまたまnullである場合に起こりますか？）