Qn1 (a)

CREATE DATABASE ku_db;

Qn1 (b & c)

Club Details Table Faculty Details Students Results Table

Club_Name varchar(30)
Building varchar(25)
Phone No varchar(20)
Sports_Name varchar(25)
Campus_Name varchar(30)
Address varchar(30)
Distance varchar(30)
CONSTRAINT club_pk_1 UNIQUE
(Club_Name)
CONSTRAINT club_pk_2 UNIQUE
(Building)
CONSTRAINT club_pk_3 UNIQUE
(Sports_Name)
Table
Student_name varchar(25)
Name varchar(50)
Student_ID varchar(25)
Dean varchar(50)
Date_of_birth date
Building varchar()
Gender varchar(25)
Campus_name
Programme_name
varchar(25)
varchar(25)
School varchar(25)
Programme_code
Programme_name varchar(25)
varchar(25)
Faculty_name varchar(25)
Programme_code
Course_name varchar(25)
varchar
School varchar(25)
Course varchar(25)
Year varchar(25)
CONSTRAINT
faculty_pk_1 Term varchar(25)

UNIQUE (Name) CW_Mark INT

CONSTRAINT FinalExam_Mark INT

faculty_pk_2
Grade varchar(10)
UNIQUE (Dean)
Lecturer_name varchar(25)
CONSTRAINT
faculty_pk_3 CONSTRAINT
UNIQUE students_pk_1 UNIQUE
(Campus_name)
 (Student_ID)

CONSTRAINT
students_pk_2 UNIQUE
(Faculty_name)

CONSTRAINT
students_pk_3 UNIQUE
(School)

Lecturer Details Table Campus Details School Details Table

Table
Lecturer_ID INT Name varchar(25)
Name varchar(25)
Name varchar(25) Building varchar(25)
Address varchar(25)
Title varchar(25) Title varchar(25)
Distance varchar(25)
Office_Room varchar(25) Level varchar(25)
CONSTRAINT
Suppervisor varchar(25) Duration varchar(25)
campus_pk_1
CONSTRAINT lecturer_pk_1 UNIQUE (Title) UNIQUE (Name) CONSTRAINT
school_pk_1 UNIQUE
CONSTRAINT lecturer_pk_2 UNIQUE CONSTRAINT
(Name)
(Name) campus _pk_2
UNIQUE (Address) CONSTRAINT
CONSTRAINT lecturer_pk_3 UNIQUE
school_pk_2 UNIQUE
(Office_Room) CONSTRAINT
(Building)
CONSTRAINT lecturer_pk PRIMARY KEY campus _pk_3
UNIQUE (Distance) CONSTRAINT
(Lecturer_ID)
school_pk_3 UNIQUE
(Level)

Qn1 (d)

INSERTING RECORD INTO Club TABLE

INSERT INTO club(Club_Name, Building, Phone_No, Sports_Name, Campus_Name, Address,
Distance) VALUES ('Chess', 'Sports Building', '0756435654', 'Basket Ball', 'Main Campus',
'Kansanga Kampala-Uganda', '2km');

INSERT INTO club (Club_Name, Building, Phone_No, Sports_Name, Campus_Name, Address,

Distance) VALUES (' Table tennis', 'Boma Building', '0786435654', 'Basket Ball', 'Western
Campus', 'Ishaka, '5km');

INSERTING RECORD INTO Faculty TABLE

INSERT INTO faculty(Name, Building, Campus_name, Dean, School, Programme_name ,

Programme_code, Course ) VALUES ('Database and Management Sciences', 'Main Campus',
'Dr.Ssendegeya',School of Database Administration', 'Bachelor Database Administration',
'BBA102', 'BBA');

