DVD rental management system Database Design

Prabir Shrestha 491-5302 Nay Lin Zaw 481-5231 Pramit Silwal 502-5407
October 2008 1

Contents

1. Brief review of the Enterprise 2. The E-R Diagram 2.1 Decisions made while choosing appropriate E-R

3 4
... 8

3. The Business Logic

3.1 Some strengths and weaknesses of our design

8
. 10

4. Intended Use of Database 5. Relational Database Schema 6. Relational SQL Database Definition 7. System Architecture Revisited

11 15 16 20

1. Brief review of the Enterprise

The enterprise is a database system which keeps track of the information about DVDs and customers that is to be used in a DVD rental shop. Without the use of the database system the rental shop has to maintain scattered DVD records and customer information. A centralized database will help to provide general accessibility to this information as well as ensuring that the data is preserved more securely. Now the system provides not only the features that weve proposed in the proposal, weve added up more features and they are: Search the DVD, search the member information and status including previous and current transactions provide access to information about DVD availability provide access to information about rented DVD information (eg. Due date) allow updates to information as required allow removal of items upon their disposal provide different level of permission to different types of users provide different privileges to different kinds of customers

2. The E-R Diagram

2.1 Decisions made while choosing appropriate E-R

From the above illustration of ER diagrams, it is to show that weve designed 4 ER diagrams and among the 4, due to some restrictions and limitations of different designs, weve chose the 4th ER diagram as our actual database design. Meaning our actual implementation will be based on the *ER diagram 4*. We started with *ER Diagram 1* and updated to *ER Diagram 2* because we thought that there was no attribute that differentiated a premium user from a normal user thus specializing customer entity into these two entities would be unnecessary for practical purposes. So the alternative was to have both normal and premium users belong to a single entity called customers. In *ER Diagram 3*we decided to link the copies weak entity with rent and dvd parent entity to reserve because whenever any user rents a DVD we need to keep track of which DVD copy he/she has rented and not just know how many DVDs are rented and how many are in stock. As for reserving, a customer solely wants to reserve any copy of the DVD. Thus with some modifications we have finalized the E-R diagram as follows. In *ER Diagram 4*, we thought that everything was correct in *ER Diagram 3* however since the aim of a good E-R diagram is to represent all the possible business logic, we decided to specialize the customer entity so that we could capture the rule that normal and premium users can borrow up to 2 and 4 DVDs respectively. Also in rent relation, we notice that having the Due Date attribute is useless since we can track down the due date from attribute Rent Date. So we removed attribute Due Date and added new attribute ReturnedDate so that we can track down which customers rent is overdue or when a customer has to return the DVD. After that weve fixed some of the cardinality mapping and participation.

3. The Business Logic.

TheDVDshophasuserswhocaneitherbeadministrators(Admin)orcustomers.All usershaveauniqueIDtoidentifythem.Theadministratorsmanagethedatabaseandhave authoritytomodifythedatabase.ThecustomercanonlyborrowDVDsfromtheshop.Aperson canbebothadministratorandcustomer. Foreachuser,wemaintainseveraldescriptiveattributes.Someimportantonesare securityfeatureslikepasswordforauthenticationandIDverificationquestionandanswers.We mayhaveoneormorephonenumbersforeveryuser.

Therearetwokindsofcustomers:normalandpremium.Allcustomershavetobeonly oneofthetwotypes.Thedifferencebetweenthetwokindsisthatnormalcustomersgetto rentupto2DVDsusingtheiraccount,whereaspremiumcustomersgettorentupto4DVDs. Anotherprivilegetopremiumcustomersisthattheycanrequestupto2DVDs.That is,eveniftheDVDisnotavailableatthestore,thecustomercanrequesttoreservethatDVD forhim/herwheneveracopyisreturned.Normalcustomersdonothavetheprivilegeofdoing thisandcanonlyrentfromwhatsavailableinthestoreatthecurrenttime. EachcustomeriscanonlyrentDVDsifhe/shehasntexceededthequotaallocatedand ifhe/sheisnotbanned.Acustomercanbebannedbyanadmindependingonthesituation.For example,acustomermaybebannedfornotreturningDVDsforanextendedperiodoftimeor situationsmayarisewhentheshopnolongerwantstoserviceaparticularcustomer.Thisbanis atemporarybanandcanbechangedbyadminassituationchanges. ItistobenotedthateveryDVDentityhasauniqueIDhowevercanhavemultiple copies.EachcopyisidentifiedwiththecombinationofDVDIDandcopynumber.Whena customerrentsaDVD,he/sheactuallyrentsacopyoftheDVD.Acustomermayrentcopiesof thesameofdifferentDVDsaccordingtohis/herquota. WheneveraDVDisrentedbyacustomer,wemaintaintherentaldateaswellasthe returndate,ifthecustomerreturnstheDVDaftertheduedate,heischargedwithoverdue feesdependingonhowmanydayshesexceededhisduedate. Wemaintainatablewithinformationrelatedtodirectors.EveryDVD(meaningthe movie)hastobedirectedbyoneormoredirectors.Wealsomaintainatablewithinformation relatedtoactors.AgaineveryDVDhastohaveatleastoneactorinithowever,wemay maintaininformationofactorsanddirectorsthatdonotbelongtoanyDVDinthedatabase. ADVDmayhaveoneormoregenre(forexample,action,comedy,horror,etc.) ADVDmayalsohavemultiplekeywordsassociatedwithitsothatitseasierforthe customertosearchaDVDbasedonwordsthatsuggestthecontentsorwordsthatareincluded inthetitleoftheDVD.
9

