잡다한 배똥월드

728x90

 

 

 

1. 정의

  • 함수적 종속성 등의 종속성 이론을 이용하여 잘못 설계된 관계형 스키마를 더 작은 속성의 세트로 쪼개어 바람직한 스키마로 만들어 가는 과정
  • 하나의 종속성이 하나의 릴레이션에 표현될 수 있도록 분해해가는 과정
  • 종류 : 제1정규형, 제2정규형, 제3정규형, BCNF형, 제4정규형, 제5정규형
  • 차수가 높아질수록 만족시켜야 할 제약 조건이 늘어남
  • 데이터베이스의 논리적 설계 단계에서 수행
  • 논리적 처리 및 품질에 큰 영향을 미침
  • 정규화된 데이터 모델은 일관성, 정확성, 단순성, 비중복성, 안정성 등을 보장
  • 정규화 수준이 높을수록 유연한 데이터 구축이 가능하고 데이터의 정확성이 높아지는 반면 물리적 접근이 복잡하고 너무 많은 조인으로 인해 조회 성능이 저하됨

 

 

 

 

2. 목적

  • 데이터 구조의 안정성 및 무결성을 유지
  • 어떠한 릴레이션이라도 데이터베이스 내에서 표현 가능하게 만듬
  • 효과적인 검색 알고리즘을 생성할 수 있음
  • 데이터 중복을 배제하여 이상(Anomaly)의 발생 방지 및 자료 저장 공간의 최소화가 가능
  • 데이터 삽입 시 릴레이션을 재구성할 필요성을 줄임
  • 데이터 모형의 단순화가 가능
  • 속성의 배열 상태 검증이 가능
  • 개체와 속성의 누락 여부 확인이 가능
  • 자료 검색과 추출의 효율성을 추구

 

 

 

 

3. 이상(Anomaly)

  • 정규화를 거치지 않으면 데이터베이스 내에 데이터들이 불필요하게 중복되어 릴레이션 조작 시 예기치 못한 곤란한 현상이 발생하는 것
  • 종류 : 삽입 이상, 삭제 이상, 갱신 이상
  • 삽입 이상(Insertion Anomaly) : 릴레이션에 데이터를 삽입할 때 의도와는 상관없이 원하지 않은 값들도 함께 삽입되는 현상
  • 삭제 이상(Deletion Anomaly) : 릴레이션에서 한 튜플을 삭제할 때 의도와는 상관없는 값들도 함께 삭제되는 연쇄가 일어나는 현상
  • 갱신 이상(Update Anomaly) : 릴레이션에서 튜플에 있는 속성값을 갱신할 때 일부 튜플의 정보만 갱신되어 정보에 모순이 생기는 현상

 

 

 

 

4. 정규화의 원칙

  • 정보의 무손실 표현, 즉 하나의 스키마를 다른 스키마로 변환할 때 정보의 손실이 있어서는 안 됨
  • 분리의 원칙, 즉 하나의 독립된 관계성은 하나의 독립된 릴레이션으로 분리해야 함
  • 데이터의 중복성이 감소되어야 함

 

 

 

 

5. 1NF(제1정규형)

  • 릴레이션에 속한 모든 도메인(Domain)이 원자값(Atomic Value)만으로 되어 있는 정규형
  • 릴레이션의 모든 속성 값이 원자 값으로만 되어 있는 정규형
  • 릴레이션의 모든 속성이 단순 영역에서 정의됨

 

 

 

 

6. 2NF(제2정규형)

  • 릴레이션 R이 1NF이고, 기본키가 아닌 모든 속성이 기본키에 대하여 완전 함수적 종속을 만족하는 정규형
  • 함수적 종속 : 데이터들이 어떤 기준값에 의해 종속되는 것을 의미. B에 따라 A가 결정될 때 A를 B에 함수 종속적이라고 하며, B → A로 표현
  • 완전 함수적 종속 : 어떤 테이블 R에서 속성 A가 다른 속성 집합 B 전체에 대해 함수적 종속이지만 속성 집합 B의 어떠한 진부분 집합 C에는 함수적 종속이 아닐 때 속성 A는 B에 완전 함수적 종속
  • 부분 함수적 종속 : 어떤 테이블 R에서 속성 A가 다른 속성 집합 B 전체에 대해 함수적 종속이면서 속성 집합 B의 어떠한 진부분 집합에서도 함수적 종속일 때, 속성 A는 속성 집합 B에 부분 함수적 종속

 

 

 

 

