問題タブ [functional-dependencies]

次の機能依存関係がある場合

F |= E -> BC が偽であることに頭を包むことはできません。EならAへ、AならBCへ。このロジックの何が間違っていますか?

以下の関数fは、特定のタイプ'a'に対して、タイプ'c'のパラメーターを取ります。さまざまなタイプの「a」、「c」はさまざまな方法で制限されます。具体的には、「a」が任意の積分型である場合、「c」は任意の「実数」型であることが許可されるべきです。'a'がFloatの場合、'c'はFloatのみになります。

1つの試みは次のとおりです。

何らかの理由で、GHC 7.4.1は、「fIntegralの使用から生じる（Real c）を推測できなかった」と不満を述べています。関数従属性はこの推論を可能にするはずだと私には思えます。この場合、aはiと統合されるため、関数従属性により、dはcと統合される必要があります。この場合、cは「Real」であると宣言されます。ここで何が欠けていますか？

機能従属性はさておき、このアプローチは上記の制限を適用するのに十分表現力がありますか、それともより良い方法がありますか？'a'にはいくつかの異なる値しか使用していないため、次のようなインスタンスがあります。

ありがとう

以下のコードを検討してください。

ghciで推定されたタイプのfを見ると

次のコードを追加すると

エラーが発生します

ここで何が起こったのか理解できませんか？制限により、のタイプは、推定されたタイプのに示されているようにFoo Int a制限されているはずです。hInt -> Floatf

インスタンスを解決する前に型の統合が行われているためですか？

[アップデート]

カフェのメーリングリストでダン・ドエルが説明

答えは、fundepの実装と型族の違いはローカル制約情報であると私は信じています。Fundepsはローカル伝播を行いません。

したがって、最初の定義では、ローカルで' Int -> a'を提供しました。これは、GHCに受け入れられます。次に、関数の外部で' (Foo Int a) => Int -> a'が実際にであることがわかりInt -> Floatます。

2番目の定義では、''を与えようとしていますが、GHCは、それを決定するために使用しない制約' 'をInt -> Float''に提供する必要があることをローカルでしか認識していません。Int -> aFoo Int aa ~ Float

これはfundepsに固有のものではありません。ローカル制約ルールを持つバージョンのfundepsを作成することができます（新しいタイプのファミリーのものに変換することで簡単にできます）。しかし、その違いは、重複するインスタンスが型族ではなく、fundepsでサポートされている理由でもあります。しかし、私は今はそれには入りません。

それが何を意味するのかまだわかりません。それで、まだより理解しやすい答えを探しています。

enter code hereデータベース試験の準備をしています。

R={A,B,C,D,E,F,G} の重要な機能依存関係を、次のような機能依存関係のセットで見つけることについて質問があります。

この場合の候補キーは CF です。これは、CF+=ABCDEFG であるためです。

自明ではない機能的依存関係は C->B である可能性があります

これは本当ですか?そうでない場合、非自明な関数の依存関係を計算する方法と、Armstrong Axioms を使用してそれを証明する方法

ご理解とご協力をお願いいたします

型クラスと関数従属性を使用して、たとえば次のコードで変換できる型関数を取得し、次に示すように別の型クラスで使用しようとし ています。IntCont Int

そして、これがghci7.4.2のエラーです

TypeConv型クラスに私が読んだ基金があるとすると、「与えられてrepr、a私たちは推測することができbます」そしてインスタンスを提供しましたInt、なぜghcはそれを推測できないのa' ~ Cont Intですか？

ここで、機能依存関係と候補キーを見つけるように求められます。

FD と候補キーを理解するとき、私は少し混乱しています。私の理解では、「X の 1 つの値が与えられた場合、Y の 1 つの値を知っているか」という場合に FD を見つけることができますか? たとえば、studentID が与えられた場合、studentName はわかりますか? はい。それは簡単です。

候補キーについては、おそらく主キーになる可能性がありますが、必然的に主キーとして使用されるキーだと思います。

今、私はシナリオを持っています:

人材紹介会社は、面接の予約の詳細を記録するデータベースを作成しています。この機関は、「候補者」(CND) が仕事を見つけるのを支援する「プレースメント マネージャー」(PLM) を採用しています。各プレースメント マネージャーは、多くの候補者と面接します。ただし、候補者は 1 人の配置マネージャーに割り当てられます。これは、候補者が持つ各予定について、常に同じプレースメント マネージャーとの予定であることを意味します。任意のアポイントメントは、1 人の候補者と割り当てられたプレースメント マネージャーの間で行われます。

