ASSIGNMENT

Ivy Chelangat 23/00865

Janet Makau 24/07649

Mpoe Kelvin 24/06173

Ron Limo 24/06481

Brenda Mugambi 23/01051

Austine Onganga 21/08909

Assignment 1.
a) Stages of the Database Development Life Cycle

i. Planning
• Expected Outcomes: Define the project scope, objectives, and feasibility. Identify
stakeholders and requirements.
• Challenges: Misalignment of stakeholder expectations, unclear objectives, or
underestimated resource needs.
ii. Requirement Analysis
• Expected Outcomes: Gather and document functional and non-functional requirements.
Create a requirement specification document.
• Challenges: Incomplete requirements, changing user needs, and communication
barriers among stakeholders.
iii. Design
• Expected Outcomes: Develop a conceptual, logical, and physical design of the database.
Create ER diagrams and schema designs.
• Challenges: Design complexity, lack of clarity in requirements leading to poor design
decisions, and integration issues with existing systems.
iv. Implementation
• Expected Outcomes: Build the database according to the design specifications. Populate
the database with initial data.
• Challenges: Technical difficulties, insufficient testing, data migration issues, and timeline
delays.
v. Testing
• Expected Outcomes: Validate the database against requirements. Conduct performance
testing, security testing, and user acceptance testing.
• Challenges: Undetected bugs, incomplete test cases, and user resistance during
acceptance testing.
vi. Deployment
• Expected Outcomes: Deploy the database into a production environment. Ensure users
are trained and ready to use the system.
• Challenges: Downtime during deployment, user training gaps, and unexpected issues
post-launch.
vii. Maintenance
• Expected Outcomes: Regular updates and optimizations to ensure the database runs
efficiently. Implement backup and recovery solutions.
• Challenges: Evolving user requirements, data integrity issues, and performance
degradation over time.

b) Logical Design Phase

Key Tasks

i. Requirement Analysis
• Gather requirements from stakeholders (administrators, faculty, students).
• Identify key entities: Students, Courses, Enrollments, Instructors, Departments.
Example: Understanding what data is necessary for student records (name, ID, contact
information).
ii. Entity-Relationship (ER) Modeling
• Create an ER diagram to visually represent the entities and their relationships.
Example: A student can enroll in multiple courses, and a course can have multiple students.
iii. Normalization
• Normalize the data to eliminate redundancy and ensure data integrity.
Example: Separate student information (StudentID, Name, Email) from enrollment data
(StudentID, CourseID, Semester).
iv. Define Attributes
• Specify attributes for each entity, including data types and constraints.
Example: For the Student entity, attributes might include StudentID (Primary Key), Name
(String), DateOfBirth (Date).
Important Considerations

• Data Integrity: Ensure that relationships are correctly defined to maintain referential
integrity (e.g., foreign keys).
• Scalability: Consider future growth, such as an increasing number of students or courses.
 • Security: Identify sensitive data (e.g., personal identification) and plan for access
controls.
Possible Difficulties

• Conflicting Requirements: Different stakeholders may have varying needs that can
complicate the design.
• Complex Relationships: Handling many-to-many relationships (e.g., students enrolling in
multiple courses) can complicate the schema.
Physical Design Phase
Key Tasks

i. Database Selection
• Choose the appropriate database management system (DBMS) based on requirements.
Example: A relational DBMS like MySQL or PostgreSQL may be suitable for structured student
data.
ii. Table Creation
• Define tables based on the normalized design, specifying columns, data types, and
constraints.
Example: Create a Students table with StudentID, Name, Email, and a Courses table with
CourseID, CourseName.
iii. Indexing
• Implement indexes on frequently queried fields to improve performance.
Example: Index StudentID in the Enrollments table to speed up enrollment queries.
iv. Data Distribution
• Plan for data distribution if using a distributed database or cloud-based solution.
Example: Consider where to store enrollment records to balance load and access speed.
Important Considerations

• Performance Optimization: Analyze query performance and adjust indexes or storage

strategies as needed.
• Backup and Recovery: Implement backup strategies to protect data integrity and ensure
recovery in case of failure.
• Compliance: Ensure that the design adheres to regulations like FERPA (Family
Educational Rights and Privacy Act) for student data.
Possible Difficulties

