정규화는 데이터의 중복 방지, 무결성을 충족하기 위해 데이터베이스를 설계하는 방법으로 1972년 영국의 컴퓨터 과학자인 Edgar F. Codd가 처음으로 제안하였다.

1. 정규화의 목표 및 이유

: 정규화의 기본 목표는 '테이블 간의 중복된 데이터를 허용하지 않는다는 것이다.' 이는 중복된 데이터를 허용하지 않음으로써, 무결성을 유지할 수 있으며 DB의 저장 용량을 줄일 수 있다.

데이터를 중복으로 저장하면, 일관되지 않은 데이터, 비정상적인 삽입, 갱신, 삭제처리, 디스크 공간의 낭비 등 많은 문제를 일으킨다. 정규화는 중복 데이터를 저장하면서 발생시키는 문제점을 없애기 위해, 정보를 주제별로 분할하는 프로세스라 할 수 있다.

2. 정규화의 효과 및 장점

• 정규화를 통해 각 테이블의 개념들이 좀 더 세분화됨에 따라 해당 개념에 대한 재활용 가능성이 높아진다.
• 정규화는 식별자가 아닌 속성이 한번만 표현됨에 따라 중복이 최소화된다. 이에 따라 데이터 품질이 확보되고 저장공간이 절약되며, 데이터 조작언어(DML) 처리시 성능이 향상된다.

3. 정규화의 단점

• 릴레이션의 분해로 인해 릴레이션 간 연산이 많이져 응답시간이 오히려 느려질 수 있다.
• 정규화의 단점을 국복하기 위해 "반정규화"를 통해 성능을 향상시키는 방법이 있다.

4. 정규화 단계

제 1 정규화

: 테이블 칼럼이 '원자 값'을 갖도록 테이블을 분해하는 것. -> 원자 값은 하나의 값을 의미하며 속성 값이 더 이상 분해될 수 없는 값을 의미한다.

제 2 정규화

: 제 1 정규화를 진행한 테이블에 대해 '완전 함수 종속'을 만족하도록 테이블을 분해하는 것. -> 완전 함수 종속은 기본키의 부분 집합이 결정자가 되어선 안된다는 것을 의미한다. -> 완전 함수 종속을 충족시키기 위한 조건이 있다. (복합키로 구성된 칼럼을 분해한다던지, 부분 함수 종속을 파악해 분해한다던지)

제 3 정규화

: 제 2 정규화를 진행한 테이블에 대해 '이행적 함수 종속'을 없애도록 테이블을 분리하는 것. -> 이행적 함수 종속이란? A -> B, B -> C가 성립할 때, A -> C가 성립되는 것을 의미한다.

정규화 단계의 예시 1

다음의 예시를 통해 정규화가 어떻게 진행되는지 알 수 있다.

제 1 정규화

제1 정규화란 테이블의 컬럼이 원자값(Atomic Value, 하나의 값)을 갖도록 테이블을 분해하는 것이다.

정규화 필요 예시 1을 보면 두개의 회사가 부서번호를 통해 식별되고 있다. 하지만 이용가능요일을 보게되면 여러 개의 데이터가 들어가 있음을 확인할 수 있다.

이에 테이블의 컬럼이 원자값을 갖는다는 말은, 이용가능한요일이라는 컬럼에 값이 하나씩만 들어가도록 조정해야 한다!

제 2 정규화

제2 정규화란 제1 정규화를 진행한 테이블에 대해 완전 함수 종속을 만족하도록 테이블을 분해하는 것이다.

완전 함수 종속?, 부분 함수 종속? 이행적 함수 종속? 이런 개념들은 제 2 정규화를 진행하기 전 빠르게 알아가자!

함수 종속성

어떤 테이블 A와 B에 대하여, A값에 의해 B 값이 유일하게 정해지는 관계를 말한다.

이때, A를 결정자라고 하고, B를 종속자라고한다.

Ex) 함수종속성의 결정자와 종속자 예시.

함수종속성 종류.

< 완전 함수 종속을 충족한 테이블의 예시 >

프로그램 번호를 기본키로 구성된 헬스케어 프로그램의 구성이다. 다양한 프로그램이 있지만, 프로그램 번호를 알면 프로그램의 코스와 프로그램명, 프로그램 설명의 정보를 명확하게 알 수 있다. 즉, 프로그램번호는 결정자이고, 프로그램 코스, 프로그램 명, 프로그램 설명은 프로그램 번호에 함수적 종속성이 있다고 할 수 있다.

< 다양한 부분 함수 종속을 가진 테이블의 예시 >

예약번호를 기본키로 구성된 예약 테이블이다. 예약번호를 통해 언제, 몇시에, 누가, 어떤 코스를, 몇분동안, 결제는 했는지? 등 다양한 정보를 담고 있다. 이는 예약번호를 통해서도 알 수 있는 정보이면서도 기본키가 아닌 다른 속성에 종속되기 때문에 부분 함수 종속을 띄고 있다고 할 수 있다. 각각의 부분함수 종속을 충족하는 조건은 다음과 같다.

1. 회원번호는 결정자이고, 회원정보들과 함수적 종속성을 가진다.
2. 프로그램 번호는 종속자이고, 프로그램정보들과 함수적 종속성을 가진다.
3. 프로그램 옵션번호는 종속자이고, 프로그램 시간, 가격과 함수적 종속성을 가진다.
4. 결제번호는 종속자이고, 결제수단과 결제상태와 함수적 종속성을 가진다.

위와 같은 테이블의 완전 함수 종속을 만족시키기 위해 제 2 정규화를 진행하면 다음과 같은 결과를 얻을 수 있다.

제 2 정규화의 핵심인 완전 함수 종속을 충족시키기 위해선, 부분 함수 종속을 제거해야 한다!

제 3 정규화

제 3 정규화란 제 2 정규화를 진행한 테이블에 대해 ‘이행적 함수 종속’을 없애도록 테이블을 분해하는 것이다.