3.1 Some strengths and weaknesses of our design Strengths:

Our user entity has a considerable number of attributes. Besides contact information, some of these attributes allow us to keep track of users logon history. Since our application is web based, this seems appropriate because we want to provide the customers with maximum security features. The DVD rental shop has several kinds of users and some of them can be both admin and customers. Thus to avoid data redundancy and possible update anomalies, we have decided to have a single table for all users with attributes helping us to distinguish between them. By specializing customer entity into premium entity we have made possible for only the premium customers to reserve DVDs. We maintain tables containing information about directors, actors, genres and keywords. This not only allows for efficient many to many relationship participation but prevents deletion anomaly. For example if there is only one DVD related to a certain director and if we delete the DVD from our database, we will lose the information about the director or have to re enter the information in the future. Our rent table has not only present information on outstanding DVDs but also past records of all transactions. Therefore, we could advance our database to include mechanisms to suggest DVDs to users based on their rental history.

Weaknesses:
Although we mentioned earlier that we have a huge user table, there is a chance of losing valuable user information if somehow parts or whole of the table is deleted. Dividing the table into a reasonable number of sub tables using minimal foreign keys could be a good strategy. We could have a borrow policy for example so that each borrow policy has extra information in addition to the quota and fine rates. For example a borrow policy might include users being or not being liable to damages caused to the DVD. But since out design is comparatively for a smaller application, this feature has been left out. In a real world situation, the user would want to search for movie titles using more than keywords and names. A better design would perhaps be to allow users to rate DVDs themselves and have blogs or some such feature that allows users to interact with themselves.

10

4. Intended Use of Database

CREATE PROC tblActors_GetAllActors AS SELECT * FROM tblActors

This is the admin view of list of actors.

CREATEPROCtblActors_Insert ( @Genderchar(1), @nameNameType, @idintOUTPUT ) AS SETNOCOUNTONdboptimizationsorowsaffectedarenotcounted INSERTINTOtblActors (Gender,[Name]) 11

 GO

VALUES (@gender,@name) SET@id=scope_identity()

Ifauserissigninwithadminaccount,thatuserisallowedtoaddanddeletethedvdfromthedatabase throughthewebpage. CREATEPROCtblDvds_GetAllDvds AS SELECT*FROMtblDvds GO

12

 ThisisthelistofallDVDsinthedatabase.In insert stored procedures we have included some

Database optimatization by doing SET NOCOUNT ON. This feature will turn off Microsoft Sql affected rows counting which can improve the speed. Instead of using rows affected, it will return the new id of the currently inserted Dvd.

CREATEPROCtblDvds_Insert ( @titleTitleType, @ratingint, @yearPublishedint, @idintOUTPUT ) AS SETNOCOUNTONdboptimizationsorowsaffectedarenotcounted INSERTINTOtblDvds (title,rating,yearPublished) VALUES 13

 GO

(@title,@rating,@yearPublished) SET@id=scope_identity()

ThisishowAdmininsertDVDs.Youllseethatthedatatypeofratingisinteger.Thisishowwe categorizetheratinginrelationtonumbers1,2,3and4. Bad1 Good2 VeryGood3 Excellent4 14

5. Relational Database Schema

15

6. Relational SQL Database Definition

