タグ付けされた質問 「subtypes」

3
相互に排他的なサブクラスを持つタイプ/サブタイプデザインパターンでのサブタイプのサブタイプの実装
前書き この質問が将来の読者に役立つように、一般的なデータモデルを使用して、直面している問題を説明します。 我々のデータモデルは、としてラベル付けされなければならない3つの事業体で構成A、BおよびC。物事をシンプルに保つために、それらの属性はすべてintタイプになります。 エンティティにAは次の属性があります:D、EおよびX; エンティティにBは次の属性があります:D、EおよびY; エンティティにCは次の属性がDありZます。 すべてのエンティティが共通の属性を共有Dしているため、タイプ/サブタイプデザインを適用することにしました。 重要:エンティティは相互に排他的です!これは、エンティティがAまたはBまたはCであることを意味します。 問題: エンティティAにBは、さらに別の一般的な属性Eがありますが、この属性はエンティティに存在しませんC。 質問: 可能であれば、上記の特性を使用して設計をさらに最適化したいと思います。 正直に言うと、これをどのように行うのか、どこから試すのかわからないので、この投稿です。

4
単一の列から複数のテーブルを参照するのに最適な設計ですか?
提案されたスキーマ 何よりもまず、投稿全体を通じて参照するために提案されたスキーマの例を次に示します。 Clothes ---------- ClothesID (PK) INT NOT NULL Name VARCHAR(50) NOT NULL Color VARCHAR(50) NOT NULL Price DECIMAL(5,2) NOT NULL BrandID INT NOT NULL ... Brand_1 -------- ClothesID (FK/PK) int NOT NULL ViewingUrl VARCHAR(50) NOT NULL SomeOtherBrand1SpecificAttr VARCHAR(50) NOT NULL Brand_2 -------- ClothesID (FK/PK) int NOT NULL PhotoUrl VARCHAR(50) …

