Database Systems and Information Management

Introduction

Organizations increasingly compete through their ability to collect, integrate, govern, and interpret data. Customer transactions, supply-chain events, employee records, financial postings, digital interactions, and operational sensor readings all create information assets. Yet data has little managerial value when it is duplicated, inconsistent, inaccessible, insecure, or disconnected from organizational decisions. Database systems provide the technical foundation for storing and retrieving data, while information-management practices determine how data is defined, controlled, shared, protected, and converted into business value.

For MBA managers, database knowledge is not limited to writing queries. It supports decisions about enterprise architecture, analytics investment, data ownership, regulatory compliance, business-process redesign, and the risks associated with poor information quality. This chapter examines relational and NoSQL databases, data modelling, SQL fundamentals, data warehouses and data lakes, master data management, data-quality controls, and information-governance principles.

Learning Objectives

By the end of this chapter, the reader should be able to:

1. Explain the purposes and operating principles of relational and NoSQL database systems.
2. Develop conceptual, logical, and physical data models using entities, attributes, keys, and relationships.
3. Interpret and construct fundamental SQL statements.
4. Distinguish operational databases, data warehouses, data lakes, and lakehouses.
5. Explain master data management and assess data-quality dimensions.
6. Apply governance, security, privacy, and accountability principles to organizational data.
7. Evaluate database choices and information-management controls in a managerial context.

1. Database Systems as Organizational Infrastructure

A database is an organized collection of related data managed so that authorized users and applications can store, retrieve, update, and protect it. A database management system (DBMS) is the software layer that provides these capabilities. A DBMS normally manages data definition, transaction processing, concurrency, recovery, access control, metadata, and query execution.

A database system includes more than tables and software. It comprises data, the DBMS, applications, users, procedures, infrastructure, metadata, and governance arrangements. This broader view matters because a technically sophisticated DBMS cannot compensate for ambiguous data definitions or weak accountability.

Operational systems are optimized for frequent, relatively small transactions such as creating an order, recording a payment, or changing an address. Analytical systems are optimized for scanning and aggregating large volumes of historical data. Confusing these purposes can damage performance: complex management reports may slow down the system responsible for processing customer orders.

Transactions and ACID properties

A transaction is a logically coherent unit of work. In a banking transfer, for example, debiting one account and crediting another should be treated as one operation. Traditional relational systems commonly support ACID properties:

• Atomicity: all parts of a transaction occur, or none occur.
• Consistency: a committed transaction leaves the database satisfying defined rules, such as referential and domain constraints.
• Isolation: concurrent transactions do not produce unacceptable interference.
• Durability: committed results survive failures, normally through logging and recovery mechanisms.

ACID does not mean that every possible business rule is automatically enforced. It means that the DBMS provides a framework for reliable transactions; designers must still define appropriate constraints and processes.

Distributed systems often face a trade-off between strong consistency, availability, and tolerance of network partitions. NoSQL systems may therefore offer tunable or eventual consistency for workloads where rapid availability and horizontal scaling are more important than immediate uniform visibility of every update. The correct choice depends on business risk, not on fashion.

2. Relational Database Concepts

The relational model represents data as relations, commonly implemented as tables. A table consists of rows, called tuples, and columns, called attributes. Each attribute has a domain, such as integer, date, currency, or a controlled set of status values.

Consider the following simplified relations:

CUSTOMER(CustomerID, CustomerName, Segment)

ORDER(OrderID, CustomerID, OrderDate, Status)

ORDER_LINE(OrderID, ProductID, Quantity, UnitPrice)

A primary key uniquely identifies each row. CustomerID is the primary key of CUSTOMER, while CustomerID in ORDER is a foreign key referencing CUSTOMER. A foreign key expresses referential integrity: an order should not refer to a customer who does not exist, unless a deliberate business rule allows an unknown customer record.

Relationships are commonly classified as:

• One-to-one: one employee has one personnel profile.
• One-to-many: one customer places many orders.
• Many-to-many: many orders contain many products. This is normally implemented through an associative table such as ORDER_LINE.