代理店の初期スキーマは次のとおりです。

Appt は予約の日時です。PLM# & PLMname はプレースメント マネージャーの ID と名前、CND# は候補の ID です。CNDname は候補者の名前です。CNDaddress は、候補者の連絡先です。仕事は面接で話されている仕事です。

したがって、上記のシナリオでは、候補キーは次のようになります。

ここでの私の問題は、上記のように書き出すか、候補キーを1つだけ持つかがわからないことです

{PLM#, CND#, Appt}

FD:

前提条件 1 面接時に仕事について話し合う 候補者は 1 日に 1 回だけ面接を受けることができます

正規化する前にFDをチェックしたいだけです。

次のテーブル定義があるとします。

TRUCK（TruckNum、TruckType、TypeDesc、TruckMiles、DatePurchased、TruckSerialNum、BaseCity、BaseState、BaseNum、BaseManagerName、ManagerPhone、BasePhone）

機能依存性のリストを設定する必要があります。

これまでのところ：

また、次の注意事項/制限事項があります。

1. トラックは単一の基地を拠点としています。

2. ベースは、多くのトラックのベースになることができます。

とにかく、私が持っている質問は実際にはかなり単純で、（おそらく）完全に初心者っぽいです。私を混乱させているのはBaseNumです。

私がこれを持っていることに注意してください：

TruckNum->（...）BaseNum

その後

BaseNum->（...）

BaseNumを2回使用している方法をご覧ください。これは許可されていますか？

1NFの定義は、テーブルに繰り返しグループが含まれていてはならないということです。しかし、それは（FDではなく）テーブル定義のためだけではありませんか？よくわかりません。

私は人工生命を使った実験を実行するためのフレームワークを開発しており、関数従属性の代わりに型族を使用しようとしています。型族はHaskellersの間で好まれるアプローチのようですが、私は関数従属性がより適しているように見える状況に遭遇しました。私はトリックを逃していますか？これが型族を使ったデザインです。（このコードは正常にコンパイルされます。）

ユーザーに定型文の最後の2行を書かせないようにする方法はありますか？以下のfundepsを使用したバージョンと比較してください。これにより、ユーザーにとっては簡単になります。（UndecideableInstancesの使用は危険信号である可能性があります。）（このコードも正常にコンパイルされます。）

編集：簡単な例を提示しようとして、私は自分のデザインの動機の一部を省略しました。

ユニバースクラスが果たす最大の役割は、エージェントのシリアル化と逆シリアル化であるため、エージェントクラスにリンクする必要があると思います。またreadAgent、writeAgent機能します。ただし、変更後に誤ってエージェントを作成することを忘れないようにしたかったので、それらの関数をエクスポートする代わりに、withAgentすべてを処理する関数を提供します。このwithAgent関数は、エージェントで実行される関数と、プログラムを実行するエージェントの名前（一意のID）の2つのパラメーターを取ります。そのエージェントを含むファイルを読み取り、プログラムを実行し、更新されたエージェントをファイルに書き戻します。（代わりに、readAgent関数とwriteAgent関数をエクスポートすることもできます。）

Daemon各エージェントにCPUの公平なシェアを与える責任があるクラスもあります。したがって、デーモンのメインループ内で、現在のエージェントのリストをユニバースに照会します。次に、エージェントごとに、そのエージェントのプログラムwithAgentを実行する関数を呼び出します。liveAlittleデーモンは、エージェントがどのタイプであるかを気にしません。

withAgentこの関数のもう1つのユーザーは、エージェント自体です。エージェントのliveALittle関数内で、交配相手となる可能性のあるパートナーを探すために、エージェントのリストをユニバースに照会する場合があります。関数を呼び出して、withAgentある種の嵌合関数を実行します。明らかに、エージェントは同じ種（タイプクラス）の別のエージェントとのみ交配できます。

編集：これが私が使用すると思う解決策です。型族や関数従属性ではありませんが、コンパイラーがどちらliveALittleを呼び出すかを認識できるように、何かを行う必要があります。私がそれを行った方法は、ユーザーliveALittleにパラメーターとして正しいものを提供させることです。

次の機能依存関係があると仮定します。

(G-(AB ->C) U (A -> C) = ACB である B+ の閉包により B を削除できることがわかります

最小限のカバーを見つけるために、DEG -> H、DG -> H に関する他の左側の冗長性にどのようにアプローチすればよいでしょうか。これらを減らすことができますか。

どうもありがとう、マシュー