4
MySQLの2つのテーブルの継承をモデル化する方法
データを保存するテーブルがいくつかあり、仕事をした人のタイプ(労働者、市民)に応じてeventテーブルに保存しますが、今ではこれらの人が動物を救いanimalます(テーブルがあります)。 最後に、男(労働者、市民)が動物を救ったというイベントを保存するテーブルが必要ですが、お辞儀をする必要がありidますか、または仕事をした市民または労働者の価値を知る方法はありますか? さて、このデザインでは、どの人が仕事をしたかをどのように関連付けるかわかりません、私はこの最後の表の列にcivil_idベールを保存するだけの人(別名市民)しかいpersonません...しかし、どのように市民か労働者かを知っている場合、他の「中間」テーブルが必要ですか? 次の図の設計をMySQLに反映する方法は? 追加の詳細 次の方法でモデル化しました。 DROP TABLE IF EXISTS `tbl_animal`; CREATE TABLE `tbl_animal` ( id_animal INTEGER NOT NULL PRIMARY KEY AUTO_INCREMENT, name VARCHAR(25) NOT NULL DEFAULT "no name", specie VARCHAR(10) NOT NULL DEFAULT "Other", sex CHAR(1) NOT NULL DEFAULT "M", size VARCHAR(10) NOT NULL DEFAULT "Mini", edad VARCHAR(10) NOT …

3
各音楽アーティストがグループまたはソロパフォーマーであるシナリオのモデリング
以下で詳しく説明するように、音楽アーティストの描写を含むビジネスコンテキストのエンティティ関係図(ERD)を設計する必要があります。 シナリオの説明 アンアーティストが持っている名前を、とでなければならないのいずれかのグループ やソロパフォーマー(両方ではありません)。 A グループは、一人の以上で構成されソロパフォーマーと有するメンバーの数(数から計算されるべきであるソロ出演構成するグループ)。 A ソロパフォーマーは、かもしれ加盟多くの団体、あるいは全くのグループと1つの以上プレイしてもよい楽器を。 質問 このようなシナリオを表すERDを構築する方法は?「または」の部分と混同しています。

2
「どちらか一方」の関係をモデル化するにはどうすればよいですか?
Softwareという名前のエンティティと、2つのサブタイプFreeSoftwareおよびNonFreeSoftwareがあるとします。NonFreeSoftwareエンティティには、購入日、ベンダーなどの属性があります。FreeSoftwareエンティティには、ライセンス、ソースコードのURLなどの属性があります。 それで、別のエンティティであるOperatingSystemをモデル化したい場合、どうすればよいですか?ソフトウェアには「ある」関係がありますが、FreeSoftwareおよびNonFreeSoftwareには「どちらかまたは両方」の関係があります。 この階層を分析する方法に何か欠けていると思います。

2
異なる属性セットを持つことができるエンティティタイプをモデル化する方法は?
ユーザーとアイテムの間に1対多(1:M)の関係を持つデータベースを再作成するときに問題が発生します。 これはかなり簡単です、はい。ただし、各アイテムは特定のカテゴリ(たとえば、Car、Boat、Plane)に属しており、各カテゴリには特定の数の属性があります。 Car 構造: +----+--------------+--------------+ | PK | Attribute #1 | Attribute #2 | +----+--------------+--------------+ Boat 構造: +----+--------------+--------------+--------------+ | PK | Attribute #1 | Attribute #2 | Attribute #3 | +----+--------------+--------------+--------------+ Plane 構造: +----+--------------+--------------+--------------+--------------+ | PK | Attribute #1 | Attribute #2 | Attribute #3 | Attribute #4 | +----+--------------+--------------+--------------+--------------+ …

4
カテゴリ間で決定するスーパータイプ/サブタイプ:完全にばらばらまたは不完全な重なり
デスクトップコンピュータ、ラップトップ、スイッチ、ルーター、携帯電話などのITハードウェアを格納するインベントリデータベースを構築しています。すべてのデバイスが単一のテーブルに格納されているスーパータイプ/サブタイプパターンと特定の情報を使用しています。サブタイプのテーブルに入れられます。私のジレンマは、次の2つのデザインから選択しています。 上の図では、すべてのデバイスが共通のサブタイプを共有しています。たとえば、デスクトップコンピューターとラップトップは、次のテーブルのレコードを持ちます:デバイス、ネットワークデバイス。スイッチには、デバイス、ネットワークデバイスのレコードがあります。ルーターは、Device、NetworkDevice、WANDeviceにレコードを持っています。位置情報を追跡するデバイスには、位置情報の記録があります。このセットアップについて私が考えたいくつかの長所と短所: 長所:HostnameやLocationIDなどの共通フィールドに基づいてレコードを選択する方が簡単です。 プロ:nullフィールドはありません。 欠点:特定のデバイスのCRUD操作に含める必要があるテーブルは明確ではなく、将来のDBAを混乱させる可能性があります。 下の図では、すべてのデバイスに独自のサブタイプがあります(ここには表示されていないデバイスのクラスがさらにあります)。この状況では、どのテーブルレコードが挿入または選択されるかは明らかです。デスクトップコンピューターとラップトップはコンピューターなどに行きます。このセットアップについて私が考えたいくつかの長所と短所: メリット:サブタイプのCRUD操作に使用するテーブルはすぐにわかります。 メリット:CRUD操作には1つのテーブルのみを使用する必要があります。 欠点:共通のサブタイプフィールドに基づいてレコードをSELECTするには、すべてのテーブルを組み合わせる必要があります。たとえば、HostnameやLocationIDによる検索などです。 どちらの状況でも、ClassDiscriminatorフィールドは、CHECK制約で使用できるようにサブタイプテーブルに配置され、挿入できるタイプを制御します。 設計が優れている推奨事項はありますか、それとも完全に意見の問題であり、データベースの意図した目的に依存していますか? 編集:私が持っている特定の質問は、「NetworkDevice」テーブルの重複する性質についてです。このテーブルは、コンピュータ、スイッチ、ルーターなど、ホスト名やIPアドレスを持つデバイスのネットワーク情報を保持するためのものです。このテーブルの重複する性質は問題を引き起こす可能性があるものですか、それともこの方法で実装しても問題ありませんか? 提供された入力について、事前にありがとうございます。追加情報が必要かどうか尋ねてください。

4
変数エンティティをリレーショナルテーブルに変換する方法がわからない
はじめにおよび関連情報: 次の例は、私が直面している問題を示しています。 動物には人種があり、猫でも犬でもかまいません。猫はシャムまたはペルシャのいずれかです。犬はジャーマンシェパードまたはラブラドールレトリバーにすることができます。 動物は強力なエンティティですが、その人種は2つの提供された値(猫または犬)の1つを持つことができる属性です。 これらの値はどちらも複雑です(問題を説明するためにここでは犬/猫のタイプのみを追加しましたが、猫/犬の名前やその他の要素もある場合があります)。 問題: この例では、リレーショナルテーブルを作成する方法がわかりません。 問題を解決するための私の努力: 問題を表す陳の表記法を使用してERダイアグラムを描画しようとしましたが、初心者であるため、正しく行ったかどうかはわかりません。ここに私が持っているものがあります: 間違ったものを描いた場合はお詫び申し上げます。その場合は訂正してください。私は単に「無料のソリューション」を手に入れたいのではなく、将来この問題を自分で解決できるように対処する方法を学びたいと思っています。 頭に浮かぶのは、猫用と犬用の2つの別々のテーブルを作成することだけです。また、Animalテーブルの人種属性には、猫または犬の値のみが格納されます。このようなもの: Animal< # Animal_ID, race, other attributes > Cat < # Cat_ID, $ Animal_ID, breed > Dog < # Dog_ID, $ Animal_ID, breed > 私は自分の解決策について本当に気分が悪く、それが間違っているのではないかと心配しています。 質問: 私の例をどのようにしてER図に変換できますか? そのER図をリレーショナルテーブルに変換する方法は? さらに情報が必要な場合はコメントを残してください。できるだけ早く投稿を更新します。私はここでかなり新しいので、適切なタグを追加してください。 ありがとうございました。

1
2つの可能な所有者/親タイプを持つエンティティのデータベーススキーマ?
私はSequelizeをORMとしてPostgreSQLを使用しています。 1つのタイプがありUserます。2番目のタイプはGroupで、GroupMembershipsテーブルを介して任意の数のユーザーを関連付けることができます。Userは、任意の数のを所有することもできGroupます。 3番目のタイプはPlaylist、UserORまたはaのいずれかに属することができgroupます。このタイプのスキーマを設計して、1つのタイプの所有者またはいずれかのタイプの所有者を持つことができる最善の方法は何ですか? 最初のパスでは両方の関連付けを作成しましたが、一度に1つだけ入力しました。これは機能する可能性がありますが、ハックに見え、クエリを困難にします。 追加情報 コメントを介してMDCCLによって投稿された説明要求に対する私の応答は次のとおりです。 (1)プレイリストが特定のグループによって所有されている場合、このプレイリストは、そのグループのメンバーである限り、1 対多のユーザーに関連していると言えますか? これは技術的には正しいと思いますが、この1対多の関連付けは明示的には存在しません。 (2)では、特定のプレイリストを1 対多のグループが同時に所有することは可能ですか? いいえ、をPlaylist1対多で所有することはできませんGroups。 (3)特定のプレイリストを1 対多のグループ、およびそのようなグループのメンバーではない1 対多のユーザーが所有することは可能ですか? いいえ。(2)のように、1対多のto が存在しPlaylistてGroupはならないためです。さらに、Playlistがによって所有されてGroupいる場合、は所有していませんUser。逆も同様です。一度に1人の所有者のみ。 (4)グループ、ユーザー、プレイリストを一意に識別するために使用されるプロパティは何ですか? それぞれに代理主キー(id)と自然キー(主ではない)があります。これらはslug、GroupおよびPlaylist、およびにusername対応していUserます。 (5)特定のプレイリストで所有者が変更される可能性はありますか? 私はこれが機能であることを計画していませんが(少なくとも最初は)、これは仮説的に発生する可能性があります。 (6)Group.SlugおよびPlaylist.Slug属性の意味は何ですか?それらの値は、主キーとして定義されるのに十分安定していますか、それとも頻繁に変更されますか?これら2つのプロパティの値は、User.Usernameとともに一意である必要がありますか? これらslugのは、固有の小文字のハイフン付きのバージョンであり、それぞれのエンティティのtitleです。たとえばgroup、title「テストグループ」を含むa は「テストグループ」を持ちslugます。重複には増分整数が追加されます。これは彼らのtitle変化がいつでも変わるでしょう。私はそれが彼らが素晴らしい主キーを作成しないことを意味すると思いますか?はい、slugsそしてusernames、それぞれのテーブルにユニークです。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.