IDB Assignment BingBing Legend Online Game Final

BingBing Legend Mobile Game Database system
About
Case study
FierceOne Sdn. Bhd. wishes to develop a new mobile application, named “BingBing Legend”
which is a Multi-Player Online Battle Arena game. The company has completed its game flow plan and
interface designs, but as for database design, the company has hired our team to help in designing and
implementing the database. This BingBing Legend mobile game has several requirements and features
that need to be satisfied as stated in the given scenario.
The Team
Name Signature TP number

BANA MAHER ALI QUBBEJ BANA TP057739
DAHIYA ABHAY SINGH ABHAY TP047179
Yahya Sherif Solayman Mohamed Saleh Yahya TP057094
ZAINA MAHER ALI QUBBEJ ZAINA TP057738
Signature taken on 22nd of June, 2020
Page | ii
Abstract
This project designs, implements, and documents a database system for BingBing Legend Mobile
Game as per the specification of FierceOne Sdn. The project starts by outlining the disadvantages of a
file-based system as a general concept and for BingBing Legend specifically, and how a database system
is an efficient solution. The project then _IDentifies the business rules of the system creating a
nomalized databases, and then present the data in an Entity Relationship. Finally, along with some
queries, a database schema is implemented with a DDL and DML.
Page | iii
Table of Content
Contents
About .............................................................................................................................................................ii
Case study ..................................................................................................................................................ii
The Team ...................................................................................................................................................ii
Abstract ........................................................................................................................................................iii
Table of Content ...........................................................................................................................................iv
Table of Figures ...........................................................................................................................................vii
Table of Tables............................................................................................................................................viii
1.0 Database and Database Management System ........................................................................................ix
Disadvantages of File-based system .........................................................................................................ix
Advantages of Database and DBMS ........................................................................................................ix
2.0 Business Rules .........................................................................................................................................x
2.1 Defenition ............................................................................................................................................x
2.2 Keywords .............................................................................................................................................x
2.3 Business rules with respect to BingBing Legend Online Game ..........................................................x
2.3.1 Entities: .........................................................................................................................................x
2.3.2 Attributes ....................................................................................................................................xii
2.3.3 Relationships ............................................................................................................................xvii
2.4 Constraints ........................................................................................................................................xxi
2.4.1 Logical Constraints ....................................................................................................................xxi
2.4.2 Null Constraints .........................................................................................................................xxi
2.4.3 Unique Constraints ....................................................................................................................xxi
2.4.4 Primary Keys Constraints ..........................................................................................................xxi
2.4.5 Default Constraints ...................................................................................................................xxii
3.0 Normalization .....................................................................................................................................xxiii
3.1 Definition........................................................................................................................................xxiii
3.2 Benefits ...........................................................................................................................................xxiii
3.3 Forms ..............................................................................................................................................xxiii
3.3.1 Unnormalized form (UNF) ......................................................................................................xxiii
3.3.2 First normalized form (1NF) ...................................................................................................xxiv
3.3.3 Second normalized form (2NF) ...............................................................................................xxiv
3.3.4 Third normalized form (3NF) ...................................................................................................xxv
4.0 Entity Relationship Diagram ..............................................................................................................xxvi
4.1 Definition ........................................................................................................................................xxvi
4.1.1 steps involved in creating an ERD include:.............................................................................xxvi
4.2 Designing Database ........................................................................................................................xxvi
Page | iv
4.2.1 Tool used ..................................................................................................................................xxvi

4.4 ERD Design ...................................................................................................................................xxvii
5.0 Database Schema ..............................................................................................................................xxviii
5.1 Data Base Diagram .......................................................................................................................xxviii
5.1 EERD ..............................................................................................................................................xxix
5.2 Data Dictionary...............................................................................................................................xxix
6.0 SQL-Data Definition Language (DDL) .............................................................................................xxxv
6.1 Creating the DataBase ...................................................................................................................xxxv
6.2 Creating tables ...............................................................................................................................xxxv
6.2.1 Player account table ................................................................................................................xxxv
6.2.2 Hero table................................................................................................................................xxxv
6.2.3 Skin table ................................................................................................................................xxxv
6.2.4 Personal Statistics table .........................................................................................................xxxvi
6.2.5 Player Hero table ...................................................................................................................xxxvi
6.2.6 Hero Skin table ......................................................................................................................xxxvi
6.2.7 Game Mode table .................................................................................................................xxxvii
6.2.8 Team table.............................................................................................................................xxxvii
6.2.9 Game Table ...........................................................................................................................xxxvii
6.3 Inserting values...........................................................................................................................xxxviii
6.3.1 Player Account Table ...........................................................................................................xxxviii
6.3.2 Hero Table ...........................................................................................................................xxxviii
6.3.3 Skin Table ..............................................................................................................................xxxix
6.3.4 Personal Statistics Table ........................................................................................................xxxix
6.3.5 Player Hero Table ........................................................................................................................xl
6.3.6 Hero Skin Table ...........................................................................................................................xl
6.3.7 Game Mode Table ......................................................................................................................xli
6.3.8 Team Table..................................................................................................................................xli
6.3.9 Game Table ................................................................................................................................xlii
7.0 SQL-Data Manipulation Language (DML).........................................................................................xliii
7.1 Student Query ..................................................................................................................................xliii
7.1.1 Student 1 (Yahya Sherif Solayman Mohamed Saleh) ..............................................................xliii
7.1.2 Student 2 (BANA MAHER ALI QUBBEJ) .............................................................................xliv
7.1.3 Student 3 (DAHIYA ABHAY SINGH) .....................................................................................xlv
7.1.4 Student 4 (ZAINA MAHER ALI QUBBEJ) ............................................................................xlvi
8.0 References ..........................................................................................................................................xlvii
9.0 Work-Load Matrix .............................................................................................................................xlviii
Section 1 ..............................................................................................................................................xlviii
Section 2 ..............................................................................................................................................xlviii
Page | v
Page | vi
Table of Figures
Figure 1: Entity-relationship Diagram .........................................................................................................23
Figure 2: Data Base Diagram Schema .........................................................................................................24
Figure 3: EERD ...........................................................................................................................................25
Page | vii
Table of Tables
Table 1: Entities ...........................................................................................................................................12
Table 2: Attributes........................................................................................................................................16
Table 3: Relationships..................................................................................................................................17
Table 4: Data Dictionary ..............................................................................................................................30
Table 5: Player Account Table .....................................................................................................................34
Table 6: Hero Table ......................................................................................................................................34
Table 7: Skin Table ......................................................................................................................................35
Table 8: Personal Statistics Table ................................................................................................................35
Table 9: Player Hero Table ..........................................................................................................................36
Table 10: Hero Skin Table ...........................................................................................................................36
Table 11: Game Mode Table ........................................................................................................................37
Table 12: Team Table ...................................................................................................................................38
Table 13: Game Table .................................................................................................................................38
Table 14: Workload Matrix - Section 1........................................................................................................44
Table 15: Workload Matrix - Section 2........................................................................................................45
Page | viii
1.0 Database and Database Management System

