問題タブ [relational-model]

1970 年に Edgar Codd によって最初に定義されたリレーショナル モデルのルールを理解しようとしています。

具体的には、参照整合性が彼のリレーショナル モデルの一部であるかどうかに興味があります。次の例でデモンストレーションを試みます（この質問をきれいにするためだけに）：

お客様

請求書

さて、ご覧のとおり、顧客 (外部キー) がMaryである請求書が 1 つあります。これは彼のリレーショナル モデルに違反しますか? エドガー・コッドはこれを見て、「なんてこった」と言うでしょうか? それとも、彼は言うでしょうか、それはまったく問題ありません...

これは理論的な問題です。

アプリのこの部分の開発をしばらく延期しているのは、これを循環的な方法で実行したいからですが、学校で講師が教えてくれたのを覚えているので、それは悪い考えだと感じています。

私が残したこの例に関係のないものはすべて無視して、注文システムの設計があります。

• クレジットカード
• お客様
• 注文

そうして欲しい、

• 顧客はクレジットカードを持つことができます (0-n)
• 顧客からの注文 (1-n)
• 注文には 1 人の顧客がいます (1-1)
• 注文には 1 枚のクレジット カードがあります (1-1)
• クレジット カードは 1 人の顧客を持つことができます (1-1) (一意の ID であるため、cc 番号の一意性を無視できます。夫/妻は cc インスタンスなどを共有できます)

基本的に、最後の部分は問題が発生する場所です。クレジット カードが拒否され、別のカードを使用したい場合があります。これは、「現在の」カードを更新する必要がありますが、これはその注文に使用されている現在のカードを変更するだけであり、変更することはできません。顧客がディスク上に持っている可能性のある他の注文。

これにより、3 つのテーブル間に円形のデザインが効果的に作成されます。

考えられる解決策: どちらか

円形のデザインを作成し、参照を与えます:

• cc ref 注文、
• お客様の cc への参照
• 顧客参照注文

また

• お客様の cc への参照
• 顧客参照注文
• 3 つすべてのテーブル ID を参照する新しいテーブルを作成し、注文に固有のものを配置して、常に 1 つの cc のみがその注文に対して最新であるようにします。

基本的に、どちらも同じデザインをモデル化していますが、解釈が異なります。現時点では後者のオプションが最も気に入っています。（それが理にかなっていれば）

私の質問は、

• それぞれの長所と短所がある場合はどうなりますか?
• 循環関係/依存関係の落とし穴は何ですか?
• これはルールの有効な例外ですか?
• 後者よりも前者を選ぶべき理由はありますか?

ありがとうございます。明確化/説明が必要なことがあればお知らせください。

--更新・編集--

記載した要件に誤りがあることに気付きました。SOの物事を単純化しようとすると、基本的にボールを落としました。別のレイヤーを追加する Payments 用の別のテーブルがあります。難点は、注文には複数の支払いがあり、異なるクレジット カードを使用できる可能性があることです。（他の支払い方法についても知りたい場合）。

根本的な問題は依然として同じであり、これは実際には別の複雑さのレイヤーを追加するだけだと思う​​ので、ここでこれを述べます.

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

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

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

SQLサブクエリを結合に、またはその逆に変換するための一般化された手順またはアルゴリズムはありますか？つまり、サブクエリを含まない機能的に同等のステートメントになるサブクエリを含む構文的に正しいSQLクエリステートメントに適用できる一連の活版印刷操作はありますか？もしそうなら、それらは何ですか（つまり、アルゴリズムは何ですか）、そしてどのような場合にそれらは適用されませんか？

スーパーキーには、主キーの一部ではないものを含めることができますか？

データベース、リレーショナル モデル、およびトランザクション理論に役立つニーモニックを探しています。たとえば、トランザクションの特性 (原子性、一貫性、分離性、耐久性) を覚えるのに役立つ「ACID」を学びました。他に何がありますか？

私の問題を説明する前に、いくつかのことを整理したいと思います。

1. 私は経験豊富な (専門家ではありませんが) データベース設計者です。リレーショナル モデルについてよく理解できたと思います。
2. 私は、あらゆる状況で何をすべきかを正確に知っているほど、リレーショナル モデルをしっかりと理解しているわけではありません。まだ勉強してる。

月に 1 回銀行から Excel スプレッドシートを受け取るとしますが、常に同じ銀行からではありません。スプレッドシートには、銀行名、口座番号、口座残高、顧客 (口座名義人) の名前、顧客の SSN、口座名義人の住所の 6 つの列しかありません。各行には異なる口座番号があり、口座番号は複数の行に記載されていません。このスプレッドシートをデータベースにインポートして、将来いつでも「2010 年 10 月 13 日のジョン スミスの住所は?」と尋ねたいと考えています。

