DAVID WAMBUA MBITI

S18/02712/20

COMPUTER 351 ASSIGNMENT

YEAR IV

SEMESTER 1

QUESTION ONE

1.Discuss security and integrity of databases and distributed database systems .

ANSWERS

Databases

Databases are used to store and manage important data.

A. Database Security

Database security is protecting the data from threats, like hackers or accidental damage.

Important aspects to database security

1. Access control

Authentication: This is the process of confirming who a user is.For example, using a password or
fingerprint.

Authorization: After someone is identified, authorization controls what they can do with the data. For
instance, can they just view the data, or can they also add, change, or delete it?

2. Encryption

Encryption at Rest: This means the data is stored in a scrambled form, so even if someone steals the
storage device, they can’t read the data without the decryption key.

Encryption in Transit: This protects data when it's being sent from one place to another. For example,
when data is transferred over the internet, it can be encrypted to keep it safe from hackers.

3. Audit and Monitoring

Audit Logs: These are records that track who accessed the database and what changes were made. It
helps find out if anything suspicious happens.

Realtime Monitoring: This means continuously checking the database to spot problems right away, such
as unauthorized access.
4. Backup and Recovery

Backups: Regular backups are important so that if data is lost or damaged, you can restore it.

Recovery Plans: If something goes wrong (like a crash or attack), having a plan to get the database back
to normal is crucial.

B. Database Integrity

Database integrity means keeping the data accurate, consistent, and reliable. This ensures that the data
is correct and doesn’t get corrupted or lost over time.

Entity Integrity

Each record in the database should be unique. For example, using a primary key (like an ID number) to
make sure every record can be identified without confusion.

Referential Integrity

This ensures that relationships between tables stay consistent. For example, if one table refers to
another, the reference must be valid.

Domain Integrity

This makes sure data values are correct and follow rules. For example, an "age" field should only have
numbers, not text, and it should make sense (like not having a negative number for age).

Transactional Integrity (ACID)

Atomicity: A transaction (a group of actions) is either fully completed or not done at all. This prevents
halfdone operations that could corrupt data.

Consistency: A transaction should move the database from one valid state to another. It should follow
all the rules set for the database.

Isolation: Multiple transactions can happen at the same time, but they shouldn’t interfere with each
other.

Durability: Once a transaction is done, the changes are permanent, even if the system crashes right
after.
C. Security and Integrity in Distributed Database Systems

Distributed databases are databases spread across multiple servers or locations. These systems face
more challenges in security and integrity because the data is not stored in one place, and it moves
around more often.

(i) Security Challenges

Access Control: In distributed databases, access control becomes trickier because users might access
different parts of the system in different locations.

Network Security: Data is often transferred over the internet, so it needs to be protected from being
intercepted by hackers.

Replicating Data Securely: In distributed systems, data is often copied across different servers for
safety.

(ii) Integrity Challenges

Data Consistency: Since data is spread across multiple servers, ensuring all copies of the data stay in
sync is a big challenge. For example, if one copy of the data changes, the other copies must be updated
too.

Concurrency Control: In distributed systems, many users might try to access and change data at the
same time. Proper methods need to be in place to ensure that this doesn’t cause errors or data
corruption.

(iii) Fault Tolerance and Availability

Replication: To make sure data is always available, it’s often copied across different servers. If one
server fails, the system can still work with the copy.

Network Issues: Distributed systems need to handle cases where some parts of the network might fail
or be disconnected. This requires careful planning to ensure the system continues to work even in these
situations.
QUESTION TWO

1. Discuss concurrency control in DBMS

ANSWERS

Concurrency control in a Database Management System (DBMS) is the process of managing

simultaneous transactions to ensure that they do not interfere with each other and cause errors. When
multiple users or applications access the database at the same time, there is a risk that data may
become inconsistent or incorrect. The goal of concurrency control is to ensure that the database
remains consistent and correct, even when many transactions are happening at once.

Transaction

A transaction is a set of operations that are executed as a single unit. These operations can include
reading, updating, or deleting data.

Each transaction must follow the ACID properties:

