MIS407-1 Portfolio Project Jerrod Rodgers w metadata

Running head: PORTFOLIO PROJECT 1
Portfolio Project
Jerrod Rodgers
MIS407-1 – Database Concepts
Colorado State University – Global Campus
Dr. Reginald Haseltine
January 25, 2016

PORTFOLIO PROJECT 2
Portfolio Project
This portfolio project uses a narrative from the eighth course module in which a business
wishes to implement a relational database system to replace their paper files. From the narrative
the required entities and their attributes, the relationships between the identified entities, and an
entity relationship diagram have been determined. From those a spreadsheet of the databases
metadata has been created also. In succession a database named
“MomandPopJohnsonVideoStore” has been created, populated, and manipulated to retrieve and
alter data. Please note all references to video tapes shall be referred to as VHS.
The Database Lifecycle
Much like the development of any information technology system, the creation and
implementation of a database must follow the relational Database Life Cycle (DBLC). The
DBLC has five primary steps or stages; requirements analysis, logical design, physical design,
implementation, and monitoring, modification and maintenance (RelationalDBDesign, n.d.).
While some define additional stages like feasibility studies, testing, etc. (Shiflet, 2002), the
primary development portions include a requirements analysis, logical design, physical design,
implementation, and monitoring/maintenance. Each of stage must be followed during the
development of a database to ensure accuracy in the creation stages. Any oversight could result
in extensive modifications or rebuilding of sections of the database. For this portfolio project the
first four stages are mostly used as the database does not require monitoring or maintenance in
this instance.
As a generally labor-intensive stage, gathering requirements of a proposed database
involves determining what the database will be required to do. How much data it will need to

PORTFOLIO PROJECT 3
store, what the entities of the database will be, and what their attributes are. These entities will
become the tables of the database with their attributes becoming the columns of data. This
process provides the developer with a list of what the database will be made up of.
The next step, Logical Design, has a couple parts including a conceptual design of the
database, and entity relationship modeling. This conceptual design includes a description of the
databases structure by the way of Entity Relationship Sentence Pairs. These allow the developer
a way to list each relationship between entities, in both directions. This is a crucial step that must
be carefully reviewed to discover potential relationship errors such as many-to-many
relationships. These types of relationships can cause several instances of data to be grouped
together thus destroying a data sets attributes. These many-to-many relationships must be
removed by way of a bridge entity. This creates a new entity with its own attributes that must be
added to the list of entities for proper database development.
The second part of the Logical Design step requires the creation of an Entity Relationship
Diagram (ERD). The ERD, or entity relationship model, is a blueprint of the database. It lays out
the tables, their attributes, and the relationships between the entities, while also identifying an
entities primary keys and foreign keys. From this the developer is able to develop a spreadsheet
of the database’s metadata.
This spreadsheet of metadata satisfies the Physical Design step by clearly listing the table
names, primary and foreign keys, and attributes of each table. Additionally, the type and size of
data for each attribute as well as a brief description of the attribute is included. This gives the
database developer a set of defined parameters for the implementation stage.

PORTFOLIO PROJECT 4
During the implementation stage the developer uses the parameters from the metadata
spreadsheet to create SQL statements to design each table. Using the metadata, it is possible to
create each table including its columns, the type and size of data allowed in the columns, and
how the data from one column may be related to another table. Because of these relations
between entities most relational database management systems impose constraints restricting the
modification or deletion of some data as it may have implications beyond its primary table. Thus
the development cycle must be closely followed and reviewed prior to this step to reduce or
eliminate errors in implementation.
Entity and Attribute Identification
Using the information about the “Mom and Pop Johnson Video Store” from the portfolio
project description it is possible to discern that the following are to be considered entities in the
new database. Each entity is followed by its attributes which are used to describe each instance
of the entity. The entity will can be recognized by all capital letters and the attributes shall have
both upper and lower case letters.
• CUSTOMERS: CustomerID, LastName, FirstName, MiddleName, StreetAddress, City,
State, ZipCode, Phone, and email.
• TRANSACTIONS: TransactionID, DateRented, Tax, InitialPrice, Fees, RentalTotal.
• MOVIES: MovieID, Title, Genre, Rating, Runtime, YearReleased.
• DVDS: DvdID.
• VHS: VhsID.

