Database and SQL

COUNT(*) is the correct SQL aggregate function to return the number of records in a table. COUNT() without the asterisk is incomplete, and COLUMNS is not a valid aggregate function in SQL.

A table can have only one clustered index because clustered indexes determine the physical order of data storage. The limits 128, 256, or 'up to columns' refer to non-clustered indexes, not clustered ones.

SQL Server supports Inner, Left (Outer), Right (Outer), Full (Outer), and Cross joins. 'Multiple' is not a join type - it's not a recognized SQL Server join category.

SQL Server constraints include Default, Check, Unique, Primary Key, and Foreign Key. DISTINCT is not a constraint - it's a query clause used to eliminate duplicate rows from SELECT results, not a rule enforcing data integrity.

ORDER BY is the SQL clause used to sort result sets in ascending or descending order. 'ORDER', 'SORT', and 'Distinct' are not valid sorting keywords in SQL.

SQL Server aggregate functions include COUNT, SUM, AVG, MIN, and MAX - they perform calculations on sets of values. GROUP is not an aggregate function; it's used with GROUP BY to arrange identical data into groups, but GROUP BY itself is a clause, not an aggregation function.

Referential integrity ensures that relationships between tables remain consistent. It guarantees that a foreign key value either matches a valid primary key in the related table or is NULL, preventing orphaned records and maintaining valid data relationships across tables.

The HISTOGRAM statement in Natural/Adabas performs two key functions: it initiates an automatic processing loop that iterates through each matching descriptor value (option A), and it populates the *NUMBER system variable with the count of occurrences or rows processed (option D). Options B and C are incorrect because HISTOGRAM is specifically for descriptor processing, not general field access or column value processing.

The 'Data driven' option allows the mapping to handle both inserts and updates based on flags set in the data flow. When selected, Informatica uses the update strategy flags (DD_INSERT, DD_UPDATE, DD_DELETE) set within the mapping to determine the operation type for each row. This enables a single session to perform different DML operations dynamically.

In Informatica PowerCenter, using a Sorter transformation can be faster because it utilizes the Integration Service's memory (cache) and parallel processing, avoiding database overhead and network roundtrips caused by database-level sorting via an 'ORDER BY' clause. However, performance varies based on database optimization, making the absolute claim debatable.

In PLM systems, an attribute's data type is immutable after creation because it defines the storage format and validation rules. Changing the type would break existing data and database constraints. Ranges, default values, and names are typically modifiable, while Vault refers to storage location, not an attribute property.

Relationship revision options include Float (A) allowing independent object modification, None (B) for permanent connections, and Replicate (E) for duplicating connections. Clone (C) and Copy (D) are not valid relationship revision options in Matrix database schema.

REPLICATE in Matrix relationships creates duplicate connections between objects, preserving the original while copying the link. Float (B) means independent modification, disconnect (C) breaks the relationship, revise (D) changes connection properties, and clone (E) duplicates objects, not connections.

In ENOVIA Matrix relationship definitions, the REPLICATE property creates a duplicate connection between the same pair of objects. This allows multiple identical relationship instances to exist between the same source and target objects. Options B (floating), C (disconnecting), and D (revising) describe other relationship operations, while E (cloning objects) refers to object duplication, not relationship duplication.

In Matrix/3DX PLM systems, an attribute's data type is locked at creation and cannot be changed later. This is a fundamental schema design principle - changing a type would break existing data and require database migration. Ranges, default values, and names can typically be modified through schema updates or admin tools without affecting the core data structure.