23-Ind-B4 Design of Information Systems · December 2017
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams — December 2017 — 98-Ind-B4, Design of Information Systems. 3 hours; closed book, no calculator permitted. The exam comprises four parts: Part A (select 20 terms from the list given and explain each in a sentence or two, no more than 50 words, 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 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.
A database management system provides three core capabilities regardless of the underlying data model. Data definition lets a designer specify the database's structure — its tables or collections, the fields/columns and data types within each, keys, and integrity constraints — turning a conceptual schema (Question 1, term 23) into an enforced physical structure the DBMS itself polices. The data dictionary is the DBMS's own repository of metadata: the definitive, automatically maintained record of every table/collection, field, data type, and relationship, letting developers and analysts look up what a piece of data means and how it is structured without reverse-engineering it from application code. Data manipulation lets users and applications retrieve, add, modify, and remove data through a defined language rather than custom low-level file-handling code — in a relational system this is declarative SQL: the user states what data is wanted and the DBMS's own query optimizer determines how to retrieve it efficiently.
A Relational DBMS (RDBMS — e.g., Oracle, SQL Server, PostgreSQL, MySQL) organizes data into two-dimensional tables of rows and columns, with a rigid, pre-declared schema enforced at write time (every row must have every declared column, of the declared type, and must satisfy any declared constraint). Data query/manipulation uses SQL, a mature, standardized declarative language supporting complex multi-table joins, aggregation, and transactions with strong ACID (atomicity, consistency, isolation, durability) guarantees. Data definition is explicit and centralized: DDL statements (CREATE TABLE, foreign-key constraints) fix the structure before data is loaded, and normalization (Question 1, term unrelated but same discipline) minimizes redundancy. The data dictionary is comprehensive and tightly integrated — because the schema is fixed and explicit, the dictionary can describe every table, column, and relationship with certainty.
Non-relational systems (document stores like MongoDB, key-value stores like Redis, column-family stores like Cassandra, graph databases like Neo4j) instead organize data in a form matched to a specific access pattern, and typically use a flexible or "schema-less" data definition: individual records (documents) can carry different fields from one another, and structure can evolve without a formal schema-migration step, which suits rapidly changing or highly variable data (e.g., product catalogues with wildly different attributes per category). Data query/manipulation is typically simpler and more limited than SQL — key-based lookups, document queries, or graph traversals — optimized for very high-volume, low-latency reads/writes at the cost of the rich ad-hoc multi-entity joins SQL supports natively; many NoSQL systems also relax ACID guarantees in favour of horizontal scalability across many commodity servers (the "eventual consistency" trade-off). The data dictionary concept is correspondingly weaker or absent: because structure is not centrally declared, there is no single authoritative schema description to maintain — documentation of "what fields exist" instead lives in application code or a separately maintained convention, which raises the risk of silent, undocumented drift.
The relational model's rigid schema and rich query language suit data whose structure is well understood and stable and where complex, ad-hoc cross-entity queries and strong consistency (e.g., financial transactions) matter most. The non-relational model's flexible schema and horizontal scalability suit data whose structure varies or evolves quickly, whose volume or velocity exceeds what a single relational server can efficiently handle, and where the access pattern is narrow and well known in advance (e.g., session storage, a social graph, sensor time-series). Many modern architectures use both together — a relational system for transactional core data and a non-relational system for a specific high-volume workload — rather than treating the choice as all-or-nothing.
