CSCI440 DATABASE SYSTEMS

RPG Database
Utilizing MySQL
Talon Daniels, James Blazicevich, & Steve Dighans 12/5/2011

Table of Contents

1 Table of Contents
2 SYSTEM REQUIREMENTS ............................................................................................................................... 2 2.1 2.2 3 4 5 6 7 CLIENT REQUIREMENTS ......................................................................................................................................2 DEVELOPER REQUIREMENTS ................................................................................................................................2

CONTEXTUAL DATA FLOW DIAGRAM ............................................................................................................ 4 ER MODEL ..................................................................................................................................................... 5 NORMALIZED DB MODEL............................................................................................................................... 6 DBMS RECOMMENDATION ........................................................................................................................... 7 IMPLEMENTATION DB MODEL ...................................................................................................................... 8 7.1 7.2 DB MODEL ......................................................................................................................................................8 NORMALIZATION LEVEL RATIONALE ......................................................................................................................9

8 9

DATA DICTIONARY ...................................................................................................................................... 10 SQL .............................................................................................................................................................. 13 9.1 9.2 9.3 9.4 9.5 SCHEMA CREATION .........................................................................................................................................13 EXAMPLE DEVELOPER QUERIES ..........................................................................................................................16 EXAMPLE USER CLIENT QUERIES ........................................................................................................................17 EXAMPLE DATABASE ADMINISTRATOR QUERIES ....................................................................................................17 IMPLEMENTATION SCREENSHOTS .......................................................................................................................18

10

TIME LOG .................................................................................................................................................... 20 10.1 10.2 10.3 TALON DANIELS ............................................................................................................................................20 JAMES BLAZICEVICH .......................................................................................................................................20 STEVE DIGHANS ............................................................................................................................................20

11

APPENDIX .................................................................................................................................................... 21 11.1 11.2 11.3 11.4 11.5 SYSTEM REQUIREMENTS ...................................................................................................................................21 CONTEXTUAL DATA FLOW DIAGRAM ..................................................................................................................22 ER DIAGRAM .................................................................................................................................................23 ER DIAGRAM PROGRESS...................................................................................................................................24 NORMALIZED DB MODEL PROGRESS ..................................................................................................................25

System Requirements

2 System Requirements
2.1 Client Requirements
Account o Customers must be able to create an account which will be used to manage the characters they create, along with various other things. Characters o Each account will be allowed to create characters with unique character names. The character will wear pieces of gear which have a power and defense amount, the sum of the power and defense on the gear will determine the power and defense of the character. Each character has an amount of gold which is used in shops. Additionally, the character will store the highest level zone it has access to in addition to how many enemies it has killed in that zone. Gear o Each character can wear up to four pieces of gear: a weapon, chest, legs, and helm. Each character can equip one of each type of gear and the characters total power and defense levels are calculated by summing the power and defense of all equipped items. Each piece of gear must be sold in only one shop, and all pieces of gear are sold in a shop. Monsters o Monsters are what the character will fight in order to progress through the game. Monsters that are defeated will drop gold based on their power. Monsters have a power and a defense level and monsters must appear in only one specific zone. Zones o Zones contain shops and a set of monsters. Each zone contains a specific monster which is a boss for that zone. The next zone is unlocked when the boss is defeated for the current zone. Zones have a size which determines how many monsters must be defeated before being able to fight the boss monster of the zone.

2.2 Developer Requirements

2.2.1 Entities Account Entity o Each account will be represented by an account entity with the following attributes: email, name, and password. The email column will be the primary key. Character Entity o Each character will be represented by a character entity with the following attributes: charName, gold, account, headGear, headType, chestArmor, chestType, legArmor, legType, weapon, and weaponType. The charName will be the primary key. The account column will be a foreign key to the account entity. headGear & headType, chestArmor & chestType, legArmor & legType, and weapon & weaponType will be composite foreign keys to the gear entity. Gear Entity o Each piece of gear will be represented by a gear entity with the following attributes: name, type, cost, power, defense, and soldIn. The name column and type column will be 2

