12

データストレージの技術を学ぼうとして、私はできるだけ多くの確かな情報を取り入れようとしています. PerformanceDBA は、特に次の投稿にいくつかの非常に役立つチュートリアル/例を投稿しました:私のデータは正規化されていますか? およびリレーショナル テーブルの命名規則このモデルのサブセットについては、すでにここで質問しました。

だから、彼が提示した概念を理解していることを確認するために、私は物事をさらに一歩か二歩進めて、概念を理解しているかどうかを確認したかった. したがって、この投稿の目的は、他の人も学ぶことができることを願っています. 私が提示するものはすべて、私にとって概念的なものであり、生産システムに適用するのではなく、学習するためのものです。私は PerformanceDBA のモデルを使用して作業を開始したので、PerformanceDBA からも情報を得ることができれば素晴らしいと思いますが、どなたからも情報を提供していただければ幸いです。

私はデータベース、特にモデリングに慣れていないので、このテーマに関する専門知識が不足しているため、常に適切な質問をしたり、自分の考えを明確に説明したり、適切な言葉遣いを使用したりするとは限らないことを最初に認めます。ですから、それを心に留めておいてください。私が軌道から外れた場合は、遠慮なく正しい方向に導いてください。

これに十分な関心がある場合は、これを論理フェーズから物理フェーズに移して、プロセスの進化を示し、スタックで共有したいと思います。ただし、論理ダイアグラム用にこのスレッドを保持し、追加の手順のために新しいスレッドを開始します。私の理解では、最後にMySQL DBを構築していくつかのテストを実行し、思いついたものが実際に機能するかどうかを確認します。

これが、この概念モデルで捉えたいもののリストです。V1.2用に編集

  1. これの目的は、バンド、そのメンバー、および彼らが出演するイベントを一覧表示し、音楽やその他の商品を販売することです。
  2. メンバーは友達とマッチングできます
  3. メンバーは、バンド、音楽、イベントについてレビューを書くことができます。
    • メンバーはレビューを編集することができ、履歴は維持されますが、特定のアイテムについてメンバーごとに 1 つのレビューしかありません。
    • BandMembers は、関連付けられているバンドに関するレビューに 1 つのコメントを書く機会があります。バンド全体として、1 つのレビューにつき 1 つのコメントのみが許可されます。
    • その後、メンバーはすべてのレビューとコメントを評価できますが、特定のインスタンスごとに 1 回のみです。
  4. メンバーは、お気に入りのバンド、音楽、商品、イベントを選択できます
  5. バンド、曲、およびイベントは、ジャンルのタイプに分類され、必要に応じてサブジャンルにさらに分類されます。バンドまたはイベントが複数のジャンル/サブジャンルの組み合わせに分類されることは問題ありません。
  6. 特定のバンドのイベントの日付、時間、場所が掲載され、メンバーはイベントに参加することを示すことができます。イベントは複数のバンドで構成することができ、同じ日に 1 つの場所で複数のイベントを開催することができます。
  7. すべての当事者は少なくとも 1 つのアドレスに結び付けられ、アドレス履歴が保持されます。各当事者は、一度に複数の住所に関連付けることもできます (つまり、請求、配送、物理)。
  8. Bands、BandMembers、一般メンバーのプロフィールが保存されます。

少し複雑かもしれませんが、プロセスが進化し、コミュニティからの情報が提供されるにつれて、うまくいけば多くの人にとって素晴らしい学習ツールになる可能性があります. 入力はありますか?

代替テキスト

EDIT v1.1 PerformanceDBA への対応

U.3) これは、データベースにバンドの商品以外の商品がないことを意味します。正しい ? それが私の最初の考えでしたが、あなたは私に考えさせました。おそらく、サイトは独自の商品やバンドの他の商品を販売したいと考えているでしょう。そのために作るmodがわからない。カタログ セクション全体の作り直しが必要ですか、それともバンドとの識別関係のみが必要ですか? 完全なアルバムまたは曲の両方を販売するための mod を試みました。いずれにせよ、どちらもダウンロードのみが可能な電子形式になります。そのため、アルバムは 2 つの個別のエンティティではなく、曲で構成されていると記載しました。

U.5) Favorite との循環関係について、あなたが何を提起しているかは理解できます。「その処理を識別するのは、何らかの形式の差別化 (FavoriteType) を備えた 1 つのエンティティのいずれかである」ということを知りたいのですが、その方法が明確ではありません。ここで何が欠けていますか?

u.6)「ビジネス ルール これはおそらくあなたが苦手な唯一の領域です。」<br> 正直な回答をありがとう。私はこれらに再度対処しますが、最初に私があなたに返信した回答で頭の中の混乱を解消したいと思っています.

Q.1)はい、承認済み、拒否済み、ブロック済みを希望します。これが論理モデルをどのように変更するかについて、あなたが何を指しているのかわかりませんか?

Q.2)ユーザーである必要はありません。BandMember としてのみ存在できます。それはあなたが求めているものですか?

軽微な問題

0、1、またはそれ以上… モデルを作成するときに、この点に注意するのを忘れていたことを認めます。このバージョンをそのまま提出し、将来のバージョンで対処します。物事を理解していることを確認するために、制約チェックについてもっと読む必要があります。

M.4)将来の OrderPurchase を想定しているかどうかによって異なります。ここでの意味を拡張できますか?

代替テキスト

EDIT V1.2 PerformanceDBA の入力に応じて...

学んだ教訓。

  1. 私は、識別/非識別とカーディナリティ (つまり、ジャンル/サブジャンル) の概念を混ぜ合わせており、一貫性を欠いて物事を悪化させていました。
  2. 多対多の関係を描写してから物理モデルで展開できるため、論理ダイアグラムでは連想テーブルは必要ありません。
  3. 私は多くの関係でカーディナリティを見落としていました
  4. 効果的な動詞句を使用して関係を読み、達成したいことをモデル化していることを確認することの重要性.

