[SQLD] 1.데이터 모델링의 이해

데이터 모델링이란

• 정보시스템을 구축하기 위한 데이터 관점의 업무 분석 기법
• 현실 세계의 데이터(what)에 대해 약속된 표기법에 의해 표현하는 과정
• 데이터베이스를 구축하기 위한 분석/설계의 과정

데이터 모델링 목적

• 업무정보를 구성하는 기초가 되는 정보들에 대해 일정한 표기법에 의해 표현함으로써 정보시스템 구축의 대상이 되는 업무 내용을 정확하게 분석하는 것
• 분석된 모델을 가지고 실제 데이터베이스를 생성하여 개발 및 데이터관리에 사용하기 위한 것
• 즉, 단지 데이터베이스만을 구축하기 위한 용도로 쓰이는 것이 아니라 데이터모델링 자체로서 업무를 설명하고 분석하는 부분에서도 매우 중요한 의미를 가지고 있다

모델링 특징

• 현실세계를 일정한 형식에 맞추어 표현하는 추상화의 의미를 가짐
• 시스템 구현, 업무분석, 업무 형상화의 목적이 있음
• 복잡한 현실을 제한된 언어나 표기법으로 이해하기 쉽도록하는 단순화의 의미를 가짐
• 애매모호함을 배제하고 누구나 이해 가능하도록 정확하게 현상을 기술하는 정확화의 의미를 가짐
• 데이터 모델링 자체로 업무를 설명하고 분석하는 부분에서도 매우 중요한 의미를 가짐

 

 

데이터 모델링 유의점

중복(Duplication)

• 같은 데이터를 사용하는 사람, 시간, 그리고 장소를 파악하는데 도움을 줌으로써 데이터베이스가 여러 장소에 같은 정보를 저장하는 잘못을 하지 않도록 한다.

비유연성(Inflexibility)

• 데이터 모델을 어떻게 설계했느냐에 따라 사소한 업무변화에도 데이터 모델이 수시로 변경됨으로써 유지보수의 어려움을 가중시킬 수 있다.
• 데이터의 정의를 데이터의 사용프로세스와 분리함으로써 데이터 모델링은 데이터 혹은 프로세스의 작은 변화가 애플리케이션과 데이터베이스에 중대한 변화를 일으킬 수 있는 가능성을 줄인다.

비일관성(Inconsistency)

• 데이터의 중복이 없더라도 비일관성은 발생할 수 있다.
• 개발자가 서로 연관된 다른 데이터와 모순된다는 고려 없이 일련의 데이터를 수정할 수 있기 때문에 문제가 발생한다.
• 데이터 모델링을 할 때 데이터와 데이터 간의 상호 연관 관계에 대해 명확하게 정의한다면 위험을 사전에 예방할 수 있다.
• 사용자가 처리하는 프로세스 혹은 이와 관련된 프로그램과 테이블의 연계성을 높이는 것은 데이터 모델이 업무 변경에 대해 취약하게 만드는 단점에 해당한다.

데이터 모델링 개념

개념적 데이터 모델링

• 추상화 수준이 높음
• 업무 중심적이고 포괄적인 수준의 모델링 진행
• 전사적 데이터 모델링
• EA(Enterprise Architect) 수립 시 많이 사용

논리적 데이터 모델링

• 시스템을 구축하고자 하는 업무에 대해 Key, 속성, 관계 등을 정확하게 표현
• 재사용성 높음

물리적 데이터 모델링

• 실제로 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적인 성격을 고려하여 설계

데이터 모델링 관계

• 관계는 존재적 관계와 행위에 의한 관계로 구분될 수 있다
• ERD에서는 관계를 연결할 때 존재와 행위를 구분하지 않고 단일화된 표기법을 사용한다
• UML(Unified Modeling Language)에는 클래스다이어그램의 관계 중 연관관계(Association)와 의존관계(Dependency)가 있고 이것은 실선과 점선의 표기법으로 다르게 표현된다

데이터베이스 스키마 구조 3단계

개념 스키마

• 모든 사용자 관점을 통합한 조직 전체 관점의 통합적 표현
• 모든 응용시스템들이나 사용자들이 필요로 하는 데이터를 통합한 조직 전체의 데이터베이스를 기술한 것
• 데이터베이스에 저장되는 데이터와 그즐간의 관계를 표현하는 스키마

외부 스키마

내부 스키마

ERD작성 순서

• 엔티티 도출
• 엔티티 배치
• 관계 설정
• 관계명 기술

엔티티 특징