Relational databases are effective when data has stable structure, relationships are important, and transactions require strong integrity. They support declarative querying: the user specifies what data is required, while the DBMS determines an execution plan.

Normalization

Normalization is a design technique for reducing unnecessary redundancy and update anomalies. In an unnormalized order table, customer name and address might be repeated on every order line. If the address changes, many rows must be updated, creating opportunities for inconsistency.

The main practical forms are:

• First Normal Form (1NF): each field contains an atomic value and repeating groups are separated.
• Second Normal Form (2NF): the table is in 1NF and every non-key attribute depends on the whole primary key, particularly relevant to composite keys.
• Third Normal Form (3NF): the table is in 2NF and non-key attributes do not depend transitively on other non-key attributes.

Normalization is not an absolute objective. Analytical systems often deliberately denormalize data to improve query simplicity and speed. Managers should distinguish the normalized design of transaction systems from dimensional designs used for reporting.

3. NoSQL Database Concepts

NoSQL refers broadly to non-relational database approaches designed to support flexible schemas, large-scale distribution, high throughput, or data structures that do not fit naturally into normalized tables. NoSQL is not a single technology. Major categories include:

A document database might store a customer and selected preferences in one document. This can reduce joins and support rapid application development, but duplicated data may become difficult to update consistently. A graph database represents relationships directly, making it useful where paths and networks are central to the question. A key-value system is highly efficient when applications already know the key required for retrieval, but it is less suitable for complex ad hoc queries.

NoSQL systems often use denormalization, partitioning, replication, and horizontal scaling across commodity or cloud infrastructure. Their flexibility is valuable when data structures evolve rapidly, but “schema-less” does not mean “structure-free.” The schema may be enforced by application code, validation rules, contracts, or governance processes. Without such controls, data drift can make analysis unreliable.

A practical selection framework asks:

1. Are relationships and multi-record transactions central?
2. Is the workload transactional, analytical, streaming, or content-oriented?
3. How predictable is the data structure?
4. What latency, throughput, availability, and recovery requirements exist?
5. Can the organization govern multiple technologies and skill sets?
6. What privacy, audit, portability, and vendor-dependence risks arise?

Many enterprises use polyglot persistence: different database technologies are selected for different workloads, with integration and governance becoming essential.

4. Data Modelling

Data modelling translates business meaning into a structured representation that can be implemented in a database. It is a communication activity as well as a technical one. Business managers should participate because terms such as “customer,” “active account,” and “revenue” frequently have competing definitions.

Levels of modelling

Conceptual modelling identifies major entities and relationships without implementation detail. Examples include Customer, Product, Supplier, and Order.

Logical modelling specifies attributes, identifiers, cardinalities, optionality, and normalization, while remaining relatively independent of a particular DBMS.

Physical modelling defines tables, data types, indexes, partitions, storage arrangements, and platform-specific implementation decisions.

An entity-relationship model describes entities, attributes, and relationships. Cardinality states how many instances may participate. For example, a customer may place zero or many orders, while every order must normally belong to exactly one customer. Optionality is important: a customer may have no order, but an order without a customer may violate policy.

Keys and constraints

A candidate key is any minimal attribute set that uniquely identifies a row. One candidate key is selected as the primary key. A surrogate key is an artificial identifier, such as an integer or universally unique identifier, whereas a natural key has business meaning, such as a national registration number. Surrogate keys can provide stability when business identifiers change, but they do not eliminate the need to control natural-key duplication.

Important constraints include:

• NOT NULL: a value is mandatory.
• UNIQUE: duplicate values are prohibited within a column or column combination.
• CHECK: values must satisfy a condition, such as quantity > 0.
• PRIMARY KEY: uniquely identifies each record and cannot be null.
• FOREIGN KEY: restricts references to valid parent records.

Good models also record metadata: definitions, owners, source systems, permitted values, sensitivity classification, retention period, and transformation rules.

5. SQL Fundamentals