U.2) このモデルの概念では、イベントの場所として会場を追跡することだけが必要です。それ以上のデータを収集する必要はありません。そうは言っても、イベントは特定の EventDate で開催され、会場で開催されます。会場では、特定の日に複数のイベントが開催され、場合によっては複数のイベントが開催されます。私の新しいモデルでは、 EventDate はすでに Event に関連付けられていると考えていました。したがって、Venue は EventDate との関係を必要としません。U.2) の下にリストされている 5 番目と 6 番目の箇条書きは、私の考えに疑問を投げかけています。ここで何か不足していますか?

U.3)アイテムとバンドの間のリンクをアイテムとパーティに移動する時が来ましたか? 現在のデザインでは、ご指摘のバンドに関係のない商品を販売する可能性はないと思います。

U.5)私は、個別のスーパータイプ/サブタイプの関係にするのではなく、あなたの入力に従って残しました。

追加の改訂

AR.1) FavoriteItem の演習を行った後、Item to Review には多対多の関係が必要であると感じたため、それが示されています。必要? ここに画像の説明を入力

では、v1.3 に進みます

このバージョンでは、デザインを行ったり来たりして数日かかりました。論理的なプロセスが完了したら、正しい軌道に乗っているかどうかを確認したいので、学んだことと、このプロセスを経る初心者として直面した問題を深く掘り下げます。このバージョンの大きなポイントは、過去に欠けていたものを確認するためにいくつかのキーを投入する必要があったことです. マトリックスを実行するプロセスを経ることも、大きな助けになることがわかりました。いずれにせよ、PerformanceDBA からの情報提供がなければ、私は暗闇の中で迷子になっていたでしょう。私の現在のデザインは、私がまだそうであることを再確認するかもしれませんが、私は多くのことを学んだので、少なくとも懐中電灯を手に持っていることを知っています.

現時点では、識別関係と非識別関係についてまだ混乱していることを認めます。私のモデルでは、モデル化したい関係を結合するためだけに、null 以外の非識別関係を使用する必要がありました。この主題について多くのことを読んでいると、この主題について多くの意見の相違と優柔不断があるように思われるので、私は自分のモデルで正しいことを表していると思うことをしました。いつ強制するか (識別)、いつ解放するか (非識別)? 誰でも入力がありますか?

ここに画像の説明を入力

編集 V1.4

わかりました、V1.3 の入力を取り、この V1.4 用にクリーンアップしました

現在、属性を含めるために V1.5 に取り組んでいます。

ここに画像の説明を入力

編集 V1.6

さて、ここに投稿してからしばらく経ちましたが、このプロジェクトの作業はまだ進行中です。V1.4 の前回の投稿から多くの変更を含む V1.6 を投稿しています。このバージョンは、キーのさらなる進化を示しています。属性や AK や IE はまだ含まれていません。私は物理モデルの作業を開始し、それを使用して属性の作業を支援し、AK と IE の定義に関する問題に光を当てようとしました。論理モデルの次の投稿には、これらのキーと属性が含まれます。

ここに画像の説明を入力

4

2 に答える 2

9

了承

私が言わなければならないのは、あなたは(a)前の質問で提供されたモデリング要素を把握し、(b)それらを適用することで素晴らしい仕事をしたということです。あなたはたった1日で長い道のりを歩んできました。正しい教育を受ければ、有能な人々は素晴らしいことをする力を与えられ、自分の力を発揮することができるという事実の素晴らしい補強です。

方法

あなたが述べた目的と実証された能力(言うまでもなく、私がSOで扱った最初のシーカー、大量のDDLの代わりにERDを投稿したDb Designの質問)を考えると、私は答えを提供しません。私はあなたに指示とガイダンスを与えます、そしてあなたはあなた自身のモデルを進歩させなければなりません。

もちろん、詳細についても説明しますが、すべてではなく、1つまたは2つのサブジェクトエリアについて完全に説明します。あなたはそれを拾い上げて、すべての主題分野にそれを適用することができます。

エンティティの識別をまだ扱っているため、コアサブジェクトエリアには応答していません。それが解決されるとReviews、などが簡単になります。トランザクションエンティティは、識別エンティティに依存しています。

方向

D.1)モデル全体を見る必要があると述べたことを知っています。例外が1つあります。履歴データまたは時間データまたは監査データ(例:編集および保存されたバージョン)。この初期段階では、それらを脇に置くことができます。論理モデルが完成する直前に実装されます。これは、(a)一部の親の単純な依存関係である(b)最初に他のすべてのテーブルに関連して親をモデル化する必要があること、および(c)不要な複雑さを排除することで、関連することに集中できるようにすることを認識しています。分野。

  • 特に、動詞句の時制は無視できます(バージョンテーブルのすべての場所で必要になりますHas/Had)。焦点はアーカイブではなくモデリングであるため、今のところ現在形を維持します。

未解決

U.1)
完全に許可されていないオプションの親。IDEF1Xだけでなく、整合性の概念によっても。FK参照が定義されている場合は、親が存在する必要があります。オプションの親を許可するには、FKリファレンスを削除する(または実装しない)必要があります。そのような条件は、定義上、「リレーショナルデータベース」としての資格からの結果を除外します。例えば。Address:Order

  • もちろん、先進国では、法律上または税務上の理由から、Orderが必要です。Addressこれは、標準要件の問題とは別のものです。

U.2)イベント
Party::PartyAddressは正しいです。Address::PartyAdress正しい。Event::Address作業が必要です。アドレスは識別参照テーブルです。使用する場合、それは親にEventなり、子になります。Events複数の場所、およびEvents1つまたは複数の場所 を識別/モデル化するのはあなたに任せます。

  • 関係する会場があるかもしれません。またはEventOccurrence

  • しかし、それが複数の場所で発生するジェネリックEventであり、エンティティを必要としない場合、AddressはすでににありOrderます。

