Computerized databases are fundamental to managing large volumes of data efficiently in Kenyan ICT workplaces such as banks, county government offices, and universities. For ICT Technicians, understanding how to maintain these databases ensures data integrity, security, and usability over time. This chapter focuses on the user perspective of computerized databases, gathering user requirements for database systems, and designing effective database schemas that meet organizational needs.

3.1 Computerised database user requirements collection

Computerised database users range from data entry clerks to database administrators, each interacting with the system differently. For an ICT Technician in Kenya, accurately collecting user requirements is crucial to developing or maintaining databases that support decision-making and operational efficiency. Simulations help replicate real-world scenarios to test database functionality before full deployment.

3.1.1 Introduction to database

A computerised database is an organised collection of data stored electronically to allow easy access, management and updating. In a school administration office, for example, one database can hold student details, fee payments and examination marks, so that a clerk can retrieve any learner's record in seconds instead of searching through paper files. This section covers the fundamental ideas an ICT Technician needs in order to understand how data is structured, linked and manipulated.

3.1.1.1 Key concepts

Key concepts are the basic terms and principles used whenever databases are discussed, designed or maintained. An ICT Technician who understands them can talk to users and developers in the same language and can recognise what a system needs.

The main terms are:

• Database: A structured repository that stores data electronically, allowing efficient retrieval and management. Example: a college's student database.
• Database Management System (DBMS): Software that facilitates the creation, maintenance and use of databases, such as MySQL, Microsoft SQL Server or Microsoft Access. Users and programs never touch the stored files directly; they work through the DBMS.
• Table: The primary structure in which data is stored, arranged in rows and columns. A Students table, for instance, holds one row for each learner.
• Record: A single row in a table, representing one complete item such as one student or one product.
• Field: A column in a table, representing one attribute of the data such as Admission Number, Surname or Date of Birth.
• Query: A command that allows users to retrieve or manipulate data based on specific criteria, for example listing all students who owe fees.

The main principles are:

• Data integrity: Ensures that the data stored is accurate, valid and consistent. In a payroll database, integrity rules prevent a negative number of days worked from being entered and keep each employee's details the same wherever they appear.
• Data security: Protects sensitive information from unauthorised access through user accounts, passwords, access rights and encryption. A records clerk may be allowed to view staff details while only the administrator may change them.
• Multi-user access: Allows several users to read and modify the database at the same time. In an office with a shared stock database, the store clerk can record receipts while the accountant runs a stock report.
• Data redundancy: The unnecessary repetition of the same data in several places. It wastes storage and causes inconsistency, so good database design reduces it.
• Data independence: The ability to change how data is stored without having to rewrite the programs or forms that use it, which makes maintenance easier.

3.1.1.2 Database organisation

Database organisation describes how data is arranged so that it can be stored and found efficiently. Data is built up in levels: characters form fields, fields form records, records form tables, and tables together form the database. A well-organised database lets a technician locate a single learner's fee balance without scanning unrelated data.

The levels of organisation are:

• Character: The smallest unit a user sees, such as a letter, digit or symbol, stored as bytes.
• Field: A group of characters that has meaning, such as a phone number or surname.
• Record: A collection of related fields describing one entity. One student record might contain admission number, name, class and guardian's phone number.
• Table: A collection of records of the same type, held in rows and columns. All student records sit in one Students table.
• Database: A collection of related tables, together with the objects that work with them, such as forms, queries and reports.

Data can be organised using different models:

• Flat file: All data is held in a single table or file. It is simple, but data is repeated, as when a spreadsheet repeats a teacher's name on every row of a class list.
• Hierarchical: Data is arranged in a tree of parent and child records, where each child has only one parent.
• Network: Records are linked in a more flexible way, so a child can have more than one parent.
• Relational: Data is held in separate tables that are linked through common fields. This is the model used by most business databases today.

