了承
私が言わなければならないのは、あなたは(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
複数の場所、およびEvents
1つまたは複数の場所 を識別/モデル化するのはあなたに任せます。
U.3)仮定Catalog
は、従来の意味でのエントリ(JCPenney 2011)であり、販売またはレンタルするアイテムのリストです。
OrderSaleItem
正しい
重要なポイント。は依存関係にあり、AsssetとしてCatalog
のコンテキストでのみ存在できます。Band
罰金。つまり、データベースにはバンド商品以外の商品はありません。正しい ?
「ブルース・ブラザースとのイブニング・パフォーマンス」が、Event
注文、請求、支払いが可能なものであることがわかります。また、レビュー、コメントなど。
Song
それにどのように適合するのかわかりません。バンドはアルバム、曲、またはその両方を販売していますか?
他にバンドの商品はありません:コンサート/イベントのお土産。ポスター; 刻まれたショットグラス?
参照する命名規則およびデータベースの残りの部分と一致して、Catalog
(コテント)にItem
(行)という名前を付ける必要があります。あなたはすでに(当然のことながら?)OrderSaleItem
、(ではなく、でそれを使用していOrderSaleCatalog
ます。
U.4)ジャンル
U.5)お気に入り
のカーディナリティItem::Favorite
が逆になっています。これを修正すると、Favorite
サブジェクトエリアはさらにモデリングする必要があります。
エンティティの同じペア間の循環関係またはデュアルパスは、未解決のモデルのシグナルです。通常、1つは正しく、もう1つは冗長です。(例外はありますが、ここにはありません。これが発生すると、動詞句がそれらを区別します。)
両方ではなく、どちらかのBand::Favorite
xorItem::Favorite
が正しい。
Item::Favorite
Band
ですでに識別されているので、正しいようですItem
同様に、Favorite
バンドと商品の1つのエンティティは堅実に聞こえません。単一のFavorite
エンティティ内のすべての識別子はParty
です。正規化すると壊れますが、この段階で識別子を明確にすることを要求することもできます。FavoriteType
それは、その扱いを識別する何らかの形の差別化()を持つ1つのエンティティのいずれかです。または、1つFavorite
はバンド用、もう1つは商品用であり、この場合、区別は必要ありません。あいまいさは排除されます。
U.6)ビジネスルールこれはおそらくあなたが苦手な唯一の分野です。一般的な対応。タスクを個別に実行しました(すべてのモデリングとBRの作成)。これらはモデルと一致しません。次のサイクルを実行するときは、ビジネスルールをディレクティブとして使用し、エンティティ、リレーション、動詞句の場合と同様に、それらを同時に調整します。
質問
Q.1)ユーザー/友達
あなたはそれの本質を完全に持っています。そして、関係のカーディナリティ。(これは完全に処理されます。)これは、Acceptedの場合は正しいですFriend
。
したがって、時制は過去である必要があります(過半数の行に移動します)
Requested
、および保留中Accepted
のは少数派です。IsAccepted
ビットまたはブールで簡単に実装できます。
後であなたはまたはを持っているかもしれませんIsRejected
(IsBlocked
後者は別のエンティティでなければなりません)。
それはあなたが必要とするものですか?
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)OrderSaleItem
xorで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)はい、承認、拒否、ブロックしたいのですが。これが論理モデルをどのように変えるかについて、あなたが何を参照しているのかわかりませんか?
前者には、追加のステータスがあります。
Blocked
。
- 次に、動詞句を変更する必要があり(わかりやすくするためにRoleNameを含めます)、そのうちの1つには別の意味があります。。
- (属性レベルのモデルでははるかに明確になるため、単語ではなく画像でモデル化するので、これを含めました。)
Q.2)ユーザーである必要はありません。それらはBandMemberとしてのみ存在できます。それはあなたが求めていることですか?
M.3)物事を理解していることを確認するために、制約チェックについてもっと読む必要があります。
- 今は心配しないでください。私はあなたにそれを単純に保つ理由を与えていました(NonSQLは物事を単純化するように見えますが、実際にはそれをより複雑にします)。MyNonSQLにはこれらの機能がないため、プラットフォームの考慮を排除し、カーディナリティを有意義にモデル化することができます。
M.4)将来OrderPurchaseを想定しているかどうかによって異なります。ここで何を意味するのかを詳しく説明していただけますか?
バージョン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◀
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を示していますか、それとも個別ですか?
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に続く..。