問題タブ [bcnf]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
database - 機能依存性を伴う 1NF 正規形
次の例を読みました。その関係 A(X,Y,Z,P,Q,R) は、次の関数依存関係があります。
なぜこれが1NFにあるのですか?
誰でも私を助けることができますか?
mysql - 候補のキー決定要因は BCNF に十分対応できますか?
宿題で出てきた問題は次のようなものです。
- 行列式が候補キーの一部である場合、BCNF にはそれで十分でしょうか?
すべての非キー属性が主キー全体に依存し、他には何も依存しない場合、関係は BCNF にあるため、そうは思いません。これは、行列式が候補キーの一部であると言いますが、これは部分的な機能依存を意味しますか?
ただし、候補キーがスーパーキーである可能性があるため、自分で推測し始めましたが、そうではないようです。
どう思いますか?
database - すべての関係を 2 属性の関係に分解してみませんか?
ご存じのとおり、属性が 2 つしかない関係はすべて BCNF にあります。
では、問題は、すべての関係を 2 属性の関係に分解しないのはなぜでしょうか?
答えは、そうすると、損失のない結合を実現できないためです。
その答えの例を教えてください。関係を与えて、それをいくつかの 2 属性の関係に分解します。次に、それらを結合すると、データが失われます。
どうもありがとうございました。
database - 多値依存関係の混乱
4NF と多値依存関係 (MVD) の概念に苦労しています。
現在受講しているコースの補足書を探しています。その一例を以下に示します。
この本では、アスタリスクが一意のキーまたは複合属性キーを参照していると述べています。
与えられたもの: R(A*,B,C*) と集合 {(A,B):R,(B,C):R} は無損失分解特性を満たします。
多値依存関係 B->>C は成立しますか?
B は間違いなく一意のキーですか?
R は 4NF ですか?
可逆分解を理解しています - 上記の 2 つのセットを自然に結合すると、元のデータセット、つまりこの場合は A、B、C が得られます。
しかし、与えられた情報をどのように取り、B->>Cが成立するか、成立しないかを証明/確認する方法を理解できません。
私は私の混乱について教授に電子メールを送りました.
database-design - 機能依存関係の 1 つの属性を null にすることはできますか?
私は書店に一連の関数依存関係 F、R = {cid、cname、bid、name、rentdate、returndate、cost} を持っています。そのテーブルは 1 つだけです。
customerid、bookid、bookname、この人物によるこの本のレンタル日と返却日。
明らかに、BCNF ではありません
しかし、これに対して重要な機能依存関係の F を特定する方法は?
私の意見では:
cid -> cname
入札 -> bname
入札、賃借日 -> 返却日、cid
それは大丈夫ですか?最後の機能依存関係では、特定の時間に 1 冊の本をレンタルする各注文には、固有の返却日があり、1 人だけに属していると思います
しかし、このテーブルでは、rentdate と returndate も null に設定できるため、この関数の依存関係についても混乱しています!!!
このようにして、
入札、賃借日 -> 返却日、cid
正しい?
database - 主キーは定数 int にする必要がありますか?
そのため、私の学校のプロジェクトの 1 つで、疑似 e コマース Web サイト用のデータベースを作成する必要があります。プロジェクトの指示では、データベースを Boyce-Codd 正規形で実装するように求められていますが、この正規形にはあいまいさがあると思います。
そのようなエンティティを実装するとしましょうUsers
:
(注:*
主キーを意味します)
まず、BCNF をよく理解していれば、このエンティティは BCNF ではありません。username
s が s と同様に一意である場合、email
このエンティティを次のように定義することもできます。
私の最初の質問は、この実体をボイス・コッド正規形で作成する方法ですか?
次に、この BCNF フォームには別の問題がありid
ます。ユーザーが自分のユーザー名と電子メールを変更できると仮定します。主キーも変更されます。私の問題は、エンティティの要素を定義する一時的な定数が実際にないことです。これは、たとえば、ロギングに関するいくつかの問題を意味します。主キーを持つユーザーからのアクションをログに記録すると仮定すると、foo@smth.com
彼の電子メールをfoo2@smth.com
に変更すると、この種のログが得られます。
次に、電子メールの変更を把握できなければ、先行ログはすべて意味がありません。つまり、誰が誰なのかわかりませんfoo@smth.com
。
次に、私の 2 番目の質問は、時間定数 id (整数など) を使用する方が安全だと思いませんか?
normalization - 4NF と多値の依存関係
私はこの演習を与えられ、私の答えについて誰かの意見を得たいと思っています:
リレーション スキーマ R = (A、B、C、D) と依存関係のセット F = (A -> BCD) が与えられます。R が 4NF にあると主張できますか?
私の最初の考えは、4NF は多値の依存関係により関心があるため、4NF にあると主張することはできないということでした。
しかし、私の教授の回答は、多値の依存関係が与えられていないため、実際には4NFであると主張できるため、4NFであるというものでした。
彼の主張や私の主張を裏付ける文献 (書籍、論文など) を教えてもらえますか? 私はしばらく探していましたが、実質的なものは何も見つかりません。
sql - BCNF 条件不明
以下を読みました。R は関係スキーマ、X は属性のセット、A は R の属性です。F を FD のセットとします。R が BCNF にあるためには、F のすべての X-> A について、次が成り立たなければなりません。
2) で、なぜ X はスーパーキーでなければならないのですか? BCNFの場合、重要な依存関係ごとに、キーが何らかの属性を決定することを理解しているため、条件がXである必要はありません。
2) を X が候補キーであると置き換えると、何が問題になりますか?
database - 部分的な機能依存性、まだ 3NF ですか?
関係スキーマ R (ABCD)
関数の依存関係は次のとおりです
。AB -> D
CB -> D
A-> C
C -> A
最高正規形 ???
私の理解 :
候補キー = ABおよびBC
テーブルの作成中、AB と BC の両方を主キーと見なすことはできません。それでは一つ一つ取り上げていきましょう。
キー AB の場合:
AB -> D ( Fully Functional Dependency , so no problem )
CB -> D ( ??? )
A -> C (partial Functional Dependency , as left side contains only part of key)
C -> A ( Functional Dependency , So no problem )
キーBC用
現在、両方のキーによって、リレーションには部分的な機能依存関係が含まれています。
その場合、2NF であってはなりません。
しかし、答えは 3NF です。
私を修正してください。