① 업무 정보를 구성하는 기초가 되는 정보들을 일정한 표기법으로 표현한다.
② 분석된 모델로 데이터베이스를 생성하여 개발 및 데이터관리에 사용하기 위한 것이다.
③ 데이터베이스를 구축하는 목적으로 데이터 모델링을 수행하며 업무에 대한 설명은 별도의 표기법을 이용한다.
-> 데이터베이스만을 구축하기 위한 용도로 쓰이는 것이 아니다.
④ 데이터 모델링 자체로서 업무의 흐름을 설명하고 분석하는 부분에 의미를 가지고 있다.
① 통합된 모든 사용자의 관점은 개념스키마와 관련이 있다.
② 물리적인 저장구조를 표현하는 스키마는 내부스키마이다.
③ view 단계는 여러 사용자 관점으로 구성하는 개념스키마에 해당한다.
-> 여러 사용자 관점으로 구성하는 것은 외부스키마이다.
④ 논리적인 데이터 독립성을 고려하는 단계는 외부단계와 개념적 단계이다.
① 외부스키마
② 개념스키마
-> 통합관점의 스키마 구조를 표현한 것을 개념 스키마라고 한다.
③ 내부스키마
④ 논리스키마
데이터베이스 스키마 구조
외부 스키마
사용자가 보는 관점에서 데이터 스키마를 정의
사용자나 응용 프로그램이 필요한 데이터를 정의(View: 사용자가 접근하는 대상)개념 스키마
사용자 관점의 데이터베이스 스키마를 통합하여 데이터베이스의 전체 논리적 구조를 정의
전체 데이터베이스의 개체, 속성, 관계, 데이터 타입 등을 정의내부 스키마
데이터가 물리적으로 어떻게 저장되는지를 정의
데이터의 저장 구조, 컬럼, 인덱스 등을 정의함
S병원은 여러 명의 환자가 존재하고 각 환자의 이름, 주소 등을 관리해야한다.
① 병원
-> 병원은 S병원 1개이므로 엔터티로 성립되지 않는다. 엔터티는 2개 이상의 속성과 2개 이상의 인스턴스를 가져 소위 면적으로 표현될 수 있어야 기본적인 엔터티의 자격을 갖췄다고 할 수 있다.
② 환자
③ 이름
④ 주소
① 관계 엔터티
② 행위 엔터티
③ 중심 엔터티
④ 기본 엔터티
발생 시점에 따른 엔터티 분류
- 기본, 키 엔터티
- 중심 엔터티
- 행위 엔터티
① 도메인
② 속성
-> 데이터 모델링 관점에서 속성을 정의하자면, "업무에서 필요로 하는 인스턴스에서 관리하고자 하는 의미상 더 분리되지 않는 최소의 데이터 단위"로 정의할 수 있다.
③ 엔터티
④ 관계
① 엔터티에 대한 자세하고 구체적인 정보를 나타낸다.
② 하나의 엔터티는 두 개 이상의 속성을 갖는다.
③ 하나의 인스턴스에서 각각의 속성은 하나 이상의 속성값을 가질 수 있다.
-> 하나의 인스턴스에서 각각의 속성은 한 개의 속성값을 가져야 한다.
④ 속성도 집합이다.
엔터티(테이블), 인스턴스(행), 속성(컬럼), 속성값의 관계
- 한 개의 엔터티는 두 개 이상의 인스턴스 집합이어야 한다.
- 한 개의 엔터티는 두 개 이상의 속성을 갖는다.
- 한 개의 속성은 한 개의 속성값을 갖는다.
① 1차 정규화
② 2차 정규화
③ 3차 정규화
④ 4차 정규화
① 파생 속성
-> 다른 속성에 영향을 받아 발생하는 속성으로 계산된 값들이 이에 해당한다.
② 기본 속성
③ 설계 속성
④ PK 속성
① 관계는 존재에 의한 관계와 행위에 의한 관계로 구분될 수 있으나 ERD에서는 관계를 연결할 때, 존재와 행위를 구분하지 않고 단일화된 표기법을 사용한다.
② UML에는 클래스다이어그램의 관계 중 연관관계와 의존관계가 있고 이것은 실선과 점선의 표기법으로 다르게 표현이 된다.
③ 연관관계는 항상 이용하는 관계로 존재적 관계에 해당되고, 의존관계는 상대방 클래스의 행위에 의해 관계가 형성되는 행위적 관계에 해당한다.
④ 연관관계는 오퍼레이션에서 파라미터 등으로 이용할 수 있고, 의존관계는 소스코드에서 멤버변수로 선언하여 사용할 수 있다.
-> 연관관계는 소스코드에서 멤버변수로 선언하여 사용하게 하고
의존관계는 오퍼레이션에서 파라미터 등으로 이용할 수 있도록 되어 있다.
① 관계는 존재적 관계와 행위에 의한 관계로 나누어볼 수 있다.
② 관계의 표기법은 관계명, 관계차수, 식별성의 3가지 개념을 사용한다.
-> 관계 표기법은 관계명, 관계차수, 선택성(선택사양)의 3가지 개념으로 표현한다.
③ 부서와 사원 엔터티 간의 '소속'관계는 존재적 관계의 사례이다.
④ 주문과 배송 엔터티 간의 '배송근거'관계는 행위에 의한 관계의 사례이다.
① 논리적 독립성
② 물리적 독립성
-> 물리적 독립성은 물리 스키마가 변경되어도 논리 스키마에 영향을 주지 않는다.
물리적 독립성은 파일 저장 구조의 변경이 논리 스키마와 응용 프로그램에 영향을 주지 않는다.
③ 개념적 독립성
④ 내부적 독립성
(가) 두 개의 엔터티 사이에 관심 있는 연관규칙이 존재하는가?
(나) 두 개의 엔터티 사이에 정보의 조합이 발생되는가?
(다) 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?
(라) 업무기술서, 장표에 관계연결을 가능하게 하는 동사가 있는가?
① (가), (나), (다)
② (가), (나), (라)
③ (가), (다), (라),
④ (가), (나), (다), (라)
① 사원번호: number(10) | 주민등록번호 number(13)
② 이름: varchar(20) | 사원번호: number(10)
-> 명칭, 내역 등과 같이 이름으로 기술되는 것들은 주식별자로 지정하기에 적절하지 않다. 특히 사람의 이름은 동명이인이 있을 수 있기 때문에 주식별자로서 더더욱 부적절하다.
③ 주민번호: number(13) | 사원번호: number(10)
④ 일련번호: varchar2(10) | 주민등록번호 char(18) | 사원번호: number(10)
① 엔터티와 엔터티가 1:M 관계의 부모와 자식관계에서 데이터가 부모없이 자식쪽 엔터티의 인스턴스가 먼저 생성될 수 있을 경우 비식별자 관계로 연결해야 한다.
② 부모 엔터티의 인스턴스가 자식 엔터티의 인스턴스보다 먼저 소멸하는 경우 비식별자 관계로 연결해야 한다.
③ SQL 문의 조인 관계를 최소화 하는 경우 비식별자 관계로 연결해야 한다.
-> SQL 문의 조인관계를 최소화하기 위해 식별자 관계로 연결해야 한다.
④ 자식 엔터티의 식별자가 부모 엔터티의 주식별자를 상속받아 생성하는 것 보다 별도의 주식별자를 생성하는 것이 더 유리하다고 판단되는 경우 비식별자 관계로 연결해야 한다.
(가) 대표성을 가지며, 엔터티 내의 여러 인스턴스 중 하나를 유일하게 구분할 수 있는 식별자
(나) 엔터티 내의 여러 인스턴스 중 하나를 유일하게 구분할 수 있으나, 대표성을 가지지 못하는 식별자
(다) 엔터티 내의 집합을 명확하게 설명할 수 있는 업무적으로 의미가 부여된 식별자
(라) 다른 엔터티로부터 상속되어 정의된 식별자
③ (가) 주식별자 (나) 보조식별자 (다) 본질식별자 (라) 외부식별자
-> 본질식별자: 업무에 의해 만들어지는 식별자
외부식별자: 타 엔터티와의 관계를 통해 타 엔터티로부터 받아오는 식별자
업무 분석을 통해 바로 정의한 속성을 (㉠), 원래 업무상 존재하지는 않지만 설계를 하면서 도출해 내는 속성을 (㉡), 다른 속성으로부터 계산이나 변형이 되어 생성되는 속성을 (㉢)이라고 한다.
① ㉠ 기본 속성 ㉡ 설계 속성 ㉢ 파생 속성