Disadvantages of File-based system
Data Redundancy – Data is stored more than once in different files which means duplicate data may
occur in all these files (Thakur, 2015).
Example: The game will record and save information such as game _ID, game date, game time, list of
heroes, and heroes’ levels, and the game/battle’s results, which means that the list of heroes, heroes’
levels may be same for each game played. These games played are also not dependent on each other.
Data Inconsistency – Various copies of the same data may contain different values. If data needs to be
updated or modified then all the files containing that data need to be modified as well (Thakur, 2015).
Example: If a certain change is made in for a game, it needs to be changed for all the upcoming
games that will be played.
Accessing Anomalies – It is not easy to access data in a desired or efficient way, making the
supervision of departments very difficult and inefficient. So if a user wants information in a specific
manner then they require creating a separate program for it (Thakur, 2015).
Example – If the developer needs to access players that have more than 700 diamonds or a list of
heroes, they’ll need to create a separate program to execute a search algorithm.
Advantages of Database and DBMS

No Data Redundancy – Duplication is removed by data normalization, which saves storage and
reduces access time.
Data Consistency – Data normalization also takes care of data inconsistency, so a change made can be
implemented in every department on the database.
Easy Data Recovery – DataBse Management System (DBMS) keeps backup of data, so it is easier to
recover the data in case of an error/ failure.
Data Security and Privacy – The data accessed in DBMS is limited, which means it is private, and it
is easier to apply constraints in databases so only an authorized user can access the data. Each user
has a different set of access therefore data is secured from threats such as _IDentity theft, misuse, and
data leaks (cited in beginnersbook.com, 2015).
Page | ix
2.0 Business Rules
2.1 Defeni?on
The Business rules are brief, precise, and unambiguous descriptions of policies, procedures, or
principles within a specific organization:
• Must be kept up to date
• Sometimes are external to the organization
• Describe characteristics of the data as viewed by the company
Business rules are derived from the case study to effectively _IDentify relationships that entities
within a business have between one another, and what relationship they are in, what attributes are
stored and so forth.
2.2 Keywords
The business rules define the entities, attributes, relationships, and constraints of data in the database.
Each of those keywords is defined as per below:
• Entity - anything about which data are to be collected and stored
• Attribute - a characteristic of an entity
• Relationship - describes an association among entities which can be:
o One-to-many (1:M) relationship
o Many-to-many (M:N or M:M) relationship
o One-to-one (1:1) relationship
• Constraint - a restriction placed on the data
2.3 Business rules with respect to BingBing Legend Online Game

Our team’s approach to _IDentifying the business rules is through a detailed analysis of each of the
keywords of the business rules and briefly explaining and defining each; along with justifying
additional inclusion and approaches.
2.3.1 EnOOes:
1. Player
2. Personal-Statistics
3. Hero
4. Skin
5. Player-Hero
6. Hero-Skin
7. Game-Mode
8. Team
Page | x
9. Game
Addi?onal inclusions
✓ A Player-Hero entity was introduced as a br_IDge-table and the best way to link the player to the
heroes they own. This entity behaves like an array which the company can query to display the list of
heroes owned by a player as per below:
SELECT Hero_ID FROM Player-Hero WHERE Player_ID=“the desired

player”
o The statement can also be nested to get the name of a given hero_ID
✓ Much like the Player-Hero entity, the Hero-Skin entity was introduced to show the skins a hero has of
a particular play.
SELECT Skin_ID FROM Hero-Skin WHERE Ph_ID=“the desired player’s

hero”
o Note that since we want to access the heroes the player own this entity will refer to the
Player-Hero entity.
✓ Our team assumes that a Game-Mode entity is needed to store the different types of arenas and game
modes available to be referenced by the game entity.
✓ The team table makes the queries for starting a game much faster even without an implemented index.
This is achieved because the entity holds the _ID of the heroes of specific players joining and
represents them in one unique _ID.
✓ Lastly, our team assumes that to store information about each game a game entity is essential since all
of its attributes do not depend on other attributes of the other entities.
Entities
Player Any user of this game will get a unique player account that holds
his information in-game.
Personal-Statistics A representation of the player’s details and accomplishments.
Hero An entity that holds all the information about the heroes the
players can own and use in the game as per their role.
Skin Holds details of skin for each hero that the player can equip.
Page | xi
Player-Hero An entity that links a player to a hero they own and represent the
hero’s level. This entity makes it easy and efficient to select all the
heroes that the player owns.
Hero-Skin This entity refers to the player hero entity and _IDentifies all the
skins of a particular hero owned by the specified player.
Game An entity that holds information about the games played their
results and participants.
Game-Mode An entity that stores all the game modes that can be picked and
played by teams.
Team This entity is used to create a team that is composed of five

