데이터베이스

만물사전 프로젝트 누구나 수정, 추가 가능합니다. 이 만물사전은 누구나 수정, 추가 가능합니다. 전체 삭제는 문서 훼손 입니다.

데이터베이스(Database)는 특정 조직의 업무를 수행하는 데 필요한 상호 관련된 데이터들의 모임을 말한다. 베이스(Base)란 기지(基地)라는 의미를 가지고 있다. 유추해서 생각해보면 데이터베이스는 데이터를 공급하는 보급기지로 풀이된다.

데이터베이스 설계

데이터베이스 설계는 컴퓨터 세계의 데이터로 변환하기 위한 데이터베이스 모델링 과정을 말한다.

데이터베이스 생명주기

데이터베이스의 생명주기는 다음과 같다.

1. 요구 조건 분석(Requirements Analysis) 2. 설계(Design) 3. 구현(Implementation) 4. 운영(Operation) 5. 감시와 개선(Moniotoring and Tuning)

데이터베이스 설계 단계

데이터베이스 생명주기 중 1~3단계 과정이다.

1. 요구 조건 분석: 요구 조건 명세서 작성 2. 개념적 설계: 개념스키마, 트랜잭션 모델링, E-R모델 3. 논리적 설계: 목표 DBMS에 맞는 스키마를 설계한다. 4. 물리적 설계: 목표 DBMS에 맞는 물리적 구조의 데이터로 변환한다. 5. 구현: 특정 DBMS의 DDL로 데이터베이스를 생성한다.

제1단계: 요구 조건 분석 단계

요구 조건 분석 단계에서는 시스템의 운영상태 등을 분석하고 사용자들의 요구사항에 대한 분석까지 포함하는 단계를 말한다. 소프트웨어 공학에서 눈덩이 효과를 보면 요구 조건 분석 단계에서 중요성을 알 수 있다. 분석 단계에서 작은 오류가 발생하면 경사면에서 굴러오는 눈덩이처럼 나중에는 커다란 시스템 완성 단계의 누적된 오류가 발생한다.

요구 조건 분석을 위한 방법으로는 인터뷰와 설문조사 등 있다.

인터뷰 진행 절차는 다음과 같은 방식으로 진행된다.

1. 계획과 준비단계: 인터뷰 일정, 인터뷰 지침, 인터뷰를 하는 요지, 인터뷰 시 기록 양식 등을 결정하는 단계이다. 2. 인터뷰 수행 단계: 핵심 사항 및 상세 면담 기록을 작성한다. 3. 인터뷰 결과 분석 단계: 인터뷰 결과를 분석한다. 4. 분석 및 피드백 단계: 인터뷰 분석 결과를 승인 요청하고 승인 완료 후에는 프로젝트를 진행한다.

제2단계: 개념적 설계(Conceptual Design) 단계

개념적 설계(Conceptual Design)는 사용자들의 요구사항을 이해하기 쉬운 형식으로 간단히 기술하는 단계이다. DBMS에 독립적이고 고차원적인 표현 기법으로 기술한다. 개념적 설계를 표현하는 방법에는 객체 데이터 모델(Conceptual Data Model), E-R 다이어그램이 있다.

ERD(E-R 다이어그램)

ERD 또는 E-R(Entity-Relationship) 다이어그램이라고도 한다. E-R 다이어그램을 표현하는 방법에는 정보공학 · IE(Information Engineering) 방식, Idef1x(Integration Definition for Inforamtion Modeling) 방식이다.

엔티티 도출

엔티티(Entity)는 업무의 관심 대상이 되는 정보를 갖고 있거나 그에 대한 정보를 관리할 필요가 있는 유형을 말한다. 쉽게 말하면 실체, 개체를 말한다.

1. 업무 기술서에서 명사를 찾아 표시 2. 중복된 명사, 불명확한 개념, 광범위한 명사는 제거, 동의어 통일, 업무 진행 과정을 나타내는 단어 제거, 속성은 따로 분리한다. 3. 또는 직관적인 방법으로 엔티티를 찾을 수 있다. (핵심 엔티티를 찾아내고 앞에서 설명한 절차대로 나머지 엔티티를 찾아가면 쉽게 엔티티를 도출 할 수 있다.)

주 식별자 정의

주 식별자 또는 기본키(Primary Idntifier, PK; Primary Key)는 엔티티에 소속된 인스턴스(같은 클래스에 속하는 개개의 객체)들을 구분하는 기준이 되는 속성이다. 만일 어떤 속성 x가 엔티티의 주 식별자라면 그 엔티티에 속한 모든 인스턴스 속성 x 값을 비교했을 때 중복된 값이 나타나지 않아야 한다. 후보 식별자 중 가장 중요한 하나를 주 식별자로 나머지를 대체키로 지정한다.

