겨울방학에 자격증을 딸 생각으로 yes24에서 ebook을 구매하였다.
준비중인 자격증은 ADsP와 SQLD로 만만하면서 그렇다고 완전히 만만하지는 않은 자격증들이다.
SQLD를 도전하는 내 입장에서는 비전공자라고 하기도 애매하고 전공자라고도 하기가 참 애매하다.
일단 데이터베이스 관련 과목이 전공수업에는 있지만 아직 수강전이며,
학점은행 진행 당시에 데이터베이스 과목을 수강하기는 했으나, 해 본 사람은 다 알겠지만 거의 강의를 틀어놓기만 한 수준이라서 수료했다고 말하기는 참 그렇다.
단어들을 좀 아는 정도라고 할 수 있겠는데, 1주일 합격신화, 3일 합격신화는 내 이야기가 절대 아님을 확신할 수 있다.
넉넉하게 잡고 공부하려는데 직장병행까지 하려니 영 쉽지가 않다.
노랑이 책이 가장 유명한 것 같으나 기본 베이스가 없다시피 한 나로서는 유선배 책이 맞는 것 같았다.
유튜브에서 홍쌤 강의를 들으려고 교안도 구매했는데 1강을 들어보니 유선배로 전체적인 이론틀을 잡고 나서 듣는 것이 더 도움이 될 것 같아서 일정을 뒤로 미뤘다.
유선배 이론서를 쭉 훒으면서 문제를 풀어보고 틀린 문제들에 관한 이론을 정리하면서 공부할 계획이다.
1. 엔터티(Entity)란?
- 식별이 가능한 객체라는 의미
- 엔터티는 명확한 조건이 기준이 되어야 한다.
2. 엔터티의 특징
1) 업무에서 쓰이는 정보여야 한다.
2) 유니크함을 보장할 수 있는 식별자가 있어야 한다.
3) 2개 이상의 인스턴스를 가지고 있어야 한다.
4) 반드시 속성을 가지고 있어야 한다.
5) 다른 엔터티와 1개 이상의 관계를 가지고 있어야 한다.
3. 엔터티의 분류
1) 유형 VS 무형
| 무형 엔터티 | 물리적인 형태 존재 예) 상품, 회원 등 |
| 개념 엔터티 | 물리적인 형태 없음 예) 부서, 학과 등 |
| 사건 엔터티 | 행위를 함으로써 발생 예) 주문, 이벤트 응모 등 |
2) 발생시점
| 기본 엔터티 | 독립적으로 생성되며, 자식 엔터티를 가질 수 있음 업무에 원래 존재하는 정보 예) 상품, 회원, 사원, 부서 등 |
| 중심 엔터티 | 기본 엔터티로부터 파생되고, 행위 엔터티 생성 업무에 있어서 중심적인 역할을 하며 데이터의 양이 많이 발생 예) 주문, 매출, 계약 등 |
| 행위 엔터티 | 2개 이상의 엔터티로부터 파생 데이터가 자주 변경되거나 증가할 수 있음 예) 주문내역, 이벤트 응모 이력 등 |
4. 엔터티의 이름을 정할 때 주의할 점
- 업무에서 실제로 쓰이는 용어 사용
- 한글은 약어를 사용하지 않고 영문은 대문자로 표기
- 단수 명사로 표현하고 띄어쓰기는 하지 않음
- 다른 엔터티와 의미상으로 중복될 수 없음(주문, 결제 엔터티는 중복될 수 있음)
- 해당 엔터티가 갖고 있는 데이터가 무엇인지 명확하게 표현
5. 속성의 특성에 따른 분류
| 기본속성 | 업무 프로세스 분석을 통해 바로 정의가 가능한 속성 |
| 설계속성 | 업무에 존재하지는 않지만 설계하다 보니 필요하다고 판단되어 도출해낸 속성 예) 학번 |
| 파생속성 | 다른 속성의 속성값을 계산하거나 특정한 규칙으로 변형하여 생성한 속성 예) 상품의 구매 수량 |
6. 도메인 : 속성이 가질 수 있는 속성값의 범위
7. 용어사전 : 엔터티의 속성명을 정의할 때 명확한 의미의 이름을 부여하고 다른 엔터티와의 혼란을 예방하기 위해 이용하는 것
※ 복합식별자와 인조식별자의 차이
| 구분 | 복합식별자 (Composite Key) | 인조식별자 (Surrogate Key) |
| 구성 방식 | 둘 이상의 속성을 조합하여 고유성 보장 | 자동 생성된 단일 속성을 사용 |
| 데이터와의 관계 | 데이터 속성과 직접 관련 있음 | 데이터 속성과 무관, 인위적으로 생성 |
| 복잡성 | 복잡 (여러 속성을 조합해야 함) | 단순 (단일 속성으로 관리) |
| 사용 사례 | 교차 테이블, 데이터 자체로 고유성 필요 | 대부분의 테이블, 성능 최적화 필요시 |
| 예시 | (학생ID, 수업ID) 가 학생이 속한 특정 수업을 고유하게 식별할 때 | CutomerID, OrderID 처럼 자동으로 생성되는 숫자 ID |
8. 데이터 모델링을 할 때 지양해야 할 점
| 중복 (Duplication) |
같은 데이터가 여러 엔터티에 중복으로 저장되는 현상을 지양해야 한다. |
| 비유연성 (Inflexibility) |
애플리케이션과 데이터 간의 연계성이 높으면 애플리케이션이 변경될 때마다 데이터 모델도 변경되어야 하는 상황이 생길 수 있다. 이런 상황은 시스템을 유지보수하는 데에 어려움을 가중시키므로 데이터 모델과 프로세스를 분리하여 유연성을 높이는 것이 바람직하다. |
| 비일관성 (Inconsistency) |
데이터의 중복이 없는 경우에도 비일관성이 발생할 수 있다. 개발자가 다른 데이터와의 경관성을 고려하지 않고 일부 데이터만 변경할 수 있기 때문이다. 이런 위험을 예방하기 위해 데이터 모델링을 할때 데이터 간의 연관 관계에 대해 명확하게 정의해야 한다. |
9. ERD 작성 순서
1) 엔터티를 그린다
2) 엔테티를 적절하게 배치한다
3) 엔터티 간의 관계를 나타낸다
4) 관계명을 정의한다
5) 관계의 참여도를 나타낸다
6) 관계의 필수 여부를 나타낸다
10. 관계차수 : 1:1, 1:M, M:N 과 같은 관계의 기수성을 나타낸다.
11. 관계선택사양 : 관계가 필수 관계인지, 선택 관계인지를 나타낸다.
12. 엔터티 간의 관계를 정의할 때 고려해야할 사항
엔터티 간의 관계에는 부모-자식의 관계 외에 다른 관계도 존재할 수 있다.
존재 관계 : 엄마와 아기처럼 존재 자체로 연관성 있는 관계 (예 : 직원과 부서, 학생과 학과)
행위 관계 : 특정한 행위를 함으로써 연관성이 생기는 관계 (예 : 회원과 주문, 학생과 출석부)
12. 식별자
인조식별자(대리식별자) : 주식별자의 속성이 두 개 이상인 경우 그 속성들을 하나로 묶에서 사용하는 식별자
복합식별자 : 두 개 이상의 속성으로 구성된 식별자
보조식별자 : 인스턴스를 식별할 수 있지만 대표 식별자가 아님. 다른 엔터티와 참조관계로 연결되지 않음.
외부식별자 : 다른 엔터티에서 온 식벌자. 다른 엔터티와의 연결고리 역할.