PORTFOLIO PROJECT 5
• DIRECTORS: DirectorID, LastName, FirstName.
• ACTORS: ActorID, LastName, FirstName.
• ACTRESSES: ActressID, LastName, FirstName.
• AWARDS: AwardID, AwardName.
• DISTRIBUTOR: DistributorID, Name.
• DISTMOVIE: DistMovieID, Title, Genre, Rating, Runtime, YearReleased.
• DISTDVD: DistDvdID.
• DISTVHS: DistVhsID.
Based upon these primary entities the relationship sentence pairs were made. However, it
was found that using only these entities would result in several many-to-many relationships such
as; an ACTRESS can have many MOVIES, and a MOVIE can have many ACTRESSES. Thus
the following bridge entities were created to absolve these many-to-many relationships.
• DVDTRANSACTIONLINEITEMS: DVDTranLineItemID, DateRented, DateReturned,
LateFee, DamageFee, RentalPrice, LineTotal.
• VHSTRANSACTIONLINEITEMS: VHSTranLineItemID, DateRented, DateReturned,
LateFee, DamageFee, RewindFee, RentalPrice, LineTotal.
• DIRECTORLINEINDIVIDUALS: DirectorLineIndID.
• ACTORLINEINDIVIDUALS: ActorLineIndID.

PORTFOLIO PROJECT 6
• ACTRESSLINEINDIVIDUALS: ActressLineIndID.
• AWARDLINEITEMS: AwardLineItemID
• DVDDISTRIBUTORLINEITEMS: DVDDistLineItemID
• VHSDISTRIBUTORLINEITEMS: VHSDistLineItemID
Entity Relationship Sentence Pairs
Once the entities and attributes are identified it is possible to create entity relationship
sentence pairs. These identify the relationships between entities which assist in building a visual
model as well as identifying any many-to-many relationships which must be removed by using a
bridge entity. The following sentences reflect the use of bridge entities therefore all many-to-
many relationships have already been dissolved. Once again entities are identified by all capital
letters. Note: there is an assumption that the Mom and Pop Johnson Video Store purchases a
specific movie in a specific format from only
• A CUSTOMER can have many TRANSACTIONS.
• A TRANSACTION must have only one CUSTOMER.
• A TRANSACTION can have many DVDTRANSACTIONLINEITEMS.
• A DVDTRANSACTIONLINEITEM must have only one TRANSACTION.
• A DVDTRANSACTIONLINEITEM must have only one DVD.
• A DVD can have many DVDTRANSACTIONLINEITEMS.

PORTFOLIO PROJECT 7
• A DVDTRANSACTIONLINEITEM must have only one MOVIE.
• A MOVIE can have many DVDTRANSACTIONLINEITEMS.
• A TRANSACTION can have many VHSTRANSACTIONLINEITEMS.
• A VHSTRANSACTIONLINEITEM must have only one TRANSACTION.
• A VHSTRANSACTIONLINEITEM must have only one VHS.
• A VHS can have many VHSTRANSACTIONLINEITEMS.
• A VHSTRANSACTIONLINEITEM must have only one MOVIE.
• A MOVIE can have many VHSTRANSACTIONLINEITEMS.
• A MOVIE can have many VHS.
• A VHS must have only one MOVIE.
• A MOVIE can have many DVDS.
• A DVD must have only one MOVIE.
• A MOVIE must have one or more DIRECTORLINEINDIVIDUALS.
• A DIRECTORLINEINDIVIDUAL must have only one MOVIE.
• A DIRECTORLINEINDIVIDUAL must have only one DIRECTOR.
• A DIRECTOR can have many DIRECTORLINEINDIVIDUALS.