FollowingistheSQLdatadefinitionthatcreatesourdatabaseontheMicrosoftSQLserver. DVDrentalDB CREATETYPEUsernameTypeFROMvarchar(20) CREATETYPEEmailTypeFROMvarchar(50) CREATETYPEPasswordTypeFROMvarchar(20) CREATETYPESecretTypeFROMVARCHAR(100) CREATETYPENameTypeFROMVARCHAR(50) CREATETYPEAddressTypeFROMVARCHAR(50) CREATETABLEtblUsers ( membershipuserdetails IDintIDENTITY(1,1)NOTNULL, UsernameUsernameTypeNOTNULL, EmailEmailTypeNOTNULL, PasswordPasswordTypeNOTNULL, PasswordQuestionSecretTypeNOTNULL, PasswordAnswerSecretTypeNOTNULL, TitleintNOTNULL, FirstNameNameTypeNOTNULL, LastNameNameTypeNOTNULL, DOBdatetimeNOTNULL, AddressAddressTypeNOTNULL, PRIMARYKEY(ID), UNIQUE(Username), ) CREATETABLEtblActors ( IDintIDENTITY(1,1)NOTNULL, Genderchar(1)NULL, [Name]NameTypeNOTNULL PRIMARYKEY(ID) ) 16

 CREATETABLEtblAdmins ( keepstrackofwho'sadmin UserIDintNOTNULL, PRIMARYKEY(UserID), FOREIGNKEY(UserID)REFERENCEStblUsers(ID), ) ALTERTABLEtblAdmins ADDCONSTRAINTfk_AdminCustomersFOREIGNKEY(ID)REFERENCEStblUsers(ID) ONDELETECASCADE ONUPDATECASCADE CREATETABLEtblNormalCustomers ( IDint, PRIMARYKEY(ID) ) ALTERTABLEtblNormalCustomers ADDCONSTRAINTfk_NormalCustomersFOREIGNKEY(ID)REFERENCEStblUsers(ID) ONDELETECASCADE ONUPDATECASCADE CREATETABLEtblPremiumCustomers ( IDint, PRIMARYKEY(ID) ) ALTERTABLEtblPremiumCustomers ADDCONSTRAINTfk_PremiumCustomersFOREIGNKEY(ID)REFERENCEStblUsers(ID) ONDELETECASCADE ONUPDATECASCADE CREATETABLEtblBelongsTo ( DVDintNOTNULL, GenreintNOTNULL, PRIMARYKEY(DVD,Genre), FOREIGNKEY(DVD)REFERENCEStblDVD(ID), FOREIGNKEY(Genre)REFERENCEStblGenres(ID), 17

) CREATETABLEtblContains { DVDintNOTNULL, KeywordintNOTNULL, PRIMARYKEY(DVD,Keyword), FOREIGNKEY(DVD)REFERENCEStblDVD(ID), FOREIGNKEY(Keyword)REFERENCEStblKeywords(ID), ) CREATETABLEtblCopies ( copyinformationofeachDVD DVDIDintNOTNULL, CopyNumberintIDENTITY(1,1)NOTNULL, PRIMARYKEY(DVDID,CopyNumber), FOREIGNKEY(DVDID)REFERENCEStblDVD(ID), ) CREATETABLEtblCustomers ( customerdetails UserIDintNOTNULL, IsBannedbitNOTNULL, IsPremiumbitNOTNULL, Preferencechar(30)DEFAULTNULL, PRIMARYKEY(UserID), FOREIGNKEY(UserID)REFERENCEStblUsers(ID), ) CREATETABLEtblDirectedBy { DVDintNOTNULL, DirectorintNOTNULL, PRIMARYKEY(DVD,Director) FOREIGNKEY(DVD)REFERENCEStblDVD(ID), FOREIGNKEY(Director)REFERENCEStblDirector(ID), ) 18

CREATETABLEtblDirectors ( IDintIDENTITY(1,1)NOTNULL, FirstNameNameTypeNOTNULL, LastNameNameTypeNOTNULL, PRIMARYKEY(ID) ) CREATETYPEGenreTypeFROMvarchar(50) CREATETABLEtblGenres ( IDintIDENTITY(1,1)NOTNULL, TitleGenreType, PRIMARYKEY(ID), UNIQUE(Title) ) CREATETYPETitleTypeFROMvarchar(50) CREATETABLEtblDvds ( IDintIDENTITY(1,1)NOTNULL, TitleTitleTypeNOTNULL, RatingintDEFAULT0, YearPublishedintNOTNULL, PRIMARYKEY(ID) ) CREATETYPEKeywordTypeFROMvarchar(50) CREATETABLEtblKeywords ( IDintIDENTITY(1,1)NOTNULL, wordKeywordType, PRIMARYKEY(ID), UNIQUE(word) ) CREATETABLEtblPlaysIn { ActorintNOTNULL, DVDintNOTNULL, PRIMARYKEY(Actor,DVD), FOREIGNKEY(Actor)REFERENCEStblActors(ID), 19

FOREIGNKEY(DVD)REFERENCEStblDVD(ID), ) CREATETABLEtblRents( rentaldetails CustomerintNOTNULL, DVDintNOTNULL, CopyNumberintNOTNULL, DueDatedatetimeNOTNULL, RentDatedatetimeNOTNULL, PRIMARYKEY(Customer,DVD,CopyNumber), ) CREATETABLEtblRequests ( detailsofrequestfordvdmadebypremiumcustomers PremiumCustomerintNOTNULL, DVDintNOTNULL, RequestDatedatetimeNOTNULL PRIMARYKEY(PremiumCustomer,DVD), FOREIGNKEY(PremiumCustomer)REFERENCEStblCustomers(UserID), FOREIGNKEY(DVD)REFERENCEStblDVD(ID), )

7. System Architecture Revisited

We will be using the .net framework to implement our DVD rental system. This system uses a relational database server (Microsoft SQL Server 2005 Express Edition) to store the data, along with a web based front end working via the ASP .Net webserver. We used Microsoft Visual Studio 2008 Professional IDE to work on the ASP .Net and C#. A three tier architecture is implemented to make our code more manageable. It will be divided into data access layer, business logic layer and presentation layer. Part of data access layer and business logic layer was implemented with C# by using class mechanism. Because our system is based on 3-tier architecture, even if we desire to use different database server (eg.Oracle), we dont have to reimplement the business logic layer and presentation layer. In this case we only need to reimplement the data access layer. Data tier Microsoft SQL + (C# DAL) Logic tier C# (BLL)
20

Presentation tier ASP .NET (PL)