7. 3NF(제3정규형)

  • 릴레이션 R이 2NF이고, 기본키가 아닌 모든 속성이 기본키에 대해 이행적 종속을 만족하지 않는 정규형
  • 무손실 조인 또는 종속성 보존을 저해하지 않고도 항상 3NF 설계를 얻을 수 있음
  • 이행적 종속 : A → B이고 B → C일 때 A → C를 만족하는 관계를 의미

 

 

 

 

8. BCNF(Boyce-Codd 정규형)

  • 릴레이션 R에서 결정자가 모두 후보키(Candidate Key)인 정규형
  • 3NF에서 후보키가 여러 개 존재하고 서로 중첩되는 경우에 적용하는 강한 제3정규형
  • 모든 BCNF가 종속성을 보존하는 것은 아님

 

 

 

 

9. BCNF의 제약 조건

  • 키가 아닌 모든 속성은 각 키에 대하여 완전 종속해야 함
  • 키가 아닌 모든 속성은 그 자신이 부분적으로 들어가 있지 않은 모든 키에 대하여 완전 종속해야 함
  • 어떤 속성도 키가 아닌 속성에 대해서는 완전 종속할 수 없음

 

 

 

 

10. 4NF(제4정규형)

  • 릴레이션 R에 다치 종속 A →> B가 성립하는 경우 R의 모든 속성이 A에 함수적 종속 관계를 만족하는 정규형
  • 다치 종속 : 복합 속성 A, C에 대응하는 집합 B가 A에만 종속되고 C에는 무관하면 B는 A에 다치 종속이라고 함

 

 

 

 

11. 5NF(제5정규형, PJ/NF)

  • 릴레이션 R의 모든 조인 종속이 R의 후보키를 통해서만 성립되는 정규형
  • 조인 종속 : 릴레이션 R이 속성에 대한 부분집합 A, B, ··· C를 모두 조인한 결과가 자신과 동일한 경우 R은 조인 종속을 만족한다고 함

 

 

 

 

12. 정규화 과정 정리

  • 비정규 릴레이션 → (도메인이 원자값) → 1NF
  • 1NF → (부분적 함수 종속 제거) → 2NF
  • 2NF → (이행적 함수 종속 제거) → 3NF
  • 3NF → (결정자이면서 후보키가 아닌 것 제거) → BCNF
  • BCNF → (다치 종속 제거) → 4NF
  • 4NF → (조인 종속성 이용) → 5NF

 

 

 

 

 

728x90
728x90

 

 

 

1. 무결성(Integrity)

  • 데이터베이스에 저장된 데이터 값과 그것이 표현하는 현실 세계의 실제 값이 일치하는 정확성을 의미
  • 무결성 제약 조건 : 데이터베이스에 들어 있는 데이터의 정확성을 보장하기 위해 부정확한 자료가 데이터베이스 내에 저장되는 것을 방지하기 위한 제약 조건
  • 종류 : 개체 무결성, 도메인 무결성, 참조 무결성, 사용자 정의 무결성 등

 

 

 

 

2. 개체 무결성(Entity Integrity, 실체 무결성)

  • 기본 테이블의 기본키를 구성하는 어떤 속성도 Null 값이나 중복값을 가질 수 없다는 규정

 

 

 

 

3. 도메인 무결성(Domain Integrity, 영역 무결성)

  • 주어진 속성 값이 정의된 도메인에 속한 값이어야 한다는 규정

 

 

 

 

