データベース設計の「第 3 正規形」では、機能の依存関係を取り除く必要があります。他のフィールドから計算できる属性 (フィールド) をテーブルから削除して、冗長性を排除しようとします。たとえば、別のエンティティを参照する場合、そのキーのみを保存します。これらの参照されたエンティティから属性のレプリカを保存しません。これは、参照されたエンティティを変更するたびにそれらを更新する必要があることを意味するためです。
もう 1 つの状況は、高さなどの属性です。人の身長を知りたいのですが、アプリケーションでは、メートル、フィート、天文単位など、さまざまな単位で知りたい場合があります。ただし、これらの値のすべてを保存するわけではありません。計算フィールドを削除する必要があるため、そのうちの 1 つ (もちろんメートル) のみを残し、必要なときに変換された値を「その場で」計算します。
また、年齢なども保存せず、生年月日から計算します。この場合、時間とともに年齢が変化するという事実も役割を果たします。これを行わないと、常に更新し続けない限り、データはすぐに不正確になります。
ここで、各ユーザーの星座を表示するソーシャル ネットワークがあるとします。各ユーザーについて、生年月日と時間、およびユーザーが選択した占星術の伝統 (西洋または中国など) から計算されたサインを表示します。誰かの星座を計算することは、かなり専門的で複雑な計算ですが、占星術のライブラリから呼び出して計算するだけです。このデータベースをどのように設計しますか、機能的に依存するこの属性を削除しますか、それともユーザーのサインを 1 回計算しますか、それとも生年月日を更新するたびに計算し、それをデータベースに保存してサインインの計算の可能性を忘れますか?システムの残りの部分、または「3NF」を強制しますか 鉄拳で支配？また、アルゴリズムが計算しているサインとは異なるサインをユーザーが主張する場合、ユーザーのサインを微調整できることの潜在的な利点をどのように見ますか?
ここで、新しいアプリケーションを考えてみましょう。あなたは、新しい徴集兵の可能な職業を選択する陸軍用のシステムを構築しています。システムの一部は、ORNL で開発された巨大なパターン認識マシンであり、データベースから得られる大量のデータに基づいて、徴集兵に許可される職業を教えてくれます。このパターン認識方法は、各人の身長、生年月日、医療記録、学校の成績証明書を調べ、その人が 2 つのアンケートのうちの 1 つに回答した長いリストも調べます。また、上位の将校が記入した評価アンケートも考慮に入れ、行われる分析では、各年のすべての徴集兵を同時に調べて、フィードフォワードなどの一連のパラメーターを考え出します。神経網。このニューラル ネットワークは、パターン認識システム全体よりも単純ですが、それでも温度単位の変換だけでなく、かなり複雑な計算です。それにもかかわらず、あなたはそれを「ブラックボックス」として見ることができ、データベースから記録を引き出すと、各徴集兵の運命を知ることができます.
陸軍のカレンダーの特定の日に分析が行われ、ANN パラメーターが検出されます。次に、ブラック ボックスを実行して、各徴集兵に次の 1 年または 2 年に何をするかを伝えることができます。それはかなり重要なことです。あなたは人々の職業を決定し、キッチンでオーブンを操作する人や、タンクを運転する人を派遣します。全員が陸軍のネットワークにログインして自分の職業をチェックし、個人のウェブページで結果を確認します。
これで小さなブラック ボックスが表示され、データベースから取得した属性に基づいてこの重要な値が出力されます。属性とパラメーターはおそらく決して変更されず、徴集兵の運命の計算はおそらく常に正しく、初日から常に同じ値になります。しかし、「計算された属性を削除する」というルールに従うためだけに、それをデータベースの外に残しますか?
これは、年齢、星座、または温度変換の単なる計算ではありません。パターン認識システムは、まさに属性を計算するためのパスです。しかし、この非常に重要なことを何度も何度も再計算して、それをシステム内に永久に保持したいですか? それとも、すべてを一度計算して、この魔法のブラック ボックスの存在を忘れたほうがよいと思いますか? つまり、このクレイジーなパターン認識コードをすべて1 日1 回実行し、結果を選択してデータベースに記録するだけです。誰かがログインして分析の出力を確認するときは、クエリが単なる退屈なデータ取得手順になるようにし、すべてのパターン認識の「興奮」は別の機会にします。
もう 1 つの明白な状況: あなたは Amazon のようなウェブ ストアを運営しています。DB 内のユーザーのレコードから供給される本を人々に推奨するためのパターン認識メソッドがあります。現在の推奨事項が必要なときは常に実行し続けますか?それとも、パターン認識ボックスをシステムの残りの部分とは別のものとして扱い、その結果を他のプログラムが読み取れるデータベースにフィードするだけですか? たとえば、気まずい瞬間に推奨事項を切り替えていないことを確認するためのコントロールがあればいいと思いませんか?... 計算負荷についてあまり心配する必要はありません。優れたメモリと計算リソースを想定してください。
TL;DR -- 計算された属性を削除する規則は決して破られるべきではないと思いますか?それとも、非常に複雑で繊細なパターン認識方法によって計算された非常に重要な属性の結果をデータベースに格納しても問題ないと思いますか? 実際には「オンデマンド」で計算を実行できないふりをして、これらの結果を記録したままにしておく必要がある状況はありませんか? とにかく更新されませんか?