PORTFOLIO PROJECT 8
• A MOVIE can have many ACTRESSLINEINDIVIDUALS.
• An ACTRESSLINEINDIVIDUAL must have only one MOVIE.
• A ACTRESSLINEINDIVIDUAL must have only one ACTRESS.
• An ACTRESS can have many ACTRESSLINEINDIVIDUALS.
• A MOVIE can have many ACTORLINEINDIVIDUALS.
• A ACTORLINEINDIVIDUAL must have only one MOVIE.
• A ACTORLINEINDIVIDUAL must have only one ACTOR.
• An ACTOR can have many ACTORLINEINDIVIDUALS.
• A MOVIE can have many AWARDLINEITEMS.
• A AWARDLINEITEM must have only one MOVIE.
• A AWARDLINEITEM can have one DIRECTOR.
• A DIRECTOR can have many AWARDLINEITEMS.
• A AWARDLINEITEM can have one ACTOR.
• A ACTOR can have many AWARDLINEITEMS.
• A AWARDLINEITEM can have one ACTRESS.
• A ACTRESS can have many AWARDLINEITEMS.

PORTFOLIO PROJECT 9
• A AWARDLINEITEMS must have only one AWARD.
• A AWARD can have many AWARDLINEITEMS.
• A MOVIE can have many DVDDISTRIBUTORLINEITEMS.
• A DVDDISTRIBUTORLINEITEM must have only one MOVIE
• A DVDDISTRIBUTORLINEITEM must have only one DISTDVD.
• A DISTDVD can have many DVDDISTRIBUTORLINEITEMS.
• A DVDDISTRIBUTORLINEITEM must have only one DISTMOVIE.
• A DISTMOVIE can have many DVDDISTRIBUTORLINEITEMS.
• A DVDDISTRIBUTORLINEITEM must have only one DISTRIBUTOR.
• A DISTRIBUTOR can have many DVDDISTRIBUTORLINEITEMS.
• A MOVIE can have many VHSDISTRIBUTORLINEITEMS.
• A VHSDISTRIBUTORLINEITEM must have only one MOVIE.
• A VHSDISTRIBUTORLINEITEM must have only one DISTVHS.
• A DISTVHS can have many VHSDISTRIBUTORLINEITEMS.
• A VHSDISTRIBUTORLINEITEM must have only one DISTMOVIE.
• A DISTMOVIE can have many VHSDISTRIBUTORLINEITEMS.

PORTFOLIO PROJECT 10
• A VHSDISTRIBUTORLINEITEM must have only one DISTRIBUTOR.
• A DISTRIBUTOR can have many VHSDISTRIBUTORLINEITEMS.
• A DISTMOVIE can have many DISTDVDS.
• A DISTDVD must have only one DISTMOVIE.
• A DISTMOVIE can have many DISTVHS.
• A DISTVHS must have only one DISTMOVIE.
Entity Relationship Diagram
Using the identified entities and entity relationship sentence pairs it is possible to create
an Entity Relationship Diagram (ERD). The ERD seen in Figure 1 shows the aforementioned
entities and their attributes as well as the relationships between each entity. In addition, the ERD
shows which attribute will be the entities primary key, which is a unique identifier to each
instance of data, while also showing what attribute will be used to connect entities by way of a
foreign key. These foreign keys are unique identifiers of a single instance of data within another
entity.

Figure 1. An Entity Relationship Diagram of the proposed database for Mom and Pop Johnson
Video Store. Blue identifies primary entities while yellow identifies bridge entities.

