
SQLD 학습을 진행하며 기억할 내용을 간략히 기록합니다.
용어로 Entity(엔티티)를 엔터티라고 발음하지만 엔티티로 정리합니다.
데이터 모델링의 세 가지 관점
1. 데이터 관점 : 업무가 어떤 데이터와 관련이 있는지 또는 데이터 간의 관계는 무엇인지에 대해서 모델링 하는 방법(What, Data)
2. 프로세스 관점 : 업무가 실제로 하고 있는 일은 무엇인지 또는 무엇을 해야 하는지를 모델링 하는 방법(How, Process)
3. 데이터와 프로세스의 상관 관점 : 업무가 처리하는 일의 방법에 따라 데이터는 어떻게 영향을 받고 있는지 모델링하는 방법(Interaction)
외부스키마: 여러 사용자 관점으로 구성- View
개념스키마: 통합된 모든 사용자의 관점
내부스키마: 물리적인 저장구조를 표현
외부스키마 -- 논리적 데이터 독립성 -- 개념스키마 -- 물리적 데이터 독립성 -- 내부 스키마
사상
논리적 독립성: 개념 스키마가 변경되어도 외부 스키마에는 영향을 주지 않는다.
논리적 구조가 변경되어도 응용 프로그램에는 영향이 없음, 통합구조 변경 가능
-> 개념 스키마가 변경되어도 외부 스키마는 영향 X
외부 스키마를 변경하지 않으면서 개념적 스키마(또는 논리적 스키마)를 변경할 수 있는 성질
물리적 독립성: 물리 스키마가 변경되어도 논리 스키마에 영향을 주지 않는다.
물리적 독립성은 파일 저장구조의 변경이 논리 스키마와 응용 프로그램에 영향을 주지 않음
-> 내부스키마가 변경되어도 외부/개념 스키마는 영향 X
개념 스키마를 변경하지 않으면서 내부 스키마를 변경할 수 있는 성질
정리
외부, 개념, 내부 순서로 스키마가 이루어져있음
외부와 개념 사이에는 논리적 독립성, 개념과 내부 사이에는 물리적 독립성을 가지고 있음
논리적 독립성에 의해 개념은 변경되어도 상위 외부 스키마에 영향이 없음
물리적 독립성에 의해 내부는 변경되어도 상위 외부, 개념 스키마에 영향이 없음
공통코드, 통계성 엔티티의 경우 관계 생략 가능
기본 속성:
설계 속성:
파생 속성: 데이터를 조회할 때 성능을 빠르게 하기 위해 원래 속성의 값을 계산하여 저장할 수 있도록 만든 속성
관계
존재에 의한 관계, 행위에 의한 관계로 구분 가으
ERD에서는 이 두 가지를 구분하지 않고 단일화된 표기법을 사용
UML에서는 이 두 가지를 구분하여 연관관계는 실선, 의존관계는 점선으로 표현
관계의 표기법
관계명, 관계차수, 선택성
존재에 의한 관계
소속된다
행위에 의한 관계
주문한다
명칭, 내역 등과 같이 번호가 아닌 이름으로 기술 되는 것들은 주식별자로 지정하기에 적절하지 않음
특히 사람의 이름은 동명이인이 있을 수 있기 때문에 더욱이 부적절
유일성: 주식별자에 의해 엔티티 내의 모든 인스턴스들은 유일하게 구분
존재성: 반드시 데이터값이 존재함
불변성: 주식별자가 한번 특정 엔티티에 지정되면 그 식별자의 값은 변하지 않아야 함
최소성: 주식별자를 구성하는 속성이 수는 유일성을 만족하는 최소의 수
비식별자: 부모 속성을 자식의 일반 속성으로 사용
1. 부모 없는 자식이 생성될 수 있는 경우
2. 부모와 지식의 생명주기가 다른 경우
3. 여러 개의 엔티티가 하나의 엔티티로 통합되어 표현되었는데 각각의 엔티티가 별도의 관계를 가진 경우
4. 자식 엔티티에 별도의 주식별자를 생성하는 것이 더 유리한 경우
5. SQL 문장이 길어져 복잡성이 증가되는 것을 방지
주식별자: 대표성을 가짐, 여러 인스턴스 중 하나를 유일하게 구분 가능
보조식별자: 여러 인스턴스 중 하나를 유일하게 구분 가능하나 대표성을 가지지 못함
본질식별자: 집합을 명확하게 설명할 수 있는 업무족으로 의미가 부여
외부식별자: 다른 엔티티로부터 상속되어 정의
인조 식별자: 인위적으로 만듦
속성이 가질 수 있는 값의 범위: 도메인
기본 속성: 업무분석을 통해 바로 정의한 속성
설계 속성: 원래 업무상 존재하지는 않지만 설계를 하면서 도출해내는 속성
파생 속성: 다른 속성으로부터 계산이나 변형이 되어 생성되는 속성