Computer Science/Database :: 데이터베이스

데이터베이스 강의 마무리 정리

HJPlumtree 2022. 6. 11. 13:53

데이터베이스 강의 마무리 하며 정리

 

 

✅ DBMS 이전 데이터 관리 방식, 운영체제의 지원으로 여러 파일에 나누어 데이터를 영구 저장하고 운영하는 시스템

  • 파일 처리 시스템

 

 

✅ 파일 처리 방식의 데이터 관리로 발생할 수 있는 문제점

  • 데이터 중복
  • 데이터 무결성 훼손
  • 동시 접근 이상

 

 

✅ 데이터 중복으로 생길 수 있는 문제

  • 일관성
  • 보안성
  • 경제성

 

 

✅ 한 조직의 연관된 데이터 집합을 다수의 사용자가 공용으로 사용하기 위해 통합 저장한 데이터

  • 데이터베이스

 

 

✅ 한 조직의 연관된 데이터 집합을 다수의 사용자가 공용으로 사용하기 위해 통합 저장하는 소프트웨어 패키지

  • 데이터베이스 관리 시스템

 

 

✅ DBMS가 데이터의 일관성을 보장하면서 다수의 데이터 조작 요청을 동시에 수행하기 위한 개념

  • 트랜잭션

 

 

✅ 데이터는 값과 OO로 구성된다

  • 메타 데이터

 

 

✅ 메타 데이터는 DBMS의 어떤 부분이 관리, 담당 할까?

  • 시스템 카탈로그(데이터 사전)

 

 

✅ DBMS 기능, 하나 이상의 원본 테이블로부터 유도되어 일반 테이블처럼 조작할 수 있는 가상의 테이블

  • 뷰(view)

 

 

✅ 데이터베이스 모델링 단계

  1. 요구사항 분석
  2. 개념적 데이터 모델링
  3. 논리적 데이터 모델링
  4. 물리적 데이터 모델링

 

 

✅ 데이터베이스 모델링 과정에서 ER 모델과 관계형 모델이 각각 적용되는 단계

  • ER 모델: 개념적 데이터 모델링
  • 관계형 모델: 논리적 데이터 모델링

 

 

✅ ER 모델 구성요소 중 개체 집합 간의 수학적인 연결관계

  • 관계 집합

 

 

✅  데이터 베이스 시스템 아키텍처, 서버와 클라이언트 사이 데이터에 접근하는데 사용되는 비즈니스 규칙을 저장한 중간 계층을 삽입하여 운용

  • 3계층 클라이언트-서버 구조

 

 

✅ 관계형 모델에서 데이터를 저장, 관리하는 2차원 형태의 표

  • 릴레이션

 

 

  • 가: 컬럼값
  • 나: 컬럼, 속성, 필드
  • 다: 레코드, 투플
  • 라: 스키마
  • 이름, 연비, 가격 컬럼만으로 새로운 릴레이션 구성하기 위한 관계대수식
    => Π이름, 연비, 가격(자동차)

 

 

✅ 관계형 모델에서 컬럼값의 특징

  • 원자성

 

 

✅ 두 개의 릴레이션 사이에 명시되는 제약 조건, 한 릴레이션에 있는 레코드가 다른 릴레이션에 있는 레코드를 참조하려면 반드시 존재하는 레코드만 참조해야한다는 제약조건 명시

  • 참조 무결성 제약조건

 

 

✅ SQL 언어 영역, 데이터베이스로부터 정보 검색, 레코드 추가, 삭제, 수정 기능

  • 데이터 조작 언어

 

 

✅ 새로운 컬럼 추가, 컬럼 데이터 타입 변경 등 테이블 구조 변경할 때 사용하는 명령어

  • ALTER

 

 

✅ 새로운 레코드 삽입하는 데 사용하는 SQL 명령어

  • INSERT

 

 

✅ 레코드 삭제하는데 사용하는 SQL 명령어

  • DELETE

 

 

✅ 임의의 릴레이션 스키마 R의 인스턴스 r(R)에 포함되는 서로 다른 두 투플 t1, t2 속성 집합 X와 Y에 대해, t1[X] =t2[X] 일 때, t1[Y] = t2[Y]가 성립한다는 정의

  • 함수적 종속성

 

 

✅ 릴레이션 내의 컬럼 간의 함수적 종속적 종속 관계를 직관적이고 이해하기 쉽게 다음과 같이 직사각형관 화살표로 도식화한 표현 방식

  • 함수적 종속성 다이어그램

 

 

✅ 정규화에 대한 설명

  • 관계형 데이터베이스 모델에서 논리적 데이터베이스 스키마를 효과적으로 설계하는 데 이용
  • 정보의 중복으로 발생할 수 있는 문제점, 즉 삽입, 삭제, 갱신 등 과정에서 발생할 수 있는 이상 현상 방지
  • 투플들에서 서로 관련되는 데이터 속성요소 간의 종속성을 최소화하기 위한 구성 기법
  • 카노니컬 커버는 클로저에 포함된 모든 함수적 종속성을 커버할 수 있는 최소한 함수적 종속성들로만 이루어진 집합

 

 