이행적 함수 종속이란? : 테이블 내의 기본키(PK)가 아닌 일반 칼럼으로 종속되는 칼럼들을 분리한다.

앞서 설명한 예약 테이블을 기준으로 제 3 정규화를 진행하면 다음과 같다.

오늘은 여기까지...

수정이 이뤄진다면 좀 더 보완하겠다!

개념적 설계에서 논리적 설계로 넘어가기 위해 기본키(Primary Key)와 외래키(Foreign Key)를 이해하고, 이를 식별관계, 비식별 관계로 연결지어 보자.

1. 식별자 분류

1) 식별자 분류 식별자의 종류는 자신의 개체(Entity) 내에서 대표성을 가지는가에 따라 주식별자(Primary Identifier)와 보조식별자(Alternate Identifier)로 구분하고 엔터티 내에서 스스로 생성되었는지 여부에 따라 내부식별자와 외부식별자(Foreign Identifier)로 구분할 수 있다.

또한 단일 속성으로 식별이 되는가에 따라 단일식별자(Single Identifier)와 복합식별자(Composit Identifier)로 구분할 수 있다. 원래 업무적으로 의미가 있던 식별자 속성을 대체하여 일련번호와 같이 새롭게 만든 식별자를 구분하기 위해 본질식별자와 인조식별자로도 구분할 수 있다.

예시) 엔티티 내 다양한 식별자 도출

2) 주 식별자 도출기준 데이터 모델링 작업에서 중요한 작업 중의 하나가 주식별자 도출작업이다. 주식별자를 도출하기 위한 기준을 정리하면 다음과 같다.

• 해당 업무에서 자주 이용되는 속성을 주식별자로 지정한다.
• 명칭, 내역 등과 같이 이름으로 기술되는 것들은 가능하면 주식별자로 지정하지 않는다.
• 복합으로 주식별자로 구성할 경우 너무 많은 속성이 포함되지 않도록 한다.

2-1) 해당 업무에서 자주 이용되는 속성을 주식별자로 지정하도록 한다. 예를 들면, 직원이라는 엔티티가 있을 때 유일하게 식별가능한 속성으로는 주민등록번호와 사원번호가 존재할 수 있다. 사원번호가 그 회사에서 직원을 관리할 때 흔히 사용되므로 사원번호를 주식별자로 지정하고 주민등록번호는 보조식별자로 사용할 수 있다.

• 사원번호, 회원번호, 게시글번호, 결제번호, 프로그램번호 등 엔티티 내 유일하게 식별가능한 속성을 주식별자로 선택한다.

2-2) 명칭, 내역 등과 같이 이름으로 기술되는 것들은 가능하면 주식별자로 지정하지 않도록 한다. 예를 들어, 한 회사에 부서이름이 100개가 있다고 할 때, 각각의 부서이름은 유일하게 구별될 수 있다고 하여 부서이름을 주식별자로 지정하지 않도록 해야 한다. 만약 부서이름을 주식별자로 선정하면 물리데이터베이스로 테이블을 생성하여 데이터를 읽을 때 항상 부서이름이 WHERE 조건절에 기술되는 현상이 발생된다. 부서이름은 많은 경우 20자 이상이 될 수 있으므로 조건절에 정확한 부서이름을 기술하기는 쉬운 일이 아니다. 이와 같이 명칭이나 내역이 있고 인스턴스들을 식별할 수 있는 다른 구분자가 존재하지 않을 경우는 새로운 식별자를 생성하도록 한다. 보통 일련번호와 코드를 많이 사용한다.

• 부서명을 부서번호로, 프로그램명을 프로그램번호를 새로운 식별자로 만들어 주식별자로 사용한다.

2-3) 주식별자로 선정하기 위한 속성이 복합으로 구성되어 주식별자가 될 수 있을 때 가능하면 주식별자 선정하기 위한 속성의 수가 많지 않도록 해야 한다. 그러나 만약 주식별자로 선정된 속성들이 자신이 가지고 있는 자식엔터티로부터 손자엔터티, 그리고 증손자엔터티까지 계속해서 상속이 되는 속성이고 복잡한 데이터 모델이 구현되어 물리데이터베이스에서 조인으로 인한 성능저하가 예상되는 모습을 가지고 있다면 속성의 반정규화 측면에서 하나의 테이블에 많은 속성이 있는 것이 인정될 수도 있다. 하지만 일반적으로 주식별자의 속성의 개수가 많다는 것(일반적으로 7~8개 이상)은 새로운 인조식별자(Artificial Identifier)를 생성하여 데이터 모델을 구성하는 것이 데이터 모델을 한층 더 단순하게 하고 애플리케이션을 개발할 때 조건절을 단순하게 할 수 있는 방법이 될 수 있다.

• "접수" 엔티티의 접수일자, 관할부서, 입력자사번, 접수방법, 신청인, 신청인 연락처 등 주식별자가 넘쳐난다면, "접수 번호"의 인조식별자를 통해 주식별자 속성을 단순화 한다.

2. 식별자관계와 비식별자 관계

외부식별자(Foreign Identifier)는 자기 자신의 엔터티에서 필요한 속성이 아니라 다른 엔터티와의 관계를 통해 자식 쪽에 엔터티에 생성되는 속성을 외부식별자라 하며 데이터베이스 생성 시에 Foreign Key 역할을 한다.

관계와 속성을 정의하고 주식별자를 정의하면 논리적인 관계에 의해 자연스럽게 외부식별자가 도출되지만 중요하게 고려해야 할 사항이 있다.

엔터티에 주식별자가 지정되고 엔터티간 관계를 연결하면 부모쪽의 주식별자를 자식엔터티의 속성으로 내려 보낸다. 이 때 자식엔터티에서 부모엔터티로부터 받은 외부식별자를 자신의 주식별자로 이용할 것인지 또는 부모와 연결이 되는 속성으로서만 이용할 것인지를 결정해야 한다.

1) 식별자 관계

