Symbiosis Institute of Technology

A DBMS Project Report on

MALWARE DATABASE

Submitted by

Sahil Patil (18070122056)

Parthraj Salvi (18070122058)

Rohanraje Bhosale (19070122502)

Sanket Gadakh (19070122503)

Nikhil Sawant (19070122504)

Under the Guidance of

Prof. Shruti Patil

Department of Computer Science

SYMBIOSIS INSTITUTE OF TECHNOLOGY, PUNE

0
 Index
1. Introduction.………………………………………………………………………………………………….1

2. Problem Statement…………………………………………………………………………………………...2

3. Functional Requirements…………………………………………………………………………………….3

4. Entities and their relationships……………………………………………………………………..4

5. EER diagram……………………………………………………………………………………….5

6. Relational schema………………………………………………………………………………….6

7. Keys………………………………………………………………………………………………..6

8. Codd’s Rules……………………………………………………………………………………………..7

1
 INTRODUCTION

The objective of the particular project we are working on is a database for all the malwares. Malwares being a
crucial entity for our industry of computer science and IT sector, having a uniform database for all of the kinds
of any malware is an important need of today’s era and that’s where we are focusing on. Malware defined as
malicious file that intends or sometimes not intentionally create a harmful effect on a computer system.

Malwares vary from different types such as:

• Virus
• Worms
• Spyware
• Trojans
• Ransomware

So being a vast sector it’s really necessary for all the anti-virus providers to be updated and ready with
solutions as soon as newer one arrives and for researchers as well.

1
 PROBLEM STATEMENT

With “everything becoming computer oriented” security is a very much important and antivirus does the job
well but even that needs to be updated and efficient every time, so with our project we are here to provide an
efficient database for malwares.
With our malware database website any user (anti-virus providers and researchers) will look for a particular
antivirus and will get all the related information regarding its creation through an URL so it’s like an internet
of malware.
So, with all the threats and risk of having security breach in our ecosystem which is already being a part of our
life, we must stay on the line for defense against the virtual threats. With researchers any upcoming
possibilities could be tackled and losses like ransomware could have easily being saved.
All of the lives are dependent on virtual means from money payments to now work from home making
everyone online, it’s really needs to be safeguarded from any known or unknown threats.
So, malware database will be the uniform place for all the safety needs in software/virtual ecosystem.

2
 FUNCTIONAL REQUIREMENTS

• Every User needs to sign up with username, password, email and contact details.
• Every user will be assigned a unique U_ID.
• User may have a membership.
• User will upload or download the information about malware from the website.
• User can also comment on any malware. This will store the C_ID, C_Time & C_Date.
• User can connect to Admin through Technical support.
• Admin will manage all the Malwares through website.
• Different Malware will have different M_ID, M_Name, M_Size, M_Report, M_Status, M_URL, &
M_Category.
• Malware has many categories.
• Malware can be a worm, adware, Spyware, Trojan Horse or Ransomware

3
 ENTITIES & THEIR RELATIONSHIPS

Entities:
• User
• Admin
• Malware
• Comments
• Membership
• Login
• Payment

Entities & their relationships:

ENTITY RELATIONSHIP CARDINALITY ENTITY

User can upload or download

User Many to Many Malware
Malware
User has one or many
User Many to One Membership
memberships
User can connect to admin for
User Many to One Admin
technical support and help
Admin can manage the
Admin One to Many Malware
malwares
User can tag or comment on any
Comments Many to Many Malware
malware

4
ER DIAGRAM

5
 RELATIONAL SCHEMA

1. User_Acc:

U_ID U_FirstName U_LastName U_DOB U_Email U_Contact U_Username U_Password

Primary Key → U_ID

Candidate Key → U_ID, (U_FirstName,U_LastName)
Unique Key → U_Email, U_Contact

2. Admin:

A_ID A_FirstName A_LastName A_Contact A_Email A_DOB

Primary Key → A_ID

Candidate Key → A_ID, (A_FirstName, A_LastName)
Unique Key → A_Email, A_Contact

3. Comments:

C_ID C_Date C_Time M_ID M_Name

Primary Key → C_ID,

Foreign Key → M_ID, M_Name
Candidate Key → C_ID

4. Membership:

Mem_ID Mem_Plan U_ID

Primary Key → Mem_ID

Foreign Key → U_ID
Candidate Key → Mem_ID

5. Malware:

M_ID M_Name M_Size M_Report M_Status M_URL M_Category

Primary Key → M_ID

Candidate Key → M_ID, M_URL
Unique Key → M_URL

6. Login
L_ID U_username U_password

Primary Key → L_ID

Foreign Key → U_username
Candidate Key → L_ID, U_username
Unique Key → U_username

7. Payment
P_ID P_Date P_Time U_ID U_LastName

Primary Key → P_ID

Foreign Key → U_ID, U_LastName
Candidate Key → P_ID
6
 CODD’S RULE

Rule 1: Information Rule

The data stored in a database, may it be user data or metadata, must be a value of some table cell.
Everything in a database must be stored in a table format.
This rule is followed in our database.

Rule 2: Guaranteed Access Rule

Every single data element (value) is guaranteed to be accessible logically with a combination of
table-name, primary-key (row value), and attribute-name (column value). No other means, such as
pointers, can be used to access data.
This rule is followed in our database.

Rule 3: Systematic Treatment of NULL Values

The NULL values in a database must be given a systematic and uniform treatment. This is a very
important rule because a NULL can be interpreted as one the following − data is missing, data is not
known, or data is not applicable.
This rule is not followed in our database.

Rule 4: Active Online Catalog

The structure description of the entire database must be stored in an online catalog, known as data
dictionary, which can be accessed by authorized users. Users can use the same query language to access
the catalog which they use to access the database itself.
This rule is followed in our database.

Rule 5: Comprehensive Data Sublanguage Rule

A database can only be accessed using a language having linear syntax that supports data definition, data
manipulation, and transaction management operations. This language can be used directly or by means
of some application. If the database allows access to data without any help of this language, then it is
considered as a violation.
This rule is followed in our database.

Rule 6: View Updating Rule

All the views of a database, which can theoretically be updated, must also be updatable by the system.
This rule is followed in our database.

Rule 7: High-Level Insert, Update, and Delete Rule

A database must support high-level insertion, Updation, and deletion. This must not be limited to a single
row, that is, it must also support union, intersection and minus operations to yield sets of data records
This rule is followed in our database.

7
Rule 8: Physical Data Independence
The data stored in a database must be independent of the applications that access the database. Any
change in the physical structure of a database must not have any impact on how the data is being
accessed by external applications.
This rule is followed in our database.

Rule 9: Logical Data Independence

The logical data in a database must be independent of its user’s view (application). Any change in
logical data must not affect the applications using it. For example, if two tables are merged or one is
split into two different tables, there should be no impact or change on the user application.
This rule is followed in our database.

Rule 10: Integrity Independence

A database must be independent of the application that uses it. All its integrity constraints can be
independently modified without the need of any change in the application. This rule makes a database
independent of the front-end application and its interface.
This rule is followed in our database.

Rule 11: Distribution Independence

The end-user must not be able to see that the data is distributed over various locations. Users should
always get the impression that the data is located at one site only. This rule has been regarded as the
foundation of distributed database systems.
This rule is followed in our database.

Rule 12: Non-Subversion Rule

If a system has an interface that provides access to low-level records, then the interface must not be able
to subvert the system and bypass security and integrity constraints.
This rule is not followed in our database.