잔글편집 요약 없음 |
|||
| 1번째 줄: | 1번째 줄: | ||
데이터베이스(Database)는 특정 조직의 업무를 수행하는 데 필요한 상호 관련된 데이터들의 모임을 말한다. 베이스(Base)란 기지(基地)라는 의미를 가지고 있다. 유추해서 생각해보면 데이터베이스는 데이터를 공급하는 보급기지로 풀이된다. | |||
==데이터베이스 설계== | ==데이터베이스 설계== | ||
| 8번째 줄: | 6번째 줄: | ||
===데이터베이스 생명주기=== | ===데이터베이스 생명주기=== | ||
데이터베이스의 생명주기는 다음과 같다. | 데이터베이스의 생명주기는 다음과 같다. | ||
1. 요구 조건 분석(Requirements Analysis) | 1. 요구 조건 분석(Requirements Analysis) | ||
2. 설계(Design) | 2. 설계(Design) | ||
| 17번째 줄: | 14번째 줄: | ||
===데이터베이스 설계 단계=== | ===데이터베이스 설계 단계=== | ||
데이터베이스 생명주기 중 1~3단계 과정이다. | 데이터베이스 생명주기 중 1~3단계 과정이다. | ||
1. 요구 조건 분석: 요구 조건 명세서 작성 | 1. 요구 조건 분석: 요구 조건 명세서 작성 | ||
2. 개념적 설계: 개념스키마, 트랜잭션 모델링, E-R모델 | 2. 개념적 설계: 개념스키마, 트랜잭션 모델링, E-R모델 | ||
| 24번째 줄: | 20번째 줄: | ||
5. 구현: 특정 DBMS의 DDL로 데이터베이스를 생성한다. | 5. 구현: 특정 DBMS의 DDL로 데이터베이스를 생성한다. | ||
==== 요구 조건 분석 단계 ==== | ==== 제1단계: 요구 조건 분석 단계 ==== | ||
'''요구 조건 분석 단계'''에서는 시스템의 운영상태 등을 분석하고 사용자들의 요구사항에 대한 분석까지 포함하는 단계를 말한다. 소프트웨어 공학에서 눈덩이 효과를 보면 요구 조건 분석 단계에서 중요성을 알 수 있다. 분석 단계에서 작은 오류가 발생하면 경사면에서 굴러오는 눈덩이처럼 나중에는 커다란 시스템 완성 단계의 누적된 오류가 발생한다. 요구 조건 분석을 위한 방법으로는 인터뷰와 설문조사 등 있다. | '''요구 조건 분석 단계'''에서는 시스템의 운영상태 등을 분석하고 사용자들의 요구사항에 대한 분석까지 포함하는 단계를 말한다. 소프트웨어 공학에서 눈덩이 효과를 보면 요구 조건 분석 단계에서 중요성을 알 수 있다. 분석 단계에서 작은 오류가 발생하면 경사면에서 굴러오는 눈덩이처럼 나중에는 커다란 시스템 완성 단계의 누적된 오류가 발생한다. | ||
요구 조건 분석을 위한 방법으로는 인터뷰와 설문조사 등 있다. | |||
인터뷰 진행 절차는 다음과 같은 방식으로 진행된다. | 인터뷰 진행 절차는 다음과 같은 방식으로 진행된다. | ||
1. 계획과 준비단계: 인터뷰 일정, 인터뷰 지침, 인터뷰를 하는 요지, | 1. 계획과 준비단계: 인터뷰 일정, 인터뷰 지침, 인터뷰를 하는 요지, 인터뷰 시 기록 양식 등을 결정하는 단계이다. | ||
2. 인터뷰 수행 단계: 핵심 사항 및 상세 면담 기록을 작성한다. | 2. 인터뷰 수행 단계: 핵심 사항 및 상세 면담 기록을 작성한다. | ||
3. 인터뷰 결과 분석 단계: 인터뷰 결과를 분석한다. | 3. 인터뷰 결과 분석 단계: 인터뷰 결과를 분석한다. | ||
4. 분석 및 피드백 단계: 인터뷰 분석 결과를 승인 요청하고 승인 완료 후에는 프로젝트를 진행한다. | 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)'''는 엔티티 간의 관계로부터 도출한다. 관계가 있는 두 엔티티를 부모와 자식으로 구분한다. 부모 엔티티의 주 식별자 속성을 자식이 가지고 있는가 확인하고 없으면 추가해야 한다. 즉, 두 엔티티 간의 관계를 결정하여 주는 속성으로 관계에 의한 자식 엔티티에 위치하고 있으며 부모 엔티티의 주 식별자가 같은 값을 갖는다. | |||
2018년 12월 7일 (금) 20:28 판
데이터베이스(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)는 엔티티 간의 관계로부터 도출한다. 관계가 있는 두 엔티티를 부모와 자식으로 구분한다. 부모 엔티티의 주 식별자 속성을 자식이 가지고 있는가 확인하고 없으면 추가해야 한다. 즉, 두 엔티티 간의 관계를 결정하여 주는 속성으로 관계에 의한 자식 엔티티에 위치하고 있으며 부모 엔티티의 주 식별자가 같은 값을 갖는다.