1Z0-007 · Question #107
Examine the structure of the EMPLOYEES table: EMPLOYEE_ID NUMBER NOT NULL, Primary Key EMP_NAME VARCHAR2(30) JOB_ID NUMBER\ SAL NUMBER MGR_ID NUMBER References EMPLOYEE_ID column DEPARTMENT_ID…
The correct answer is C. The EMP_ID_SEQ sequence is not affected by modifications to the EMPLOYEES table. D. Any other column of NUMBER data type in your schema can use the EMP_ID_SEQ sequence. the EMP_ID_SEQ sequence is not affected by modification to the EMPLOYEES table. Any other column of NUMBER data type in your schema can use the EMP_ID_SEQ sequence. Incorrect answer: A EMP_ID_SEQ sequence can be use to populate JOB_ID B EMP_ID_SEQ sequence will not be…
Question
Examine the structure of the EMPLOYEES table:
EMPLOYEE_ID NUMBER NOT NULL, Primary Key EMP_NAME VARCHAR2(30) JOB_ID NUMBER\ SAL NUMBER MGR_ID NUMBER References EMPLOYEE_ID column DEPARTMENT_ID NUMBER Foreign key to DEPARTMENT_ID column of the DEPARTMENTS table You created a sequence called EMP_ID_SEQ in order to populate sequential values for the EMPLOYEE_ID column of the EMPLOYEES table. Which two statements regarding the EMP_ID_SEQ sequence are true? (Choose two.)
Options
- AYou cannot use the EMP_ID_SEQ sequence to populate the JOB_ID column.
- BThe EMP_ID_SEQ sequence is invalidated when you modify the EMPLOYEE_ID column.
- CThe EMP_ID_SEQ sequence is not affected by modifications to the EMPLOYEES table.
- DAny other column of NUMBER data type in your schema can use the EMP_ID_SEQ sequence.
- EThe EMP_ID_SEQ sequence is dropped automatically when you drop the EMPLOYEES table.
- FThe EMP_ID_SEQ sequence is dropped automatically when you drop the EMPLOYEE_ID column.
How the community answered
(70 responses)- A1% (1)
- B10% (7)
- C83% (58)
- E1% (1)
- F4% (3)
Explanation
the EMP_ID_SEQ sequence is not affected by modification to the EMPLOYEES table. Any other column of NUMBER data type in your schema can use the EMP_ID_SEQ sequence. Incorrect answer: A EMP_ID_SEQ sequence can be use to populate JOB_ID B EMP_ID_SEQ sequence will not be invalidate when column in EMPLOYEE_ID is modify. E EMP_ID_SEQ sequence will be dropped automatically when you drop the EMPLOYEES table. F EMP_ID_SEQ sequence will be dropped automatically when you drop the EMPLOYEE_ID
Topics
Community Discussion
6The correct answers are C and D, and they both flow from the same core Oracle concept: a sequence is an independent schema object with no structural dependency on any table or column. When you run CREATE SEQUENCE EMP_ID_SEQ, Oracle registers it in the data dictionary as its own object, completely separate from EMPLOYEES. Modifying or even dropping the EMPLOYEES table leaves EMP_ID_SEQ sitting in your schema untouched, which knocks out B, E, and F. And because a sequence just generates numeric values, nothing in Oracle's engine restricts which NUMBER column pulls from it, so JOB_ID or any other NUMBER column in your schema can call EMP_ID_SEQ.NEXTVAL just as freely as EMPLOYEE_ID can, which confirms D and refutes A. The exam topic this maps to is "Managing Schema Objects," specifically the behavior of sequences as standalone database objects. Memory hook: a sequence does not know your table exists, and your table does not know your sequence exists.
C and D are your answers here. A sequence in Oracle is a completely independent schema object, it has no physical or logical tie to any table or column you might associate it with mentally. You can use EMP_ID_SEQ to populate JOB_ID, DEPARTMENT_ID, MGR_ID, or any other NUMBER column in your schema because the sequence just generates numbers and has no idea what table or column you are inserting into. That also explains why modifying or even dropping the EMPLOYEES table leaves the sequence sitting right where it is, untouched, which rules out B, E, and F. Coming from a background where I assumed database objects were more tightly coupled than they actually are, this was a real lightbulb moment for me, and it shows up on the exam exactly because it trips up people who think logically but have not verified the actual Oracle behavior.
I froze on this one in the testing center, I literally wrote "SEQUENCE IS A FREE AGENT" on my scratch paper, meaning it floats independent of any table, any column, any drama, it just generates numbers on demand for whoever calls it, period. Picture a vending machine in the hallway, the building can get renovated, rooms can be renumbered, the whole wing can be demolished, and that vending machine just keeps dispensing snacks for anyone with the right coin, that is your sequence, which is why C and D are the winners: the sequence does not care what you do to EMPLOYEES, and any NUMBER column anywhere in your schema can slide up and use EMP_ID_SEQ like it owns the place.
C and D, though A almost got me since sequences float free.
F and C, dropping the column kills the sequence tied to it.
Hey Imani, good instinct on the sequence part, but dropping the column alone does NOT automatically drop the sequence in most engines, so F is out. C and D is the right pair because you need the DROP COLUMN step plus a separate DROP SEQUENCE step to clean house completely.