System Requirements the composite primary key. The soldIn column will be a foreign key to the zone entity and must not be null. Zone Entity o Each zone will be represented by a zone entity with the following attributes: name, size, and description. The name column will be the primary key. Monster Entity o Each monster will be represented by a monster entity with the following attributes: name, power, defense, and zone. The name column will be the primary key. The zone column will be a foreign key to the zone entity. Zone must not be null. Relationships Character-Gear relationship o Since there are four types of gear, there will be eight columns in the character table for this relationship. The columns in the character table will be called headGear & headType, chestArmor & chestType, legArmor & legType, and weapon & weaponType. Each of these sets of columns will be composite foreign keys to the name and type column in the gear table. This is done in order to enforce gear being equipped to the correct gear slots on the character. Additionally, it reduces the amount of join operations between the character and gear table. Character-Account relationship o This is a simple 1 to many relationship which is implemented with each character having a foreign key called account, referencing the primary key of the account table. Character-Zone relationship o This relationship will be represented by a table called progress. This table will have the following attributes: name, zone, and numKills. The name column and zone column will be the composite primary key for the progress. The zone column will be not null and the numKills column is used to measure the progress of the character in that zone. The name column will have a unique constraint. Gear-Zone relationship o Since gear is only sold in one zone, the gear table has a soldIn column which is a foreign key to the zone table. The zone table will have a primary key which is referenced by the soldIn column in the gear table. Monster-Zone relationship o Since monsters are only found in one zone, the monster table has a zone column which is a foreign key to the zone table. The zone table will have a primary key which is referenced by the zone column in the monster table.

2.2.2

Contextual Data Flow Diagram

3 Contextual Data Flow Diagram

User with Account Shop data, monster data, zone data, login info, gold amount

Update character stats, monster kills, equipped gear, zone location RPG Database

Account creation status User without Account

Desired account information

Insert new monsters, gear, and zones

Information about existing content

RPG Developer

power
0:N 0:4

4 ER Model

gold

Character Gear

Equip

defense name
1:1 1:1

name
1:1

cost

type

Has

Progress In

Sold In

email
0:N

5
numKills Account
0:N 0:N 1:1

name
0:N

password

description

name size Monster In Zone name

power

defense

ER Model

Normalized DB Model

5 Normalized DB Model

DBMS Recommendation

6 DBMS Recommendation
For the implementation of our RPG database, we have chosen to go with MySQL. The first and foremost factor for our decision is price. Being free software, MySQL fits very nicely into our three respective college budgets. If we were to ever develop an RPG to use this database, we would also be doing so with other freely available tools, so it wouldnt make much sense to purchase a DBMS to use alongside other free tools. Secondly, MySQL is a good fit for all of our previous experiences with DBMSs. Before this class, one of our group members had never had written out SQL queries manually, while the other two group members who had in the past were experienced with MySQL. In addition to our previous experiences outside of CSCI 440, it seems logical to stick with the system that was presented to us during the semester for completion of the SQL assignment. Because all of the members of our group did favorably well on the assignment that required us to use the CS departments MySQL server, we wanted to stick with something that we knew we could get positive results from. In addition to our experiences with MySQL directly, all three of us have used the also freely available MySQL Workbench tool, and in order to speed up our development of the project we decided to stick with a tool where all three of us were familiar with the graphical user interface. Last but not least, we like the fact that MySQL adheres well to preset SQL standards. That way, theoretically, if an RPG utilizing our database ever became wildly popular, and required a more robust, enterprise level DBMS, the transition to such would be relatively easy. Furthermore, if other developers ever wanted to produce an RPG based game utilizing our database; it is beneficial to stick with a system that most developers would be familiar with. Even though these three factors are all good reasons to choose MySQL as our DBMS, it was not without issue. Originally our implementation model for the CHARACTER table only had the name of the headGear, chestArmor, legArmor and weapon. However, we found that MySQL does not support subqueries for a CHECK constraint. Because of this, the only way to ensure, for example, that a legArmor type was not placed in a CHARACTERs headGear category, is to make a constraint based on its type, requiring the key to be composite. This made our CHARACTER table 4 columns longer, but functionally the same. This however was a valuable learning experience, and from here on out we can anticipate not being able to use a sub-query to define a constraint in MySQL.

