タグ付けされた質問 「database-design」

概念スキーマおよび/または論理モデルおよび/またはデータベースの物理設定の開発。

3
各音楽アーティストがグループまたはソロパフォーマーであるシナリオのモデリング
以下で詳しく説明するように、音楽アーティストの描写を含むビジネスコンテキストのエンティティ関係図（ERD）を設計する必要があります。 シナリオの説明 アンアーティストが持っている名前を、とでなければならないのいずれかのグループ やソロパフォーマー（両方ではありません）。 A グループは、一人の以上で構成されソロパフォーマーと有するメンバーの数（数から計算されるべきであるソロ出演構成するグループ）。 A ソロパフォーマーは、かもしれ加盟多くの団体、あるいは全くのグループと1つの以上プレイしてもよい楽器を。 質問 このようなシナリオを表すERDを構築する方法は？「または」の部分と混同しています。
1
PostgreSQLでのローリングデータの保存とクエリ
大量の気象モデルデータをPostgreSQLデータベースに入れています。マシンには8つのコアと16 GBのRAMが搭載されています。PostGIS 2.1でPostgreSQL 9.3を実行しています。各テーブルには、さまざまな気象データ（気温、露点、風など）があります。各テーブルには6〜7列があります。緯度、経度、ポイントジオメトリ、標高、モデルが関連する日時、および対象となる1〜2のデータ値です。データは主に、時間と高度によって境界ボックスを照会されます。テーブルあたり約145,757,360行になります（現在より古いデータはもはや関係がなくなり、削除されます）。テーブルのサイズは、おおよそ、インデックスなしで約10 GBと推定されます。（これは、52バイトのデータと1行あたり23バイトのオーバーヘッドです）。新しいモデルデータが利用可能になると、データは定期的に更新/挿入されます。注意： だから私はこれらの2つの計画を見ています： ポイントジオメトリの追加のインデックスを使用して、（日時、標高）でインデックスを付けてクラスタ化するだけです。古い行を削除し、vacuum / analyzeを実行し、再クラスター化する通常のcronジョブを実行します。 日時でパーティション化し、ジオメトリのインデックスを持つテーブルごとに標高でクラスタ化してインデックス化します。通常のcronジョブを実行して、新しいテーブルを追加し、古いテーブルを削除します。 さらに、 したがって、テーブルを削除する方がはるかに効率的で、削除およびバキューム処理を行うことを知っています。しかし、それ以外の場合はパフォーマンスが向上しますか？ パーティションは、すべてのテーブルが均等に更新されて削除されるまで適切ではない場合に適切ですか（ドキュメントでは、一部のテーブルのみを選択した場合にパーティションが最適に機能することが示されています）？ データを配信する場合、選択はクラスター化インデックスよりも高速になりますか？複数のリクエストが一度に行われる場合、答えは変わりますか？ ありがとうございました。必要なデータをすべて入れてほしい。知らない場合はお知らせください。追加します。
3
ログテーブルはidフィールドまたは主キーを取得する必要がありますか？
特定のファイルが別のシステムにエクスポートされた日時スタンプを記録するログテーブルがあります。 現在、exportedLogテーブルには3つのフィールドがあります。 id (primary key) messageId (int) exportedDateTime (datetime) これを確認すると、idこのテーブルへの結合がないため、フィールドは何の役にも立たないことがわかりました。このテーブルで機能するのは、メッセージを処理してこのログテーブルに挿入するバッチジョブの挿入だけです。 idフィールドを削除する必要がありますか？ どちらかmessageId、exportedDateTimeまたは両方に主キーが必要ですか？
2
「どちらか一方」の関係をモデル化するにはどうすればよいですか？
Softwareという名前のエンティティと、2つのサブタイプFreeSoftwareおよびNonFreeSoftwareがあるとします。NonFreeSoftwareエンティティには、購入日、ベンダーなどの属性があります。FreeSoftwareエンティティには、ライセンス、ソースコードのURLなどの属性があります。 それで、別のエンティティであるOperatingSystemをモデル化したい場合、どうすればよいですか？ソフトウェアには「ある」関係がありますが、FreeSoftwareおよびNonFreeSoftwareには「どちらかまたは両方」の関係があります。 この階層を分析する方法に何か欠けていると思います。
2
1対1の関係は正規化されていますか？
レコードの統計データの大規模なセットがあると考えてください。例：20〜30 INTカラム。セット全体が1つのレコードに属しているため、セット全体を1つのテーブルに保持するか、1対1の関係で接続された別のテーブルを作成する方が良いでしょうか。 前者の利点はJOIN、対応するレコードのすべての統計データを回避して迅速にアクセスできることです。 後者の利点は、カラムを整頓することです。最初の列は読み取り中心で、2番目の列は書き込み中心です。もちろん、行レベルのブロッキングでInnoDBを使用しているので、パフォーマンスに大きな影響はないと思います。 一般に、1つのレコードに対して異なるデータセットを分離することが実用的かどうか知りたいですか？
3
複数の関係に対して1つのテーブルを用意するべきではないのはなぜですか？
データベースにStore、Employee、Saleなどの複数のリレーションがあり、ペアを単純なバイナリリレーションで接続するとします。個人的には、外部キーで構成される自然キーを使用して、Employee_StoreおよびEmployee_Saleという名前のテーブルを作成します。 現在、私の同僚は、複数のリレーションシップ用に1つのテーブルを作成することを強く求めています。上記の例の場合、EmployeeLinksというテーブルがある可能性があります。 EmployeeLinks( IdLink int PK, IdEmployee int FK null, IdStore int FK null, IdSale int FK null, LinkType int not null ) これが良い考えではない理由を教えてください。私は自分の主張を持っていますが、私はそれらを非公開にし、あなたの公平な意見を聞きたいと思います。 編集： 最初、上のテーブルには主キー（！）がありません。外部キーはnullを許可するため、代理キーが唯一のオプションです。
5
オープンソースの階層型データベース管理システムはありますか[終了]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、データベース管理者のスタック交換のトピックになるようにします。 10か月前に閉鎖。 階層型データベース管理システムを探していて、出会ったのはIBMのimsだけでした。使用できるオープンソースシステムはありますか？
3
インデックスの最大行サイズエラー
array列に上限はありますか？ 配列フィールドに挿入すると、このエラーが発生します- PG::Error: ERROR: index row size 3480 exceeds maximum 2712 for index "ix_data" これが私のテーブル定義です- create table test_array(id varchar(50), data text[]); ALTER TABLE test_array ADD PRIMARY KEY (id); CREATE INDEX ix_data ON test_array USING GIN (data); 配列フィールドを検索しているので、配列フィールドにインデックスが必要です。
2
MySQL-それ自体を参照する外部キー制約を持つ行を削除します
ユーザーが私のウェブサイトに投稿したすべてのフォーラムメッセージを保存するテーブルがあります。メッセージ階層構造は、入れ子集合モデルを使用して実装されます。 以下は、テーブルの単純化された構造です。 Id（主キー） Owner_Id（IDへの外部キー参照） Parent_Id（IDへの外部キー参照） nleft そろそろ nlevel これで、テーブルは次のようになります。 + ------- + ------------- + -------------- + ---------- + ----------- + ----------- + | Id | Owner_Id | Parent_Id | nleft | nright | nlevel | + ------- + ------------- + -------------- + ---------- + ----------- + ----------- + | 1 …
2
多くの列といくつかのテーブル-パフォーマンスの面で
はい、私はデータの正規化が（現状のまま）私の優先事項であることを認識しています。 私は列の車両データを格納する65個の列を持つテーブルを持っている：used_vehicle、color、doors、mileage、priceなど、合計65インチ 今、私はそれを分割して持つことができるVehicleテーブル、VehicleInterior、VehicleExterior、VehicleTechnical、VehicleExtra（すべての一対一のメインとVehicleテーブル）。 約500万行（車両）があるとします。 上SELECTでのWHERE句：パフォーマンスが（どちらの場合は、上の少なくともインデックスを付けて検索するほうが良いでしょうIDs）： Vehicle 65列のテーブルまたは VehicleテーブルJOINSに関連するすべてのデータを返すために、他の4つのテーブル（すべてで5万行）にVehicle？ （データベースエンジンごとに、PostgreSQLやMySQLを検討してください）。 以前の経験から得られた詳細な洞察を本当に感謝しますか？
2
効率的な範囲集計クエリのためのデータベース？
簡単な例として、次のようなテーブルがあるとします。 seq | value ----+------ 102 | 11954 211 | 43292 278 | 19222 499 | 3843 テーブルには数億のレコードが含まれる可能性があり、次のようなクエリを頻繁に実行する必要があります。 SELECT sum(value) WHERE seq > $a and seq < $b seqインデックスが作成されている場合でも、一般的なデータベース実装は各行をループして、最良の場合の合計を計算します。O(n)ここnで、は範囲のサイズです。 O(log(n))クエリごとに、これを効率的に実行できるデータベースはありますか？ ここで説明するように、セグメントツリーと呼ばれるデータ構造に遭遇しました。範囲ツリーまたは間隔ツリーとも呼ばれますが、これらの名前はすべて、データ構造のわずかに異なるバリエーションとして説明されることがよくあります。 しかし、そのようなデータ構造を実装するデータベースに出くわしたことはありません。インメモリ構造の場合、最初から実装するのは簡単ですが、永続化する必要がある場合や、メモリに収まりきらない場合は注意が必要です。これを既存のデータベースの上に実装するための効率的なパターンがある場合、それも役立ちます。 補足：これは追加専用のテーブルではないため、この場合、累積合計を保持するなどの解決策は機能しません。
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 | +----+--------------+--------------+--------------+--------------+ …
2
概念的なERDマルチテーブル多対多、またはおそらく再帰？
概念図を作成しています[そうです、属性とキーが含まれていることは知っていますが、これは、学習中に行っていることを統合するためだけのものです]-したがって、関係と図表の方法ではなく表;） 私の心のハードルは次のとおりです。 私は、プロファイル、場所、および組織の関係をモデル化する最良の方法を確認しようとしています。 まず、ルール： 1つ以上のプロファイルは、1つ以上の組織のメンバー/友達になることができます。およびその逆。 1つまたは複数のプロフィールを他のプロフィールのメンバー/友達にすることができます。 1つ以上の組織が他の組織のメンバー/フレンドになることができます。 FriendとMemberは異なります。Friendsは読み取り専用のようなものであり、[レベルに応じて]メンバーは変更するためのフルアクセス権を持っています。 さらに複雑なことに、ロケーションには独自の「さらに」洗練されたルールのセットがあります。たとえば、組織は2つのロケーションを所有しますが、ロケーションルールによっては、その組織のメンバー[ プロファイル ]が1つのロケーションでフルアクセスできますが、その他。[申し訳ありませんが、表示サイズを上げるには、別のウィンドウで画像を開く必要があります。] ご覧のように、プロファイルと組織の概念はほとんど同じです。これは、モデル化されていない友達とメンバーの概念です。[...オーナー/レコード内の管理者/メンバー/友達など]。したがって、なぜ私は次の概念を考えているのですか？ 上の画像のOption.2を参照してください。これは、現在の組織とOrganization_Locationsテーブルとそれらの関係を削除し、プロファイルとのやや再帰的な関係としてOption.2組織テーブルに置き換えます。 問題の核心は、私が多態性をプログラム的に気にしすぎて、単純さと柔軟性を損ない、プロセスで完全に混乱しているのかどうかだと思います;） 事前にあなたの考えをありがとう、大いに感謝-M :)。 改訂された図： MDCCLの質問への回答： はい、プロフィールは1人の人物で構成され、同じ意味を持っています-あなたの理論的根拠が向かっているところに-私はあなたが正しいと信じています：組織と人物はプロフィールのサブタイプである可能性があります。したがって、プロファイルは1人または1つの組織で構成されます。 プロファイルごとに1つのメールアドレス。 はい。上記のように、組織には少なくともメールアドレスが必要です。 正しい、1つの固定アドレス。 それは可能性ですが、まれです-私が学んでいることから-したがって、将来の寿命などのためにそのようなモデルを作成する必要があります。したがって、確認のために、ロケーションは複数の人が所有することができます。 場所は間違いなく他のほとんどの間の不可欠なエンティティです。おそらく私はここで簡潔に何ができるかを明確にし、次にこの質問への有益な追加にうまくいけば私の他の答えを最初に読んでみましょう[ そして最後に＃6への私の答えを見てください ];）Re：役割の所有者 An **Organization** can be an Owner of zero or more **Locations**. A Person can be an owner of zero of more Locations[したがって、以前に推測したとおり。簡単に言えば、プロファイルは0個以上のロケーションの所有者になることができます。 はい、ロケーションの所有者であるプロファイルは、すべてのロール権限[スーパーユーザー]を想定しています。プロファイルで管理者は、特定の細部修正できる場所が、主に他のすべてを介して供給された詳細/データ編集/助けプロファイルを/ S …
2
IPアドレスの保存-varchar（45）とvarbinary（16）
2つのフィールド（IDas BIGINTおよびIPAddressas varchar(45)またはor）を持つテーブルを作成しますvarbinary(16)。アイデアは、すべての一意のIPアドレスを保存し、他のテーブルのID実際のIPアドレスの代わりに参照を使用することIP addressです。 一般的に、ID与えられたforを返す、IP addressまたは（アドレスが見つからなかった場合は）アドレスを挿入して生成されたを返すストアドプロシージャを作成しますID。 多くのレコードがあることを期待しています（正確な数はわかりません）が、上記のストアドプロシージャをできるだけ速く実行する必要があります。それで、実際のIPアドレスをテキストまたはバイト形式で保存する方法を知りたいです。どっちがいいの？ SQL CLRIPアドレスのバイトを文字列に変換したり、その逆を行ったりするための関数をすでに作成しているため、変換は問題ではありません（IPv4およびの両方で機能しますIPv6）。 検索を最適化するためにインデックスを作成する必要があると思いIP addressますが、クラスター化インデックスにフィールドを含める必要があるのか、または別のインデックスを作成し、どのタイプで検索を高速化するのかわかりませんか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.