4. 참조 무결성(Referential Integrity)

  • 외래키 값은 Null이거나 참조 릴레이션의 기본키 값과 동일해야 함
  • 릴레이션은 참조할 수 없는 외래키 값을 가질 수 없다는 규정
  • 외래키와 참조하려는 테이블의 기본키는 도메인과 속성 개수가 같아야 함

 

 

 

 

5. 사용자 정의 무결성(User-Defined Integrity)

  • 속성 값들이 사용자가 정의한 제약 조건에 만족해야 한다는 규정

 

 

 

 

6. 데이터 무결성 강화

  • 데이터 품질에 직접적인 영향을 미치므로 데이터 특성에 맞는 적절한 무결성을 정의하고 강화해야 함
  • 프로그램이 완성되고 데이터가 저장된 상태에서 무결성을 정의할 경우 많은 비용이 발생하므로 데이터베이스 구축 과정에서 정의
  • 애플리케이션, 데이터베이스 트리거, 제약 조건을 이용하여 강화할 수 있음

 

 

 

 

7. 애플리케이션을 이용한 강화

  • 데이터 생성, 수정, 삭제 시 무결성 조건을 검증하는 코드를 데이터를 조작하는 프로그램 내에 추가
  • 코드를 이용한 복잡한 규칙 등을 검토하는 무결성 검사는 데이터베이스에서 수행하기 어려우므로 애플리케이션 내에서 처리
  • 장점 : 사용자 정의 같은 복잡한 무결성 조건의 구현이 가능
  • 단점 : 소스 코드에 분산되어 있어 관리가 힘들고, 개별적인 시행으로 인해 적정성 검토가 어려움

 

 

 

 

8. 데이터베이스 트리거를 이용한 강화

  • 트리거 이벤트에 무결성 조건을 실행하는 절차형 SQL을 추가
  • 장점 : 통합 관리가 가능하고, 복잡한 요구 조건의 구현이 가능
  • 단점 : 운영 중 변경이 어렵고, 사용상 주의가 필요

 

 

 

 

9. 제약 조건을 이용한 강화

  • 데이터베이스에 제약 조건을 설정하여 무결성을 유지
  • 장점 : 통합 관리 가능, 간단한 선언으로 구현 가능, 변경 용이, 오류 데이터 발생 방지 등
  • 단점 : 복잡한 제약 조건의 구현과 예외적인 처리가 불가능

 

 

 

 

 

728x90
728x90

 

 

 

1. 제약 조건

  • 데이터베이스에 저장되는 데이터의 정확성을 보장하기 위하여 키(Key)를 이용하여 입력되는 데이터에 제한을 주는 것
  • 개체 무결성 제약, 참조 무결성 제약 등

 

 

 

 

2. 키(Key)

  • 데이터베이스에서 조건에 만족하는 튜플을 찾거나 순서대로 정렬할 때 튜플들을 서로 구분할 수 있는 기준이 되는 애트리뷰트
  • 종류 : 후보키, 기본키, 대체키, 슈퍼키, 외래키 등

 

 

 

 

3. 후보키(Candidate Key)

  • 릴레이션을 구성하는 속성들 중에서 튜플을 유일하게 식별하기 위해 사용하는 속성들의 부분집합
  • 기본키로 사용할 수 있는 속성들을 말함
  • 하나의 릴레이션 내에서는 중복된 튜플들이 있을 수 없으므로 모든 릴레이션에는 반드시 하나 이상의 후보키가 존재
  • 릴레이션에 있는 모든 튜플에 대해서 유일성과 최소성을 만족시켜야 함
  • 유일성(Unique) : 하나의 키 값으로 하나의 튜플만을 유일하게 식별할 수 있어야 함
  • 최소성(Minimality) : 모든 레코드들을 유일하게 식별하는 데 꼭 필요한 속성으로만 구성되어야 함

 

 

 

 

4. 기본키(Primary Key)

  • 후보키 중에서 특별히 선정된 주키(Main Key)로 중복된 값을 가질 수 없음
  • 한 릴레이션에서 특정 튜플을 유일하게 구별할 수 있는 속성
  • 후보키의 성질을 가짐 => 유일성과 최소성을 가지며 튜플을 식별하기 위해 반드시 필요한 키
  • NULL 값을 가질 수 없음

 

 

 

 

