Free Data Management Foundations Practice Test Questions and Answers (2026)

A FULL JOIN, also known as a FULL OUTER JOIN, is used to retrieve all records from both the left (table1) and the right (table2) tables. It combines the functionality of both LEFT JOIN and RIGHT JOIN. If there are rows in one table that do not have a match in the other, the result set will include those rows and fill the columns from the non-matching table with NULL values. This ensures that every row from both participating tables is represented in the final output, regardless of whether a match is found based on the join predicate.

B. Outer Join: This is a general category that includes LEFT, RIGHT, and FULL joins. It is not the specific type that guarantees all rows from both tables are returned.

C. Inner Join: This join returns only the rows where the join condition is met in both tables, explicitly excluding rows that do not have a match.

D. Cross Join: This join produces a Cartesian product, which is a result set where each row from the first table is combined with every row from the second table, without a join condition.

---

1. PostgreSQL 16 Documentation. (2023). 7.2.2. Joins Between Tables. "Finally, a FULL OUTER JOIN... returns all the joined rows, plus one row for each unjoined row from the left table (extended with nulls on the right), plus one row for each unjoined row from the right table (extended with nulls on the left)."

Source: PostgreSQL Documentation

2. Microsoft SQL Server Documentation. (2023). FROM clause plus JOIN, APPLY, PIVOT (Transact-SQL). In the section for FULL [ OUTER ] JOIN, it states: "Specifies that all rows from both the left and right outer input sources are returned... If a row from the left outer input source does not match any row in the right outer input source, the row from the left outer input source is returned in the result set, and output columns from the other table contain null values."

Source: Microsoft Learn

3. Stanford University. (n.d.). CS145: Introduction to Databases, Lecture Notes on Relational Algebra. The full outer join operation (⟗) is defined as the union of the left outer join and the right outer join (R ⟗ S = (R ⟕ S) ∪ (R ⟖ S)), which mathematically ensures all tuples from both relations R and S are included in the result.

Source: Stanford CS145 Course Material

A simple primary key is, by definition, a key composed of a single attribute (field or column). This is the most direct and accurate term for a primary key that consists of only one field. It stands in contrast to a composite or compound key, which is formed by combining two or more attributes to uniquely identify a record. The term "simple" specifically describes the structural composition of the key itself.

B. Partition: This term refers to database storage strategies for dividing large tables into smaller parts, not the number of fields in a primary key.

C. Stable: A stable key is one whose value does not change over time. This describes a behavioral characteristic, not its structure (single vs. multiple fields).

D. Meaningless: A meaningless (or surrogate) key is an artificial key with no business significance. This describes its semantic nature, not its composition.

1. Elmasri, R., & Navathe, S. B. (2017). Fundamentals of Database Systems (7th ed.). Pearson. In Chapter 3, Section 3.2.2, "Constraints on Relational Databases," the text distinguishes between keys formed from a single attribute (simple keys) and those formed from multiple attributes (composite keys).

2. Coronel, C., & Morris, S. (2019). Database Systems: Design, Implementation, and Management (13th ed.). Cengage Learning. Chapter 3, "The Relational Database Model," Section 3.4.1, "Keys," defines a simple key as "a key that is composed of a single attribute."

3. Ullman, J. D., & Widom, J. (2008). A First Course in Database Systems (3rd ed.). Pearson Prentice Hall. Chapter 2, "The Relational Model," Section 2.3.1, "Keys," explains that a key can consist of one or more attributes, implicitly defining a single-attribute key as the simplest form.

An aggregate function performs a calculation on a set of rows and returns a single, summary value. Common examples in SQL include COUNT(), SUM(), AVG(), MIN(), and MAX(). These functions are used to condense information from multiple rows into a single result, often in conjunction with the GROUP BY clause to create summary reports for different categories within the data. For instance, SUM(sales) would compute the total sales value across all rows in the specified group.