U.3)仮定Catalogは、従来の意味でのエントリ(JCPenney 2011)であり、販売またはレンタルするアイテムのリストです。

  • OrderSaleItem正しい

  • 重要なポイント。は依存関係にあり、AsssetとしてCatalogのコンテキストでのみ存在できます。Band罰金。つまり、データベースにはバンド商品以外の商品はありません。正しい ?

  • 「ブルース・ブラザースとのイブニング・パフォーマンス」が、Event注文、請求、支払いが可能なものであることがわかります。また、レビュー、コメントなど。

  • Songそれにどのように適合するのかわかりません。バンドはアルバム、曲、またはその両方を販売していますか?

  • 他にバンドの商品はありません:コンサート/イベントのお土産。ポスター; 刻まれたショットグラス?

  • 参照する命名規則およびデータベースの残りの部分と一致して、Catalog(コテント)にItem(行)という名前を付ける必要があります。あなたはすでに(当然のことながら?)OrderSaleItem、(ではなく、でそれを使用していOrderSaleCatalogます。

U.4)ジャンル

  • で問題ありませんan Item is classified by one-to-many Genres

  • さらに思いますa Genre classifies one-to-many Items。関係は1対多です(物理に到達すると、連想テーブルとして解決されます)。

U.5)お気に入り
のカーディナリティItem::Favoriteが逆になっています。これを修正すると、Favoriteサブジェクトエリアはさらにモデリングする必要があります。

  • エンティティの同じペア間の循環関係またはデュアルパスは、未解決のモデルのシグナルです。通常、1つは正しく、もう1つは冗長です。(例外はありますが、ここにはありません。これが発生すると、動詞句がそれらを区別します。)

  • 両方ではなく、どちらかのBand::FavoritexorItem::Favoriteが正しい。

  • Item::FavoriteBandですでに識別されているので、正しいようですItem

  • 同様に、Favoriteバンド商品の1つのエンティティは堅実に聞こえません。単一のFavoriteエンティティ内のすべての識別子はPartyです。正規化すると壊れますが、この段階で識別子を明確にすることを要求することもできます。FavoriteTypeそれは、その扱いを識別する何らかの形の差別化()を持つ1つのエンティティのいずれかです。または、1つFavoriteはバンド用、もう1つは商品用であり、この場合、区別は必要ありません。あいまいさは排除されます。

U.6)ビジネスルールこれはおそらくあなたが苦手な唯一の分野です。一般的な対応。タスクを個別に実行しました(すべてのモデリングとBRの作成)。これらはモデルと一致しません。次のサイクルを実行するときは、ビジネスルールをディレクティブとして使用し、エンティティ、リレーション、動詞句の場合と同様に、それらを同時に調整します。

質問

Q.1)ユーザー/友達
あなたはそれの本質を完全に持っています。そして、関係のカーディナリティ。(これは完全に処理されます。)これは、Acceptedの場合は正しいですFriend

  • したがって、時制は過去である必要があります(過半数の行に移動します)

  • Requested、および保留中Acceptedのは少数派です。IsAcceptedビットまたはブールで簡単に実装できます。

  • 後であなたはまたはを持っているかもしれませんIsRejectedIsBlocked後者は別のエンティティでなければなりません)。

  • それはあなたが必要とするものですか?

Q.2)の根拠は何Person is zero-to-many Usersですか?

マイナーな問題

M.1)単数のみ。

M.2)Party Has zero-to-many Addresses。私は彼らがビジネスを取引するためにそれを持っていなければならないと思います(しかしおそらくすべてのためではありませんUsers)。

M.3)Order May Have zero-to-many Payments。「必須」とは、最初Paymentに。と同時に挿入する必要があることを意味しOrderます。

  • 同様に、必須の子(0対多ではなく1対多)の場合、最初の子を親と同時に挿入する必要があります。即時制約チェック(遅延ではない)が実装されているため、これはエンタープライズデータベースのトランザクションを介して行われます。そして、町の小さな端は、遅延制約チェックのような愚かなことをめぐって戦い、「より良い」ものであり、彼らが作成した無限ループに巻き込まれないようにする方法を考え出すために人生の半分を費やします。MyNonSQLには何もありませんので、この実装について心配する必要はありません。

M.4)OrderSaleItemxorでOrderItemあるOrder必要がありますOrderSale。あなたが将来想像OrderPurchaseするかどうかに依存します。

▶サブジェクトエリアの例◀

リレーショナルデータベースのモデリングの標準に慣れていない読者は、▶IDEF1X表記◀が役立つと思うかもしれません。

述べたように、私は完成したデータモデルを提供するのではなく、ガイダンスのみを提供します。これは、選択した1つのサブジェクトエリアの1つの進行にすぎません。それは「正しい」または完全ではありません。

  • あなたの動詞句は素晴らしいです。私はあなたが検討するための代替案を提供しました、それらは「正しい」または「より良い」ではありません。あなたは彼らまたはあなた自身の進歩を選ぶ必要があります。目標は、いずれの場合も最も簡潔で正確なVPです。

  • Person正解と不正解の提案はありませんUser。それはあなたの答えを待っています。しかし、私はモデルで何かを使わなければなりませんでした。それらを別々にモデル化したので、対位法を評価するのは興味深いかもしれません。

では、先に進んでモデルを進めてから、もう一度投稿してください(質問を編集し、ヘッダーパラグラフを残して、残りを置き換えてください)。

V1.1と応答

それは確かに進歩です。

セクションの見出しを含め、アイテムに疑似法的な形式で番号を付け直しました。これにより、番号をずっと維持し、追加し続けることができます。実際、SO編集の問題も本当に緩和されます。

U.3)カタログセクション全体を作り直す必要がありますか、それともバンドとの関係を特定するだけですか?

  • いいえ。これは、このレベルで作業することの素晴らしい点です。ここで行う決定は、データが貨物として実行される、または実行されない鉄道線路になります(したがって、派生するために代替の輸送と重労働が必要になります。大量のコードまたは追加のデータウェアハウスの形式)。そして、ここでの決定は安価です(モデリング時間、紙)。

  • 現在、アイテムはバンドのコンテキストにのみ存在します。扶養家族です。バンド以外の商品を許可するには、独立している必要があります。次に、既存のスーパー/サブタイプクラスターを作り直す必要があります。

完全なアルバムまたは曲の両方を販売するためにmodを試みました。いずれにせよ、どちらもダウンロードのみが可能な電子形式になります。そのため、アルバムを曲で構成されているものとしてリストしました

  • Ok。しかし今では、曲ではなくアルバムのみを販売できます。

2つの別々のエンティティではなく。

  • 意味がわかりません(2つの別個のエンティティがあります)。

  • 私の▶サブジェクトエリアの例◀を見たことがないようです。 ここで開くと、V1.1を追加したビットが含まれていることに注意してください。私は昨日そこにあったもの、V1.0の応答を変更していません。

  • 実際には、例を見ながら、V1.0の回答をもう一度確認する必要があることを意味します。

