모델링(Modeling) : 현실 세계를 대상으로 일종의 모델을 만드는 것
모델(Model) : 현실 세계의 사물 혹은 개념을 구성요소로 나누고, 이를 일정하게 도식화한 것
모델링에서 중요한 것은 도식화하는 방법과 약속된 표기법을 따라야 한다는 것이다.
모델링을 하는 이유 중 하나가 업무의 흐름을 가시화하고 명세화하여(업무 형상화) 설계 및 개발 등에 사용하고자 하는 것이기 때문이다.
약속되지 않은 표기법을 사용한다면 다른 업무 참여자는 그 의미를 이해할 수 없으므로 업무에 활용할 수 없게 된다.
모델링은 추상화를 기본으로 하기 때문에, 어떤 특징을 어느 정도로 표현할지는 모델링의 목적(업무 프로세스의 데이터)에 따라 달라진다.
업무 프로세스 상에서 관리가 필요 없는 것까지 불필요하게 구체화할 필요는 없으며, 필요한 수준에서 데이터를 추상화하여 단순하고 명료하게 표현하는 것이 중요하다.
추상화(Abstraction) : 대상의 주요 특징을 추출하여 일정한 형식으로 표현한다. 대상을 범주화하여 클래스로 구분하고 공통된 특징을 서술하는 객체 지향 설계에서의 추상화 개념과 유사하다.
단순화(Simplification) : 복잡한 현실 세계를 그대로 표현하지 않고 보다 단순하게 표현한다. UML, ERD와 같이 제한된 언어나 약속된 표기법을 사용하여 누구나 쉽게 이해할 수 있도록 한다.
명확화(Clarity) : 모델링의 결과는 보는 사람에 따라 서로 다르게 해석되지 않고, 대상을 명확하게 이해할 수 있도록 모호함이 없게 기술한다.
결국 데이터 모델링은 일정한 표기법을 사용해서 대상이 되는 데이터를 추상화, 단순화, 명확화하여 표현하는 것이다. 추상화, 단순화, 명확화는 일반적인 모델링의 특성이면서 데이터 모델링의 특성에 해당한다.
데이터를 모델링 할 때는 다음과 같은 부분을 유의해야 한다.
중복 최소화 : 데이터 베이스의 여러 곳에 같은 정보를 중복해서 저장해서는 안된다.
비유연성 최소화 : 데이터의 정의와 데이터의 사용 프로세스를 분리하여 데이터 또는 프로세스의 변화가 응용 프로그램과 데이터 베이스에 미치는 영향을 최소화해야 한다.
비일관성 최소화 : 데이터 간의 상호 연관 관계를 명확하게 정의하여 데이터가 일관성 있게 유지되어야 한다.
데이터 관점(대상) : 업무를 구성하는 데이터에 집중하여, 어떤 데이터들이 서로 관게를 맺고 사용되는지를 모델링하는 것이다. 정적 분석, 구조 분석 등을 기반으로 한다.
프로세스 관점(처리 방법) : 업무의 흐름에 집중하여, 업무가 실제로 처리하는 일이 어떻게 처리되는지를 모델링하는 것이다. 동적 분석, 도메인 분석 등을 기반으로 한다.
데이터와 프로세스의 상관 관점(대상과 처리 방법의 상관 관계) : 업무를 구성하는 데이터와 프로세스가 어떻게 관계를 맺고 영향을 주고 받는지를 모델링하는 것이다. CRUD(Create, Read, Update, Delete) 분석을 기반으로 한다.
1. 개념적 데이터 모델링
가장 높은 추상화 레벨의 모델링
업무와 개념 중심으로 포괄적인 수준의 모델링
전사적 차원의 데이터 모델링 수행할 때 발생
EA(Enterprise Architecture)를 수립할 때 많이 이용
엔터티, 속성 도출
2. 논리적 데이터 모델링
데이터 모델에 대한 키, 속성, 관계 등을 표현
서로 다른 DBMS에 적용이 가능한 수준에서의 추상화 레벨
높은 재사용성
정규화를 통해 중복 데이터 최소화
식별자 도출 및 관계를 정의
3. 물리적 데이터 모델링
특정 DBMS에 맞춰 구현이 가능한 수준에서 모델링 수행
DBMS의 성능이나 보안 및 가용성 등을 고려하여 설계
가장 낮은 수준에서의 추상화 레벨
성능 향상을 위해 반정규화 수행
테이블, 인덱스, 함수 등을 생성
ANSI-SPARC에서 정의한 데이터 베이스 아키텍처는 데이터 독립성을 보장하기 위한 설계 방법을 제시한다.
데이터 독립성은 데이터를 사용하는 사용자 영역과 실제로 데이터를 저장하는 디스크나 메모리 영역을 서로 분리하여, 상호 간에 데이터 구조나 형식에 있어서 독립적으로 설계될 수 있도록 하는 특성을 말한다.
3단계 스키마 구조는 사용자, 설계자, 개발자 관점에서 스키마를 정의한 것이다.
외부 스키마 : 사용자 관점. 사용자 또는 애플리케이션이 바라보는 데이터 스키마를 정의한다. 다중 사용자 뷰를 제공한다.
개념 스키마 : 설계자 관점. 모든 사용자가 바라보는 데이터 베이스 스키마를 통합해서 나타낸다. 전체 데이터 베이스에 저장되는 데이터와 그 관계를 정의한다. 통합된 뷰를 제공한다.
내부 스키마 : 개발자 관점. 디스크나 메모리 상의 물리적, 실질적 저장 구조를 나타낸다. 테이블, 컬럼, 인덱스 등을 정의한다. 물리적 뷰를 제공한다.
외부 스키마와 개념 스키마 사이에는 논리적 데이터 독립성이 이뤄진다.
논리적 데이터 독립성 : 외부 스키마와 개념 스키마 간의 독립성. 개념 스키마가 변경되어도 외부 스키마는 영향을 받지 않는다.
물리적 데이터 독립성 : 개념 스키마와 내부 스키마 간의 독립성. 내부 스키마가 변경되어도 개념 스키마나 외부 스키마는 영향을 받지 않는다.
응용 프로그래머가 접근하는 것은 애플리케이션의 접근과 같은 의미이다.
ERD는 데이터 모델링에 대한 문서화 방법을 제공하며, 시스템 분석 및 설계의 결과를 가시화, 문서화, 명세화하여 사용자, 설계자, 개발자 간의 의사소통 수단이 된다.
ERD는 다음과 같은 순서대로 작성한다.
엔터티를 도출한다.
도출된 엔터티를 적절하게 배치한다. 중요한 엔터티는 왼쪽 상단에 배치한다.
엔터티 간의 관계를 설정한다.
관계명을 기술한다. (행위 관계, 존재 관계를 표현)
관계의 참여도(Cardinality)를 기술한다. (일대일, 일대다, 다대다 표현)
관계의 필수 및 선택 여부를 기술한다. (Null 값을 가질 수 있는지 여부)
관계의 참여도는 관계의 표현에 있어서 매우 중요하기 때문에 생략해서는 안된다.
엔터티는 자신을 상세하게 표현하기 위해서 속성이라는 하위 요소를 갖는다. 예를 들어, 회원 엔터티의 속성으로는 회원명, 주소, 전화번호, 아이디, 비밀번호 등이 있을 수 있다.
업무에서 필요로 하고 관리하고자 하는 정보여야 한다.
식별이 가능하도록 유일한 식별자를 가져야 한다.
영속적으로 존재하는 인스턴스가 두 개 이상인 집합을 이뤄야 한다.
하위 요소로 반드시 속성을 가져야 한다.
엔터티는 다른 엔터티와 한 개 이상의 관계를 가져야 한다. 단 통계성 엔터티나 코드성 엔터티의 경우 관계를 생략할 수 있다.
여기서 인스턴스는 엔터티에 맞게 실제로 디스크에 저장된 데이터 1건을 말한다.
1. 발생 시점 및 상속 관계에 따른 분류
기본 엔터티 : 자신의 고유한 주식별자를 가지는 독립적으로 생성된 엔터티
중심 엔터티 : 기본 엔터티로부터 주식별자를 상속 받아 생성되며, 업무의 중심 역할을 하는 엔터티
행위 엔터티 : 두 개 이상의 엔터티를 상속 받아 생성되는 엔터티이며, 내용이 자주 변경되거나 데이터의 양이 계속 증가한다.
예를 들어, 회사에서 사원 및 부서 등은 기본 엔터티에 해당하지만, 급여나 주문 같은 것은 중심 엔터티에 해당한다. 이에 따른 급여 내역과 주문 내역은 행위 엔터티가 된다.
2. 물리적 형태의 존재 여부에 따른 분류
유형 엔터티 : 물리적 형태가 존재하는 엔터티
무형 엔터티 : 물리적 형태 없이 개념적으로 정의되는 엔터티
사건 엔터티 : 업무를 수행하면서 발생하는 행위나 이벤트를 나타내는 엔터티
학생이나 상품 등은 유형 엔터티가 되지만, 부서나 강의 등은 개념 엔터티가 된다. 학생이 강의를 구매했을 경우 주문과 수강이라는 사건 엔터티가 만들어질 수 있다.
엔터티를 나타내는 특징 중에서 업무와 관계되어 필요한 것들로 정의한다. 속성의 개수에는 제한이 없지만 처리하고자 하는 업무 프로세스에 꼭 필요한 것인지 고려하여, 엔터티를 정의할 때 필수적인 것들로만 최소화해야 한다.
하나의 엔터티 인스턴스에서 각각의 속성은 한 개의 속성값만을 가져야 한다. 만약 한 개 이상의 속성값을 가진다면, 1차 정규화를 수행하여 한 개의 속성만 갖도록 해야한다.
한 개의 엔터티는 두 개 이상의 인스턴스를 갖는다. (엔터티는 인스턴스의 집합이다.)
한 개의 엔터티는 두 개 이상의 속성을 가진다. (엔터티는 속성의 집합이다.)
한 개의 속성은 한 개의 속성값만을 가진다.
1. 속성의 특성에 따른 분류
기본 속성 : 엔터티가 본래부터 가지고 있어야 하는 속성
설계 속성 : 엔터티가 본래부터 가지고 있던 속성은 아니지만 설계 시 필요하다고 판단되어 도출된 속성
파생 속성 : 다른 속성으로부터 계산되거나 특정 규칙에 따라 변형되어 만들어진 속성
PK 속성(기본키 속성) : 해당 엔터티의 인스턴스를 유일하게 식별할 수 있는 속성
FK 속성(외래키 속성) : 관계를 통해 다른 엔터티의 속성을 가져와 포함시킨 속성
일반 속성 : PK, FK가 아닌 나머지 일반 속성
도메인은 데이터 타입, 크기, 제약 사항 등을 묶어 별도의 이름을 붙여 정의하고, 이렇게 정의된 도메인을 각각의 속성에 지정할 수 있다. 도메인이 지정된 속성은 해당 도메인의 데이터 타입, 크기, 제약 사항 등을 따른다.
시스템 카탈로그 : 데이터 베이스에 저장되어 있는 모든 객체들에 대한 정의나 명세에 대한 정보가 수록되어 있는 시스템 테이블
용어 사전 : 논리적, 물맂거 데이터 베이스 설계 시 사용되는 용어들의 의미를 정의해 놓은 문서
카디널리티 : 관계의 차수를 말하며 특정 데이터 집합의 유일한 값의 개수
엔터티의 관계는 존재적, 행위적 관계로 나눌 수 있으나, ERD에서는 구분하지 않고 동일하게 표현한다. UML의 클래스 다이어그램에서는 이 둘을 연관 관계와 의존 관계로 구분하고, 표기도 실선과 점선으로 나타낸다.
연관 관계 : 존재 자체로 연관성을 가지는 경우(예 : 자동차는 바퀴를 멤버로 가지고, 클래스 수준에서 사용한다.)
의존 관계 : 특정 행위를 할 때만 연관성을 가지는 경우(예 : 자동차는 운전자를 특정 메소드에서만 사용한다.)
존재적 관계 : 사원과 부서처럼 일종의 소속 관계를 갖는 경우를 말하며, 존재 자체로 서로 연관성을 갖는다.
행위적 관계 : 고객과 주문의 관계처럼 한 엔터티가 특정 행위나 이벤트를 일으킬 경우에 연관성이 발생하는 관계이다.
주문에 대해 고객은 반드시 존재해야 하므로 필수적 관계이지만, 고객은 주문을 하지 않을 수도 있기 때문에 고객에 대해 주문은 선택적 관계이다.
식별자(Identifier) : 엔터티 인스턴스에서 유일하게 구별할 수 있는 속성이자 엔터티 인스턴스의 대표 속성
키(Key) : 식별자와 유사한 개념으로, 조건에 맞는 검색이나, 정렬, 조인 등의 기준이 되는 속성이다.
주식별자(Primary Key) : 해당 엔터티 인스턴스를 유일하게 구별할 수 있는 식별자이다.
주식별자는 아래의 4가지 항목을 만족해야 한다.
유일성 : 각 엔터티 인스턴스를 유일하게 구별할 수 있어야 한다.
최소성 : 유일성을 보장하면서도 최소 개수의 속성이 되어야 한다.
불변성 : 속성값이 최초 생성 시 부여된 값에서 변경되지 않고 유지되어야 한다.
존재성 : 반드시 값을 가져야 하며 Null 값을 가질 수 없다.
1. 대표성 여부
주식별자 : 해당 엔터티 인스턴스를 유일하게 구별할 수 있는 식별자로 유일성, 최소성, 불변성, 존재성을 만족하는 식별자. 다른 엔터티와 참조 관계를 연결할 수 있다.
보조 식별자 : 해당 엔터티를 유일하게 구별할 수 있는 식별자이지만, 대표성이 없다. 다른 엔터티와 참조 관계를 연결할 수 없다.
주식별자와 보조 식별자 모두 후보키에 속한다. 후보키는 유일성과 최소성을 만족하는 속성이다.
2. 스스로 생성 여부
내부 식별자 : 엔터티 내부에서 스스로 만들어지는 식별자
외부 식별자 : 관계를 통해 다른 엔터티로부터 받아오는 식별자
3. 속성의 수
단일 식별자 : 식별자를 구성하는 속성이 하나인 식별자
복합 식별자 : 식별자를 구성하는 속성이 둘 이상인 식별자
4. 대체 여부
본질 식별자(원조 식별자) : 업무에 존재하는 본래의 식별자
인조 식별자(대리 식별자) : 업무에 존재하지 않으나, 원조 식별자가 너무 복잡하게 구성되어 있으 인위적으로 만든 식별자
1. 식별자 관계
엔터티 간의 강한 연결 관계 표현
부모 엔터티의 식별자가 자식 엔터티의 주식별자 구성에 포함
ERD로 그릴 때 실선으로 표현
부모 엔터티 인스턴스와 자식 엔터티 인스턴스가 같은 생명 주기를 가질 때 식별자 관계로 표현하는 것이 적합
2. 비식별자 관계
엔터티 간의 약한 연결 관계
부모 엔터티의 식별자가 자식 엔터티의 일반 속성
ERD로 그릴 때 점선으로 표현
자식 엔터티의 주식별자를 부모 엔터티와 별도로 생성하거나, 부모 엔터티 인스턴스에 참조값이 없어도 자식 엔터티 인스턴스가 생성될 수 있을 때 고려
여러 개의 엔터티를 하나로 통합하면서 각각의 엔터티가 가지고 있는 개별 관계가 통합될 때에도 비식별자 관계를 우선적으로 고려