Metadata
Using the ERD is then possible to create a metadata table which is used to identify
specifics about each entity’s attributes. Each attribute is listed as well as its primary or foreign
key status, if any, the type of data, size, and if nulls are allowed. This metadata table is then used
to create each table of the database giving the developer a set list of details about each attribute
to ensure accuracy in creation.
Key Type(s) Column Name Data Type Size Can be NULL? Description
Primary Key AccountID int No Unique Customer Identifier
LastName nvarchar 30 No Last Name of Customer
FirstName nvarchar 20 No First Name of Customer
MiddleName nvarchar 20 Yes Middle Name of Customer
StreetAddress nvarchar 50 No Street Address of Customer
City nvarchar 30 No City of Customer
State char 2 No State of Customer
ZipCode nvarchar 10 No Zip Code of Customer
Phone1 nvarchar 10 No Customer's Primary Phone Number
Phone2 nvarchar 10 Yes Customer's Secondary Phone Number
Email1 Xml No Customer's Primary Email Address
Email2 Xml Yes Customer's Secondary Email Address
Primary Key TransactionID int No Unique Transaction Identifier
Foreign Key AccountID int No Reference to Customer Identifier
DateRented date No Date Items Were Rented
Tax money No Tax Assessed to Transaction
InitialPrice money No Starting Total with Tax Before Fees if any
Fees money No Total of Fees to be Added to Total
RentalTotal money No Total Including Tax, Initial Price, and Fees if any
Primary Key DVDTranLineItemID int No Unique Identifier to Transaction Line Item
Foreign Key TransactionID int No Reference to a Specific Transaction
Foreign Key MovieID int No Reference to a Specific Movie
Foreign Key DVDID int No Reference to a specific DVD
DateRented date No Date DVD was Rented
DateReturned date Yes Date DVD was Returned if Applicable
LateFee money No Late Fee ifNecessary
DamageFee money No Fee for Damage or Replacement of Item
RentalPrice money No Price of Rented Item Including Sale or Disc.
LineTotal money No Total of LateFee, DamageFee, and RentalPrice
Primary Key VHSTranLineItemID int No Unique Identifier to Transaction Line Item
Foreign Key TransactionID int No Reference to a Specific Transaction
Foreign Key VHSID int No Reference to a specific VHS
DateRented date No Date VHS was Rented
DateReturned date Yes Date VHS was Returned if Applicable
LateFee money No Late Fee ifNecessary
DamageFee money No Fee for Damage or Replacement of Item
RewindFee money No Fee for Rewinding VHS if Applicable
RentalPrice money No Price of Rented Item Including Sale or Disc.
LineTotal money No Total of LateFee, DamageFee, RewindFee and RentalPrice
Primary Key DVDID int No Unique Identifier to DVD
CUSTOMERS Table
TRANSACTIONS Table
DVDTRANSACTIONLINEITEMS Table
VHSTRANSACTIONLINEITEMS Table
DVDS Table

Primary Key VHSID int No Unique Identifier to VHS
Primary Key MovieID int No Unique Identifier to Movie
Title nvarchar 50 No Title of Movie
Genre nvarchar 20 No Genre of Movie
Rating nvarchar 4 No Rating of Film
Runtime time(0) No Runtime of Film
YearReleased numeric(4, 0) 4 No Year Filmwas Released
Primary Key DirectorLineIndID int No Unique Identifier to Director Line Indv.
Foreign Key DirectorID int No Reference to a Specific Director
Primary Key ActorLineIndID int No Unique Identifier to Actor Line Indv.
Foreign Key ActorID int No Reference to a Specific Actor
Primary Key ActressLineIndID int No Unique Identifier to Actress Line Indv.
Foreign Key ActressID int No Reference to a Specific Actress
Primary Key DirectorID int No Unique Identifier to Director
LastName nvarchar 30 No Last Name of Director
FirstName nvarchar 30 No First Name of Director
Primary Key ActorID int No Unique Identifier to Actor
LastName nvarchar 30 No Last Name of Actor
FirstName nvarchar 30 No First Name of Actor
Primary Key ActressID int No Unique Identifier to Actress.
LastName nvarchar 30 No Last Name of Actress
FirstName nvarchar 30 No First Name of Actress
Primary Key AwardLineItemID int No Unique Identifier to Award Line Item
Foreign Key AwardID int No Reference to Specific Award
Foreign Key MovieID int No Reference to Specific Movie
Foreign Key DirectorID int No Reference to Specific Director
Foreign Key ActorID int No Reference to Specific Actor
Foreign Key ActressID int No Reference to Specific Actress
Primary Key AwardID int No Unique Identifier to Award
AwardName nvarchar 50 No Name of Award Given
Primary Key DVDDistLineItemID int No Unique Identifier to DVD Dist. Line Item
Foreign Key DistributorID int No Reference to Specific Distributor
Foreign Key DistMovieID int No Reference to Specific Dist. Movie
Foreign Key DistDVDID int Yes Reference to Specific Dist. DVD
DIRECTORS Table
VHS Table
MOVIES Table
DIRECTORLINEINDIVIDUALS Table
ACTORLINEINDIVIDUALS Table
ACTRESSLINEINDIVIDUALS Table
ACTORS Table
ACTRESSES Table
AWARDSLINEITEMS Table
AWARDS Table
DVDDISTRIBUTORLINEITEMS Table