관계의 정의

관계(relation)는 두 엔티티(entity) 타입 사이의 관계를 의미한다. 업무 흐름을 제대로 파악해야만 관계를 도출 할 수 있다. 어떤 엔티티 x의 정보가 만들어지기 위해서는 다른 엔티티 y의 정보를 필요로 하는 관계에 있을 경우 엔티티 y는 엔티티 x와의 관계를 가지게 되며 엔티티 y는 엔티티 x의 부모 엔티티가 된다.

외래식별자의 정의

외래식별자 또는 외부식별자, 외부키(Foreign Identifier, FK; Foreign Key)는 엔티티 간의 관계로부터 도출한다. 관계가 있는 두 엔티티를 부모와 자식으로 구분한다. 부모 엔티티의 주 식별자 속성을 자식이 가지고 있는가 확인하고 없으면 추가해야 한다. 즉, 두 엔티티 간의 관계를 결정하여 주는 속성으로 관계에 의한 자식 엔티티에 위치하고 있으며 부모 엔티티의 주 식별자가 같은 값을 갖는다.

제3단계; 논리적 설계(logical Design) 단계

논리적 설계(logical Design) 단계는 개념적 설계 단계에서 생성한 개념적 스키마(E-R 다이어그램)을 입력하여 특정 데이터베이스가 수행할 수 있는 스키마를 정의한다. 즉, E-R 다이어그램을 특정 DBMS를 위한 논리적 구조로 변형하는 것을 말한다. 이 과정에서 결과물은 릴레이션(관계 혹은 관계 데이터베이스) 스키마이다.

논리적 데이터 모델에는 관계 데이터 모델(Relational Data Model), 네트워크 데이터 모델(Network Data Model), 계층 데이터 모델(Hierarchical Data Model)이 있다.

• 관계 데이터 모델: 릴레이션(Relation) 즉, 표 또는 테이블(table)의 집합으로 되어있다.
• 네트워크 데이터 모델: 데이터 구조도가 네트워크(Network) 즉, 그래프의 형태를 취하고 있다.
• 계층 데이터 모델: 데이터 구조도가 트리(Tree) 형태이다.

규칙1: 모든 개체는 릴레이션으로 변환한다.

E-R 다이어그램의 각 개체를 하나의 릴레이션으로 변환한다. 개체(엔티티, Entity)의 이름을 릴레이션 이름으로 하고 개체가 가진 속성도 릴레이션 속성으로 그대로 변환한다. 개체가 가지고 있는 키 속성은 그대로 릴레이션의 기본키로 변환한다.

단, 개체가 가지고 있는 속성이 복합 속성인 경우 복합 속성을 구성하고 있는 단순 속성만 릴레이션의 속성으로 변환한다.

규칙2: 다대다(n:m) 관계는 릴레이션으로 변환한다.

E-R 다이어그램에 있는 다대다(n:m) 관계를 하나의 릴레이션으로 변환한다. 관계 이름을 릴레이션의 이름으로 하고 관계의 속성도 릴레이션 속성으로 그대로 변환한다. 단, 관계를 맺고 있는 개체가 무엇인지 중요하므로, 관계를 맺고 있는 개체들을 규칙1에 따라 변환한 후 이 릴레이션들의 기본키를 관계 릴레이션에 포함시키고 외래키로 지정한다. 그리고 이 외래키들을 조합하여 관계 릴레이션의 기본키로 지정한다.

고객 릴레이션의 기본키인 고객번호 속성과 상품 릴레이션의 기본키인 상품번호 속성을 가져와 주문 릴레이션에 포함시키고 외래키로 지정한다. 그런 다음 두 외래키를 조합하여 주문 릴레이션의 기본키로 지정한다. 필요하다면 주문번호 속성과 같은 별도의 기본키를 지정할 수도 있다.

규칙3: 일대다(1:n) 관계는 외래키로 표현한다.

일반 개체들이 참여하는 일대다(1:n) 관계는 릴레이션으로 변환하지 않고 외래키로만 표현한다. 관계를 맺고 있는 개체들을 규칙1에 따라 변환한 릴레이션 중에서, 일대다(1:n) 관계의 1측 개체 릴레이션의 기본키를 가져와 n측 개체 릴레이션에 포함시키고 외래키로 지정한다. 관계의 속성들도 n측 개체 릴레이션에 포함시킨다. 단, 외래키나 관계의 속성을 포함시킬 때 해당 릴레이션의 원래 개체 속성과 이름이 같으면 이름을 변경해야 한다.

