| Term | Definition |
|---|---|
| Data | Raw facts, figures or symbols about people, things, events or processes that can be collected, measured and analysed. It is raw and unprocessed and has no meaning on its own · e.g. 25°C, or a person's age = 25. |
| Information | Processed and organized data that is meaningful and useful and helps in decision making · e.g. "Mary scored 25 marks in January." It is structured, organized and active. |
| Information management | The process of collecting, storing, organizing and managing information efficiently. |
| Data science | A multi-disciplinary field that uses data, algorithms and scientific methods to extract insight and knowledge from structured, semi-structured and unstructured datasets, combining computer science, statistics and machine learning to collect, clean, analyse and visualize data. |
| Data lifecycle | The stages data goes through from creation to deletion. |
| Metadata | Data about data · structured information that describes, explains, locates or otherwise makes it easier to retrieve, use or manage an information resource. |
| Information retrieval system | A system that searches and retrieves relevant information from stored data · e.g. search engines, library catalogue systems, e-commerce search. |
| Indexing | A technique used to speed up data retrieval by creating a reference (index) to data, like the index in a book. Also: the process of creating a data structure that improves search speed. |
| DDDM | Data-driven decision making · the process of making decisions based on data analysis rather than intuition. |
| Information privacy | The right of individuals or organizations to control how their data is collected, used and shared. |
| Encryption | The process of converting data into an unreadable format · e.g. plain text "Hello" → "x592@H". |
| Data masking | Hiding sensitive data · e.g. showing a card number as xxx 1234. |
| Database | A collection of interrelated data stored together with controlled redundancy to serve one or more applications in an optimal fashion, organized so that a computer program can quickly select desired pieces of information. Also: an integrated, self-describing collection of related data. |
| DBMS | A collection of related data and software programs used to define, construct, maintain and manipulate data in a database · it enables you to store, modify and extract data. E.g. SQL Server, Access, Oracle. |
| Transaction | A sequence of actions that represent a logical unit of work, transforming the database from one state to another. |
| Database model | An organizing principle that specifies a particular mechanism for data storage and retrieval. |
| Database architecture | How the database is structured · how data flows between its parts; the blueprint for storing, managing and accessing data efficiently. |
| Logical data independence | The ability to change the conceptual (logical) schema without changing the external schema or application program. |
| Physical data independence | The ability to change the physical storage scheme without changing the conceptual/logical schema. |
| Basis | Data | Information |
|---|---|---|
| What it is | Raw, unprocessed facts, figures or symbols | Processed and organized data |
| Meaning | Has no meaning on its own | Meaningful and useful |
| Purpose | The raw material, awaiting meaning | Supports decision making |
| Form | Binary digital encoded (0, 1), measured in bits, bytes, gigabytes | Structured, organized and active |
| Dependency | Independent · exists on its own | Depends on data · cannot exist without it |
| Example | 25, 28, 30 · bare marks | "Mary scored 25 marks in January" |
Data by nature: quantitative · numeric information that can be measured (weight, height, sales figures, temperature) · qualitative · descriptive information expressing characteristics or attributes (customer feedback, colour of a car, satisfaction level).
Improved decision making · ensure data accuracy and consistency · enhance efficiency · support business operation.
Banking systems managing transactions · hospital systems managing patient records · e-commerce platforms tracking orders.
| # | Stage | What happens |
|---|---|---|
| 1 | Data creation | Generation from sources · users or systems |
| 2 | Data collection | Gathering the data |
| 3 | Data storage | Saving it in databases or the cloud |
| 4 | Data processing | Cleaning and transforming |
| 5 | Data analysis | Finding patterns and trends |
| 6 | Data distribution | Sharing results with those who need them |
| 7 | Data archiving | Moving inactive data to long-term storage |
| 8 | Data deletion | Secure disposal at end of life |
Importance of the data lifecycle: ensures data quality · improves data quality and usefulness · supports compliance and security.
Examples: Netflix recommending movies · TikTok · banks detecting fraud · hospitals predicting disease.
Importance of data: data is the foundation of data science · without data, analysis is impossible.
Data collection → data processing → data analysis → interpretation → decision making → prediction.
Example: sales data shows declining product demand → decision: reduce production or improve marketing.
| Advantages of DDDM | Challenges of DDDM |
|---|---|
| More accurate decisions | Poor data quality |
| Reduced risks | Lack of skills |
| Better performance | Data overload |
| Technique | What it is · examples | Advantages | Disadvantages |
|---|---|---|---|
| Manual | Collected by humans without automation · surveys, questionnaires, paper forms, interviews, observation | Low cost and simple · flexible | Time consuming · prone to human error · difficult to scale |
| Sensor-based | Collected automatically by devices · thermometers, temperature sensors, biometric scanners, IoT, GPS | Real-time data · high accuracy · automation | Expensive · requires maintenance · may produce large data volumes |
| API-based | Collected from external systems via Application Program Interfaces · weather API, social media API, payment gateways | Fast and automated · access to large datasets · real-time updates | Requires programming knowledge · API limits/restrictions · depends on external systems |
Healthcare · patient records, disease prediction · Banking · fraud detection, transaction tracking · E-commerce · product recommendation, customer behaviour analysis · Education · student performance prediction, learning analytics · Transportation · traffic prediction, ride sharing.
| Format | Definition | Characteristics | Examples |
|---|---|---|---|
| Structured | Data organized in a fixed format, usually in tables | Rows and columns · easy to store and query · highly organized | Student records · SQL tables and a customer database · Excel spreadsheets |
| Semi-structured | Data that does not follow strict tables but has some structure | Flexible structure · uses tags or key-value pairs | JSON files · XML documents · emails |
| Unstructured | Data with no predefined format or structure | Difficult to analyse · large in volume · requires advanced tools (AI, NLP) | Videos · images · comments · audio recordings · social media posts |
{ "Name": "John", "Age": 20 } · it has keys and values, so it has some structure, but no fixed table.
| Basis | File-based storage | Database system (DBMS) |
|---|---|---|
| What it is | Data stored in separate files · text files, spreadsheets | A structured system where data is stored in tables and managed by a DBMS |
| Characteristics | Flat files (.txt, .csv) · each file independent · no central control | Centralized storage · tables of rows and columns · supports relationships (keys) |
| Advantages | Simple to use · low cost · suitable for small systems | Reduces redundancy · better data integrity · improved security · easy data retrieval · multi-user access |
| Disadvantages | Data redundancy · data inconsistency · difficult data sharing · poor security · no relationship between data | Very expensive · requires an expert or administrator · complex to manage |
Components (5): data collection · indexing system · query processor · search engine · user interface.
Retrieval process (4): user enters query → system searches indexed data → matches result → returns relevant information.
Types of retrieval: exact match (database query) · best match (search engines).
| Index | Based on |
|---|---|
| Primary index | The primary key · unique values |
| Secondary index | Non-key attributes · may have duplicates |
| Clustered index | Data stored in order |
| Non-clustered index | A separate structure pointing to the data |
Benefits of indexing: faster search · improved query performance.
Limitations of indexing: takes extra storage · slows down data updates (every insert or update must maintain the index too).
| Technique | How it works | Advantages | Disadvantages |
|---|---|---|---|
| Linear (sequential) search | All elements are checked one after another until the target is found: start at the first record, compare each value, stop when found or when the end is reached | Simple to implement · works on unsorted data | Slow for large datasets · poor time complexity |
| Index search | Uses an index to locate data without scanning all records: search the index, locate the pointer, retrieve the actual data | Much faster · efficient for large data | Requires extra storage · index maintenance overhead |
Worked example from class: search for 25 in {10, 15, 25, 30} · linear search checks 10, then 15, then 25 and stops. An index search would go straight to it.
| Structure | How it works | Advantages | Disadvantages |
|---|---|---|---|
| B-tree indexing | A balanced tree structure storing sorted data. Nodes contain multiple keys; all leaf nodes are at the same level. Search by traversing tree levels | Efficient for large datasets · balanced structure gives consistent performance · supports range queries | Complex structure · requires maintenance |
| Hashing | Uses a hash function to map a key to a specific location in memory · Hash(25) → Address 5 | Very fast look-up · good time complexity | Collision · two keys map to the same location · not suitable for range queries |
B-tree: [20]
/ \
[10] [30, 40] all leaves on one level
StudentDB| S/N | Name | MatNo | Age | Dept | Sex |
|---|---|---|---|---|---|
| 1 | John | 2025/PGD/001 | 22 | Agric Sc | M |
| 2 | Ada | 2025/PGD/002 | 24 | Economics | F |
| 3 | Rueben | 2025/PGD/003 | 30 | Maths | M |
| 4 | Eze | 2025/PGD/004 | 32 | Computer Sc | M |
| 5 | Obuchi | 2025/PGD/005 | 21 | Law | F |
SELECT Name FROM StudentDB WHERE Age >= 30;
Result: Rueben
Eze
WHERE conditionSELECT * · retrieve only the needed columnsWHERE properly · filter the data at the sourceJOIN efficiently · join Table 1 (Name, MatNo, Age, Dept, Sex) to Table 2 (State, LGA) to get the combined rowSELECT COUNT(*) FROM Table1Query optimization concept: the query optimizer chooses the best execution plan · by reducing disk access, by reducing CPU usage, and by using indexes and statistics.
| Category | Full name | What you do | Keywords |
|---|---|---|---|
| DQL | Data Query Language | Read data | SELECT |
| DML | Data Manipulation Language | Change data | INSERT, UPDATE, DELETE |
| DDL | Data Definition Language | Define structure | CREATE, ALTER, DROP |
| DCL / TCL | Data Control / Transaction Control Language | Permission and transaction | GRANT, REVOKE, COMMIT, ROLLBACK |
SELECT Name, Price
FROM Products
WHERE Category = 'iphones'
ORDER BY Price DESC
LIMIT 10;
INSERT INTO Users (Name, Email)
VALUES ('Ada', '[email protected]');
UPDATE Products
SET Price = Price * 1.1
WHERE Category = 'iphone';
SELECT … FROM … WHERE … GROUP BY … HAVING … ORDER BY … LIMIT. Writing WHERE after ORDER BY is a syntax error and an easy lost mark.Real-world applications: e-commerce · fast product search using indices · banking · quick transaction retrieval · social media · searching users.
Types of data: personal (name, age) · financial (bank details) · health records · biometric · academic.
Privacy risks: identity theft · data misuse · unauthorized access.
Regulations: GDPR (Europe) · HIPAA (healthcare) · local data protection laws (Nigeria).
| Technique | What it does |
|---|---|
| Encryption | Converts data into an unreadable format · "Hello" → "x592@H". Two types: symmetric and asymmetric |
| Access control | Restricts who can view or modify data · role-based access control and user authentication (password / biometrics) |
| Backup and recovery | Regular backups prevent data loss; recovery systems restore data after failure |
| Data masking | Hiding sensitive data · e.g. a card shown as xxx 1234 |
| Firewalls and antivirus | Protect against unauthorized access and malware |
| Threat | Control |
|---|---|
| Malware · viruses, worms, ransomware | Firewalls · block unauthorized network access |
| Phishing · fake emails to steal information | Authentication · verify user identity |
| Unauthorized access · hackers accessing systems | Authorization · define what users can access |
| SQL injection · malicious SQL commands | Update and patching · fix system vulnerabilities |
| Data breaches · exposure of sensitive data | Encryption · monitoring and auditing · track system activities |
How data masking protects sensitive information: it replaces or hides part of a sensitive value while leaving the record usable · a card number displayed as xxx 1234 still identifies the card to its owner but is useless to anyone who sees it, whether a call-centre agent, a developer testing on real data, or an attacker who obtains the screen. Unlike encryption it is not reversed for the viewer · the hidden digits are simply never shown.
| Component | Meaning |
|---|---|
| 1. Data | Any computer representation of a stored logical entity · discrete pieces of information usually formatted in a special way |
| 2. Relationship | Represents a correspondence between various elements |
| 3. Constraints | Predicates that define the correct state of the database |
| 4. Schema | Describes the organization of and relationships between the database · the design of the database |
Given Table 1 (Age, Name, MatNo), Table 2 (LGA, State), Table 3 (Religion, Country), Table 4 (PA, Sex, Height) · the schema separates the data into tables that are related because common attributes exist in a selected pair of the tables. Because of those common attributes we can combine two or more tables to get the complete data of each student. That is exactly what a JOIN does.
The DBMS is made up of (a) the database, (b) the DBMS itself, (c) the application program · what the user interacts with. Its primary goal is to provide a mechanism where data can be stored and information retrieved from the database.
User
↓
┌───────────────────────────────┐
│ Application Process │
│ ┌───────────────────────────┐ │ ┌──────────┐
│ │ Transaction Processing │─┼─────▶│ DB │
│ │ Data Management │ │ │ metadata │
│ └───────────────────────────┘ │ └──────────┘
└───────────────────────────────┘ DBS
| Service | What it does |
|---|---|
| 1. Transaction management | A transaction is a sequence of actions representing a logical unit of work, transforming the database from one state to another. On COMMIT the changes are made permanent; on ROLLBACK the transaction returns to its original state. |
| 2. Concurrency control | Coordinates database manipulation processes that operate concurrently, access shared data and can potentially interfere with one another. Its goal is to allow concurrency while maintaining consistency of the shared data. |
| 3. Recovery management | Ensures that an aborted or failed transaction does not adversely affect the database or other transactions · the database is returned to a consistent state after a failure. |
| 4. Security management | The protection of data against unauthorized access · only authorized users or administrators may reach the database. |
| 5. Language interface | Provides the languages for the definition and manipulation of data · structures created with the DDL, manipulation done with DML commands. |
| 6. Storage management | Manages the permanent storage of data. The internal schema defines how data is stored, and the storage manager interfaces with the operating system to reach physical storage. |
| 7. Data catalog management | The data catalog is a system database holding metadata · information about data, relationships, constraints and the entire schema · organized into a unified database that can itself be queried to learn the structure of the database. |
The file-based system was developed in response to industry's need for more efficient data access, but it has three named limitations · this is a standard exam question:
Applications of a database (7): purchasing from the supermarket · using credit cards · booking a vacation with a travel agent · a computerized library system · using the internet · taking out insurance · renting a video.
A database model is an organizing principle that specifies a particular mechanism for data storage and retrieval. The primary difference between models lies in the methods of expressing relationships and constraints among the data elements. The relational model is the current favoured model, while object-oriented and structured models are emerging.
| # | Model | How it organizes data | Advantages | Disadvantages |
|---|---|---|---|---|
| 1 | Hierarchical | Organizes data elements as tabular rows, one per instance of an entity, in a tree: parent → child. E.g. a company's GM above departmental managers | Simple · has data security and integrity · efficient (not complicated) · fast access | Implementation complexity · database management problems · lack of structural independence · programming complexity · implementation limitation · rigid, difficult to modify |
| 2 | Network | Replaces the hierarchical tree with a graph, allowing more general connections among nodes. Its defining difference is the many-to-many (n-n) relationship · records may have more than one parent | Conceptual simplicity · handles more relationship types · ease of data access · data integrity and independence · database standards | System complexity · absence of structural independence |
| 3 | Relational | Stores data in tables. Powerful because it requires few assumptions about how data is related or extracted, so the same database can be viewed in different ways and a single database can be spread across several tables. Each table corresponds to an entity, each row to an instance | Simple and widely used · easy querying with SQL · flexible views | Less flexible for very complex data |
| 4 | Object oriented | Data stored as objects, as in programming | Handles complex data | Complex implementation |
| 5 | Semi-structured | A flexible model using formats like JSON and XML | Adaptable · used in modern web systems | Weaker guarantees than a fixed schema |
Also named in the notes: the object-relational model and the deductive model.
Book ──── 1:1 ──── Distributor given a book, its distributor is determined Book ──── n:1 ──── Distributor what books does this distributor supply? Book ──── n:n ──── Distributor combines both; readable from either side
The notes use this to make one point: the same real-world relationship can be depicted in several ways, and the model you choose decides which questions are cheap to answer.
General Manager
┌───────────┬────────────┬──────────┐
Sales Treasury Supply Accounts
Manager Manager Manager Manager
└───────────┴────────────┴──────────┘
Departments
Note the sentence the notes give for why the hierarchical model fell out of use: many of its limitations result from its overly restrictive view of relationships · a child may have only one parent, which real data often violates. That is precisely the gap the network model's n-n relationship was invented to fill.
Used in most RDBMS · Postgres, MySQL, Oracle. Database architecture is how the database is structured · how data flows between its parts; the blueprint for storing, managing and accessing data efficiently.
| Level | What it holds |
|---|---|
| 1. External / View | The area or angle the users see · views, reports, app interfaces. The user cannot see the whole database; complexity is hidden and security is added |
| 2. Conceptual / Logical | DBMS independent; where the DBA works. It holds the "what" · tables, relationships, constraints and schemas |
| 3. Internal / Physical | How data is stored · files, indices, data blocks, partitions, on disk or SSD |
Types of database architecture: client–server · three-tier.
┌──────────────────────────────┐ │ EXTERNAL views · reports │ ← what users see ├──────────────────────────────┤ │ CONCEPTUAL tables · relations│ ← what the DBA designs ├──────────────────────────────┤ │ INTERNAL files · indices │ ← how it is stored └──────────────────────────────┘
| Independence | Definition | Class example |
|---|---|---|
| Logical data independence | The ability to change the conceptual (logical) schema without changing the external schema or application program | You add a new column Middle-Name to the Customers table. If the application, running SELECT First-Name, Middle-Name FROM Customers_Table, keeps working, the database is logically independent |
| Physical data independence | The ability to change the physical storage scheme without changing the conceptual/logical schema | You move Customers_Table from HDD to SSD. If the application keeps working, you have physical independence |
Middle-Name at the conceptual level, and programs using SELECT First-Name FROM Customers_Table are unaffected. Independence fails only where an application depends on the schema's shape rather than on named columns · the classic case being SELECT *, which silently starts returning an extra column, or code that reads fields by position. That is the strongest single argument for avoiding SELECT * in application code, and it ties this question straight back to the efficient-query techniques in §6.
| Sector | Data collected | Applications used | Benefits | Challenges |
|---|---|---|---|---|
| Healthcare | Patient records (name, age, history) · medical images (X-ray, MRI) · lab results · vital signs (heart rate, blood pressure) | EHR · centralized patient data storage · CDSS · clinical decision support helping doctors diagnose · telemedicine · remote consultation · health monitoring systems · wearables | Improved patient care · faster diagnosis · reduced errors | Data privacy concerns · high system cost · integration issues |
| Finance | Transaction records · customer profiles · credit history · market data (stock monitoring) | Online banking systems · fraud detection systems · risk management systems · automated trading systems | Secure transactions · real-time processing · better financial decisions | Cyber security, threats and regulatory compliance |
| Logistics | Shipment details · inventory levels · delivery routes · GPS tracking | Supply chain management · inventory management · route optimization · warehouse management | Efficient delivery · reduced cost · real-time tracking | Data integration · system complexity |
| Social media | User profiles (text, likes, comments) · behavioural data · multimedia content | Recommendation systems · targeted advertising · content moderation · trend analysis | Personalized user experience · increased engagement · business insight | Privacy issues · misinformation · data overload |
COMMIT can be undone. COMMIT makes changes permanent; ROLLBACK is what returns the transaction to its original state.DELETE under DDL. DELETE removes rows and is DML; DROP removes the table and is DDL.