簡単にするために、すべての顧客が 1 つのアドレスしか持たず、すべての顧客が 0 個以上のアカウントを持つことができるとしましょう。少しの間、Excel シートのインポートを 1 回だけ行う必要があると仮定しましょう。これはばかげた前提ですが、ご了承ください。その場合は、次の設計で十分です。

私の質問の残りの部分は、そのスキーマが「正しい」ことに同意するという前提に基づいているので、問題ないことを願っています。

インポートが 1 回だけであれば問題ありませんが、銀行ごとに年間 12 回のインポートを行うことになります。これが私がそれを会計処理する方法をどのように考えていたかです：

これで、すべてのアカウントがインポートに関連付けられ、「アカウント 12345 は 10/13/10 のインポート 572 から発生した」などのことを確実に言うことができます。customerたとえば、テーブルを見ると、もう少しあいまいになる可能性があります。customerテーブル内の行数がテーブル内よりも少ないaccountため (一部の顧客は複数のアカウントを持っているため)、アカウントとインポートの場合のように、顧客とインポートの間に 1 対 1 の関係はありません。データが失われることも、データの整合性が失われることもないことはわかっていますが、それでも何らかの犠牲を払っているように感じます。

私の質問は (これは自由すぎるかもしれません):これはデータを保存する良い方法だと思いますか? 別の方法でやったでしょうか？

編集: これらのエンティティについて、知っておくべき重要な考え方があります。account時間をかけて存在する 1 つのアカウントと考えないでください。は、ある時点でのアカウントaccountのスナップショットと考えてください。したがって、残高 $100 のアカウント 12345 は、残高 $150 のアカウント 12345 と同じではありません。はい、実世界では両方の記録が同じ銀行口座に関連付けられていますが、私が保存しているのは、ある時点での口座のスナップショットです。顧客と同様の (ただし同一ではない) 状況。account

7年間の開発経験で見たすべてのデータベースのほぼすべてのテーブルには、自動インクリメントの主キーがあります。どうしてこれなの？米国の州の表があり、各州が一意の名前を持っている必要がある場合、自動インクリメントの主キーはどのように使用されますか？州名を主キーとして使用しないのはなぜですか？一意の行を装った複製を許可する言い訳のように私には思えます。

これは私には明白に思えますが、繰り返しになりますが、他の誰も私と同じ論理的結論に到達して行動しているようには見えないので、私が間違っている可能性が高いと想定する必要があります。

自動インクリメントキーを使用する必要がある実際の実用的な理由はありますか？

Product、ProductType、 と呼ばれる 3 つのエンティティがありProductCategoryます。

、、の 3ProductType種類があるとしましょう。BookMusicVideo

ProductCategory、、、の3 つの異なるものがありBookます。FictionNovelTechnical

、、、ProductCategoryの3MusicつRockの異なるJazzPop

そして、3 つProductCategoryの異なる for Video: Fiction, Comic, がありDramaます。

AProductには aProductTypeがあり、多くProductCategoryの 's を持つことができます。しかし、そのProductCategoryは と一致する必要がありProductTypeます。たとえば、 が の場合、ProductType、、およびasBookのみを使用できます。FictionNovelTechnicalProductCategory

アプリケーションコードやトリガーなどを使用せずに、この制限でこのスキーマをモデル化することは可能ですか (つまり、ProductCategoryaProductはその と一致する必要がありProductTypeます)。テーブル、外部キーなどを使用するだけです。

これをどのようにモデル化しますか？

この質問には、いくつかの仮説的な背景が必要です。MySQL を RDBMS として使用して、列、、、employeeを持つテーブルを考えてみましょう。ある人物が別の人物と同じ名前と生年月日を持っている場合、それらは定義上、同じ人物であるため (1809 年 2 月 12 日に生まれたエイブラハム リンカーンという名前の 2 人がいるという驚くべき偶然を除けば)、ユニークキーオンとは「同じ人を二度収納しない」という意味です。ここで、次のデータを検討してください。namedate_of_birthtitlesalarynamedate_of_birth

次のステートメントを実行しようとすると、失敗するはずです。

これを試してみると、成功します：

そして今、私のデータは次のようになります。

これは私が望んでいることではありませんが、起こったことに完全に同意できないとは言えません。数学的集合の観点から話すと、

私の推測では、MySQL は「生年月日のあるジム・ジョンソンがまだこのテーブルにないことを知らないので、彼を追加します」と言っていると思います。NULL

私の質問は、常に知られているわけではありませんが、どうすれば重複を防ぐことができますか? date_of_birthこれまでに思いついた最善の方法はdate_of_birth、別のテーブルに移動することです。ただし、これに関する問題は、たとえば、同じ名前、役職、給与、異なる生年月日を持つ 2 人のレジ係がいて、重複せずに両方を保存する方法がなくなる可能性があることです。