✅ 다음 릴레이션에서 포함된 함수적 종속성

  • {도크번호, 입항시간} => 출항시간
  • {도크번호, 입항시간} => 목적
  • 목적 => 담당 도선사

 

 

✅ 유일성이 특성인 키

  • 슈퍼키

 

 

✅ 유일성과 최소성이 특성인 키

  • 후보키

 

 

✅ 정규형 조건 수준이 약한 순에서 강한순 나열

  • 제1 정규형 => 제2 정규형 => 제3 정규형 => BC 정규형

 

 

✅ 크기가 큰 순에서 작은순으로 나열

  • 데이터베이스 > 파일 > 블럭 > 레코드

 

 

✅ 컬럼의 길이가 정해져 레코드의 길이가 항상 동일한 레코드

  • 고정 길이 레코드

 

 

✅ 가변 길이 레코드 방식이 필요한 이유

  • 한 블럭 내에 저장되는 레코드 유형이 둘 이상일 때
  • 길이가 고정되지 않은 컬럼이 한 개 이상일 때
  • 레코드가 멀티셋(multiset)을 이용하는 컬럼을 가질 때

 

 

✅ 가변 길이 레코드를 효과적으로 저장하기 위해 파일 또는 블록의 헤더에 유지하는 다음과 같은 형식의 구조

  • 슬롯 페이지 구조

 

 

✅ 요청에 필요한 블럭이 버퍼에 있을 때, 그 블럭이 위치한 메모리 내의 주소를 프로그램에 전달, 버퍼에 없을 경우 요청한 블럭을 적재하기 위한 공간을 새로 할당하는 것

  • 버퍼 관리자

 

 

✅ 물리적 저장장치중 데이터 접근 속도가 빠른 장치에서 느린 장치 순으로 나열

  • 레지스터 > 캐시 > 메인 메모리 > 자기디스크

 

 

✅ 다음 그림과 같이 인덱스의 엔트리가 일부 레코드에 대한 검색 키 값만 유지하는 인덱스

  • 희소 인덱스

 

 

✅ 모든 검색 키 값에 대해 검색키 <값, 포인터> 쌍으로 구성, 인덱스 엔트리르 갖고 있어 검색 속도가 빠른 장점 BUT 인덱스 파일 크기가 커서 I/O 비용이 증가해서 탐색 시간이 오래 걸릴 수 있는 단점을 지닌다

  • 밀집 인덱스

 

 

✅ 요청된 레코드에 빠르게 접근할 수 있도록 하는 인덱스의 효율성에 대한 평가기준

  • 인덱스를 저장하기 위해 부가적인 필요한 공간 비용
  • 새로운 데이터 삽입 시 발생하는 인덱스 구조 유지 비용
  • 인덱스를 통해 데이터를 찾고 접근하는데 걸리는 시간

 

 

✅ 해시 인덱스에서 검색키를 버킷 주소에 대응시키는 것은?

  • 해시 함수

 

 

✅ 다른 두 레코드 R1과 R2의 검색키가 h에 의해 동일한 버킷으로 대응되었을 때, R1과 R2의 관계를 뭐라고 부르지?

  • 동거자

 

 

✅ 데이터베이스 크기에 따라 버킷의 개수가 자동적으로 조절되는 형태의 해싱이 뭐지?

  • 동적 해싱

 

 

✅ 새로운 레코드 삽입 시 잦은 충돌이 발생해서 버킷에 레코드를 삽입할 자유 공간이 남아 있지 않은 상태

  • 오버플로(Overflow)

 

 

✅ 다음의 트리 구조는 뭘까?

  • B+ 트리

 

 

✅ 다음 테이블에서 '등급' 컬럽에 비트맵 인덱스를 생성할 때 '일반'에 대한 비트열

  • '일반' 있으면 1 없으면 0
  • 10010

 

 

✅ DBMS 기법, 하나의 논리적인 작업을 처리하기 위해 연속적인 데이터베이스 명령어 집합

  • 트랜잭션

 

 

✅ 트랜잭션의 ACID 특성

  • 원자성(Atomicity): 트랙잭션의 모든 함수가 실행되거나 안되거나, 모 or 도
  • 일관성(Consitency): 트랙잭션 전후에 DB 인관성 유지
  • 고립성(Isolation): 다른 트랙잭션에 방해받지 않는다
  • 지속성(Durability): DMBS에 문제 생겨도, DB에 저장된 트랜잭션은 결과가 지속되어야 한다

 

 

✅ 트랜잭션 Ti와 Tj의 스케줄에 포함된 데이터베이스 연산 실행 순서를 교환해도 논리적으로 문제가 발생하지 않는 데이터베이스 연산

  • Ii = READ(Q)
  • Ij = READ(Q)

 

 

:Library by Anif Riyanto @unsplash