INSERT INTO faculty(Name, Building, Campus_name, Dean, School, Programme_name ,

Programme_code, Course ) VALUES ('Faculty of Applied Sciences', 'Main Campus',
'Dr.Tindyebwa Donald',School of Computing and Information Science', 'Bachelor of Information
Technology', 'BIT102', 'BIT');

INSERTING RECORD INTO students TABLE

INSERT INTO students(Student_name, Student_ID, Date_of_birth, Gender, Programme_name,

Programme_code, Faculty_name, Course_name, School, Year, Term, CW_Mark,
FinalExam_Mark, Grade, Lecturer_name) VALUES ('Mutumba Jackson', 'BIT/2345/43/DU',
'27/11/1996',Male', 'Bachelor of Information Technology', 'BIT202', 'Faculty of Computing
Applied Sciences', ‘Information Technology’, ‘School of Computing’, ‘2019’,’Second’,
‘30’,’40’,’B+’,’Stephen Joab’);

INSERT INTO students(Student_name, Student_ID, Date_of_birth, Gender, Programme_name,

Programme_code, Faculty_name, Course_name, School, Year, Term, CW_Mark,
FinalExam_Mark, Grade, Lecturer_name) VALUES ('Ssekitoleko Abdul', 'BIT/34455/43/DU',
'09/10/1995',Male', 'Bachelor of Information Technology', 'BIT102', 'Faculty of Computing
Applied Sciences', ‘Information Technology’, ‘School of Computing’, ‘2019’,’First’,
‘25’,’35’,’C+’,’Nuwagaba Charles’);

Qn2.
Incomplete transaction is the premature termination of transaction processing before transactions
can be committed to the database, which might result in data loss or corruption.

When a transaction is not completed either because a query times out or because the batch is
cancelled in the middle of a transaction without issuing a COMMIT or ROLLBACK statement to
complete the transaction, the transaction is left open and all the locks acquired during that
transaction continue to be held. Subsequent transactions executed under the same connection are
treated as nested transactions, so all the locks acquired in these completed transactions are not
released. This problem repeats with all the transactions executed from the same connection until
a ROLLBACK is executed. As a result, a large number of locks are held, users are blocked, and
transactions are lost, which results in data that is different from what you expect.
Recovery using Log File
When has a transaction committed?
‒ When <Ti, Start>and <Ti,Commit> is in the log file
When has a transaction failed/aborted?
‒ When <Ti, Start> is in the log file but <Ti,Commit>
Backward Recovery:
‒ Undo transaction (restore old values) if no Commit
Forward Recovery:
‒ Start with an earlier copy of the database
‒ Redo transaction (write new values) if Commit

Qn3.
DBMS Transaction properties

The transaction has the four properties. These are used to maintain consistency in a database,
before and after the transaction.

1. Atomicity
2. Consistency
3. Isolation
4. Durability

Atomicity

 It states that all operations of the transaction take place at once if not, the transaction is
aborted.
  There is no midway, i.e., the transaction cannot occur partially. Each transaction is
treated as one unit and either run to completion or is not executed at all.

Atomicity involves the following two operations:

Abort: If a transaction aborts then all the changes made are not visible.

Commit: If a transaction commits then all the changes made are visible.

Example: Let's assume that following transaction T consisting of T1 and T2. A consists of Rs

600 and B consists of Rs 300. Transfer Rs 100 from account A to account B.

T1 T2

Read(A) Read(B)
A:=A-100 Y:=Y+100
Write(A) Write(B)

After completion of the transaction, A consists of Rs 500 and B consists of Rs 400.

If the transaction T fails after the completion of transaction T1 but before completion of
transaction T2, then the amount will be deducted from A but not added to B. This shows the
inconsistent database state. In order to ensure correctness of database state, the transaction must
be executed in entirety.

Consistency

 The integrity constraints are maintained so that the database is consistent before and after
the transaction.
 The execution of a transaction will leave a database in either its prior stable state or a new
stable state.
  The consistent property of database states that every transaction sees a consistent
database instance.
 The transaction is used to transform the database from one consistent state to another
consistent state.

For example: The total amount must be maintained before or after the transaction.

Total before T occurs = 600+300=900  
Total after T occurs= 500+400=900  

Therefore, the database is consistent. In the case when T1 is completed but T2 fails, then
inconsistency will occur.

Isolation

 It shows that the data which is used at the time of execution of a transaction cannot be
used by the second transaction until the first one is completed.
 In isolation, if the transaction T1 is being executed and using the data item X, then that
data item can't be accessed by any other transaction T2 until the transaction T1 ends.
 The concurrency control subsystem of the DBMS enforced the isolation property.

Durability

 The durability property is used to indicate the performance of the database's consistent
state. It states that the transaction made the permanent changes.
 They cannot be lost by the erroneous operation of a faulty transaction or by the system
failure. When a transaction is completed, then the database reaches a state known as the
consistent state. That consistent state cannot be lost, even in the event of a system's
failure.
 The recovery subsystem of the DBMS has the responsibility of Durability property.
Qn4.

Database Security

Database security includes a variety of measures used to secure database management systems
from malicious cyber-attacks and illegitimate use. Database security programs are designed to
protect not only the data within the database, but also the data management system itself, and
every application that accesses it, from misuse, damage, and intrusion.
Database Security Threats

Insider Threats

An insider threat is a security risk from one of the following three sources, each of which has
privileged means of entry to the database:
 A malicious insider with ill-intent
 A negligent person within the organization who exposes the database to attack through
careless actions

 An outsider who obtains credentials through social engineering or other methods, or

gains access to the database’s credentials

An insider threat is one of the most typical causes of database security breaches and it often
occurs because a lot of employees and students have been granted privileged user access.
Human Error
Weak passwords, password sharing, accidental erasure or corruption of data, and other
undesirable user behaviors are still the cause of almost half of data breaches reported.

An Evolving IT Environment
The evolving IT environment is making databases more susceptible to threats. Here are trends
that can lead to new types of attacks on databases, or may require new defensive measures:

Growing data volumes - storage, data capture, and processing is growing exponentially across
almost all organizations. Any data security practices or tools must be highly scalable to address
distant and near-future requirements.
Securing Database Server
A database server is a physical or virtual machine running the database. Securing a database
server, also known as “hardening”, is a process that includes physical security, network security,
and secure operating system configuration.

Ensure Physical Database Security

Refrain from sharing a server for web applications and database applications, if your database
contains sensitive data. Although it could be cheaper, and easier, to host your site and database
together on a hosting provider, you are placing the security of your data in someone else’s hands.

If you do rely on a web hosting service to manage your database, you should ensure that it is a
company with a strong security track record. It is best to stay clear of free hosting services due to
the possible lack of security.

If you manage your database in an on-premise data center, keep in mind that your data center is
also prone to attacks from outsiders or insider threats. Ensure you have physical security
measures, including locks, cameras, and security personnel in your physical facility. Any access
to physical servers must be logged and only granted to authorize individuals.

In addition, do not leave database backups in locations that are publicly accessible, such as
temporary partitions, web folders, or unsecured cloud storage buckets.

Lock Down Accounts and Privileges

Let’s consider the Oracle database server. After the database is installed, the Oracle database
configuration assistant (DBCA) automatically expires and locks most of the default database user
accounts.

If you install an Oracle database manually, this doesn’t happen and default privileged accounts
won’t be expired or locked. Their password stays the same as their username, by default. An
attacker will try to use these credentials first to connect to the database.
It is critical to ensure that every privileged account on a database server is configured with a
strong, unique password. If accounts are not needed, they should be expired and locked.

For the remaining accounts, access has to be limited to the absolute minimum required. Each
account should only have access to the tables and operations (for example, SELECT or INSERT)
required by the user. Avoid creating user accounts with access to every table in the database.

Regularly Patch Database servers

Ensure that patches remain current. Effective database patch management is a crucial security
practice because attackers are actively seeking out new security flaws in databases, and new
viruses and malware appear on a daily basis.

A timely deployment of up-to-date versions of database service packs, critical security hotfixes,
and cumulative updates will improve the stability of database performance.

Disable Public Network Access

Organizations store their applications in databases. In most real-world scenarios, the end-user
doesn’t require direct access to the database. Thus, you should block all public network access to
database servers unless you are a hosting provider. Ideally, an organization should set up
gateway servers (VPN or SSH tunnels) for remote administrators.

Encrypt All Files and Backups

Irrespective of how solid your defenses are, there is always a possibility that a hacker may
infiltrate your system. Yet, attackers are not the only threat to the security of your database. Your
employees and students may also pose a risk to your database. There is always the possibility
that a malicious or careless insider will gain access to a file they don’t have permission to access.

Encrypting your data makes it unreadable to both attackers and employees and students. Without
an encryption key, they cannot access it, this provides a last line of defense against unwelcome
intrusions. Encrypt all-important application files, data files, and backups so that unauthorized
users cannot read your critical data.

Database Security Best Practices

Here are several best practices you can use to improve the security of sensitive databases.

Actively Manage Passwords and User Access

If you have a large organization, you must think about automating access management via
password management or access management software. This will provide permitted users with a
short-term password with the rights they need every time they need to gain access to a database.

It also keeps track of the activities completed during that time frame and stops administrators
from sharing passwords. While administrators may feel that sharing passwords is convenient,
however, doing so makes effective database accountability and security almost impossible.

In addition, the following security measures are recommended:

 Strong passwords must be enforced

 Password hashes must be salted and stored encrypted

 Accounts must be locked following multiple login attempts

 Accounts must be regularly reviewed and deactivated if staff move to different roles,
leave the company, or no longer require the same level of access

Test Your Database Security

Once you have put in place your database security infrastructure, you must test it against a real
threat. Auditing or performing penetration tests against your own database will help you get into
the mindset of a cybercriminal and isolate any vulnerabilities you may have overlooked.

To make sure the test is comprehensive, involve ethical hackers or recognized penetration testing
services in your security testing. Penetration testers provide extensive reports listing database
vulnerabilities, and it is important to quickly investigate and remediate these vulnerabilities. Run
a penetration test on a critical database system at least once per year.

Use Real-Time Database Monitoring

Continually scanning your database for breach attempts increases your security and lets you
rapidly react to possible attacks.

In particular, File Integrity Monitoring (FIM) can help you log all actions carried out on the
database’s server and to alert you of potential breaches. When FIM detects a change to important
database files, ensure security teams are alerted and able to investigate and respond to the threat.

Use Web Application and Database Firewalls

You should use a firewall to protect your database server from database security threats. By
default, a firewall does not permit access to traffic. It needs to also stop your database from
starting outbound connections unless there is a particular reason for doing so.

As well as safeguarding the database with a firewall, you must deploy a web application
firewall (WAF). This is because attacks aimed at web applications, including SQL injection, can
be used to gain illicit access to your databases.

A database firewall will not stop most web application attacks, because traditional firewalls
operate at the network layer, while web application layers operate at the application layer (layer
7 of the OSI model). A WAF operates at layer 7 and is able to detect malicious web application
traffic, such as SQL injection attacks, and block it before it can harm your database.

Imperva Database Security

Imperva provides an industry-leading Web Application Firewall, which can prevent web
application attacks that affect databases, including SQL injection. We also provide file integrity
protection (FIM) and file security technology, defending sensitive files from cybercriminals and
malicious insiders.
In addition, Imperva protects all cloud-based data stores to ensure compliance and preserve the
agility and cost benefits you get from your cloud investments:

Cloud Data Security – Simplify securing your cloud databases to catch up and keep up with
DevOps. Imperva’s solution enables cloud-managed services users to rapidly gain visibility and
control of cloud data.

Database Security – Imperva delivers analytics, protection, and response across your data
assets, on-premise and in the cloud – giving you the risk visibility to prevent data breaches and
avoid compliance incidents. Integrate with any database to gain instant visibility, implement
universal policies, and speed time to value.

Data Risk Analysis – Automate the detection of non-compliant, risky, or malicious data access
behavior across all of your databases enterprise-wide to accelerate remediation.

Qn5.

Weak Login Credentials

Password authentication is a process that involves a user inputting a unique ID and key that are
then checked against stored crede.ntials.

Password-based authentication is one of the most popular approaches to authenticate a user in

various enterprise applications. But there are many problems associated with the password based
authentication systems and the risks associated with using passwords as an authentication
mechanism for enterprise applications is not completely secure.
When users register for an account on a site or application that uses password-based logins,
they’re prompted to create a username and password.

However, if the password is predictable, this can lead to vulnerabilities in the authentication process.
Predictable usernames can make it easier for attackers to target specific users.

Rather than using a full brute-force attack, the attackers will look for accounts with easy-to-guess
passwords, which are used far too often. . They’ll try common credentials like "admin," "admin1," and
"password1." With no restrictions on weak passwords, even sites protected against brute-force attacks
can find themselves compromised.

Weak passwords always play a major role in any hack. For the ease of user, sometime
applications do not enforce password complexity and as a result of that users use simple
passwords such as password, password123, Password@123, 12345, god, own mobile number
etc. Weak password does not always mean length and the characters used, it also means the
guessability. Name@12345, it looks quite complex password but can be guessable. So do not use
password related to name, place, or mobile number. Weak passwords can be guessable or
attacker can bruteforce if the length of the password is very small, so try to use random strings
with special characters. Though that can be hard to remember as a security point of view it’s
quite secure.

Weak or stolen passwords are the top entry point for hackers

The fact is, cybercriminals know that passwords are the weak link. That’s why they are a top
target for hackers. It works. Stolen credentials are the top cited action involved in security
breaches. In fact, 81 percent of hacking-related breaches used stolen and/or weak passwords.

Even your most privileged users aren’t being password-smart

To make matters worse, some of your most privileged accounts may have poor passwords.
Privileged accounts are ones that have access to confidential data or the ability to provide access
to other apps and systems. For example, administrator accounts.