Free CITM-001 Practice Test

A distributed database system offers several key advantages over a centralized one.
1. Increased Availability (A): Data is often replicated across multiple sites (nodes). If one site fails due to a hardware or network issue, the system can continue to operate using data from other available sites, significantly enhancing fault tolerance and overall availability.
2. Easier Expansion (B): The architecture is modular. To increase storage or processing capacity, new servers can be added to the network without requiring a complete system overhaul. This concept, known as modular or incremental growth, makes expansion more manageable and cost-effective.
3. Improved Performance (D): Performance is enhanced in two main ways. First, data can be stored physically closer to the users who access it most frequently, reducing network latency (data localization). Second, complex queries can be broken down and executed in parallel across multiple machines, reducing the total query response time.

C. Easy to scale: While distributed databases are designed for scalability, this option is less precise than "Easier Expansion." The process of managing a large-scale distributed system, ensuring consistency and handling complex coordination, is not inherently "easy." "Easier Expansion" more accurately describes the specific advantage of modular growth. ---

1. Özsu, M. T., & Valduriez, P. (2020). Principles of Distributed Database Systems (4th ed.). Springer.

Page 6, Section 1.3.2, "Increased Reliability and Availability": "If one site fails, the DDBMS can continue to operate at a reduced level... Availability is the probability that the system is continuously available... In a distributed system, the failure of one or a few sites, or the failure of some communication links, does not render the entire system inoperable." (Supports option A)

Page 7, Section 1.3.4, "Easier System Expansion": "In a distributed environment, it is much easier to accommodate increasing database sizes. Major system overhauls are seldom necessary; expansion can usually be handled by adding processing and storage power to the network..." (Supports option B)

Page 7, Section 1.3.3, "Improved Performance": "A query that involves data from several sites can be split into subqueries that are executed in parallel at these sites... Furthermore, since the data is placed closer to its points of use, the communication delays... are minimized." (Supports option D)

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

Page 910, Section 19.1.2, "Reliability and Availability": "In a distributed system, if one site fails, the remaining sites may be able to continue operating. If the data are replicated, the failure of a site does not necessarily imply the shutdown of the system." (Supports option A)

Page 910, Section 19.1.2, "Speedup of Query Processing": "If a query involves data at several sites, the query can be broken down into subqueries that can be executed in parallel at each site. The parallel computation allows for faster query processing..." (Supports option D)

3. Ramakrishnan, R., & Gehrke, J. (2003). Database Management Systems (3rd ed.). McGraw-Hill.

Page 709, Section 22.1.1, "Advantages of Distributed Databases": "Increased Availability: If a site goes down in a distributed DBMS, the other sites can continue to operate... By replicating data, we can ensure that the failure of a single site does not make the data inaccessible." (Supports option A)

Page 709, Section 22.1.1, "Advantages of Distributed Databases": "Easier Local and Global Expansion: In a distributed DBMS, it is easier to accommodate an increase in the size of the database. If a company opens a new branch, it can easily add a new site to the distributed DBMS." (Supports option B)

Reciprocal interdependence, as defined in organizational theory, describes the most complex relationship where the outputs of one unit or organization serve as the inputs for another, and vice-versa. This creates a mutual, two-way dependency. The actions of each entity directly and immediately impact the other, necessitating a high degree of communication, mutual adjustment, and coordination to manage the relationship effectively. This concept is a cornerstone of James D. Thompson's work on organizational design and technology.

A. Pooled: This describes a situation where units are independent in their daily work but contribute to a common organizational goal or resource pool, creating only indirect dependency.
C. Peer: This is not a standard classification within the established typology of organizational interdependence (Pooled, Sequential, Reciprocal) and lacks a formal definition in this context.
D. Sequential: This refers to a one-way dependency where the output of one unit becomes the input for the next, such as in an assembly line, not a mutual exchange.

1. Thompson, J. D. (1967). Organizations in Action: Social Science Bases of Administrative Theory. McGraw-Hill. In Chapter 5, "Technology and Structure," Thompson defines reciprocal interdependence as when "the outputs of each become inputs for the others... each unit involved is penetrated by the other" (p. 55).

2. Van de Ven, A. H., Delbecq, A. L., & Koenig, R. (1976). Determinants of coordination modes within organizations. American Sociological Review, 41(2), 322-338. This article builds on Thompson's work, stating that with reciprocal interdependence, "work flows back and forth between units" (p. 324). https://doi.org/10.2307/2094477

3. Stanford University, Graduate School of Business. (n.d.). OIT 262: Aligning Startups with their Markets, Lecture 4: Organizing. Courseware. The lecture notes define reciprocal interdependence as a "Two-way flow of information, work, and influence," contrasting it with the one-way flow of sequential and the independent nature of pooled interdependence (Slide 14).

