오답노트 ( 관리구문 )

 

1️⃣ 아래 데이터 모델과 같은 테이블 및 PK 제약조건을 생성하는 DDL 문장으로 가장 적절한 것은? (단, DBMS는 오라클로 가정)

[PRODUCT] (IE 표기법)

PROD_ID: VARCHAR2(10) NOT NULL

PROD_ID: VARCHAR2(10) NOT NULL

PROD_NM: VARCHAR2(100) NOT NULL REG_DT: DATE NOT NULL REGR_NO: NUMBER(10) NULL

1. CREATE TABLE PRODUCT ( PROD_ID VARCHAR2(10) NOT NULL ,PROD_NM VARCHAR2(100) NOT NULL ,REG_DT DATE NOT NULL ,REGR_NO NUMBER(10) NULL ); ALTER TABLE PRODUCT ADD PRIMARY KEY PRODUCT_PK ON (PROD_ID);
2. CREATE TABLE PRODUCT ( PROD_ID (VARCHAR2(10) ,PROD_NM VARCHAR2(100) ,REG_DT DATE ,REGR_NO NUMBER(10)); ALTER TABLE PRODUCT ADD CONSTRAINT PRODUCT_PK PRIMARY KEY (PROD_ID);
3. CREATE TABLE PRODUCT (PROD_ID VARCHAR2(10) NOT NULL ,PROD_NM VARCHAR2(100) NOT NULL ,REG_DT DATE NOT NULL ,REGR_NO NUMBER(10) NULL ,ADD CONSTRAINT PRIMARY KEY(PROD_ID));
4. CREATE TABLE PRODUCT (PROD_ID VARCHAR2(10) NOT NULL ,PROD_NM VARCHAR2(100) NOT NULL ,REG_DT DATE NOT NULL ,REGR_NO NUMBER(10) ,CONSTRAINT PRODUCT_PK PRIMARY KEY (PROD_ID));

4

❌ 1번

CREATE TABLE PRODUCT
(
  PROD_ID VARCHAR2(10) NOT NULL,
  PROD_NM VARCHAR2(100) NOT NULL,
  REG_DT DATE NOT NULL,
  REGR_NO NUMBER(10) NULL
);
ALTER TABLE PRODUCT ADD PRIMARY KEY PRODUCT_PK
ON (PROD_ID);

• 문법 오류 있음 ❌→ ADD CONSTRAINT PRODUCT_PK PRIMARY KEY (PROD_ID) 가 맞는 문법임
• ADD PRIMARY KEY PRODUCT_PK → 잘못된 순서

---

❌ 2번

CREATE TABLE PRODUCT
(
  PROD_ID VARCHAR2(10),
  PROD_NM VARCHAR2(100),
  REG_DT DATE,
  REGR_NO NUMBER(10)
);
ALTER TABLE PRODUCT ADD CONSTRAINT PRODUCT_PK PRIMARY KEY (PROD_ID);

• PROD_ID VARCHAR2(10) NOT NULL이 빠짐 → 문법 오류 ❌
• PK 제약조건은 맞게 사용되었지만 테이블 정의 자체가 잘못됨

---

❌ 3번

CREATE TABLE PRODUCT
(
  PROD_ID VARCHAR2(10) NOT NULL,
  PROD_NM VARCHAR2(100) NOT NULL,
  REG_DT DATE NOT NULL,
  REGR_NO NUMBER(10) NULL,
  ADD CONSTRAINT PRIMARY KEY(PROD_ID)
);

• ADD CONSTRAINT는 ALTER TABLE에서 사용하는 구문이고,→ 문법 오류 ❌
• 테이블 정의 내부에서는 ADD 없이 CONSTRAINT ... 만 써야 함

✅ 4번

CREATE TABLE PRODUCT
(
  PROD_ID VARCHAR2(10) NOT NULL,
  PROD_NM VARCHAR2(100) NOT NULL,
  REG_DT DATE NOT NULL,
  REGR_NO NUMBER(10),
  CONSTRAINT PRODUCT_PK PRIMARY KEY (PROD_ID)
);

• 테이블 생성문 안에 제약조건을 정의
• CONSTRAINT [이름] PRIMARY KEY ([컬럼]) 형태로 작성됨
• PROD_ID는 NOT NULL이므로 PK 조건 만족
• 문법적으로도 정확

2️⃣ 아래를 참고할 때 DELETE FROM T; 를 수행한 후에 테이블 R에 남아있는 데이터로 가장 적절한 것은?

CREATE TABLE T
(C INTEGER PRIMARY KEY,
 D INTEGER);
 
 CREATE TABLE S
 (B INTEGER PRIMARY KEY,
  C INTEGER REFERENCES T(C) ON DELETE CASADE);
  
  CREATE TABLE R
  (A INTEGER PRIMARY KEY,
   B INTEGER REFERENCES S(B) ON DELETE SET NULL);

[T]

C	D
1	1
2	1

 

[S]

B	C
1	1
2	1

 

[R]

A	B
1	1
2	2

1. (1, NULL) , (2,2)
2. (1,NULL),(2,NULL)
3. (2,2)
4. (1,1)

2

🚨 DELETE FROM T; 실행하면?

1️⃣ T의 모든 데이터가 삭제됨 → C=1, C=2 삭제

2️⃣ S.C는 T.C를 참조하므로,

→ C=1을 참조하던 S(1)과 S(2)가 삭제됨 (ON DELETE CASCADE)

❗ 즉, S 테이블 전체가 삭제됨

3️⃣ R.B는 S.B를 참조하고 있는데,

S(1)과 S(2)가 삭제되었으므로 → R의 B 값을 NULL로 설정해야 함 (ON DELETE SET NULL)

🔁 따라서 R 테이블의 두 행은 다음처럼 바뀜:

A	B
1	NULL
2	NULL

❓ "S 테이블의 기본키(PK)가 B인데, 왜 C를 기준으로 행 전체가 지워지냐?"

결론:

✅ S의 PK(B)가 뭐든 상관없이,

외래키로 참조 중인 C에 ON DELETE CASCADE가 걸려 있으면,

T의 C값이 삭제될 때 그 값을 참조하던 S의 '행 전체'가 삭제돼.

---

🔍 왜 그런가?

기본 키(PK)는 행을 유일하게 식별하는 용도고,

외래 키(FK)는 다른 테이블을 참조하는 제약조건이야.

CREATE TABLE S (
  B INTEGER PRIMARY KEY,  -- 기본키: 행의 고유 ID
  C INTEGER REFERENCES T(C) ON DELETE CASCADE  -- 외래키: T의 C 참조
);

여기서:

• B는 PK → 행을 구분하기 위한 용도
• C는 FK → T.C를 참조, 그리고 ON DELETE CASCADE 설정

---

🔥 핵심 작동 원리

• ON DELETE CASCADE는 말 그대로
• 👉 참조 대상(T)의 특정 값이 삭제되면 → 그 값을 참조 중인 S의 '행 전체'를 삭제

➡ 이 동작은 S의 PK가 어디에 있든지 관계없어!

---

💬 비유로 쉽게 설명하면

🧱 T 테이블은 건물의 "기초" 같은 거야

🧱 S 테이블은 그 위에 올라간 구조물

• S.C는 T.C라는 기반 위에 만들어진 구조
• 그런데 T.C가 삭제되면 → **그 위에 올려진 전체 구조(S의 행)**도 무너뜨리는 게 CASCADE

---

🔥 핵심 정리

구성요소	역할
FK (REFERENCES)	"이 컬럼은 다른 테이블 값을 참조한다"는 설정
CASCADE (ON DELETE)	"참조 대상이 삭제되면 나도 같이 삭제하겠다"는 행동 지정

➡ 이 둘이 합쳐졌기 때문에 S 테이블의 행들이 전부 삭제된 거야.

3️⃣ 아래 SQL의 실행 결과로 가장 적절한 것은?

[T1]

COL1	COL2
1	AAAA
1	AAAA
1	AAAA
1	BBB

SELECT COUNT(COL1) AS CNT1, COUNT(COL2) AS CNT2
FROM ( SELECT DISTINCT COL1, COL2
			 FROM T1
		 );

1. 4,2
2. 2,2
3. 1,2
4. 4,4

2

 

해설

SELECT 절에 DISTINCT 키워드를 사용하면, 중복된 데이터는 1건으로 처리하여 출력한다

다만, SELECT 절의 DISTINCT 키워드 뒤에 여러 개의 칼럼이 올 경우, 주어진 칼럼 값이 모두 동일한 행들만 중복 건으로 처리된다.

4️⃣ SQL에서 사용되는 표준 데이터 타입으로 가장 적절하지 않은 것은? (DBMS는 오라클로 가정)

1. TEXT
2. CHAR
3. VARCHAR2
4. NUMBER

1

 

해설

1. ❌ TEXT

• ✅ 표준 SQL 타입이 아님
• 일부 DBMS(예: MySQL, PostgreSQL)에서는 사용 가능
  • MySQL: TEXT, TINYTEXT, MEDIUMTEXT, LONGTEXT 등 있음
• 📛 하지만 SQL 표준에는 존재하지 않는 데이터 타입이므로 오답!

---

2. ✅ CHAR

• SQL 표준 데이터 타입
• 고정 길이 문자형
• 예: CHAR(10) → 10자 고정

---

3. ✅ VARCHAR2

• ❗ Oracle 전용 데이터 타입이지만,
• Oracle에서는 사실상 VARCHAR 대신 VARCHAR2를 권장하고 표준처럼 사용함
• 표준 SQL은 VARCHAR가 맞지만, 대부분 시험에서는 Oracle 기준으로 허용

💡 참고: VARCHAR2는 Oracle에서 VARCHAR의 미래 호환성을 위해 만든 안정된 타입

---

4. ✅ NUMBER

• SQL 표준에 포함되는 숫자형 타입
• Oracle에서는 NUMBER(p,s) 형태로 정밀도 지정 가능

5️⃣ 관계형 데이터베이스에서 자식 테이블의 FK 데이터 생성시 부모 테이블에 PK가 없는 경우, 자식 테이블 데이터 입력을 허용하지 않는 참조동작은(Referential Action)?

1. CASCADE
2. RESTRICT
3. AUTOMATIC
4. DEPENDENT

4

 

해설

DELETE ACTION

CASCADE	Master 삭제 시 CHILD 같이 삭제
SET NULL	Master 삭제 시 Child 해당 필드 Null
SET DEFAULT	Master 삭제 시 Child 해당 필드 Default 값으로 설정
RESTRICT	Child 테이블에 PK 값이 없는 경우만 Master 삭제 허용
NO ACTION	참조무결성을 위반하는 삭제/수정 액션을 취하지 않음

 

INSERT ACTION

AUTOMATIC	Master 테이블에 PK가 없는 경우 Master PK를 생성 후 Child 입력
SET NULL	Master 테이블에 PK가 없는 경우 Child 외부키를 Null 값으로 처리
SET DEFAULT	Master 테이블에 PK가 없는 경우 Child 외부키를 지정된 기본값으로 입력
DEPENDENT	Master 테이블에 PK가 존재할 때만 Child 입력 허용
NO ACTION	참조무결성을 위반하는 입력 액션을 취하지 않음

 

6️⃣ 아래를 참고할 때 오류가 발생하는 SQL은?

[BOARD]

BOARD_ID: VARCHAR2(10) NOT NULL

BOARD_NM: VARCHAR2(50) NOT NULL USE_YN: VARCHAR2(1) NOT NULL REG_DATE: DATE NOT NULL BOARD_DESC: VARCHAR2(100) NULL

1. INSERT INTO BOARD VALUES(1, ‘Q&A’, ‘Y’, SYSDATE, ‘Q&A 게시판’);
2. INSERT INTO BOARD (BOARD_ID, BOARD_NM, USE_YN, BOARD_DESC) VALUES (’100’,’FAQ’,’Y’,’FAQ 게시판’);
3. UPDATE BOARD SET USE_YN = ‘N’ WHERE BOARD_ID = ‘1’;
4. UPDATE BOARD SET BOARD_ID = 200 WHERE BOARD_ID = ‘100’;

2

 

해설

REG_DATE 조건에 NOT NULL이 있지만 INSERT INTO 구문에 REG_DATE 칼럼이 대입되지 않아 NULL이 입력되므로 오류가 발생함

✅ 1. NUMBER 컬럼에 입력할 때

입력	값	의미	가능 여부 설명
1	숫자	✅ 가능	숫자 그대로 입력 (권장)
'1'	문자열	✅ 가능 (주의)	오라클이 암시적으로 TO_NUMBER('1') 변환

🔸 '1'도 숫자로 자동 변환되기 때문에 오류는 나지 않지만,

문자열이 숫자로 변환 안 될 경우(예: 'abc')는 오류 발생함.

INSERT INTO table_name (num_col) VALUES (1);     -- ✅ 안전
INSERT INTO table_name (num_col) VALUES ('1');   -- ✅ 가능하지만 추천 안 함
INSERT INTO table_name (num_col) VALUES ('abc'); -- ❌ 오류 발생

📌 정리: NUMBER에는 숫자형 리터럴(예: 1, 3.14)을 직접 쓰는 게 안전하고 명확함.

---

✅ 2. DATE 컬럼에 입력할 때

입력	값	의미	가능 여부 설명
'2024-01-01'	문자열	⚠️ 조건부 가능	기본 날짜 형식과 맞으면 OK
DATE '2024-01-01'	날짜 리터럴	✅ 권장	ISO 표준 날짜 형식
TO_DATE('2024-01-01', 'YYYY-MM-DD')	명시적 변환	✅ 권장	포맷 지정 가능

-- 올바른 방법
INSERT INTO table_name (date_col) VALUES (TO_DATE('2024-01-01', 'YYYY-MM-DD'));
INSERT INTO table_name (date_col) VALUES (DATE '2024-01-01'); -- ISO 방식

-- 시스템 NLS_DATE_FORMAT이 'YYYY-MM-DD'일 때만 가능
INSERT INTO table_name (date_col) VALUES ('2024-01-01'); -- ⚠️ 환경에 따라 오류

 

📌 정리: DATE는 무조건 문자열이 아님

반드시 TO_DATE 함수나 DATE 'YYYY-MM-DD' 리터럴을 쓰는 게 안전하고 정확함.

✅ 3. VARCHAR2 컬럼에 입력할 때

오라클은 INSERT나 WHERE절에서 데이터 타입이 암시적으로 변환(implicit conversion)되는 걸 허용하기 때문이야.

• 숫자 1 → 문자열 '1'
• 이건 오라클 내부에서 자동으로 TO_CHAR(1)처럼 바꿔줌.

---

📌 예시

CREATE TABLE test_table (
  name VARCHAR2(10)
);

-- 작은 따옴표 없이 숫자 입력
INSERT INTO test_table (name) VALUES (1);

-- 조회하면 '1'이라는 문자열로 저장됨
SELECT * FROM test_table;

7️⃣ 아래를 참고할 때 오류가 발생하는 INSERT문으로 가장 적절한 것은?

CREATE TABLE 주문 (
주문번호 NUMBER PRIMARY KEY,
주문일자 DATE NOT NULL,
회원번호 NUMBER,
주문상태코드 VARCHAR2(3) DEFAULT '000'
);

1. INSERT INTO 주문(주문번호, 주문일자, 회원번호, 주문상태코드) VALUES(1, SYSDATE, 1900123,’002’);
2. INSERT INTO 주문(주문번호, 주문일자, 회원번호, 주문상태코드) VALUES(2, ‘20190301’,1900124,’001’);
3. INSERT INTO 주문(주문번호, 주문일자, 회원번호, 주문상태코드) VALUES(3, SYSDATE-1,1900125,’001’);
4. INSERT INTO 주문(주문번호, 주문일자, 회원번호, 주문상태코드) VALUES(4,20190302,1900126,’001’);

4

해설

오라클 암시적 타입 변환 정리표

변환방향	입력 타입 → 대상 타입	변환 예시	설명
문자열 → 숫자	'123' → NUMBER	INSERT INTO num_col VALUES('123');	문자열이 숫자로 바뀜. 'abc'는 오류
숫자 → 문자열	123 → VARCHAR2	INSERT INTO varchar_col VALUES(123);	자동으로 '123'으로 변환되어 저장됨
문자열 → 날짜	'2024-05-19' → DATE	INSERT INTO date_col VALUES('2024-05-19');	시스템 NLS_DATE_FORMAT과 일치해야 정상 동작
날짜 → 문자열	SYSDATE → VARCHAR2	`SELECT '날짜: '
숫자 → 날짜	12345 → DATE	잘 사용 안 됨 (거의 오류)	명시적 변환 필요 (TO_DATE, TO_CHAR 등)