join - 関係代数結合の最適化

Question

学校の教科書で、結合操作の多くが、結合の右側のテーブルを最適化するようには見えず、左側だけであるのを見てきました。たとえば、データベース部門を管理している従業員の名前を見つけるには、次のようにします:
_name ( _{Mgr_ssn} ( _{Dname = 'Database'} ( Department ) ) ⨝<sub>Mgr_ssn = ssn Employee

)
_name ( Mgr_ssn ( _{Dname = 'Database'} ( Department ) ) ⨝<sub>Mgr_ssn = ssn ( _{ssn, name} Employee ) )

もちろん、これは Employee が他の多くの属性を持っていることを前提としています。そうすることで、従業員の他のすべての属性を結合することを心配する必要がないため、システムは時間を節約できると思います。結合の右側でこのようなプロジェクションを見たことがなく、それが許容できるかどうか、または不要かどうか疑問に思っています。

Answer 1

適切なクエリ オプティマイザーは、処理するデータを最小限に抑えるために、適切な制限を押し下げ、場合によっては予測も押し下げます。また、オプティマイザーが自動的にそれを行い、結果が同じであるため、リレーショナル代数で式を最適化する必要は特にありません。

このような 2 つのテーブルの結合シーケンスでは、部門と結合する前にプロジェクションを形成する利点があるかどうかは明らかではありません。考えられる処理シーケンスは、Dname = 'Database' で (おそらく単一の) 部門を見つけ、次に E.SSN = D.Mgr_SSN で Employee の単一の行を見つけることです。ただし、部分式が複数回使用されている場合は、実行する価値があるかもしれません。

また、設計がひどいことに注意してください。データベース設計の結合フィールドとして、SSN のように機密性の高いものを使用しないでください。PCIチームは発作を起こすでしょう！しかし、おそらく名前は過去の穏やかな時代の名残かもしれませんが、コンテンツは生成された代理であり、実際の SSN は Employee.RealSSN に保存されます (権限のない人に見られないように暗号化されている場合もあります。許可された人だけがそれを選択できるように列に正しく許可することも有効です)。

Answer 2

ほとんどのオプティマイザは、左ディープ ジョインのみを考慮するシステム R オプティマイザを使用します。そのため、右側に結合が表示されることはありません。

すべてのオプションの探索空間は指数関数的であるため、オプティマイザーは合理的に受け入れられるソリューションを迅速に見つけたいと考えています (オプティマイザーは最適なソリューションを見つけるのではなく、最悪のソリューションを回避しようとします)。

PS 左深い結合を使用する理由は、結果をディスクに書き込む必要なく結果をパイプライン処理できるため、I/O を節約できるからです。