티스토리 뷰

정보처리기사20190303(교사용).docx
0.07MB

일단 정보처리기사 최근 기출문제지를 검색해봤더니 이건 뭐 죄다 한글파일이라 열어볼 수 없어서 네이버 오피스를 이용해 마이크로소프트 워드파일로 변환해 저장한 파일을 공유한다. 이 원본 파일의 출처는 "전자문제집 CBT"다. 파일은 https://www.comcbt.com/xe/j4/3434933에 가면 다운로드 받을 수 있다. 다른 파일들도 많이 있으니 더 많은 정보를 원한다면 방문하여 이용하길 바란다.

※ 저작권에 문제가 된다면 즉시 댓글 부탁드리며 확인해본 바 해설집에는 저작권이 있음을 확인했지만 교사용에는 적절할 설명을 확인하지 못하는 바, 교사용 문제지를 이용해 새로운 해설을 작성하므로 저작권에는 문제가 없을 것으로 사료되나 이 조차 문제가 되거나 본래 해설지를 작성하셨던 "좋은아빠되기"님께서 원치 않으신다면 본 포스팅을 삭제할 용의가 충분히 있으므로 댓글로 요청시 조치하겠습니다.

 

첫번째 문제부터 슬슬 확인해보자.

 

1. SQL에서 View를 삭제할 때 사용하는 명령은?

일단 SQL은 Structured Query Language의 약어로 사전에는 "구조화 질의어"라고 나와있는데 그냥 DB에서 사용하는 코딩언어라고 생각하면 되겠다. 근데 View가 뭔가하고 당황할 수도 있겠다. View라는 것은 간단하게 설명하자면 테이블들의 데이터 중 필요한 부분만 간추려서 메모리상에만 존재하는 어떤 가상의 테이블이라고 생각하면 되겠다.

이 가상의 테이블을 만드는 이유는 여러가지가 있는데 서로 떨어져 있는 테이블의 데이터를 내 입맛대로 모아서 보려면 SQL문의 JOIN 명령을 이용해야하는데 이런 SQL문의 실행 빈도가 꽤 높아서 빈번하게 호출을 해야한다면 차라리 View를 만들어서 구성을 하는게 더 이익을 볼 수 있겠다 싶을 때 만들어 사용한다고 생각하면 좋겠다. 이게 의외로 메모리를 많이 사용하므로 실무에서 View를 구성해야할 때는 꽤 많은 고민을 하고 결정하길 바란다.(보통은 DBA가 결정해주겠지만...)

 

암튼 이 문제의 답은 DROP인데 View도 일종의 테이블이라서 테이블을 삭제하는 명령인 DROP을 사용한다고 유추할 수 있다면 쉬운 문제다.

 

2. 다음 릴레이션의 Degree와 Cardinality는?

13011 홍길동 3학년 전기
13002 이순신 4학년 기계
13003 강감찬 2학년 컴퓨터

 

이 문제에서는 DB에서 테이블에서 Degree와 Cardinality의 단어 뜻을 제대로 이해하고 있는가에 대해서 질문하고 있다고 생각한다면 일단 멍청이는 아니란 소리다. 근데 Degree는 온도의 "도"를 표현할 때나 각도의 "도"를 표현할 때 사용하는 단어고 Cardinality는 무슨 단어인지 모르겠다면 일단 사전을 먼저 뒤져보는게 좋다.

 

자, 뭔놈의 DB에서 갑자기 집합의 크기(Cardinality)라는 걸 찾고 Degree라는 것을 찾는지 살짝 이해가 가지 않고 사실 실무에서도 사용하지 않는 단어라 짜증이 밀려오지만 일단 침착하게 다른 해법을 찾아보도록 하자.

 

DB에서 사용하는 카디널리티에 대한 이야기를 하자면 간단하게 "중복 값에 대한 지표" 정도로 이해하는 것이 좋다.

예를 들어 중복값이 없으면 카디널리티가 "높다". 중복값이 많으면 카디널리티가 "낮다"고 표현한다. 그래서 위의 표에서는 중복된 값이 하나도 없으므로 카디널리티가 "높다"고 이해하면 된다. 그럼 수치적으로 카디널리티는 어떻게 표현하는 것이 옳은가에 대해서 설명하자면 위의 표에서 각각의 레코드(Row: 행)가 중복되었는가에 따라 달라질텐데 다행이도 중복된 데이터 레코드가 없으므로 카디널리티는 3이 되겠다.

 

개념적으로 카디널리티는 굉장히 이해하기 힘든 개념이지만 이 문제에서는 레코드의 갯수를 카디널리티라고 대신 표현한 것이라고 보여지는 것은, 일단 테이블을 하나만 두고 카디널리티를 구하라고 한다면 1:1관계에서의 중복도를 체크하는 것이라서 레코드의 갯수를 구하라는 말이랑 같은 의미라고 파악은 되는데 이는 내 추측이다. 만약 문제에서 중복된 데이터가 존재한다면 키 무결성 제약 조건에서 깨지는 것이기 때문에 잘못된 문제가 되어버리게 되니 그렇게 이해를 한 것이지 옳은 의미로 파악한 것은 아니다.

 

Cardinality에 대한 설명으로 괜찮은 포스팅 글을 찾았으니 참고하길 바란다. 문제와는 관련이 없다.

