NivaarExam PrepOfficial exam papers ↗

23-Ind-B4 Design of Information Systems · December 2013

Question 4 of 13: Core Capabilities of a DBMS

Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)

Notes on this paper

National Exams — December 2013 — 98-Ind-B4, Design of Information Systems. 3 hours; closed book, no calculator permitted. The exam comprises four parts: Part A (select 20 of 40 terms and explain each in a sentence or two, 2 marks each = 40 marks), Parts B and C (select 2 of 5 questions in each part, 11 marks each = 22 marks per part), and Part D (select 1 of 2 questions, 16 marks). Complete answers to every term and every question in all four parts follow below, not only the minimum selection a candidate would submit on exam day.

Reference texts: Laudon & Laudon, Management Information Systems: Managing the Digital Firm, 15th ed.; Schwalbe, Information Technology Project Management, 9th ed.

Question 4 (Part B.3): Core Capabilities of a DBMS (11 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Data Definition

A DBMS provides a Data Definition Language (DDL, e.g., SQL's CREATE/ALTER/DROP statements) that lets a database designer specify the database's structure: its tables, the columns and data types within each table, primary and foreign keys, integrity constraints (e.g., NOT NULL, uniqueness), and indexes. This capability turns the conceptual schema (Question 1, term 18) into an enforced physical structure the DBMS itself will police, so a large share of data-quality enforcement (e.g., "an order must reference a real customer") happens automatically at the database layer rather than being re-implemented in every application that touches the data.

Data Dictionary

The data dictionary is the DBMS's own repository of metadata — the definitive record of every table, column, data type, constraint, relationship, and often the business meaning and ownership of each data element, automatically maintained as the schema is created and altered. It lets developers, analysts, and database administrators look up exactly what a piece of data means and how it is structured without having to reverse-engineer it from application code, and it is the mechanism that keeps naming and definitions consistent across every application that shares the same database — a single "Customer ID" definition instead of a different, incompatible one in every system.

Data Manipulation Language

A Data Manipulation Language (DML, most commonly SQL's SELECT, INSERT, UPDATE, and DELETE) lets users and applications retrieve, add, modify, and remove data without writing custom low-level file-handling code. Critically, SQL is declarative: the user specifies what data they want (e.g., "all orders over $1,000 placed this month"), and the DBMS's own query optimizer determines how to retrieve it efficiently, which is what makes ad-hoc, non-programmer querying and reporting practical.

Why These Capabilities Matter Together

Together, these three capabilities are what let a DBMS separate data from the applications that use it: data definition establishes and enforces one authoritative structure, the data dictionary documents what that structure means, and the DML provides one consistent way for any authorized application or user to access it. This is the foundation on which multi-user concurrency control, backup/recovery, and security (access control, Question 1's term 1) are all built, and it is why an organization runs one shared DBMS rather than letting every application maintain its own private data files.