B. This describes a set difference operation, such as EXCEPT or MINUS, which is used to find distinct rows in one query result that are not present in another.

C. This describes projection, the process of selecting specific columns to be returned in a result set, which is the fundamental purpose of the SELECT clause itself.

D. This describes a JOIN operation (specifically a CROSS JOIN if no condition is specified), which is used to combine rows from two or more tables.

1. PostgreSQL 16 Documentation, Chapter 9: Functions and Operators, Section 9.21: Aggregate Functions. The documentation states, "Aggregate functions compute a single result from a set of input values." This directly supports the definition that they operate over a set of rows.

2. Oracle Database SQL Language Reference, 23c, Chapter 7: SQL Functions, "Aggregate Functions". The official documentation explains, "Aggregate functions return a single result row based on groups of rows, rather than on single rows." This confirms that their purpose is to compute a value over a set of rows.

3. Silberschatz, A., Korth, H. F., & Sudarshan, S. (2020). Database System Concepts (7th ed.). McGraw-Hill. Chapter 4, "Intermediate SQL", Section 4.1 "Aggregate Functions", p. 135. The text introduces aggregate functions by stating they "take a collection (a set or multiset) of values as input and return a single value."

Information independence, more commonly known as data independence, is a core concept in database systems that allows for the modification of the database schema at one level without altering the schema at a higher level. This principle is a primary goal of the three-schema architecture. It enables changes to the logical or physical organization of data—such as adding a new field, splitting a table, or changing storage structures—without requiring changes to the application programs or user views that rely on that data. This separation significantly reduces maintenance costs and improves system flexibility.

A. An ability to change database type is a system migration or re-architecture effort, not the definition of data independence within a system.

B. An ability to make changes to existing queries is an application development task; data independence aims to protect queries from underlying data changes.

C. An ability to interchange databases relates to interoperability or migration, not the internal schema independence of a single database system.

---

1. Elmasri, R., & Navathe, S. B. (2017). Fundamentals of Database Systems (7th ed.). Pearson. In Chapter 2, Section 2.2, "The Three-Schema Architecture and Data Independence," the text defines logical data independence as "the capacity to change the conceptual schema without having to change the external schemas and their associated application programs" and physical data independence as "the capacity to change the internal schema without having to change the conceptual schema." This directly supports the idea of changing the data's organization.

2. Silberschatz, A., Korth, H. F., & Sudarshan, S. (2020). Database System Concepts (7th ed.). McGraw-Hill. In Chapter 1, Section 1.9, "Data Independence," it is stated: "The ability to modify a schema definition in one level without affecting a schema definition in the next higher level is called data independence." This confirms that the concept is about changing the schema (data organization).

3. Ramakrishnan, R., & Gehrke, J. (2003). Database Management Systems (3rd ed.). McGraw-Hill. In Chapter 1, Section 1.5.2, "Data Independence," the authors explain that data independence is a key advantage of a DBMS, allowing changes to the "conceptual schema... or the physical schema" without impacting applications. This aligns with changing the data's organization.

The diagram displays a relationship where instances of a single entity type, EMPLOYEE, are related to other instances of the same entity type. This is known as a unary or recursive relationship. The crow's foot notation indicates a one-to-many cardinality: one employee (in the role of a manager) can manage zero or many other employees, while an employee is managed by zero or one manager. This structure is commonly used to model hierarchies, such as organizational charts.

A. Many-to-many: This relationship would require crow's foot notation on both ends of the relationship line, which is not present in the diagram.

B. Associative entity: An associative entity is a construct used to resolve a many-to-many relationship and would be depicted as a separate entity, which is not shown here.

D. Intersection data: This refers to attributes that describe a relationship (often a many-to-many one) and are stored in an associative entity, not the type of relationship itself.

---

