SQLD 1-1 요약

yoon·2023년 8월 3일

SQLD

목록 보기
1/7
post-thumbnail

정미나, "유선배 SQL 개발자(SQLD) 과외노트", 시대고시기획
해당 책을 바탕으로 작성하였습니다.

그냥 개인적으로 다시 보고 공부하려고 만들었습니다.😀

데이터 모델의 이해

모델링이란?

현실 세계를 단순화하여 표현하는 기법.

모델링의 특징 3가지

보기
- 단순화 : 복잡한 현실 세계를 정해진 표기법으로 단순하고 쉽게 표현.
- 명확화 : 불분명함을 제거하고 명확하게 해석할 수 있도록 기술.
- 추상화 : 현실 세계를 일정한 형식으로 표현.

모델링의 3가지 관점

보기
- 데이터 관점 : 어떤 데이터들이 업무와 얽혀있는지, 데이터 간에는 어떤 관계가 있는지에 대해 모델링.
- 프로세스 관점 : 실제로 처리하고 있는 일은 무엇인지, 앞으로 처리해야 할 일은 무엇인지를 모델링.
- 데이터와 프로세스의 상관 관점 : 프로세스의 흐름에 따라 데이터가 어떤 영향을 받는지를 모델링.

모델링의 세 가지 단계

보기
1. 개념적 데이터 모델링
- 추상화 레벨이 가장 높은 모델링. 업무 중심적, 포괄적 수준의 모델링이 진행.
2. 논리적 데이터 모델링
- 재사용성이 가장 높은 모델링. DB 모델에 대한 Key, 속성, 관계 등을 모두 표현하는 단계.
3. 물리적 데이터 모델링
- 실제 DB로 구현 가능하도록 성능이나 가용성 등의 물리적인 성격을 고려하여 모델을 표현하는 단계.

데이터 모델링 시 주의점

보기
- 중복 : 같은 데이터가 여러 엔티티에 중복으로 저장되는 현상을 지양.
- 비유연성 : 데이터 모델의 설계에 따라 애플리케이션의 사소한 변경에도 데이터 모델이 수시로 변경되어야 하는 상황이 생길 수 있음. 이런 상황은 시스템을 유지보수하는 데 어려움을 가중시키므로 데이터 모델과 프로세스를 분리하여 유연성을 높이는 것이 바람직하다.
- 비일관성 : 데이터의 중복이 없는 경우에도 발생. 개발자가 다른 데이터와의 연관성을 고려하지 않고 일부 데이터만 변경할 수 있기 때문. 이런 위험을 예방하기 위해 데이터 모델링을 할 때 데이터 간의 연관 관계에 대해 명확하게 정의.

데이터의 독립성

3단계 스키마 구조

보기
출처 : https://en.wikipedia.org/wiki/ANSI-SPARC_Architecture

- 외부 스키마
사용자의 관점 : 각 사용자가 보는 DB의 스키마를 정의.
- 개념 스키마
통합된 관점 : 모든 사용자가 보는 DB의 스키마를 통합하여 전체 DB를 나타내는 것.
- 내부 스키마
물리적인 관점 : 물리적인 저장 구조. 컬럼 정의, 인덱스 등.

3단계 스키마 구조의 이유 및 보장하는 독립성

보기
DB에 대한 사용자들의 관점과 DB가 실제로 표현되는 물리적인 방식을 분리하여 독립성을 보장하기 위해.
- 논리적 독립성 : 개념 스키마가 변경되어도 외부 스키마는 영향 X.
- 물리적 독립성 : 내부 스키마가 변경되어도 외부/개념 스키마는 영향 X.

ERD(Entity Relationship Diagram)

시스템에 어떤 엔티티들이 존재하며 그들 간에 어떤 관계가 있는지를 나타내는 다이어그램

IE/Crow's Foot 표기법

보기

ERD 작성 순서

보기
1. 엔티티를 도출하고 그림.
2. 엔티티를 적절하게 배치.
3. 엔티티 간의 관계 설정.
4. 관계명 기입.
5. 관계의 참여도 기입.
6. 관계의 필수/선택 여부 기입.

Entity

Entity란?

데이터를 용도별로 분류한 그룹.

Entity의 특징

보기
- 업무에서 쓰이는 정보여야 함.
- 유일함을 보장할 수 있는 식별자 필요.
- 2개 이상의 인스턴스를 가지고 있어야 함.
- 반드시 속성을 가지고 있어야 함.
- 다른 엔티티와 1개 이상의 관계를 가지고 있어야 함.

Entity의 분류

  1. 유형 / 무형

    보기
    - 유형 엔티티 : 물리적인 형태 존재, 안정적, 지속적(상품, 회원)
    - 개념 엔티티 : 물리적인 형태 없음, 개념적(부서, 학과)
    - 사건 엔티티 : 행위를 함으로써 발생, 빈번, 통계 자료로 이용 가능(주문, 응모)
  2. 발생시점

    보기
    - 기본 엔티티 : 독립적으로 생성, 자식 엔티티 가능(상품, 회원)
    - 중심 엔티티 : 기본 엔티티로부터 파생, 행위 엔티티 생성(주문)
    - 행위 엔티티 : 2개 이상의 엔티티로부터 파생(주문 내역, 이벤트 응모 이력)

엔티티의 이름을 정할 때 주의할 점