5. 대체키(Alternate Key)

  • 후보키가 둘 이상일 때 기본키를 제외한 나머지 후보키를 의미
  • 보조키라고도 함

 

 

 

 

6. 슈퍼키(Super Key)

  • 한 릴레이션 내에 있는 속성들의 집합으로 구성된 키
  • 릴레이션을 구성하는 모든 튜플들 중 슈퍼키로 구성된 속성의 집합과 동일한 값은 나타나지 않음
  • 모든 튜플에 대해 유일성은 만족시키지만, 최소성은 만족시키지 못함

 

 

 

 

7. 외래키(Foreign Key)

  • 다른 릴레이션의 기본키를 참조하는 속성 또는 속성들의 집합
  • 참조되는 릴레이션의 기본키와 대응되어 릴레이션 간에 참조 관계를 표현하는데 중요한 도구
  • 한 릴레이션에 속한 속성 A와 참조 릴레이션의 기본키인 B가 동일한 도메인 상에서 정의되었을 때의 속성 A를 외래키라고 함
  • 외래키로 지정되면 참조 릴레이션의 기본키에 없는 값은 입력할 수 없음

 

 

 

 

 

728x90
728x90

 

 

 

1. 정의

  • 1970년 IBM에 근무하던 코드(E. F. Codd)에 의해 처음 제안됨
  • 관계형 데이터베이스를 구성하는 개체(Entity)나 관계(Relationship)를 모두 릴레이션(Relation)이라는 표(Table)로 표현
  • 릴레이션은 개체를 표현하는 개체 릴레이션, 관계를 나타내는 관계 릴레이션으로 구분 가능
  • 장점 : 간결하고 보기 편리하며, 다른 데이터베이스로의 변환이 용이
  • 단점 : 성능이 다소 떨어짐

 

 

 

 

2. Relation 구조

  • 데이터들을 표(Table)의 형태로 표현한 것
  • 구조를 나타내는 릴레이션 스키마와 실제 값들인 릴레이션 인스턴스로 구성

 

 

 

 

3. 튜플(Tuple)

  • 릴레이션을 구성하는 각각의 행
  • 속성의 모임으로 구성
  • 파일 구조에서 레코드와 같은 의미
  • 튜플의 수를 카디널리티(Cardinality) 또는 기수, 대응수라고 함 => 행의 개수

 

 

 

 

4. 속성(Attribute)

  • 데이터베이스를 구성하는 가장 작은 논리적 단위
  • 파일 구조상의 데이터 항목 또는 데이터 필드에 해당
  • 개체의 특성을 기술
  • 속성의 수를 디그리(Degree) 또는 차수라고 함 => 열의 개수

 

 

 

 

5. 도메인(Domain)

  • 하나의 애트리뷰트가 취할 수 있는 같은 타입의 원자(Atomic)값들의 집합
  • 실제 애트리뷰트 값이 나타날 때 그 값의 합법 여부를 시스템이 검사하는데에도 이용됨

 

 

 

 

6. 특징

  • 한 릴레이션에는 똑같은 튜플이 포함될 수 없음 => 릴레이션에 포함된 튜플들은 모두 상이함
  • 한 릴레이션에 포함된 튜플 사이에는 순서가 없음
  • 튜플들의 삽입, 삭제 등의 작업으로 인해 릴레이션은 시간에 따라 변함 => 동적임
  • 릴레이션 스키마를 구성하는 속성들 간의 순서는 중요하지 않음
  • 속성의 유일한 식별을 위해 속성의 명칭은 유일해야 하지만, 속성을 구성하는 값은 동일한 값이 있을 수 있음
  • 튜플을 유일하게 식별하기 위해 속성들의 부분집합을 키(Key)로 설정함
  • 속성의 값은 논리적으로 더 이상 쪼갤 수 없는 원자값만을 저장

 

 

 

 

 

728x90
728x90

 

 

 

1. 정의