1. Elmasri, R., & Navathe, S. B. (2017). Fundamentals of Database Systems (7th ed.). Pearson. In Chapter 7, Section 7.2, "The Relational Data Model and Relational Database Constraints," the concept of a recursive (unary) relationship is explained using the example of an employee supervising other employees, which directly corresponds to the provided diagram.

2. Connolly, T., & Begg, C. (2015). Database Systems: A Practical Approach to Design, Implementation, and Management (6th ed.). Pearson. Chapter 16, "Conceptual Database Design Methodology," discusses relationship degrees, defining a unary (or recursive) relationship as one where an entity type is linked to itself. The "Staff manages Staff" example is used for illustration.

3. Ullman, J. D., & Widom, J. (2008). A First Course in Database Systems (3rd ed.). Prentice Hall. Chapter 4, "The Entity-Relationship Model," describes relationships that involve only one entity set, termed "recursive relationships," and provides examples such as a "married-to" relationship between people.

The MERGE statement is a standard SQL command designed to synchronize data between a source and a target table. It evaluates a condition to determine whether a row exists in the target table. Based on the outcome, it can perform an INSERT (if the row does not exist), an UPDATE (if the row exists and meets certain criteria), or a DELETE (if the row exists in the target but not the source, or meets other criteria). This consolidation of multiple Data Manipulation Language (DML) operations into a single, atomic statement is highly efficient for tasks like data warehousing and maintaining data consistency.

A. INTO: The INTO keyword is used within an INSERT statement to specify the destination table for new rows.

B. JOIN: The JOIN clause is used in SELECT, UPDATE, or DELETE statements to combine rows from two or more tables.

D. DROP: The DROP command is a Data Definition Language (DDL) statement used to delete entire database objects, such as tables.

---

1. Oracle Corporation. (2023). Oracle Database SQL Language Reference, 23c. "MERGE Statement". This official documentation states, "Use the MERGE statement to select rows from one or more sources for update or insertion into a table or view. You can specify conditions to determine whether to update or to insert into the target table or view. This statement is a convenient way to combine multiple operations. It lets you avoid multiple INSERT, UPDATE, and DELETE DML statements."

2. Microsoft Corporation. (2024). MERGE (Transact-SQL). SQL Server Documentation. In the "Remarks" section, it is stated: "Performs insert, update, or delete operations on a target table from the results of a join with a source table. For example, you can synchronize two tables by inserting, updating, or deleting rows in one table based on differences found in the other table."

3. Silberschatz, A., Korth, H. F., & Sudarshan, S. (2020). Database System Concepts (7th ed.). McGraw-Hill. In Chapter 4, "Intermediate SQL," Section 4.5, "Modifications of the Database," the text describes the MERGE statement: "The merge construct allows the combination of an insert and an update... Some database systems, such as Oracle and Microsoft SQL Server, also allow a delete clause..." (p. 153).

The standard SQL syntax for inserting a new row into a table is INSERT INTO tablename (column1, column2, ...) VALUES (value1, value2, ...);. Option B correctly follows this structure. It specifies the INSERT INTO command, the target table (Employee), the specific column to populate (Name), the VALUES keyword, and the corresponding value to be inserted ("John Doe"). Specifying the column name is a best practice, as it makes the statement independent of the column order in the table.

A. INSERT Employee { "John Doe" };

This syntax is incorrect. SQL uses parentheses () to enclose the list of values, not curly braces {}, and it is missing the mandatory INTO keyword.

C. INSERT INTO Employee ("John Doe");

This statement is missing the required VALUES keyword, which must precede the list of values being inserted into the table.

D. INSERT Employee (Name) Values ("John Doe");

This statement is missing the INTO keyword. While some database systems treat INTO as optional, it is part of the ANSI SQL standard syntax and is required for portability and clarity.

1. PostgreSQL 16 Documentation, SQL Commands, INSERT. The official documentation specifies the syntax as INSERT INTO tablename [ ( columnname [, ...] ) ] VALUES ( { expression | DEFAULT } [, ...] ). This confirms that INTO and VALUES are required keywords.

