問題タブ [modeling]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
architecture - オープンなレイヤード アーキテクチャとクローズドなレイヤード アーキテクチャとは何を意味するのでしょうか?
非常に些細な質問に聞こえるかもしれませんが、インターネット上でリソースを見つけることができませんでした。
オープン レイヤード アーキテクチャとクローズド レイヤード アーキテクチャとは何か、オープン レイヤード アーキテクチャの保守が明らかに難しい理由を教えてください。クローズド/オープン レイヤード アーキテクチャを使用することの欠点はありますか?
database - データベースのメタデータ リポジトリを設計するために従うべきガイドラインはありますか?
内部データベース用のメタデータ リポジトリを設計したいと考えています。リポジトリは、次のような質問に対する簡単な回答を提供できる必要があります。どのテーブルにどのタイプのデータが含まれているか、テーブルの関係は何ですか? 従うべき業界標準のガイドラインはありますか?
database-design - 業界標準のデータベース モデリング言語は何ですか?
だまされてこれを閉じることに投票する人がいる前に、私がこれまでに見つけたすべての質問は、データベース モデリングに適した特定のプログラムに関する質問であることを知っておいてください。私の質問は、リレーショナル データベースをモデル化するための業界標準言語(存在する場合) は何ですか?
UML は一般的に、特に OOP モデリングで非常に人気があり、現在読んでいる本の著者 (Davidson による「Pro SQL Server 2005 データベースの設計と最適化」) は IDEF1X を使用しています。MS Visio は IDEF1X をサポートしていますが、多くの特定のシンボル (「リレーショナル」シンボル セットと呼ばれる) を持たない一般的なモデリング言語のように見えるものにデフォルト設定されていますが、Visio は Office スイートの一部であるため、かなり標準的であることはわかっています。
では、夏のインターンとして履歴書を作成しようとしている場合、業界で将来的に最も役立つモデリング言語はどれでしょうか?
c# - 余分なフィールドを持つOne-Manyテーブルからクラスを設計する
データベース内のOne-Manyリレーションシップからクラスに戻す追加のプロパティをモデル化するにはどうすればよいですか?
たとえば、Model、Manager、Model_Managerの3つのテーブルがあります。Model_Managerテーブルには、ModelId、ManagerId、および2つの追加プロパティ(PercentageとOwner)があります。
最初に、ManagerとModelの2つのクラスを作成しました。Modelクラスには、1-ManyリンクをキャプチャするためのManagerのコレクションが含まれています。
しかし、ここで、追加のパーセンテージと所有者のプロパティをどこに配置しますか。「実際の」クラスでなくても、実際にModel_Managerクラスをデザインに含めることは理にかなっていますか?
java - Flex / Java Web アプリに推奨されるデータ モデリング ツールとテクニックは何ですか?
私はあなたがすでにうまく使っている包括的なセットアップを探しています。どのビルディング ブロックを使用するかについてのヒントはすでにたくさんありますが、それらをすべて組み合わせる方法がわかりません。購入が必要な工具もOK。
詳細:
Java サーバー アプリケーション用の Flex フロント エンド クライアントを開発しています。ビジネス ロジック内のオブジェクトを表す一連のモデル クラスがあり、すべてのレイヤーで同じプロパティを持ち、同じ動作を示す必要があります。これらのオブジェクト
- ユーザー入力用のフォーム検証ロジックがある
- UI全体でさまざまな形式(リスト、詳細ビューなど)で表示されます
- XMLまたはAMFを使用してサーバーから取得および送信されます
- サーバー上で再度検証されます
- クラスとフィールドに対応するテーブルとフィールドを含む RDBM に格納されます
これは非常に一般的なアプリケーション構造だと思います。私はすでに使用しています:
- Java バックエンドの ORM (Eclipse 永続パッケージ)
- こちら で説明されているように、XML スキーマと mx.rpc.xml のクラスを使用して、XML からアクション スクリプトへの自動マッピング。
ここで、私が実際にやりたいことは、オブジェクトを 1 回定義し (既に XSD に持っています)、ツールでチェーン全体のクラス スタブをセットアップすることです。何を使用できますか?
私はすでに聞いたことがあります(ただし評価はしていません):
- XML スキーマから Java クラスを生成する XMLBeans
- Java クラスから AS クラスを生成する Granite DS
uml - UML に対する LePUS3 の利点は何ですか?
コンポジット デザイン パターンなどのオブジェクト指向の概念をオンラインで検索すると、それらが LePUS3 表記で表されていることがよくありました。私はこのモデリング言語にあまり詳しくありません。
UMLよりも優先すべきものですか?
model - UML: 他のアクティビティを作成/変更するアクティビティのモデル化
ある組織の行動モデルを構築するとしましょう。具体的には、組織内で行われるすべての活動 (「入札」、「注文の履行」、「出荷」などの活動) を記述する一連の活動図を作成します。 」など)。
現在、組織における重要な活動の 1 つは、すべての活動自体を確立し、維持することを含むものです。そのアクティビティをモデル化しながらオブジェクト フローを表示したい場合、そのような入力/出力をアクティビティとしてどのように正確に表現しますか?
たとえば、UML メタモデルの Activity クラスのインスタンスであるオブジェクトを使用することは意味的に正しいでしょうか? (私が使用している UML モデリング ツールでは、そのようなオプションはありません。ツールが無知なためですか、それとも、メタモデルからのクラスのインスタンスをモデルに含めることを想定していないためですか?)
jpa - JPAでポリモーフィックな関連付けを表現するにはどうすればよいですか?
ポリモーフィック アソシエーションは、外部キーまたは多対 1 の関係に似ていますが、ターゲットが多くのタイプ (言語のクラス、データベースのテーブル) のいずれかであるという違いがあります。
数年間使用してきたデータベース設計を PHP から Java に移植しています。古いコードでは、独自の ORM を展開していましたが、これは多くの理由で最適ではありませんでした。後で微調整を開始し、自分で再度実装することになるかもしれませんが、今のところ、エンティティ クラスで市販の ORM と JPA を使用したいと考えています。
データベースのレイアウトについて、JPA で表現する方法がわからないことが 1 つあります。
Node
グラフを格納するテーブルがEdge
あります(重要な場合はDAG)。各ノードは、必要に応じて、データベースから別のエンティティを 1 つ参照できます。これらのエンティティは、グラフ全体で複数回参照される可能性があり、ユーザーがアクセスできない「孤立した」エンティティも存在する可能性がありますが、少なくともしばらくの間保持することは理にかなっています。
これらのオブジェクトは、継承などの点でまったく関連していませんが、Customer->Site->Floor->Room のような自然な階層を持っています。実際、何年も前に、「親」オブジェクトを指す外部キー フィールドだけから始めました。しかし、この階層は十分に柔軟ではなく、バラバラになり始めました。
たとえば、ユーザーがフォルダー内のオブジェクトをグループ化できるようにしたいのですが、一部のオブジェクトは複数の「親」を持つことができ、時間の経過とともに関係が変化します。以前の関係を追跡する必要があるため、グラフのエッジにはタイムスパンが関連付けられており、そのエッジがいつからいつまで有効であったかが示されます。
ノードからオブジェクトへのリンクは、ノード テーブルの 2 つの列に格納されます。1 つは外部テーブルの ID を保持し、もう 1 つはその名前を保持します。例 (一部の列は省略):
JPAを使用する以外の解決策があるかもしれません。テーブルのレイアウトを変更したり、新しいテーブルを導入したりすることもできます。ただし、これについてはすでによく考えており、テーブルの構造は問題ないように思えます。思いもよらなかった第3の方法もあるかもしれません。