22. 06. 02 - [ 4차 시험! - SQL활용 TEST ], [ DB 모델링 관련 TIP ]

 

 

4차 TEST 진행!

 

 

이번 시험 과목은 SQL 활용 파트

 

1. 서술형
2. 문제 해결 시나리오

 

 

 

 

 

 

 

 

 

미니 프로젝트에서도 사용해보고, 시험 준비도 하고  

프로그래머스 사이트를 이용하여 여러 문제도 풀어보고 해서

 

자신감 뿜뿜

 

 

 

 

 

 

서술형 문제 파트

• [ CREATE, ALTER, DROP 문의 개념 설명 ]
• [ NUMBER, TO_CHAR, INITCAP, INTERSECT 개념 설명 및 쿼리 작성 ]
• [ JOIN, GROUP BY, ROLLUP, CUBE 관련 내용 들 ]
• 정도로 나온 기억..

 

 

 

문제 해결 시나리오 파트

• [ SELECT 가 아닌 HAVING을 사용해서 쿼리를 수정해야 하는 문제  ]
• [ 서브 쿼리를 이용하여 정렬한 후 ROWNUM으로 원하는 만큼 뽑아내기 ]

 

 

 

 

---

 

 

 

 

 

 

헷갈렸던 부분들도 있지만 확실히 여러 문제를 풀어보아서 그런지 

쿼리를 작성하고, 문제점을 찾아 해결하는데 

개념을 잡기가 좋았다 ㅎㅎ

 

 

 

 

 

그래서 점수는!!!

 

 

 

 

 

 

서술형 94점! 

문제 해결 100점!

 

 

 

 

 

서술형에서 개념 설명하는 부분에서 키워드가 빠져있어서

2문제에서 부분 감점당하였다.

 

 

 

 

 

#1 INITCAP 함수는 첫 글자를 대문자로 바꿔주는 역할 

빠진 키워드는 - 영문자일 경우 // 나머지는 소문자로 바꿔준다.

 

 

 

 

#2 INTERSECT 연산자

빠진 키워드 - SELECT 결과

선행 SELECT 결과에서 // 다음 SELECT 결과와 겹치는 부분만을 추출

조건의 결과 / 행 / 열 / 이런 거는 애매해서 부분 점수 처리

 

 

 

---

 

 

 

INTERSECT 부분은 좀 아쉬웠지만

INITCAP 함수는

몰랐던 부분이라 새롭게 배웠다.

 

 

 

저번 TEST에서 불안한 떨림을

실력 확인의 설렘으로 만들고 싶다 했었는데 

이번 시험에서 잘 이루어진 것 같아서 뿌듯하다.

 

 

 

 

 

---

 

 

 

 

남은 시간은 

 

DB모델링에 대해서 생각해 볼 여러 가지 내용들에 대해서 알아보았다.

 

 

 

 

1. 기본키

• 시퀀스를 이용하여 넘버링하는 것이 안전하다.

 

 

---

 

 

2. 외래키

• 비식별(분홍 키)로 연결해보고 안 되겠네 판단되면 식별키(파란 키)로 해서 변경해주는 것을 추천
• 연결을 반드시 해야 한다고 생각하지 말자
• 연결을 반드시 해주어야 하는 경우는 다대다 관계의 경우를 해소해야 할 경우 가운데 테이블을 끼워 넣어야 하는 경우
• 다대다 관계가 있을 시 물리적으로 실행 안 된다.

 

 

 

---

 

 

3. 칼럼 값으로는 넘버링된 애들 사용하는 것이 좋다.

 

 

 

 

 

 

회원 각각의 grade 칼럼마다 bronze라는 긴 문자열 필요하다. - 자원 낭비

grade 관련 테이블 만들어 놓고

실제 회원 정보에서 grade 칼럼에는 넘버링된 1,2,3 사용!

join 해서 찾아낼 수도 있다.

 

 

+@ '1-bronze'에서 --- 변경 --->  '1-아이언' 