사용자의 요구를 분석하여 그것들을 컴퓨터에 저장할 수 있는 데이터베이스의 구조에 맞게 변형한 후 특정 DBMS로 데이터베이스를 구현하여 일반 사용자들이 사용하게 하는 것

 

 

 

 

2. 데이터베이스 설계 시 고려사항

  • 무결성 : 삽입, 삭제, 갱신 등의 연산 후에도 데이터베이스에 저장된 데이터가 정해진 제약 조건을 항상 만족해야 함
  • 일관성 : 데이터베이스에 저장된 데이터들 사이나, 특정 질의에 대한 응답이 처음부터 끝까지 변함없이 일정해야 함
  • 회복 : 시스템에 장애가 발생했을 때 장애 발생 직전의 상태로 복구할 수 있어야 함
  • 보안 : 불법적인 데이터의 노출 또는 변경이나 손실로부터 보호할 수 있어야 함
  • 효율성 : 응답시간의 단축, 시스템의 생산성, 저장 공간의 최적화 등이 가능해야 함
  • 데이터베이스 확장 : 데이터베이스 운영에 영향을 주지 않으면서 지속적으로 데이터를 추가할 수 있어야 함

 

 

 

 

3. 데이터베이스 설계 순서

  • 요구 조건 분석 : 요구 조건 명세서 작성
  • 개념적 설계 : 개념 스키마, 트랜잭션 모델링, E-R 모델
  • 논리적 설계 : 목표 DBMS에 맞는 논리 스키마 설계, 트랜잭션 인터페이스 설계
  • 물리적 설계 : 목표 DBMS에 맞는 물리적 구족의 데이터로 변환
  • 구현 : 목표 DBMS의 DDL(데이터 정의어)로 데이터베이스 생성, 트랜잭션 작성

 

 

 

 

4. 요구 조건 분석

  • 데이터베이스를 사용할 사람들로부터 필요한 용도를 파악하는 것
  • 사용자에 따른 수행 업무와 필요한 데이터의 종류, 용도, 처리 형태, 흐름, 제약 조건 등을 수집
  • 수집된 정보를 바탕으로 요구 조건 명세를 작성

 

 

 

 

5. 개념적 설계(정보 모델링, 개념화)

  • 정보의 구조를 얻기 위하여 현실 세계의 무한성과 계속성을 이해하고 현실 세계에 대한 인식을 추상적 개념으로 표현하는 과정
  • 개념 스키마 모델링과 트랜잭션 모델링을 병행 수행
  • 요구 조건 명세를 DBMS에 독립적인 E-R 다이어그램으로 작성
  • DBMS에 독립적인 개념 스키마를 설계

 

 

 

 

6. 논리적 설계(데이터 모델링)

  • 현실 세계에서 발생하는 자료를 컴퓨터가 이해하고 처리할 수 있는 물리적 저장장치에 저장할 수 있도록 변환하기 위해 특정 DBMS가 지원하는 논리적 자료 구조로 변환(mapping) 시키는 과정
  • 필드로 기술된 데이터 타입과 이 데이터 타입들 간의 관계로 표현되는 논리적 구조의 데이터로 모델화
  • 개념 스키마를 평가 및 정제하고 DBMS에 따라 서로 다른 논리적 스키마를 설계하는 단계
  • 트랜잭션의 인터페이스를 설계
  • 관계형 데이터베이스라면 테이블을 설계하는 단계

 

 

 

 

7. 물리적 설계(데이터 구조화)

  • 논리적 설계 단계에서 논리적 구조로 표현된 데이터를 디스크 등의 물리적 저장장치에 저장할 수 있는 물리적 구조의 데이터로 변환하는 과정
  • 데이터베이스 파일의 저장 구조 및 액세스 경로를 결정
  • 저장 레코드의 형식, 순서, 접근 경로와 같은 정보를 사용하여 데이터가 컴퓨터에 저장되는 방법을 묘사
  • 기본적인 데이터 단위 : 저장 레코드(Stored Record)
  • 여러 가지 타입의 저장 레코드 집합이라는 면에서 단순한 파일과 다름
  • 데이터베이스 시스템의 성능에 중대한 영향을 미침

 

 

 

 