players and the heroes they pick along with their respective levels.
On its own, this entity makes game handling very simple and
efficient.
Table 1: Entities
2.3.2 AQributes
-Primary keys are underlined and italic.
-Foreign keys are defined just like primary keys, but they end with an *.
• Player:
1. Player_ID
2. Player_Name
3. Username
4. Email
5. Global_lvl
6. Diamonds
7. Battle_Points
8. Online_Status
• Personal-Statistics:
1. Player_ID*
2. MostUsed_Hero*
Page | xii
3. Details
4. PrevGame_Result
• Hero:
1. Hero_ID
2. Hero_Name
3. Hero_Role
4. Hero_Speciality
5. Hero_Price
• Skin:
1. Skin_ID
2. Skin_Name
3. Hero_ID*
4. Skin_Price
• Player-hero:
1. Ph_ID
2. Player_ID*
3. Hero_ID*
4. Lvl
• Hero-Skin:
1. Ph_ID*
2. Skin_ID*
• Game-Mode:
1. Mode_ID
2. Mode_Type
3. Mode_Name
4. Arena
• Team:
1. Team_ID
2. Ph_ID1*
3. Ph_ID2*
4. Ph_ID3*
Page | xiii
5. Ph_ID4*
6. Ph_ID5*
• Game:
1. Game_ID
2. Mode_ID*
3. Game_Duration
4. Battle_DateTime
5. Game_Loser
6. Game_Winner
Addi+onal inclusions
The normalization subsection contains a further explanation.
✓ The Hero’s ID was included in the skin entity, instead of the name, because it gives the company the
ability to change the name in one area, i.e. the hero entity and it will be updated everywhere else.
o Thus preventing Update and deletion anomaly.
✓ The Player has a name attribute that is used when sending them an email or update as the name makes
the message more customizable.
✓ Ph_ID is added to Player-Hero as a mean for the Hero-Skin entity to reference it, making the query
speed for the Hero-skin much faster.
o Preventing Insertion and update anomaly.
✓ Team_ID is created in team-member to be referenced in the game entity.
o Preventing Insertion anomaly.
✓ The game entity has a Battle_DateTime instead of two separate attributes because both the date and
time can be stored in a DateTime data type.
✓ The Game result attribute was replaced by two attributes in the game entity: Game_loser and
Game_Winner. Those two attributes summarize the result in a way that easy to understand and
represent as illustrated in the attributes table.
Attributes
Player
Player_ID A unique primary key to each player, automatically incremented.
Player_Name Player’s real name, which is used when sending the player emails and
updates to make the messages dynamic.
Page | xiv
Username Player’s in-game name.
Email Player’s email address.
Global_lvl The player’s global level, publicly viewable.
Diamonds An integer that holds the number of diamonds the player owns.
Battle_Points An integer that holds the number of battle points the player earned and
currently owns.
Online_Status A bool where true means online and false means offline.
Personal Statistics: publicly viewable

PLayer_ID A foreign key referencing the Player_ID, located in Player, that links the player
to their statistics.
MostUsed_Hero A foreign key to the Hero_ID, located in the Hero entity, of the most used hero
by the player.
Details A description of the player and their profile.
PrevGame_Result A bool where True means the player one last game they played and false means
they lost.
Hero
Hero_ID A unique primary key to each hero, automatically incremented.
Hero_Name The hero’s name such as Dark Rose, Rafaela, Tigreal, Fanny, and Estes,
Cyclops, Lolita, Clint, etc.
Hero_Role A description of the hero’s role such as Fighter, Tank, Assassin, etc.
Hero_Speciality A description of the hero’s specialty such as Charge, Regen, Reap, etc.
Hero_Price An integer representing the Hero’s price in diamonds and battle points.
Skin
Page | xv
Skin_ID A unique primary key to each skin, automatically incremented.
Skin_Name The skin’s name usually one that describes it.
Hero_ID A foreign key to the Hero_ID, located in the Hero entity, that represents the hero
who can be equipped by the skin.
Skin_Price An integer representing the skin’s price in diamonds and battle points.
Player-hero
Ph_ID A unique primary key to each player and the corresponding hero,
automatically incremented.
Hero_ID A foreign key to the Hero_ID, located in the Hero entity, that represents the hero
corresponding to the player.
Player_ID A foreign key, referencing the Player_ID located in Player, which represents the
_ID of the player that owns the hero of Hero_ID.
Lvl The current level of a specific hero owned by the specified player.
Hero-Skin
Ph_ID A foreign key, referencing Ph_ID located in the Player-Hero entity, which
represents a specific hero of the specific player.
Skin_ID A foreign key, referencing skin_ID located in the skin entity and represents the
skin of the given hero that the player owns.
Game-Mode
Mode_ID A unique primary key to each of the three available game modes,
automatically incremented.
Mode_Type The specific type of the mode: Brawl mode, Human vs AI mode, or Classic
Mode.
Mode_Name The game mode’s name usually a simple one.
Arena The environment and cosmetics of each game mode.
Team
Page | xvi
Team_ID A unique primary key to each team created automatically incremented.
Ph_ID1 A foreign key, referencing Ph_ID located in Player-hero, this _ID represents the
chosen hero’s information of the first player.
chosen hero’s information of the second player.
chosen hero’s information of the third player.
chosen hero’s information of the fourth player.
chosen hero’s information of the fifth player.
Game
Game_ID A unique primary key to each that has been played, automatically
incremented.
Mode_ID A foreign key referencing Mode_ID, located at Game-Mode, showing