Implementation DB Model

7 Implementation DB Model
7.1 DB Model

Implementation DB Model

7.2 Normalization Level Rationale

For the implementation of our database, we decided to go with the third normal form. Not only is the third normal form the most intuitive when designing a database from the bottom up, but it is the most applicable to the way our database will function when an actual RPG will need to access values on a regular basis. Ensuring that all of the attributes are about the key, the whole key, and nothing but the key, eliminates ambiguity when requesting values that the top level software will rely upon for correct functionality. As you may notice however, our 3rd normal form model is not identical to our implementation ready model. This is because when requesting values for what gear a character has equipped, we would rather be able to query for the results directly instead of having to perform a join operation with our EQUIP table. This makes it much easier for a developer to query for the gear that a character is currently using, requiring only a simple select statement with no join operation. Having the CHARACTER table set up in this fashion also implicitly enforces our constraint that a character can only have 4 pieces of gear equipped at any one time. This constraint is not clear from the prospective of the EQUIP table, but becomes obvious when the attributes are in the CHARACTER table and given the applicable category names of headGear, chestArmor, legArmor and weapon. This also helps disambiguate the types of gear that are available from the perspective of the database model, so a developer desiring to build an RPG based off our database would be immediately informed of such constraints, instead of having to read them in a more technical documentation of the system.

Data Dictionary

8 Data Dictionary
Abbreviations used to describe the ROLE column E Entity A relationship of n entities to m R n:m entities A An attribute of an entity K Key attribute of an entity FK Foreign key of an entity Name ACCOUNT email accountName accountPassword CHARACTER Short Description The account of the user, unique to the user email associated with a specific account name of a user's account password of a user's account Playable characters in the RPG Role E K A A E Type Table String String String Table Format email, accountName, accountPassword VARCHAR(255) VARCHAR(45) VARCHAR(45) name, gold, account, headGear, headType, chestArmor, chestType, legArmor, legType, weapon, weaponType VARCHAR(255) INT(11) VARCHAR(255) VARCHAR(255) VARCHAR(45) VARCHAR(255) VARCHAR(45) VARCHAR(255) NULL allowed Default Value

NO NO NO

N/A N/A N/A

name gold account headGear headType chestArmor chestType legArmor

name of the playable character amount of gold a certain character has the account associated with the character the headgear item associated with a character the type of the headGear, to implement constraint the chest armor item associated with a character the chest armor type, to implement constraint the leg armor item associated with a character

K A FK A A A A A

String Integer String String String String String String

NO NO NO YES YES YES YES YES

N/A 0 N/A NULL NULL NULL NULL NULL

10

Data Dictionary

Name legType weapon weaponType GEAR name type

Short Description the leg armor type, to implement constraint the weapon associated with a character the weapon type, to implement constraint the different types of gear available, and their stats the name of the gear piece the type of the gear piece (headGear, chestArmor, legArmor, weapon) the cost of the gear piece, in units of gold the power of the gear piece, when it deals damage the amount of damage a gear piece can take the name of the zone where the gear piece is available the different types of monsters a character will battle the name of the monster the amount of damage the monster can deal the amount of damage the monster can take before it is killed the zone the monster can be found in the amount of progress that a character has made in the game, determined by the number of kills per zone

Role A A A E K K

Type String String String Table String String VARCHAR(45)

Format

NULL allowed YES YES YES

Default Value NULL NULL NULL

VARCHAR(255) VARCHAR(45) name, type, cost, power, defense, soldIn VARCHAR(255) VARCHAR(45)

NO NO

N/A N/A

cost power defense soldIn MONSTER name power defense zone PROGRESS

A A A FK E K A A FK R 1:N