보기
- 업무에서 실제로 쓰이는 용어 사용.
- 한글은 약어 사용 X, 영어는 대문자로 표기.
- 단수 명사로 표현, 띄어쓰기 X.
- 다른 엔티티와 의미상으로 중복 X.
- 해당 엔티티가 갖고 있는 데이터가 무엇인지 명확하게 표현.

속성(Attribute)

속성이란?

의미상 더 이상 쪼개지지 않는 레벨이어야 하고 프로세스에 필요한 항목이어야 함.

속성값

하나의 속성은 한 개의 속성값만 가질 수 있다. 만약 여러 개의 속성값을 갖는 경우에는 별도의 엔티티로 분리하는 것이 좋다.

엔티티, 인스턴스, 속성, 속성값의 관계

  • 한 개의 엔티티는 ? 개 이상의 인스턴스를 갖는다.
  • 한 개의 인스턴스는 ? 개 이상의 속성을 갖는다.
  • 한 개의 속성은 ? 개의 속성값을 갖는다. 보기
    2, 2, 1

분류

특성에 따른 분류

보기
- 기본속성 : 업무 프로세스 분석을 통해 바로 정의가 가능한 속성. 엔티티의 가장 많은 퍼센티지를 차지, 일부 설계 속성과 파생 속성을 제외한 모든 속성이 기본 속성에 해당.
- 설계속성 : 업무에 존재하지는 않지만 설계 과정에서 합리적인 모델링을 위해 만들어진 속성(예: 동명이인을 학번으로 유일함 보장).
- 파생속성 : 다른 속성으로부터 파생된 속성을 의미. 계산된 값이나 가공된 값(예: 상품 재고, 좋아요 수).

구성방식에 따른 분류

보기
- PK(Primary Key) 속성 : 엔티티의 인스턴스들을 식별할 수 있는 속성.
- FK(Foreign Key) 속성 : 다른 엔티티의 속성에서 가져온 속성. 다른 엔티티와 관계를 맺게 함. NULL 값 가능.
- 일반 속성 : PK, FK를 제외한 나머지 속성.

도메인?

보기
속성이 가질 수 있는 속성값의 범위. 엔티티를 정의할 때 데이터 타입과 크기로 나타낼 수 있다.

관계(Relationship)

관계란?

엔티티와 엔티티의 관계를 의미. 존재 관계와 행위 관계로 나눌 수 있음.

존재 관계

보기
- 존재 자체로 연관성이 있는 관계. 예를 들어 직원 / 부서, 학생 / 학과 등.

행위 관계

보기
- 특정한 행위를 함으로써 연관성이 생기는 관계. 예를 들어 회원 / 주문, 학생 / 출석부 등.

표기법

보기
- 관계명 : 관계의 이름. 모든 관계는 두 개의 관계명을 가짐. 각 엔티티 관점이 있기 때문. 관계명은 반드시 명확한 문장, 그리고 현재형으로 표현.
- 관계차수 : 관계에 참여하는 수. 1:1, 1:M, M:N 형식이 있음.
- 관계선택사양 : 필수인지 선택인지의 여부.

식별자

식별자란?

속성 중 인스턴스를 구분 가능하게 만들어주는 대표 속성을 의미.

주식별자

PK에 해당하는 속성. 여러 개의 속성이 주식별자가 될 수도 있다.

특징

보기
- 유일성 : 각 인스턴스에 유일함을 부여하여 식별 가능하게 함.
- 최소성 : 유일성을 보장하는 최소 개수의 속성이어야 함.
- 불변성 : 속성값이 되도록 변하지 않아야 함.
- 존재성 : NULL일 수 없다.

분류

4개의 분류 기준

보기
- 대표성 여부
> 주식별자 : 대표 식별자. 다른 엔티티와 참조 관계로 연결.
> 보조식별자 : 인스턴스를 식별할 수는 있지만 대표 식별자 X. 다른 엔티티와 참조 관계로 연결 X.

- 스스로 생성되었는지 여부
> 내부식별자 : 엔티티 내부에서 스스로 생성된 식별자.
> 외부식별자 : 다른 엔티티에서 온 식별자. 다른 엔티티와 연결고리 역할.

- 단일 속성의 여부
> 단일식별자 : 하나의 속성으로 구성된 식별자
> 복합식별자 : 두 개 이상의 속성으로 구성된 식별자

- 대체 여부
> 원조식별자 : 업무 프로세스에 존재하는 식별자. 가공되지 않은 원래의 식별자(본질식별자).
> 대리식별자 : 주식별자의 속성이 두 개 이상인 경우 그 속성들을 하나로 묶어서 사용하는 식별자(인조식별자).

식별자 관계

보기
부모 엔티티의 식별자가 자식 엔티티의 주식별자가 되는 관계. 주식별자는 반드시 존재해야하므로(존재성) 부모 엔티티가 있어야 생성 가능. 단일, 복합 식별자인지에 따라 1:1, 1:M이 결정.

비식별자 관계

보기
부모 엔티티의 식별자가 자식 엔티티의 주식별자가 아닌 일반 속성이 되는 관계. 일반 속성의 값은 NULL이 될 수 있으므로 부모 엔티티가 없는 자식 엔티티 생성 가능. 자식 엔티티가 존재하는 상태에서 부모 엔티티 삭제 가능.
profile
문제 정의 - 이유 분석 - 해결 방안 모색 - 실행

1개의 댓글

comment-user-thumbnail
2023년 8월 3일

접기 펼치기 기능이 안 된다니..

답글 달기