Structured Query Language (SQL) is the dominant language for relational databases. It includes data definition, manipulation, querying, transaction control, and authorization capabilities.

Data definition and manipulation

A simplified table definition is:

CREATE TABLE Customer (
    CustomerID INTEGER PRIMARY KEY,
    CustomerName VARCHAR(100) NOT NULL,
    Segment VARCHAR(30),
    CONSTRAINT valid_segment CHECK (Segment IN ('Retail', 'Business'))
);

Records can be added or changed with INSERT, UPDATE, and DELETE. Updates should normally include a carefully tested WHERE clause. In production environments, transactions, backups, approval controls, and change logs reduce the risk of unintended mass modification.

A basic query is:

SELECT CustomerID, CustomerName
FROM Customer
WHERE Segment = 'Business'
ORDER BY CustomerName;

WHERE filters rows before presentation. GROUP BY forms groups, while aggregate functions such as COUNT, SUM, AVG, MIN, and MAX summarize values. HAVING filters groups after aggregation.

SELECT CustomerID, SUM(Quantity * UnitPrice) AS CustomerValue
FROM OrderLine
GROUP BY CustomerID
HAVING SUM(Quantity * UnitPrice) > 10000;

The exact query requires a suitable relationship between orders and order lines; a production design would join the relevant tables.

Joins

A join combines rows using a related condition:

SELECT c.CustomerName, o.OrderID, o.OrderDate
FROM Customer AS c
JOIN Orders AS o
  ON c.CustomerID = o.CustomerID
WHERE o.Status = 'Completed';

An inner join returns matching rows. A left outer join returns all rows from the left table and matching rows from the right, with nulls where no match exists. The choice affects managerial interpretation. For example, a left join is necessary to identify customers who have never placed an order; an inner join would silently exclude them.

Query quality and security

SQL injection occurs when untrusted input is concatenated into executable SQL. Parameterized queries or prepared statements should be used instead. Least-privilege database accounts, input validation, encryption, auditing, and separation of development and production environments are complementary controls.

Query performance depends on data volume, indexes, join conditions, statistics, and execution plans. Indexes can accelerate retrieval but impose storage and update costs. Managers should evaluate performance using workload evidence rather than adding indexes indiscriminately.

6. Data Warehouses, Data Lakes, and Lakehouses

A data warehouse is a curated repository designed primarily for reporting and analysis. It normally integrates data from multiple operational sources, preserves historical states, applies business rules, and provides consistent dimensions and measures. Extract-transform-load (ETL) transforms data before loading; extract-load-transform (ELT) loads data first and transforms it within a scalable analytical platform.

A common warehouse design is the star schema. A central fact table stores measurable events, such as sales amount and quantity, while dimension tables describe customers, products, dates, and locations. The grain must be explicit: for example, “one row per product per order line.” If the grain is unclear, totals may be double-counted.

A data lake stores large volumes of raw or lightly processed structured, semi-structured, and unstructured data. It supports exploratory analytics, machine learning, and future uses not fully known at collection time. Its advantages include flexibility and low-cost scalable storage. Its risks include unclear ownership, duplicated data, weak metadata, privacy exposure, and becoming a “data swamp.” Catalogues, lineage, access controls, retention policies, and quality checks are therefore essential.

A lakehouse seeks to combine the flexible storage of a lake with warehouse-like management, governance, transaction support, and analytical performance. The label describes an architectural pattern rather than a universal product or guaranteed outcome.

Data pipelines should include profiling, validation, transformation, reconciliation, monitoring, error quarantine, and lineage. A dashboard is only as trustworthy as the pipeline and definitions beneath it.

7. Master Data Management

Master data management (MDM) is the organizational and technical discipline of creating, maintaining, and distributing authoritative records for core entities such as customers, products, suppliers, locations, and legal entities. Master data differs from transaction data: “Customer” is a master entity, while “Order 84721” is a transaction involving that entity.