Atomicity: A transaction is allor-nothing. Either all operations in the transaction are completed, or none
of them are.

Consistency: After a transaction, the database must be in a valid state, meaning it follows all the rules
(like integrity constraints).

Isolation: Each transaction should not interfere with others. The changes made by one transaction
should not be visible to other transactions until the transaction is finished.

Durability: Once a transaction is committed, its changes are permanent, even if the system crashes.

Problems in Concurrent Transactions

When multiple transactions are running at the same time, some issues can arise:

Lost Update: Two transactions try to update the same data at the same time. One transaction’s update
might be lost because it is overwritten by the other.

Temporary Inconsistency: One transaction reads data that another transaction is in the middle of
changing, causing the reader to see incorrect or inconsistent data.

Overwritten Data:One transaction changes data that another transaction has already changed, causing
the first transaction’s changes to be lost.

Deadlock: Two or more transactions are waiting for each other to release resources, creating a cycle
where neither transaction can proceed.
Concurrency Control Methods

There are different methods to control concurrency and prevent the problems mentioned above. The
main methods are locking protocols, timestamp based protocols, optimistic concurrency control, and
multi-version concurrency control.

1. Locking Protocols

In locking protocols, when a transaction wants to access a data item(like a piece of information), it must
first "lock" it. The lock prevents other transactions from accessing or modifying the same data at the
same time.

Shared Lock (S-Lock): Allows multiple transactions to read the data, but no transaction can modify it
while it's locked.

Exclusive Lock (X-Lock): Prevents any other transaction from reading or modifying the data.

One common type of locking is Two-Phase Locking (2PL), where:

Growing Phase: A transaction can acquire locks but cannot release them.

Shrinking Phase: A transaction can release locks but cannot acquire new ones.

While locking prevents conflicts, it can cause deadlocks, where two or more transactions wait for each
other to release locks. Deadlock detection and handling techniques are used to solve this issue.

2. Timestamp-Based Protocols

In timestamp-based protocols, each transaction is given a timestamp when it begins. The DBMS uses
these timestamps to decide the order in which transactions should be executed. If two transactions try
to access the same data in a conflicting way, the one with the earlier timestamp is allowed to proceed,
and the other is rolled back.

Basic Timestamp Ordering: If a transaction tries to read or write data that conflicts with another
transaction, the one with the later timestamp is aborted.

This method avoids deadlocks, but transactions may need to be rolled back often, which can reduce
performance.

3. Optimistic Concurrency Control (OCC)

In Optimistic Concurrency Control (OCC), transactions execute without any locks, assuming that conflicts
will be rare. However, before committing (finishing), the transaction checks if there are any conflicts
with other transactions. If there are conflicts, the transaction is rolled back and must start over.
OCC has three phases:

Read Phase: The transaction reads data and performs operations without locking the data.

Validation Phase: Before committing, the transaction checks if any other transactions have caused
conflicts.

Write Phase: If no conflicts were found, the transaction writes the changes to the database.

4. MultiVersion Concurrency Control (MVCC)

Multi-Version Concurrency Control (MVCC) allows multiple versions of the same data item to exist at the
same time. This means that transactions can access the version of the data that was available when they
started, without interfering with other transactions.

Snapshot Isolation: Each transaction gets a snapshot of the database at the time it started, so it sees a
consistent version of the data, even if other transactions are changing the data.

MVCC is useful in systems with many read operations because it reduces the need for locking and allows
multiple transactions to run without interfering with each other.

Serializability is the highest level of isolation in which the results of executing multiple transactions
concurrently should be the same as if the transactions were executed one at a time in some order. This
means that the system ensures no conflicts between transactions that could lead to incorrect data.

Levels of isolation:

Serializable: Transactions are executed in a way that ensures the same result as if they were done one
after the other.

Repeatable Read: A transaction reads the same data every time it accesses it.

Read Committed: A transaction can only read data that has been committed by other transactions.

Read Uncommitted: The lowest level of isolation, where a transaction can read data that has not been
committed, possibly leading to incorrect results.