부모로부터 받은 식별자를 자식엔터티의 주식별자로 이용하는 경우는 Null값이 오면 안되므로 반드시 부모엔터티가 생성되어야 자기 자신의 엔터티가 생성되는 경우이다. 부모로부터 받은 속성을 자식엔터티가 모두 사용하고 그것만으로 주식별자로 사용한다면 부모엔터티와 자식엔터티의 관계는 1:1의 관계가 될 것이고, 만약 부모로부터 받은 속성을 포함하여 다른 부모엔터티에서 받은 속성을 포함하거나 스스로 가지고 있는 속성과 함께 주식별자로 구성되는 경우는 1:M 관계가 된다.

2) 비식별자 관계

부모엔터티로부터 속성을 받았지만 자식엔터티의 주식별자로 사용하지 않고 일반적인 속성으로만 사용하는 경우가 있다. 이과 같은 경우를 비식별자 관계(Non-Identifying Relationship)라고 하며 다음의 네 가지 경우에 비식별자 관계에 의한 외부속성을 생성한다.

1) 자식엔터티에서 받은 속성이 반드시 필수가 아니어도 무방하기 때문에 부모 없는 자식이 생성될 수 있는 경우이다. 2) 엔터티별로 데이터의 생명주기(Life Cycle)를 다르게 관리할 경우이다. 예를 들어 부모엔터티에 인스턴스가 자식의 엔터티와 관계를 가지고 있었지만 자식만 남겨두고 먼저 소멸될 수 있는 경우가 이에 해당된다. 이에 대한 방안으로 물리데이터베이스 생성 시 Foreign Key를 연결하지 않는 임시적인 방법을 사용하기도 하지만 데이터 모델상에서 관계를 비식별자관계로 조정하는 것이 가장 좋은 방법이다. 3) 여러 개의 엔터티가 하나의 엔터티로 통합되어 표현되었는데 각각의 엔터티가 별도의 관계를 가질 때이며 이에 해당된다.

3. 개념적 설계를 바탕으로 식별, 비식별관계 만들기.

(1:1) 관계: 부모는 하나의 자식이 있다. (1:N) 관계: 부모는 하나 이상의 자식 있다. (N:M) 관계: 하나 이상의 부모와 하나 이상의 자식이 있다. (1:1O) 관계: 부모는 하나의 자식이 있을수도, 없을수도 있다. (1:NO) 관계: 부모는 여러개의 자식이 있을수도, 없을수도 있다.

식별자 관계

• 부모의 주식별자가 자식의 주식별자가 되는 경우를 "식별자 관계"라고 한다.
• 부모 테이블의 기본키(PK)가 자식 테이블의 외래키(FK)이면서, 기본키(PK)로 사용되는 관계.

Ex) 카드결제는 카드가 있어야 생기는 엔터티이다. 이런경우를 부모관계라고 표현한다. 여기서, 카드 엔터티의 카드번호 주식별자(기본 키)를 결제 엔터티의 주식별자(기본 키)로 지정했다. FK는 Foreign Key로 외래키라는 뜻이다. 다른 엔터티의 기본 키를 참조한 키라고 해석하면된다. 이런경우를 식별자 관계라고 한다.

비식별자 관계

• 부모의 주식별자가 자식의 주식별자가 되지 않고 그냥 속성으로 사용하는 경우 비식별자 관계라고 한다.
• 자식테이블에서 참조된 외래키(FK)가 기본키가 아닌 일반 컬럼으로 참조되는 관계

• 부모 테이블의 기본키(PK)가 자식 테이블의 외래키(FK)로만 사용되는 관계

• 자식 테이블의 행(row)를 추가할 때 부모 테이블의 참조행(row)가 없어도, 자식 테이블의 행(row)를 추가할 수 있다.

• 부모 테이블에 데이터가 없어도, 자식 테이블에 데이터를 추가 할 수 있다.

Ex) 카드AS는 카드가 있어야 생기는 엔터티이다. 하지만 식별관계처럼 카드번호를 기본키로 사용하지 않고, 카드AS번호를 기본 키로 사용한다. 부모 엔터티 주식별자(카드번호)를 그냥 속성으로만 사용하였다. 이런 경우를 비식별자 관계라고 한다.

4. 주의점

• 테이블 설계 시 "비식별 관계로 테이블을 설계하는 것"을 권장한다.
• 식별 관계를 사용할 경우 데이터의 정합성을 보장하지만 비즈니스 로직이 변경되면 테이블 관리가 힘들어진다. 정합성 : 데이터 들의 값이 서로 일치함
• 비식별관계를 이용할 경우 정합성을 유지하기 위해 별도의 비즈니스 로직이 필요하다.
• 비식별 관계는 데이터 무결성을 보장하지 않는다. 무결성 : 데이터 값이 정확한 상태

출처: https://dataonair.or.kr/db-tech-reference/d-guide/sql/?pageid=5&mod=document&uid=329

https://inpa.tistory.com/entry/DB-%F0%9F%93%9A-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%AA%A8%EB%8D%B8%EB%A7%81-1N-%EA%B4%80%EA%B3%84-%F0%9F%93%88-ERD-%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8

개체와 속성을 추출하고, 관계까지 추출했다면, 이제 "ERD"로 작성해보자!

1. ERD (Entity Relationship Diagram)란?

ERD는 데이터베이스 구조를 한 눈에 알아보기 위해 그려놓는 다이어그램이다.

ERD는 단어에서 의미하는 그대로 'Entity =개체' 와 'Relationship =관계'를 중점적으로 표시하는 다이어그램으로 구체화 하는 것을 말한다.

2. ERD 표기법

1) 개체 (Entity)

• 개체란 단독으로 존재하는 객체를 의미하며, 동일한 객체는 존재하지 않는다.
• ERD에서는 개체를 "사각형"으로 표기한다.

• 데이터베이스를 설계할 때, '테이블'이 Entity로 정의될 수 있다. 예시) ERD로 표현한 개체

2) 속성 (Attribute)