MDM addresses the problem that different systems may represent the same entity differently. One application may store “ABC Ltd,” another “A.B.C. Limited,” and a third may use an outdated address. MDM establishes identity resolution, survivorship rules, stewardship, reference data, and distribution mechanisms.

Common MDM styles include:

• Registry: links records across systems while leaving source data in place.
• Consolidation: collects and reconciles records into a central analytical view.
• Coexistence: maintains a central master while allowing controlled updates in source systems.
• Centralized: makes the master hub the authoritative point for creation and change.

A governance process may define who can create a supplier, how duplicates are matched, which source wins when attributes conflict, how exceptions are reviewed, and how changes are propagated. MDM is therefore not merely a software installation; it requires policy, stewardship, process redesign, and executive sponsorship.

8. Data Quality and Information Governance

Data quality is fitness for intended use. Common dimensions include:

• Accuracy: data correctly represents the real-world object or event.
• Completeness: required values are present.
• Consistency: the same value or rule does not conflict across records or systems.
• Timeliness: data is available and current when needed.
• Validity: values conform to format, domain, and business rules.
• Uniqueness: entities are not unnecessarily duplicated.
• Integrity: relationships and dependencies remain valid.

Quality can be measured with explicit denominators. For example, if 9,700 of 10,000 mandatory customer records contain a valid email address, completeness for that field is:

This metric assumes that “valid email address” has been defined operationally and that the denominator includes only records for which the field is genuinely required. A high percentage does not prove that the addresses are accurate or current.

Quality controls operate at several points: entry validation prevents errors; application controls enforce workflow rules; batch profiling identifies anomalies; reconciliation compares totals between systems; exception queues enable correction; and monitoring detects drift. Root-cause analysis is preferable to repeatedly correcting symptoms. If product codes are frequently invalid, the organization should examine the interface, master-data process, and training rather than merely reject individual records.

Information governance is the framework of decision rights, policies, standards, roles, and controls governing data throughout its lifecycle. Typical roles include:

• Data owner: accountable for business meaning, risk, and access decisions.
• Data steward: manages definitions, quality issues, and operational adherence.
• Data custodian: operates the technical environment and security controls.
• Data consumer: uses data according to approved purposes and conditions.

Governance should address classification, access, retention, archival, deletion, lineage, quality, sharing, incident response, and change management. A policy without monitoring and consequences is unlikely to change behavior.

Privacy, security, and ethics

Data governance must reflect applicable privacy and sector regulations. Core principles include purpose limitation, data minimization, lawful and transparent processing, retention limitation, accuracy, security, and accountability. Sensitive data should be classified and access should follow least privilege and need-to-know principles.

Controls may include encryption in transit and at rest, strong authentication, role-based access, segregation of duties, masking, tokenization, audit logs, backup testing, vulnerability management, and incident response. Governance also requires ethical judgment. A database may technically permit combining datasets, but combining them may create unjustified surveillance, discriminatory profiling, or re-identification risk.

Artificial intelligence increases the importance of lineage and quality. Models trained on duplicated, biased, stale, or unlawfully collected data can produce systematically harmful outputs. Organizations should document data provenance, assess representativeness, test for bias, restrict sensitive attributes where appropriate, and maintain human accountability for consequential decisions.

9. Illustrative Case: Meridian Retail Group

Background

Meridian Retail Group operates physical stores and an online channel. Its order-processing system uses a relational database, while the online recommendation service uses a document database. Marketing maintains separate customer spreadsheets, and the finance warehouse receives nightly extracts.

Problem

Management reports disagree about customer counts and revenue. The same customer appears under several names, cancelled orders are treated inconsistently, and the warehouse contains duplicate product records. A campaign also exposed an outdated customer email address, leading to complaints about privacy and trust.

Analysis

The organization has an integration and governance problem rather than simply a reporting problem. Customer and product are master entities, but no authoritative definitions or stewardship roles exist. The operational database is appropriate for order transactions, whereas the warehouse requires explicit revenue and order-status rules. The recommendation database can remain document-oriented, but it needs controlled identifiers linked to the master customer record.