Primary Key VHSDistLineItemID int No Unique Identifier to VHS Dist. Line Item
Foreign Key DistributorID int No Reference to Specific Distributor
Foreign Key DistMovieID int No Reference to Specific Dist. Movie
Foreign Key DistVHSID int Yes Reference to Specific Dist. DVD
Primary Key DistMovieID int No Unique Identifier to Distributor Movie
Title nvarchar 50 No Title of Movie
Genre nvarchar 20 No Genre of Movie
Rating nvarchar 4 No Rating of Film
Runtime time(0) No Runtime of Film
YearReleased numeric(4, 0) 4 No Year Film was Released
Primary Key DistributorID int No Unique Identifier to Distributor
Name nvarchar 50 No Name of Distributor
Primary Key DistDVDID int No Unique Identifier to Dist. DVD
Foreign Key DistMovieID int No Reference to Dist. Movie
Primary Key DistVHSID int No Unique Identifier to Dist. VHS
Foreign Key DistMovieID int No Reference to Dist. Movie
DISTRIBUTORS Table
DISTDVD Table
DISTVHS Table
VHSDISTRIBUTORLINEITEMS Table
DISTMOVIE Table
DDL CREATE SQL Script
The following images are screenshots showing the creating of the required tables for the
database. The images are in alphabetical order by table name, however they were designed in the
following order due to foreign key constraints; CUSTOMERS, TRANSACTIONS, MOVIES,
DVDS, VHS, AWARDS, DIRECTORS, ACTORS, ACTRESSES, DISTRIBUTORS,
DISTMOVIES, DISTDVDS, DISTVHS, VHSTRANSACTIONLINEITEMS,
DVDTRANSACTIONLINEITEMS, DIRECTORLINEINDIVIDUALS,
ACTORLINEINDIVIDUALS, ACTRESSLINEINDIVIDUALS, AWARDLINEITEMS,
DVDDISTRIBUTORLINEITEMS, and VHSDISTRIBUTORLINEITEMS.

Figure 2. CREATE SQL Statement for the creation of the ACTORLINEINDIVIDUALS table.
Figure 3. CREATE SQL Statement for the creation of the ACTORS table.

Figure 4. CREATE SQL Statement for the creation of the ACTRESSES table.
Figure 5. CREATE SQL Statement for the creation of the ACTRESSLINEINDIVIDUALS
table.

Figure 6. CREATE SQL Statement for the creation of the AWARDS table.
Figure 7. CREATE SQL Statement for the creation of the AWARDLINEITEMS table.

Figure 8. CREATE SQL Statement for the creation of the CUSTOMERS table.

Figure 9. CREATE SQL Statement for the creation of the DIRECTORLINEINDIVIDUALS
table.
Figure 10. CREATE SQL Statement for the creation of the DIRECTORS table.
Figure 11. CREATE SQL Statement for the creation of the DISTDVDS table.