• Performance Issues: As the database grows, queries may slow down without proper
indexing and optimization.
• Data Migration: If transitioning from an old system, migrating existing data to the new
format can be complex and error-prone.

Assignment 2
a) Analysis and Review of KCA University's Database Infrastructure
i. Database Design Considerations:
There are two general categories of distributed systems from a design viewpoint:
Geographically Distributed Database: This involves physical data distribution, and each campus
can have its own database server. Data is partitioned or replicated across sites, and
synchronization is necessary.
Logically Distributed Database: Data appears to be distributed across systems but is controlled
centrally. It allows for data abstraction, centralized control, and easier consistency enforcement a
principle highly championed in relational database design. ii. Relevance to KCA University's
Environment:
Based on Design Assumptions:
KCA University likely uses a logically distributed system, possibly on a centralized on-premise
server or through cloud-based services.
This maps to three-tier database design (presentation, logic, data tiers), where the data layer is
central. The logic layer manages data access and validation rules. The presentation layer is
accessed by students/staff from anywhere.
Supporting Design Concepts:
Data Integrity and Consistency: Logically distributed design more easily accommodates ACID
properties than fragmented geographical setups. Normalization and Centralized Schemas: One
schema can serve all users if the system is logically distributed.
Access Control: Centralized user authentication and role-based are easier to manage with a
centralized architecture. iii. Hypothetical System Implementation:
Database Type: Likely a relational DBMS such as MySQL, PostgreSQL, or MS SQL Server —
managed centrally.
Cloud-based Optimizations: To improve scalability and availability, the system might take
advantage of cloud features like read replicas, failover nodes, or regional caching — all
distributed DB development best practices.
Security Model: Role-based access control (RBAC), a key design principle, would likely be used
to restrict access to administrative, faculty, and student data.
iv. Conclusion :
According to principles of database design and development, KCA University likely has a
logically distributed database system that is centrally hosted and accessed via web or cloud
interfaces. This arrangement ensures:
Centralized schema management
Data normalization is effortless
Maintenance and backups are simplified
Access control is improved
Query performance is optimized across all campuses
Geographical distribution would introduce complexity in synchronization and schema
management that is not typically desirable unless there are substantial bandwidth or political
constraints.

b) Distinguishing between data redundancy and system redundancy

i. Data Redundancy: Data redundancy occurs when the same piece of data is stored in
multiple places within a system or database.
Example: In a school management system, a student's contact information might be stored in
both the admissions database and the library database. If the student's phone number changes,
updating it in one place but not the other can lead to inconsistencies.
ii. System Redundancy: System redundancy involves duplicating critical components or
systems to ensure continuous operation in case of failure.
Example: A hospital's patient monitoring system might have backup servers and power supplies.
If the primary server fails, the backup server takes over, ensuring that patient data is
continuously monitored without interruption.
c) Concept of system redundancy in distributed database systems
System Redundancy in Distributed Databases :- refers to the implementation of multiple,
geographically dispersed database nodes that replicate data and services. This is crucial for
maintaining high availability, reliability, and facilitating disaster recovery.

Key Aspects:

i. Data Availability:
By replicating data across multiple nodes, distributed databases ensure that if one node becomes
unavailable, other nodes can continue to serve data requests without interruption.
ii. Reliability:
Redundant systems can detect and handle failures automatically. For instance, if a node fails, the
system can reroute traffic to healthy nodes, minimizing downtime and maintaining service
reliability. iii. Disaster Recovery:
In the event of a catastrophic failure, such as a data center outage, redundant systems allow for
rapid failover to backup systems or locations, ensuring business continuity and data integrity.
Examples from Corporate Systems:

• MySQL Cluster:
MySQL Cluster employs synchronous replication across multiple nodes to ensure data
consistency and availability. In case of node failure, the system can automatically promote a
replica to become the new primary node, ensuring continuous service.

• High-Availability Clusters:
High-availability clusters (HA clusters) are groups of computers that support server applications
with minimal downtime. They operate by using high-availability software to harness redundant
computers in groups or clusters that provide continued service when system components fail.