Approach and solution

Meridian establishes a data council chaired by the chief operating officer. Business owners define “active customer,” “completed sale,” and “net revenue.” A customer master service assigns a stable identifier and applies matching rules using approved attributes. Suspected duplicates are placed in a steward review queue rather than automatically merged when confidence is low.

The warehouse is redesigned with a documented sales fact grain of one row per completed order line. A calendar dimension and governed product and customer dimensions support consistent reporting. Pipeline controls reconcile daily order counts and monetary totals to the operational system, while failed records are quarantined and investigated. Access to personal information is restricted, campaign exports are logged, and retention rules are applied.

Outcome

The organization obtains a consistent customer count, traceable revenue measures, and a controlled process for correcting duplicates. Marketing can still use analytical segments, but only approved attributes are exported. The recommendation service continues to use a document model, demonstrating that governance and identifiers can integrate different database technologies.

Learning points

1. Database selection should follow workload requirements.
2. Common definitions are as important as technical integration.
3. MDM requires people, policies, and processes in addition to software.
4. Data-quality metrics need explicit rules and denominators.
5. Privacy and governance controls must be designed into data flows, not added after incidents.

10. Managerial Decision Framework and Best Practices

Managers evaluating a database initiative should begin with business capabilities and risk. They should document workload characteristics, data sensitivity, growth, availability targets, recovery requirements, integration needs, and user skills. Total cost includes licensing, cloud consumption, engineering, migration, training, monitoring, security, and exit costs.

A robust implementation generally follows these practices:

1. Define business terms and ownership before building dashboards.
2. Model data at the appropriate conceptual, logical, and physical levels.
3. Select relational, NoSQL, or combined technologies according to workload evidence.
4. Make transaction boundaries, data grain, keys, and constraints explicit.
5. Separate operational processing from heavy analytical workloads where necessary.
6. Implement lineage, cataloguing, quality checks, and exception management.
7. Apply least privilege, encryption, retention, and tested recovery procedures.
8. Monitor service performance and data quality continuously.
9. Design for portability and document vendor-specific dependencies.
10. Review governance effectiveness through measurable outcomes, not policy volume.

Important limitations remain. Normalization can increase join complexity; denormalization can create update problems. NoSQL flexibility can create inconsistent structures. Warehouses may encode historical assumptions that later prove wrong. Lakes can accumulate inaccessible or sensitive data. Automated matching and AI-based quality controls can produce false positives and false negatives. All designs therefore require ongoing review, transparent assumptions, and accountable human oversight.

Chapter Summary

Database systems are core organizational infrastructure for reliable transactions, integration, analysis, and decision-making. Relational databases organize structured data through tables, keys, relationships, constraints, and SQL; they are especially suitable where integrity and multi-record transactions are central. NoSQL databases provide document, key-value, wide-column, and graph models that support flexible structures and distributed workloads, but they still require deliberate schema and governance controls.

Data modelling progresses from conceptual entities and relationships to logical keys and constraints and finally to physical implementation. SQL supports definition, manipulation, filtering, joining, aggregation, and controlled access. Data warehouses provide curated historical analysis, while data lakes provide flexible storage for varied data; lakehouse architectures seek to combine advantages of both.

Master data management establishes authoritative identities and definitions for core entities. Data quality involves accuracy, completeness, consistency, timeliness, validity, uniqueness, and integrity. Information governance assigns decision rights and controls data throughout its lifecycle. Security, privacy, ethics, lineage, and accountability are essential because data systems affect customers, employees, markets, and public trust.

Key Terms

ACID: Transaction properties of atomicity, consistency, isolation, and durability.

Attribute: A characteristic or field describing an entity.

Data lake: Scalable repository for raw or lightly processed data in varied formats.

Data model: Representation of data entities, attributes, relationships, and constraints.

Data quality: Fitness of data for its intended purpose.

Data warehouse: Curated repository optimized for integrated historical analysis.

Database: Organized collection of related data.

DBMS: Software that manages database storage, access, integrity, and recovery.