which game mode was picked for the game.
Game_Duration An integer representing the duration of the game in seconds which can be
converted into an appropriate form when needed.
Battle_DateTime A DATETIME variable that holds the date and time in which the game has
started.
Game_Loser A foreign key referencing the Team_ID of the team that lost the game.
Game_Winner A foreign key referencing the Team_ID of the team that won the game.
Table 2: Attributes
2.3.3 RelaOonships
1. Each player can befit many Heroes, many heroes can be befitted by a player. A hero befits by
many players, many players can befit by the same hero.
a. Many to many relationship (M:M)
Page | xvii
2. Since the player can own many heroes, each player can be part of many player-heroes, many
player-heroes can have the same player.
a. One to many relationship (1:M)
3. Each hero is owned by many players and thus can be included in many player-heroes, many
player-heroes can have the same hero.
4. Each hero can have many skins, many skins can be owned by one hero.
5. Each player can buy many skins for his hero(es), many skins can be bought for the player’s
hero(es).
a. One to many relationship(1:M)
6. Each hero has many skins, many skins are wearable by the same hero.
7. Many skins can be owned by many players who have the prerequisite hero, many players who
have the required hero can have the same skin and many skins can be owned by a single player.
a. Many to many relationship (M:M)
8. Each team consists of five players, five players make up one team.
9. Two teams play one game, each game is played by two teams.
10. A game mode can be selected for many games, many games can be played in the same game
mode.
11. Each player has a personal statistic, each personal statistic is for a single player.
a. One to one relationship (1:1)
Jus?fica?ons
✓ The same hero can be owned by any player, but at the same time a player can own many heroes,
therefore it’s a many to many relationship.
✓ The same is true for the relationship between the player’s heroes and their skins.
✓ Since the Player-Hero entity was introduced, the one to many relationships is now represented by the
relationship between the Player-Hero entity and the two entities that reference it: Player and Hero.
o Relational database.
Page | xviii
✓ The skin has two sets of relationships: skins available for each hero, and skins a player owns for
each of his heroes. They are represented by the relationship between the Hero and Skin entities, and
the Hero-skin and skin entities respectively.
o Relational database.
✓ A relationship exists between the team entity and player-hero instead of just player or hero because
the entity holds the player and the hero they picked along with their level which the game requires.
Relationships
Player 1:M Player-Hero Since the player can own many heroes, each player can be part of
many player-heroes, many player-heroes can have the same player.
Player-hero M:1 Hero Each hero is owned by many players and thus can be included in
many player-heroes, many player-heroes can have the same hero.
Player M:M Hero Each player can befit many Heroes, many heroes can be befitted by a
player. A hero befits by many players, many players can befit by the
same hero.
Hero 1:M Skin Each hero can have many skins, many skins can be owned by one
hero.
Player-Hero 1:M Hero-skins Each player can buy many skins for his hero(es), many skins can be
bought for the player’s hero(es).
Hero 1:M Skin Each hero has many skins, many skins are wearable by the same hero.
Hero-skin M:M Skin Many skins can be owned by many players who have the prerequisite
hero, many players who have the required hero can have the same
skin and many skins can be owned by a single player.
Team 1:M Player-Hero Each team consists of five players, five players make up one team.
Game 1:M Team Two teams play one game, each game is played by two teams.
Game-Mode 1:M Game A game mode can be selected for many games, many games can be
played in the same game mode.
Player 1:1 Personal-Statistic Each player has a personal statistic, each personal statistic is for
a single player.
Table 3: Relationships
Page | xix
Page | xx
2.4 Constraints
2.4.1 Logical Constraints
1. The player must own at least one hero before they can purchase the skins for that specific hero.
2. Both heroes and their skins can only be purchased using either diamonds or battle points.
3. A game mode must be picked before starting a game.
4. A team can contain five players: no more and no less.
5. A team can consist of active players only.
6. The choice of heroes must be unique in each team.
2.4.2 Null Constraints

All attributes cannot be null as they hold data that is essential for the entity and is ready to be provided
when called; with the following exceptions:
1. The Details attribute in the Personal_statistic table can be Null since at the start of the game the
player will not retain any details.
2. The mostUsed_Hero in the Personal_statistics table can be Null since at the start of the game the
player will not have used any heroes.
2.4.3 Unique Constraints

1. The player’s name must be unique.
2. The Username must be unique.
3. The Email must be unique.
4. The Hero’s name must be unique.
5. The skin name must be unique.
6. Both the mode name and Arena must be unique.
7. Each member in a team must be unique.
Jus?fica?on
• Our teams assume that the hero’s role and specialty can repeat but not simultaneously.
• Furthermore, the team assumes that while every other attribute of the game mode must be unique
the mode type can repeat.
2.4.4 Primary Keys Constraints

1. All primary keys are integers
2. Since all primary keys are integers, they can be auto increments starting at 1 and iterate by 1,
making the insertion process easier.
Page | xxi
2.4.5 Default Constraints

1. The default or starting value of the global level attribute of the player entity is 1.
2. The default or starting value of the Diamonds attribute of the player entity is 250.
3. The default or starting value of the Battle_points attribute of the player entity is 3000.
4. The default or starting value of the lvl attribute of the player-hero entity is 1.
Page | xxii
3.0 NormalizaOon
3.1 Defini?on
Database normalization is the process of organizing a database into tables and columns
effectively. Tables generated through normalization are specific to an entity and only including
supporting entities and attributes (Essential SQL, 2019).
3.2 Benefits
Normalization is used to minimize and eliminate redundancy as well as remove undesirable
characteristics: Insertion, Update, and Deletion Anomalies (www.javatpoint.com, 2011).
3.3 Forms
Three common forms transform an unnormalized form (UNF) into a normalized database
(Essential SQL, 2019):
1. First normalized form (1NF): Makes the tables in a database scalable so they can be
easily extended.
2. Second normalized form (2NF): removes all partial dependencies from the tables in a
database.
a. “Partial Dependency occurs when a non-prime attribute is functionally
dependent on part of a cand_IDate key” (www.tutorialspoint.com, n.d.).
3. Third normalized form (3NF): removes transitive dependencies from the tables in a
database.
a. “When an indirect relationship causes functional dependency it is called
Transitive Dependency” (www.tutorialspoint.com, n.d.) :
i. If P -> Q and Q -> R is true, then P-> R is a transitive dependency.
3.3.1 Unnormalized form (UNF)

The starting form: an unorganized representation of every attribute of all the entities.
Player(Player_ID, Name, Username, Email, Level_Global, Diamonds,

BattlePoints, Online_Status, MostUsed_Hero, Details, PrevGame_Result,
Heros_owned, heroes_levels, Skins_owned, {Hero_Name, Hero_Role,
Hero_Speciality, Hero_Price, {Name_Skin, Skin_Price}}, Mode_Type,
Mode_Name, Arena, Game_Duration, Battle_DateTime, Game_Loser_players,
Game_Winner_players)
• Primary keys are underlined and italic.

