Database Fundamentals and Technologies

IMS DB databases are organized hierarchically with segments containing other segments. The maximum depth of this hierarchy - the number of levels from root to the deepest leaf segment - is 15 levels. This is a fundamental architectural constraint in IMS database design.

PROCOPT (Processing Options) specifies the type of access allowed (GET, INSERT, REPLACE, DELETE) and can be defined at both the PCB level (for the entire database view) and at the SENSEG (Sensitive Segment) level (for specific segment types). The question wording 'Segment field (SENSEG)' is technically imprecise but the concept is correct - PROCOPT applies to segment definitions.

A PSB (Program Specification Block) serves as a container for PCBs (Program Communication Blocks) and must contain at least one PCB to be valid. There is no fixed upper bound - a PSB can contain as many PCBs as needed for the application to access different databases or different views of the same database.

PROCOPT (Processing Options) is the parameter that defines what types of database operations are permitted - such as GET (read), INSERT (create), REPLACE (update), and DELETE. It is specified in the PCB and SENSEG statements to control access rights at the database or segment level. PCB, SENSEG, and SENFLD are structure definitions, not access control specifications.

In IMS database terminology, when a parent segment has multiple occurrences of the same child segment type, those child segments are called 'twins'. For example, if an ORDER segment has multiple LINE-ITEM segments of type 'LINE-ITEM', those LINE-ITEMs are twins of each other under that ORDER.

In Oracle SQL, the ROWNUM pseudo-column is assigned sequentially starting at 1. The condition rownum >= 2 is never met because the first row evaluated is assigned ROWNUM 1, which fails the condition, preventing any subsequent rows from being fetched. Thus, 0 rows are returned.

With negative precision in Round/Trunc functions, -3 means round/truncate to the nearest 1000. For value 159.63: Round(159.63, -3) = 0 (since 159 is closer to 0 than 1000) and Trunc(159.63, -3) = 0 (truncating toward zero). The correct output pair is (0, 0), which is not listed in any option, making 'none of the above' the right choice.

The format mask '999999.99' in Oracle TO_CHAR specifies 6 digits before decimal (with leading spaces for smaller numbers) and 2 digits after decimal. Converting string '9999' with this mask produces ' 9999.00' which is 10 characters total: 2 leading spaces, 4 digits, decimal point, and 2 decimal digits. The LENGTH function returns 10.

The query uses ADD_MONTHS function which adds months to a date. Starting from '17/10/2009', ADD_MONTHS(..., 12) adds 12 months to become '17/10/2010'. The TRUNC function with no arguments truncates to the first day of the month, giving '01/10/2010' (October 1st, 2010). The correct answer is '01/10/10'.

TIMESTAMP and INTERVAL types (DAY TO SECOND, YEAR TO MONTH) are valid SQL datetime data types for column definitions. INTERVAL MONTH TO DAY is not a valid interval type (should be INTERVAL DAY TO MONTH), and TIMESTAMP WITH DATABASE TIMEZONE is incorrect syntax.

To add a primary key with ALTER TABLE, you must use ADD CONSTRAINT with a constraint name and PRIMARY KEY keyword. Option D follows the correct syntax, though note that the column name appears to have unusual spacing. Option A lacks parentheses and constraint name, B lacks the constraint name before PRIMARY KEY, C has potential naming issues, and E uses MODIFY which is not correct for adding constraints.

To turn on an existing constraint, option C is correct:

The correct syntax to turn on an existing constraint is:

C. ALTER TABLE table_name ENABLE CONSTRAINT constraint_name;

Option A is also a valid syntax for enabling a constraint.

Option B is incorrect because there is no "STATUS" option for the ALTER TABLE statement.

Option D is incorrect because there is no "TURN ON" option for the ALTER TABLE statement.

Therefore, the answer is: C. ALTER TABLE table_name ENABLE CONSTRAINT constraint_name;

SQL Server restricts each data file to membership in a single filegroup. This design ensures clear data organization and prevents ambiguity in data placement and management. Files cannot span multiple filegroups.

Triggers execute within the transaction scope of the triggering statement. DDL operations like CREATE TABLE are prohibited because they would require implicit commits that conflict with the trigger's transactional context and could cause rollback issues.

In iBATIS stored procedures, the correct attribute for parameter mapping is 'parameterMap'. The 'parameterName' attribute doesn't exist in the iBATIS DTD. The procedure uses the parameterMap named 'swapParameters' to map output parameters correctly.

iBATIS is a persistence framework that maps SQL statements to Java objects, emphasizing full control over custom SQL and stored procedures rather than full object-relational mapping (ORM).

SqlSessionFactory is created using SqlSessionFactoryBuilder in iBATIS/MyBatis. This builder pattern reads configuration and builds the factory. Other options like SqlBuilder or SqlSessionBuilder are incorrect or don't exist.

The statement claims iBATIS discourages SQL use, but this is false - iBATIS is designed to leverage SQL's power. It allows developers to write raw SQL queries while simplifying database access, preserving all SQL benefits. Therefore the correct answer is False.