Integer Integer Integer String Table String Integer Integer String Table

INT(11) INT(11) INT(11) VARCHAR(255) name, power, defense, zone VARCHAR(255) INT(11) INT(11) VARCHAR(255) name, zone, numKills

NO NO NO NO

0 0 0 N/A

NO NO NO NO

N/A 0 0 N/A

11

Data Dictionary

Name name zone numKills ZONE name size description

Short Description the name of the character making progress the name of the zone where progress was made the number of kills a character has made in a particular zone the places a character can go to battle monsters the name of the zone the size of the zone, in square units the flavor text of the particular zone

Role K K A E K A A

Type String String Integer Table String Integer String

Format VARCHAR(255) VARCHAR(255) INT(11) name, size, description VARCHAR(255) INT(11) VARCHAR(255)

NULL allowed NO NO NO

Default Value N/A N/A 0

NO NO YES

N/A 0 NULL

12

SQL

9 SQL
9.1 Schema Creation
SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0; SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0; SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL'; CREATE SCHEMA IF NOT EXISTS `RPGDatabase` DEFAULT CHARACTER SET latin1 ; USE `RPGDatabase` ; -- ------------------------------------------------------ Table `RPGDatabase`.`Account` -- ----------------------------------------------------DROP TABLE IF EXISTS `RPGDatabase`.`Account` ; CREATE TABLE IF NOT EXISTS `RPGDatabase`.`Account` ( `email` VARCHAR(255) NOT NULL , `accountName` VARCHAR(45) NOT NULL , `accountPassword` VARCHAR(45) NOT NULL , PRIMARY KEY (`email`) ) ENGINE = InnoDB;

-- ------------------------------------------------------ Table `RPGDatabase`.`Zone` -- ----------------------------------------------------DROP TABLE IF EXISTS `RPGDatabase`.`Zone` ; CREATE TABLE IF NOT EXISTS `RPGDatabase`.`Zone` ( `name` VARCHAR(255) NOT NULL , `size` INT NOT NULL DEFAULT 0 , `description` VARCHAR(255) NULL DEFAULT NULL , PRIMARY KEY (`name`) ) ENGINE = InnoDB;

-- ------------------------------------------------------ Table `RPGDatabase`.`Gear` -- ----------------------------------------------------DROP TABLE IF EXISTS `RPGDatabase`.`Gear` ; CREATE TABLE IF NOT EXISTS `RPGDatabase`.`Gear` ( `name` VARCHAR(255) NOT NULL , `type` VARCHAR(45) NOT NULL , `cost` INT NOT NULL DEFAULT 0 , `power` INT NOT NULL DEFAULT 0 ,

13

SQL
`defense` INT NOT NULL DEFAULT 0 , `soldIn` VARCHAR(255) NOT NULL , PRIMARY KEY (`name`, `type`) , INDEX `FK_SOLDIN` (`soldIn` ASC) , CONSTRAINT `FK_SOLDIN` FOREIGN KEY (`soldIn` ) REFERENCES `RPGDatabase`.`Zone` (`name` ) ON DELETE CASCADE ON UPDATE CASCADE) ENGINE = InnoDB;