• Foreign keys are defined just like primary keys, but they end with an *.
• Red highlights the issue that the next normalization form will solve.
Page | xxiii
3.3.2 First normalized form (1NF)

Separate Repeating groups:

Heros_owned, heroes_levels, Skins_owned, Mode_Type, Mode_Name, Arena,
Game_Duration, Battle_DateTime, Game_Loser, Game_Winner)
Heroes(Hero_ID, Hero_Name, Hero_Role, Hero_Speciality, Hero_Price)
Skin(Skin_ID, Hero_ID*, Skin_Name, Skin_Price)
Team(Team_ID, Player_ID1, hero1, Player_ID2, hero2, Player_ID3, hero3,

Player_ID4, hero4, Player_ID5, hero5)
Jus?fica?on
✓ While players can own a different number of heroes and a different amount of skins for each the
details for each such as their names, role, specialty and price remain constant and thus should be
separated into their tables and referenced with a primary key.
✓ The list of winning players or losing players is nothing but a repetition of players that can be
separated into its table.
3.3.3 Second normalized form (2NF)

Eliminate partial dependences:

Heros_owned, heroes_levels, Skins_owned)
Game-Mode(Mode_ID, Mode_Type, Mode_Name, Arena)
Game(Game_ID, Mode_ID*, Game_Duration, Battle_DateTime, Game_Loser,

Game_Winner)
Team(Team_ID, Player_ID1, hero1, Player_ID2, hero2, Player_ID3, hero3,

Player_ID4, hero4, Player_ID5, hero5)
Jus?fica?on
✓ Since the informa+on stored in the and the data of each game mode is not directly related to the
primary key of the player table, they are both separated into their tables with their primary keys.
Page | xxiv
3.3.4 Third normalized form (3NF)

Eliminate Transitive dependencies

BattlePoints, Online_Status)
Personal-statistics(Player_ID*, MostUsed_Hero, Details,

PrevGame_Result)
Player-Hero(Ph_ID, Player_ID*, Hero_ID*, lvl)
Hero-Skin(Ph_ID*, Skin_ID*)
Game-Mode(Mode_ID, Mode_Type, Mode_Name, Arena)
Game(Game_ID, Mode_ID*, Game_Duration, Battle_DateTime, Game_Loser,

Game_Winner)
Team(Team_ID, Ph_ID1*, Ph_ID2*, Ph_ID3*, Ph_ID4*, Ph_ID5*)
Jus?fica?on
✓ Personal sta+s+cs were separated into its table since it holds plenty of details that are best-accessed
indiv_IDual and thus we have separate aCributes.
✓ Heroes level and the skins owned both depend on the heroes owned and not the player _ID,
therefore they are all separated into two tables.
✓ The Player-Hero table corresponds to each hero with his player and represents that hero’s level.
✓ Hero-Skin corresponds to every player’s hero to the skins of that hero that the player owns.
✓ Now that we have an op+mal way to represent the player’s hero and their level, we use Ph_ID in the
Team table.
Page | xxv
4.0 EnOty RelaOonship Diagram
4.1 Defini?on
An en+ty-rela+onship diagram (ERD) is a data modeling technique that graphically illustrates an
informa+on system’s en++es and the rela+onships between those en++es. In short, an ERD is a
conceptual and representa+onal model of data used to represent the en+ty framework
infrastructure. (Techopedia.com, 2019)
The elements of an ERD are:
• En++es
• Rela+onships
• ACributes
*Those elements are defined and explained in the business rules.
4.1.1 steps involved in creaOng an ERD include:
1. _IDen+fying the en++es.

2. Determining all interac+ons between the en++es.
3. Analyzing the nature of interac+ons and determining the cardinality of the rela+onships
4. Crea+ng the ERD.
4.2 Designing Database
Our team used Chen’s nota+on over crow’s foot nota+on to design our database for our system
because it is easy to navigate and clear to use.
4.2.1 Tool used