(Source: PostgreSQL Official Documentation, Chapter: "SQL Commands", Section: "INSERT")

2. Ramakrishnan, R., & Gehrke, J. (2003). Database Management Systems (3rd ed.). McGraw-Hill. In Chapter 5, "SQL: Queries, Constraints, Triggers," the basic form for insertion is defined as: INSERT INTO tablename (columnlist) VALUES (valuelist). This is a standard academic textbook for database courses.

(Source: Page 157, Section 5.2.4, "INSERT Statement")

3. Stanford University, CS 145 Introduction to Databases, Course Notes on SQL. The notes on Data Manipulation Language (DML) present the syntax for insertion as INSERT INTO R(A1, ..., An) VALUES (v1, ..., vn);, reinforcing the structure used in the correct answer.

(Source: Stanford InfoLab, SQL DML Notes)

A tangible entity represents a physical object that exists in the real world and can be perceived by the senses. These entities, such as a person, a car, or a product, are concrete and have measurable physical properties. In database modeling, a table representing EMPLOYEE or PRODUCT would be based on a tangible entity, as each record corresponds to a specific, measurable object in the real world.

A. Logical entity: A logical entity is a representation within a data model's structure; it is a component of the design, not the physical real-world object itself.

C. Virtual entity: A virtual entity is typically a data object, like a view in a database, that is derived from other entities and does not have its own persistent physical storage.

D. Conceptual entity: A conceptual (or intangible) entity represents a non-physical concept, event, or idea, such as a bank account, a course registration, or a project, which are not physical objects.

---

1. Elmasri, R., & Navathe, S. B. (2017). Fundamentals of Database Systems (7th ed.). Pearson. In Chapter 7, Section 7.2.1, the text defines an entity as a "thing" or "object" in the real world with an independent existence. It distinguishes between objects with a physical existence (e.g., a person, a car) and those with a conceptual existence (e.g., a company, a job, a university course). This directly supports the definition of a tangible entity as a physical object.

2. Coronel, C., & Morris, S. (2016). Database Systems: Design, Implementation, and Management (12th ed.). Cengage Learning. Chapter 4, "Entity Relationship (ER) Modeling," defines an entity as an object of interest to the end user. It clarifies that an entity can be tangible, such as a customer or a product, or intangible, such as a bank account or a project plan.

3. Stanford University, CS 145 Introduction to Databases Course Notes. (n.d.). Lecture 3: The Entity-Relationship Model. Retrieved from Stanford University. The course materials describe entities as real-world objects or things, distinguishing between those that are physical (e.g., students, departments) and those that are conceptual (e.g., courses, enrollments). This aligns with the distinction between tangible and conceptual entities.

A foreign key is a fundamental concept in relational databases used to establish and enforce a link between the data in two tables. It is a column, or a set of columns, in one table (the referencing table) that refers to the primary key of another table (the referenced table). This constraint ensures referential integrity, meaning that a value in the foreign key column must correspond to an existing value in the referenced table's primary key, or be NULL.

A. Super key: A super key is any set of one or more attributes that, taken collectively, uniquely identifies a record in a table. It does not define a relationship between tables.

B. Simple key: This term describes a key that consists of a single column. While a foreign key can be a simple key, this term only describes its structure, not its function of referencing another table.

C. Composite key: This term describes a key that consists of two or more columns to uniquely identify a record. Like a simple key, this describes structure, not the referential function.

---

1. Silberschatz, A., Korth, H. F., & Sudarshan, S. (2020). Database System Concepts (7th ed.). McGraw-Hill.

Section 3.7, "Integrity Constraints": "A foreign-key constraint specifies that the values of the foreign key in any tuple of the referencing relation must be a subset of the values of the primary key in some tuple of the referenced relation." (p. 98).

2. Elmasri, R., & Navathe, S. B. (2017). Fundamentals of Database Systems (7th ed.). Pearson.

