RadarURL
Skip to content
조회 수 5863 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
 2-2.gif


참고 : Join에 관해 글을 올리다 보니 관계형 데이터 모델에 대한 설명이 우선 되어야 할 것 같아 이글을 올립니다.


현 재 상용 데이터베이스 제품은 대다수가 채용하고 있는 관계형 데이터 모델의 개념이 처음 언급된 것은 1970년대 E. F. Codd 박사의 "A Relational Model of Data for Large Shared Data Backs"라는 논문이었다. 그 당시, 사용되던 데이터 모델로는 계층형 데이터 모델, 네트워크형 데이터 모델이 있었지만 관계형 데이터 모델의 구조가 기존 데이터 모델에 비해 좀 더 유연하여 실세계를 좀 더 현실감 있게 반영할 수 있었기 때문에 많은 데이터베이스 시스템에 구현되었으며 이로 인하여 관계형 데이터 모델을 지원하는 관계형 데이터베이스 관리 시스템(RDBMS) 제품들이 데이터베이스 시장을 지배하게 되었다.

 

관계형 데이터 모델은 기본적으로 다음과 같이 핵심적인 3개의 구성요소로 구성되어 있으며, 실세계의 모든 업무체계를 아래의 3가지로 모두 표현할 수 있다는 개념이다.

 

1. 개체(Entity) : 시스템화하고자 하는 사건, 사물

2. 관계(Relationship) : 개체간, 속성간의 연관성

3. 속성(Attribute) : 개체, 관계성의 성질을 나타내는 더 이상 쪼갤 수 없는 정보의 단위

 

위 에서 표현된 각 구성요소들이 결국에는 관계형 데이터베이스에 구현된다. 즉, 개체는 테이블이라는 3차원의 구조로 표현되며, 관계는 외래키(FK :Foreign Key), 속성은 테이블 내의 컬럼으로 구축된다. 그러므로, 데이터베이스 시스템을 구축하기에 앞서 모델링하고자 하는 실세계를 개체, 관계, 속성으로 명확히 정의할 필요가 있다.

관계형 데이터베이스의 정의

 관계형 데이터 모델을 전산화하여 논리적으로 구축해 놓은 것이 관계형 데이터베이스이다.

관계형 데이터베이스는 정보를 저장하기 위하여 아래와 같은 2차원의 테이블 구조를 사용한다. 예를 들어, 회사의 모든 사원 정보를 데이터베이스에 저장하고자 한다면 다음과 같은 사원 테이블이 필요하게 되는데, 이는 관계형 모델로 정의된 사원 개체가 관계형 데이터베이스 내에서 사원 테이블로 구현된 것이다.

emp_1-hadesjjang.gif


 

관계형 데이터베이스의 용어

 관계형 데이터베이스에서 모든 데이터는 2차원 테이블에 저장된다. 다음과 같이 사원 정보가 입력되어 있는 사원 테이블에서 각 번호가 의미하는 것은 다음과 같다.

dept-hadesjjang.gif


 

행(Row) : 특정한 한 명의 사원을 표현하기 위해 필요한 모든 데이터이다. 테이블 내의 각 행은 반드시 기본키에 희하여 식별 가능해야 하며, 기본키의 값은 절대 중복되면 안된다. 테이블내의 행들은 임의 순서로 저장되어 있으나, 검색시 정렬이 가능하다.

기본키(PK :Primary Key) : 사번(EMPNO) 컬럼은 절대 중복 될 수 없으며, 값이 반드시 지정되어야 한다. 그러므로, 테이블내의 모든 행들은 기본키에 의해 식별될 수 있다.

컬럼(Column) :급여(SAL) 컬럼은 기본키가 아니므로 특별한 제약조건이 지정되지 않는 한, 값을 지정하지 않아도 되며 값이 중복되어도 상관 없다.

외래키(FK :Foreign Key) : 외래키는 테이블간의 관계를 정의하는 컬럼이다. 부서코드(DEPTNO) 컬럼은 외래키로서 다른 테이블의 기본키 또는 고유(Unique) 제약조건이 걸려 있는 고유키 컬럼을 참조한다. 여기서는 부서(DEPT) 테이블의 부서코드(DEPTNO)컬럼을 참조하고 있다.