The Systems Design Life Cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project. While models can vary, a widely accepted seven-phase model is: 1. Planning, 2. Analysis, 3. Design, 4. Development (Building), 5. Testing, 6. Implementation (Installation), and 7. Operations & Maintenance. The sixth phase, Implementation or Installation, involves deploying the tested system into the live production environment. This includes activities like data migration, user training, and the physical installation of hardware and software.

A. Training: Training is a critical sub-activity that occurs within the sixth implementation/installation phase, not a standalone phase itself in this context.
C. Operations: This is the seventh and final phase of the SDLC, which begins only after the system has been successfully installed and is running.
D. Building: This refers to the development or coding phase, which is the fourth step in the SDLC, occurring well before testing and installation.

1. Florida State University, College of Communication & Information. (n.d.). The System Development Life Cycle (SDLC). LIS 2780 Course Guide. Retrieved from https://guides.lib.fsu.edu/c.php?g=1222451&p=9010501.

Reference Point: The guide explicitly lists the seven phases of the SDLC, identifying "Implementation" as the sixth phase.

2. University of Texas at Austin, McCombs School of Business. (n.d.). The Systems Development Life Cycle. Tech Articles. Retrieved from https://www.mccombs.utexas.edu/tech-articles/the-systems-development-life-cycle/.

Reference Point: This article outlines the seven phases, clearly stating that the sixth phase is "Implementation," which involves installing the system for user access.

3. Valacich, J. S., & George, J. F. (2020). Modern Systems Analysis and Design (9th ed.). Pearson.

Reference Point: Chapter 1, "The Systems Development Environment," describes the SDLC. While it presents a condensed four-phase model, the detailed breakdown shows that implementation (which includes installation, documentation, and training) follows the design and precedes the operation phase. The more granular, traditional model places it as the sixth step.

The statement is correct. Transaction Processing Systems (TPS) capture and process the day-to-day operational data of a firm, such as sales orders, payroll, and shipping. The output of this processing is detailed, up-to-date information. When this information is aggregated and summarized, it provides managers with a clear and accurate picture of key business metrics, including the exact status of the order backlog or the firm's current financial standing (e.g., accounts receivable, cash flow). This availability of precise, timely data directly reduces uncertainty and provides a solid foundation for managerial control and decision-making.

B. False: This is incorrect because the fundamental purpose of processing transaction data is to create an accurate, structured record of business activities. This record is the primary source of information that reduces ambiguity and uncertainty about the firm's operational state.

1. Laudon, K. C., & Laudon, J. P. (2020). Management Information Systems: Managing the Digital Firm (16th ed.). Pearson. In Chapter 2, "Global E-Business and Collaboration," the text explains that Transaction Processing Systems (TPS) are the primary producers of information for other systems and are used to answer routine questions and track the flow of transactions. This tracking and data provision is what reduces uncertainty about operations like order backlogs.

2. Valacich, J., & Schneider, C. (2018). Information Systems Today: Managing in the Digital World (8th ed.). Pearson. Chapter 8, "Enhancing Business Processes Using Enterprise Information Systems," describes how systems like ERP (which are built around a core TPS) provide a "single version of the truth" regarding business data, thereby eliminating uncertainty and providing a clear view of financial and operational positions.

3. MIT OpenCourseWare. (2004). 15.561J Information Technology I, Class 10: Transaction Processing. MIT Sloan School of Management. The course materials describe TPS as systems that "collect, store, modify, and retrieve the transactions of an organization." This retrieval of verified, processed transaction data is what informs managers about the firm's status, thus reducing uncertainty. (See lecture notes for Class 10).

The success of an organization's information processing capabilities is a shared responsibility, primarily driven by strategic direction and tactical implementation. Top Management is responsible for setting the overall strategy, aligning information technology (IT) with business goals, and approving the necessary resources and investments. Their commitment is crucial for championing IT initiatives. Middle Management is responsible for executing this strategy by managing IT projects, overseeing the implementation of new systems within their departments, and ensuring that these systems meet the specific needs of business units. The synergy between top management's vision and middle management's execution is fundamental to achieving successful information processing.

A. Stakeholders Management: This is a management process or function focused on all parties affected by the organization, not a specific hierarchical department or level responsible for information processing.
D. Bottom Level Management: This level is primarily concerned with the day-to-day operational use of information systems, rather than the strategic planning and implementation that dictate their overall success.

1. Laudon, K. C., & Laudon, J. P. (2020). Management Information Systems: Managing the Digital Firm (16th ed.). Pearson. In Chapter 2, "Global E-Business and Collaboration," the text describes how different information systems serve various management levels. Executive Support Systems (ESS) for senior (top) management focus on strategic decision-making, while Management Information Systems (MIS) and Decision-Support Systems (DSS) serve middle management's monitoring, controlling, and tactical decision-making functions (pp. 46-51). This division illustrates the distinct but complementary responsibilities of top and middle management in leveraging information.