• 속성은 개체가 가지고 있는 속성을 의미한다.
• ERD에서는 속성을 "원"으로 표기한다.
• 속성 중 "기본키"는 속성에 밑줄을 그어 표기한다. 예시) ERD로 표현한 속성

3) 관계 (Relationship)

• 관계는 개체 간의 관계를 의미한다.
• ERD에선 개체를 서로 이으며 어떤 관계를 가지는지 "마름모"로 표기한다.

예시) ERD로 표현한 관계

4) 관계성 그리기 - 까치발표기법

• 추출된 관계를 ERD로 표기하기 위해 까치발 표기법을 많이 사용한다.
• 까치발 표기법을 통해 개체(Entity)간 관계성을 표시할 수 있다.

예시) ERD로 표현한 관계성

1. 학생은 교과목을 수강한다.
2. 결제 시 쿠폰을 사용할 수도, 사용 안 할 후도 있다.
3. 하나의 부서에 여러 명의 사원이 소속된다.
4. 회원은 게시글을 작성할 수도, 작성 안 할 수도 있다. (게시글은 회원이 작성함으로써 '생성'되고, 한 명의 회원은 여러 개의 게시글을 작성할 수 있다.)

3. 개념적 설계

위와 같이 개체와 속성을 추출하고, 관계를 설정한다음 관계성까지 표현한다면 개념적 설계가 마무리 된다.

4. 마무리

끝.

관계는 엔티티끼리 상호 연관성이 있는 상태를 의미한다.

• 관계는 데이터 모델 내에 존재하는 엔티티 간 논리적인 연관성을 의미한다. 관계는 "부서"엔티티와 "사원"엔티티의 관계와 같이 "존재에 의한 관계" 가 있고,

• *"고객"엔티티와 **"주문"엔티티의 관계와 같이 "행위에 의한 관계" 가 있다.

  1. 관계의 정의

  관계를 사전적으로 정의하면 상호 연광성이 있는 상태로 말할 수 있다. 이것을 데이터 모델에 대입하여 정의하면 "엔티티 인스턴스사이의 논리적인 연관성으로서 존재의 형태로서나 행위로서 서로에게 연관성이 부여된 상태"라고 할 수 있다. 관계는 엔티티와 엔티티 간 연관성을 표현하기 때문에 엔티티의 정의에 따라 영향을 받기도 하고, 속성 및 정의 및 관계 정의에 따라서도 다양하게 변할 수 있다.

2. 관계의 페어링

관계의 페어링은 엔티티 안에 인스턴스가 개별적으로 관계를 가지는 것이고 이것의 집합을 관계로 표현한다는 것이다.

3. 관계의 표기법

4. 관계차수

1) 일대일 관계 (1:1)

1:1 관계란 어느 엔티티쪽에서 상대 엔티티를 보더라도, ** 반드시 단 하나씩 관계를 가지는 것** 을 말한다.

하나의 부모 엔티티에 연결된 자식 엔티티는 하나밖에 올 수 없는 관계

Ex) 사원번호 - 주민번호

• 사원번호, 주민등록번호는 모두 고유한 사원을 가리킨다.

• 사원번호 하나엔 하나의 주민등록번호만 대응될 수 있다.

  Ex) 전화번호 - 유저

• 각 전화번호가 단 한 명의 유저와 연결되어 있고, 그 반대도 동일하다면 1:1 관계이다.

  Ex) 남자 - 여자 예를 들어, 우리나라에서 결혼 제도는 일부일처제로, 한 남자는 한 여자와, 한 여자는 한 남자와 밖에 결혼을 할 수 없다.

• 남편 또는 부인을 2명 이상 둘 수 없는데, 이러한 관계가 1:1 관계다.

2) 일대다 관계 (1:N)

1:N 관계란 한쪽 엔티티가 관계를 맺은 엔티티 쪽에 여러 객체를가질 수 있는 것을 의미한다. 1:N 관계는 매우 흔한 방식으로, DB를 설계할 때 자주 쓰인다.

하나의 부모 엔티티에 연결된 자식 엔티티가 여러 개가 될 수 있는관계

Ex) 부모 - 자식

• 부모는 자식을 1명만 낳을수도 있고, 2명, 3명, 4명, 10명 그 이상도 낳을 수 있다.
• 여러 명의 자식(N)의 입장에서 한 쌍의 부모(1)중 어떤 부모에 속해 있는지 표현해야하므로 부모 테이블의 PK를 자식 테이블에 FK로 집어 넣어 관계를 표현한다.

• PK(Primary Key) : 각 엔티티를 식별할 수 있는 대표키, 테이블에서 중복되지 않는(Unique) 값, Null일 수 없다.

• FK(Foreign Key) : 다른 테이블의 기본키를 참조, 모든 필드는 참조하는 기본키와 동일한 도메인(값의 종류&범위)을 갖는다. 모든 필드 값은 참조하는 기본키와 동일하거나 null 일 수 있다. 즉, 부모 테이블(1)에서는 내 자식들이 누구인지 정보를 넣을 필요가 없고, 자식 테이블(N)에서만 각각의 자식들이 자신의 부모 정보(FK)를 넣음 으로써 관계를 표현할 수 있다.

Ex) 부서 - 사원

• 부서에 여러 사원이 속한다. 사원은 여러 부서를 가질 수 없다.

  Ex) 회원 - 게시글

  • 회원은 게시글을 여러 개 작성할 수 있고, 게시글 하나는 한 명의 회원만 작성할 수 있다.

  Ex) 상품 - 제조업체

  • 각 상품은 한 제조업체가 공급하고, 제조업체 하나는 여러 상품을 공급한다.

  3) 다대다 관계 (N:M)

  N:M 관계는 관계를 가진 양쪽 엔티티 모두에서 1:N 관계를 가지는 것을 말한다. 즉, 서로가 1:N 관계로 보고 있는 것이다.

  하나의 부모 엔티티와 연결된 자식 엔티티가 여러 개가 될 수 있고 여러 개의 부모 엔티티와 연결된 자식 엔티티가 하나가 될 수 있는 관계

  Ex) 사원 - 업무

  • 한명의 사원이 A업무, B업무를 동시에 할 수도 있고, A업무를 여러 사원이 같이 할 수도 있다.