U.5)...しかし、その方法は私にはわかりません。ここで何が欠けていますか?

  • 差別化された1つのエンティティの例は、所有しているスーパータイプ/サブタイプクラスターのいずれかです。お気に入りはスーパータイプで、BandFavouriteとItemFavouriteはサブタイプです。それぞれがBandxorItemをそれぞれ参照できるようにします。

  • ItemFavouriteをモデル化しました。ここで問題は、ItemFavouriteの事実は、バンドがFavouriteであることを意味するのかということです。またはBandFavouriteは個別の事実ですか?この例では、Favourite :: ItemFavourite / BandFavourite構造を使用せずに、後者をモデル化しました。

Q.1)はい、承認、拒否、ブロックしたいのですが。これが論理モデルをどのように変えるかについて、あなたが何を参照しているのかわかりませんか?

  • V1.0への変更はありません(すでにかなり完了していると述べました)が、追加のエンティティが必要になる場合があります。

  • Friendには3つのビットまたはブールインジケーターが必要です。それはこれらのステータスにサービスを提供します:

    • Requested(ただし、受け入れられません)
    • Requested & Accepted
  • しかし、BlockedはFriendではありません(または以前はFriendであった可能性がありますが、Blocked以降はそうではありません)。したがって、エンティティ名を変更して(2つのリレーションを変更しない)xorBlockedを別のエンティティにする必要があることを反映する必要があります。2番目の関係の2つの別々の意味は複雑さにつながるため、後者を使用します。

前者には、追加のステータスがあります。

  • Blocked
    • 次に、動詞句を変更する必要があり(わかりやすくするためにRoleNameを含めます)、そのうちの1つには別の意味があります。。
    • (属性レベルのモデルでははるかに明確になるため、単語ではなく画像でモデル化するので、これを含めました。)

Q.2)ユーザーである必要はありません。それらはBandMemberとしてのみ存在できます。それはあなたが求めていることですか?

  • いいえ。なぜ人とユーザーを区別する必要があるのですか?個別のアクションまたは属性は何ですか?これまでのところ、私は個人とユーザーを同じエンティティと見なしています。人は活動のないユーザーです。

  • これは最後の項目であり、コアサブジェクトエリアを扱うことを妨げています。

M.3)物事を理解していることを確認するために、制約チェックについてもっと読む必要があります。

  • 今は心配しないでください。私はあなたにそれを単純に保つ理由を与えていました(NonSQLは物事を単純化するように見えますが、実際にはそれをより複雑にします)。MyNonSQLにはこれらの機能がないため、プラットフォームの考慮を排除し、カーディナリティを有意義にモデル化することができます。

M.4)将来OrderPurchaseを想定しているかどうかによって異なります。ここで何を意味するのかを詳しく説明していただけますか?

  • モデルのコンテキストで。(アイテムの)SalesOrdersを作成するための構造を提供します。したがって、Item、Order、およびOrde​​rItem。

  • ただし、PurchaseOrdersも追跡するための構造を提供した場合(アイテムや事務用品、家賃などを購入するため)、SalesOrdersとPurchaseOrdersを区別する必要があります。したがって:

    • アイテム
    • OrderSaleおよびOrde​​rSaleItem
    • OrderPurchaseおよびOrde​​rPurchaseItem

バージョン1.1

U.2)イベントが進行しました

  • EventDateはよさそうだ。関係をと定義しますEvent Was Perfromed On EvenDate

  • ItemGenreは完璧ですが、Event::Venueには作業が必要です。これはあなたが一貫して犯す間違いなので、説明が必要です。

    • 正しくモデル化されています。Venueこれは独立しており、のコンテキスト外に存在しますEvent。しかし、Event May Be [Held] At zero-to-many [Independent] Venuesそれは不可能です。

    • イベントは多くの会場で開催され、会場は多くのイベントを主催します。それがすべてである場合、これは論理レベルであるため、多対多の関係を描くことができ、それで完了です。物理レベルでは、その関係は、PKが2つの親PKであり、データがない連想テーブルを実装することによって解決されます。(敵は良い例です。)

    • ただし、データがある場合(たとえば、参加者の日付や数などを追跡する必要がある場合)、それは連想テーブルではなく、別のエンティティです。イベントと会場の間で行われること。

    • EventDateは良い候補です。私たちはすでにそれと日付を持っています。会場を追加してかき混ぜるだけです。イベントと会場の間で行われることをパフォーマンスと呼びます。

  • 同様に、EventAddressは進行していますが、完了していません。

    • イベントには住所がありますか、それとも会場には住所がありますか?(モデル化、言葉は必要ありません)

    • 会場の場合:会場のすべての過去の住所(パーティーなど)が必要ですか、それとも現在の住所(注文など)だけが必要ですか?

M.5)サブジャンル。SubGenreが(a)独立していて、(b)関係が非識別である理由を説明できますか。

M.6)Item Is zero-to-many Favourites。したがって:Item Is a Favourite of zero-to-many Users。同様に、Each User Chooses zero-to-many Favourites。したがってEach User Chooses zero-to-many Favourite Items

V1.2と応答

大きな進歩。

U.2)イベントがさらに進行

編集と新しい要件を確認します。一部は「はい」、一部は「いいえ」です。データモデルの他のすべてのサブジェクトエリアは(論理の場合)ほぼ完全です。この1つのエリアは混乱しており、ほとんど解決されていません。部分的に追加された要件のためです(苦情はありません、それは実際の生活で起こります;それはあなたがそれをどのように扱うかについてです)。

ここで私が指摘する主なポイントは、データモデルは、ビジネス要件だけではなく、常に現実の世界をモデル化する必要があるということです。これにより、(a)DMが変更の影響から隔離され、(b)追加の要件に対応する強固なプラットフォームが提供されます。これは、現実世界全体をモデル化する必要があるという意味ではありませんが、モデル化する部分は現実を反映している必要があり、要件だけを満たすために押しつぶされてはなりません。

