問題タブ [relational-algebra]

セットの除算は他の一連の操作によって実行できることを十分に認識しているので、私の質問は次のとおりです。

SQLに除算を設定するコマンドはありますか？

2つの問題に対して関係代数を作成する必要があるデータベース割り当てがあります。私はそれの大部分でかなり大丈夫だと感じていますが、別のテーブルに結合されているテーブルから属性を投影しようとすると混乱します。

たとえば、これは正しいですか？

Q1）受付係がまだどのインシデントに電話をかける必要があるかを知ることができるように、電話をかけなかったインシデントの詳細をリストしてください。

私が関係代数に解釈しようとしているSQLは次のとおりです。

アドバイスをいただければ幸いです。

私はリレーショナル代数が初めてで、課題のために 2 つ作成する必要があります。SQL で直面した問題を書き出しましたが、関係代数でそのような結合を表現する方法がわかりません。ヘルプ/ポインタは大歓迎です。

「最適化されたクエリジェネレーター」を作りたいとしましょう。基本的に、時間/スペースの制限に基づいて SQL サーバーに配置できるものよりもはるかに優れた SQL クエリ オプティマイザーです。クエリと DB 統計を入力として取り、ターゲット システムに合わせて調整された SQL クエリを生成し、ほぼ理想的な計画にすばやく最適化します。

どの程度の SQL をサポートする必要がありますか? ほとんどの有用なクエリを簡単に記述できるほど柔軟でありながら、完全な SQL よりも十分に小さく、切り詰める価値のある SQL のサブセットはありますか? また、「マシンの近く」に固執する必要がない場合、クエリを説明するより良い方法はありますか?

既存の SQL を処理するプログラムではなく、新しい SQL を作成するためのツールを考えています。入力言語がクエリの要件を記述できる限り、実際に SQL を入力として受け取る必要はありません。

質問の別の形式は次のようになると思います:パフォーマンスのためだけに存在し、読みやすさ/理解度を向上させることのないSQLの部分はありますか?

誰かが指摘したように、これを行うには「大量の製品固有の知識」が必要であり、それ(たとえば、ネストされたサブクエリと何でも、どの種類のインデックスを使用する必要があるか、そのようなこと) は、まさにツールがカプセル化することを意図したものです。ユーザーがその知識を学ぶ必要がないようにします。

注:実際のクエリ プランの生成には興味がありません。これは DBMS の仕事であり、とにかく SQL からは実行できないからです。特定の DBMS 用に調整する必要のない入力から、その DBMS 用の適切な SQL を作成する作業を自動化できるシステムに興味があります。

誰かがここで何が起こっているのか、この問題を解決する方法を説明してもらえますか?

リレーション R(A,B) に次のタプルがあるとします。

関係 S(B,C,D) にはタプルがあります。

R と S の自然結合を計算します。次に、自然結合
R |><|に含まれる次のタプルを特定します。S. 各タプルにはスキーマ (A、B、C、D) があると想定できます。

自然な結合が本当に何を意味するのかわかりません。説明してもらえますか？

Aheoは、列が 1 つしかないテーブルを使用してもよいかどうかを尋ねます。列のないもの、または最近のほとんどの「リレーショナル」DBMS でこれを行うのが難しいように思われる場合、属性のないリレーションはどうでしょうか?

私はCJデイトのSQLとリレーショナル理論：正確なSQLコードを書く方法を読んでいます、そして彼は位置クエリが悪いと主張します—例えば、これINSERT：

代わりに、次のような属性ベースのクエリを使用する必要があります。

タプル（行）は順序付けられていない属性のセット（列）であるため、最初のクエリがリレーショナルモデルと一致していないことを理解しました。最初のクエリのどこに害があるのか​​理解できません。誰かが私にこれを説明できますか？

リレーショナル データベースに数学的アプローチを採用するリソースを提案できる人はいますか? 本質的にリレーショナル代数だと思います。

私は数学のバックグラウンドを持っており、現在はデータベースで多くの作業を行っており、ギャップを埋めたいと考えています.

SQLクエリを作成するとき、「単一のクエリでこれを行う方法はない」とよく思います。それが起こったとき、私はしばしばストアドプロシージャまたは（ある種の）一時テーブルを使用するマルチステートメントテーブル値関数に目を向け、結果を単純に組み合わせて結果テーブルを返すことになります。

理論の問題として、単一の結果セットを単一のクエリ（複数のステートメントではなく）として返すクエリを記述できるかどうかを誰かが知っているかどうか疑問に思います。明らかに、私はコードの可読性や保守性、おそらくクエリのパフォーマンス/効率などの関連するポイントを無視しています。これは理論に関するものです-それは可能です...そして心配しないでください、マルチステートメントがすべての場合に私の目的により適しているときに、私は確かにシングルステートメントクエリを書くことを強制し始めるつもりはありませんが、単一のクエリから結果を取得するための実行可能な方法があるかどうかについて、2回または少し長く考えるようになるかもしれません。

いくつかのパラメーターが適切であると思います。一般的なベストプラクティスに従うテーブル（主キーを持つすべてのテーブルなど）を備えたリレーショナルデータベース（MS SQLなど）を考えています。

注：これで「AcceptedAnswer」を獲得するには、明確な証拠（Web資料などへの参照）を提供する必要があります。