8. 물리적 설계 단계에서 꼭 포함되어야 할 것

  • 저장 레코드의 양식 설계
  • 레코드 집중(Record Clustering)의 분석 및 설계
  • 접근 경로 설계 등

 

 

 

 

9. 물리적 설계 시 고려 사항

  • 인덱스의 구조
  • 레코드 크기
  • 파일에 존재하는 레코드 개수
  • 파일에 대한 트랜잭션의 갱신과 참조 성향
  • 성능 향상을 위한 개념 스키마의 변경 여부 검토
  • 빈번한 질의와 트랜잭션들의 수행속도를 높이기 위한 고려
  • 시스템 운용 시 파일 크기의 변화 가능성

 

 

 

 

10. 물리적 설계 옵션 선택 시 고려 사항

  • 물리적 설계 옵션 : 특정 DBMS에서 제공되는 것, 데이터베이스 파일에 대한 저장 구조와 접근 경로에 대한 다양한 옵션
  • 반응 시간(Response Time) : 트랜잭션 수행을 요구한 시점부터 처리 결과를 얻을 때까지의 경과 시간
  • 공간 활용도(Space Utilization) : 데이터베이스 파일과 액세스 경로 구조에 의해 사용되는 저장공간의 양
  • 트랜잭션 처리량(Transaction Throughput) : 단위시간 동안 데이터베이스 시스템에 의해 처리될 수 있는 트랜잭션의 평균 개수

 

 

 

 

11. 데이터베이스 구현

  • 논리적 설계 단계와 물리적 설계 단계에서 도출된 데이터베이스 스키마를 파일로 생성하는 과정
  • 사용하려는 특정 DBMS의 DDL(데이터 정의어)을 이용하여 데이터베이스 스키마를 기술한 후 컴파일한 빈 데이터베이스 파일을 생성
  • 생성된 빈 데이터베이스 파일에 데이터를 입력
  • 응용 프로그램을 위한 트랜잭션을 작성
  • 데이터베이스 접근을 위한 응용 프로그램을 작성

 

 

 

 

 

728x90
728x90

 

 

 

1. 데이터저장소

  • 소프트웨어 개발 과정에서 다루어야 할 데이터들을 논리적인 구조로 조직화하거나, 물리적인 공간에 구축한 것을 의미
  • 논리 데이터저장소와 물리 데이터저장소로 구분
  • 논리 데이터저장소 : 데이터 및 데이터 간의 연관성, 제약조건을 식별하여 논리적인 구조로 조직화한 것
  • 물리 데이터저장소 : 논리 데이터저장소에 저장된 데이터와 구조들을 소프트웨어가 운용될 환경의 물리적 특성을 고려하여 하드웨어적인 저장장치에 저장한 것을 의미
  • 논리 데이터저장소를 거쳐 물리 데이터저장소를 구축하는 과정은 데이터베이스를 구축하는 과정과 동일

 

 

 

 

2. 데이터베이스의 정의

  • 특정 조직의 업무를 수행하는 데 필요한 상호 관련된 데이터들의 모임
  • 통합된 데이터(Integrated Data) : 자료의 중복을 배제한 데이터의 모임
  • 저장된 데이터(Stored Data) : 컴퓨터가 접근할 수 있는 저장 매체에 저장된 자료
  • 운영 데이터(Operational Data) : 조직의 고유한 업무를 수행하는 데 존재 가치가 확실하고 없어서는 안 될 반드시 필요한 자료
  • 공용 데이터(Shared Data) : 여러 응용 시스템들이 공동으로 소유하고 유지하는 자료

 

 

 

 