Ex) 여행상품 - 고객

• 고객 한 명은 여러 개의 여행상품을 구매할 수 있고, 여행 상품 하나가 여러 개의 고객을 가질 수 있다.

  Ex) 회원 - 상품

• 한 회원은 쇼핑몰의 여러 상품들을 가질 수 있다. 판매중인 상의, 하의, 모자, 신발 등

• 반대로 한 티셔츠도 여러 회원들이 가질 수 있다. 내가 구매한 상의, 엄마가 구매한 상의, 친구가 구매한 하의 등

  다대다 관계 (N:M)은 두개의 엔티티만으로는 표현할 수 없고, 두 엔티티의 관련성을 표현하기 위해 중간에 또 다른 엔티티를 필요로 한다.

데이터 모델링에서 M:N관계는 완성되지 않는 모델로 간주되어 M:N관계를 1:N 관계로 전환시켜주는 작업을 필요로 한다.

: N:M 관계는 관계(Relation)로 변환하라.

Ex) 회원 - 상품

• 한 회원은 쇼핑몰의 여러 상품들을 가질 수 있다. 판매중인 상의, 하의, 모자, 신발 등
  • 반대로 한 티셔츠도 여러 회원들이 가질 수 있다. 내가 구매한 상의, 엄마가 구매한 상의, 친구가 구매한 하의 등

    -> 주문(주문번호(PK), 회원번호(FK), 상품번호(FK), 주문수량)

5. 관계선택사양

관계선택사양(Optionality)는 관계차수로 연결된 엔티티간 필수적인 관계인지, 선택적인 관계인지를 정의하는 중요한 단계이다.

마무리

관계(Relation)

: 개체 간 의미 있는 연관성

• 요구사항 문장에서 개체 간의 연관성을 의미 있게 표현한 동사를 찾아라!
• 찾아낸 관계에 대해 매핑 카디널리티와 참여특성을 결정하라!

• 매핑 카디널리티: 일대일(1:1), 일대다(1,N), 다대다(N:M)

• 참여특성: 필수적 참여 / 선택적 참여

• 필수적 참여: 개체가 반드시 참여해야 하는것을 의미.

   Ex – 학생 개체가 수업개체와의 수강 관계에 필수적 참여

• 선택적 참여: 개체중 일부만 관계에 참여해도 되는 것을 의미.

   Ex – 도서 개체가 고객 개체와의 구매 관계에 선택적으로 참여 

속성의 사전적 의미는, 어떤 사물의 성질이나 특징, 그것이 없다면 실체를 생각 또는 표현할 수 없는 것으로 정의할 수 있다.

데이터 모델의 관점에서 속성은, 인스턴스로 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위로 정의할 수 있다.

예시 1) 사원

사원정보를 관리하고자 사원엔티티를 추출했을때, 사원의 정보를 하나씩 쪼갠것이 '속성'이라 할 수 있다.

추가로 쇼핑몰을 예시로 들어보자. A라는 회원이 가입을 했다면, 우리는 아이디, 이름, 연락처, 주소, 결제수단 등의 정보를 가진 회원 DB를 갖게 된다. 이때 고객의 정보를 담는 그릇 “고객”이라는 개체 집합이 생기고, 이름, 전화번호, 주소, 고객ID와 같은 정보는 개체의 속성이 된다. 그 외에도 “상품”, “장바구니”, "배송" 등의 개체를 가질 수 있겠다.

2. 속성의 종류

속성의 종류는 다음과 같다.

(1) 더 작은 단위로 나눌 수 있나? — 단순속성 vs 복합속성

예를 들어 고객 가입 일시와 같은 속성은 년/월/일로 더 작게 쪼갤 수 있으므로 복합속성이다. 반면 나이와 같은 속성은 숫자를 쪼개면 의미가 없어지므로 쪼갤 수 없는 단순속성이다.

(2) 값을 더 가질 수 있나? — 단일값 vs 다중값

하나의 개체에 한 개 값만 가질 수 있을 경우 단일값이라고 한다. 고객 ID와 같은 속성은 한 개체의 고유한 성질이므로 단일값으로 지정해야한다. 반면 고객 전화 번호는 핸드폰 번호, 집 전화번호, 회사 번호와 같이 여러 개 값을 받을 수 있기 때문에 다중값이다. -> 추가적으로, 고객 ID는 개체를 구분하는 유일한 값으로, 키 속성이라고도 한다. 키 속성은 ERD를 그릴 때 밑줄을 그어 표시한다.

(3) 다른 정보로 유추할 수 있나? — 저장속성 vs 유도속성

회원 가입할 때 첫 페이지에 오만떼만 정보를 다 입력하라고 한다면? 귀찮은 생각에 뒤로가기를 먼저 누르게 될 것이다. 그만큼 필수적인 정보만을 받아서 간결히 유지하는 것이 중요한대, 이렇게 필수적인 것을 저장속성이라고 한다. 유도속성은 저장속성으로 부터 유추할 수 있는 정보로, 생년월일이란 저장속성을 통해 유추할 수 있는 ‘나이’가 유도속성이다.

3. 속성의 특징

• 엔터티와 마찬가지로 반드시 비즈니스에서 필요로 하고 IT시스템에서 저장 및 관리하고자 하는 정보여야 한다. Ex) 회원개체의 아이디, 비밀번호, 이름 등의 속성

• 정규화 이론에 따라 속성이 속해 있는 엔티티의 주식별자에 함수적 종속성을 가져야 한다. Ex) 예약개체의 식별자인 예약번호는 예약일과 예약시간을 나타낸다.

• 하나의 속성에는 1개의 값만 가진다. 하나의 속성에 여러 개의 값이 있는 다중 값일 경우 별도의 엔터티를 이용하여 분리한다. Ex) 회원개체에서 회원아이디와 이름은 각각 하나씩이다.