2. Thong, J. Y. L., & Yap, C. S. (1995). CEO characteristics, organizational factors and information technology adoption in small businesses. Omega, 23(4), 429–442. This study empirically demonstrates that top management support, specifically from the CEO, is one of the most critical factors influencing the adoption and success of information technology in an organization (Section 4, "Results," p. 437).

3. Balogun, J. (2003). From Blaming the Middle to Harnessing its Potential: Creating Change Intermediaries. British Journal of Management, 14(1), 69–83. https://doi.org/10.1111/1467-8551.00266. This article highlights the critical role of middle managers as change agents who translate top-level strategic initiatives (such as implementing new information systems) into everyday reality, making their role indispensable for the success of such projects (p. 70).

In the context of a relational database, a table is structured into rows and columns. Each row represents a single, complete data entry or item within the table. This horizontal grouping of related data is formally known as a "tuple" in relational model theory, but is most commonly referred to as a "record." For example, in a table of employees, each row would be a record containing all the information about one specific employee (e.g., their ID, name, and position).

B. column: A column (also called an attribute or field) is a vertical entity in a table that contains all the data for a single, specific type of information for all records.
C. information: Information is a broad term for processed and organized data. It is the content of the database, not a specific structural component like a row or record.

1. Elmasri, R., & Navathe, S. B. (2017). Fundamentals of Database Systems (7th ed.). Pearson. In Chapter 3, "The Relational Data Model and Relational Database Constraints," Section 3.1, the text states: "Each row in the table represents a collection of related data values... In the formal model, a row is called a tuple... In informal terms, a relation can be thought of as a table of values... A row is also called a record." (p. 60).

2. Ullman, J. D., & Widom, J. (2008). A First Course in Database Systems (3rd ed.). Pearson Prentice Hall. In Chapter 2, "The Relational Model," Section 2.1.2, it is explained: "The rows of a relation, other than the header row, are called tuples. A tuple is a list of values... The term record is an alternative to 'tuple'." (p. 26).

3. MIT OpenCourseWare. (2010). 6.830 Database Systems, Lecture 2: Relational Algebra. Massachusetts Institute of Technology. The lecture notes explicitly map the terminology: "Relation = table", "Tuple = row/record", "Attribute = column/field".

In the context of systems analysis and design, there are five commonly recognized and fundamental techniques for collecting data and determining system requirements. These methods are:
1. Interviews: One-on-one or small group discussions with stakeholders to gather in-depth information.
2. Questionnaires: Written sets of questions distributed to a large number of people to collect data on attitudes, beliefs, and characteristics.
3. Observation: Watching users perform their jobs to understand existing processes and identify problems or opportunities for improvement.
4. Document Analysis: Reviewing existing business documents, forms, reports, and system manuals to understand the current system.
5. Joint Application Design (JAD): Highly structured group meetings or workshops involving users, managers, and analysts to jointly define system requirements.

A. Three: This count is insufficient as it omits several core, standard techniques essential for comprehensive requirements gathering in system design.
B. Four: This number is also incomplete and fails to account for the full range of primary data collection methods recognized in the field.
D. Six: While some methodologies might further subdivide techniques (e.g., treating prototyping separately from JAD), the five listed are the most widely accepted primary categories.

1. Valacich, J. S., George, J. F., & Hoffer, J. A. (2015). Essentials of Systems Analysis and Design (6th ed.). Pearson. In Chapter 4, "Determining System Requirements," the text explicitly outlines and details the five key techniques for requirements determination: Interviews, Questionnaires, Observation, Document Analysis, and Joint Application Design (JAD).

2. Dennis, A., Wixom, B. H., & Roth, R. M. (2018). Systems Analysis and Design (7th ed.). Wiley. Chapter 3, "Requirements Determination," is dedicated to this topic and presents these five methods as the fundamental "Requirements-Gathering Techniques."

3. University of Missouri-St. Louis. (n.d.). INFSYS 3843: Systems Analysis and Design I Course Material. In the lecture notes for "Requirements Determination," the five techniques (Interviews, JAD, Questionnaires, Document Analysis, Observation) are presented as the primary methods for information gathering. (Referenced in course syllabi and lecture slides for the respective semester).

In a hard disk drive (HDD), data is stored in sectors on spinning platters. The total time to access data is composed of seek time, rotational delay, and transfer time. Rotational delay, also known as rotational latency, is the time required for the platter to spin so that the beginning of the desired data sector is positioned directly under the read-write head. This delay occurs after the head has already moved to the correct track (seek time) and is a direct consequence of the disk's rotational speed.

