問題タブ [data-modeling]

私の要件は、すべてのオブジェクトのすべての属性の変更に対して完全な監査証跡が保持されるデータ モデルです。オブジェクトの定義も流動的です。時間の経過とともに、新しい属性が現れたり消えたりする可能性があります。この監査証跡は元のデータベースとは別に存在するため、トリガーベースの監査モデルは機能しません。

リレーショナル データベースでは、1 つの大きな ATTRIBUTE_HISTORY テーブルを使用してこれを実装できます。このテーブルは、適切なタイムスタンプ フィールドと責任フィールドを使用して、各属性に対する個々の変更をすべて記録します。

私の質問: 新しいストレージ モデル (BigTable、HBase、CouchDB、RDF ストアなど) は、この目的で RDBMS よりも優れていますか?

検索可能なバージョン管理が必要な wiki アプリケーションを作成しています。これに最適なデータモデルは何ですか?

私は Django で書いていますが、それほど重要ではありません。

すべての番号が適合する電話番号の形式はありますか? （市外局番3桁、残り7桁よりも柔軟なもの）

歴史上の人物について、さまざまな情報源が語っていることを記録したいと思います。すなわち

• ウィキペディアのウェブサイトによると、スーザン B. アンソニーは 1820 年 2 月 15 日に生まれ、好きな色は青でした。
• 闘争の世紀という本には、スーザン・B・アンソニーは1820年2月12日に生まれ、彼女の好きな色は赤だったと書かれています
• 女性参政権の歴史という本は、スーザン・B・アンソニーは1820年2月15日に生まれ、彼女の好きな色は赤で、彼女はエイブラハム・リンカーンの2番目のいとこであったと述べています

また、研究者には、これらの情報源が行っている個々の主張について、たとえばパーセンテージで自信を示すことができるようにしてほしい. すなわち

• ユーザー A は、スーザン B. アンソニーが 1820 年 2 月 15 日に生まれたことを 90% 確信しています。彼女の好きな色が青であるという確信は 75%、エイブラハム リンカーンの従兄弟であるという確信は 30% でした。
• ユーザー B は、スーザン B. アンソニーが 1820 年 2 月 12 日に生まれたことを 30% 確信しています。彼女の好きな色が青であるという確信は 60%、エイブラハム リンカーンの従兄弟であるという確信は 10% でした。

次に、各ユーザーに Susan B. Anthony のビューを表示して、彼女の誕生日、好きな色、およびユーザーが真実である可能性が最も高いと考える関係を表示するようにします。

私はリレーショナル データベース データストアも使用したいと考えています。これを行うには、ユーザーが信頼を表明できるようにするアトミック ファクトの個々のタイプごとに個別のテーブルを作成することが考えられます。この例では、合計で 8 つのテーブルがあり、3 つの個別のアトミック ファクトに対して 3 つの個別のテーブルがあります。

これは、実際には多くの種類のアトミック ファクトを記録する必要があるため、非常に急速に複雑になるように感じます。これを行うためのより良い方法はありますか?

これは、Martin Fowler が「矛盾した観察」と呼んでいる問題と同じだと思います。

プロジェクトの MVC パラダイム (CakePHP) を使用して、ソーシャル ネットワーキング サイトのシンプルなデザインを作成しています。すべてのユーザーの詳細を格納する Users というテーブルがあり、すべてのグループの詳細を格納する Groups テーブルがあります。これら 2 つのモデル間の関係は多くのものに属しており、グループに属するすべてのポートフォリオを格納する group_portfolios テーブルと、ユーザーに関連するすべてのポートフォリオ情報を格納する user_portfolio テーブルがあります。ユーザーは複数のポートフォリオを持つことができます グループは複数のポートフォリオを持つことができます ユーザーは多くのメディアを持つことができます グループは多くのメディアを持つことができます

ユーザーとグループに関連付けられたメディアの機能を分離しました。私の質問は、

1) MVC アプリケーションのモデリングに関して、私は正しい方法で考えていますか?
2) ユーザーとグループの機能を分離しているため、メディアやポートフォリオなど、それらに関連するすべての情報を表す 2 つのテーブルができあがっています。これにより、特にポートフォリオなどを検索するときに、冗長性やパフォーマンスに関連する問題が発生しますか?
3) 後で機能を追加したい場合、これは拡張できますか?
4) システムをモデル化するためのより良い方法はありますか?

ありがとうございました

ユーザー入力を永続化する一連の汎用データベース テーブルを構築するというアイデアを評価しています。次に、ワークフローを開始して入力を処理するための二次プロセスがあります。

初期のユーザー入力を保存するという概念は、処理して特定のアプリケーションの構造化されたスキーマに入れることとは別のものであるという考え方です。

例としては、ある種の求人への応募や自由回答式のクイズなどがあります。生の回答は、人間による分類がなければ、集計レポートにとってそれほど価値がありません。しかし、生の入力を履歴レコードとして保存したいと考えています。

