問題タブ [relational-model]

Ted Codd のThe Relational Model for Database Management, Version 2の序文で、彼は次のように書いています (最初の段落)。

今日、適切に設計されたデータベース管理システムがあれば、データ処理と意思決定支援の王国への鍵を手に入れることができます。 そのため、リレーショナル モデルに基づいて完全に設計されたプロトタイプ マシンが現在存在しています。その演算ハードウェアは、アーキテクチャの非常に小さな部分です。実際、「コンピュータ システム」という古い用語は、今では間違った呼び方のように思えます。

テッド・コッドが言及していた試作機を知っている人はいますか? このマシンについて説明している古いコンピューター サイエンス / コンピューター エンジニアリングの論文を読みたいです。

これは宿題の質問です。私はすでに私自身の答えを持っていますが、それが正しいかどうかはわかりません。皆さんにアドバイスする必要があります。概念図は次のとおりです。

これが私のリレーショナルスキーマです：

Employer（EmployerID、name）->主キーはEmployerIDです

Employees（EmpID、name）->主キーはEmpIDです

雇用主と従業員の実体は、通常のクラスとして正しいはずだと思います。しかし、実行中のプロジェクトと、関連付けクラスと依存クラスであるプロジェクトエンティティがわかりません。これが私の答えです：

RUnning Project（EmpID、Year、Duration、ProjectID、ProjectName）->すべての主キー

Project（ProjectID、ProjectName）->すべての主キー

UMLクラスモデルからデータベースリレーショナルモデルへのマッピングを自動的に可能にするアプリケーション（Enterprise Architectなど）を知っている人はいますか？どのように？

ありがとう

休止状態の 3.6.3.Final を使用しています。次のように定義された一方向の ManyToOne を持つ 2 つのリレーショナル エンティティ A と B があります。

ここで、すでに pk id = 1 で db に永続的な B インスタンスがあり、次の操作を行っているとします。

有名な「TransientObjectException: object references an unsaved transient...」例外をスローします。驚くべきことに、@Version @Column を削除するか @Transient にすると、上記のコードは問題なく動作します。なぜ私がこの行動を観察しているのか分かりますか?

ブラウザベースのゲーム内でプレーヤーデータを保持するスキーマを設計しています。

私には3つの関係があります。それらのうちの2つには、少なくとも2つの候補キーがありますが、3つ目には、{playerId、message、date}の3つの属性しかありません。

1..1：0 .. *の関係があるため、この関係は一意の行を保持しません。つまり、各プレーヤーに任意の数のニュースタプルが存在する可能性があります。タプルを一意に識別できる必要はありません。とにかく、どの属性も実際には候補になることはできません。

私の質問は次のとおりです。リレーショナルモデルでは、重複するタプルは存在できず、各リレーションにはキーが必要であると述べています。上記の私のスキーマは、これらの制約の両方と矛盾しますが、私の目的のために機能します。一意のインデックス属性（IDなど）を追加するだけでよいことはわかっていますが、それは不要のようです。私は何かが足りないのですか？

御時間ありがとうございます。

このトピックは、この質問に多少関連しています。そこでの私の答えは、私が知っているすべてのデータベースのデータにアクセスするには SQL が必要であるという仮定に基づいていました。

私の知る限り、いくつかのdbmsクライアントでデータに直接アクセスしている場合でも、いくつかのdbコネクタを使用していくつかのプログラム（c ++、java、cobolなど）で行ごとの操作（つまり、カーソル）を実行している場合でも、ある時点で必要になります、実際にデータを読み取り/変更するための SQL を記述します。

今私は尋ねています：これは一般的に本当ですか？SQL ダイアレクトに依存しない RDBMS はありますか?

SQL は (厳密ではありませんが) EFCodd (1970) によるリレーショナル モデルの基礎であるリレーショナル代数に基づいていることを私は知っています。

そこで私が質問したいのは、リレーショナル モデルをより適切に実装できる RDBMS はありますか?

スタッフと呼ばれる関係の表形式の表現があります。次数やカーディナリティ (5 と 3) などの多くのタスクを完了するように求められましたが、2 番目のタプルについて話すことに意味がない理由を尋ねられました関係があり、なぜそうなるのかわかりません。

※これは模擬試験であり、解答はありません。

次のシナリオを検討してください。ペットの飼い主は複数の猫を飼っている場合もあれば、複数の犬を飼っている場合もあります。一部の犬は、同じ所有者の一部の猫と関係があります (つまり、ケンカします:-)) 。

次のリレーショナル設計では、異なる所有者の猫と犬が関連している可能性があるため、この制限はありません。リレーショナル設計によってこの制限を課す方法はありますか?

次のテーブルがあるとしましょう

• subgroup_nameは a に対して UNIQUEgroup(group_id)です。
• Agroupは多くの を持つことができますsubgroups。
• これらsubgroup_namesはユーザー提供です。subgroup_id(列の使用は避けたいと思います。subgroup_nameモデルでは意味があり、単なるラベルではありません。あらかじめ決められた名前のリストを提供していますが、ユーザーは柔軟性のために自分の名前を追加できます)。
• このテーブルには、サブグループ属性 (多対 1 の関係) を含む子テーブルを参照する 2 つのレベルがあります。

(group_id, upper(trim(subgroup_name))); に PRIMARY KEY を設定したいと思います。

私が知っていることから、postgres は関数で PRIMARY KEY/UNIQUE を使用することを許可していません。IIRC、リレーショナル モデルでは、列を保存されたものとして使用することも必要です。

CREATE UNIQUE INDEX ON subgroups (group_id, upper(trim(subgroup_name)));私のモデルの他のテーブルには、これらの2つの列を指すFOREIGN KEYがあるため、私の問題は解決しません。

2 つの選択肢があります。

オプション A)

• クリーンアップされたサブグループ名を subgroup_name に保存します
• クリーンアップされていない文字列を含む subgroup_name_raw という列を追加します

オプション B)

• キー ペアに UNIQUE INDEX と PRIMARY KEY の両方を作成します。（かなりの無駄のようです）

洞察はありますか？

注：Postgres 9.2を使用しています