(https://itholic.github.io/database-cardinality/)

 

Degree는 왜인지 모르겠으나 Column과 같은 의미로 사용되고 Attribute라고도 한다. 한마디로 속성 값이란 이야긴데 Degree = Column = Attribute = Field 이렇게 외워두면 편하겠다.(도데체가 왜 Degree와 Column이 같은 의미로 사용되는지 알 수가 없다. 그냥 외우자.)

 

그리고 카디널리티 묻는 시험문제에서 "중복"관련 질문이 아닌것 같다면 Cardinality = Row = Tuble = Record 이라고 외워두자.

 

그러면 정답은 Degree = 4, Cardinality = 3으로 1번 정답.

 

참고로 이 문제는 Cadinality때문에 좋은 문제라고 볼 수 없는 것이 위에서도 이야기 했지만 데이터에 대한 중복값을 알기위한 지표로써 "높다", "낮다"로 One to Many, Many to Many, One to One 과 같은 테이블간 관계에서 발생하거나 컬럼의 항목에 따른(예를 들어 "주민등록번호는 Cardinality가 높다" - 중복값이 없으므로. "성별은 Cardinality가 낮다" - 기본적으로 두가지 중 하나의 데이터를 갖기 때문에 중복된 데이터가 많아서) Cardinality의 지표를 묻는 문제였다면 쉽게 이해했겠으나 엉뚱하게 질문해서 용어의 의도와는 다르게 문제를 해석해야 하다니. 좋은 문제는 아니라고 생각한다.

 

이 문제와 관련해서 참고할 만한 포스팅은 https://coding-factory.tistory.com/77 이 곳을 방문할 것.

 

3. 모든 응용프로그램이나 사용자들이 필요로 하는 데이터를 통합한 조직 전체의 데이터베이스 구조를 논리적으로 정의하는 스키마는?

일단 스키마(Schema)가 어떤 의미인지 사전적으로 알아볼 필요가 있는데 "계획"이나 "도식"을 의미한다. 한마디로 데이터베이스의 구조를 어떻게 계획하는가에 대한 설계도를 스키마라고 이해하면 되겠다.

이 문제에서는 "조직 전체"의 데이터베이스 구조를 "논리적으로" 정의하는 스키마가 어떤 스키마인지 물어보는 건데 당연히 논리적인건데 "개념 스키마"겠지. 한마디로 말장난하는 문제다. 그래도 각 스키마가 어떤 역할을 하는지는 알아야하니 짚고 가도록 하자.

 

스키마의 정의

- 데이터베이스의 구조와 제약 조건에 대한 전반적인 명세를 기술한 메타데이터의 집합

- 데이터 개체(Entity), 속성, 관계 및 데이터 값들이 갖는 제약 조건등에 관해 전반적으로 정의

- 사용자의 관점에 따라 "외부 스키마", "개념 스키마", "내부 스키마"로 나뉨

 

  • 외부 스키마(External Schema) = 서브 스키마(Sub Schema) = 사용자 뷰(View)
    - 사용자 개인의 입장에서 필요로 하는 데이터베이스의 논리적 구조를 정의
    - 전체 데이터베이스의 한 논리적인 부분으로 볼 수 있어서 서브 스키마라고도 함
    - 하나의 데이터베이스에서는 여러개의 외부 스키마가 존재할 수 있고 하나의 외부스키마를 여러 응용 프로그램, 사용자가 공유 가능
    - SQL로 쉽게 사용 가능
  • 개념 스키마(Conceptual Schema) = 전체적인 뷰
    - 데이터베이스의 전체적인 논리적 구조로서 모든 응용프로그램이나 사용자들이 필요로 하는 데이터를 종합한 조직 전체의 데이터베이스로 "하나만" 존재함
    - 개체간의 제약조건을 나타내고, 데이터베이스의 접근 권한, 보안 및 무결성 규칙에 관한 명세를 정의
    - 데이터베이스 파일에 저장되는 데이터 형태를 나타내는 것으로 단순히 스키마라고 하면 개념 스키마를 의미한다.
    - 기관이나 조직체의 관점에서 데이터베이스를 정의
    - 데이터베이스 관리자(DBA)에 의해서 구성됨
  • 내부 스키마(Internal Schema) = 저장 스키마(Storage Schema)
    - 물리적 저장장치의 입장에서 본 데이터베이스 구조. 물리적 저장장치와 밀접한 계층
    - 실제로 데이터베이스에 저장될 레코드의 물리적인 구조를 정의하고, 저장 데이터 항목의 표현방법, 내부 레코드의 물리적 순서등을 나타냄
    - 시스템 프로그래머나 시스템 설계자가 보는 관점의 스키마

 

이런 스키마의 정의에 대한 문제는 계속 등장하니 외워둘 필요가 있다.

 

4. 병행제어의 목적으로 옳지 않은 것은?

이 질문을 풀기위해서는 병행제어가 뭔지부터 알아야한다. 병행제어란 동시에 여러 트랜젝션(Transaction)을 수행할때 DB의 일관성을 파괴하지 않도록 트랜젝션의 상호작용을 제어하는 것이다.

 

병행제어의 목적으로 아래과 같은 내용들이 있다.

 

  • DB 공유도 최대화
  • 시스템 활용도 최대화
  • 응답시간 최소화
  • 단위 시간당 트랜젝션 처리 건수 최대화
  • DB의 일관성 유지

 

병행제어의 필요성은 아래와 같다.

 

  • 갱신분실(Lost Update) - 같은 데이터를 공유하여 갱신할 때 갱신 결과의 일부가 사라지는 현상
  • 모순성(Inconsistency) - 동시에 같은 데이터를 갱신할 때 상호 불일치가 발생, 불일치 분석(Inconsistent Analysis)라고도 함
  • 연쇄 복귀(Cascading Rollback) - 트랜젝션 중 하나에 문제가 생격 Rollback되는 경우 다른 트렌젝션도 Rollback이 되어버리는 현상

병행제어 기법에 대한 내용은 나중에 다시 한번 다뤄보자.

4번의 정답은 3번이 되겠다. 데이터베이스 공유의 최소화가 아니라 최대화가 맞다.

댓글
댓글쓰기 폼