Chapter 5, Section 5.2.4, "Referential Integrity, and Foreign Keys": "The referential integrity constraint is specified between two relations and is used to maintain the consistency among tuples in the two relations... A foreign key is a set of attributes FK in a relation schema R1 whose values are required to match the values of the primary key PK of some tuple in another relation schema R2." (p. 143).

3. PostgreSQL 16 Documentation. (2023). Chapter 5. Data Definition.

Section 5.4.5, "Foreign Keys": "A foreign key constraint specifies that the values in a column (or a group of columns) must match the values appearing in some row of another table. We say this maintains the referential integrity between two related tables."

Non-relational (NoSQL) databases are engineered to address the challenges of big data. Their core design principles, such as horizontal scalability (scaling out) and flexible data models (document, key-value, graph), allow them to efficiently store and process massive volumes of unstructured or semi-structured data. Unlike relational databases that can become bottlenecks, NoSQL systems are built for high availability and performance at scale, making them the preferred choice for applications dealing with large, diverse, and rapidly growing datasets.

B. They are often called "NoSQL" (Not only SQL) and typically use proprietary or non-SQL query languages, not the standard SQL of relational systems.

C. Relational databases, with strict ACID properties, are ideal for transactional accuracy. NoSQL databases often prioritize availability over consistency (BASE model).

D. This describes the tabular structure of relational databases. Non-relational databases use flexible models like document, key-value, column-family, or graph stores.

1. Amazon Web Services (AWS) Documentation. "What is NoSQL?". In the section "Relational vs. NoSQL," it states, "NoSQL databases are a great fit for many modern applications such as mobile, web, and gaming that require flexible, scalable, high-performance, and highly functional databases to provide great user experiences." This directly aligns with the demands of big data applications.