3. 데이터베이스의 특징

  • 실시간 접근성(Real-Time Accessibility) : 수시적이고 비정형적인 질의(조회)에 대하여 실시간 처리에 의한 응답이 가능해야 함
  • 계속적인 변화(Continuous Evolution) : 새로운 데이터의 삽입(Insertion), 삭제(Deletion), 갱신(Update)으로 항상 최신의 데이터를 유지해야 함 => 동적 상태
  • 동시 공용(Concurrent Sharing) : 데이터베이스는 서로 다른 목적을 가진 여러 응용자들을 위한 것이므로 다수의 사용자가 동시에 같은 내용의 데이터를 이용할 수 있어야 함
  • 내용에 의한 참조(Content Reference) : 데이터베이스에 있는 데이터를 참조할 때 데이터 레코드의 주소나 위치에 의해서가 아니라, 사용자가 요구하는 데이터 내용으로 데이터를 찾음

 

 

 

 

 4. DBMS(DataBase Management System, 데이터베이스 관리 시스템)

  • 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해주고, 데이터베이스를 관리해 주는 소프트웨어
  • 데이터의 종속성과 중복성의 문제를 해결하기 위해 제안된 시스템으로, 모든 응용 프로그램들이 데이터베이스를 공용할 수 있도록 관리해 줌
  • 데이터베이스의 구성, 접근 방법, 유지관리에 대한 모든 책임을 짐
  • 필수 기능 : 정의(Definitior), 조작(Manipulation), 제어(Control) 기능

 

 

 

 

5. 정의 기능

  • 모든 응용 프로그램들이 요구하는 데이터 구조를 지원하기 위해 데이터베이스에 저장될 데이터의 형(Type)과 구조에 대한 정의, 이용 방식, 제약 조건 등을 명시하는 기능

 

 

 

 

6. 조작 기능

  • 데이터 검색, 갱신, 삽입, 삭제 등을 체계적으로 처리하기 위해 사용자와 데이터베이스 사이의 인터페이스 수단을 제공하는 기능

 

 

 

 

7. 제어 기능

  • 데이터베이스를 접근하는 갱신, 삽입, 삭제 작업이 정확하게 수행되어 데이터의 무결성이 유지되도록 제어해야 함
  • 정당한 사용자가 허가된 데이터만 접근할 수 있도록 보안(Security)을 유지하고 권한(Authority)을 검사할 수 있어야 함
  • 여러 사용자가 데이터베이스를 동시에 접근하여 데이터를 처리할 때 처리 결과가 항상 정확성을 유지하도록 병행 제어(Concurrency Control)를 할 수 있어야 함

 

 

 

 

8. DBMS의 장점

  • 데이터의 논리적, 물리적, 독립성이 보장됨
  • 데이터의 중복을 피할 수 있어 기억 공간이 절약됨
  • 저장된 자료를 공동으로 이용 가능
  • 데이터의 일관성, 무결성, 보안 유지 가능
  • 데이터를 표준화 가능
  • 데이터를 통합하여 관리 가능
  • 항상 최신의 데이터를 유지
  • 데이터의 실시간 처리가 가능

 

 

 

 

9. DBMS의 단점

  • 데이터베이스의 전문가가 부족
  • 전산화 비용이 증가
  • 대용량 디스크로의 집중적인 Access로 과부하(Overhead)가 발생
  • 파일의 예비(Backup)와 회복(Recovery)이 어려움
  • 시스템이 복잡

 

 

 

 

10. 데이터의 독립성

  • 종속성에 대비되는 말로, DBMS의 궁극적 목표
  • 논리적 독립성 : 응용 프로그램과 데이터베이스를 독립 => 데이터의 논리적 구조를 변경시키더라도 응용 프로그램은 변경되지 않음
  • 물리적 독립성 : 응용 프로그램과 물리적 장치를 독립 => 데이터베이스 시스템의 성능 향상을 위해 새로운 디스크를 도입하더라도 응용 프로그램에는 영향을 주지 않음

 

 

 

 