A. Sequential delay: This is not a standard term used to describe a specific component of disk access time. It is an imprecise and non-technical phrase in this context.
C. Seek time: This is the time it takes for the read-write head assembly to move from its current position to the correct track (or cylinder) on the platter.
D. Collision time: This term is associated with network protocols, specifically Carrier Sense Multiple Access with Collision Detection (CSMA/CD), and refers to the time it takes to detect a data collision on a shared medium.

1. Patterson, D. A., & Hennessy, J. L. (2013). Computer Organization and Design: The Hardware/Software Interface (5th ed.). Morgan Kaufmann. In Chapter 5, Section 5.4, "Dependability, Reliability, and Availability," the text defines the components of disk access time. It states, "The second component is the rotational latency... the time for the desired sector to rotate under the read/write head." (p. 311).

2. Silberschatz, A., Galvin, P. B., & Gagne, G. (2018). Operating System Concepts (10th ed.). Wiley. In Chapter 10, "Mass-Storage Structure," Section 10.2.1, "Disk Structure," the text explains, "The time waiting for the disk to rotate the desired sector to the disk head is the rotational latency." (p. 438).

3. Arpaci-Dusseau, R. H., & Arpaci-Dusseau, A. C. (2018). Operating Systems: Three Easy Pieces. Arpaci-Dusseau Books. In Chapter 37, "Hard Disk Drives," Section 37.3, "A Simple Disk Model," the authors define the components of I/O time: "The time for the desired sector to rotate under the disk head; this is also known as the rotational delay." (p. 4).

The statement is correct. In management theory, decision-making and control are typically structured in a three-level hierarchy. At the top is Strategic Planning, which involves long-range, high-level decisions about the organization's objectives. At the bottom is Operational Control, which concerns the efficient and effective execution of specific, day-to-day tasks. Managerial Control (also known as Tactical Control) occupies the middle level. Its primary function is to ensure that resources are obtained and used effectively and efficiently to accomplish the organization's strategic objectives. It translates broad strategic goals into specific plans and policies for operational units, thus falling squarely between strategic and operational activities.

B. False: This is incorrect. The hierarchical model of management control, famously articulated by Robert N. Anthony, explicitly positions managerial control as the intermediate layer between strategic planning and operational control.

1. Anthony, R. N. (1965). Planning and Control Systems: A Framework for Analysis. Harvard University, Graduate School of Business Administration. (This foundational text establishes the three-level framework: strategic planning, management control, and operational control, with managerial control as the intermediate level).

2. Laudon, K. C., & Laudon, J. P. (2016). Management Information Systems: Managing the Digital Firm. Pearson. In Chapter 2, "Global E-Business and Collaboration," the text discusses the different levels in a firm (senior, middle, and operational) and the types of decisions made at each level, aligning with the concept of strategic, managerial, and operational control.

3. MIT OpenCourseWare. (2004). 15.561J Information Technology I, Lecture 2: Organizational Context. Massachusetts Institute of Technology. The lecture notes discuss Anthony's Triangle (or the Management Pyramid), which visually represents strategic decisions at the top, tactical (managerial) in the middle, and operational at the base. This confirms the hierarchical relationship described in the question.

In Data Flow Diagrams (DFDs), the flow of data is universally represented by a directed line, or an arrow. The arrowhead indicates the direction of data movement. This symbol connects other DFD components, such as external entities, processes, and data stores, illustrating the path data takes through a system. The arrow is labeled with the name of the data it carries. This notation is standard across different DFD methodologies, including both Gane & Sarson and Yourdon/DeMarco.

A. Square: A square (or rectangle) represents an external entity, which is a source or destination of data outside the system's boundary, not the flow of data itself.
B. Rectangle: Similar to a square, a rectangle is used to depict an external entity. A rounded rectangle is typically used to represent a process that transforms data.
D. Data Store: A data store, usually shown as two parallel lines or an open-ended rectangle, represents a repository where data is held for later use, not the movement of data.

1. Hoffer, J. A., George, J. F., & Valacich, J. S. (2011). Modern Systems Analysis and Design (6th ed.). Prentice Hall. Chapter 7, "Structuring System Process Requirements," Figure 7-3, p. 211, explicitly defines a data flow as "Data in motion, moving from one place in a system to another" and its symbol as an arrow.

2. University of Texas at Austin, McCombs School of Business. (n.d.). Data Flow Diagramming (DFD) Symbols. Retrieved from https://www.mccombs.utexas.edu/~/media/Files/MSB/Depts/IROM/MIS-Cases/Fall2012/dfdsymbols.pdf. This document shows both Gane & Sarson and Yourdon & DeMarco notations, where the "Data Flow" is represented by an arrow in both systems.

3. Yourdon, E. (1989). Modern Structured Analysis. Prentice-Hall. Chapter 9, "The Dataflow Diagram," pp. 137-140, defines the data flow as a "pipeline through which packets of information of known composition flow" and illustrates it with a directed arrow.