[SQLD] 21.11.20 제43회 SQL개발자 후기, 공부방법, 정리본, 43회 출제문제
2021년 11월 20일 토요일 제43회 SQL개발자 자격증 시험 후기 오늘 보고왔다! 내 공부방법과 정리본, 이번에 시험에 출제된 문제들을 기억나는대로 적어보겠다 개인적으로 기출이나 복원된 문제가
lotuus.tistory.com
[목차]
💚모델링
💚엔터티 Entity
💚속성 Attribute
💚관계 Relationship
💚식별자 Identifiers
💚ERD IE 표기법 vs Barker 표기법
💚모델링
데이터모델링
데이터모델링의 고려사항
데이터모델링의 유의점
데이터모델링의 3단계진행
데이터 독립성
Mapping 사상, 연결
데이터모델표기법 ERD Entity Relationship Model
좋은 데이터 모델의 요소
💚엔터티 Entity
엔터티와 인스턴스
엔터티의 특징
엔터티의 분류
엔터티의 명명
💚속성 Attribute
속성의 특징
속성의분류
도메인
속성의 명명
💚관계 Relationship
관계 페어링
관계의 분류
관계의 표기법
관계 정의 시 체크사항
💚식별자 Identifiers
주식별자의 특징
식별자 분류
주식별자 도출기준
식별자/비식별자 관계
💚ERD IE 표기법 vs Barker 표기법
데이터 모델의 이해
💚모델링
현실세계를 추상화, 단순화( 목적에 맞게 관심있는 특성만 추출 )하여 표현하는 기법이다.
EX. 같은 사람에 대한 내용이여도, 병원에 있는 사람(환자)에 대한 내용과
은행에 있는 사람(고객)에 대한 내용은 완전히 다른 방법으로 접근해야한다.
데이터모델링
데이터모델링은 업무정보를 구성하는 기초정보를 약속된 표기법에 의해 표현함으로써 업무내용을 정확하게 분석하고,
분석된 모델로 실제 데이터베이스를 생성하여 시스템 개발 및 데이터 관리에 사용하기 위해 수행한다.
애매모호함을 배제하고 누구나 이해가 가능하도록 정확하게 현상을 기술하는 정확화의 의미를 가진다. (O)
시스템 구현만을 위해 진행하는 사전단계의 작업으로서 데이터베이스 구축을 위한 사전작업의 의미가 있음 (X)
-> 시스템 구현을 포함한 업무분석 및 업무형상화 목적도 있음
데이터모델링의 고려사항
- 잘못된 데이터 모델링을 시스템 완성 후 변경하고자 하면 파급효과가 크다. 독립성이 확보되어야 능동 대응이 가능하다.
- 복잡한 정보를 간결하게 표현해야한다.
- 데이터 표준을 정의하여 데이터의 품질을 높여야한다.
데이터모델링의 유의점
| 중복 | 여러 장소에 같은 정보가 저장되지 않도록 해야한다. |
| 비유연성 | 사소한 업무변화에 데이터 모델이 수시로 변경되면 안된다. => 데이터 정의를 데이터 사용 프로세스와 분리함으로써 방지할 수 있다. |
| 비일관성 | 데이터는 모순되지않고 일관성있어야한다. |
데이터모델링의 3단계진행
개념적 데이터 모델링(Conceptual Data Modeling) 추상화정도 높음 / 구체화정도 낮음
사용자와 시스템 개발자의 요구사항을 사람이 이해할 수 있는 데이터 모델로 변환하는 과정이다.
개체, 관계를 정의하여 ERD로 정의한다.
논리적 데이터 모델링(Logical Data Modeling) 추상화정도 중간 / 구체화정도 중간
컴퓨터가 이해할 수 있는 논리적구조로 변환하는 과정이다.
ERD를 특정 DBMS에 맞게 사상한다.
물리적 데이터 모델링(Physical Data Modeling) 추상화정도 낮음 / 구체화정도 높음
논리적 구조를 저장장치가 표현할 수 있는 물리적 구조로 변환하는 과정이다.
create table Order(
orderID number(2) primary key,
customerID number(2) references Customer(customerID),
productID number(2) references Product(productID),
orderdate DATE
);
데이터 독립성
유지보수 비용 증가, 데이터 중복성 증가, 데이터 복잡도 증가, 요구사항 대응 저하
이러한 이유들로 데이터 독립성이 필요하게되었다.
데이터독립성은 ANSI/SPARC의 3단계 구조로 정의할 수 있다.
| 외부스키마 | 개인이 보는 DB스키마. 추상화정도 높음 |
| 논리적 데이터 독립성 | 개념스키마가 변경되어도 외부스키마에 영향 없는 것. (새 칼럼이 추가되어도 프로그램에 영향 없음) |
| 개념스키마 | 모든 사용자. 전체가 보는 DB스키마. |
| 물리적 데이터 독립성 | 내부스키마가 변경되어도 개념/외부 스키마에 영향 없는 것. (저장장치가 변경되어도 프로그램에 영향 없음) |
| 내부스키마 | 물리장치가 데이터 저장방법을 표현하는 스키마. 추상화정도 낮음 |
Mapping 사상, 연결
| 논리적 사상 (외부 - 개념스키마) | 외부화면에 보여지는 외부스키마와 전체에 보여지는 개념스키마가 연결된다. |
| 물리적 사상 (개념 - 내부스키마) | 전체에 보여지는 개념스키마와 저장장치 관점의 내부스키마가 연결된다. |
데이터모델표기법 ERD Entity Relationship Model
ERD는 엔터티와 엔터티간의 관계를 쉽게 도식화된 다이어그램으로 표시하는 방법이다.
ERD 작업순서
1. 엔터티 그리기
2. 엔터티 적절히 배치
중요한 순서대로 왼쪽상단 - 오른쪽상단 - 왼쪽하단 - 오른쪽하단 순서로 배치한다.
업무흐름상 타 엔터티와 많은 관계를 가진 중심엔터티를 중앙에 배치한다.
3. 엔터티간 관계 설정
4. 관계명 기술
관계명은 현재형을 사용하고 지나치게 포괄적인 용어는 사용하지 않도록 한다.
5. 관계의 관계차수(참여도) 기술
6. 관계의 필수여부 기술
좋은 데이터 모델의 요소
| 완전성 | 업무에서 필요로하는 모든 데이터가 정의되어있어야 한다. |
| 중복배제 | 동일한 사실은 반드시 한번만 저장되어야한다. |
| 업무규칙 | 업무규칙이 데이터모델에 표현되어있어야 한다. |
| 데이터재사용 | 데이터가 재사용가능하도록 설계되어야 한다. |
| 의사소통 | 엔터티, 관계, 업무규칙 등이 정보시스템에 표현됨으로써 데이터 모델이 의사소통의 도구로서 사용된다. |
| 통합성 | 공유데이터를 여러 업무영역에서 공동으로 사용할 수 있도록 정의되어야 한다. |
💚엔터티 Entity
엔터티는 사람, 개념 등 명사에 해당하며, 업무상 관리가 필요한 관심사에 해당한다. 저장이 되기 위한 어떤 것(Thing) 이다.
엔터티와 인스턴스
인스턴스는 실제 객체(홍길동, 이순신)이고, 엔터티는 범주(사람)에 해당되는 것이다.
엔터티는 인스턴스의 집합이라고 말할 수 있다.
엔터티의 특징
- 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다.
- 유일한 식별자(PK)에 의해 식별이 가능해야한다.
- 두 개 이상의 인스턴스 집합이어야 한다. = 두 개 이상의 속성을 갖는다.
- 업무 프로세스에 의해 이용되어야 한다.
- 반드시 속성이 있어야 한다.
- 다른 엔터티와 최소 한 개 이상의 관계가 있어야 한다. 단, 통계성/코드성 엔터티는 관계를 생략할 수 있다.
- 객체지향의 싱글턴패턴처럼, 엔터티는 한개의 인스턴스를 가지는 것만으로 충분한 의미를 부여할 수 있다. (X)
엔터티의 분류
| 유/무형에 따른 분류 |
유형엔터티 | 물리적인 형태가 있는 엔터티 | 사원, 물품, 강사 |
| 개념엔터티 | 개념적으로 사용되는 엔터티 | 조직, 보험상품 | |
| 사건엔터티 | 업무를 수행함에 따라 발생되는 엔터티 | 주문, 청구, 미납 |
| 발생시점에 따른 분류 |
기본엔터티 | 업무에 원래 존재하는 정보로 독립 가능한 엔터티 | 사원, 부서, 고객 |
| 중심엔터티 | 업무로부터 발생되고 다른엔터티와 관계를 통해 행위 엔터티를 생성한다. | 계약, 청구, 주문 | |
| 행위엔터티 | 두 개 이상의 부모로부터 발생되고 자주 내용이 바뀌는 엔터티 | 주문목록, 사원변경이력 |
엔터티의 명명
- 현업업무에서 사용하는 용어로 사용
- 약어 사용 X
- 단수명사 사용
- 모든 엔터티에서 유일하게 이름 부여
- 엔터티 생성의미대로 이름 부여
💚속성 Attribute
업무에서 필요로 하는 인스턴스에서 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위
엔터티를 설명하고 인스턴스의 구성요소가 된다. ( 강사 엔터티의 속성 : 이름, 주소, 계약일자... )
한 개의 속성은 한 개의 속성값을 갖는다.
속성의 특징
- 엔터티와 마찬가지로 반드시 해당 업무에서 필요한 정보이어야 한다.
- 정해진 주식별자에 함수적 종속성을 가져야 한다.
- 한 속성은 한 개의 값만 가진다.
속성의 분류
| 특성에 따른 분류 |
기본 속성 | 업무에서 추출한 모든 속성. 인스턴스의 본래 속성 | 이름, 계좌번호, 이자율 |
| 설계 속성 | 데이터 모델링을 위해 만든 속성 (일련번호) | 상품코드, 지점코드 | |
| 파생 속성 | 계산되는 값 속성 | 합계, 평균, 이자 |
| 엔터티 구성방식에 따른 분류 |
PK 속성 | 엔터티를 식별할 수 있는 속성 | |
| FK 속성 | 다른 엔터티와의 관계를 나타내는 속성 | ||
| 일반 속성 | PK, FK가 아닌 속성 |
| 세부의미에 따른 분류 |
단순 속성 | 세부 의미로 쪼갤 수 없는 속성 | 시, 구, 동, 번지 |
| 복합 속성 | 세부 의미로 쪼갤 수 있는 속성 | 주소 |
| 개수에 따른 분류 |
단일값 속성 | 속성 하나에 한 개의 값을 가지는 속성 | |
| 다중값 속성 | 속성 하나에 다중 값을 가지는 속성 → 1차 정규화를 하거나, 별도의 엔터티를 만들어 관계로 연결하자. |
휴대전화번호가 2개인 사람 |
도메인 Domain
속성이 가질 수 있는 값의 범위
속성의 명명
- 해당 업무에서 사용하는 이름을 부여한다.
- 서술식 속성명은 사용하지 않는다. 명사형 속성명을 사용한다.
- 약어사용은 가급적 제한한다.
- 전체 데이터모델에서 유일성 확보하는 것이 좋다.
- 직원 엔터티의 이름, 고객 엔터티의 이름과 같이 각 엔터티별로 동일한 속성명을 사용하여 데이터 모델의 일관성을 가져가는 것이 좋다. (X)
💚관계 Relationship
인스턴스 사이의 논리적인 연관성으로서 존재의 형태로서나 행위로서 서로에게 연관성이 부여된 상태
엔터티가 인스턴스의 집합을 논리적으로 표현한것과 동일하게 관계는 관계 페어링의 집합을 논리적으로 표현한 것이다.
관계 페어링
엔터티 안의 인스턴스가 개별적으로 관계를 가지는 것
관계의 분류
| 존재에 따른 분류 | 엔터티 간의 상태를 의미한다. ERD에서는 존재/행위에 따른 표기 구분 없다. UML에서는 연간관계에 해당되며 실선으로 표현한다. |
소속한다 |
| 행위에 따른 분류 | 엔터티 간의 행위를 의미한다. ERD에서는 존재/행위에 따른 표기 구분 없다. UML에서는 의존관계에 해당되며 점선으로 표현한다. |
주문한다 |
관계의 표기법
| 관계명 Membership |
관계의 이름. 각각의 관계는 두 개의 관계명을 가지고 있다. [ 부서(포함한다) - 사원(소속된다) ] 관계명은 능동적이거나 수동적으로 명명된다. 과거/미래형이 아닌 현재형으로 표현한다. (수강신청했다(X), 수강신청한다(O) ) |
| 관계차수 Deegree Cardinality |
관계의 참여자 수. 1:1, 1:M, M:N로 표한다. |
| 관계선택사양 Optionality |
관계의 필수/선택관계를 표현한다. 필수참여관계는 엔터티끼리 필수적으로 연결되어야 하는 관계이다. 선택참여관계는 엔터티끼리 선택적으로 연결되어야 하는 관계이다. |
관계 정의 시 체크사항
- 두 엔터티 사이에 관심있는 연관규칙이 존재하는가?
- 두 엔터티 사이에 정보의 조합이 발생되는가?
- 업무기술서, 장표에 관계 연결에 대한 규칙이 서술되어 있는가?
- 업무기술서, 장표에 관계 연결을 가능하게 하는 동사(Verb)가 있는가? 명사(Noun) (X)
💚식별자 Identifiers
엔터티를 대표할 수 있는 속성을 의미한다.
하나의 엔터티는 반드시 하나의 유일한 식별자가 존재해야한다.
주식별자의 특징
| 유일성 | 모든 인스턴스들이 주식별자로 유일하게 구분되어야 한다. | 이름은 동명이인이 있을 수 있다. 사원번호 부여 |
| 최소성 | 주식별자를 구성하는 속성은 최소의 수가 되어야 한다. | 사원번호로도 구분가능한데 사원번호+이름으로 구성될 필요 없음 |
| 불변성 | 주식별자의 값은 자주 변하지 않는 것이어야 한다. | 사원번호는 변경되면 안된다. |
| 존재성 | 주식별자가 지정되면 반드시 값이 들어와야 한다. | 사원번호가 없는 직원은 있을 수 없다. |
식별자 분류
| 대표성 여부 | 주식별자 | 유일성O, 최소성O, 대표성O : 모두 만족하는 식별자 | 사원번호 |
| 보조식별자 | 유일성O, 최소성O, 대표성X : 대표성만 만족하지 않는 식별자 | 주민번호 | |
| 스스로 생성 여부 |
내부식별자 | 엔터티 내부에서 스스로 만들어지는 식별자 | |
| 외부식별자 | 타 엔터티와의 관계로 받아오는 식별자 | ||
| 속성의 수 | 단일식별자 | 하나의 속성으로 구성된 식별자 | 사원번호 |
| 복합식별자 | 둘 이상 속성으로 구성된 식별자 | 이름+주민번호 | |
| 대체 여부 | 본질식별자 | 업무에 의해 만들어지는 식별자 | |
| 인조식별자 | 원조식별자가 복잡하여 인위적으로 만든 식별자 | 사원번호 |
주식별자 도출기준
- 해당 업무에서 자주 이용되는 속성으로 지정한다.
- 명칭, 내역과 같이 이름으로 기술되는 것은 가능하면 지정하지 않는다. (명칭이 길어질 경우 처리가 느려진다)
- 복합 속성인 경우, 너무 많은 속성이 포함되지 않도록 한다.
식별자/비식별자 관계
| 식별자관계 | 비식별자관계 | |
| 목적 | 강한 연결관계를 표현한다. | 약한 연결관계를 표현한다. |
| 부모에게 물려받은 식별자 |
부모로부터 받은 식별자를 자식엔터티에서 주식별자로 이용하는 경우 = 부모엔터티가 생성되어야 자식엔터티가 생성된다. (발령 엔터티는 반드시 사원 엔터티가 있어야 생성될 수 있다) |
부모로부터 받은 식별자를 자식엔터티에서 주식별자로 이용하지 않고 일반속성으로 이용하는 경우 = 부모엔터티가 없어도 된다. |
| 식별자/비식별자로만 구성할 경우 |
여러 부모의 식별자를 받을 경우, 주식별자의 개수가 많아지게된다. = 개발 시 복잡해지고 오류가능성이 높아진다. EX. 엔터티명(PK) ParentA(AA) → ParentB(AA, BB) → ParentC(AA, BB, CC) → ME(AA, BB, CC, MM, MM) |
자주 조회하는 주식별자를 일반속성으로 두면 자식엔터티에서 데이터를 처리할 때, 쓸데없이 부모엔터티까지 찾아가야하는 경우가 발생한다. EX. 엔터티명(PK) / C에서 점검번호='301' 데이터 조회 where A.분야번호 = B.분야번호 AND B.점검번호 = C.점검번호 AND C.점검번호 = '105' |
| 표기법 | 실선 | 점선 |
| 식별자/비식별자 관계를 선택해야 하는 경우 |
- 강한 관계인 경우 - 자식테이블에서 종속적인 주식별자를 원할 경우 - 부모테이블의 식별자를 계속 상속할 경우 - 엔터티별로 생명주기를 동일하게 관리할 경우 |
- 약한 관계인 경우 - 자식테이블에서 독립적인 주식별자를 원할 경우 - 부모테이블의 식별자를 상속받지 않을 경우 - 엔터티별로 생명주기를 다르게 관리할 경우 - SQL문장의 복잡성이 증가하는 경우 |
💚ERD IE 표기법 vs Barker 표기법
ERD(Entity Relationship Diagram)은 서로 다른 엔터티들과의 관계를 직관적으로 표현하는 수단이다.
ERD의 구성요소는 엔터티, 관계, 속성 3가지 이다.
표기 읽는 방법
| IE 표기법 | 부서는 0명 or 1명 or n명 이상의 사원들로 구성되어있다. | (표기를 위해서 점선, 실선 혼합했지만 있을 수 없다. 점선만쓰거나 실선만 사용해야한다.) |
| 사원은 1개의 부서를 갖는다. |
||
| Barker 표기법 |
부서는 1명 이상의 사원들로 구성되어있다. |
(식별관계이므로 #사원번호가 부서테이블에 PK로 있어야한다) |
| 사원은 부서가 없을 수 있다. |
(잊지말자. 식별/비식별관계는 엔터티의 기본키를 확인해야 알 수 있다!!)
(표기법 표시에 집중했으니 의미의 옳고 그름은 잠시 접어두자)