끝.

개체 (Entity, 엔티티or엔터티)

• 엔티티는 우리말로실체, 객체라고 번역하기도 하는데 실무적으로는 엔터티보단 엔티티라 많이 부른다.

  • 엔티티는 사람, 장소, 물건, 사건, 개념 등의 명사에 해당한다.
  • 엔티티는 업무상 관리가 필요한 관심사에 해당한다.
  • 엔티티는 저장이 되기 위한 어떤 것(Thing)이다.

1. 개체(Entity) - 엔티티란?

“업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것(Thing)"으로 설명할 수 있다. 또는, 엔터티는 업무 활동상 지속적인 관심을 가지고 있어야 하는 대상으로서 그 대상들 간에 동질성을 지닌 인스턴스들이나 그들이 행하는 행위의 집합으로 정의할 수 있다.

엔티티는 그 집합에 속하는 개체들의 특성을 설명할 수 있는 속성(Attribute)을 갖는데, 예를 들어 ‘학생’이라는 엔티티는 학번, 이름, 이수학점, 등록일자, 생일, 주소, 전화번호, 전공 등의 속성으로 특징지어질 수 있다. 이러한 속성 가운데에는 엔터티 인스턴스 전체가 공유할 수 있는 공통 속성도 있고, 엔터티 인스턴스 중 일부에만 해당하는 개별 속성도 있을 수 있다.

또한 엔티티는 인스턴스의 집합이라고 말할 수 있고, 반대로 인스턴스라는 것은 엔터티의 하나의 값에 해당한다고 정의할 수 있다. 예를 들어 과목은 수학, 영어, 국어가 존재할 수 있는데 수학, 영어, 국어는 각각이 과목이라는 엔터티의 인스턴스들이라고 할 수 있다.

또한 사건이라는 엔터티에는 사건번호2010-001, 2010-002 등의 사건이 인스턴스가 될 수 있다. 엔터티를 이해할 때 눈에 보이는(Tangible)한 것만 엔터티로 생각해서는 안되며 눈에 보이지 않는 개념 등에 대해서도 엔터티로서 인식을 할 수 있어야 한다.

실제 업무상에는 눈에 보이지 않는 것(Thing)이 엔터티로 도출되는 경우가 많기 때문에 더더욱 주의할 필요가 있다.

엔티티를 표현하는 방법은 각각의 표기법에 따라 조금씩 차이는 있지만 대부분 사각형으로 표현된다. 다만 이 안에 표현되는 속성의 표현방법이 조금씩 다를 뿐이다. 엔터티와 엔터티간의 ERD를 구현하면 다음과 같다.

1) 엔티티의 특징

엔터티는 다음과 같은 특징을 가지고 있으며 만약 도출된 엔터티가 다음의 성질을 만족하지 못하면 적절하지 않은 엔터티일 확률이 높다.

• 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다.(예. 환자, 토익의 응시횟수, …)
  예를 들어 환자라는 엔터티는 의료시스템을 개발하는 병원에서는 반드시 필요한 엔터티이지만 일반회사에서 직원들이 병에 걸려 업무에 지장을 준다하더라도 이 정보를 그 회사의 정보로서 활용하지는 않을 것이다. 즉 시스템 구축 대상인 해당업무에서 그 엔터티를 필요로 하는가를 판단하는 것이 중요하다.

• 두 번째는 식별자(Unique Identifier)에 의해 식별이 가능해야 한다는 점이다.

유일한 식별자는 그 엔터티의 인스턴스만의 고유한 이름이다. 두 개 이상의 엔터티를 대변하면 그 식별자는 잘못 설계된 것이다. 예를 들어 직원을 구분할 수 있는 방법은 이름이나 사원번호가 될 수가 있다. 그러나 이름은 동명이인(同名異人)이 될 수 있으므로 유일하게 식별될 수 없다. 사원번호는 회사에 입사한 사람에게 고유하게 부여된 번호이므로 유일한 식별자가 될 수 있는 것이다.

• 세 번째는 영속적으로 존재하는 인스턴스의 집합이 되어야 한다는 점이다.

엔터티의 특징 중 “한 개”가 아니라 “두 개 이상”이라는 집합개념은 매우 중요한 개념이다. 두 개 이상이라는 개념은 엔터티뿐만 아니라 엔터티간의 관계, 프로세스와의 관계 등 업무를 분석하고 설계하는 동안 설계자가 모든 업무에 대입해보고 검증해?러 개의 인스턴스를 포함한다.

• 네 번째는 업무프로세스(Business Process)가 그 엔터티를 반드시 이용해야 한다는 점이다.

업무프로세스에 의해 전혀 이용되지 않는다면 업무 분석이 정확하게 안되어 엔터티가 잘못 선정되거나 업무프로세스 도출이 적절하게 이루어지지 않았음을 의미한다.

• 다섯 번째는 엔터티에는 반드시 속성(Attributes)이 포함되어야 한다는 점이다.

속성을 포함하지 않고 엔터티의 이름만 가지고 있는 경우는 관계가 생략되어 있거나 업무 분석이 미진하여 속성정보가 누락되는 경우에 해당한다. 또한 주식별자만 존재하고 일반속성은 전혀 없는 경우도 마찬가지로 적절한 엔터티라고 할 수 없다. 단, 예외적으로 관계엔터티(Associative Entity)의 경우는 주식별자 속성만 가지고 있어도 엔터티로 인정한다.

• 여섯 번째는 엔터티는 다른 엔터티와 최소 한 개 이상의 관계가 존재해야 한다는 것이다.

본적으로 엔터티가 도출되었다는 것은 해당 업무내에서 업무적인 연관성(존재적 연관성, 행위적 연관성)을 가지고 다른 엔터티와의 연관의 의미를 가지고 있음을 나타낸다. 그러나 관계가 설정되지 않은 엔터티의 도출은 부적절한 엔터티가 도출되었거나 아니면 다른 엔터티와 적절한 관계를 찾지 못했을 가능성이 크다.