11. 스키마(Schema)

  • 데이터베이스의 구조와 제약 조건에 관한 전반적인 명세(Specification)를 기술(Description)한 메타데이터(Meta-Data)의 집합
  • 개체(Entity), 속성(Attribute), 관계(Relationship) 및 데이터 조작 시 데이터 값들이 갖는 제약 조건 등에 관해 전반적으로 정의
  • 외부 스키마 : 사용자나 응용 프로그래머가 각 개인의 입장에서 필요로 하는 데이터베이스의 논리적 구조를 정의한 것
  • 개념 스키마 : 데이터베이스의 전체적인 논리적 구조로서 모든 응용 프로그램이나 사용자들이 필요로 하는 데이터를 종합한 조직 전체의 데이터베이스로 하나만 존재 => 일반적인 스키마
  • 내부 스키마 : 물리적 저장장치의 입장에서 본 데이터베이스 구조로 형식을 정의하고 표현 방법, 물리적 순서 등을 나타냄 => 저장 스키마라고도 불림

 

 

 

 

 

728x90
728x90

 

 

 

1. 정의

  • 정점(Node, 노드)과 선분(Branch, 가지)을 이용하여 사이클을 이루지 않도록 구성한 그래프(Graph)의 특수한 형태
  • 노드(Node) : 하나의 기억 공간
  • 링크(Link) : 노드와 노드를 연결하는 선
  • 가족의 계보(족보), 조직도 등을 표현하기에 적합

 

 

 

 

2. 용어

  • 노드(Node) : 트리의 기본 요소로서 자료 항목과 다른 항목에 대한 가지(Branch)를 합친 것
  • 근 노드(Root Node) : 트리의 맨 위에 있는 노드
  • 디그리(Degree, 차수) : 각 노드에서 뻗어 나온 가지의 수
  • 단말 노드(Terminal Node) = 잎 노드(Leaf Node) : 자식이 하나도 없는 노드, 즉 디그리가 0인 노드
  • 자식 노드(Son Node) : 어떤 노드에 연결된 다음 레벨의 노드들
  • 부모 노드(Parent Node) : 어떤 노드에 연결된 이전 레벨의 노드들
  • 형제 노드(Brother Node, Sibling) : 동일한 부모를 갖는 노드들
  • 트리의 디그리 : 노드들의 디그리 중에서 가장 많은 수

 

 

 

 

3. 트리의 운행법(Traversal)

  • 트리를 구성하는 각 노드들을 찾아가는 방법
  • 이진 트리를 운행하는 방법은 산술식의 표기법과 연관성을 갖음
  • Preorder 운행 : Root → Left → Right 순으로 운행
  • Inorder 운행 : Left → Root → Right 순으로 운행
  • Postorder 운행 : Left → Right → Root 순으로 운행

 

 

 

 

4. 수식의 표기법

  • 산술식을 계산하기 위해 기억시키는 방법
  • 이진 트리를 많이 사용
  • 이진 트리로 만들어진 수식을 인오더, 프리오더, 포스트오더로 운행하면 각각 중위(Infix), 전위(Prefix), 후위(Prostfix) 표기법이 됨
  • 전위 표기법(PreFix) : 연산자 → Left → Right, +AB
  • 중위 표기법(InFix) : Left → 연산자 → Right, A+B
  • 후위 표기법(PostFix) : Left → Right → 연산자, AB+

 

 

 

 

 

728x90
728x90

 

 

 

5. 개발 언어의 선정 기준

  • 적정성 : 개발하려는 소프트웨어의 목적에 적합해야 함
  • 효율성 : 코드의 작성 및 구현이 효율적이어야 함
  • 이식성 : 다양한 시스템 및 환경에 적용이 가능해야 함
  • 친밀성 : 개발 언어에 대한 개발자들의 이해도와 활용도가 높아야 함
  • 범용성 : 다른 개발 사례가 존재하고 여러 분야에서 활용되고 있어야 함

 

 

 

 

6. 서버 개발

  • 서버 프로그램을 제작하여 웹 애플리케이션 서버(WAS)에 탑재하는 것을 의미
  • 서버 개발로 구축되는 서버는 웹 애플리케이션 서버임
  • 서버 개발에 사용되는 프로그래밍 언어 : Java, Java Script, Python, PHP, Ruby 등
  • 서버 개발을 위해 다양한 프레임워크들이 존재하며 프레임워크들은 언어에 종속적임

 

 

 

 

 

728x90

+ Recent posts