How can I improve this database model?

I'm trying to model the relationship of dvd sales and dvd rentals to a customer. Although I dont think my transction table is correct. If anyone can let me know if I'm goin in the right direction with the design that would be g开发者_JAVA技巧reat.

Here is one way you can design this.

I am not a database expert. I have designed databases for small sized applications with few tables. I try (emphasis on try, sometimes I fail to) to be more generic as possible so I am not confined to a corner when there is a scope change.

1. In your diagram, I noticed few things like your assumption of selling only DVDs. What happens if the shop owner starts to sell Blu-ray discs or portable game consoles. My suggestion would be to keep the design generic. So I rephrased the DVD table to Item so that the table could hold anything.

2. I also added Item type table so that you can define what type of item it is.

3. You transactions should be considered as a single order. A customer can place a single order that can contain a set of items they would like to purchase and also few items that they would like to rent. You wouldn't ask them to swipe the card twice, would you? Instead, create an order for the customer in the Order Header and place their line items in the Order detail table. The order detail table would also specify quantity like how many items the customer would like to purchase/rent. When they rent, the return date field would be null to begin with. When they return the item, you can go back and fill in the date by searching for the item id and customer id combination.

You can design this in n number of ways but with limited info, this is what I could come up with.

I am not stating that this is the best design. I hope this gives you some idea to take it from here and fine tune it according to your needs..

Many retail databases model each type of transaction ("Sale of Harry Potter", "Rental of Harry Potter") as different rows in the same table. So you would have "TransactionType", and then you can have Customer->Transaction->LineItem (An instance of a transaction)->TransactionType.

I would put all the transaction info in one table. Some fields may not be used depending on the type of transaction (P Purchase, R Rental) but so what? Disk space is cheap. The code will be simpler and run faster by having fewer tables.