2026. 2. 3. 09:30ㆍ대우개발원 수업 내용/Database (sql)
[ ER모델 개념 ]
ER(Entity-Relationship, 개체-관계) 모델이란?
- 개체 타입(entity type)과 관계 타입(relationship type)을 이용해서 현실 세계의 데이터를
사람이 이해하기 쉽게 개념적으로 표현하는 개념적 데이터 모델
- 1976년 피터 첸(Peter Chen) 박사가 제안
- 매우 단순하다는 장점 때문에 현재 가장 널리 사용됨
- 보통 ER 다이어그램(diagram)으로 표현됨
- 사용자, 즉 DB 설계자를 위한 모델이므로 DBMS는 이해할 수 없음
[ ER 모델 기본요소 ]
- 개체(entity) DB가 표현하려고 하는 유,무형의 정보 대상으로서, 현실 세계에 존재하면서 서로 구별할 수 있는 요소다.
- 관계(relationship) : 개체 간의 의미 있는 연결 또는 연관성을 표현하는 요소다.
- 속성 (attribute) : 개체나 관계의 특성을 나타내는 요소로서, 이름을 가진 정보ㄹ의 가장 적은 논리적 단위다.
[ 개체 개념 ]
개체(entity)란?
- 현실 세계에 존재하면서 서로 구별되는 유형 또는 무형의 정보 대상
- 둘 이상의 속성(attribute)으로 구성됨
- 파일 시스템에서 '레코드(record)'에 대응함
- 단독으로 존재할 수 있고 정보의 역할을 함
개체 구분
① 개념적 개체: 개념적으로는 존재하지만 대개 눈에 보이지 않는 무형의 개체
예) 사건, 평가, 승진 등
② 물리적 개체: 실제로 존재하면서 눈에 보이는 유형의 개체
예) 학생, 상품, 부동산 등
ER 다이어그램에서 개체 표현 방법 : 직사각형
[ 개체 관련 주요 개념 ]
- 개체 타입(entity type): 개체의 이름과 개체를 구성하는 속성들을 정의한 것이다.
ex) 사원(사번, 이름, 입사일, 전공)
- 개체 인스턴스(entity instance): 개체의 속성들이 구체적인 값을 가짐으로써 실체화된 것이다.
ex) (241013, ‘김희망’, 20240901, ‘컴퓨터공학’)
- 개체 집합(entity set): 동일한 개체 타입에 속하는 개체 인스턴스들의 집합이다.
ex) (241013, ‘김희망’, 20240901, ‘컴퓨터공학’),
(241120, ‘이소망’, 20240115, ‘기계공학’),
…
- 속성(attribute): 개체의 특성을 나타내는 기본 요소다.
ex) 사번, 이름, 입사일, 전공
[ 사원 개체를 정의하는 주요 개념들 ]
[개체: 사원]
┌──────────────┐
│ 개체 타입 │
│──────────────│
│ 사번 │
│ 이름 │
│ 입사일 │
│ 전공 │
└──────────────┘
↓
┌────────────────────────────────────────────┐
│ 개체 인스턴스 ① │
│────────────────────────────────────────────│
│ 사번: 241013 │
│ 이름: 김희망 │
│ 입사일: 2024-09-01 │
│ 전공: 컴퓨터공학 │
└────────────────────────────────────────────┘
┌────────────────────────────────────────────┐
│ 개체 인스턴스 ② │
│────────────────────────────────────────────│
│ 사번: 241120 │
│ 이름: 이소망 │
│ 입사일: 2024-01-15 │
│ 전공: 기계공학 │
└────────────────────────────────────────────┘
↓
[개체 집합: 사원 인스턴스들의 모음]
[ 속성 개념 ]
속성(attribute)이란?
- 개체나 관계의 특성을 나타내는 기본 요소
- 파일 시스템의 데이터 항목(data item) 혹은 필드(field)에 대응함
- 이름을 가진 정보의 가장 작은 논리적 단위이지만 단독으로 존재할 때는 대개 무의미함
✔ (241013, '김희망', 20240901, '컴퓨터공학') → "김희망의 전공이 컴퓨터공학"이라는 정보 제공
✔ '김희망' 또는 '컴퓨터공학' → 하나의 속성값만으로는 아무런 정보도 제공하지 못함
ER 다이어그램에서 속성 표현 방법: 타원형
- (a) 타원 안에 속성 이름 표현
사원
├── 사번
├── 이름
├── 입사일
├── 전공
└── 휴대폰 - 타원 밖에 속성 이름 표현
사원
├── ○ 사번
├── ○ 이름
├── ○ 입사일
├── ○ 전공
└── ○ 휴대폰
✔ 도메인(domain): 각 속성이 가질 수 있는 값의 범위
[ 속성의 종류 ]
① 상수 속성(constant attribute)
② 시변 속성(time varying attribute)
③ 단순 속성(simple attribute 또는 atomic attribute)
④ 복합 속성(composite attribute)
⑤ 단일치 속성(single-valued attribute)
⑥ 다중치 속성(multi-valued attribute)
⑦ 유도 속성(derived attribute)
⑧ 저장 속성(stored attribute)
⑨ 널 속성(null attribute)
⑩ 기본키 속성(primary key attribute)
⑪ 부분키 속성(partial key attribute)
[ 상수 속성과 시변 속성 ]
상수 속성(constant attribute)
- 시간이 지나도 값이 변하지 않는 속성
예) 주민등록번호
시변 속성(time varying attribute)
- 시간이 지남에 따라 값이 변할 수 있는 속성
예) 주소, 휴대폰
[ 단순 속성과 복합 속성 ]
단순 속성(simple attribute 또는 atomic attribute)
- 더 이상 작은 구성 요소로 분해할 수 없는 속성
예) 회원번호, 이름, 휴대폰
복합 속성(composite attribute)
- 독립적인 의미가 있는 단순 속성들로 분해할 수 있는 속성
예) 주소
[ 단일치 속성과 다중치 속성 ]
단일치 속성(single-valued attribute)
- 특정 개체에 대해 단 하나의 값만 갖는 속성
예) 주민등록번호, 학번
다중치 속성(multi-valued attribute)
- 특정 개체에 대해 여러 개의 값을 가질 수 있는 속성
예) 취미, 자격증
- ER 다이어그램에서 이중선 타원으로 표현함
[ 유도 속성과 저장 속성 ]
유도 속성(derived attribute)
- 속성의 값이 그와 관련된 다른 속성의 값으로부터 유도되어 결정되는 속성
- ER 다이어그램에서 유도 속성은 점선 타원으로 표시
저장 속성(stored attribute)
- 유도 속성을 결정하기 위해 사용된 속성
[ 널 속성 ]
널 속성(null attribute)이란?
- 널 값을 갖는 속성
널 값이란?
- 어떤 개체 인스턴스가 특정 속성에 대한 값을 갖고 있지 않을 때, 이를 명시적으로 표시하기 위해
사용하는 값
널 값을 갖는 경우
① 어떤 속성의 값이 그 개체 인스턴스에 ‘해당되지 않는(not applicable)’ 경우
예) 학생 개체의 여학생 경우 ‘군필여부‘ 속성 값
② 어떤 속성의 값을 ‘알 수 없는(unknown)’ 경우
㉠ 값이 존재하지만 값이 누락(missing)된 경우
예) 환자 개체의 ‘몸무게‘나 ‘키’ 속성 값
㉡ 값의 존재 여부를 모르는(not known) 경우
예) 학생 개체의 ‘토익성적’ 속성 값
[ 기본키 속성과 부분키 속성 ]
기본키 속성(primary key attribute)
- 개체 집합을 구성하는 각 개체 인스턴스들을 유일하게 식별할 수 있는 속성 또는 속성들의 집합
- 주 식별자(primary identifier)라고도 칭함
예) 대학생 개체의 ‘학번‘
- ER 다이어그램에서 속성 이름 밑에 실선 표시 혹은 검은색 타원형으로 표현
부분키 속성(partial key attribute)
- 개체를 식별할 수 있는 키를 형성하기에 충분한 속성을 갖지 못한 약한 개체 타입의 부분적인 식별자
- ER 다이어그램에서 속성 이름 밑에 점선 표시 혹은 회색 타원형으로 표현
[ 관계 개념 ]
관계(relationship)란?
- ER 모델에서 개체 간의 의미 있는 연결 또는 연관성을 표현하는 요소로서,
개체 집합 간의 대응 관계를 표현함
- 개체와 마찬가지로 관계 타입과 관계 인스턴스로 구성됨
ER 다이어그램에서 관계 표현 : 마름모
○ 사번
○ 이름
○ 휴대폰
│
┌───────────┐
│ 사원 │
└───────────┘
│
│
◇ 근무하다 ◇(마름모)
│
│
┌───────────┐
│ 부서 │
└───────────┘
│
○ 부서번호
○ 부서명
○ 사무실관계 타입의 속성이란?
- 관계가 두 개체 간의 관련성을 나타내므로 관련된 두 개체의 기본키 속성을 그대로 관계의 속성으로 가짐
- 관계 타입은 자체적으로는 기본키 속성이 없음
- 관계 타입도 관계를 설명하는 속성(들)을 가질 수 있음
[ 일대일(1:1) 유형 ]
- 어느 개체를 기준으로 보더라도 개체 인스턴스 하나가 다른 개체 인스턴스 하나와만 연관성이 있는 유형
- 예: 학생 1명에게 노트북 1대를 대여하는 ‘대여하다’ 관계
┌───────────┐
│ 학생 1 │
└───────────┘
│
│
◇ 대여하다 ◇
│
│
┌───────────┐
│ 노트북 1 │
└───────────┘[ 일대다(1:n) 또는 다대일(n:1) 유형 ]
- 두 개체 가운데 어느 한 개체를 기준으로 보면 하나 이상의 개체 인스턴스와 연관성이 있고,
다른 개체를 기준으로 보면 한 개체 인스턴스와만 연관성이 있는 유형
- 예: 교수 개체와 학생 개체 간의 ‘지도하다’ 관계
┌───────────┐
│ 교수 1 │
└───────────┘
│
│
◇ 지도하다 ◇
│
│
┌───────────┐
│ 학생 n │
└───────────┘[ 다대다(m:n) 유형 ]
- 두 개체 가운데 어느 개체를 기준으로 보더라도 하나 이상의 개체 인스턴스와 연관성이 있는 유형
- 즉, 여러 개체 인스턴스가 다른 여러 개체 인스턴스와 연관되는 유형
- 예: 학생 개체와 교과목 개체 간의 ‘수강하다’ 관계
┌───────────┐
│ 학생 m │
└───────────┘
│
│
◇ 수강하다 ◇
│
│
┌───────────┐
│ 교과목 n │
└───────────┘[ 카디널리티(cardinality)란? ]
- 관계에 참여하는 하나의 개체에 대해 다른 개체가 몇 개 대응하는지를 나타내는 것으로,
관계에 대응하는 개체 수를 의미함
- 카디널리티는 한 쌍의 값인 (min, max)로 표현함
┌───────────┐
│ 교수 1 │
└───────────┘
(0,3) ------------- 부분 참여
│
│
◇ 강의하다 ◇
│
│
┌───────────┐
│ 교과목 n │
└───────────┘
(1,1) -------------- 전체 참여- 강의하다 관계에 참여하는 교수 및 교과목 개체의 카다널리티 표현
┌───────────┐
│ 학생 m │
└───────────┘
(0,7)
│
│
◇ 수강하다 ◇
│
│
┌───────────┐
│ 교과목 n │
└───────────┘
(15,100)- 수강하다 관계에 참여하는 학생 및 교과목 개체의 카다널리티 표현
[ 차수(degree)란? ]
- 관계로 연결된 개체 타입의 수를 의미함
- 차수의 유형 : 1진 관계, 2진 관계, 3진 관계, n진 관계(혹은 다원 관계) 등
[ 다중 관계(multiple relationship)란? ]
- 두 개체 타입 사이에 2개 이상의 관계가 존재하는 것
[ 순환 관계와 역할 ]
순환 관계(recursive relationship)란?
- 하나의 개체 타입이 동일한 관계 타입에 두 번 참여하는 것 (자기 참조 관계라고도 칭함)
역할(role)이란?
- 관계 타입의 의미를 명확히 하기 위해 관계 타입의 간선 위에 표시한 것
- 순환 관계의 경우 하나의 개체 타입이 두 가지 역할을 하게 되므로 반드시 역할을 표기하는 것이 좋음
[ ER 다이어그램 개념 ]
ER 다이어그램(ER Diagram)이란?
- 개념적 데이터 모델인 ER 모델을 그래픽 방식으로 표현하는 방법
- 1976년 피터 첸(Peter Chen)이 처음 제안
ER 다이어그램 작성 시 유의 사항
① 개체 타입은 반드시 기본키 속성을 포함해야 함
② 기본키 속성 외에 개체 타입을 직접적으로 설명하는 속성도 표현함
③ 코드 개체를 제외한 모든 개체 타입은 독자적으로 존재할 수 없음
④ 관계 타입은 독자적으로 존재할 수 없음
⑤ 기본키 속성(또는 속성 집합)은 실선으로 밑줄을 표시함
ER 다이어그램의 특징
① 다대다(m : n) 관계 표현 가능
② 다원 관계를 표현할 수 있음
- 3진 관계처럼 3개의 개체 타입이 하나의 관계에 연관된 것 표현 가능
③ 다중 관계 표현 가능
- 두 개체 타입 사이에 둘 이상의 관계가 존재하는 것 표현 가능
④ 관계 타입을 설명하는 속성을 쉽게 표현할 수 있음
[ 개념적 설계 ]
개념적 설계란?
- 요구 분석 명세서를 기초로 하여 사용자의 요구사항을
DB 설계자가 쉽게 이해할 수 있도록 표현하는 과정
개념적 설계 단계의 두 가지 주요 업무
1 개념적 스키마 모델링(conceptual schema modeling)
2 트랜잭션 모델링(transaction modeling)
개념적 스키마 모델링(conceptual schema modeling)이란?
- 데이터 요구 분석 명세서를 기초로 하여 DBMS와는 독립적인 개념적 데이터 모델,
즉 개념적 스키마(conceptual schema)를 표현하는 과정
- 줄여서 개념적 모델링이라고도 함
- 데이터의 구성과 표현에 초첨을 맞추므로 데이터 중심의 DB 설계에 해당함
[ 개념적 스키마 모델링 ]
ER(Entity-Relationship) 모델: 현재 가장 널리 사용되고 있는 개념적 데이터 모델
이해하기 쉽게 ER 다이어그램(diagram)으로 표현
ER 다이어그램으로 표현한 개념적 스키마 모델링의 결과를 개념적 구조(conceptual structure)
또는 개념적 스키마(conceptual schema)라고 함
[ 트랜잭션 모델링 ]
트랜잭션 모델링(transaction modeling)이란?
- 트랜잭션 요구 분석 명세서를 기초로 하여 업무 단위별로 유형별 트랜잭션을 표현하는 과정
- 트랜잭션의 유형 : 읽기(검색), 쓰기(삽입, 삭제, 갱신), 혼합(읽기+쓰기) 등
- 데이터 처리에 초점을 맞추므로 처리 중심의 DB 설계에 해당함
- 설계 초기 단계부터 응용 프로그램 개발의 기초가 되는 트랜잭션을 식별하는 작업이 중요함
커밋과 롤백
[ 개념적 스키마 모델링 순서 ]
ER 모델을 활용한 개념적 스키마 모델링 순서
① 데이터 요구 분석 명세서를 기초로 하여 개체 타입을 식별한다.
② 개체 타입들 간의 관계 타입을 식별한다.
③ 관계 타입의 유형과 카디널리티(옵션)를 결정한다.
④ 개체 타입의 속성을 식별한다.
⑤ 개체 타입의 주 식별자, 즉 기본키 속성을 결정한다.
⑥ 관계 타입의 속성을 식별한다.
⑦ 식별한 개체 타입과 관계 타입, 개체 및 관계 타입의 속성을 모두 ERD로 표현한다.
⑧ ERD가 데이터 요구 분석 명세서에 포함된 모든 요구사항을 반영하는지 검증한다.
[ 개체 식별 ]
개체
- DB가 표현하려고 하는 유·무형의 정보 대상으로서, 현실 세계에 존재하면서 서로 구별될 수 있는 요소
개체 타입(entity type)이란?
- 개체에 대한 정의, 즉 개체의 이름과 개체를 구성하는 속성들을 정의한 것
개체 식별의 중요성
- 어떤 개체가 식별 되느냐에 따라 속성과 관계가 달라질 수 있음
- 개체 하나에 평균 4~5개 정도의 응용 프로그램이 개발되므로 개체 식별이 DB 구축의 성패를 좌우
[ 개체 식별 방법 ]
개체 식별 순서 및 방법
① 개체 후보 식별
- 데이터 요구 분석 명세서에서 주로 주어나 목적어로 표현된 것이 개체 타입 후보가 될 수 있음
② 개체 후보 검토
- 각 개체 후보의 실제 데이터 수와 대표 속성 파악
- 동음이의어나 이음동의어 등도 검토
- 동사로 표현되었는데(or 동사화할 수 있는데) 개체로 잘못 추출된 것이 있는지 검토
- 필요한 경우 개체 이름 변경 가능
③ 개체 타입 선정
- 실제 데이터(즉, 개체 인스턴스)가 2개 이상 존재하고, 2개 이상의 속성을 지닌 개체 후보를
개체 타입으로 선정
- 동일한 의미를 갖는 개체가 있으면 제외시킴
- 추후 관계로 표현하는 것이 더 적합한 개체가 있으면 개체 타입에서 제외시켜야 함
[ 개체 표현 방법 ]
피터 첸 표기법(Peter Chen Notation)
- 둘 이상의 속성(타원형으로 표현)과 연결된 직사각형으로 표현하고,
주 식별자(즉, 기본키 속성)는 속성 이름 아래 밑줄 표현 또는 검은색 타원형으로 표현
IE(Information Engineering: 정보공학) 표기법
- 관계의 다 측(n측)을 나타내기 위해 까마귀발 모양을 사용하기 때문에 까마귀발 표기법(Crow’s feet notation) 또는
새발 표기법이라고도 부름
- 개체는 사각형으로 표현하고, 사각형 위에 개체 이름을 표시하며, 기본키와 일반 속성을 구분해서 표현함
[ 개체 이름 결정 방법 ]
① 개체 이름은 반드시 전체 DB 안에서 유일해야 함
② 현업에서 익숙한 표준 용어를 사용함
③ 단수 명사를 사용함
④ 가능하면 약어는 사용하지 않음
⑤ 개체의 성격을 쉽게 파악할 수 있는 이름을 부여함
⑥ 이름의 일관성을 위해 이름 부여 규칙을 미리 정하는 것이 좋음
예) 여러 개 명사로 구성된 개체 개체 이름의 경우,
공백 없이 연결(예: 장비구매처) or 밑줄로 명사 연결(예: 장비_구매처)
⑦ DB 구축 프로젝트와 관련된 자료 사전 또는 용어 사전을 만들어서 참조하는 것이 좋음
- 사전에 각 개체에 대한 명확한 정의를 포함시키는 것이 좋음
[ 개체 후보 식별 방법 ]
개체 후보 식별 시 유의 사항
① 일단 개체가 될 가능성이 있는 모든 대상 추출한다.
- 데이터 요구 분석 명세서에서 주로 주어나 목적어로 표현된 것
② 유사한 개체(예: 이음동의어)도 무시하지 말고 모두 추출한다.
③ 어떤 대상이 해당 개체에 속하는지가 분명하도록 각 개체 정의한다.
예) 학생을 ‘우리 대학에 재학 중인 사람’으로 정의하면
> 수시 합격생이나 졸업생, 수료생은 학생 개체에 속하지 않음
④ 업무 처리 과정을 지나치게 고려하지 않는다.
추후 업무 처리 과정이 달라질 수 있으므로, 우선 데이터 중심 설계에 초점 맞추어 개체 추출
⑤ 개념이 명확하지 않은 대상은 업무 담당자에게 다시 확인한다.
⑥ 예외 상황은 무시하고 넘어간다.
> 핵심 개체를 추출하는 데 더 집중함
⑦ 개체 후보 가운데 선정된 개체의 핵심적인 특징을 파악해 본다.
> 개체의 특징을 설명하는 속성이 적어도 2개 이상 존재해야 함
[ 관계 식별 방법 ]
관계(relationship)란?
- 개체들 간의 의미 있는 연결 또는 연관성을 의미하는 요소
- 관계를 제대로 식별하지 못하면 많은 개체에 동일한 속성이 중복되어 데이터의 일관성 보장이 어려움
관계 식별 방법
① 데이터 요구 분석 명세서에서 ‘동사’로 표현된 부분(또는 동사화할 수 있는 부분)이 개체 간의
관련성을 표현하는 경우, 관계로 식별
② 식별된 개체 가운데 ‘관계’로 표현해야 더 적합한 것은 관계로 전환
③ 관계 이름 부여
④ 관계 유형 결정(필요한 경우 카디널리티도 결정)
⑤ 관계를 설명하는 속성 파악
⑥ 관계 이름과 유형, 속성 등이 포함된 관계 타입 목록 작성
[ 관계 식별 시 유의 사항 ]
유의 사항
① 관계는 개체 간의 상호 연관성을 표현하는 것으로, 개체와 관련된 업무 수행 규칙에 해당함
> 데이터 요구 분석 명세서에서 주로 동사 또는 동사화할 수 있는 형태로 표현되는 경우가 많음
② 업무를 충분히 파악한 다음 전체 업무를 고려해서 넓은 시각으로 분석해야 함
③ 업무 규칙이 변경됨에 따라 관계도 변경될 수 있음을 염두에 둠
④ 식별된 개체 가운데 ‘관계’로 표현하는 것이 적합한 단어가 있는지 검토함
⑤ 관계는 기본적으로 관계에 포함된 양쪽 개체의 기본키를 속성으로 갖게 됨
> 관계의 속성을 파악할 때는 관계를 설명하기 위해 추가로 필요한 속성을 파악하는 데 집중함
[ 관계 표현 방법 ]
피터 첸 표기법
- 관계는 1개 이상의 개체를 실선으로 연결하는 마름모로 표현하고, 관계 유형을 실선 위에 표시함
IE 표기법
- 개체를 선(비식별 관계 타입은 점선, 식별 관계 타입은 실선)으로 연결하고 선 위에 관계 이름을 표시함
- 개체 간의 관계를 나타내는 외래키를 두 개체 가운데 하나에 포함시키고, 관계 유형은 까마귀발 모양으로 표현함
[ 관계 이름 결정 방법 ]
관계 이름 결정 시 유의 사항
① 가능하면 개체 간의 관련성을 나타내는 동사로 표현함
예) 지도하다, 수강하다, 근무하다
② 현재 시제로 표현함
③ 개체 간의 관련성이 명확하도록 표현함
④ 관계 이름은 DB 안에서 유일해야 함
⑤ 부연 설명이 필요 없는 일반적인 용어로 표현함
[ 속성 식별 ]
속성 식별 방법
① 데이터 요구 분석 명세서에서 개체를 설명하는 명사를 개체의 속성으로 식별
② 데이터 요구 분석 명세서에서 관계를 설명하는 명사를 관계의 속성으로 식별
③ 데이터 요구 분석 명세서에서 개체의 기본키 속성을 식별할 수 없을 때는 기본키 역할을 할 속성 추가
④ 데이터 요구 분석 명세서에는 없지만 개체나 관계의 특성을 설명하는 데 필요한 속성이 있다면 속성을 추가로 식별
유의 사항 1
① 유일한 기본키, 즉 주 식별자(primary identifier)와 설명자(descriptor), 즉 일반 속성을 구분해서 식별
② 개체와 관계가 식별되면 큰 틀의 개념적 모델이 완성되지만, 속성이 식별되어야 개체의
특성이 분명해지므로 주요 속성 모두 식별
③ 개체 및 관계를 식별할 때 주요 속성을 먼저 식별하지만, 모든 속성이 정의되어야 개체와 관계가 완성되므로,
개념적 설계 단계에서 가능한 모든 속성 식별
④ 개체 및 관계를 식별할 때 함께 식별된 주요 속성의 이름이 요구 분석 명세서를 기준으로 부여되었으므로
필요한 경우 속성 이름 변경
유의 사항2
① 모든 개체는 반드시 하나 이상의 식별자를 포함해야 함
② 식별자는 반드시 유일한 값을 가져야 함
③ 식별자는 개체가 존재하는 동안 값이 변경되지 않아야 함
④ 식별자 역할을 할 속성이 둘 이상인 경우, 개체의 특성을 대표할 수 있는 속성을
기본키(주 식별자)로 결정
[ 속성 표현 방법 ]
피터첸 표기법
- 각 속성은 타원형으로 표현하고 개체나 관계와 실선으로 연결하며,
- 일반적으로 기본키 속성은 맨 앞에 표시함
IE 표기법
- 개체를 표현하는 사각형 내부에 기본키 속성과 설명자(일반 속성)를 구분해서 표현함
[ 속성 이름 ]
속성 이름 결정 시 유의 사항
① 한 개체 또는 관계 안에서는 유일한 이름을 부여해야 하고, 소속된 개체나 관계가 다르면
동일한 이름을 부여할 수 있음
② 유지보수 시에 불편하므로 되도록 속성 이름 앞에 개체 이름이 포함되지 않게 함
예) 직원 개체의 경우 : 직원이름 > 이름, 직원_급여 > 급여
③ 현업에서 익숙한 표준 용어 사용
④ 약어보다는 전체 이름 사용
⑤ 속성의 성격이 분명히 인식될 수 있도록 구체적으로 부여
예) 2개의 서로 다른 개체가 ‘가격’ 속성을 갖는 경우
정확히 같은 의미가 아니라면 ‘구매가격’, ‘판매가격’으로 구분해서 표현
⑥ 일관성을 위해 미리 이름 부여 규칙을 정해두는 것이 좋음
예) 단어와 단어는 ‘_’으로 연결한다는 규칙을 정했다면 > ‘제품_코드’, ‘분류_코드’
⑦ DB 구축 프로젝트와 관련된 용어 사전을 만들어서 참조하는 것이 좋음
[ 트랜잭션 개념 ]
트랜잭션(transaction)이란
- DB에서 하나의 논리적 기능을 수행하기 위한 작업의 기본 단위
- 데이터의 일관성을 보장하기 위해 서로 밀접하게 관련되어 분리할 수 없는 하나 이상의 데이터 조작 명령문으로 구성됨
- DB의 일관성과 무결성이 유지되는 상태에서 요청된 작업을 완수하기 위한 하나의 논리적 작업 단위
예) 은행 고객 A가 B의 계좌로 10만원을 이체하는 트랜잭션
- A의 계좌에서 10만 원을 감소시키는 명령문 + B의 계좌에 10만 원을 증가시키는 명령문
> 두 명령문이 모두 성공해야 이체 트랜잭션이 완성됨
> 어느 하나라도 실패하면 실제로 DB에는 이체 정보가 반영되지 않음
[ 트랜잭션 모델링의 주요 업무 ]
트랜잭션 모델링의 주요 업무는?
- 트랜잭션 요구분석 명세서를 기초로 하여 업무 단위별로 유형별 트랜잭션 명세서를 작성하고,
요구 분석 내용 가운데 ER 다이어그램이나 트랜잭션 명세서에 표현하기 어려운 운영상의 제약사항도 정의하는 것
트랜잭션 모델링의 필요성
- 주요 트랜잭션을 선정하여 기능적 특성을 DB 설계 초기에 파악함으로써 추후 구현 단계에서
트랜잭션을 처리하는 응용 프로그램을 작성하기 위한 기초 자료를 제공함
- 개념적 스키마 모델링에서는 표현하기 어려운 운영상의 제약사항을 정의하는 일이 중요함
- 트랜잭션에 필요한 모든 정보가 개념적 스키마에 포함되어 있는지 확인 가능
[ 트랜잭션 명세서 및 제약사항 작성 방법 ]
트랜잭션 명세서 작성 방법
- DB 설계에 반영해야 하는 주요 트랜잭션을 식별한 다음, 각 트랜잭션의 내부적인 제어 흐름을
파악해서 트랜잭션의 유형을 구분하고, 입력 및 출력 데이터를 작성함
- 트랜잭션의 상대적 중요도(상중하), 예상 실행 빈도수 등 추가 가능
트랜잭션 유형 구분
① 읽기 트랜잭션: 데이터를 수정하지 않고 검색(retrieval)하는 작업
② 쓰기 트랜잭션: 데이터를 삽입(insert)/삭제(delete)/갱신(update)해서 데이터를 수정하는 작업
③ 혼합 트랜잭션: 데이터 읽기와 쓰기가 모두 포함된 작업
제약사항이란?
- 요구 분석 내용 가운데 ER 다이어그램이나 트랜잭션 명세서에 표현하기 어려운 운영상의 제약사항
- 속성이 갖는 값에 대한 제약조건은 해당되지 않음
제약사항 정의 시 유의 사항
- 트랜잭션 명세서와 마찬가지로 추후 응용 프로그램을 작성할 때 중요한 역할을 하므로 가능하면 빠짐없이 작성
- 운영상의 제약사항이 ERD에 간접적으로 표현되는 경우가 많으므로 각 제약사항이 ERD에 표현되었는지 잘 파악해서 작성
> ERD에 함축된 것은 운영상의 제약사항 목록에 명시할 필요 없음
'대우개발원 수업 내용 > Database (sql)' 카테고리의 다른 글
| Database 11일차 (0) | 2026.02.05 |
|---|---|
| Database 10일차 (0) | 2026.02.04 |
| Datebase 8일차 (1) | 2026.01.30 |
| Database 7일차 (0) | 2026.01.29 |
| Database 6일차 (0) | 2026.01.28 |