また、ユーザーが一部の情報を部分的に入力し、ユーザーが戻るまで保持できるようにすることもできます。

アプリケーション固有のデータスキーマに入れることができるポイントまですべての入力を処理することは、すべてのデータを取得するまで不可能な場合があります。

2 つの最初の質問:

1. この概念に名前があると仮定すると、それは何ですか?
2. これは合理的なアプローチですか？なぜですか、そうでないのですか？

アップデート：

アイデアを述べる別の方法を次に示します。ユーザーは、DTO のフィールドに順番に入力しています。部分的に完成した状態でも DTO をディスクに保存したい (と思う)。ユーザーがフィールドへの入力を完了したら、DTO を取り出して、特定の DTO を表すテーブルに構造化された保存のために処理したいと考えています。ただし、入力の一部は実際には構造化レコードの一部として保存されるべきではないため、部分的に完了した、または (さらに悪いことに) 一時的に正しくない入力セットを保存することはできません。

私の考えは、任意のタイプの DTOを保存し、必要に応じて特定のアプリで処理するためにそれらを引き出す一般的な方法を作成することです。したがって、この一般的な DTO テーブルには、顧客満足度調査に関するデータが、新しいアカウント セットアップ ウィザードで回答された質問のすぐ隣に格納されている可能性があります。

既存のMySQLデータベースのデータベースモードを簡単に作成できるソフトウェアを探しています

設計スキルを従来のRDBMSデータストアからAppEngineデータストア（つまり、「ソフトスキーマ」スタイル）に移行するのに役立つリソースを探しています。私はいくつかのプレゼンテーションを見てきましたが、すべてが包括的なテーマといくつかの特定のテクニックに触れています。

データの構造、特に既存のアプリケーションの移植方法を再考するための実際のアプローチに関する経験（「溝から」）からの知識をプールできる場所があるかどうか疑問に思います。私たちはHibernateをベースにしており、おそらくデータモデルを使って少し間違った道をたどり、DBが苦労しているいくつかの厄介なクエリを生成しています。

次の場合に返信してください。

1. 重要なアプリケーションをAppEngineに移植しました
2. AppEngineで一般的なタイプのアプリケーションを最初から作成しました
3. あなたは1も2もしていませんが、それを検討していて、これまでのところあなた自身の発見を共有したいと思っています。

最近、データ モデリングについて少し読んだことがありますが、エンティティが果たす役割について質問があります。

会社があり、会社がサプライヤー、顧客、ディストリビューターなど、またはこれらの役割の組み合わせであるという単純なケースを考えてみましょう。したがって、会社 X はサプライヤーと顧客の両方である可能性があります。

データ レベルでは、CompanyS のテーブルがあり、次に Company テーブルを参照する SupplierS、CustomerS などのテーブルがある場合があります。少なくとも、これはそれがどのように表現されるかだと思います。

さて、アプリケーションランドのどこかに、CustomerS や SupplierS などのクラスがあります。それぞれが Company で構成され、その特定のクラスに関するその他の特別な要素が含まれます。

一度に 1 つのエンティティ クラスだけを操作する限り、これで問題ありません。会社から始めて、それがどのような役割を果たしているのかを確認したい場合はどうすればよいでしょうか? したがって、アプリケーションで Company をプルアップすると、それがサプライヤーとディストリビューターであることがわかります。

これを行うにはいくつかの方法が考えられますが、この問題領域は非常に古いため、これらの概念をモデル化するための実証済みの真のパターンが必要であると感じています。

したがって、私がここで探しているのは、アプリケーション レベルでエンティティ ロールをモデル化するための一般的な戦略またはパターンです。この特定のテーマに関する特定の参考資料は大歓迎です (ブログや書籍など)。

私が思いついたこのデータモデルを見ていますが、快適ではありません。エンティティ名を変更したので、（うまくいけば）より意味がありました。いずれにせよ、以下をどのようにモデル化しますか?

私は3つのエンティティを持っています。政府顧客、個人顧客、公共顧客。プライベート カスタマーとパブリック カスタマーはどちらも CorporateCustomer です。企業および政府の顧客はアカウントです。すべてのアカウントは同じキー スペースを共有します (したがって、PrivateCustomer の PK が 1 の場合、Public または GovernmentCustomer の PK が 1 になることはありません)。CorporateCustomers には、GovernmentCustomer にはない 1:M の関係があります。PublicCustomers には、PrivateCustomers にはない 1:M の関係があります。

継承:

現在、私のモデルには 5 つのテーブルがあります。「アカウント」テーブルはこの階層のルートであり、各子テーブルの PK はその親の PK の FK です。したがって、すべてのテーブルの PK は同じです。

ええ、これをどのようにモデル化しますか？ここで何かが大きく間違っていないことを願っています:)。

編集：

また: - アプリではなく、DB が ref の整合性を処理するようにしたいと思います。- CorporateCustomer は、Private または Public のいずれかの顧客にならずに存在することはできません。その抽象。