第二に、イベント、バンドイベント、パフォーマンスなどの区別が明確ではありません。現在、イベントはパーティーバンドアイテムイベントです。それは問題ありませんが、要件ごとの新しいスタイルのイベントでは機能しません。

第三に、あなたは住所の再パーティーと注文をうまく処理できますが、再会場は処理できません。

  • 標準に準拠したモデルを受け入れているため、アドレスは参照テーブルです。

    • 独立しています(四角い角)

    • 実際には、アドレスとその上のすべてを1ページ目に配置できます。モデルページのこの部分を2つにし、このページにのみアドレスを設定します。

    • 正しくモデル化されている:パーティにはアドレスの履歴があります。少なくとも1つの電流が必要です{IsBilling| IsShipping | 実行されているアクティビティに基づくIsPhysical}アドレス。

    • 正しくモデル化:注文には1つのIsBillingアドレスがあります(IsShippingが必要な場合は、別のリレーションを追加する必要があります)。

  • 住所は会場の子ではありません(独立、正しい)。会場が0から多の住所にあるとは思いません。(おそらくそれは古いカーディナリティが逆転したバグですが、イベントと会場に関する他の混乱のため、私にはわかりません。)

  • 実際にAddress::Orderは疑わしいです。(Q.3)注文に有効な住所、または注文を実行する当事者の特定の住所を参照させますか?

  • イベントに戻る。宣言されたとおりにEventDateを受け入れます。それは問題ありませんが、レビューなどは、キノコで行った単一のコンサートではなく、一般的なコンサートに適用されます。V1.3に移行します。

    • イベントなどの用語は要件などと一致していますが、記載されている要件をサポートしていません。

    • それでは、「イベント」を実際の世界で使用されている方法で使用し始め、そのようにモデル化してみましょう。私たちが「イベント」と呼んでいるパーティーバンドアイテムは、実際にはパフォーマンスです。そして、予定されている一般的なものではなく、特定の会場での単一のものです。

    • これは、EventDateで意味したことであるか、EventDateがパフォーマンスに解決されます。

よろしければ、1000語の入力は避けて写真を差し上げます。▶サブジェクトエリアの例V1.2◀

  • イベントごとの複数のバンドが解決されていることに注意してください。

  • そして動詞句は天からまっすぐです。アドレスは複数の会場をホストし、それぞれが複数のイベントを提供し、それぞれが複数のパフォーマンスであり、それぞれが1つのパーティバンドアイテムです。

U.3)代わりに、アイテムとバンドの間のリンクをアイテムとパーティーに移動する時が来ましたか?現在のデザインでは、あなたが育ててきたように、バンドに縛られていない商品を販売する可能性はないと思います。

  • まず、私が衒学者であるからではなく、本当の教祖がリレーショナルの世界への移行に本当に役立つと言っているので、リレーショナルの用語を使用する必要があります。

  • 第二に、「関係を動かす」ことによってそれを達成することはできません。

  • バンド以外の商品をモデル化する必要があります。どのように販売するか。追跡する; それの支払いを受ける。レビューや回答などが必要かどうか。パーティーがそれと何の関係があるのか​​わかりません。現在、パーティーアイテムではなくバンドアイテムを販売しています。参照整合性の問題を検討してください。

バージョン1.2

AR.1)FavoriteItemの演習を終えた後、レビューするアイテムには多対多の関係が必要であると感じています。必要?

  • V1.1では、アイテムには多くのレビューがあり、レビューは約1つのアイテムでした。1人の人が多くのレビューを生成しました(アイテムごとに1つ)。それは論理的です。

  • A Review is about many Items合理的ではありません。

  • どちらかといえば、FavouriteItem / FavouriteBandが解決されたので、Reviewも同様に解決と区別が必要です。BandReviewとItemReviewを区別する必要がありますか。良い/悪いItemReviewは良い/悪いBandReviewを示していますか、それとも個別ですか?

    • レビュー(現状)は、バンドまたはアイテムのいずれかに関するものにすることはできません。つまり、2つの外部キーと1つのwill Null、およびNullFKは許可されません。アイテムとバンドはすでに差別化されており、その差別化は成熟しています。

    • ItemReviewsは要約することができますが、それは別の話です。

U.7)それは私たちに解決すべき新しい問題を残します。レビューがバンド、アルバム、曲、パフォーマンスに関するものである可能性がある場合、参照整合性をどのように確保しますか。SongReviewなどを参照するためにAlbumReviewは必要ありません。モデル化します。

R.5)モデルは現在、アイテムレベルでジャンルを提供しています。これは、アルバムと曲を意味します(商品はチェック制約を介して禁止できます)。バンドではありません。(a)バンドは時間の経過とともに変化し、(b)アイテムレベルでのその種の分類はより正確であり、(c)バンドのジャンルはアルバムまたは曲から簡単に導き出すことができることを考えると、これで十分かもしれません。

  • 個別のバンドジャンルが必要な場合は、それを追加する必要があります。

  • イベントジャンルはどうですか?必要に応じて、イベントごとに1つのジャンルになると思います。

  • VenueやGenreのようなテーブルは、主要なデータベースでの深刻な検索基準であることに注意してください。分析のためのベクトル。

    • データウェアハウスの少年たちは、これをディメンションとしてファクトに追加する必要があります。適切にモデル化されたデータベースでは、それらはすでにディメンションからファクトとして存在します。 10,000人以上を魅了する「フォークミュージック」イベントが予定されているすべての会場を見せてください。 。
  • ディスカッションポイント。上記が間違っていると言っていない。私がデータベースとiTunesの両方で見つけたのは、精度のカウントです。なぜレッセフェールを持っているのかジャンル::あなたがジャンルを持っていることができるときいくつかのこと::特定のもの。あなたがGenre::Songのみを持っていて、Songが1つのジャンルのみを持っている場合、AlbumとBandは正確なロールアップです。今のやり方は、データ入力者の音楽知識次第で、Genre :: Thingが多いので、ゆるいです。ジャンル::曲がタイトです。

R.6)メンバーは、イベントに参加することがモデル化されていないことを示すことができます。また、関心と予約と出席を明確にします。

R.8)モデル化されていません。

M.3)問題は解決されましたが、動詞句は変更されていません。