필드(Field) : 행과 컬럼이 교차하는 지점을 필드(Field)라고 정의한다.

널(Null) : 필드에 값이 지정되어 있지 않는 경우를 일반적으로 NULL 값을 갖는다고 표현한다.

 NULL 값 자체도 다음의 두 가지 의미를 갖는데, "값이 아직 지정되지 않았다(Undefine)"는 의미와

"값을 아직 모른다(Unknown)"는 의미이다. 절대, 0(Zero)이나 공백(Space)과는 의미가 다르므로 혼돈해서는 안 된다.



기본키(PK)와 외래키(FK)

 

ERD 에서 표현된 개체는 추후 테이블로, 속성은 컬럼으로, 관계는 외래키 또는 테이블로 구현된다고 기술한 바 있다. 여기서는 관계형 데이터베이스에서 아주 중요하게 다루어지는 기본키(PK :Primary Key)와 외래키(FK :Foreign Key)에 대하여 살펴본다.
기본키는 다음 그림과 같이 테이블내의 각 행을 유일하게 식별 할 수 있는 컬럼이며 외래키는 자신 또는 다른 테이블의 기본키 또는 고유키를 참조하는 컬럼이다.

pkfk-hadesjjang.gif


 

예 를 들어, 위 그림과 같이 관계형 데이터베이스에 부서 테이블과 사원 테이블이 구축되어 있다고 가정하자. 부서 테이블에는 부서 정보가 입력되어 있으며, 사원 테이블에는 사원들의 정보가 각각 입력되어 있다. 부서 테이블내에서 각각의 부서 정보를 유일하게 식별할 수 있는 컬럼을 기본키로 설정하게 되는데, 이 경우는 부서코드(DEPTNO)를 기본키로 설정했다. 그러나, 부서 테이블내에 입력된 실제 데이터를 보면 부서코드(DEPTNO) 컬럼 외에 부서명(DNAME), 위치(LOG) 컬럼 모두 기본키가 될 자격(모든 값이 고유하고 NULL 값이 존재하지 않음)은 충분히 있지만 부서명(DNAME)이나 위치(LOG) 컬럼은 추후 NULL값이 입력되거나 데이터 값이 중복 입력될 소지가 충분히 있으므로 기본키의 후보로서 적절치 않음을 알 수 있을 뿐 아니라 기본키는 해당 테이블의 대표 속성으로서 나름대로 의미를 가지기 때문에 부서코드(DEPTNO)가 기본키로서 적절함을 알 수 있다. 부서 테이블 또한 동일한 맥락에서 사번(DEPTNO)이 기본키로 지정되었음을 확인 할 수 있다.

 

외래키는 테이블간의 관계를 정의하는 컬럼으로 위 그림에서는 사원들의 소속부서 정보를 관리하고자 설정된 것이다. 만약, 사원의 소속부서 정보를 궅이 데이터베이스에 구축하여 관리하고자 할 필요가 없다면 이러한 관계 설정은 불필요한 것이 된다. 여기서는 부서 테이블의 기본키 컬럼을 사원 테이블의 외래키 컬럼으로 추가시켜 부서와 사원간의 관계를 상호 참조 할 수 있도록 지정하였다. 이로써 각각의 사원들이 어느 부서에 소속되어 있는지, 각각의 부서에 소속된 직원들은 누구인지 등의 정보를 검색할 수 있게 된다.

 

데이터 모델링의 4단계

 

데이터 모델링은 다음 그림과 같이 4단계에 걸쳐서 진행되며, 각 단계별 수행 작업과 산출물은 다음과 같다.

model-hadesjjang.gif


 

