데이터 조작 프로시저

정보처리기사 필기 준비하며 정리한 내용입니다.

데이터 조작 프로시저 작성

프로시저

• 데이터베이스 안에 저장된 하나의 일처리하는 단위
  • DB내부에 있는 쿼리문을 이용하여 프로그램을 짜놓은 것
  • 쿼리의 집합
    • 데이터 주고받는 과정을 모아서 함수로 만든 것
  • 데이터베이스 내부에서 돌아가는 프로그램의 단위이다

저장 프로시저의 범위

1. Stored Function
   • 무조건 리턴값이 있는 것
     • 데이터베이스에서 계산한 것만 돌려주면 됨 (대부분)
   • 인자값 전달할 땐 In Out Inout 세가지
     • 주기만하고 받아오고 넣을수도있고뺄수도있고
       • 이중에서 IN만 사용가능하다 (받아올 수만 있다)
   • CREATE OR REPLACE FUNCTION function_name
     • CREATE FUNCTION만 있다면? 무조건 생성만 시킴
     • OR REPLACE는 만약 그 function이 존재하면 재정의를 한다는 뜻
       • 따라서 없으면 만들어주고, 있으면 재정의하라는 뜼
2. Stored Procedure
   • 리턴값이 있어도 되고 없어도 되고
   • 하나의 절차를 수행하는 함수 같은 것
     • PL/SQL블록 (SQL이 수행되는 절차들을 쭉 만들어놓은 것)
       • SQL들의 덩어리!
   • IN OUT INOUT 다 할 수 있다!
   • CREATE OR REPLACE PROCEDURE procedure_name
3. Stored Package
   • 관련있는 것들을(위의 것들 중에) 묶어놓은 폴더의 개념
4. Trigger ⭐
   • INSERT, UPDATE, DELETE문이 TABLE에 대해 행해질 때 = 이벤트를 발생시켰을 때
     • 묵시적으로 (알아서 자동으로) 수행되는 프로시저
     • SELECT는 이벤트가 아니다!! (그 안에서 가지고 오는 거라
   • 테이블과 별도로 데이터베이스에 저장
   • VIEW에 대해서가 아니라 TABLE에 관해서만 정의될 수 있다
     • 뷰는 물리가 아니라 가상의 테이블이라서
       • 3과목에서 자세히 다룬다!!
   • 종류
     1. 행 트리거
        • FOR EACH ROW라는 옵션을 사용한다
        • 각각의 행에 데이터 변화가 생길때마다 실행된다
          • ex. INSERT가 발생하면 각각의 행 단위로 뭔가 수행이 되는 것
     2. 문장 트리거
        • 위의 옵션을 안 붙이면 이게 수행된다.
        • 모든 게 다 끝나고 나서(트리거 사건에 의해) 한 번 수행되는 것
          • 각각의 행 제어하는 게 X

📌ORM 프레임워크

object-relational mapping

• 객체와 관계형 데이터베이스의 데이터를 자동으로 매핑(연결)해준다
  • 쿼리만 갖고오면 됨 (XML로 만든다)
• 객체지향프로그램으로 데이터베이스의 데이터를 다룬다
• 장점
  • 비즈니스 로직에 더 집중할 수 있다
    • 비즈니스 로직이란?
      • 일처리. 예를들어 입금하고 입금된 돈을 확인하고
  • 재사용 및 유지보수 편리성 증가
• 단점
  • 완벽한 ORM으로만 서비스 구현하기 어렵다
    • 복잡한 쿼리는 이걸 이용하기 어렵다
  • 프로시저가 많으면 ORM의 장점 활용이 어렵다
    • 프로시저는 매핑이 안된다

매핑 기술 비교

1. SQL Mapper
   • SQL을 명시하여 단순히 필드 매핑이 목적
   • SQL문장으로 직접 데이터베이스 데이터 다룬다
   • 실무에서 많이 쓴다
   • iBatis, Mybatis, jdbc Templetes 등
2. OR Mapping (=실질적인 ORM)
   • 객체를 통해 간접적으로 데이터베이스 다룬다
   • 객체와 관계형 데이터베이스 자동으로 매핑
   • SQL 쿼리가 아닌 직관적인 코드로 데이터 조작 가능
     • 쿼리가 아닌 프로그램으로 데이터 주고받을 수 있다!
   • JPA, Hibernate 등

 

---

 

데이터 조작 프로시저 최적화

최적화 = 튜닝

데이터베이스를 이용하는 이유 : 빨리 가져오기 위해서

1) Query 성능 측정 및 개선