2) 엔티티의 명명(Naming)

엔터티의 이름을 정하는 데에 있어서는 다음과 같은 원칙을 지켜야 합니다.

• 가능하면 현업업무에서 사용하는 용어를 사용한다.

• 가능하면 약어를 사용하지 않는다.
• 단수 명사를 사용한다.
• 모든 엔터티를 통틀어서 유일한 이름을 가져야 한다.
• 엔터티의 생성의미대로 이름을 부여한다.

2. 마무리

개체(Entity) : 저장할 만한 가치가 있는 중요 데이터를 가진 사람이나 사물들을 명사로 정의한 것.

• 요구사항 문장에서 업무와 관련이 깊은, 의미 있는 명사를 찾아라!

끝.

출처:

• https://dataonair.or.kr/db-tech-reference/d-guide/sql/?pageid=5&mod=document&uid=326

DB설계에서 가장 중요한 것은 "분석"이다. 내가 구현할 시스템이 무엇인지 정확하게 파악하고 이에 따른 DB설계가 이뤄져야 한다. 만약, DB설계가 제대로 되어 있지 않은 상태에서 시스템이 구현된다면, 향후 사소한 문제로 인해 DB를 수정할때 어렵게 해결해야만 하는 문제점이 생긴다. 이에 DB설계는 많은 생각과 디테일을 요구한다.

1. DB 요구사항 분석의 정의

• 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화 하는 활동
• 사용자 요구의 타당성을 조사하고 비용과 일정에 대한 제약을 설정
• 사용자의 요구를 정확하게 추출하여 목표를 정한다.

1) 요구사항 - 기능적 요구사항

• 시스템이 무엇을 하는지, 어떤 기능을 하는지 등 기능의 수행과 관련된 요구사항
• 시스템의 입력과 출력으로 무엇이 포함되어야 하는지에 대한 사항
• 시스템이 어떤 데이터를 저장하거나 연산을 수행해야 하는지에 대한 사항
• 시스템이 반드시 수행해야 하는 기능
• 사용자가 시스템을 통해 제공받기를 원하는 기능

2) 요구사항 - 비기능적 요구사항

• 품질이나 제약사항과 관련된 요구사항
• 시스템 장비 구성 요구사항
• 성능 요구사항
• 인터페이스 요구사항
• 데이터를 구축하기 위해 필요한 요구사항
• 테스트, 보안을 위한 요구사항
• 품질 요구사항: 가용성, 정합성, 상호 호환성, 대응성, 이식성, 확장성, 보안성 등
• 프로젝트 관리 요구사항
• 프로젝트 자원 요구사항

2. 예시모음

예시1) 보드 구독 커뮤니티 DB

1. 보드를 구독하려면 아이디,구독여부가 있어야합니다.
2. 유저는 여러 보드를 구독할 수 있습니다.
3. 보드를 구독했다면 글작성, 댓글작성, 좋아요 뿐만 아니라 여러 부가기능을 사용할 수 있습니다.
4. 유저는 또한 여러 글, 댓글을 작성할 수 있습니다.
5. 보드에 대한 정보 보드설명, 보드추가기능여부를 저장하고 있습니다.
6. 유저에 대한 정보 아이디,실명, 비밀번호, 구독여부를 가지고 있습니다.
7. 글에 대한 정보 아이디,글내용,글쓴날짜,어떤 보드에 해당하는 지 가지고 있습니다.

예시2) 커뮤니티 기능을 도입한 마트관리

1. Roach 마트에 가입하려면 고객은 회원아이디, 비밀번호, 나이, 직업을 입력해야한다.
2. 가입한 회원에게는 등급과 적립금이 부여된다.
3. 회원은 회원아이디로 식별한다.
4. 상품에 대한 상품번호, 상품명, 재고량, 단가정보를 유지해야 한다.
5. 상품은 상품번호로 식별한다.
6. 회원은 여러 상품을 주문할 수 있고, 하나의 상품을 여러 회원이 주문할 수 있다.
7. 회원이 상품을 주문하면 주문에 대한 주문번호, 주문수량, 배송지, 주문일자 정보를 유지해야 한다.
8. 각 상품은 한 제조업체가 공급하고, 제조업체 하나는 여러 상품을 공급할 수 있다.
9. 제조업체가 상품을 공급하면 공급일자와 공급량 정보를 유지해야 한다.
10. 제조업체에 대한 제조업체명, 전화번호, 위치, 담당자 정보를 유지해야 한다.
11. 제조업체는 제조업체명으로 식별한다.
12. 회원은 게시글을 여러개 작성할 수 있고, 게시글 하나는 한 명의 회원만 작성할 수 있다.
13. 게시글에 대한 글번호, 글제목, 글내용, 작성일자 정보를 유지해야 한다.
14. 게시글은 글 번호로 식별한다.

예시3) 쇼핑몰 구축을 위한 요구사항

1. 회원이 상품을 구매한다.
2. 회원은 상품을 카트(장바구니)에 담을 수 있다.
3. 회원정보: 회원아이디, 비밀번호, 성명, 주소, 연락처
4. 상품: 상품아이디, 상품명, 이미지, 가격
5. 회원이 요구하는 배송지에 배송을 지원한다.
6. 회원은 0또는 1곳 이상의 배송지를 등록할 수 있다.
7. 배송지: 배송지 아이디, 회원아이디, 우편번호, 연락처, 주소, 기본배송지등록여부
8. 회원은 구매하기 위해 상품을 카트에 담는다.
9. 카트(장바구니) 회원아이디, 상품아이디, 수량, 금액, 날짜
10. 회원은 구매시 신용카드로 구매한다.
11. 신용카드: 신용카드 아이디, 회원 아이디, 카드사, 카드번호, 유효기간
12. 회원은 0또는 1장 이상의 신용카드를 등록한다.
13. 주문: 회원아이디, 주문 일자, 상품명, 수량, 금액, 배송지 아이디, 카드 아이디