Entity: A distinguishable real-world object or concept represented in data.

Foreign key: Attribute that references a key in another table.

Information governance: Policies, roles, rights, and controls governing organizational data.

Lakehouse: Architecture combining data-lake flexibility with warehouse-style management.

Master data: Stable core entities such as customers, products, and suppliers.

Master data management: Discipline for maintaining authoritative, consistent master records.

Normalization: Relational design process that reduces redundancy and anomalies.

NoSQL: Family of non-relational database approaches for flexible or distributed workloads.

Primary key: Attribute or attribute set that uniquely identifies a table row.

SQL: Language for defining, querying, and manipulating relational data.

Transaction: Logical unit of database work.

Review Questions

Short Answer Questions

1. What is the difference between a database and a DBMS?
2. Define a primary key and a foreign key.
3. What is the purpose of normalization?
4. Name four major categories of NoSQL databases.
5. What is master data management?

Long Answer Questions

1. Compare relational and NoSQL databases, including their strengths, limitations, and appropriate managerial applications.
2. Explain conceptual, logical, and physical data modelling and show how decisions at each level affect implementation.
3. Explain the role of SQL joins, grouping, and aggregation in management reporting.
4. Compare data warehouses and data lakes, including their architecture, users, benefits, and risks.
5. Discuss information governance, privacy, security, and ethical accountability as organizational responsibilities.

Analytical / Application Questions

1. A retailer needs real-time order processing, customer-journey analysis, and a product recommendation service. Recommend an architecture using suitable database types and justify the integration and governance controls required.
2. An organization reports 98% completeness for customer email addresses, but campaign delivery rates are falling. Diagnose why the completeness metric may be insufficient and propose additional quality measures and controls.
3. A multinational company has three incompatible supplier databases and frequent duplicate payments. Design an MDM and data-quality programme, identifying ownership, matching, survivorship, controls, and performance indicators.

Multiple Choice Questions with Answers

Question 1

Which property ensures that all parts of a transaction occur or none occur?

A. Atomicity

B. Consistency

C. Isolation

D. Durability

Correct Answer: A. Atomicity

Question 2

Which database model is generally most suitable for representing complex networks of relationships such as fraud connections?

A. Key-value

B. Graph

C. Document

D. Flat-file

Correct Answer: B. Graph

Question 3

What is the principal purpose of a foreign key?

A. To sort rows alphabetically

B. To encrypt a table

C. To enforce a relationship with another table

D. To calculate aggregate values

Correct Answer: C. To enforce a relationship with another table

Question 4

Which SQL clause filters groups after aggregation?

A. WHERE

B. ORDER BY

C. FROM

D. HAVING

Correct Answer: D. HAVING

Question 5

A data warehouse is primarily designed for:

A. High-volume analytical reporting

B. Replacing all application code

C. Storing only unstructured media

D. Managing employee passwords

Correct Answer: A. High-volume analytical reporting

Question 6

Which dimension of data quality concerns whether values conform to defined formats and rules?

A. Timeliness

B. Validity

C. Uniqueness

D. Availability

Correct Answer: B. Validity

Question 7

What is the main purpose of master data management?

A. To eliminate all transaction records

B. To create authoritative and consistent records for core entities

C. To replace every relational database with a graph database

D. To increase duplicate customer records

Correct Answer: B. To create authoritative and consistent records for core entities

Question 8

If 9,700 of 10,000 required records contain a valid value, the completeness rate is:

A. 9.7%

B. 70%

C. 97%

D. 99.7%

Correct Answer: C. 97%

Question 9

Which approach best reduces SQL-injection risk?

A. Concatenating user input into SQL strings

B. Using parameterized queries

C. Removing all database indexes

D. Allowing every user administrative access

Correct Answer: B. Using parameterized queries

Question 10

Which role is primarily accountable for business meaning, risk, and access decisions concerning data?

A. Data owner

B. Data consumer

C. Network technician

D. External auditor only

Correct Answer: A. Data owner