1) 요구형성 및 분석

 데 이터베이스 시스템 구축을 위한 요구사항을 취합하여 분석한 후, 업무처리 규정을 도출하는 단계이다. 이 단계에서 필요한 자료는 업무분장표, 현재업무흐름도, 입출력 활용 장표, 인터뷰 내용, 현 시스템분석도 등이 요구되며 이를 기반으로 최종 업무처리 규정이 산출되게 된다.

 

예) 업무처리 규정

* 각각의 회사원은 한 부서에 소속된다.

* 회사원에 관해서는 사번, 이름, 주소 등의 정보가 유지된다.

* 부서에 관해서는 부서코드, 부서명에 대한 정보가 유지된다.

2) 개념적 설계

 전 단계에서 산출된 업무처리규정을 이용하여 중심 데이터인 개체를 도출하고 개체 관계도(ERD)를 작성하는 과정이다. 데이터베이스를 처음 다루는 입문자에게 개체라는 개념이 상당히 어렵게 느껴질 수도 있으나 관계형 데이터 모델이 최종적으로 관계형 데이터베이스에 구축될 때, 개체가 테이블로 변환된다는 생각을 하면 쉽게 개념을 잡을 수 있을 것이다.

%B0%B3%B3%E4-hadesjjang.gif



 

3) 논리적 설계

 전 단계에서 산출된 ERD로부터 엔티티를 테이블, 속성을 컬럼, 관계를 테이블 또는 속성으로 적절히 변화하는 단계이다. 이 과정에서는 정규화라는 과정이 필수적으로 선행된다. 정규화란 자료의 손실이나 불필요한 정보의 도입 없이 데이터의 일관성, 최소한의 데이터 중복, 최대의 데이터 안정성 확보를 위한 안정적 자료구조로 변환하는 기번을 의미하는데, 쉽게 말하자면 동일한 테이블내에 같은 데이터들이 중복해서 입력이 되면 데이터가 입력, 수정, 삭제되는 조작 과정에서 여러 가지 이상현상이 발생하기 때문에 정규화는 이러한 일들이 발생되지 않도록 데이터 중복을 최소화하여 테이블을 여러 개로 분리시키는 일련의 과정을 말한다.

예) 테이블로의 변환 예

     부서 테이블(부서코드(PK), 부서명, 위치)

     사원 테이블(사번(PK), 이름, 주소, 부서코드(FK))

 

4) 물리적 설계

 전 단계에서 변환된 관계형 테이블을 실제 데이터베이스 서버에 구현 할 수 있도록 테이블 차트를 작성한다. 또한, 이 단계에서는 서버의 디스크 구조에 따라 데이터 파일의 배치, 인덱스 최적 설계, 트랜잭션 처리 알고리즘 등을 결정하여 구현된 데이터베이스가 최대한의 성능을 발휘할 수 있도록 구현하는 단계이다.

%B9%B0%B8%AE-hadesjjang.gif



 

ERD(Entity - Relationship Diagram)

 

ERD는 데이터베이스 모델링의 4단계 중에서 개념적 설계의 산출몰로서 도출되어야 하는 결과이다.

ERD 는 수작업으로 작성할 수도 있으나, 최근의 데이터베이스들은 엄청난 수의 테이블을 포함하고 있기 때문에 ERD를 직접 손으로 작성한다는 것은 거의 불가능하다. 이를 위해서 상용 ERD작성 툴을 많이 사용하는데, 그 대표적인 소프트웨어가 CA의 Erwin이라는 프로그램이다.

 

Erwin에서 관계형 데이터 모델의 기본이 되는 3개의 구성요소는 다음과 같이 표현된다.

■ 개체(Entity)

 Erwin에서 개체는 사각형으로 표현되며, 사작형의 상단에 개체의 이름이 기술된다.

erwin-hadesjjang.gif


 