예시4) XX대학 요구사항

1. 교수(Professor)는 아이디(ssn), 이름(name), 나이(age), 직위(rank), 연구 분야(speciality)를 가진다.
2. 학과(Department)에는 학과번호(dno), 학과이름(dname), 학과사무실(office)이있다.
3. 대학원생(Graduate)은 아이디(ssn), 이름(name), 나이(age), 학위과정(deg_prog, 석사/박사)을 가진다.
4. 과제(Project)는 과제번호(pid), 지원기관(sponsor), 개시일(start_date), 종료일(end_date), 예산액 (budget)이있다.
5. 학과마다그 학과를 운영(run)하는 교수(학과장이라고 한다)가 한명씩 있다.
6. 한 교수가 여러학과에서 근무(work-dept)할 수 있는데, 이때각 학과별로 참여백분율(pct_time)이 기록된다.
7. 대학원생에게는 학위 과정을 밟을 전공학과(major)가하나씩 있다.
8. 대학원생에게는 어떤과목을 들으면좋을지 조언(advisor)해주는 선임대학원생(학생조언자라고 한다)이있다.
9. 과제는 한 교수(연구책임자라고 한다)에의해 관리(manage)된다.
10. 과제는 한 사람이상의 교수(공동연구책임자라고 한다)에의해 수행(work-in)된다.
11. 한 과제는 한 명이상의 대학원생(연구조교라고 한다)에의해 수행(work-prog)된다.

14번은 개체와 속성을 연결해주는 부분이다. 511번은 관계로 개체들을 연결해주는 부분이다.

예시5) 항공사 예약프로그램의 요구사항

1. 한빛 항공사에 회원으로 가입하려면 회원아이디, 비밀번호, 성명, 신용카드 정보를 입력해야 한다
2. 회원의 신용카드 정보는 여러 개를 저장할 수 있는데, 세부적으로는 신용카드번호, 유효기간을 저장할 수 있다
3. 한빛 항공사에서는 보유한 비행기에 대해 비행기번호, 출발날짜, 출발시간 정보를 저장하고 있다
4. 한빛 항공사에서는 좌석에 대한 좌석번호, 등급 정보를 저장하고 있다 회원은 좌석을 예약하는데, 회원 한 명은 좌석을 하나만 예약할 수 있고, 한 좌석은 회원 한명만 예약할 수 있다
5. 비행기에는 좌석이 존재하는데, 비행기 하나에는 좌석이 여러 개 존재할 수 있고
6. 한 좌석은 반드시 하나의 비행기에만 존재해야 한다.
7. 좌석은 비행기가 없으면 의미가 없다.

다양한 예시를 참고하여 내가 만들고자 하는 DB설계에 적절한 요구사항을 도출해보자.

요구사항 분석을 마치면, 요구사항내 존재하는 개체(Entity)와 속성(Attribute)을 추출하는 단계로 넘어간다.

끝.

출처:

• https://velog.io/@doryyy/TIL-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%AA%A8%EB%8D%B8%EB%A7%81

• https://velog.io/@hsngju/DB-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8%EB%A5%BC-%EC%9C%84%ED%95%9C-RDBMS-%EC%84%A4%EA%B3%84%EB%B0%A9%EB%B2%952-%EA%B0%9C%EB%85%90%EC%A0%81-%EC%84%A4%EA%B3%84

• https://velog.io/@tmdgusya/DB-%EC%8A%A4%ED%82%A4%EB%A7%88-%EC%84%A4%EA%B3%84#nm-%EA%B4%80%EA%B3%84%EB%8A%94-%EB%A6%B4%EB%A0%88%EC%9D%B4%EC%85%98%EC%9C%BC%EB%A1%9C-%EB%B3%80%ED%99%98%ED%95%9C%EB%8B%A4

• https://blog.advenoh.pe.kr/database/%EA%B4%80%EA%B3%84%ED%98%95-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EC%84%A4%EA%B3%84-%EB%B0%8F-%EA%B5%AC%EC%B6%95/

1. 요구사항 분석

• DB 설계에 앞서 내가 구현해야할 시스템이 어떻게 처리되는지 정확히 파악해야 한다.

2. 개체(Entity)와 속성(Attribute)을 추출 (대부분 명사)

• 요구분석에 기반하여 어떤 데이터가 필요한지 생각해보고 Entity(Table)이 얼마나 어떻게 필요한지 파악하는 것이 필요하다.
• 개체(Entity)의 속성(Attribute)은 어떤것이 필요할지 생각해보고 엔티티에 맞는 속성을 넣는다.
• -> 엔티티 완성 후 Excel 통해 속성을 구성해본다면 도움이 된다. *

3. 개체(Entity) 간의 관계(Relationship)를 추출(대부분 동사)

• 추출된 개체(Entity) 간의 어떤 관계를 가질 수 있는지를 파악해 관계(Relationship)를 만든다.

• 관계는 크게 1:1, 1:N, N:N관계로 이뤄진다.

4. 만들어진 개체-속성, 개체-관계를 바탕으로 개념적 설계(ERD) 작성

5. 논리적 설계 작성

6. 정규화

7. 물리적 설계 작성

마무리.

DB 설계를 잘 하는 사람은 '논리적 설계'부터 시작하곤 한다. 하지만, 누구에게나 처음과 과정은 있어야 한다. 잘 모르겠다. 자신이 없다. 막막하다. 싶을땐 처음부터 차근차근 해보는 것이 제일 좋다. DB의 꽃은 '정규화'이지만 시작은 '요구사항 분석'이니까!

끝.

미루고 미루던 개발 블로그를 시작하였다.
개발자의 길로 전향한지도 벌써 8개월.... 그간 많은 일들이 있었지만, 개발 블로그를 시작하며 그간 있었던 이야기들을 하나씩 풀어보고자 한다. 나의 일기는 이제 시작이다.

"미생을 넘어 완생의 그날까지"