sql - リレーショナル データベース テーブル

Question

私は現在、ソフトウェア エンジニアリング クラスの ASP.Net MVC プロジェクトに取り組んでいます。私の目標は、小さなオンライン ゲーム レンタル システムを作成することです。現在、映画、ゲーム、登録者の 3 つのテーブルがあります。LINQ-to-SQL を使用して、これらの各テーブルをモデルのクラスとして定義しています。これまで映画とゲームのモデルを作成してきましたが、登録者モデルを作成するときにやりたいことは、登録者と映画とゲームの関係を作成することです。これまでに試したことは、ID (Registrant テーブルの主キー) と映画とゲームの両方の登録者 ID フィールドの間に外部キーを定義することです。私が気付いたのは、登録者のインスタンスを削除すると、関連する映画やゲームが他のテーブルから削除されるということです。私は何を

要約すれば：

私がこれまでに持っているもの：

• 3 つのテーブル: 登録者、映画、ゲーム。
• 映画やゲームのインベントリの LINQ-to-SQL モデル。

私がセットアップしようとしているもの：

• 登録者が映画および/またはゲームをレンタル/返却するモデル。ゲームがレンタル/返却されると、ステータスを示すためにインベントリ内のアイテムの横にフラグが配置されます。

質問：

• レンタルした映画/ゲームをモデル化するために個別のテーブルを追加すると、在庫モデルで定義されたアイテムが削除されなくなりますか?? つまり、顧客がレンタルした映画を返品すると、rentedMovie インスタンスは削除されますが、映画インベントリで参照されている映画は削除されません。

• 他のテーブルの関連するエントリが変更されるたびに、エントリが削除されるのではなく、関連するエントリにステータスフラグが設定されている関連するテーブルのようなものはありますか?? つまり、顧客がレンタルした映画を返却すると、rentedMovie インスタンスが参照する映画にレンタル可能であることを示すフラグを設定し、rentedMovie インスタンスは削除されます。

Answer 1

私はこれについて少し違ったやり方をします。Movieまず、 aと aGameを別々のエンティティとして扱う本当の理由はありますか? RentableItem映画でも、ゲームでも、ゲーム機でも、ブルーレイ プレーヤーでも、なんでもいいのです。フィールドでキーを設定item_idすると、予想されるメタデータ ( title、type、genre、次に、 a が1 つまたは複数を賃貸rental_class, and so on). するという事実をモデル化する必要があります。これは、各行が賃貸されたものを特定(つまり、は によってキー付けされ、への外部キーと への外部キーを持ちます。には、期日、「返却」フラグ、レンタルの価格などもあります。 RegistrantRentableItemsRentalRentableItemRegistrantRentalrental_idRentableItem.item_idRegistrant.registrant_idRental

RentableItemitem_id が と同じでRentableItem、"returned" フラグが falseの Rental レコードがあれば、 がストアにないことがわかります。RentableItemテーブルだけを変更する必要はありませんRental。

Answer 2

このモデルでは、同じタイプの複数の映画またはゲームを同時にレンタルできるようになったため、rentedGames とrentedMovies に別々のテーブルを作成するのは正しいことです。これは、特定の映画のインスタンスを 1 つだけ持つよりも確実に現実的です。またはゲーム。

これにより、リンク レコード (rentedMovie など) が削除されたときに、親レコードが削除されなくなります。ただし、リレーションシップを「カスケード削除」しないように設定し、元の映画またはゲーム テーブルの登録者 ID フィールドを null 許容にすることを許可している場合、この親映画の削除はとにかく発生しないはずです。

2番目の質問に答えるには（特定のタイトルに対して1つの映画/ゲームのみを想定しています）：これが通常行われる方法は、リンクテーブルを使用している場合、これはあなたがやりたいことですが、単にrentedMovieを削除することです/ゲーム記録。映画またはゲームのリンク レコードが存在しないことは、その映画またはゲームがレンタル可能になったことを (再び) 知るために、コードで判断する必要があるすべてのことです。

Answer 3

クラス/練習のためにこれを行っていることは知っているので、これは関係ないかもしれませんが、物事のレンタル履歴があると非常に役立つことが多いと考えてください. このため、レンタルしたレコードを削除したくない場合がありますが、その代わりにアイテムを返却済みとしてマークするだけです。

検討：

TABLE RentalTransaction:
RentalTransactionID integer PK NOT NULL
CustomerID integer FK NOT NULL
RentedOn datetime NOT NULL
DueDate datetime NOT NULL
<..any other fields you may need..>

TABLE RentalItems:
RentedID integer PK NOT NULL
RentalTransactionID integer FK NOT NULL
RentedItemID integer FK NOT NULL
RentedQty integer NOT NULL
RentalRetuned datetime NULL

個々のアイテムがアウトかどうかは、RentalReturnedフィールドがアウトかどうかでわかりnullます。null でない場合、アイテムが戻ってきたことがわかり、レンタル データを集計して、レンタルの頻度、レンタルの平均期間などを確認できます。いくつかのチェックを組み込む必要があります。確かに、実際に持っているよりも多くのアイテムのコピーをレンタルしたり、その他のことをしたりすることはありませんでしたが、これは全体的にスキーマのより柔軟なスタートだと思います. あなたがやっていることはあまりにも複雑かもしれませんが、私は少なくともアイデアを持ち出したいと思っていました.

Answer 4

rentedMovie インスタンスを本当に削除しますか? 人がレンタルした映画の数などをどのように報告しますか?

モデルを少し再考することをお勧めします。最初のステップとして、人のデータを保存する場所、アイテムのデータを保存する場所、人/アイテムのデータを保存する場所が必要です。

今のところ、映画とゲームの違いは無視してください。基礎となる構造を定義したら、それは正規化のプロセスになります。

簡単な出発点として、次のものが必要です。

人 1..1 ---- 1..* 雇用 0..* ---- 1..1 項目

ここで、Hires テーブルは、personID、ItemID、および何らかの説明のタイムスタンプ (同じ映画の再レンタルを許可するため) で構成される結合キーを持つ、他の 2 つのテーブル間のリンク テーブルです。

次に、項目タイプなどに別のテーブルを用意することを検討できます。

Answer 5

最初に考慮すべきことは、映画は実際にはタイトルとメディアの 2 つのエンティティであるということです。タイトルは「ロード・オブ・ザ・リング」ですが、メディアはお持ち帰りのDVDです。1 つのタイトルには複数のメディア (コピー) を含めることができますが、1 つのメディアには 1 つのタイトルを含めることができます。Rentalテーブルにはメディアレンタルごとに行があり、このテーブルはレンタル時にバーコードがスキャンされるたびに新しい行を取得し、DateReturned返却時にデータが入力されます。Statusテーブル内のフィールドは、Media各ディスク/ゲームのイン/アウト ステータスを追跡します。どの映画が顧客に一緒にレンタルされたかを追跡する必要があると思われる場合は、DateRented(datetime) で検索するか、ReceiptNumberまたはShoppingBasketIDをRentalテーブルに追加します。