ERD 에서 관계를 표시하는 방법은 관계의 카디널리티(Cardinality)에 따라 다르게 표현된다. 여기서, 카디널리티란 각 관계자에서 참여자의 수를 표현하는 것을 말하는데 쉽게 설명하자면 한개 부서에 한명의 사원만이 배정되는 관계는 1:1이 되며, 한개 부서에 한명이상의 사원이 배정되면 1:M(Many)이 되는 것이다. M:M의 경우는 한 개의 부서에 한명이상의 사원이 배정되며, 한명의 사원이 여러 부서에 동시에 소속될 수 있다는 의미가 된다. 예를 들면, 인사과에 홍길동, 콩쥐, 팥쥐 등 여러 명의 사원이 배정되는 관계라면 1:M, 인사과에 홍길동, 콩쥐 팥쥐등 여러명의 사원이 배정되는 동시에 홍길동이 인사과, 총무과, 홍보과 등의 여러 부서에 소속되면 M:M 관계가 되는 것이다. 그러나. M:M 관계의 경우는 논리적인 테이블로 구현할 수 없기 때문에 논리적 설계과정에서 M:M 관계를 테이블로 변환하여 두 개의 1:M 관계로 반드시 분해 하여야만 한다는 점을 잊으면 안 된다.

 

그러면 Erwin에서 이러한 카디널리티가 어떻게 표현되는지 살펴보자. Erwin에서 카디널리티가 1로 표현되는 엔티티 쪽은 실선으로 그리고 M으로 표현되는 엔티티 쪽은 까마귀 밭(Crow's foot)과 같이 그린다. 위와 같은 경우는 한 개의 부서에 여러 명의 사원이 소속되는 관계를 표현한 것임을 알 수 있다.

또한, 관계로 표현된 점선의 양단에 ○ 기호를 확인 할 수 있는데, 이 기호는 선택도를 표시한 것이다. 즉, ○이 붙어 있는 경우를 선택(Optional), 그렇지 않은 경우를 필수(Mandatory)라고 표현하는데, 사원 엔티티 쪽에 ○이 붙어 있는 경우는 각 부서에 사원이 한명도 배정되지 않을 수도 있다는 의미이고 반대로, 부서 엔티티 쪽에 ○이 붙어 있는 경우는 사원 중에서 어떠한 부서에도 소속되지 않은 사원이 있을 수 있음을 의미한다.

 

카디널리티와 선택도가 이해되었다면 다음과 같은 ERD를 각각 분석해보도록 하자, ERD를 읽을 때는 왼쪽엔티티에서 오른쪽 엔티티로 한번 읽고, 그 반대로 한번 읽는다.

entity-hadesjjang.gif


 

마 지막으로 카디널리티와 선택도 이외에 한가지 더 알아두어야 할 것이 있는데 관계의 식별성이다. 지금까지 Erwin에서 표현되는 관계는 점선이었는데, 이 점선을 비식별(Non-Identifying) 관계라고 부른다. 비식별 관계로 표시되는 경우는 카디널리티가 1쪽인 엔티티의 기본키 속성이 M쪽인 엔티티의 외래키로 구현되는 과정에서 일반 속성으로 추가된다는 의미이다. 즉, 아래 그림과 같이 부서 엔티티의 기본키인 부서코드 속성이 사원 엔티티의 외래키로 생성되며 일반 속성으로 추가된다는 의미이다.

1.gif


 

반 면에 다음과 같이 실선으로 표시되는 관계를 식별(Identitying) 관계라고 부르는데, 이와 같은 경우, 카디널리티가 1쪽인 엔티티의 기본키 속성이 M쪽인 사원 엔티티의 외래키로 구현되는 과정에서 사원의 기본키 속성으로 추가된다는 의미이다. 즉, 아래 그림과 같이 부서 엔티티의 기본키인 부서코드 속성이 사원 엔티티의 외래키로 생성되며 기본키 속성으로 추가된다는 의미이다.

2-2.gif


 

식 별/비식별 관계는 두개의 엔틴티간에서는 큰 의미가 없기 때문에 다음과 같은 세 개의 엔티티로 구성된 식별/비식별 관계를 살펴보도록 하자. 먼저, 지역 엔티티, 부서 엔티티, 사원 엔티티로 수성되어 있으며 각각 1:M 관계로 설정되었다. 즉, 지역 엔티티의 기본키인 지역코드가 부서 엔티티의 외래키(일반 속성)로 추가되었고, 부서 엔티티의 기본키인 부서코드가 사원 엔티티의 외래키(일반 속성)로 추가되었음을 확인할 수 있다. 이러한 ERD에서 사원의 이름을 검색조건으로 지역명을 검색하고자 한다면 3개의 엔티티를 모두 조인(Join) 하여야 한다.


3.gif

반 면, 아래와 같이 지역 엔티티와 부서 엔티티간의 식별관계로 수성된 경우는 사원 엔티티에 지역 엔티티와 부서 엔티티의 기본키가 각각 포함되므로 지역 엔티티와 사원 엔티티가 직접 조인(Join)이 가능해지기 때문에 위의 경우보다 수행성능이 항상될 것임을 예상할 수 있다.

4.gif


식별/비식별 관계는 구현상 장단점이 있기 때문에 상황에 맞추어 선택해야 한다.


글 소스 : 이 글은 예전에 제가 공부하려고 구해놓은 것인데... 원천 소스가 어딘지(또는 누구인지) 알수가 없네요.
             혹시 아시는 분 있으시면 댓글 남겨주시면 표시를 하거나 저작권에 위배된다면 삭제하도록 하겠습니다.

 

출처 : http://oksoft.tistory.com/26

?

List of Articles
번호 제목 글쓴이 날짜 조회 수
21 MySQL Dump / Import (덤프 / 임포트) JAESOO 2016.10.10 71
20 빅데이터 시대, DB·데이터 암호화 솔루션 길라잡이 JAESOO 2015.04.28 379
19 mariadb 원격 접속 허용 JAESOO 2014.04.29 2971
18 Database(데이터베이스) 관련 Naming Rule(이름설정 규칙) [SQL] JaeSoo 2013.12.03 6066
17 iBATIS(아이바티스) 시작 JaeSoo 2013.09.22 4264
16 iBatis(아이바티스)란? JaeSoo 2013.09.22 5198
15 innodb 와 myisam 의 차이점과 성능비교 JaeSoo 2013.04.11 4395
14 DB 모델링 툴 검토 JaeSoo 2013.03.21 3672
13 데이터베이스 모델링 툴의 새로운 대안 eXERD JaeSoo 2013.03.21 3998
12 무료 DB모델링툴(Freeware) 검토결과 1 JaeSoo 2013.03.21 4687
11 ERD 그리는 프로그램 JaeSoo 2013.03.21 3600
10 [ERD 툴] DB Modelling 툴 종류 및 비교 JaeSoo 2013.03.21 4160
9 innodb를 myisam으로 변환 가능한가요? JaeSoo 2012.07.28 4226
8 InnoDB vs MyISAM JaeSoo 2012.07.28 2714
7 테이블 스페이스(TABLE SPACE)란? JaeSoo 2012.07.20 3754
6 SAM,DAM,VSAM,ISAM,SMS JaeSoo 2012.07.12 4419
5 고급 조인 만들기 : SELF JOIN, NATURAL JOIN, OUTER JOIN JaeSoo 2012.05.08 7143
4 쿼리의 결합 : UNION 으로 쿼리 결합하기 JaeSoo 2012.05.08 3619
3 ERD 를 엑셀 EXCEL 로 변환 JaeSoo 2012.04.23 5177
» 관계형 데이터 모델(Relational Data Model) 의 설계 JaeSoo 2012.02.17 5863
Board Pagination Prev 1 2 Next
/ 2

PageViews   Today : 1,377   Yesterday : 1,710   Total : 19,855,293  /  Counter Status   Today : 481   Yesterday : 607   Total : 1,435,758
Site Info   Member : 237  /  Total documents : 1,223   New documents : 0  /  Total comments : 24

Edited by JAESOO

sketchbook5, 스케치북5

sketchbook5, 스케치북5

나눔글꼴 설치 안내


이 PC에는 나눔글꼴이 설치되어 있지 않습니다.

이 사이트를 나눔글꼴로 보기 위해서는
나눔글꼴을 설치해야 합니다.

설치 취소