만약 n측 개체 릴레이션의 기본키를 가져와 1측 개체 릴레이션에 외래키로 포함시키면 해당 외래키가 다중 값을 가져 릴레이션의 특성을 위반하게 되므로 반드시 1측 개체 릴레이션의 기본키를 n측 개체 릴레이션의 외래키로 지정해야 한다.

예외적으로, 약한 개체가 참여하는 일대다 관계는 외래키를 포함해서 기본키로 지정한다. 규칙 3처럼, 약한 개체가 참여하는 일대다(1:n) 관계도 릴레이션으로 변환하지 않고 외래키로만 표현한다.

규칙4: 일대일(1:1) 관계는 외래키로 표현한다.

E-R 다이어그램에 있는 일대일(1:1) 관계도 일대다(1:n) 관계처럼 릴레이션으로 변환하지 않고 외래키로만 표현한다. 이때, 데이터의 중복을 피하려면 개체가 관계에 참여하는 특성에 따라 약간 다르게 처리해야 한다.

규칙4-1: 일반적인 일대일 관계는 외래키를 서로 주고 받는다.

일반적인 일대일(1:1) 관계는 릴레이션으로 변환하지 않고 외래키로만 표현한다. 관계를 맺고 있는 개체들을 규칙1에 따라 변환한 릴레이션들이 서로의 기본키를 주고 받아 이를 외래키로 지정한다. 이때, 관계가 가지고 있는 속성들은 관계에 참여하는 개체를 변환한 릴레이션에 모두 포함시킨다.

규칙4-2: 일대일 관계에 필수적으로 참여하는 개체의 릴레이션만 외래키를 받는다.

일대일(1:1) 관계를 맺고 있는 두 개체 중 관계에 필수적으로 참여하는 개체에 대응하는 릴레이션에만 외래키를 포함시킨다. 즉, 관계에 필수적으로 참여하는 개체에 해당하는 릴레이션이 선택적으로 참여하는 개체에 해당하는 릴레이션의 기본키를 받아 외래키로 지정한다. 이때, 관계가 가지고 있는 속성들도 관계에 필수적으로 참여하는 개체에 해당하는 릴레이션에 함께 포함시킨다.

규칙4-3: 모든 개체가 일대일 관계에 필수적으로 참여하면 릴레이션 하나로 합친다.

일대일(1:1) 관계를 맺고 있는 두 개체가 모두 관계에 필수적으로 참여한다면 그만큼 관련성이 있는 개체라는 의미다. 그러므로 두 개체에 해당하는 릴레이션들을 하나로 합쳐 표현한다. 관계의 이름을 릴레이션의 이름으로 사용하고, 관계에 참여하는 두 개체의 속성들도 관계 릴레이션에 모두 포함시킨다. 그리고 두 개체 릴레이션의 키 속성을 조합하여 관계 릴레이션의 기본키로 지정한다.

규칙5: 다중 값 속성은 릴레이션으로 변환한다.

관계 데이터 모델의 릴레이션에서는 다중 값을 가지는 속성을 허용하지 않는다. 그러므로 E-R 다이어그램에 있는 다중 값 속성은 그 속성을 가지고 있는 개체에 해당하는 릴레이션이 아닌 별도의 릴레이션을 만들어 포함시킨다. 새로 만들어진 릴레이션에는 E-R 다이어그램에서 다중 값 속성으로 표현된 속성뿐만 아니라 그 속성을 가지고 있는 개체에 해당하는 릴레이션의 기본키를 가져와 포함시키고 이를 외래키로 지정한다. 새로 만들어진 릴레이션의 이름은 자유롭게 정하고, 기본키는 다중 값 속성과 외래키를 조합하여 지정한다.

기타 고려 사항

규칙 4-1처럼 외래키를 서로 주고 받지 않고 릴레이션으로 변환하면 다음과 같다. 다대다(n:m) 외의 관계를 릴레이션으로 변환해도 된다. 하지만 그러면 생성되는 릴레이션의 개수가 많아져 릴레이션을 관리해야 하는 DBMS의 부담이 커지게 된다. 그러므로 릴레이션의 개수가 불필요하게 늘어나지 않도록 외래키만으로도 표현이 가능한 일대일(1:1)이나 일대다(1:n) 관계는 릴레이션으로 변환하지 않는 것이 좋다.