M.7)連想テーブルに対する論理モデル。その問題が解決したので、論理モデルの関連テーブルをすべて削除します。残りのテーブル(2つの親の間)にはデータが含まれます。つまり、すべての依存テーブルを調べて、データがないものをすべて削除します。したがって、V1.3はすっきりする必要があります。

M.8)アイテムOrderItemです。

M.9)これでParty-Person-Userが解決されました。Exclusive Subtype構造には、Discriminatorが必要であり、Constrainstを使用して整合性を適用します。多くの場合、PartyTypeが最適です。ただし、2つだけの場合は、1列IsBandまたはIsPersonで十分です。

M.10)カーディナリティが逆転したバグを修正しましたが、一部の動詞句はまだ間違った方向に進んでいます。

1月27日

実際、これらの問題の多くは、(エンティティ関係レベルだけでなく)論理キー/属性レベルに移行した方がより明確になると思います。そして、それは私たちがやった時です。例えば:

Q.3)注文:住所が不審です。注文を実行する当事者に固有のアドレスではなく、任意のアドレスを注文に含めることができるため、制約は完全には正しくありません。

しかし、あなたは参照整合性を持たないMyNonSQLであるため、実際のSQLでどのように行われるかを知らない可能性があります。そのため、RI制約でもあるFK定義を提供します。SQLがない場合に、RM、正規化に基づいており、SQLでサポートされている私の簡潔なステートメントを理解することを期待するのは不公平です。

  • 2つの制約が真であるためには、各制約でPartyが同じである必要があるため(1つしかないOrder.PartyId)、PartyIdに属するPartyAddressのサブセットのみが許可されます。

▶住所認定の例◀

パートIIに続く..。

于 2011-01-23T07:56:27.080 に答える
3

... パート II

V1.3と対応

聖トレド!あなたはガスで料理をしているのよ、若いやつ。すべての問題はマイナーなものであるか、学習している新しいステップに関連しています。

識別子と ID 列

Id列がどのようにデータベースを無効にし、リレーショナル パワーを奪うかについて少なくとも 20 回は投稿してきたので、ここで完全な概要を説明するつもりはありません。この質問のコンテキストでのみ問題を扱います。

  • ▶一例◀ですので、まずは質問を詳しくご確認ください。マークは非常に有能ですが、完全に立ち往生していることに注意してください。 それから私の答えを読んでから、データモデルを見てください(コンテキストが提供されますので、今すぐ実行してください)

  • アイデアは、データをデータとしてモデル化することであり、これは私たちが行っていることであり、データベースになるか、xor移動するすべてのものに列を固定Idすることで、モデリングの演習と正規化が妨げられ、大量のデータが得られます。スプレッドシートは相互に「リンク」されており、大量の重複があり、パフォーマンスがありません。

  • したがって、[Table]Idすべてのテーブルからフォームのすべての列を削除します (Migrated Keys はそのままにしておいてください。正しいものです)。ただし、次のテーブル (これらは主要な識別子であり、データベース全体に反映されます) を除きます。ERwin がすべての子、孫などを修正する方法に注意してください。 . テーブル:
    Party
    Address
    Item

リレーショナル/IDEF1X 識別子

あなたは識別子について学んでいます。これらはナチュラルキーです。ユーザーが使用するキー、または親から子に外部キーとして移行されたキー。したがって、これらは関係を識別するだけでなく、子も識別します。あなたの名字は、あなたのことだけでなく、あなたのお父さんのこと、そしてあなたがお父さんの息子であることも教えてくれます。それをユニークにしたいですか?問題ありません。名を追加するだけです。

あなたは私の回答を読み、私のデータ モデルを見て、モデルに識別子を追加してきました。それより**ずっと*簡単です。ERwin (IDEF1X を実装しているため) がそれを行います。

  • パーティー、バンド、そして人を連れて行きます。Party の Identifier はPartyId
    (OK、これは代理キーであり、自然キーではありません。しかし、自然キーLastname, FirstName,BirthDateなどは非常に長いため、それを主キーとして使用すると、子、孫、偉大な人に移行されます。 -孫、これは望ましくないため、短い代理キーを追加し、それを主キーにします)

  • PartyIdERwin でサブタイプを作成し、関係を示すと、PK として Band と Person に自動的に配置されます。「(FK)」としてマークされます。(注: モデルでは (FK) を示すために太字フォントを使用しています。)

  • これで完了です。Party::Band は 1:0-1、Band Primary Key はPartyIdです。これはサブタイプであるため、ERwin は Relation がIdentifyingであることを保証します。したがって、親 PK は子 PK になり、依存子の子は角が丸くなります。

    • サブタイプが含まれていない場合は、関係が 1::0-1 でなく、1::1-n である可能性があることを除いて、同じです。その場合、 f などの別の要素を追加して一意にする必要がありますFirstNameSequenceNo
    • そして、識別関係が必要であることを ERwin に示す必要があります。(そうしないと、プレーンな FK になり、列は線の下になります。テーブルは独立し、角は四角になります)。
    • そして、ある時点でこれらの FK 列を使用して PK を形成することにした場合は、関係をクリックして、非識別から識別に変更するだけです。列は線の上に移動します。角が丸くなります。

役割

  • 次のステップに進みましょう。Band::Party が 1::1 であることはわかっています。その Band は Party の子です。これBand.PartyIdは完全な PK です (Id列は必要ありません)。人も同じ。しかし、それらはばかげた名前であり、別の言い方をすれば、バンドは実際には人によって異なる役割であり、両方ともパーティーです. そのため、ロールを明確に識別したいと考えています。

    • Band では、その Role を反映するためPartyIdに,を呼び出したいと思います。テーブルではなく、サブタイプ シンボルと子の間のRelationBandIdを編集します。ダイアログで、 RoleName を として入力します。それでおしまい。これで完了です。 BandId

    • したがって、以下は ... から次のように変更されます。

      FloorItem.ItemId       FloorItemId
      BandItem.ItemId        BandItemId
      その結果 ...
      Other.BandItemId       OtherId
      Album.BandItemId       AlbumId
      Song.BandItemId        SongId
      Performance.BandItemId PerformanceId

  • すべての列を削除する[Table]Idと、PK のない次のテーブルが残ります。Nameとりあえず、列を PK として追加します。これらのテーブルの自然キー、識別子に対してユーザーが何を望んでいるかを後で教えてください: イベント
    ジャンル

  • PartyAddress は、上で説明したすべての例 (つまり、正しくモデル化されたもの) です。ありませんでしPartyAddressIdた。一緒にPKを形成しますPartyIdAddressId両方の関係は識別です。

