問題タブ [functional-dependencies]
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 - 機能従属性の特定II
前回の投稿と少し混乱していたので、問題を解決するための良い例を見つけました。
HireDateとcarRegが主キーです。だから私の質問は、私が以下で特定したもの以外の追加の機能依存性を誰かが見つけることができます....変更も歓迎します:
上記が正しいかどうかはわかりませんが、もっとあると思います。誰かが私がこれらの忌まわしいFDを最終的に理解するのを手伝ってくれませんか!
編集:catcallの答えに基づいて....私の質問はこれです:custName-> custNoはどのように有効なFDですか?上記の関係では、確かに、顧客名は正確に1つの顧客番号にマッピングされますが、直感的には、複数のJSMithをテーブルに追加できることがわかります。この場合、このFDは1 .. *関係を形成するため、無効になります。この事実を知っているcustName->custNoと本当に言えますか?FDはサンプルデータに基づいているだけですか?それとも、追加できる可能性のある値を考慮に入れていますか?
database - ノーマライゼーション 3NF
正規化のいくつかの例を読んでいますが、理解できないものに出くわしました。
例の Web サイトは次のとおりです: http://cisnet.baruch.cuny.edu/holowczak/classes/3400/normalization/#allinone
わからない部分は「第三正規形」
私の頭の中では、推移的な依存関係がEMPLOYEE_OFFICE_PHONE (Name, Office, Floor, Phone)
次のようName->->Office|Floor
に見えます。Name->->Office|Phone
著者は、表EMPLOYEE_OFFICE_PHONE (Name, Office, Floor, Phone)
をEMPLOYEE_OFFICE (Name, Office, Floor)
とに分割します。EMPLOYEE_PHONE (Office, Phone)
最初の私の判断から、私はまだ推移的な依存関係を見ているName->->Office|Floor
ので、なぜそれが 3NF にあるのかわかりません。に推移的な依存関係があると述べたのは間違っていましたName->->Office|Floor
か?
推移性の理由: 機能依存関係のリストは次のとおりです。
- 名前 -> オフィス
- 名前 -> フロア
- 名前 -> 電話番号
- オフィス -> 電話
- オフィス -> フロア (これは間違っていますか? また、その理由は?
ありがとうございます。
database - カノニカルカバーとミニマルカバーの違い
これがばかげた質問である場合はお詫びします。
私は役に立たない答えを高低で検索しました。
最小限のカバーを計算する方法を知っています。
つまり、各機能依存関係が RHS で 1 つの属性のみを持つようにし、すべての FD を調べてそれぞれの閉鎖を計算し、削除できるものがあるかどうかを確認して (再び閉鎖を計算することによって)、余分な/冗長な lhs 属性を削除します。
「正規」カバーは同じことを表す別の言葉ですか?
haskell - 機能従属性の使用を支援する
機能依存性について質問があります。私の理解では、たとえば、私が書く場合class Graph g a b | g -> a, g -> b
、特定のものは1つのタイプのとg
にのみ関連付けることができます。実際、同じで異なる2つのインスタンスを宣言しようとすると、機能しません。a
b
g
a
b
ただし、次の場合、コンパイラ(ghc)は依存関係を使用できないようです。
パラメータと型アノテーションSubgraph1
を追加して修正すると、すべてがうまくいきます。a
b
database - 関係の機能的依存関係とその通常の形式の決定
私はデータベーステストのために勉強しています、そしてスタディガイドにはDBの正規化と機能依存のいくつかの(多くの)演習がありますが、先生は同様の演習をしなかったので、誰かがこれを理解して攻撃するのを手伝ってほしいです他の16の問題。
1) 次の論理スキーマがある場合: 関係 product_sales
前提条件: • POS はゾーンにグループ化されています。• 各 POS にはエージェントがいます。• 各エージェントは単一の POS で動作します。• 同じ POS の 2 つのエージェントが同じ製品を販売することはできません。• 代理店が販売する各製品には、製品と販売数量に応じて資格が割り当てられます。
a) 存在する 4 つの機能依存関係を示します。
b) この構造の標準形は何ですか。
database - データベースの無関係な属性と分解
無関係な属性の概念と 3NF への適切な分解について、私はちょっと混乱しています。
たとえば、次の関係があります。
アルゴリズムを使用して 3NF に分解するために、正規カバーを計算したいと考えています。したがって、FD から不要な属性を削除する必要があります。
A+. B+, C+, D+ (A+ = ABCDE, B+ = BD, C+ = C, D+ = AD)
私は無関係な属性を見つけようとして始めたと計算しました。まずはβで属性を見てみました
D が無関係かどうかを調べようとしました
BC -> DE
BC+ を使用すると、D が無関係であることがわかりました (BC+ には属性 D が含まれているため)。そのため、FD は から変更されBC -> DE to BC -> E
ました。α の無関係な属性を計算しようとしました。
B または C が FD で異質であるかどうかを調べましたBC -> DE
(B+ と C+ を計算すると、B または C のいずれにも E が含まれていないため、異質ではないことがわかりました)。
また、A -> BCD の無関係な属性も調べたところ、B と C の両方が無関係であることがわかりました (A+ にはすべての属性が含まれているため)。そのため、次のものが残されました。
非常に長い質問で申し訳ありませんが、私がしたことを書き留めたかっただけです。
これが正しいのか、それとも私がこれを正しく行っているのか、私は混乱しています。私はいくつかのメモといくつかのオンライン参照に従おうとしていますが、誰かが私がこれを正しく行っているかどうかを指摘できればいいと思います.
functional-dependencies - 機能依存の削減
この FD のセットの最小限のカバーを見つけることになっています。私の答えが正しいかどうか教えてください。
- XZ->Z
- XZ->Y
- XZ->B
- や→し
- YA->G
- C->W
- B->G
- XZ->G
私の答え:
- X->Z (削除された Z 属性、些細な FD)
- Z->Y (1 から X->Z->Y を伴うため、X を削除しました。)
- Z->B (ここも同じ)
- や→し
- YA->G
- C->W
- B->G
- (X->Z->B->Gなので削除)
database - 関数の依存関係の例が必要
例を使用して、データベースの概念における機能の依存関係の例を取得できますか?
特定の列が別の列に依存している場合、それは他の列に機能的に依存していると呼ばれることを理解しました.しかし、私は例で視覚化することができません..plzは私を助けてくれます
haskell - 複数の型クラス インスタンス間の対称性を利用してコードを短縮する
環境
SI プレフィックスを表す Haskell モジュールを作成しています。
各 SI プレフィックスには、対応するデータ型があります。
問題
2 つの SI プレフィックスを適用すると、2 つのプレフィックスのどちらが小さいかを静的に判断する関数を書きたいと思います。例えば:
初期解
型クラスと機能依存関係を一緒に使用するソリューションを次に示します。
上記の解決策は問題を正しく解決しているように見えますが、欠点があります。型クラスのインスタンスの数は、型の数に対して2 次です。
質問
おそらく対称性を利用して、型クラスインスタンスの数を型の数に対して線形に減らす方法はありますか?
ここでは Template Haskell を使用する方が適切かもしれません。その場合は、解決策として遠慮なく提案してください。
ありがとう!
haskell - Haskellの関数従属性の競合
なぜこれが競合を引き起こすのですか?
機能依存を削除すると、コードがコンパイルされることに注意してください。
私は、機能依存性は、実際にはコンパイルされるときに、次のようなものだけを許可するべきではないという印象を受けました!
同じb
パラメーターですが、パラメーターが異なりa
ます。これは、 ?によって一意に決定されるb -> a
ことを意味するため、これを禁止するべきではありません。a
b