E-R 다이어그램에서 사원 개체가 자기 자신과 관리 관계를 맺고 있는 것도 있다. 사원 개체는 상사와 부하직원이라는 서로 다른 역할로 관계를 맺고 있지만 관리 관계에 참여하는 실제 개체는 사원 개체 하나뿐이다. 하나의 개체만 관계에 참여하는 특수한 형태이지만 순환 관계도 기본 규칙을 그대로 적용한다. 먼저 사원 개체를 규칙1에 따라 사원 릴레이션으로 변환한다.E-R 다이어그램에서 관리 관계는 일대다(1:n)이므로 릴레이션을 생성하지 않고 외래키로만 표현한다.

ISA

ISA는 두 개체(엔티티)가 다른 개체의 하위 분류일 경우가 있을 수 있다. ISA라는 말을 안에 써넣은 삼각형으로 표시하고 수퍼클래스는 위쪽에 다른 하위 분류의 서브클래스들은 아래쪽에 그린다.

수퍼클래스인 학생 릴레이션의 기본키인 학번이 서브클래스 재학생, 휴학생, 졸업생 릴레이션의 외래키로 들어간다.

용어사전(Data Dictionary) 정의

논리적 데이터베이스 설계나 물리적 데이터베이스 설계시 사용되는 용어 정의 문서를 말한다. 용어사전의 정의 방법에는 다음과 같은 방법으로 진행한다.

1. 개체(엔티티) 이름과 속성 이름들을 모아 리스트를 만든다.

2. 엔티티 이름이나 속성 이름이 여러 단어를 포함할 경우 분리한다.

3. 마지막 단어를 기준으로 정렬한다.

4. 단어에 대해 영어 단어를 붙이고 용어의 의미를 설명한다.

도메인 정의

물리적 데이터베이스에서 개체(엔티티)의 속성에 대응하는 테이블의 열(칼럼)에 대한 데이터 타입과 크기, 데이터에 대한 제약 사항등을 지정하는 것이다.

도메인을 정의하는 방법은 다음과 같다.

1. 각 개체(엔티티)에서 소겅들을 모아 리스트를 만든다. 2. 속성 이름이 여러 단어를 포함할 경우 분리한다. 3. 마지막 단어를 기준으로 정렬한다. 4. 도메인을 정한다. 5. 도메인만 모아 정리한다.

1~3은 앞서 ‘용어사전’을 통해 정리하였으므로 4.부터 작업을 진행하면 된다.

4. 도메인을 정한다.

5. 도메인만 모아 정리한다.

제4단계: 물리적 설계(physical Design) 단계

물리적 설계 단계(Physical Design)는 다음 일련의 과정을 거쳐 물리적 설계를 한다.

사용 DBMS 결정 → 데이터 타입 크기 결정 → 데이터 용량 및 설계 및 업무 프로세스 분석 → 역정규화 → 무결성 제약조건 정의 → 인덱스 정의 → 데이터베이스 생성

물리적 설계 시 고려사항은 응답시간을 최소화해야 하고 저장공간을 효율화 해야 하며, 트랜잭션 처리도(처리능력)를 고려 해야 한다.

데이터베이스 설계를 위한 인덱스 활용

자료 검색 방법에는 두가지 방법이 있다. 테이블을 처음부터 끝까지 검색하는 방법인 FTS(Full Table Scan) 방법과 인덱스를 통해 부분 검색을 하여 인덱스에 저장된 테이블의 ROW ID를 가지고 테이블을 검색한 후 정보를 가져오는 검색방법인 인덱스 스캔(Index scan) 방법이 있다.

• 논리적 구분에 따른 인덱스

• 물리적 구분에 따른 인덱스

성능 향상을 위한 인덱스 관리 방법에는 다음과 같다.

1. 인덱스 정보 확인 2. 인덱스 재구축 3. 인덱스 삭제

1. 인덱스 정보 확인

• DBA_INDEXES는 DBA 권한으로 확인할 수 있는 뷰이다.
• USER_INDEXES는 일반 사용자 권한으로 자신이 생성한 인덱스 정보를 확인할 수 있는 뷰이다.
• ALL_INDEXES는 일반 사용자 권한으로 다른 사용자가 생성한 인덱스 정보를 확인할 수 있는 뷰이다.

2. 인덱스 재구축

[인덱스 재구축 SQL] SQL>ALTER INDEX idx_ename_emp REBUILD TABLESPACE indx02;

3. 인덱스 삭제 SQL> DROP INDEX idx_ename_emp;