-- ------------------------------------------------------ Table `RPGDatabase`.`Character` -- ----------------------------------------------------DROP TABLE IF EXISTS `RPGDatabase`.`Character` ; CREATE TABLE IF NOT EXISTS `RPGDatabase`.`Character` ( `name` VARCHAR(255) NOT NULL , `gold` INT NOT NULL DEFAULT 0 , `account` VARCHAR(255) NOT NULL , `headGear` VARCHAR(255) NULL DEFAULT NULL , `headType` VARCHAR(45) NULL DEFAULT NULL , `chestArmor` VARCHAR(255) NULL DEFAULT NULL , `chestType` VARCHAR(45) NULL DEFAULT NULL , `legArmor` VARCHAR(255) NULL DEFAULT NULL , `legType` VARCHAR(45) NULL DEFAULT NULL , `weapon` VARCHAR(255) NULL DEFAULT NULL , `weaponType` VARCHAR(45) NULL DEFAULT NULL , PRIMARY KEY (`name`) , INDEX `FK_ACCOUNT` (`account` ASC) , INDEX `FK_HEADGEAR` (`headGear` ASC, `headType` ASC) , INDEX `FK_CHESTARMOR` (`chestArmor` ASC, `chestType` ASC) , INDEX `FK_LEGARMOR` (`legArmor` ASC, `legType` ASC) , INDEX `FK_WEAPON` (`weapon` ASC, `weaponType` ASC) , CONSTRAINT `FK_ACCOUNT` FOREIGN KEY (`account` ) REFERENCES `RPGDatabase`.`Account` (`email` ) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT `FK_HEADGEAR` FOREIGN KEY (`headGear` , `headType` ) REFERENCES `RPGDatabase`.`Gear` (`name` , `type` ) ON DELETE SET NULL ON UPDATE CASCADE, CONSTRAINT `FK_CHESTARMOR` FOREIGN KEY (`chestArmor` , `chestType` ) REFERENCES `RPGDatabase`.`Gear` (`name` , `type` ) ON DELETE SET NULL

14

SQL
ON UPDATE CASCADE, CONSTRAINT `FK_LEGARMOR` FOREIGN KEY (`legArmor` , `legType` ) REFERENCES `RPGDatabase`.`Gear` (`name` , `type` ) ON DELETE SET NULL ON UPDATE CASCADE, CONSTRAINT `FK_WEAPON` FOREIGN KEY (`weapon` , `weaponType` ) REFERENCES `RPGDatabase`.`Gear` (`name` , `type` ) ON DELETE SET NULL ON UPDATE CASCADE, CONSTRAINT `CHK_HEADTYPE` CHECK (headType='head'), CONSTRAINT `CHK_CHESTTYPE` CHECK (chestType='chest'), CONSTRAINT `CHK_LEGTYPE` CHECK (legType='leg'), CONSTRAINT `CHK_WEAPONTYPE` CHECK (weaponType='weapon')) ENGINE = InnoDB;

-- ------------------------------------------------------ Table `RPGDatabase`.`Monster` -- ----------------------------------------------------DROP TABLE IF EXISTS `RPGDatabase`.`Monster` ; CREATE TABLE IF NOT EXISTS `RPGDatabase`.`Monster` ( `name` VARCHAR(255) NOT NULL , `power` INT NOT NULL DEFAULT 0 , `defense` INT NOT NULL DEFAULT 0 , `zone` VARCHAR(255) NOT NULL , PRIMARY KEY (`name`) , INDEX `FK_MONSTERZONE` (`zone` ASC) , CONSTRAINT `FK_MONSTERZONE` FOREIGN KEY (`zone` ) REFERENCES `RPGDatabase`.`Zone` (`name` ) ON DELETE CASCADE ON UPDATE CASCADE) ENGINE = InnoDB;

-- ------------------------------------------------------ Table `RPGDatabase`.`Progress` -- ----------------------------------------------------DROP TABLE IF EXISTS `RPGDatabase`.`Progress` ; CREATE TABLE IF NOT EXISTS `RPGDatabase`.`Progress` ( `name` VARCHAR(255) NOT NULL , `zone` VARCHAR(255) NOT NULL , `numKills` INT NOT NULL DEFAULT 0 , INDEX `FK_CHARNAME` (`name` ASC) , INDEX `FK_PROGRESSZONE` (`zone` ASC) ,

15

SQL
PRIMARY KEY (`name`, `zone`) , UNIQUE INDEX `name_UNIQUE` (`name` ASC) , CONSTRAINT `FK_CHARNAME` FOREIGN KEY (`name` ) REFERENCES `RPGDatabase`.`Character` (`name` ) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT `FK_PROGRESSZONE` FOREIGN KEY (`zone` ) REFERENCES `RPGDatabase`.`Zone` (`name` ) ON DELETE CASCADE ON UPDATE CASCADE) ENGINE = InnoDB;