• 성능 측정 대상
  • 이벤트 쿼리(INSERT 등)는 성능 측정 대상이 아니다.
  • SELECT를 가지고 한다!
    • 빨리 찾아야 빨리 가져올 수 있으니까
      • 최적의 경로(실행 쿼리)를 설정해야 한다
      • 프로그램이 느린 게 아니라 데이터베이스에 접속해서 데이터를 가져오는 시간이 느려지는 것
        • 보통 어떤 사이트가 느려지는 경우는 WAS가 감당을 못하는 경우도 있지만 데이터베이스에 연결하는 자원의 한계 때문

SQL 처리 흐름

SQL → 옵티마이저(구문분석→실행→인출 수행) → 결과

• 옵티마이저 : 최적 경로 탐색기(최소한의 비용)
  1. 구문분석
     • 이미 했는지 확인해보기 (했으면 건너뜀)
     • 구문 오류 분석, 실제로 SQL내에 포함된 테이블 뷰 등이 데이터베이스에 존재하는지 확인
  2. 실행
     • 이미 실행이 되어있는지 = 버퍼캐시 영역에 존재하는지 확인
       1. 이미 실행되어있으면 인출까지 갈 필요X 캐시영역의 데이터 그대로 추출
       2. 버퍼영역에 데이터가 없다면!
          • 데이터버퍼 캐시영역에 저장 → 인출
  3. 인출(추출)
     • 실제로 데이터를 전달하는 과정
       • 실제 데이터베이스 표에서 데이터를 가지고 온다
     • SELECT만 인출단게까지 수행하고 나머지는 그 전단계(실행)까지 수행

SQL 성능 개선 절차

1. 문제있는 SQL 식별
   • 쿼리문에 문제가 있는 거라서!
2. 옵티마이저 통계 확인
   • 통계도구를 이용해서 확인
3. SQL문 재구성
   • 함수 쓰면 느려지니까 줄여보고
   • 힌트를 이용
     • 힌트란?
       • ex. 이 테이블에 3개의 인덱스가 있는데 a인덱스를 타면 원하는 작업을 수행할 수 있다!라는 힌트를 주는 것
     • 최적의 인덱스를 태울 수 있는 방법 = 힌트를 준다
4. 인덱스 재구성
   • 인덱스란?
     • 색인 테이블. 여러개의 인덱스를 만들 수 있다.
   • 3~4번은 바뀌어도 OK
5. 실행계획 유지 관리
   • 위의 절차로 성능이 괜찮아지면 유지 관리

 

2) 소스코드 인스펙션

• 동료검토(짝프로그래밍과 관련)
• 워크스루(자료 미리 배포하고 회의)
• 인스펙션(개발자 빠지고 전문가 그룹에게 검토받음)
• → 문제가 있다면 리팩토링 작업하게 된다.

인스펙션이란

• 전문가 그룹들이 소스코드 검토하는 것

•  

코드 인스펙션 절차 ⭐

1. 계획 : 대상, 검토항목 정하기
2. 개관(사전교육)
3. 준비 : 자료 검토
4. 검사(인스펙션 회의) : 실제 회의
5. 재작업(수정) : 문제점수정 = 리팩토링
6. 추적(후속조치) : 리팩토링이 다른 영향을 미치지 않는지 추적