識別関係と非識別関係

この主題について多くのことを読むと、この主題について多くの意見の相違と優柔不断があるように思われる

  • はい。残念ながら、最近では、キーボードとモデムがあれば誰でも「公開」できます。人々は意見を事実として投稿します。彼らは無知な主題についてナンセンスを投稿します。これは、学ぼうとしている人々を混乱させます。

  • それは科学であり、魔法でも黒魔術でもなく、意見でもありません。

  • 学習するときは、定義だけを読み、科学を明確に伝えている人の話だけに耳を傾けてください (混乱したり、科学を芸術や意見の対象であるかのように扱ったりする人には耳を傾けないでください)。私たちは、法則についての意見ではなく、事実、物理法則を学んでいます。法律は、世界中のすべての人に同じように機能します。事実は意見だと考える人から学ぶことはできません。

  • 上から見てみましょう:

    1. リレーションは定義基準 (子を独立/従属にする) であり、その逆ではありません。

    2. Relationは常に、親 PK の子の FK です。

    3. 識別関係では、その FK は PK (または PK が複合キーである PK の最初の部分) です。そして子は従属テーブルです。

    4. FK が非 PK 列であり、子が独立しているという非識別関係(他の関係によって強制的に依存される場合があります)。

    5. すべてのサブタイプには、スーパータイプからの識別関係があります。それ以外の場合、それらはサブタイプではなく、スーパータイプから独立しています。

    6. すべての 1:0-1 関係は識別です。

だから私は自分のモデルで正しいことを表していると思うことをしました。

  • [Table]Idこれが、キーを追加することになった理由かもしれません。

いつ強制するか (識別)、いつ解放するか (非識別)?

  • モデリング (データベースと関数) の再作成、特にデータの再作成を強制しないでください。私たちが管理、管理、成形、制御などしたいのは、制御できないものです。しかし、それを効果的に行うには、まずそれを理解する必要があります。強制すると何も理解できません。それを強制すると、それ自体を露出することができなくなり、機微や風味に気付くことができなくなります (私たちはそれを「知っている」ため)。厩舎の囚人ではなく、パドックの馬のように、自由に、しかし拘束された状態にしましょう。

    そのため、すべてのスプレッドシートに列を貼り付ける行為はId、データの理解を妨げ、したがってデータのモデリングを妨げます。

  • 上記のように、識別されているかどうかは関係です。エンティティが独立しているかどうかではなく、それは結果です。

リレーショナル/IDEF1X/ERwin スタイル:

  1. エンティティが必要な場合は、エンティティを描画します。それに名前を付けます。キャンバスの最初のエンティティでない限り、キーを追加しないでください。

  2. 次に、その関係を考えてみましょう。すでにモデル化したエンティティは、この新しいエンティティにどのように関連していますか? そのリレーションを描画します (リレーションは親子で描画されます)。

  3. もちろん、(それを待つ)リレーショナルデータベース内のほとんどの関係が識別であるため、デフォルトで識別に設定されます。親 PK は子 PK に配置されます。

  4. いいえ、いや、これを Independent にしたい場合は、正当な理由が必要です。ここで重要な問題は、このエンティティは完全に単独で存在するのか、他の独立したエンティティのコンテキスト外に存在するのかということです。AFAIC、あなたのモデルには 5 つあります:
    Address
    Party
    Item
    Event
    Genre

    他のすべてのエンティティは、これらの独立したエンティティのいずれかのコンテキスト内にのみ存在します。このようにして識別関係を描いたので、それらはすべて従属関係です。

    • 前に独立したアイテムがあったことを思い出してください。その後、アイテムの新しい形式ができました。古いアイテム、BandItem を作成しました。BandItem を新しいアイテムに依存させます。

    • には優れた Identifier がItemIdありました。これは (当時の) Item クラスターだけでなく、OrderItem、Review など全体で運ばれました。

    • Item のコンテキストを変更し (より高次の Item を作成)、識別関係により、全体が移行され、新しい BandItem がそのコンテキストで移行されました

    • 新しいItemIdものは引き続き優れた識別子です。BandItemIdは正確ItemIdに ですが、特定の役割を果たします。これは のサブセット/サブタイプですItemId

  5. したがって、それが真の独立エンティティである場合は、先に進んで新しい PK を与えてください。

    • ただし、この段階では、Id列ではなく、エンティティを識別する意味のあるものです。 Event.NameCustomer.Code。顧客を番号 123456 として識別する人間はいません。いいえ、彼らは「IBM」、「3M」などを考えます。後で、モデルが進行するにつれて、本当に良いキーがあることを確認します。新しいエンティティでは、識別子があることに注意してください。

    • 例外。Address、Party、Item については、V1.0 では何百万、何千、何千ものものがあることを知っていました。これらがデータベース全体に移行される主要な識別子であること。真の PK が非常に長いこと。また、PK として短いサロゲート キーが必要でした。つまり、最初からそれを設定し、私からの議論はありませんでした。

      • ドメインの準備ができている場合は、INT、INT、または SMALLINT、SMALLINT。

      • それ以外の場合Nameは、CHAR(30)。

  6. 次のステップは、新しいエンティティで PK を完了することです。親からのカーディナリティが 1::n の場合、すでに親の PK を持っているため、要素を追加して PK を一意にします。注文を見てみましょう。すでに を持っているPartIdので、OrderNo以内に収まりますPartyId。PK 列の順序を に変更するだけ(1) PartyId, (2) OrderNoです。

  7. 少しだけ強制を行うのは、PK を形成する列の数が多すぎる場合、または PK の合計幅が広すぎて、FK として子に移行できない場合のみです。次に、フォームの追加のサロゲート キーを作成します[Table]Id(それらは常に追加であり、他の要件をサポートするため、実際の PK や一意性を失うことはありません)。

    • AFAIC、そのマジック ナンバーは 7 です (実際には、多くの場合、マジック ノーです。このアイテムでさえ、ナンバー 7 として表示されます)、その最大幅は 30 バイトです。これは、Address (すでに高度に最適化されています)、Party (それ以外の場合は 64 バイト)、Item (30 バイト以上) で最初から行われていました。

    • 本質的な関係力を壊すつもりなら、その関係力自体を運ぶという苦痛が本当に悪いものである必要があり、他の理由はありません. あなたのモデルではそれに近づいていません。