SET SQL_MODE=@OLD_SQL_MODE; SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS; SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;

9.2 Example Developer Queries

Zone Creation
o INSERT INTO `RPGDatabase`.`Zone` (`name`, `size`, `description`) VALUES ('Forest', '20', 'Forest'); INSERT INTO `RPGDatabase`.`Gear` (`name`, `type`, `cost`, `power`, `defense`, `soldIn`) VALUES ('Shiny Helm', 'Helm', '1', '0', '2', 'Forest'); INSERT INTO `RPGDatabase`.`Monster` (`name`, `power`, `defense`, `zone`) VALUES ('Booshy Tree', '6', '9', 'Forest');

Gear Creation
o

Monster Creation
o

16

SQL

9.3 Example User Client Queries

Random Monster from a specific Zone
o SELECT * FROM `Monster` WHERE zone = 'Forest' ORDER BY RAND() LIMIT 1; SELECT SUM(gh.defense + gc.defense +gl.defense + gw.defense) AS defense, SUM(gh.power+ gc.power+gl.power+ gw.power) AS power FROM `Character` AS c JOIN(`Gear` AS gh,`Gear` AS gc,`Gear` AS gl,`Gear` AS gw) ON(gh.name = c.headGear AND gh.type = c.headType AND gc.name = c.chestArmor AND gc.type = c.chestType AND gl.name = c.legArmor AND gl.type = c.legType AND gw.name = c.weapon AND gw.type = c.weaponType) WHERE c.name = 'Bobert'; SELECT cost FROM `Gear` WHERE AND `type` = 'head'; `name` = 'Shiny Helm'

Return Characters total power and total defense

o

Cost of a Gear piece

o

9.4 Example Database Administrator Queries

Creating an Account
o INSERT INTO `RPGDatabase`.`Account` (`email`, `accountName`, `accountPassword`) VALUES ('angryk@cs.montana.edu', 'angryk', 'angryk'); INSERT INTO `RPGDatabase`.`Character` (`name`, `gold`, `account`, `headGear`, `headType`, `chestArmor`, `chestType`, `legArmor`, `legType`, `weapon`, `weaponType`) VALUES ('AMadK', '9002', 'angryk@cs.montana.edu', 'Shiny Helm', 'head', NULL, NULL, NULL, NULL, NULL, NULL); DELETE FROM `Character` WHERE name ='Bobert';

Creating a Character
o

Delete Character
o

17

SQL

9.5 Implementation Screenshots

Figure 9-1 MySQL Workbench representation of the database schema

18

SQL

Figure 9-2 phpMyAdmin representation of the CHARACTER table

19

Time Log

10 Time Log
10.1 Talon Daniels
Task Client Requirements Developer Requirements Contextual Data Flow Diagram ER Model Normalized DB Model DBMS Recommendation Implemtation DB Model Normalization Level Rationale Data Dictionary SQL Hours Spent 1 3 0.5 2 0.25 0.25 3 0.25 1.5 0.5

X_____________________________________

10.2 James Blazicevich

Task Client Requirements Developer Requirements Contextual Data Flow Diagram ER Model Normalized DB Model DBMS Recommendation Implemtation DB Model Normalization Level Rationale Data Dictionary SQL Hours Spent 0.25 0.25 0.25 2 2.25 2 1.5 2 2.5 0.25

X_____________________________________

10.3 Steve Dighans

Task Client Requirements Developer Requirements Contextual Data Flow Diagram ER Model Normalized DB Model DBMS Recommendation Implemtation DB Model Normalization Level Rationale Data Dictionary SQL Hours Spent 0.25 0.5 0.75 0.5 1 0.25 2 0.25 1 5

X_____________________________________

20

Appendix

11 Appendix
11.1 System Requirements

21

Appendix

11.2 Contextual Data Flow Diagram

22

Appendix

11.3 ER Diagram

23

Appendix

11.4 ER Diagram Progress

24

Appendix

11.5 Normalized DB Model Progress

25