Normalisation is the process of organising data into tables so as to minimise redundancy and dependency. For example, instead of typing a class teacher's name against every student, the teacher is stored once in a Teachers table and linked to the classes. This keeps student records from being duplicated and makes updates simpler, since a change is made in only one place.

3.1.1.3 Database relationships

A relationship is a logical link between two tables, created through a common field. The field that uniquely identifies each record in one table appears again in the related table, where it is called a foreign key. Relationships allow data to be stored once and still be combined when needed, for example joining a Students table to a Fees table to show each learner's payments.

The three types of relationship are:

• One-to-one (1:1): One record in a table is linked to exactly one record in another table. Example: each employee has one staff identity card record.
• One-to-many (1:M): One record in the first table is linked to many records in the second, while each record in the second links back to only one. Example: one class has many students, but each student belongs to one class. This is the most frequently used relationship.
• Many-to-many (M:M): Many records in one table relate to many records in another. Example: a student takes many subjects and each subject is taken by many students. It is resolved by creating a third table, called a junction table, that holds the keys of both tables.

Related tables should obey referential integrity. This rule means a foreign key value must match an existing record in the parent table, so a fee payment cannot be recorded for an admission number that does not exist. It also stops a parent record from being deleted while child records still depend on it. Drawing the relationships as diagrams belongs to database design.

3.1.1.4 Database operations

Database operations are the actions users and administrators perform on a database to store, use and look after its data. Every form, report or program that works with a database ultimately relies on a small set of such operations.

The common operations are:

• Create: Setting up a new database and its tables, fields and relationships before any data is entered.
• Insert: Adding new records, for example registering a new student at the start of the term.
• Retrieve: Reading data by searching, sorting, filtering or running queries, such as listing all students in Form 2 alphabetically.
• Update: Changing existing data, such as correcting a phone number or changing a learner's class after promotion.
• Delete: Removing records that are no longer needed, done carefully so that related records are not left without a parent.
• Report and print: Presenting selected data in a readable format for management, such as a class list or fee statement.
• Backup and recovery: Making regular copies of the database and restoring them if data is lost or corrupted. A copy kept on a separate device allows an office to resume work after a disk failure.
• Security administration: Creating user accounts, assigning access rights and reviewing who has used the system.

The detailed procedures for inserting, retrieving, updating, deleting and printing are covered under data manipulation.

Types of databases

Databases differ in how they store and distribute data, and the choice depends on the needs of the organisation.

• Relational databases: Organise data into tables with defined relationships. They suit structured records such as student, patient or payroll data.
• NoSQL databases: Handle unstructured or rapidly changing data such as social media posts or product reviews on an online shop.
• Distributed databases: Store data across several locations while appearing as one database, which suits an organisation with many branch offices.
• Cloud databases: Hosted on a cloud platform, providing scalability for small businesses that do not want to maintain their own servers.
• In-memory databases: Keep data in the computer's main memory for very fast processing, used where large numbers of transactions must be handled quickly.

Importance of databases in the workplace

• Efficient storage and retrieval: Large volumes of data can be stored compactly and found quickly, which is critical for daily operational workflows.
• Data integrity and consistency: Validation rules and relationships ensure accurate reporting, for example in examination results.
• Controlled multi-user access: Permissions let many staff work on the same data while limiting what each person may see or change.
• Basis for decision-making: Stored data can be summarised and analysed, helping managers plan budgets, stock and staffing.
• Security and backup: Access controls and regular backups protect data from theft, loss and system failure.

3.1.2 Collection of User requirements

Gathering user requirements is the process of understanding what database users need from the system to perform their tasks effectively. For ICT Technicians in Kenya, this step ensures that the database design fits practical workflows and meets compliance demands, such as those of the Data Protection Act. For example, before building a library database, the technician must learn from the librarian what must be recorded about books and borrowers, and which reports are needed at the end of each term.

Importance of user requirement collection