Figure 12. CREATE SQL Statement for the creation of the DISTMOVIES table.
Figure 13. CREATE SQL Statement for the creation of the DISTRIBUTORS table.

Figure 14. CREATE SQL Statement for the creation of the DISTVHS table.
Figure 15. CREATE SQL Statement for the creation of the DVDDISTRIBUTORLINEITEMS
table.

Figure 16. CREATE SQL Statement for the creation of the DVDS table.
Figure 17. CREATE SQL Statement for the creation of the DVDTRANSACTIONLINEITEMS
table.

Figure 18. CREATE SQL Statement for the creation of the MOVIES table.
Figure 19. CREATE SQL Statement for the creation of the TRANSACTIONS table.

Figure 20. CREATE SQL Statement for the creation of the VHS table.
Figure 21. CREATE SQL Statement for the creation of the VHSDISTRIBUTORLINEITEMS
table.

Figure 22. CREATE SQL Statement for the creation of the VHSTRANSACTIONLINEITEMS
table.
The following images show alterations to the already designed tables in which columns
with functions were added, as well as alterations to existing columns. The addition of columns
occurred after they were deleted using a DROP statement.
Figure 23. ALTER and ADD SQL Statements for the creation of the LineTotal column that
calculates all costs in a tuple of the DVDTRANSACTIONSLINEITEMS table.

Figure 24. ALTER and ADD SQL Statements for the creation of the LineTotal column that
calculates all costs in a tuple of the VHSTRANSACTIONSLINEITEMS table.
Figure 25. ALTER and ADD SQL Statements for the creation of the RentalTotal column that
calculates all costs in a tuple of the TRANSACTIONS table.

Figure 26. ALTER SQL Statements to change the DamageFee column to NOT NULL in the
DVDTRANSACTIONSLINEITEMS table, similar statements were conducted for LateFee and
Rewind fee for the aforementioned table and VHSTRANSACTIONLINEITEMS.
Figure 27. ALTER SQL Statements to change the quantity of digits required for the Runtime
column of the DISTMOVIES table.
Figure 28. ALTER SQL Statements to change the quantity of digits required for the Runtime
column of the MOVIES table.
SQL INSERT Statements

The following images show SQL INSERT Statements to populate the tables with data.
The images again are in alphabetical order by table name but were populated in the same order
as creation.
Figure 29. INSERT SQL Statements to populate the ACTORLINEINDIVIDUALS table.

Figure 30. INSERT SQL Statements to populate the ACTORS table.
Figure 31. INSERT SQL Statements to populate the ACTRESSLINEINDIVIDUALS table.

Figure 32. INSERT SQL Statements to populate the ACTRESSES table.
Figure 33. INSERT SQL Statements to populate the AWARDLINEITEMS table.

Figure 34. INSERT SQL Statements to populate the AWARDS table.
Figure 35 a & b. INSERT SQL Statements to populate the CUSTOMERS table.

Figure 36. INSERT SQL Statements to populate the DIRECTORLINEINDIVIDUALS table.
Figure 37. INSERT SQL Statements to populate the DIRECTORS table.
Figure 38. INSERT SQL Statements to populate the DISTDVDS table.

Figure 39. INSERT SQL Statements to populate the DISTMOVIES table.
Figure 40. INSERT SQL Statements to populate the DISTRIBUTORS table.

Figure 41. INSERT SQL Statements to populate the DISTVHS table.
Figure 42. INSERT SQL Statements to populate the DVDTRANSACTIONLINEITEMS table.

Figure 43. INSERT SQL Statements to populate the DVDDISTRIBUTORLINEITEMS table.
Figure 44. INSERT SQL Statements to populate the DVDS table.

Figure 45. INSERT SQL Statements to populate the MOVIES table. Note errors corrected in
Figure 46.
Figure 46. INSERT SQL Statements to populate the MOVIES table.