2. Stonebraker, M. (2010). "SQL Databases v. NoSQL Databases". Communications of the ACM, 53(4), p. 10-11. This foundational article explains that NoSQL systems emerged to meet the scalability and flexibility requirements of large-scale web applications, which are primary generators of big data. (https://doi.org/10.1145/1721654.1721693)

3. Carnegie Mellon University, Database Group Courseware. "15-445/645 Database Systems (Fall 2022)", Lecture #21: NoSQL Databases. The lecture notes explicitly contrast NoSQL with SQL databases, highlighting NoSQL's relaxed consistency (BASE vs. ACID) and non-relational data models as trade-offs for achieving higher scalability for large datasets. (See slides on "NoSQL Use Cases" and "Data Models").

By convention and as a widely accepted best practice in relational database design, the primary key column is placed first in a table's column order. This practice is not enforced by the SQL standard but significantly enhances the logical clarity and readability of the table structure. Placing the unique identifier for each record at the beginning makes it easy for developers and analysts to immediately understand the key attribute around which the table is organized. This logical ordering is a fundamental principle taught in database design courses.

A. The table header defines column names and data types (metadata), not the actual key values, which reside in the table's rows.

C. A row represents a single record; a primary key is a column (attribute) that applies to all rows to ensure each is unique.

D. While technically possible, placing the primary key in the last column is highly unconventional and contradicts standard design principles for readability.

1. Coronel, C., & Morris, S. (2016). Database Systems: Design, Implementation, and Management (12th ed.). Cengage Learning. In Chapter 3, "The Relational Database Model," all example tables, such as the AGENT table in Table 3.3 (p. 89), consistently list the primary key attribute (AGENTCODE) as the first column in the table structure, demonstrating this as a standard convention.

2. Silberschatz, A., Korth, H. F., & Sudarshan, S. (2020). Database System Concepts (7th ed.). McGraw-Hill. Throughout the text, relational schemas are presented with the primary key attributes listed first. For instance, in Chapter 2, Section 2.2, "Database Schema," the example instructor relation is defined as instructor(ID, name, deptname, salary), with the primary key ID as the first attribute.

3. Stanford University. (2016). CS145 Introduction to Databases, Lecture 2: Relational Model. In the lecture notes, relational schemas are consistently defined with the primary key attribute(s) listed first. For example, the Student relation is shown as Student(sID, sName, GPA, sizeHS), where sID is the primary key. This illustrates the standard academic convention for representing table structures. (Available via Stanford's public course archives).

The fundamental characteristic that distinguishes a strong entity from a weak entity is its ability to be uniquely identified. A strong entity possesses its own primary key, which is an attribute or set of attributes that uniquely identifies each instance of the entity. Conversely, a weak entity does not have a sufficient set of attributes to form a primary key on its own. Its existence is dependent on a strong entity, and its unique identification is achieved by combining its own partial key (discriminator) with the primary key of the owner (strong) entity. Therefore, the structure and self-sufficiency of the primary key is the core differentiator.

A. Association: Both strong and weak entities participate in associations (relationships) with other entities; this is not a distinguishing feature.

C. Foreign key: While a weak entity's primary key incorporates a foreign key from its owner, strong entities also use foreign keys to establish relationships.

D. Cardinality: This describes the numerical aspect of a relationship (e.g., one-to-many) between entities, not the intrinsic nature of the entity itself.

---

1. Elmasri, R., & Navathe, S. B. (2017). Fundamentals of Database Systems (7th ed.). Pearson. In Chapter 7, Section 7.3, "Weak Entity Types," it states: "Entity types that do not have key attributes of their own are called weak entity types... The primary key of a weak entity type is formed by the primary key of the owner entity type, plus the weak entity type’s partial key." (pp. 223-224).

2. Silberschatz, A., Korth, H. F., & Sudarshan, S. (2020). Database System Concepts (7th ed.). McGraw-Hill. In Chapter 7, Section 7.5, "Weak Entity Sets," the text explains: "An entity set that does not have a primary key is referred to as a weak entity set... The primary key of a weak entity set is formed by the primary key of the strong entity set on which the weak entity set is existence dependent, plus the weak entity set’s discriminator." (p. 285).

3. Stanford University. (n.d.). CS145 Introduction to Databases, Notes: The Entity-Relationship Model. Stanford Online. Retrieved from the course materials which state: "A weak entity can be identified uniquely only by considering the primary key of another (owner) entity... The primary key of the weak entity set is the combination of the primary key of the owner entity set and the discriminator of the weak entity set."

Databases use an Application Programming Interface (API) to provide a standardized way for applications, written in general-purpose languages like Java or Python, to communicate with them. APIs such as Java Database Connectivity (JDBC) or Open Database Connectivity (ODBC) define a set of functions and protocols that allow a program to connect to the database, submit SQL queries as text strings, and retrieve the results in a structured format. This abstracts the low-level complexity of network communication and internal database operations, thereby simplifying the integration of SQL into application code.

A. The storage manager is an internal database component that interacts with the file system; it is not an interface for application developers.

B. The ability to reverse results (transaction rollback) is a feature of transaction management, not the primary mechanism for integrating SQL with a language.

C. The query processor is an internal engine that executes queries; the API is the external interface that applications use to submit queries to this processor.

---

1. Silberschatz, A., Korth, H. F., & Sudarshan, S. (2020). Database System Concepts (7th ed.). McGraw-Hill. In Chapter 4, "Advanced SQL," Section 4.1, "Accessing SQL From a Programming Language," it states, "An application program that needs to access a database can use an application programming interface (API) to communicate with the database. The two main standards for database APIs are ODBC and JDBC." (p. 131).

2. Oracle Corporation. (2023). JDBC Developer's Guide, 23c. In the "Introduction to JDBC" section, it is stated: "The JDBC API is a Java API that enables Java programs to execute SQL statements... With the JDBC API, you can write applications that manage these tasks: Connecting to a data source, such as a database; Sending queries and update statements to the database; Retrieving and processing the results received from the database in answer to your query."

3. Ullman, J. D., & Widom, J. (n.d.). CS145 Introduction to Databases, Lecture Notes: SQL in Applications. Stanford University. The notes on JDBC describe it as "an API for database access from Java" and detail the process of establishing a connection, creating statements, and executing queries, which exemplifies the role of an API in bridging the application and the database.

In database design, particularly within the context of the Entity-Relationship (ER) model, attributes are the named properties or characteristics that describe an entity. For example, for a 'Car' entity, attributes would be named 'VIN', 'Make', 'Model', and 'Year'. These names are the fundamental identifiers for the data elements in design documents like ER diagrams and data dictionaries. They define the specific pieces of information to be stored for each instance of an entity.

A. Synonyms: A synonym is an alternative name for a data element within a data dictionary, not the primary attribute itself.

C. Repositories: A repository is a system or location where data and metadata are stored and managed, a much broader concept than an individual attribute.

D. Relationships: Relationships represent associations between different entities (e.g., a 'Customer' places an 'Order') and are a distinct component of the data model, separate from attributes.

1. Elmasri, R., & Navathe, S. B. (2017). Fundamentals of Database Systems (7th ed.). Pearson. In Chapter 7, Section 7.3.2, "Attributes," it is stated, "Each entity type... has a number of attributes that describe it... Each attribute has a name that describes the property." (p. 221).

2. Silberschatz, A., Korth, H. F., & Sudarshan, S. (2020). Database System Concepts (7th ed.). McGraw-Hill. Chapter 6, "Database Design and the E-R Model," Section 6.1.2, describes attributes as descriptive properties possessed by each member of an entity set, which are represented by their names in diagrams and schemas.

3. Mannino, M. V. (2006). Database Design, Application Development, and Administration (3rd ed.). Wiley. Chapter 4, "The Entity-Relationship Model," defines an attribute as a "named property or characteristic of an entity." (p. 104).

The transaction manager is the component of the Database Management System (DBMS) responsible for ensuring the atomicity and durability of transactions. It accomplishes this by supervising the execution of each transaction. A critical function is recording all data-modifying operations, such as INSERT, UPDATE, and DELETE, into a system log. This logging ensures that in the event of a system failure, the database can be restored to a consistent state. The transaction manager oversees the entire process, from receiving the request to committing the changes and returning the result.

A. Query optimization is the responsibility of the query processor (or query optimizer), which analyzes queries to find the most efficient execution plan.

B. This option incorrectly describes the overall architecture of a DBMS, not the composition of the transaction manager itself. The transaction manager is a component within this architecture.

D. Translating instructions into filesystem commands and managing indexes are functions of the storage manager, which handles the interaction between the DBMS and the physical storage.

1. Silberschatz, A., Korth, H. F., & Sudarshan, S. (2020). Database System Concepts (7th ed.). McGraw-Hill. In Chapter 1, Section 1.8, "Database-System Architecture," the text describes the transaction manager as the component that "ensures that the database remains in a consistent (correct) state despite system failures... It also ensures that concurrent transaction executions proceed without conflicting." This is achieved through logging, as detailed in Chapter 16, "Recovery System."

2. Elmasri, R., & Navathe, S. B. (2017). Fundamentals of Database Systems (7th ed.). Pearson. In Chapter 2, Section 2.3.1, "The DBMS Component Modules," the transaction manager is described as providing "concurrency control and recovery services to the users." The recovery service relies on the system log to restore the database after a failure.

3. Ramakrishnan, R., & Gehrke, J. (2003). Database Management Systems (3rd ed.). McGraw-Hill. In Chapter 1, Section 1.7.1, "Components of a DBMS," the transaction manager is identified as the component that "ensures that transactions are executed atomically and in an isolated manner, and that their effects are durable." The mechanism for durability is explicitly tied to logging transaction operations.