0

そのため、私の学校のプロジェクトの 1 つで、疑似 e コマース Web サイト用のデータベースを作成する必要があります。プロジェクトの指示では、データベースを Boyce-Codd 正規形で実装するように求められていますが、この正規形にはあいまいさがあると思います。

そのようなエンティティを実装するとしましょうUsers:

Users(*email, username, password, some_other_fields)

(注:*主キーを意味します)

まず、BCNF をよく理解していれば、このエンティティは BCNF ではありません。usernames が s と同様に一意である場合、emailこのエンティティを次のように定義することもできます。

Users(*username, email, password, some_other_fields)

私の最初の質問は、この実体をボイス・コッド正規形で作成する方法ですか?

次に、この BCNF フォームには別の問題がありidます。ユーザーが自分のユーザー名と電子メールを変更できると仮定します。主キーも変更されます。私の問題は、エンティティの要素を定義する一時的な定数が実際にないことです。これは、たとえば、ロギングに関するいくつかの問題を意味します。主キーを持つユーザーからのアクションをログに記録すると仮定すると、foo@smth.com彼の電子メールをfoo2@smth.comに変更すると、この種のログが得られます。

[foo@smth.com] : action xxx
[foo@smth.com] : action yyy
[foo2@smth.com] : action zzz

次に、電子メールの変更を把握できなければ、先行ログはすべて意味がありません。つまり、誰が誰なのかわかりませんfoo@smth.com。

次に、私の 2 番目の質問は、時間定数 id (整数など) を使用する方が安全だと思いませんか?

4

1 に答える 1

2

BCNF では一意性だけでは不十分です。BCNF は、機能依存性を強調しています。つまり、属性が機能的にキーに依存しているかどうかです。

この場合、属性を電子メールに依存させることはできません。電子メールは、変更されたり、非アクティブになったり、他の誰かによって取り戻されたりする可能性があります。したがって、一意であるというだけでは、キーの候補として十分に正当化されません。機能によってユーザー名の変更が制限されている場合、ユーザー名の信頼性が高くなる可能性があります。

機能依存性は本質的に機能設計に依存します。テーブルを作成しているアプリケーションが、ユーザー名の変更が許可されないと想定している場合、属性はユーザー名に依存して候補キーになる可能性があります。機能設計でユーザー名を変更できる場合は、一意で機能的に信頼できるキーを導入または組み合わせる必要があります。

導入された追加の一意の ID の場合、それらはここでのユーザー名よりも「本質的に」より「安全」ではありません。しかし、おそらく機能と機能設計はIDが変更されることを想定していないため、それらは安全に「感じる」または「なる」. 繰り返しますが、機能設計でその ID を変更できる場合、それは安全ではありません。最終的には、機能、要件、およびその機能仕様に従って属性がどのように動作することが期待されるかに依存します。

ID の導入を検討する必要があり、ユーザー名の信頼性に満足できない場合は、次のような多くの理由から、int/integer の代わりに GUID を検討してください。

  1. int/integer は通常、周期的です。つまり、特定のプラットフォームの制限の後にリサイクルされます。たとえば、16 ビットの int の制限は 32767 ～ -32768 です。GUID も再表示される可能性がありますが、その可能性は統計的にはそれほど重要ではありません。
  2. 異なるサブシステムで実行され、後で同期する必要がある操作の場合、一意でない ID が作成されることがあります。オフライン モードで顧客を登録し、後でクラウドで同期できるチェーンの 2 つのショップを考えてみましょう。最初のストアは、たとえば 3000 という ID を持つ顧客を作成し、2 番目のストアは同じことを行います。データを同期するときは、それに対応するために別の複合キー構造を使用する必要があります。一意である可能性が高い GUID は、それらを解決できます。
于 2014-11-29T01:17:54.780 に答える