Instead of using MicrosW Visio, our design team used darw.io tool so[ware, more efficient and
effec+ve soWware for building diagrams with the ability to update the diagram. Furthermore, it
prov_IDes a lot of graphics and func+onality that makes development easy and accurate.
Page | xxvi
4.4 ERD Design
Figure 1: Entity-relationship Diagram
Page | xxvii
5.0 Database Schema

5.1 Data Base Diagram
Figure 2: Data Base Diagram Schema
Page | xxviii
5.1 EERD
Figure 3: EERD
5.2 Data Dic?onary
Attributes
Player table
Variable Description Key Constraints Data
Type
Player_ID A unique primary key to each

player, automatically incremented. PRIMARY KEY NOT NULL INT
IDENTITY
Player_Na Player’s real name, which is used

NOT NULL
me when sending the player emails and UNIQUE
VARCHAR
(255)
updates to make the messages -
dynamic.
Page | xxix
Username Player’s in-game name.

NOT NULL
- UNIQUE
VARCHAR
(255)
Email Player’s email address.

- NOT NULL VARCHAR
UNIQUE (255)
Global_lvl The player’s global level, publicly

viewable. - NOT NULL INT
DEFAULT
Diamonds An integer that holds the number of

diamonds the player owns. -
NOT NULL INT
DEFAULT
Battle_Poi An integer that holds the number of

nts battle points the player earned and - INT
currently owns. NOT NULL
DEFAULT
Online_Sta A bool where true means online and

tus false means offline. - - BIT
Personal Statistics: publicly viewable table

type
PLayer_ID A foreign key referencing the
Player_ID, located in Player, that links
the player to their statistics. FK NOT INT
NULL
MostUsed_ A foreign key to the Hero_ID, located

Hero in the Hero entity, of the most used INT
hero by the player. FK -
Details A description of the player and their

profile. - - VARCHAR
(255
PrevGame_ A bool where True means the player

Result one last game they played and false
means they lost. - BIT
-
Hero table
Page | xxx

type
Hero_ID A unique primary key to each hero,
automatically incremented. PRIMARY KEY NOT NULL INT
IDENTITY
Hero_Name The hero’s name such as Dark Rose,

Rafaela, Tigreal, Fanny, and Estes, NOT NULL VARCHAR
Cyclops, Lolita, Clint, etc. (255)
UNIQUE
Hero_Role A description of the hero’s role such as

Fighter, Tank, Assassin, etc. - NOT VARCHAR
NULL (255)
Hero_Speci A description of the hero’s specialty

ality such as Charge, Regen, Reap, etc. NOT VARCHAR
- NUL (255)
Hero_Price An integer representing the Hero’s

price in diamonds and battle points.
- NOT INT
NULL
Skin table
type
Skin_ID A unique primary key to each skin,
PRIMARY KEY NOT NULL INT
automatically incremented. IDENTITY
Skin_Name The skin’s name usually one that

describes it. - NOT NULL VARCHAR
UNIQUE (255)
Hero_ID A foreign key to the Hero_ID, located

in the Hero entity, that represents the
hero who can be equipped by the skin.
FK NOT INT
NULL
Skin_Price An integer representing the skin’s price

in diamonds and battle points. - NOT INT
NULL
Player-hero table
type
Page | xxxi
Ph_ID A unique primary key to each

player and the corresponding hero,
automatically incremented. PRIMARY KEY NOT NULL INT
IDENTITY
Hero_ID A foreign key to the Hero_ID, located

in the Hero entity, that represents the
hero corresponding to the player. NOT NULL INT
FK
Player_ID A foreign key, referencing the
Player_ID located in Player, which
represents the _ID of the player that NOT NULL INT
owns the hero of Hero_ID. FK
Lvl The current level of a specific hero

owned by the specified player. - NOT NULL INT
Hero-Skin table
type
Ph_ID A foreign key, referencing Ph_ID
located in the Player-Hero entity,
which represents a specific hero of the NOT NULL INT
specific player. FK
Skin_ID A foreign key, referencing skin_ID

located in the skin entity and
represents the skin of the given hero FK NOT NULL INT
that the player owns.
Game-Mode table
type
Mode_ID A unique primary key to each of the
three available game modes,
automatically incremented. PRIMARY KEY NOT INT
IDENTITY NULL
Mode_Type The specific type of the mode: Brawl

mode, Human vs AI mode, or Classic
Mode. - NOT NULL VARCHAR
(255)
Mode_Nam The game mode’s name usually a

e simple one. - NOT NULL VARCHAR
UNIQUE (255)
Page | xxxii
Arena The environment and cosmetics of

each game mode. NOT NULL VARCHAR
- UNIQUE (255)
Team table
type
Team_ID A unique primary key to each team
created automatically incremented. PRIMARY KEY NOT NULL INT
IDENTITY
Ph_ID1 A foreign key, referencing Ph_ID

located in Player-hero, this _ID
represents the chosen hero’s NOT NULL INT
information of the first player. FK UNIQUE

represents the chosen hero’s
information of the second player. FK NOT NULL
UNIQUE INT

represents the chosen hero’s FK
information of the third player. NOT NULL INT
UNIQUE

information of the fourth player. FK NOT NULL INT
UNIQUE

information of the fifth player. FK NOT NULL INT
UNIQUE
Game table
type
Game_ID A unique primary key to each that
has been played, automatically PRIMARY KEY NOT
incremented. IDENTITY NULL
Page | xxxiii
Mode_ID A foreign key referencing

Mode_ID, located at Game-Mode,
showing which game mode was FK
picked for the game. NOT INT
NULL
Game_Dur An integer representing the duration of

ation the game in seconds which can be
converted into an appropriate form
when needed. NOT
- NULL INT
Battle_Date A DATETIME variable that holds the

Time date and time in which the game has
started. - NOT DATETIM
NULL E
Game_Lose A foreign key referencing the Team_ID

r of the team that lost the game.
FK NOT INT
NULL
Game_Win A foreign key referencing the Team_ID

ner of the team that won the game. FK INT
NOT
NULL
Table 4: Data Dictionary
Page | xxxiv
6.0 SQL-Data DefiniOon Language (DDL)
6.1 Crea?ng the DataBase

The following queries creates and selects a database for BingBing Legend Mobile Game Database system:
/* Creating and using the DataBase */
CREATE DATABASE BingBing;
USE BingBing;
6.2 Crea?ng tables

Inside the sleceted database create the following tables as per the business rules specification:
6.2.1 Player account table
-- Player account table:
-- Holds the user's information and progress
CREATE TABLE Player(
Player_ID INT NOT NULL PRIMARY KEY IDENTITY(1, 1),
Player_Name VARCHAR(255) NOT NULL UNIQUE,
Username VARCHAR(255) NOT NULL UNIQUE,
Email VARCHAR(255) NOT NULL UNIQUE,
Global_lvl INT NOT NULL DEFAULT 1,
Diamonds INT NOT NULL DEFAULT 250,
Battle_Points INT NOT NULL DEFAULT 3000,
-- 0 for Flase and any other value for True
Online_Status BIT
);
6.2.2 Hero table
-- Hero table:
-- Holds all of the heroes information
CREATE TABLE Hero(
Hero_ID INT NOT NULL PRIMARY KEY IDENTITY(1, 1),
Hero_Name VARCHAR(255) NOT NULL UNIQUE,
Hero_Role VARCHAR(255) NOT NULL,
Hero_Speciality VARCHAR(255) NOT NULL,
Hero_Price INT NOT NULL
);
6.2.3 Skin table
-- Skin table:
Page | xxxv
-- Holds all of the heroes information
CREATE TABLE Skin(
Skin_ID INT NOT NULL PRIMARY KEY IDENTITY(1, 1),
Skin_Name VARCHAR(255) NOT NULL UNIQUE,
Skin_Price INT NOT NULL,
Hero_ID INT NOT NULL REFERENCES Hero(Hero_ID)
);
6.2.4 Personal StaOsOcs table
-- Personal Statistics table:
-- Holds additional information about the player
CREATE TABLE Personal_Statistic(
Player_ID INT NOT NULL REFERENCES Player(Player_ID),
MostUsed_Hero INT REFERENCES Hero(Hero_ID),
Details VARCHAR(255),
-- 0 for Flase and any other value for True
PrevGame_Result BIT
);
6.2.5 Player Hero table
-- Player Hero table:
-
Holds the level of the referenced hero owned by the specified playe
r, and is referenced in the Hero Skin table
CREATE TABLE Player_Hero(
Ph_ID INT NOT NULL PRIMARY KEY IDENTITY(1, 1),
Player_ID INT NOT NULL REFERENCES Player(Player_ID),
Hero_ID INT NOT NULL REFERENCES Hero(Hero_ID),
lvl INT NOT NULL DEFAULT 1
);
6.2.6 Hero Skin table

-- Hero Skin table:
-
Holds all the skins of the referenced hero owned by the specified p
layer
CREATE TABLE Hero_Skin(
Ph_ID INT NOT NULL REFERENCES Player_Hero(Ph_ID),
Skin_ID INT NOT NULL REFERENCES Skin(Skin_ID)
);
Page | xxxvi
6.2.7 Game Mode table
-- Game Mode table:
-- Holds information about every game mode available
CREATE TABLE Game_Mode(
Mode_ID INT NOT NULL PRIMARY KEY IDENTITY(1, 1),
-- Brawl mode, Human vs AI mode, or Classic Mode
Mode_Type VARCHAR(255) NOT NULL,
Mode_Name VARCHAR(255) NOT NULL UNIQUE,
Arena VARCHAR(255) NOT NULL UNIQUE,
);
6.2.8 Team table
-- Team table
-
Holds the names of the team members joining the game, their heroes
and the heros' levels
CREATE TABLE Team(
Team_ID INT NOT NULL PRIMARY KEY IDENTITY(1, 1),
Ph_ID1 INT NOT NULL REFERENCES Player_Hero(Ph_ID) UNIQUE,
);
6.2.9 Game Table
-- Game Table
-- Holds the information of all the games played
CREATE TABLE Game(
Game_ID INT NOT NULL PRIMARY KEY IDENTITY(1, 1),
Mode_ID INT NOT NULL REFERENCES Game_Mode(Mode_ID),
Game_Duration INT NOT NULL,
Battle_DateTime DATETIME NOT NULL,
Game_Loser INT NOT NULL REFERENCES Team(Team_ID),
Game_Winner INT NOT NULL REFERENCES Team(Team_ID)
);
Page | xxxvii
6.3 Inser?ng values
Inside the tables the following rows have been inserted based on their datatypes:
6.3.1 Player Account Table
Table 5: Player Account Table
6.3.2 Hero Table
Table 6: Hero Table
Page | xxxviii
6.3.3 Skin Table
Table 7: Skin Table
6.3.4 Personal StaOsOcs Table
Table 8: Personal Statistics Table
Page | xxxix
6.3.5 Player Hero Table
Table 9: Player Hero Table
6.3.6 Hero Skin Table
Table 10: Hero Skin Table
Page | xl
6.3.7 Game Mode Table
Table 11: Game Mode Table
6.3.8 Team Table
Page | xli
Table 12: Team Table
6.3.9 Game Table
Table 13: Game Table
Page | xlii
7.0 SQL-Data ManipulaOon Language (DML)
7.1 Student Query
7.1.1 Student 1 (Yahya Sherif Solayman Mohamed Saleh)
Query 1
/* Query 1 */
SELECT Player_Name, Email FROM Player
WHERE Player_Name LIKE '%er%' OR Player_Name LIKE '%on%'
ORDER BY Player_Name;
Query 2
/* Query 2 */
SELECT * FROM Player WHERE
Player_ID =
(SELECT Player_ID FROM PlayerHero WHERE lvl > 3);
Query 3
/* Query 3 */
SELECT Hero.Hero_ID, Hero.Hero_Name, Player_Hero.lvl FROM Hero
INNER JOIN Player_Hero ON Player_Hero.Hero_ID = Hero.Hero_ID
WHERE Player_Hero.Player_ID =
(SELECT Player_ID FROM Player WHERE Player_Name='Wade Wilson');
Page | xliii
7.1.2 Student 2 (BANA MAHER ALI QUBBEJ)

Query 1
Query 2
Query 3
Page | xliv
7.1.3 Student 3 (DAHIYA ABHAY SINGH)

Query 1
Query 2
Query 3
Page | xlv
7.1.4 Student 4 (ZAINA MAHER ALI QUBBEJ)

Query 1
Query 2
Query 3
Page | xlvi
8.0 References
▪ beginnersbook.com. (2015). Advantages of DBMS over file system. [online] Available at: https://
beginnersbook.com/2015/04/dbms-vs-file-system/
▪ Essential SQL. (2019). Database Normalization (Explained in Simple English) - Essential SQL.
[online] Available at: https://www.essentialsql.com/get-ready-to-learn-sql-database-normalization-
explained-in-simple-english/. [Accessed: 14, May 2020].
▪ Techopedia.com. (2019). What is an Entity-Relationship Diagram (ERD)? - Definition from
Techopedia. [online] Available at: https://www.techopedia.com/definition/1200/entity-relationship-
diagram-erd.[ Accessed: 16 May 2020 ].
▪ Thakur, S. (n.d.). Disadvantages of File Processing System. [online] Available at: https://
whatisdbms.com/disadvantages-of-file-processing-system/
▪ www.javatpoint.com. (2011). DBMS Normalization - javatpoint. [online] Available at: https://
www.javatpoint.com/dbms-normalization. [Accessed: 14, May 2020].
▪ www.tutorialspoint.com. (n.d.). Partial Dependency in DBMS. [online] Available at: https://
www.tutorialspoint.com/Partial-Dependency-in-DBMS. [Accessed: 15, May 2020].
▪ www.tutorialspoint.com. (n.d.). Transitive dependency in DBMS. [online] Available at: https://
www.tutorialspoint.com/Transitive-dependency-in-DBMS [Accessed 15 May 2020].
Page | xlvii
9.0 Work-Load Matrix
Sec?on 1
This section includes all the projects from 1 through 4 inclusive:
BANA MAHER ALI QUBBEJ

Project Otle(s) Business rules Entity Relationship Diagram
Project Effort 7 Days 21 Days
Project status Complete Complete
DAHIYA ABHAY SINGH

Project title(s) Database and Database Management System
Project Effort 1 Day
Project status Completed
Yahya Sherif Solayman Mohamed Saleh

Project title(s) Compilation Business rules Normalization Workload Matrix
section 1
Project Effort 3 Days 7 Days 14 Days 1 Day
Project status 50% Complete Complete Complete
ZAINA MAHER ALI QUBBEJ

Project title(s) Business rules Entity Relationship Diagram
Project Effort 7 Days 21 Days
Table 14: Workload Matrix - Section 1
Sec?on 2
This section includes all the projects from 5 through 7 inclusive:
BANA MAHER ALI QUBBEJ

Project Otle(s) Database Schema SQL-Data Manipulation Language
(DML)
Project Effort 1 Day 2 Days
DAHIYA ABHAY SINGH
Page | xlviii
Project title(s) SQL-Data Defini+on Language (DDL) SQL-Data Manipulation Language

(DML)
Project Effort 7 Days 3 Days
Yahya Sherif Solayman Mohamed Saleh

Project title(s) SQL-Data Defini+on SQL-Data Manipulation Workload Matrix
Language (DDL) Language (DML)
Project Effort 1 day 1 day 1 day
Project status Complete Complete Complete
ZAINA MAHER ALI QUBBEJ

Project title(s) Database Schema SQL-Data Manipulation Language
(DML)
Project Effort 1 Day 2 Day
Table 15: Workload Matrix - Section 2
Page | xlix

IDB Assignment BingBing Legend Online Game Final

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IDB Assignment BingBing Legend Online Game Final

Uploaded by

Copyright:

Available Formats

BingBing Legend Mobile Game Database system

Name Signature TP number

DAHIYA ABHAY SINGH ABHAY TP047179

Yahya Sherif Solayman Mohamed Saleh Yahya TP057094

ZAINA MAHER ALI QUBBEJ ZAINA TP057738

Signature taken on 22nd of June, 2020

4.2.1 Tool used ..................................................................................................................................xxvi

1.0 Database and Database Management System

Advantages of Database and DBMS

2.0 Business Rules

2.3 Business rules with respect to BingBing Legend Online Game

SELECT Hero_ID FROM Player-Hero WHERE Player_ID=“the desired

SELECT Skin_ID FROM Hero-Skin WHERE Ph_ID=“the desired player’s

Personal-Statistics A representation of the player’s details and accomplishments.

Team This entity is used to create a team that is composed of five

Player_ID A unique primary key to each player, automatically incremented.

Username Player’s in-game name.

Email Player’s email address.

Global_lvl The player’s global level, publicly viewable.

Personal Statistics: publicly viewable

Details A description of the player and their profile.

Skin_ID A unique primary key to each skin, automatically incremented.

Skin_Name The skin’s name usually one that describes it.

Mode_Name The game mode’s name usually a simple one.

Arena The environment and cosmetics of each game mode.

Team_ID A unique primary key to each team created automatically incremented.

Mode_ID A foreign key referencing Mode_ID, located at Game-Mode, showing

2.4.2 Null Constraints

2.4.3 Unique Constraints

2.4.4 Primary Keys Constraints

2.4.5 Default Constraints

3.3.1 Unnormalized form (UNF)

Player(Player_ID, Name, Username, Email, Level_Global, Diamonds,

• Primary keys are underlined and italic.

3.3.2 First normalized form (1NF)

Player(Player_ID, Name, Username, Email, Level_Global, Diamonds,

Heroes(Hero_ID, Hero_Name, Hero_Role, Hero_Speciality, Hero_Price)

Skin(Skin_ID, Hero_ID*, Skin_Name, Skin_Price)

Team(Team_ID, Player_ID1, hero1, Player_ID2, hero2, Player_ID3, hero3,

3.3.3 Second normalized form (2NF)

Player(Player_ID, Name, Username, Email, Level_Global, Diamonds,

Heroes(Hero_ID, Hero_Name, Hero_Role, Hero_Speciality, Hero_Price)

Skin(Skin_ID, Hero_ID*, Skin_Name, Skin_Price)

Game-Mode(Mode_ID, Mode_Type, Mode_Name, Arena)

Game(Game_ID, Mode_ID*, Game_Duration, Battle_DateTime, Game_Loser,

Team(Team_ID, Player_ID1, hero1, Player_ID2, hero2, Player_ID3, hero3,

3.3.4 Third normalized form (3NF)

Player(Player_ID, Name, Username, Email, Level_Global, Diamonds,

Personal-statistics(Player_ID*, MostUsed_Hero, Details,

Heroes(Hero_ID, Hero_Name, Hero_Role, Hero_Speciality, Hero_Price)

Player-Hero(Ph_ID, Player_ID*, Hero_ID*, lvl)

Skin(Skin_ID, Hero_ID*, Skin_Name, Skin_Price)

Game-Mode(Mode_ID, Mode_Type, Mode_Name, Arena)

Game(Game_ID, Mode_ID*, Game_Duration, Battle_DateTime, Game_Loser,

Team(Team_ID, Ph_ID1*, Ph_ID2*, Ph_ID3*, Ph_ID4*, Ph_ID5*)

4.0 EnOty RelaOonship Diagram

4.1.1 steps involved in creaOng an ERD include:

1. _IDen+fying the en++es.

4.2.1 Tool used

4.4 ERD Design

Figure 1: Entity-relationship Diagram

5.0 Database Schema

Figure 2: Data Base Diagram Schema

5.2 Data Dic?onary

Player-Hero(Ph_ID, Player_ID, Hero_ID, lvl)

Team(Team_ID, Ph_ID1, Ph_ID2, Ph_ID3, Ph_ID4, Ph_ID5*)