• -- 칼럼에 bronze라고 입력해주어야 했으면 모든 칼럼에서 아이언으로 변경하는 작업 필요
• -- but
• -- 따로 분리 시 grade테이블에서 1번 아이언으로만 변경하면 됨

 

 

---

 

 

4. 생년월일, 전화번호는 고정 형으로 하는 것이 좋다.

 

 

---

 

 

5. 관리자 계정은 따로 관리

 

•  굳이 회원 테이블에 끼어서 관리하는 것보다.
• 관리자 사원 테이블을 따로 만들어서 관리하는 것이 좋다.

 

 

 

 

 

관리자 몇 명 때문에 몇 만 명의 회원들이 ADMIN_YN 칼럼의 값을 가지고 있어야 한다. -- 비효율적

 

 

 

---

 

 

6. NULL 칼럼이 너무 많으면 좋지 않다.

• 위와 같은 맥락
• 관리자가 아닌 회원들은 다 NULL 값을 가진다 – 좋지 않다.
• 모델링 다시 짜는 것 생각해볼 필요 있다.

 

 

---

 

 

7. 삭제 처리 시DELETE 쿼리보다는 칼럼으로 삭제 처리하는 것이 좋다.

• 탈퇴, 재학여부 등
• DELETE 해버리면 복구 안된다. 언제 어떤 일이 생길지 모른다.
• 경찰들이 와서 데이터 좀 봅시다. 하는 실제 경험도 있으시다고..

 

 

---

 

 

8. 조인을 통해 얻을 수 있는 칼럼은 없앨 것

 

 

 

 

주문테이블에 – 상품명은 있을 필요 없다.

• IF) JOIN 중첩으로 많이 사용하는 경우 – 상황에 맞춰 판단
• 상황1) 이 쿼리가 호출될 빈도를 생각하여서 – 자주 호출된다 하면 – 테이블로 만들어 버리기 - 공간을 더 사용하게 되지만 효율을 높인다.
• 상황 2)이 쿼리가 일정 시간마다 호출된다. - 자주 호출되지 않는다. - 조인 중첩 괜찮다.

 

 

 

---

 

 

9. 칼럼명은 가능한 일반적으로 ( || 코멘트 사용 )

• 너무 전문적으로, 너무 축약해서, 너무 다른 개념으로 정하지 않기.

 

 

 

 

 

• DB 관련 테이블도 엑셀로 작성하는 경우가 많다.
• 실무에서 엑셀로 많이 사용
• DB 관련 자료는 – 개발자만 보는 것이 아닌, 다른 협업자들도 보기 때문에 엑셀 접근성 좋음

 

 

---

 

 

10. 다른 칼럼의 연산으로 얻을 수 있는 결과는 칼럼 생성 노노 - 공간 아깝다.

 

• 상품 TABLE -- 상품번호, 상품명, 상품 가격, 재고
• 주문 TABLE — 주문번호, 상품번호, 주문 개수, 총 가격

 

• 총가격이라는 칼럼을 굳이 만들 필요 없이.
• 상품번호를 이용 — 상품 가격을 얻어오고 – 주문 개수를 곱하면 된다.

 

 

 

 

 

---

 

 

 

 

 

REVIEW


정해진 정답이 없는 DB의 쿼리와 모델링
상황에 맞춰, 조건에 맞춰
공간을 적절하게 사용하며, 효율적으로 작동할 수 있게
고민하는 것이 정답인 듯.


어느덧 4차 시험까지 진행되어버린 진도.

이제 남은 DB진도와 JAVA구조 짜는 법을 배우고
프론트 앤드쪽으로 넘어갈 거 같다.

차근차근 배워나가면서
지금의 감각을 잊지 않도록 유지하는 것이 중요할 것 같다.

망각하고 기억하고 망각하고 기억하고
망기 망기 공부법으로
단기 기억에서 장기기억으로 남도록
노력해보자!