Таблицы реляционной базы данных

Question

В настоящее время я работаю над проектом ASP.Net MVC для класса разработки программного обеспечения. Моя цель - создать небольшую систему проката онлайн-игр. В настоящее время у меня есть 3 стола, фильмы, игры и регистранты; и я использую LINQ-to-SQL, чтобы определить каждую из этих таблиц как классы для моей модели. До сих пор я создавал модели для Кино и Игр, и я хотел бы при создании модели «Регистрант» создать отношения между «Регистрантами» и «Кино и Играми». До сих пор я пытался определить внешний ключ между ID (первичным ключом в таблице Registrant) и полем registrantID в Movies и Games. Я понял, что если я удалю экземпляр регистранта, он удалит связанный фильм и / или игру из других таблиц. Я думаю о том, чтобы создать две отдельные модели, определяющие rentedGames и rentedMovies, и создать взаимосвязь между ними и таблицей Games and Movies, чтобы попытаться смоделировать для владельца домена аренду / возврат / покупку фильмов или игр из магазина.

В итоге:

Что у меня так далеко:

• 3 таблицы: Регистранты, Фильмы и Игры.
• LINQ-to-SQL модели для моего инвентарь фильмов и игр.

Что я пытаюсь настроить:

• Модель для регистранта, арендующего / возвращающего фильм и / или игру, когда игра арендована / возвращена, рядом с предметом в инвентаре ставится флаг, указывающий его статус.

Вопрос:

• Будет ли добавление отдельных таблиц в модель арендованный фильм / игра, запрещающая предметы определены в моих моделях инвентаризации из удаляется ?? то есть, когда клиент возвращает арендованный фильм, экземпляр rentedMovie удаляется, но фильм не относится к описанию фильма.

• Есть ли такая вещь, как таблица с установленным флагом состояния на связанная запись, в отличие от запись удаляется всякий раз, когда связанная запись в другой таблице модифицируется ?? т.е. когда клиент возвращает арендованный фильм, экземпляр rentedMovie устанавливает флаг в фильме, который указывает на то, что он доступен для аренды, экземпляр rentedMovie затем удаляется.

Answer 1

Я бы пошел по-другому. Во-первых, есть ли реальная причина рассматривать Movie и Game как отдельные объекты? Почему бы не иметь RentableItem, который может быть фильмом, игрой, игровым автоматом, игроком Blue-Ray или чем-то еще? Вы бы указали его в поле item_id, и в нем были бы ожидаемые метаданные (title, type, genre, rental_class, and so on). Затем вам нужно смоделировать тот факт, что Registrant арендует один или несколько RentableItems. Это можно сделать с помощью таблицы Rental, каждая строка которой соединяет одну арендуемую RentableItem с конкретным Registrant (то есть Rental имеет ключ rental_id и имеет внешний ключ для RentableItem.item_id и внешний ключ для Registrant.registrant_id. Rental также будет иметь дату оплаты, флаг "возврата", цену аренды и т. д.

Тогда вы знаете, что RentableItem нет в магазине, если есть запись проката, чей item_id совпадает с RentableItem, а флаг "возвращен" имеет значение false. Вам никогда не придется изменять саму таблицу RentableItem, только таблицу Rental.

Answer 2

Первое, что нужно учитывать, это то, что фильм - это две сущности: заголовок и медиа. Название «Властелин колец», а медиа - это DVD, который вы берете домой. Один заголовок может иметь несколько носителей (копий), в то время как один носитель имеет один заголовок. В таблице Rental есть строка для каждого проката мультимедиа, эта таблица получает новую строку при каждом сканировании штрих-кода при прокате, а DateReturned заполняется при возврате. Поле Status в таблице Media отслеживает состояние входа / выхода для каждого диска / игры. Если вы чувствуете, что вам нужно отследить, какие фильмы были арендованы вместе с клиентом, вы можете найти это по DateRented (дата / время) или добавить ReceiptNumber или ShoppingBasketID к таблице Rental.

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 или нет. Если он ненулевой, то вы знаете, что товар вернулся, и теперь вы можете агрегировать данные аренды, чтобы увидеть, как часто он выходит, какова средняя продолжительность аренды и т. Д. конечно, вы не арендовали больше копий предмета, чем на самом деле, и другие подобные вещи, но я думаю, что в целом это более гибкое начало схемы. Это может быть слишком сложно для того, что вы делаете, но я хотел, по крайней мере, выдвинуть эту идею.

Answer 4

Вы действительно хотите удалить экземпляр rentedMovie? Как вы сообщите о том, сколько фильмов снял человек и т.д.?

Я бы посоветовал немного переосмыслить вашу модель. Вам нужно где-то хранить данные о людях, где-то хранить данные о предметах и ​​где-то хранить данные о людях / предметах в качестве первого шага.

Пока игнорируйте разницу между фильмами и играми - это станет процессом нормализации, как только вы определили основную структуру.

В качестве простой отправной точки вы должны иметь:

человек 1..1 ---- 1 .. * нанимает 0 .. * ---- 1..1 пунктов

где таблица Hires является связующей таблицей между двумя другими с комбинированным ключом, состоящим из personID, ItemID и отметки времени некоторого описания (чтобы разрешить повторную аренду одного и того же фильма).

Затем можно посмотреть на отдельную таблицу для типов элементов и т. Д.

Answer 5

Вы правы, создавая отдельные таблицы для rentedGames и rentedMovies, поскольку эта модель теперь позволяет одновременно снимать в прокат более одного фильма или игры одного типа, что, безусловно, более реалистично, чем иметь только один экземпляр определенный фильм или игра.

Это предотвратит удаление родительской записи при удалении записи ссылки (скажем, rentedMovie). Но это удаление родительского фильма в любом случае не должно происходить, если вы настроили свои отношения не на «каскадное удаление» и допустили возможность обнуления поля registrantID в исходных таблицах «Фильмы» или «Игры».

Чтобы ответить на ваш второй вопрос (который, как я понимаю, предполагает только один фильм / игру для какого-либо конкретного заголовка): как обычно это делается, если вы используете таблицы ссылок, а это то, что вы хотите сделать, это просто удалить арендованный фильм / запись игры. Отсутствие записи ссылки для любого фильма или игры - это все, что нужно определить вашему коду, чтобы знать, что этот фильм или игра теперь можно сдавать в аренду (снова).