• Meets real needs: Ensures the database does what users actually require, reducing the cost of redesign later.
• Identifies data flow: Helps to define the data input, processing and output requirements of the system.
• Supports compliance: Facilitates compliance with legal and organisational policies on handling personal data.
• Allows prioritisation: Enables features to be ranked according to the needs of different user roles.
• Reduces misunderstanding: Minimises gaps between what developers build and what users expect.

Methods of collecting user requirements

• Interviews: One-on-one discussions with users to gather detailed needs. An interview with the school bursar, for instance, reveals exactly how fee balances are calculated.
• Questionnaires: Structured forms used to collect data from a large user base, useful in institutions with many departments.
• Observation: Watching users interact with the current system or manual process to identify pain points, such as a clerk copying the same details onto three registers.
• Workshops: Group sessions that bring stakeholders together to discuss and agree requirements collaboratively.
• Document analysis: Reviewing existing forms, registers and reports to understand which data is already collected and how it is used.

Key elements to capture

• Data handled: The types of data users input, update and query, such as names, dates, amounts and codes.
• Volume and frequency: How often transactions occur and how many records are expected, which affects storage and performance planning.
• Access and security: Who may view, add, change or delete data, and what passwords or restrictions are needed.
• Outputs: The reports, screens and print formats required, for example a monthly stock summary.
• Integration: The need to exchange data with other systems such as payroll or inventory.

Challenges in requirement collection and mitigation

Each challenge below is paired with the strategy used to overcome it.

• Unclear needs: Users may have difficulty articulating what they want. Prototypes, such as sample screens or forms, help them visualise the system and clarify their needs.
• Conflicting requirements: Departments may want different things from the same system. Regular stakeholder meetings with representatives of each department allow priorities to be negotiated and conflicts resolved.
• Changing requirements: Needs evolve as work changes. Collecting requirements in stages and revisiting them through iterative feedback allows adjustments without starting again.
• Limited user availability: Busy staff may be unable to attend sessions. Flexible scheduling, such as holding interviews and workshops outside peak hours, increases participation.
• Data privacy: Requirements gathering may expose personal or confidential data. Privacy training for staff ensures compliance with the Data Protection Act and protects sensitive information during collection.

Procedure for collecting user requirements

1. Identify the stakeholders: list all user groups, such as data entry clerks, supervisors, managers and the database administrator.
2. Choose suitable methods: select interviews, questionnaires, observation, workshops or document analysis according to the number and availability of users.
3. Gather the information: carry out the chosen methods and record the answers, noting data to be stored, processes and required outputs.
4. Analyse and organise the findings: remove duplicates, group similar needs and identify conflicts between users.
5. Prepare the requirement specification: write a clear document covering data, users, access levels, reports and integration needs.
6. Validate with stakeholders: present the document and prototypes to users to confirm that it is accurate and complete.
7. Manage changes: record any later change, assess its effect and obtain approval before updating the specification.

Practical assessment requirements collection

For practical assessment, ICT Technicians should demonstrate the ability to:

• Conduct comprehensive interviews and document findings.
• Develop requirement specification documents.
• Use simulation tools to model user scenarios.
• Validate requirements with stakeholders to confirm accuracy.
• Manage changes to requirements systematically.

Chapter Summary

This chapter explored the role of a computerized database user, emphasizing the importance of gathering practical assessment requirements and conducting simulations to ensure effective database use. It began with an introduction to databases, covering key concepts, organization, relationships, and common operations essential for managing data efficiently. The process of collecting user requirements was highlighted as foundational for designing databases that meet specific needs. The chapter then discussed designing computerized database schemas, focusing on creating models such as Entity-Relationship Diagrams and relational models to structure data logically. Attention was given to creating database objects including tables, records, fields, keys, forms, queries, and reports, each playing a crucial role in database functionality. The manipulation of data was detailed through operations like inserting, retrieving, deleting, and updating records, which are fundamental for maintaining accurate and current information. Finally, the chapter covered printing various database objects, ensuring that tables, forms, queries, and reports can be effectively presented for analysis and decision-making.