Figure 47. INSERT SQL Statements to populate the TRANSACTIONS table.
Figure 48. INSERT SQL Statements to populate the VHSTRANSACTIONLINEITEMS table.

Figure 49. INSERT SQL Statements to populate the VHS table.
Contents of Tables Using SELECT Statements
Figure 50. SELECT * (all) SQL Statements to retrieve all data in the
ACTORLINEINDIVIDUALS table.

Figure 51. SELECT * (all) SQL Statements to retrieve all data in the ACTORS table.
Figure 52. SELECT * (all) SQL Statements to retrieve all data in the ACTRESSESS table.

ACTRESSLINEINDIVIDUALS table.
Figure 53. SELECT * (all) SQL Statements to retrieve all data in the AWARDLINEITEMS
table.

Figure 54. SELECT * (all) SQL Statements to retrieve all data in the AWARDS table.
Figure 55. SELECT * (all) SQL Statements to retrieve all data in the CUSTOMERS table.
DIRECTORLINEINDIVIDUALS table.

Figure 57. SELECT * (all) SQL Statements to retrieve all data in the DIRECTORS table.
Figure 58. SELECT * (all) SQL Statements to retrieve all data in the DISTDVDS table.

Figure 59. SELECT * (all) SQL Statements to retrieve all data in the DISTMOVIES table.
Figure 60. SELECT * (all) SQL Statements to retrieve all data in the DISTRIBUTORS table.

Figure 61. SELECT * (all) SQL Statements to retrieve all data in the DISTVHS table.
DVDDISTRIBUTORLINEITEMS table.

Figure 63. SELECT * (all) SQL Statements to retrieve all data in the DVDS table.
DVDTRANSACTIONLINEITEMS table.

Figure 65. SELECT * (all) SQL Statements to retrieve all data in the MOVIES table.
Figure 66. SELECT * (all) SQL Statements to retrieve all data in the TRANSACTIONS table.

Figure 67. SELECT * (all) SQL Statements to retrieve all data in the VHS table.
VHSDISTRIBUTORLINEITEMS table.

VHSTRANSACTIONLINEITEMS table.
CUSTOMER Query 7.2
Figure 70. SELECT query on the CUSTOMER table specifying columns desired and sorting
option.
Last 30 Day DVD Rental 7.3

Figure 71. A SELECT and INNER JOIN statement to retrieve DVD rentals within the last 30
days by movie title and date rented.
Customer UPDATE 7.4
Figure 72. An UPDATE statement to change a customer’s maiden name to their married name.
DELETE a Customer 7.5

Figure 73. A DELETE statement to remove a customer from the database.
Figure 74. The results from this statement show the DELETE statement in Figure 73 was
successful.
Conclusion
In an overview of this course and the lessons learned from it the writer has determined
the following. The requirement gathering and logical design portion of the database life cycle is
nearly more important than understanding the relational database management system or SQL
language itself. Without proper planning the implementation phase can cause catastrophic
obstacles in which at times the most efficient route is to delete the database and start from
scratch. This is not a preferred method, especially when dealing with large databases holding
several tables with multiple relationships. An in-depth development and review of the logical
phase equals an efficient and accurate database development process.

References
RelationalDBDesign. (n.d.). DBLC Design Stages: Database Life Cycle. Retrieved from
http://www.relationaldbdesign.com/relational-database-design/module3/dblc-design-
stages.php
Shiflet, A. B. (2002). Database Application Lifecycle. Retrieved from http://www.wofford-
ecs.org/DataAndVisualization/DatabaseDevelopment/material.htm

MIS407-1 Portfolio Project Jerrod Rodgers w metadata

Recommended

Recommended

More Related Content

Similar to MIS407-1 Portfolio Project Jerrod Rodgers w metadata

Similar to MIS407-1 Portfolio Project Jerrod Rodgers w metadata (20)

MIS407-1 Portfolio Project Jerrod Rodgers w metadata