• 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다
• 유일한 식별자에 의해 식별이 가능해야 한다
• 영속적으로 존재하는 인스턴스의 집합이어야 한다
• 업무 프로세스에 의해 이용되어야 한다
• 반드시 속성이 있어야 한다
• 다른 엔티티와 최소 한 개 이상의 관계가 있어야 한다
• 통계성 엔티티나 코드성 엔티티의 경우 관계를 생략할 수 있다

발생 시점에 따른 엔티티 분류

기본 엔티티(키 엔티티)

중심 엔티티

행위 엔티티

개념 엔티티

엔티티 명명 기준

• 현업의 업무 용어를 사용하여 업무상의 의미를 분명하게 한다
• 모든 엔티티에서 유일한 이름이 부여되어야 한다
• 엔티티가 생성되는 의미대로 자연스럽게 부여하도록 한다
• 가능하면 약어를 사용하지 않는다
• 단수명사를 사용한다

관계

• 관계 표기법은 관계명, 관계차수, 선택성(선택사양)의 세가지 개념으로 표현된다
• 관계명(Relationship Membership) : 관계의 이름
• 관계차수(Relationship Degree/Cardinality) : 관계의 기수성 (1:1, 1:M)
• 관계선택사양(Replationship Optionality) : 필수관계, 선택관계

관계 도출 시 체크사항

• 두 개의 엔티티 사이에 관심 있는 연관규칙이 존재하는가?
• 두 개의 엔티티 사이에 정보의 조합이 발생되는가?
• 업무기술서, 장표에 관계연결을 가능하게 하는 동사가 있는가?
• 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?

속성

• 엔티티에 대한 자세하고 구체적인 정보를 나타낸다
• 하나의 엔티티는 두 개 이상의 속성을 갖는다
• 하나의 인스턴으세어 각각의 속성은 하나의 속성값을 가져야 한다
• 속성도 집합이다

속성 특성에 따른 분류

기본 속성(Basic Attribute)

• 원래 가지고 있어야 하는 속성
• 업무로부터 추출된 일반적인 속성

설계 속성(Designed Attribute)

• 원래 존재하지 않지만 필요에 따라 설계자가 추가한 속성

파생 속성(Derived Attribute)

• 데이터를 조회할 때 빠른 성능을 낼 수 있도록 하기 위해 원래 속성의 값을 계산하여 저장할 수 있도록 만든 속성

도메인

• 각 속성이 가질 수 있는 값의 범위
• 엔티티 내에서 속성에 대한 데이터타입과 크기 그리고 제약사항을 지정하는 것

식별자

대표성을 가지는가?

• 주 식별자(Primary Identifier) : 모든 인스턴스들이 구분되어야 한다(유일성) / 유일성을 만족하는 최소의 수가 되어야 한다(최소성) / 자주 변하지 않아야 한다(불변성) / 반드시 값이 들어와야 한다(존재성)
• 보조 식별자(Alternate Identifier) : 유일성은 만족하지만 대표성을 가지지 못해 참조관계 연결을 할 수 없다

스스로 생성되었는가?

• 내부 식별자 : 엔티티 내부에서 스스로 생성되는 식별자
• 외부 식별자(Foreign Identifier) : 다른 엔티티와의 관계를 통해 다른 엔티티로부터 받아오는 식별자

단일 속성으로 식별이 되는가?

• 단일 식별자(Single Identifier) : 하나의 속성으로 구성
• 복합 식별자(Composit Identifier) : 두개 이상의 속성으로 구성

업무에 의해 만들어졌는가?

• 본질 식별자 : 업무에 의해 만들어지는 식별자
• 인조 식별자 : 업무적으로 만들어지지는 않지만 원조식별자가 복잡한 구성을 가지고 있기 때문에 인위적으로 만든 식별자

식별자와 비식별자관계

식별자

• 강한 연결관계 표현
• 자식 주식별자의 구성에 포함됨
• 실선 표현
• 반드시 부모엔티티 종속
• 자식 주식별자구성에 부모 주식별자포함 필요
• 상속받은 주식별자속성을 타엔티티에 이전 필요

비식별자

• 약한 연결관계 표현
• 자식 일반속성에 포함됨
• 점선 표현
• 약한 종속관계
• 자식 주식별자구성을 독립적으로 구성
• 자식 주식별자구성에 부모 주식별자 부분 필요
• 상속받은 주식별자속성을 타 엔티티에 차단 필요
• 부모쪽의 관계 참여가 선택관계

비식별자 관계로 설정하는 경우

• 관계의 강약을 분석하여 상호간에 연관성이 약할 경우 
• 자식 테이블에서 독립적인 Primary Key의 구조를 가지기 원할 때 
• SQL 문장의 복잡도를 낮추는 목적 (가장 마지막으로 고려)