[정보처리기사 필기] 2022 기사패스 정보처리기사 기출문제 상세풀이 800제 : 401 ~ 450 오답정리

404. 객체지향 기법의 구성 요소

  • 메서드 (Method)
    • 객체가 수행하는 기능
    • 객체가 갖는 데이터 (속성, 상태)를 처리하는 알고리즘
  • 모듈 (Module)
    • 실행 코드와 객체들의 묶음
  • 객체 (Object
    • 데이터와 데이터를 처리하는 함수를 캡슐화한 소프트웨어 모듈
    • 클래스의 인스턴스, 자신 고유의 데이터(객체 정보, 속성, 상태)를 가지며 클래스에서 정의한 함수(객체가 수행하는 기능)를 수행
  • 클래스 (Class)
    • 공통된 특성과 연산을 갖는 객체의 집합
    • 같은 종류의 집단에 속하는 속성과 행위를 정의한 것
    • nstance : 클래스에 속한 각각의 객체
  • 메시지 (Message)
    • 객체들 간 상호작용을 하는데 사용되는 수단
    • 객체에게 행위지시를 하는 명령 : 객체 간의 통신
    • 객체 이름, 메소드 이름, 인자로 구성

 

405. 객체지향의 특징

  • 캡슐화 (Encapsulation)
    • 속성(데이터)과 메소드(연산)을 하나로 묶어서 객체로 구성
    • Readability 향상 : 유지보수 용이
    • 재사용성이 높은 S/W 개발 가능
    • 내부자료의 일관성 유지
    • 객체간 인터페이스를 이용, 종속성 최소화
  • 추상화 (Abstraction)
    • 공통 성질을 추출하여 슈퍼 클래스로 구성
    • 객체 중심의 안정된 모델 구축
    • 현실 세계를 자연스럽게 표현
    • 분석의 초점 명확
  • 다형성 (Polymorphism)
    • 동일한 이름의 여러 오퍼레이션(메소드)을 다른 사양으로 정읙 ㅏ능
    • 오버로딩 : 매개변수의 수 또는 타입을 달리하여 구분
    • 오버라이딩 : 부모클래스의 메서드를 재정의
  • 정보은닉 (Information Hiding)
    • 캡슐화된 항목을 다른 객체로부터 숨김
    • 메시지 전달에 의해 다른 클래스 내의 메서드가 호출
  • 상속성 (Inheritance)
    • 부모 클래스의 속성과 메서드를 상속받아 사용
    • 부모와 자식 클래스 간의 관계가 슈퍼클래스와 서브클래스로 유치
    • 부모 클래스는 추상적, 자식 클래스는 구체적 성질

 

406. GoF의 디자인 패턴

  • 디자인 패턴의 개념
    • 소프트웨어 공학론 안의 좋은 코드를 설계하기 위한 일종의 설계 방법론
      • 좋은 코드 : 객체 간 응집도 높음, 결합도는 낮음, 요구사항 변경 시 코드 변경을 최소화할 수 있는 코드
    • 소프트웨어 설계 패턴 : 반복적으로 발생하는 문제에 대해 미리 만들어진 솔루션으로 설계의 재사용을 통해 생산성 향상을 위한 기법
    • 패턴 : 각기 다른 소프트웨어 모듈이나 기능을 가진 다양한 응용 소프트웨어 시스템들을 개발할 때도 서로 간에 공통되는 설계 문제가 존재하며 이를 처리하는 공통적인 해결책
  • 디자인 패턴의 분류
    • 생성 패턴
      • 객체의 생성 방식을 결정하는 패턴
      • 생성 패턴의 종류
        • Factory method (Virtual Constructor)
          • 객체를 생성하기 위해 인터페이스를 정의
          • 어떤 클래스의 인스턴스를 생성할지에 대한 결정은 서브 클래스가 내리도록 함
        • Singleton
          • 오직 한 개의 클래스 인스턴스만을 갖도록 보장, 이에 대한 전역적인 접근점을 제공
        • Abstract factory (Kit)
          • 상세화된 서브 클래스를 정의하지 않고도 서로 관련성이 있거나 독립적인 여러 객체의 군을 생성하기 위한 인터페이스를 제공
        • Builder
          • 인스턴스를 생성자를 통해 직접 생성하지 않고, 빌더라는 내부 클래스를 통해 간접적으로 생성
        • Prototype
          • 원본을 만들어 놓고 원본 객체(인스턴스)를 복사하여 사용
    • 구조 패턴
      • 객체를 조직화하는데 유용한 패턴
      • 구조 패턴의 종류
        • Adapter (Wrapper)
          • 클래스의 인터페이스를 사용자가 기대하는 인터페이스 형태로 적응(변환)
          • 서로 일치하지 않는 인터페이스를 갖는 클래스들을 함께 동작
        • Bridge (Handle/Body)
          • 구현에서 추상을 분리하여 각자 독립적으로 다양성을 가질 수 있도록 함
        • Composite
          • 부분과 전체의 계층을 표현하기 위해 객체들을 모아 트리 구조로 구성
          • 사용자가 개별 객체와 복합 객체를 모두 동일하게 다룰 수 있도록 하는 패턴
        • Decorator
          • 객체에 동적으로 새로운 책임을 추가할 수 있게 함
          • 기능을 추가하려면, 서브 클래스를 생성하는 것보다 융통성 있는 방법 제공
        • Facade
          • 서브 시스템에 있는 인터페이스 집합에 통합된 하나의 인터페이스 제공 : 의사소통 및 종속성 최소화 목표
          • 서브 시스템을 좀 더 쉽게 사용하기 위해 상위 수준 인터페이스 정의 
        • Fly weight
          • 객체의 내부에서 참조하는 객체를 직접 만드는 것이 아니라, 없다면 만들고, 만들어져 있다면 객체를 공유하는 식으로 객체를 구성하는 방법
        • Proxy (Surrogate)
          • 실제 기능을 수행하는 객체 대신 가상의 객체를 사용해 로직의 흐름을 제어
    • 행위 패턴
      • 객체의 행위를 조직, 관리, 연합하는데 사용하는 패턴
      • 행위 패턴의 종류
        • Template method
          • 어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화해 전체 일을 수행하는 구조는 바꾸지 않으면서 특정 단계에서 수행하는 명세를 변경
        • Interpreter (Cursor)
          • 주어진 언어에 대해서 문법을 위한 표현 수단을 정의
          • 해당 언어로 된 문장을 해석하는 해석기를 사용하는 패턴
        • Iterator
          • 내부 표현부를 노출하지 않고 어떤 객체 집합의 원소들을 순차적으로 접근하는 방법을 제공하는 패턴
        • Command (Action, Transaction)
          • 실행될 기능을 캡슐화함으로써 주어진 여러 기능을 실행할 수 있는 재사용성이 높은 클래스 설계 패턴
        • Chain of Responsibilty
          • 요청을 처리하는 기회를 하나 이상의 객체에 부여하여 요청을 보내는 쪽과 받는 쪽의 결합을 피하는 패턴
          • 요청을 받는 객체를 연쇄적으로 묶고 객체를 처리할 수 있을 때까지 요청 전달
        • State (Object For State)
          • 객체의 내부 상태에 따라 객체의 행위 내용을 변경
        • Strategy (Policy)
          • 행위를 클래스로 캡슐화해 동적으로 행위를 자유롭게 바꿀 수 있게 해줌
        • Mediator
          • 한 집합에 속해 있는 객체들의 상호 작용을 캡슐화하는 객체를 정의하는 패턴
          • 중재자는 객체들이 직접 서로 참조하지 않도록 함으로써 객체 간의 느슨한 연결을 촉진하며 객체들의 상호작용을 독립적으로 다양화시킬 수 있도록 해줌
        • Memento (Token)
          • 객체의 상태 정보를 저장하고 사용자의 필요에 따라 원하는 시점의 데이터를 복원할 수 있는 패턴
        • Visitor
          • 객체 구조를 이루는 원소에 대해 수행할 연산을 표현
          • 방문자는 연산에 적용할 원소의 클래스를 변경하지 않고 새로운 연산을 재정의할 수 있음
        • Observer (Dependent, Publish-Subscribe)
          • 한 객체의 상태 변화에 따라 다른 객체의 상태도 연동되도록 일대 다 객체 의존 관계를 구성

 

408. 소프트웨어 아키텍처의 품질 속성의 종류

  • 시스템 품질 속성
    • 가용성 (Availability) :시스템을 장애없이 제공할 수 있는 속성
    • 성능 (Performance) : 시스템에 이벤트가 발생했을 때, 이를 적절하고 신속하게 처리하는 속성
    • 사용성 (Usability) : 사용자가 시스템을 사용하는데 불편함 없이 명확하고 편리하게 구현하는 속성
    • 변경 용이성 (Modifiability) : 시스템이 처음 설계 목표와 다른 하드웨어나 플랫폼에서도 동작할 수 있도록 구현하는 속성
    • 보안성 (Security) : 시스템에 허용되지 않은 접근을 막고, 허용된 접근에는 적절한 서비스를 제공하는 속성
    • 확장성 (Scalability) : 시스템의 용량, 처리 능력 등을 확장시켰을 때 이를 효과적으로 활용할 수 있도록 구현하는 속성
    • 기능성 (Functionality) : 시스템을 사용자의 요구기능을 만족하도록 구현하는 속성
  • 비즈니스 품질 속성
    • 시장 적시성 : 정해진 시간에 맞춰 프로그램을 출시
    • 비용과 혜택 : 개발 비용을 더 투자하여 유연성이 높은 아키텍처를 만들 것인지 결정
    • 예상 시스템 수명 : 시스템 사용기한 고려 (변경 용이성 + 확장성)
  • 아키텍처 품질 속성
    • 개념적 무결성 : 시스템을 이루는 구성 요소들 간의 일관성 유지
    • 정확성과 완결성 : 요구사항을 구현하기 위해 발생하는 제약사항들을 모두 충족
    • 구축 가능성 : 모듈 단위로 구분된 시스템을 적절하게 분배하여 유연하게 일정을 변경

 

412. 소프트웨어 아키텍처 스타일

  • 소프트웨어 아키텍처 스타일의 개념
    • 아키텍처 설계에서 반복해서 나타나는 문제를 해결하고 아키텍처가 만족시켜야 하는 시스템 품질 속성을 달성할 수 있는 방법을 정리한 문서
  • 소프트웨어 아키텍처 스타일의 종류
    • 클라이언트 서버 구조 : 다수의 클라이언트와 하나의 서버로 구성되고 서버는 클라이언트에 서비스를 제공하며 데이터를 관리하는 역할을 함
    • 계층 구조 : n-Tier 모델, 각 서브 시스템이 하나의 계층이 되고 하위층이 제공하는 서비스를 상위층의 서브 시스템이 이용할 수 있는 구조
    • MVC 구조 : 3개의 서브시스템(모델, 뷰, 컨트롤러으로 구성, 자료의 저장, 제어 기능과 표현 기능을 분리하여 재사용성을 높여줌
    • 파이프-필터 구조 : 서브시스템이 입력 데이터를 받아 처리하고 결과를 다음 서브시스템으로 넘겨주는 과정을 반복

 

415. UML 모델의 관계

  • 일반화 관계 (is-a) Generalization
    • 객체지향 개념에서 상속관계
    • UML에서는 일반화 관계로 모델링
    • 한 클래스가 다른 클래스를 포함하는 상위 개념
    • 상위와 하위 관계를 의미하며 하위는 상위의 공통점을 상속
    • 클래스를 상속받아 자식 클래스에서 사용
  • 연관관계 (has-a) Association
    • 클래스들이 상호 메시지를 주고 받는 관계를 표현
    • 한 클래스가 다른 클래스와 영속적인 연관성을 맺을 때 사용
  • 의존관계 Dependency
    • 연관 관계의 특수한 형태로 한 클래스가 다른 클래스에 의존적인 연관관계를 나타낼 때 사용
  • 집합연관 (집약관계) Aggregation
    • 연관관계의 특수한 형태로 클래스들 사이의 전체와 부분의 관계
    • 전체 객체의 라이프타임과 부분 객체의 라이프타임은 독립적이며 전체 객체가 사라져도 부분 객체는 계속 생존할 수 있음
  • 복합연관 (합성관계) Composition
    • 연관관계의 특수한 형태로 클래스들 사이의 전체와 부분의 관계
    • 전체 객체의 라이프타임과 부분 객체의 라이프타임이 동일, 전체 객체가 사라지면 부분 객체도 없어짐
  • 실체화관계 Realization
    • 하나의 클래스가 다른 클래스를 보다 구체적으로 실체화하는 관계
    • 하나의 객체가 다른 객체에 의해 오퍼레이션을 수행하도록 지정
    • 인터페이스 클래스를 다른 클래스가 구현해주는 관계가 좋은 관계

 

416. CASE 도구

  • CASE 도구의 개념
    • 계획수립에서부터 요구분석, 설계, 개발, 유지보수에 이르는 소프트웨어 생명주기 전 과정을 자동화할 수 있도록 지원하는 자동화 도구
    • 1970년대부터 현재까지 지속적으로 발전하고 있음
    • 등장 배경
      • 소프트웨어 산업 측면 : 소프트웨어 위기 극복 방안으로 등장하게 됨
      • 정보시스템 관리 측면 : 요구사항의 관리 효과 극대화, 재사용성 및 생산성 확대를 위해 등장
  • CASE 도구의 기능
    • 표준화 적용(범용성, 이식성+), 문서화를 통한 품질 개선 가능
    • 변경사항, 변경으로 인한 영향에 대한 추적 용이
    • 명세에 대한 유지보수 비용의 축소 가능
  • CASE 도구의 분류
    • Upper CASE (상위 CASE)
      • 계획수립, 요구분석, 기본설계 단계 : 다이어그램으로 표현
      • 모델들 사이의 모순 검사, 모델의 오류 검증, 일관성 검증 지원
      • 자료 흐름도, 프로토타이핑 작성 지원, UI 설계 지원
    • Lower CASE (하위 CASE)
      • 코드의 작성과 테스트, 문서화 과정을 지원
      • 구문 중심 편집 및 정적/동적 테스트 지원
      • 시스템 명세서 생성 및 소스 코드 생성 지원

 

417. 요구사항 관리 도구

  • 프로젝트 생성
    • 프로젝트 타입 및 기본 모듈 템플릿, 속성, 역할별 뷰를 설정
    • 프로젝트 생성을 도와주며 이를 저장하여 재사용
  • 요구사항 작성
    • 모든 요구사항에 고유의 ID가 생성, 부여
    • ID는 사용자에 의한 임의 변경이 될 수 없도록 관리기능 지원
  • 요구사항 Import/Export
    • 요구사항의 일괄 등록 및 추출
    • Plain Text, Rich Text, Spreadsheet, Word, Excel, Outlook, HTML 등 다양한 형식의 파일 Import와 Export 기능 제공
  • 요구사항 이력 관리
    • 요구사항 별로 히스토리 관리
  • 요구사항 베이스라인
    • 요구사항이 확정되고 관리의 시작점이 되는 요구사항 베이스라인 관리
    • 요구사항 변경에 따른 영향 평가
  • 요구사항 추적
    • 어느 요구사항이 베이스인지를 구분하기 위한 기능
    • 현재 요구사항을 기반으로 작성된 요구사항인지, 타 요구사항을 기반으로 하여 현재 요구사항이 작성되었는지를 추적하는 기능 제공
  • 협업 환경
    • 하나의 요구사항 문서를 여러 명이 작성할 수 있도록 협업 기능
    • 공유 모드를 제공하고 선점 사용자 외엔 수정 및 삭제 권한 제한
  • 외부 연동 환경
    • 요구사항대로 설계되었는지를 파악하기 위해 설계도구와 연동
    • 요구사항대로 구현되었는지를 확인하기 위해 형상 관리도구와 연동

 

418. 애자일 개발 방법론

  • XP (eXtreme Programming)
    • 의사소통 개선과 즉각적인 피드백에 의한 단순한 코딩으로 S/W 품질을 높이기 위한 방법
    • 1 ~ 3주 반복주기 (iteration)
    • 5가지 가치 : 용기, 단순성, 의사소통, 피드백, 존경
    • 12개 실천항목
  • SCRUM
    • 매일 정해진 시간에 정해진 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심의 방법론
    • 30일마다 동작 가능한 제품을 제공하는 스프린트
    • 백로그 : 제품과 프로젝트에 대한 요구사항
    • 스프린트 : 30일 단위의 짧은 개발기간으로 분리하여 반복적 수행
    • 스크럼미팅 : 매일 스크럼 미팅으로 오늘과 내일 해야 할 일의 계획 수립
    • 스크럼마스터 : 프로젝트 리더, 스크럼 수행 시 문제인지 및 이를 해결하려고 노력하는 사람
  • Lean
    • 린 시스템의 품질 기법을 소프트웨어 개발 프로세스에 적용하여 프로세스의 낭비 요소를 제거 후 결과 측정, 성과를 분석하여 소프트웨어의 품질을 향상시키는 개발 방법론
    • 7가지 원칙 : 낭비 제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화

 

428. DRM

  • 디지털 콘텐츠의 생성에서 이용까지 유통 전 과정에 걸쳐 디지털 콘텐츠를 안전하게 관리 보호/하고 부여된 권한정보에 따라 디지털 곤텐츠의 이용을 제어/통제하는 기술

 

429. 소프트웨어 버전 관리도구

  • 로컬 버전 관리
    • 담당자 한 명이 매일 공유 폴더의 파일을 자기 Pc로 복사하고 컴파일하여 에러 확인과 정상 동작 여부 확인
    • 종류 : RCS, SCCS
  • 중앙 집중식 버전 관리
    • 모든 파일을 관리하는 서버가 중앙에 있고, 클라이언트가 중앙 서버에서 파일을 받아서 사용
    • 종류 : CVS, Subversion, Perforce
  • 분산형 버전 관리
    • 원격 저장소의 파일을 공유하는 형태가 아니라 로컬 저장소에 파일을 전부 복제하여 사용하는 방식
    • 로컬 저장소에서 작업이 완료되면 커밋하여 원격 저장소에 반영하는 방식
    • 종류 : Git, Bitkeeper

 

430. 화이트박스, 블랙박스 테스트

  • 화이트 박스 테스트
    • 모듈의 원시코드를 오픈 시킨 상태에서 원시코드의 논리적인 모든 경로를 검사하여 결함을 찾는 테스트 기법 
  • 블랙 박스 테스트
    • 사용자 관점에서 원시코드는 보지 않고 목적 코드를 데이터 중심의 입출력 기준으로 수행하여 결함을 찾는 테스트 기법
    • 기능을 검사하기 위한 테스트 기법

 

432. 정렬 알고리즘

  • O(1)
    • 상수형, 자료의 크기와 무관하게 항상 같은 속도로 작동
    • Hash Function
  • O(logN)
    • 로그형
    • 주로 커다란 문제를 일정한 크기를 갖는 작은 문제로 쪼갤 때 나타나는 유형
    • 데이터의 크기에 따라 달라지나 데이터가 추가될수록 더 효율적
    • Binary Search
  • O(N)
    • 선형, 입력 자료를 차례로 하나씩 모두 처리
    • 수행시간이 자료 크기와 직접적인 관계로 변함 (정비례)
    • Find item
  • O(NlogN) 
    • 분할과 합병형, 자료를 분할하여 각각 처리하고 합병
    • 일반적으로 정렬 알고리즘이 가져야 할 최소한의 복잡도로 간주
    • Quick Sort
  • O(Nlog₂N)
    • 선형, 로그형, 복잡도
    • 로그, 변수에 비례 : 퀵 정렬, 병합 정렬
  • O(N²)
    • 제곱형, 주요처리 (기본 연산) loop 구조가 2중인 경우
    • N의 크기가 작을 때에는 N²이 N log N보다 작을 수 있음
    • 자료가 증가함에 따라 급격히 커지기 때문에 대부분의 과제들에 대해 비효율적이라고 간주
    • Bubble Sort
  • O(N³)
    • 세제복형
    • 주요처리 (기본 연산) loop가 3중인 경우
    • O(N²)보다 더 비효율적
    • Finding the Shortest Path
  • O(2ⁿ)
    • 지수형
    • 가능한 해결방법 모두를 다 검사하여 처리
    • 매우 비효율적
    • Dynamic Programming

 

434. EAI 구축 유형

  • Point-to-Point
    • 중간에 미들웨어를 두지 않고 각 애플리케이션 간 Point to Point 형태로 연결
    • 솔루션 구매 없이 통합
    • 상대적 저렴하게 통합 가능
    • 변경, 재사용 어려움
  • Hub & Spoke
    • 단일 접점이 허브 시스템을 통해 데이터를 전송하는 중앙 집중적 방식
    • 모든 데이터 전송 보장
    • 확장, 유지보수 용이
    • 허브 장애 시 전체 영향
  • Message Bus
    • 애플리케이션 사이 미들웨어(버스)를 두어 처리
    • 미들웨어 통합 통합
    • 어댑터가 각 시스템과 버스를 두어 연결하므로 뛰어난 확장성, 대용량 처리 가능
  • Hybrid
    • 그룹 내에는 Hub & Spoke 방식을 그룹 간 메시지 버스 방식을 사용
    • 표준 통합 기술, 데이터 병목 현상 최소화

 

435. 인터페이스 구현 검증 도구

  • xUnit, STAF, Fitnesse, NTAF, Selenium, watir 등

 

440. 스택

  • 한쪽 끝에서만 자료를 삽입하고 삭제할 수 있는 LIFO 형식의 자료구조
  • 활용 분야로는 컴파일러의 괄호 짝 맞추기, 미로찾기, 트리의 노드 방문, 그래프의 깊이 우선 탐색, 인터럽트 수행 시 복귀 주소 저장, 수식 연산 등에 사용

 

441. 병렬 데이터베이스 환경 중 수평 분할에서 사용되는 분할 기법

  • 라운드-로빈 : 파티셔닝 대상 튜플이 일정한 분포로 분할하는 기법
  • 범위 분할 : 연속적인 숫자나 날짜 등 분할 키를 기준으로 범위 내의 데이터를 분할하는 기법
  • 해시 분할 : 해시함수 값을 파티션에 포함하여 균등하게 데이터를 분할하는 기법
  • 리스트 분할 : 데이터에 대해 명시적인 값을 기준으로 분할하는 기법

 

443. SELECT

  • 테이블에 저장된 데이터 중 특정 컬럼을 조회하고자 할 때는 해당 컬럼 이름을 SELECT 절 뒤에 기술
  • 테이블에 저장된 모든 컬럼의 데이터를 검색하고자 할 때는 컬럼명 없이 아스테리스크(*) 기호를 이용
  • SELECT 명령을 통해 검색한 결과는 중복이 포함된 상태로 출력
  • 중복을 제거한 결과를 검색하고자 할 때는 DISTINCT 키워드를 SELECT 뒤, 컬럼명 앞에 기술

 

444. 뷰, DDL

    • 장점
      • 논리적 독립성 제공 : 논리 테이블 - 테이블의 구조가 변경되어도 뷰를 사용하는 응용 프로그램은 변경하지 않아도 됨
      • 사용자 데이터 관리 용이 : 복수 테이블에 존재하는 여러 종류의 데이터에 대해 단순한 질의어 사용이 가능
      • 데이터 보안 용이 : 중요 보안 데이터를 저장 중인 테이블에는 접근 불허, 해당 테이블의 일부 정보만 뷰를 통해 허용하는 방식, 데이터에 대한 접근 제어 가능
    • 단점
      • 뷰 자체 인덱스 불가 : 인덱스는 물리적으로 저장된 데이터를 대상으로 하기에 논리적 구성인 뷰는 인덱스를 가지지 못함
      • 뷰 정의 변경 불가 : 뷰의 정의를 변경하려면 뷰를 삭제하고 재생성
      • 데이터 변경 제약 존재 : 뷰의 내용에 대한 삽입, 삭제, 변경 제약
  • 데이터 정의어 (DDL)의 명령어 : 생성, 삭제 실행
    • CREATE
      • 뷰 생성
      • CREATE VIEW <View Name> (컬럼 목록) AS <뷰를 통해 보여줄 데이터 조회용 쿼리문>
    • DROP
      • DROP VIEW <View Name> {RESTRICT | CASCADE};
      • RESTRICT : 뷰를 다른 곳에서 참조하고 있으면 삭제 취소
      • CASCADE : 뷰를 참조하는 다른 뷰나 제약조건까지 모두 삭제

 

445. DDL

  • 생성
    • CREATE : 데이터베이스 객체 생성
  • 변경
    • ALTER : 데이터베이스 객체 변경
  • 삭제
    • DROP : 데이터베이스 객체 삭제
    • TRUNCATE : 데이터베이스 객체 내 튜플(행) 삭제
    • CASCADE : 참조하는 테이블도 같이 삭제

 

446. 집합연산자

  • 집합연산의 개념 : 테이블을 집합의 개념으로 보고, 두 테이블 연산에 집합 연산자를 사용하는 방식
  • 집합연산자의 유형
    • UNION : 여러 SQL문의 결과에 대한 합집합 - 중복행 제거
    • UNION ALL : 여러 SQL문의 결과에 대한 합집합 - 중복 행 제거하지 않음
    • INTERSECTION : 여러 SQL문의 결과에 대한 교집합 - 중복 행 제거
    • EXCEPT (MINUS) : 앞의 SQL문의 결과와 뒤의 SQL문의 결과 사이의 차집합 - 중복 행 제거, 일부 제품의 경우 MINUS 사용 

 

447. 데이터베이스 설계 - 물리적 단계에서 수행 작업

  • 저장 레코드 양식 설계 : 데이터 타입, 데이터 값의 분포, 사용될 응용 어플리케이션, 접근 빈도 등을 고려하여 결정하며 데이터 표현과 압축에 대한 양식 포함
  • 레코드 집중의 분석 및 설계 : 레코드의 집중은 레코드들이 물리적으로 집중되도록 저장 공간을 할당하여 물리적 순차성을 이용할 수 있도록 함
  • 접근 경로 설계 : 물리적 데이터베이스를 접근하는 경로에 대한 설계 수행

 

448. 개체 무결성

  • 엔티티 무결성
  • 테이블의 모든 행들이 유일하게 식별되는 무결성
  • 대부분의 경우 기본키에 의해 강화 
  • 기본 키 : 반드시 값을 가짐 (NULL 허용 안함), 유일성을 보장하는 최소한의 집합
  • 제약 조건 : Primary Key, NOT NULL