クラスタのレビュー

あなたは非常に良い仕事をしたので、これを次の進歩と考えてください. 基本的には 2 つのオプションがあり、もちろんこれを Item クラスターと比較/関連付けています。

  1. Review クラスターをそのまま使用します。SongReview と AlbumReview が必要です。そして、ItemReview を取り除きます (これはすべてのアイテムをカプセル化します。これは、2 倍になることを意味します)。バンド以外のアイテムのレビューを除外していると思っていました。

  2. 非 BandReview が任意の BandItem に関するものであることを許可します。ItemReview FK を Item から BandItem に変更します。これにより、ItemReview にすべての BandItem がカプセル化されます。PerformanceReview を削除します。

    • 確かに、BandItem.Other をレビューしたくない場合があります。他の方法で制限することができます。しかし、厳密になりたい場合は、(1) が必要です。

あなたが私の配色を採用してくれたのは素晴らしいことです。

  • 意味、視覚的な関連性は、小さなモデルには現れません (私のモデルのほとんどは SO にあります)。あなたのような大きなモデルにのみ表示されます。

  • あなたが V1.3 で素晴らしい仕事をしたので、先生はあなたに ▶リンゴ◀ を持っています。実際、▶IDEF1X Notation◀の文書はもう一度読む価値があります。非常に凝縮されており、何かをモデル化してから読むと、より多くの価値が得られると言われています。私が知る必要があるのは、自然階層と色があなたのために何かをするかどうかです.

  • これで、エンティティ レベルの論理が完成しました。

論理、キー レベルに進むことができます (唯一の属性は FK であり、それらが何であるかはわかっています)。しかし、気軽に属性の識別を開始してください (この場合、属性レベルを表示します)。

オプションの列

U.1) オプションの親がモデルに忍び込みました。PartyAddress is shipped for OrderNullable ではありません。

  • 配送先住所がオプションであることをモデル化する場合は、Order の子である OrderShipAddress エンティティが必要で、カーディナリティは 1::0-1 です。

    • Null (オプションの列) は、全身に集まる癌のようなものです。Nullable FK (オプションの親) は、5 歳未満の孤児の喉の癌です。
      .
  • これは、ここのような FK (オプションの親) に限らず、オプションの列を処理するための基本的な方法です。

マイナー

M.11) これらは V1.2 で正しかった
Review::Comment は 1::0-1
BandMember:: Comment は 1:0-n

M.12) Event::Person は n::n です (列は論理レベルでは表示されません)

V1.4と対応

非常に良い進歩です。識別子、キーに満足していますか?

U.8) (これを最初に行うと、残りは簡単に続きます。) ERwin の制限。おめでとうございます。論理モデリングにおける ERwin の機能の限界に達したモデルが作成されました。明確にするために言うと、これは物理モデルで解決されるという点で、実際には制限ではありません。もちろん、IDEF1X やリレーショナル データベースの制限でもありません。しかし、今、ロジカルでは、あなたの学習と進歩を妨げています.

  • BandItem では、PK を (BandItemId, BandId) にする必要があります。しかし、サブタイプ PK はスーパータイプ PK でなければならず、 . 実際には、スーパータイプ PK が主要な識別子である限り、別の識別関係が許容されます。これを回避するには:

    • サブタイプ記号を削除
    • Item::FloorItem と Item::BandItem の 2 つの識別関係を作成する
  • 非識別にする必要があった関係は、識別できるようになりました。

  • ERwin は、移行された PK を複製せずに FK として解決するようになりました。

  • はい、ロールを元に戻します。

U.9) これで、あなたが Review クラスターで何をしようとしているのか理解できました。まず、Rating に至るまで、正しくモデル化されていると言わせてください。

  • しかし、Review 自体には基本的な問題があります。ReviewerId の PK を使用すると、1 人のレビュアーに 1 つのレビューのみが許可されます。もちろん、Band/BandItem ごとに Reviewer ごとに 1 つの Review が必要ですが、それはサブタイプのさらに下に隠されています。基本的に、ここでの Supertype-Subtype の使用は制限が多すぎます。その早い段階で理解できてよかったですが、今はその先に進む必要があります。
    • Review クラスターの代わりに、BandReview と ItemReview の 2 つの Review テーブルを作成します。
    • リレーションは、Person::BandReview と Band::BandReview、および Person::ItemReview と BandItem::ItemReview になります。
    • 次に、それぞれに子 %Rating、%Comment、%CommentRating があります。

M.13) Order::OrderShipAddress は 1::0-1 です。正しいです。PartyAddress::Order は 1::0-n、正しい したがって、配送先住所は PartyAddress::OrderShipAddress 1::0-n である必要があります

M.14) 支払いでは、現在、注文ごとに 1 回の支払いのみが許可されています。これはあなたが必要としているものかもしれませんが、関係は 1::1-n です。さらに必要な場合は、SequenceNo を PK に追加します。

M.15) ジャンルはなんでもいいです。ただし、SubGenre では、複数のジャンルを許可するために PK に何かが必要です。ここで、Genre.Name を Genre.Genre に変更し、SubGenre を SubGenre PK に追加します。- Event.GenreId も修正されます。

M.16) 今のところ、会場には PK の名前が必要です。より良いキーの準備ができている場合は、ShortName と Name が属性として下に移動します。

Q.4) 確認中。Order には識別関係があり、PK (PartyId、OrderNo) があるため、OrderNo は PartyId 内の連番ですよね?

V1.5 に進みます。いくつかの属性を含めます。それらを特定する最善の方法は、機能モデルを開始する (そして、データ モデルをそれと並べて操作する) か、少なくともすべての画面のすべての機能を操作することです。

乾杯

于 2011-01-29T16:14:37.487 に答える