Computerized databases are central to efficient information management within Kenyan organizations that rely on ICT technicians to ensure data integrity, accessibility, and security. Whether in financial institutions like KCB, educational institutions, or county government offices, understanding user requirements and designing effective database schemas are foundational skills. This chapter focuses on gathering accurate user requirements and crafting database models that align with organizational needs, enabling ICT technicians to develop systems that support operational and strategic goals.

3.1 Computerised Database User Requirements Collection

Collecting user requirements for a computerised database is a critical first step in database development. It involves understanding what data users need, how they intend to use it, and the constraints they face. In Kenyan workplaces such as hospitals or SACCOs, failure to gather precise requirements can lead to databases that are inefficient or unusable, causing delays and increased costs. This section explores fundamental concepts of databases and the systematic process of user requirements collection.

3.1.1 Introduction to database

A database is an organised collection of data stored and accessed electronically to support efficient retrieval and management. Databases underpin many ICT systems used in the public and private sectors, from managing student fee records at a technical college to tracking loan applications at a microfinance institution.

3.1.1.1 Key concepts

Every database project relies on a small set of core ideas. Understanding these terms allows an ICT technician to talk clearly with users and developers and to recognise what a database can and cannot do. Example: a bakery that records daily orders on paper can only answer "how much flour did we use last month?" after hours of counting, whereas a database answers it in seconds.

Basic terms:

• Data: Raw facts and figures that have no meaning on their own, such as "Wanjiru", "12" or "2,500". Data becomes useful only when it is processed.
• Information: Data that has been processed and organised so that it has meaning. For example, a list of bread sales per day, totalled per week, tells the bakery owner which days are busiest.
• Database: A structured collection of related data stored electronically so that it can be searched, updated and reported on easily.
• Database Management System (DBMS): The software used to create, store, control and retrieve data in a database. Microsoft Access, MySQL and PostgreSQL are examples of DBMS software.
• Database system: The complete arrangement made up of the data, the DBMS, the hardware, the people who use it and the procedures that govern it.
• Metadata: Data that describes other data, such as the name, type and size of each item stored. A library database uses metadata to state that a "title" is text of up to 100 characters.
• Data redundancy: Unnecessary repetition of the same data in several places. Storing a customer's address in every one of their orders wastes space and leads to conflicting copies when the address changes.

Characteristics of databases:

• Structured data storage: Databases store data in structured formats, typically tables, allowing for easy querying and reporting. This structure supports complex data relationships such as those in university student records.
• Data integrity: Ensures accuracy and consistency of data over its lifecycle, preventing errors that can arise from manual record keeping in retail businesses.
• Multi-user access: Enables multiple users to access and manipulate data simultaneously while maintaining security, essential for collaborative environments like county government offices.
• Data security: Protects sensitive data from unauthorised access, critical for institutions such as a county hospital handling personal health information.
• Efficient data management: Supports operations like data insertion, deletion and updates without compromising performance, useful in dynamic environments such as hotel booking systems.

3.1.1.2 Database organisation

Database organisation describes how data is arranged, from the smallest item to the complete database, and which model is used to hold it. The way data is organised decides how fast it can be found, how much space it needs and how easily it can grow. Example: a tea factory that records each farmer's deliveries in an organised database can total payments for thousands of farmers without re-typing any figures.

Hierarchy of data:

• Character: The smallest unit a user works with, such as a letter, digit or symbol.
• Field: A group of characters that form one meaningful item, for example a farmer's name or phone number.
• Record: A set of related fields describing one person, thing or event, for example everything stored about one farmer.
• Table (file): A collection of records of the same kind, such as all farmers registered at the factory.
• Database: A collection of related tables stored together, for example the tables for farmers, deliveries and payments.

Database types relevant to ICT technicians:

• Relational databases: Use tables with relationships between them. They suit transaction processing in banks, where accuracy and consistency matter most.
• Hierarchical databases: Organise data in a tree, where each item has one parent and may have many children. An organisation chart is a natural fit for this model.
• NoSQL databases: Handle unstructured or flexible data, increasingly relevant for big data applications in agricultural cooperatives.
• Distributed databases: Data spread across multiple locations, useful for a supermarket chain with branches in several towns that must share stock levels.
• Cloud databases: Hosted online, offering scalability and remote access, adopted by startups and SMEs for flexibility.
• Object-oriented databases: Store data as objects, applied in specialised software projects such as engineering design drawings.

3.1.1.3 Database relationships

A relationship is a logical link between two sets of data, usually between two tables, created through a field they have in common. Relationships allow data to be stored once and reused, instead of being repeated. Example: a pharmacy stores each customer's details once and links every prescription to that customer, so a change of phone number is made in one place only.

Types of relationships:

Why relationships matter:

• Reduce duplication: Data is entered once and referred to many times, saving storage and typing effort.
• Keep data consistent: A correction made in one place is automatically seen everywhere the data is used.
• Allow data to be combined: Information held in separate tables can be brought together in one view, such as a customer with all their prescriptions.
• Enforce rules: A relationship can prevent a record from pointing to something that does not exist, for example a prescription with no customer.
• Support reporting: Linked data makes it possible to produce summaries across several subjects, such as total sales per supplier.

3.1.1.4 Database operations

Database operations are the actions carried out on a database by users and administrators. Some operations work on the data itself, while others protect and maintain the database. Understanding them helps when gathering requirements, because each user group needs a different set of operations. Example: a receptionist at a lodge needs to add and find guest bookings, while the manager also needs to print reports.

Data manipulation operations:

• Insert: Adding new records, such as registering a new guest at a lodge.
• Retrieve: Searching for and displaying stored data, such as finding all books borrowed by one member of a library.
• Update: Changing existing data so that it stays correct, such as recording a new phone number for a patient at a dispensary.
• Delete: Removing records that are no longer needed, for example cancelled bookings, usually under rules that protect important history.
• Sort and filter: Arranging records in a chosen order or showing only those that meet a condition, such as unpaid invoices over Ksh 10,000.

Database administration operations:

• Backup and recovery: Making copies of the database at regular intervals so that data can be restored after a failure, theft or accidental deletion.
• Security control: Giving each user only the permissions their job needs, protected by user names and passwords.
• Data validation: Checking data as it is entered, for example rejecting a date of birth in the future.
• Performance monitoring: Watching the speed and size of the database so that slow searches or lack of space are dealt with early.
• Archiving: Moving old data to separate storage so that the working database stays fast while history is kept.

3.1.2 Collection of User requirements

Gathering user requirements involves engaging with stakeholders to define what the database must achieve. This stage determines the scope, functionality, and constraints of the database system. In institutions such as county government offices, comprehensive user requirements collection ensures the database supports operational workflows effectively.

Importance of user requirements collection

• Defines scope of database: Clarifies what data will be stored and processed, preventing scope creep in projects like school management systems.
• Identifies user needs: Captures specific needs of various users, such as data entry clerks and managers in a courier company, ensuring usability.
• Facilitates communication: Bridges the gap between technical teams and users, reducing misunderstandings during development.
• Supports data integrity: Helps design validation rules by understanding data entry points and constraints.
• Aids future scalability: Anticipates future needs, allowing the database to adapt to organisational growth, as in a growing chain of salons that adds new branches.

Methods of collecting user requirements

• Interviews: One-on-one or group discussions with stakeholders to explore their needs in detail. They allow follow-up questions when an answer is unclear.
• Questionnaires: Structured forms to gather standardised information from a large user base, such as staff across multiple branches. They are quick to distribute but give limited detail.
• Observation: Studying current workflows to understand data usage patterns, important at a busy clinic reception where staff may forget to mention steps they do automatically.
• Document analysis: Reviewing existing records and reports, such as registers, forms and invoices, to identify data sources and requirements.
• Workshops: Collaborative sessions involving users and developers to brainstorm and clarify requirements. They help to resolve disagreements between departments on the spot.

Best practices in user requirements collection

• Engage diverse stakeholders: Include end-users, managers and IT staff so that all perspectives are captured.
• Use plain language: Use clear, non-technical language to avoid confusion during discussions, explaining any term users do not know.
• Prioritise requirements: Separate what is essential from what is desirable, so that critical functionality is built first.
• Document meticulously: Record every requirement in writing for reference throughout development, including who requested it.
• Validate with users: Return the collected requirements to users to confirm accuracy and completeness before design begins.

Types of user requirements

Requirements are easier to collect and check when they are grouped by type. Each type answers a different question about the database, and missing a whole type is a common reason for systems that disappoint users. Example: a hardware shop may state clearly that it needs a stock list (a data requirement) but forget to say that the list must open within three seconds (a performance requirement).

• Data requirements: The items to be stored, their formats and their sources, such as product name, quantity in stock and unit price.
• Functional requirements: What users must be able to do with the database, such as add a supplier, search for a product or print a stock report.
• Reporting requirements: The reports and summaries management needs, how often they are needed and who receives them.
• Security and access requirements: Who may view, change or delete which data. A cashier, for instance, may record sales but not alter prices.
• Performance requirements: Expected speed, number of simultaneous users and amount of data to be held now and in future.
• Constraints: Limits on the project such as budget, available hardware, deadlines and existing software. For example, a project budget of Ksh 150,000 rules out an expensive server.

Procedure for collecting and documenting user requirements

A planned procedure keeps requirements gathering orderly and complete. Following the same steps on every project reduces the risk of forgotten users or unclear agreements. Example: a farm planning to track its dairy herd would follow these steps before choosing any software.

1. Identify the stakeholders: List everyone who will use, manage or be affected by the database, such as the farm manager, milk recorders and the accountant.
2. Define the purpose and scope: Agree in writing what problem the database will solve and what it will not cover, so that expectations are realistic.
3. Select the collection methods: Choose suitable methods, such as interviews for managers and questionnaires for many recorders, and prepare questions and schedules.
4. Gather the information: Carry out the interviews, observations and document reviews, taking careful notes and collecting copies of existing forms and registers.
5. Analyse and classify the findings: Sort the information into data, functional, reporting, security and performance requirements, and remove duplicates or conflicts.
6. Prioritise the requirements: Rank each requirement as essential, important or optional with the help of the sponsor, taking time and budget into account.
7. Write the requirements specification: Produce a clear document that lists every requirement in simple, testable statements, ready to be used for database design.
8. Obtain approval and manage changes: Have the sponsor and key users sign the document, and record any later change through a formal request so that scope remains under control.

Chapter Summary

This chapter explored the essential elements involved in maintaining a computerized database, beginning with an introduction to databases, their key concepts, organization, relationships, and fundamental operations. It emphasized the importance of accurately collecting user requirements to ensure the database meets the needs of its users. The design phase covered the creation of database schemas using models such as Entity-Relationship Diagrams and relational models, which provide structured frameworks for organizing data. The chapter then detailed the creation of various database objects including tables, records, fields, keys, forms, queries, and reports, each serving a specific role in data management. Data manipulation techniques were examined, focusing on inserting, retrieving, deleting, and updating records to maintain data integrity and relevance. Finally, the chapter discussed the printing of database objects like tables, forms, queries, and reports, highlighting how these outputs support data analysis and decision-making. Together, these topics provide a comprehensive understanding of how to effectively maintain a computerized database system.