SQLD 시험 대비 요약 정리 : 1-1 데이터 모델링의 이해
제 1절. 데이터 모델의 모델의 이해
- 데이터모델링이란
- 정보 시스템을 구축하기 위한 데이터 관점의 업무 분석 기법
- 현실세계의 데이터에 대해 약속된 표기법에 의해 표현하는 과정
- 데이터베이스를 구축하기 위한 분석/설계의 과정
- 모델링의 특징 (추 단 명)
- 추상화
- 현실세계를 일정한 형식에 맞추어 표현한다는 의미, 다양한 현상을 일정한 양식인 표기법에 의해 표현한다는 것
- 단순화
- 복잡한 현실세계를 약속된 규약에 의해 제한된 표기법이나 언어로 표현하여 쉽게 이해할 수있도록 하는 개념
- 명확화
- 누구나 이해하기 쉽게 하기 위해 대상에 대한 애매모호함을 제거하고 정확하게 현상을 기술하는 것
- 모델링의 관점 (데 프 데+프)
- 데이터 관점 What, Data
- 업무가 어떤 데이터와 관련이 있는지, 데이터간의 관계는 무엇인지 모델링하는 방법
- 프로세스 관점 How, Process
- 업무가 실제 하고 있는 일은 무엇인지, 무엇을 해야하는지 모델링하는 방법
- 데이터와 프로세스의 상관관점
- 업무가 처리하는 일의 방법에 따라 데이터는 어떻게 영향을 받고 있는지 모델링하는 방법
- 데이터 모델이 제공하는 기능
- 가시화
- 명세화
- 구조화
- 문서화
- 다양한 관점 제공
- 상세수준의 표현 방법 제공
- 데이터 모델링의 중요성
- 파급효과
- 복잡한 요구사항의 간결한 표현
- 데이터 품질
- 데이터 모델링을 할 때의 유의점
- 중복
- 데이터베이스가 여러장소에 같은 정보를 저장하는 잘못은 하지 않도록 한다.
- 비유연성
- 데이터 정의를 데이터의 사용 프로세스와 분리함으로써 데이터 혹은 프로세스의 작은 변화가 애플리케이션과 데이터베이스에 중대한 변화를 일으킬 수 있는 가능성을 줄인다.
- 비일관성
- 데이터의 중복이 없더라도 비일관성은 발생할 수 있기 때문에 데이터와 데이터간 상호 연관관계에 대한 명확한 정의가 필요하다.
- 개념-논리-물리 데이터 모델 (개 논 물)
- 개념적 데이터 모델링
- 추상화 수준이 높고 업무중심적이고 포괄적인 수준의 모델링 진행, 전사적 데이터 모델링, EA 수립시 많이 이용
- 핵심 엔터티와 그들관의 관계를 발견하고, 그것을 표현하기 위해서 엔터티 - 관계 다이어그램을 생성한다.
- 개념 데이터 모델은 상위의 문제에 대한 구조화를 쉽게 하며, 사용자와 개발자가 시스템 기능에 대해서 논의할 수 있는 기반을 형성한다.
- 현 시스템이 어떻게 변형되어야하는가를 이해하는데 유용하다.
- 논리적 데이터 모델링o 데이터 모델링이 최종적으로 완료된 상태라고 정의할 수 있다.o 이 단계에서 수행하는 중요한 활동은 정규화 이다.
- o 물리적인 스키마를 설계하기 전 데이터 모델의 상태이다.
- o 시스템으로 구축하고자하는 업무에 대해 Key, 속성, 관계등을 정확하게 표현, 재사용성이 높음
- 물리적 데이터 모델링o 제일 구체적인 단계의 수준
- o 실제로 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적인 성격을 고려하여 스키마를 설계한다.
- 개념적 데이터 모델링
- 데이터 독립의 필요성
- 유지보수 비용을 절감
- 데이터의 복잡도를 낮춤
- 중복된 데이터를 줄이기 위함
- 화면과 데이터베이스 간에 서로 독립성을 유지하기 위한 목적
- 데이터베이스 3단계 구조
- 외부단계
- 사용자와 가까운 단계
- 개념 단계
- 사용자가 처리하는 데이터 유형의 공통적인 사항을 처리하는 통합된 뷰를 스키마 구조로 디자인된 형태
- 내부적 단계
- 데이터가 물리적으로 저장된 방법에 대한 스키마 구조
- 데이터 독립성 요소
- 외부 스키마
- 사용자 관점
- 개념 스키마
- 통합 관점
- 내부 스키마
- 물리적 저장구조
- 데이터 독립성
- 논리적 데이터 독립성
- 내용
- 개념 스키마가 변경되어도 외부 스키마에는 영향을 미치지 않도록 지원하는 것
- 논리적 구조가 변경되어도 응용 프로그램에는 영향이 없음
- 특징
- 사용자 특성에 맞는 변경 가능
- 통합구조 변경 가능
- 내용
- 물리적 데이터 독립성
- 내용
- 내부스키마가 변경되어도 외부/개념 스키마는 영향을 받지 않도록 지원하는 것
- 저장장치의 구조 변경은 응용 프로그램과 개념 스키마에 영향 없음
- 특징
- 물리적 구조 영향없이 개념구조 변경 가능
- 개념구조 영향 없이 물리적인 구조 변경가능
- 내용
- 논리적 데이터 독립성
- 사상 (Mapping)
- 외부적/개념적 사상 (논리적 사상)
- 외부적 뷰와 개념적 뷰의 상호관련성을 정의함
- 개념적/내부적 사상 (물리적 사상)
- 개념적 뷰와 저장된 데이터 베이스의 상호관련성을 정의함
- 데이터 모델링의 세가지 요소 (Things, Attributes, Relationships)
- 업무가 관여하는 어떤 것
- 어떤 것이 가지는 성격
- 업무가 관여하는 어떤 것의 관계
- ERD 작업순서
- 엔터티를 그린다.
- 엔터티를 적절하게 배치한다.
- 엔터티간 관계를 설정한다.
- 관계명을 기술한다.
- 관계의 참여도를 기술한다. (관계 차수)
- 관계의 필수여부를 기술한다.
- 좋은 데이터 모델의 요소
- 완정성
- 업무에서 필요로하는 모든 데이터가 데이터 모델에 정의되어 있어야 한다.
- 중복 배제
- 하나의 데이터 베이스 안에 동일한 사실은 반드시 한 번만 기록하여야 한다.
- 업무 규칙
- 업무 규칙을 데이터 모델에 표현하고, 해당 데이터 모델을 활용하는 모든 사용자가 공유할 수 있도록 제공하여야 한다.
- 데이터 재사용
- 데이터의 통합성과 독립성에 대해 고려하여야 한다.
- 의사소통
- 서브타입, 속성, 관계 등의 형태로 최대한 자세하게 표현되어야 한다.
- 통합성
- 공유데이터에 대한 구조를 여러 업무영역에대서 공동으로 사용하기 용이하게 정의할 수 있어야 한다.
제 2절. 엔터티 Entity
- 엔티티 개념
- 명사
- 업무상 필요한 관심사
- 저장이 되기 위한 어떤 것
- 인스턴스의 집합
- 엔티티 특징
- 반드시 해당 업무에 필요하고 관리하고자 하는 정보여야 한다.
- 유일한 식별자에 의해 식별이 가능해야 한다.
- 영속적으로 존재하는 인스턴스의 집합이여야 한다.
- 한개가 아니라 두개 이상이여야 한다.
- 업무프로세스에 의해 이용되어야 한다.
- 엔터티는 반드시 속성이 있어야 한다.
- 엔터티는 다른 엔터티와 최소 1개 이상의 관계가 있어야 한다.
- 엔터티의 분류
- 유 무형에 따른 분류
- 유형 | 물리적인 형태가 있고, 안정적이며 지속적으로 활용되는 엔터티
- 개념 | 물리적인 형태는 존재하지 않고, 관리해야 할 개념적 정보로 구분됨
- 사건 | 업무를 수행함에 따라 발생되는 엔터티, 비교적 발생량이 많음
- 발생시점에 따른 분류
- 기본엔터티자신은 타 엔터티의 부모역할을 하게 된다.
- 다른 엔터티로부터 주 식별자를 상속받지 않고 자신의 고유한 주식별자를 갖게 된다.
- 원래 존재하는 정보, 다른 엔터티와 관계에 의해 생성되지 않고 독립적으로 생성 가능
- 중심엔터티데이터의 양이 많이 발생되고 다른 엔터티와의 관계를 통해 행위 엔터티를 생성한다.
- 기본 엔터티로부터 발생되고, 그 업무에 있어서 중심적인 역할
- 행위엔터티
- 두 개 이상의 부모엔터티로부터 발생되고 자주 내용이 바뀌거나 데이터 양이 증가된다.
- 유 무형에 따른 분류
- 엔터티 명명
- 현업업무에서 사용하는 용어 사용
- 약어 사용 자제
- 단수명사 사용
- 모든 엔터티에서 유일하게 이름이 부여되어야 한다.
- 생성의미대로 이름 부여
제 3절. 속성 Attribute
- 속성
- 업무에서 필요로한다.
- 더 이상 분리되지 않는 최소의 데이터 단위
- 엔터티를 설명하고 인스턴스의 구성요소가 된다.
- 속성의 특징
- 해당 업무에서 반드시 필요하고 관리하고자 하는 정보
- 함수적 종속성을 가져야 한다.
- 하나의 속성에는 한 개의 값만을 가진다.
- 속성의 범위
- 도메인
- 속성의 분류
- 속성의 특징에 따른 분류
- 기본 속성 | 업무로부터 추출한 모든 속성, 엔터티의 가장 일반적이고 많은 속성
- 설계 속성 | 업무상 필요한 데이터 이외의 업무를 규칙화하기 위해 새로만들거나 변형하여 정의하는 속성
- 파생속성 | 다른 속성에 영향을 받아 발생하는 속성, 보통 계산된 값, 데이터정합성을 유지하기위해 유의해야할 것이 많으므로 가급적 파생속성은 적게 정의하는 것이 좋다.
- 엔터티 구성방식에 따른 분류
- PK속성 | 엔터티를 식별할 수 있는 속성
- FK속성 | 다른 엔터티와의 관계에서 포함된 속성
- 일반속성 | 엔터티에 포함되어있고, PK,FK에 포함되지 않은 속성
- 세부의미를 쪼갤 수 있는지에 따른 분류
- 단순속성 | 나이, 성별 등 더 이상 다른 속성들로 구성될 수 없는 단순한 속성
- 복합 속성 | 주소는 시,구,동,번지와 같은 여러 세부속성으로 구성 될 수 있음
- 단일, 다중 값에 따른 분류
- 단일값 속성 | 주민번호같은 속성은 반드시 한 개만 존재한다.
- 다중값 속성 | 사람에 따라 전화번호, 집, 차 등은 여러개를 가질 수도 있다.
- 속성의 특징에 따른 분류
- 속성의 명명
- 해당 업무에서 사용하는 이름
- 서술식 속성명은 사용하지 않음
- 약어 사용 가급적 제한
- 전체 데이터 모델에서 유일성 확보
- 엔터티, 인스턴스, 속성, 속성값의 관계
- 한 개의 엔터티는 두 개 이상의 인스턴스의 집합이어야 한다.
- 한 개의 엔터티는 두 개 이상의 속성을 갖는다.
- 한 개의 속성은 한 개의 속성 값을 갖는다.
제 4절. 관계 Relationship
- 관계
- 인스턴스 사이의 논리적인 연관성으로서 존재 또는 행위로서 서로에게 연관성이 부여된 상태
- 관계의 패어링
- 각각의 엔터티의 인스턴스들은 자신이 관련된 인스턴스들과 관계의 어커런스로 참여하는 형태를 관계 페어링이라고 한다.
- 분류
- 존재에 의한 관계 | 사원은 부서에 항상 속해 있다.
- 행위에 의한 관계 | 주문은 고객이 주문을 할 때 발생된다.
- 표기법
- 관계명 | 관계의 이름
- IE 표기법, Barker 표기법 : 포함한다, 소속된다.
- 관계차수 | 1:1, 1:M, M:N
- 관계에 참여하는 각각의 엔터티는 관계를 맺는 다른 엔터티의 엔터티에 대해 하나나 그 이상의 수와 관계를 가지고 있다.
- 관계 선택 사양 | 필수 관계, 선택 관계
- 선택참여를 하는 엔티티 쪽을 원으로 표시한다. 필수참여는 아무런 표시를 하지 않는다.
- 관계명 | 관계의 이름
- 관계 체크사항
- 두 개의 엔터티 사이에 관심있는 연관 규칙이 존재하는가?
- 두 개의 엔터티 사이에 정보의 조합이 발생되는가?
- 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?
- 업무기술서, 장표에 관계연결을 가능하게 하는 동사(Verb)가 있는가?
- 관계 읽기
- 기준 엔터티를 한 개 혹은 각으로 읽는다.
- 대상 엔터티의 관계 참여도. 즉 개수를 읽는다.
- 관계 선택 사양과 관계명을 읽는다.
제 5절. 식별자
- 식별자
- 하나의 엔티티에 구성되어 있는 여러개의 속성 중에 엔터티를 대표할 수 있는 속성
- 하나의 엔티티는 반드시 하나의 유일한 식별자가 존재해야 한다.
- 특징
- 주식별자에 의해 엔터티 내에 모든 인스턴스 들이 유일하게 구분되어야 한다.
- 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 한다.
- 지정된 주식별자의 값은 자주 변하지 않는 것이어야 한다.
- 주식별자가 지정이 되면 반드시 값이 들어와야 한다.
- 분류
- 대표성 여부
- 주식별자 | 엔티티 내에서 각 어커런스를 구분할 수 있는 구분자이며, 타 엔터티와 참조관계를 연결할 수 있는 식별자
- 보조식별자 | 엔터티 내에서 각 어커런스를 구분할 수 있는 구분자이나, 대표성을 가지지 못해 참조 관계 연결을 못함
- 스스로 생성 여부
- 내부식별자 | 엔터티 내부에서 스스로 만들어지는 식별자
- 외부식별자 | 타 엔터티와의 관계를 통해 타 엔터티로부터 받아오는 식별자
- 속성의 수
- 단일식별자 | 하나의 속성으로 구성된 식별자
- 복합식별자 | 둘 이상의 속성으로 구성된 식별자
- 대체여부
- 본질식별자 | 업무에 의해 만들어지는 식별자
- 인조식별자 | 업무적으로 만들어지지는 않지만 원조식별자가 복잡한 구성을 가지고 있기 때문에 인위적으로 만든 식별자
- 대표성 여부
- 주 식별자 도출 기준
- 해당 업무에서 자주 이용되는 속성을 주식별자로 지정한다.
- 명칭, 내역 등과 같이 이름으로 기술되는 것들은 가능하면 주식별자로 지정하지 않는다.
- 명칭이나 내역 등이 있고 인스턴스를 식별할 수 있는 다른 구분자가 존재하지 않을 경우는 새로운 식별자를 생성하도록 한다. 보통 일련번호나 코드를 사용한다.
- 복합으로 주식별자를 구성할 경우 너무 많은 속성이 포함되지 않도록 한다.
- 식별자와 비식별자 관계의 결정
- 외부 식별자는 자기 자신의 엔터티에서 필요한 속성이 아니라 다른 엔터티와의 관계를 통해 자식 쪽에 엔터티에 생성되는 속성을 외부 식별자라 하며, 데이터베이스 생성 시 FK 역할을 한다.
- 엔터티에 주식별자가 지정되고 엔터티간 관계를 연결하면 부모쪽의 주식별자를 자식 엔터티의 속성으로 내려보낸다. 이 때 자식 엔터티에서 부모엔터티로부터 받은 외부식별자를 자신의 주식별자로 이용할 것인지, 또는 부모와 연결이 되는 속성으로만 이용할 것인지 결정해야 한다.
- 식별자 관계
- 자식 엔터티의 주 식별자로 부모 엔터티의 주식별자가 상속이 되는 경우
- 부모로부터 받은 식별자를 자식 엔터티의 주식별자로 이용하는 경우는 Null 값이 오면 안되므로 반드시 부모엔터티가 생성되어야 자기 자신의 엔터티가 생성되는 경우이다.
- 비식별자 관계
- 부모엔터티로부터 속성을 받았지만 자식 엔터티의 주식별자로 사용하지 않고 일반적인 속성으로만 사용하는 경우
- 다음의 경우에 비식별자 관계에 의한 외부속성을 생성한다.
- 자식 엔터티에서 받은 속성이 반드시 필수가 아니여도 무방하기 때문에 부모없는 자식이 생성될 수 있는 경우
- 엔터티 별로 데이터의 생명주기를 다르게 관리할 경우
- 여러개의 엔터티가 하나의 엔터티로 통합되어 표현되었는데 각각의 엔터티가 별도의 관계를 가질 때
- 자식 엔터티에 주식별자로 사용해도 되지만 자식엔터티에서 별도의 주식별자를 생성하는 것이 더 유리하다고 판단 될 때
- 문제점
- 식별자 관계로만 설정할 경우 문제점
- 주식별자 속성이 지속적으로 증가할 수 밖에 없는 구조로서, 개발자 복잡성과 오류가능성을 유발시킬 수 있는 요인이 될 수 있다.
- 비식별자 관계로만 설정할 경우 문제점
- 부모의 유형의 속성이 자식 엔터티로 상속이 되지 않아 자식 엔터티에서 데이터를 처리할 때 쓸데없이 부모 엔터티까지 찾아가야 하는 경우가 발생된다.
- 식별자와 비식별자 관계 비교
항목 | 식별자 관계 | 비식별자 관계 |
목적 | 강한 연결관계 표현 | 약한 연결관계 표현 |
자식 주식별자 영 향 | 자식 주식별자의 구성에 포함됨 | 자식 일반 속성에 포함됨 |
표기법 | 실선 표현 | 실선 표현 |
연결 고려 사항 | - 반드시 부모 엔터 티 종속 - 자식 주식 별자 구성에 부모 주 식별자 포함 필요 - 상속받은 주식별자 속성을 타 엔터티에 이전 필요 |
- 약한 종속 관계 - 자식 주식별자 구성 을 독립적으로 구성 - 자식 주식별자 구 성에 부모 주식별자 부분 필요 - 상속받 은 주식별자 속성을 타 엔터티에 차단 필 요 - 부모쪽의 관계 참여가 선택관계 |