2023 유선배 SQL개발자(SQLD) 과외노트를 읽고 내용을 정리한 글입니다.
2023 유선배 SQL개발자(SQLD) 과외노트 - YES24
SQL Server 분야 베스트 1위!핵심만 쏙쏙 담은 알찬 수험서! SD에듀가 가장 효율적·효과적인 합격의 길을 제안합니다.유튜브 선생님에게 배우는 유·선·배, 『유선배 SQL개발자 과외노트』와 함께 20
www.yes24.com
데이터 모델의 이해
모델링(Modeling)
: 현실 세계를 단순화하여 표현하는 기법
- 현실 세계에서 필요한 데이터를 저장하는 데이터베이스를 구축하기 위한 분석/설계의 과정
- 모델(Model)
: 현실 세계에서 일어날 수 있는 다양한 현상에 대해서 일정한 표기법에 의해 표현해 놓은 모형- 모델링은 모델을 만들어가는 일
모델링이 갖춰야 할 조건
- 현실세계를 반영해야 한다.
- 단순화하여 표현해야 한다.
- 관리하고자 하는 데이터를 모델로 설계한다.
모델링의 특징
- 추상화(Abstraction)
: 현실 세계를 일정한 형식으로 표현하는 것
아이디어나 개념을 간략하게 표현하는 과정 - 단순화(Simplification)
: 복잡한 현실 세계를 정해진 표기법으로 단순하고 쉽게 표현한다는 의미 - 명확화(Claritiy)
: 불분명함을 제거하고 명확하게 해석할 수 있도록 기술한다는 의미
- 데이터베이스의 모델링은 현실세계를 추상화, 단순화, 명확화하기 위해 일정한 표기법에 의해 표현하는 기법이다.
모델링의 세 가지 관점
- 데이터 관점(What, Data)
: 데이터 위주의 모델링
어떤 데이터들이 업무와 얽혀있는지, 그 데이터 간에는 어떤 관계가 있는지에 대해서 모델링하는 방법 - 프로세스 관점(How, Process)
: 데이터와 프로세스의 관계를 위주로 한 모델링
이 업무가 실제로 처리하고 있는 일은 무엇인지 또는 앞으로 처리해야 하는 일은 무엇인지 또는 앞으로 처리해야 하는 일은 무엇인지를 모델링하는 방법 - 데이터와 프로세스의 상관 관점(Data vs. Process, Interaction)
: 데이터와 프로세스의 관계를 위주로 한 모델링
프로세스의 흐름에 따라 데이터가 어떤 영향을 받는지를 모델링하는 방법
모델링의 세 가지 단계
- 개념적 데이터 모델링(Comceptual Data Modeling)
: 전사적 데이터 모델링 수행 시 행해지며 추상화 레벨이 가장 높은 모델링
업무 중심적이고 포괄적인 수준의 모델링이 진행됨 - 논리적 데이터 모델링(Logical Data Modeling)
: 데이터베이스 모델에 대한 Key, 속성, 관계 등을 모두 표현하는 단계
- 재사용성이 가장 높은 모델링 - 물리적 데이터 모델링(Physical Data Modeling)
: 실제 데이터베이스로 구현할 수 있도록 성능이나 가용성 등의 물리적인 성격을 고려하여 모델을 표현하는 단계
데이터의 독립성
- 데이터베이스가 존재하는 목적 중 하나는 사용자에게 데이터를 보여줄 수 있는 뷰를 제공하는 것이다.
- 하지만 사용자 입장에서는 필요한 데이터만 볼 수 있으면 되고, 데이터베이스의 내부 구조에 대해서는 굳이 알 필요가 없다.
- DBA의 입장에서는 어플리케이션에 영향을 주지 않고 데이터베이스의 구조를 변경할 수 있어야 독립성이 보장된다고 할 수 있다.
3단계 스키마 구조
- 외부 스키마(External Schema)
: View 단계로 여러 개의 사용자 관점으로 구성되는 것
- 사용자의 관점 : Multiple User`s View 단계로 각 사용자가 보는 데이터베이스의 스키마를 정의한다. - 개념 스키마(Conceptual Schema)
: 모든 사용자 관점을 통합한 조직 전체 관점의 통합적인 표현
- 통합된 관점 : Community View of DB 단계로 모든 사용자가 보는 데이터베이스의 스키마를 통합하여 전체 데이터베이스를 나타내는 것이다. 데이터베이스에 저장되는 데이터들을 표현하고 데이터들 간의 관계를 나타낸다. - 내부 스키마(Internal Schema)
: 물리적인 저장 구조를 나타내는 것
물리적인 관점 : Physical Representation 단계로 물리적인 저장 구조를 나타낸다. 실질적인 데이터의 저장 구조나 컬럼 정의, 인덱스 등이 포함된다.
3단계 스키마 구조가 보장하는 독립성
- 논리적 독립성
: 개념 스키마가 변경되어도 외부 스키마는 영향받지 않는다. - 물리적 독립성
: 내부 스키마가 변경되어도 외부/개념 스키마는 영향받지 않는다.
ERD(Entity Relationship Diagram)
ERD 표기방식
: 시스템에 어떤 엔티티들이 존재하며 그들 간에 어떤 관계가 있는지를 나타내는 다이어그램
IE/Crow's 표기법
ERD 작성 순서
- 엔티티를 도출하고 그린다.
- 엔티티를 적절하게 배치한다.
- 엔티티 간의 관계를 설정한다.
- 관계명을 기입한다.
- 관계의 참여도를 기입한다.
- 관계의 필수/선택 여부를 기입한다.
엔티티(Entity)
엔티티
: 사전적 의미는 '독립체'
- 데이터베이스에서 엔티티는 식별이 가능한 객체라는 의미
- 쉽게 말해서, 업무에서 쓰이는 데이터를 용도별로 분류한 그룹
속성(Attribute)
- 각각의 엔티티는 자신을 더 상세하게 나타내기 위한 속성을 갖게 된다.
- 속성의 개수는 엔티티마다 상이해서 용도에 따라 매우 많을 수도 있고 매우 적을 수도 있다.
- ex)
'회원' 엔티티의 속성 : '아이디'. '비밀번호', '이름' 등
'상품' 엔티티의 속성 : '상품코드', '상품명', '카테고리' 등 - 만약, 상품 엔티티에 '새우깡', '자갈치' 라는 상품이 있다고 가정한다면 각각은 상품 엔티티의 인스턴스가 된다.
| Tip |
| 엔티티 : Table |
| 인스턴스 : Row |
| 속성 : Column |
엔티티의 특징
- 업무에서 쓰이는 정보여야 한다.
- 유니크함을 보장할 수 있는 식별자가 있어야 한다.
- 2개 이상의 인스턴스를 가지고 있어야 한다.
- 반드시 속성을 가지고 있어야 한다.
- 다른 엔티티와 1개 이상의 관계를 가지고 있어야 한다.
엔티티의 분류
유형 vs.무형 분류
- 유형 엔티티
: 물리적인 형태 존재, 안정적, 지속적,
- 상품, 회원
- 개념 엔티티
: 물리적인 형태 없음, 개념적- 부서, 학과
- 사건 엔티티
: 행위를 함으로써 발생, 빈번함, 통계 자료로 이용 가능- 주문, 이벤트 응모
발생시점에 따른 분류
- 기본 엔티티
: 독립적으로 생성되고, 자식 엔티티를 가질 수 있음- 상품, 회원, 사원, 부서
- 중심 엔티티
: 기본 엔티티로부터 파생, 행위 엔티티 생성- 주문
- 행위 엔티티
: 2개 이상의 엔티티로부터 파생- 주문 내역, 이벤트 응모 이력
속성(Attribute)
속성
: 사물이나 개념의 특징을 설명해줄 수 있는 항목들 , 엔티티의 특징을 나타내는 최소의 데이터 단위
- 속성은 의미상 더 이상 쪼개지지 않는 레벨이어야 하고, 프로세스에 필요한 항목이어야 한다.
- 어떤 속성이 업무상 불필요한 데이터라고 판단되면 해당 속성은 삭제하는 것이 바람직하다.
- ex) 아티스트 엔티티의 속성 : 이름, 생년월일, 데뷔년도, 소속사 등
속성값
: 각각의 속성은 속성값을 가지며 속성값은 엔티티에 속한 하나의 인스턴스를 구체적으로 나타내주는 데이터
- 하나의 속성은 한 개의 속성값만 가질 수 있다.
- 만약 하나의 속성이 여러 개의 속성값을 갖는 경우 별도의 엔티티로 분리하는 것이 바람직하다.
| 속성 | 속성값 |
| 이름 | 이지은 |
| 생년월일 | 19930516 |
| 소속서 | EDAM엔터테인먼트 |
엔티티, 인스턴스, 속성, 속성값의 관계
- 한 개의 엔티티는 두 개 이상의 인스턴스를 갖는다.
- 한 개의 인스턴스는 두 개 이상의 속성을 갖는다.
- 한 개의 속성은 하나의 속성값을 갖는다.
속성의 분류
특성에 따른 분류
- 기본속성
: 엔티티의 가장 일반적인 속성, 업무 프로세스 분석을 통해 바로 정의가 가능한 속성들- 엔티티의 가장 많은 퍼센티지를 차지하는 속성
- 일부 설계 속성과 파생속성을 제외한 모든 속성이 기본 속성에 해당한다.
- 설계속성 : 업무에 존재하지는 않지만, 설계 과정에서 합리적인 모델링을 위해 만들어진 속성
- 학번
- 파생속성 : 다른 속성으로부터 파생된 속성, 계산된 값이나 가공된 값이 해당
- 반드시 데이터의 정합성이 고려되어야 하고 계산 과정에서 누락되는 데이터가 생기는 경우 결과값이 엉터리가 될 수 있는 위험 요소가 존재하기 때문에 불가피하게 필요한 경우에만 정의하는 것이 바람직하다.
- 미리 상품의 구매 수량을 구한 다음 재고를 계산하여 속성으로 가지고 있는 것
구성방식에 따른 분류
- PK(Primary Key) 속성
: 엔티티의 인스턴스들을 식별할 수 있는 속성- 회원번호, 상품코드, 학번, 사번 등
- FK(Foreign Key) 속성
: 다른 엔티티의 속성에서 가져온 속성, 다른 엔티티와 관계를 맺게 해주는 매개체 역할을 하는 속성- 회원등급코드, 학과코드, 부서코드 등
- 일반 속성
: PK, FK를 제외한 나머지 속성- 상품명, 가격, 이름, 생년월일 등
도메인(Domain)
: 속성이 가질 수 있는 속성값의 범위
- 우편번호는 다섯자리의 숫자라는 범위를 가지고 있고, 엔티티를 정의할 때 데이터 타입과 크기로 나타낼 수 있다.
관계(Relationship)
관계
: 엔티티와 엔티티와의 관계를 의미하며, 어떠한 연관성이 있는지 타입을 분류하여 존재 관계와 행위 관계로 나눌 수 있다.
존재 관계
: 엄마와 아기처럼 존재 자체로 연관성이 있는 관계를 의미
- 직원과 부서, 학생과 학과 등
행위 관계
: 특정한 행위를 함으로써 연관성이 생기는 관계
- 회원과 주문, 학생과 출석부 등
표기법
관계명(Membership)
: 관계의 이름
- 엔티티와 엔티티가 어떤 관계를 맺고 있는지를 나타내주는 문장이다.
- 모든 관계는 두 개의 관계명을 가지고 있는데 이유는 각 엔티티의 관점에서 관계명을 하나씩 가지기 때문이다.
- 관계명은 반드시 명확한 문장으로 표현해야 하며 현재형이어야 한다 ( ex. 주문한다, 소속된다, 출석을한다)
관계차수(Cardinality)
: 관계에 참여하는 수
- 각 엔티티에서 관계에 참여하는 수를 의미하며 일반적으로 1:1, 1:M, M:N 형식으로 구분할 수 있다.
관계선택사양(Optionality)
: 필수인지 선택인지의 여부
- 이 관계가 필수요소인지 선택사항인지를 나타내는 말
- 주문은 반드시 하나 이상의 주문상품이 있어야 하기 때문에 주문과 주문상품의 관계는 필수
- 학생이 강의에 출석을 할지 말지는 학생의 선택사항이므로 학생과 출석부 엔티티의 관계는 선택
식별자(Identifiers)
식별자
: 모든 엔티티는 인스턴스를 가지고 있고, 인스턴스는 속성으로 자신의 특성을 나타내는데, 식별자는 이런 속성 중에 각각의 인스턴스를 구분 가능하게 만들어주는 대표 격인 속성을 의미한다.
주식별자
: 기본키, PK에 해당하는 속성
- 하나의 속성이 주식별자가 될 수도 있고, 여러 개의 속성이 주식별자가 될 수도 있다.
- 유일성, 최소성, 불변성, 존재성 만족해야 한다.
식별자 분류
대표성 여부
- 주식별자
- 유일성, 최소성, 불변성, 존재성을 가진 대표 식별자
- 다른 엔티티와 참조 관계로 연결
- 보조식별자
- 인스턴스를 식별할 수 있지만 대표 식별자가 아님
- 다른 엔티티와 참조 관계로 연결
스스로 생성되었는지 여부
- 내부식별자
- 엔티티 내부에서 스스로 생성된 식별자
- 외부식별자
- 다른 엔티티에서 온 식별자
- 다른 엔티티와의 연결고리 역할
단일 속성의 여부
- 단일식별자
- 하나의 속성으로 구성된 식별자
- 복합식별자
- 두 개 이상의 속성으로 구성된 식별자
대체 여부
- 원조식별자
- 업무 프로세스에 존재하는 식별자
- 가공되지 않은 원래의 식별자(본질식별자)
- 대리식별자
- 주식별자의 속성이 두 개 이상인 경우 그 속성들을 하나로 묶어서 사용하는 식별자 (인조식별자)
식별자 관계 vs. 비식별자 관계
식별자 관계
: 부모 엔티티의 식별자가 자식 엔티티의 주식별자가 되는 관계
- 주식별자는 반드시 존재해야 하므로(존재성) 부모 엔티티가 있어야 생성 가능하며 단일식별자인지 복합식별자인지에 따라 1:1이거나 1:M이거나가 결정된다.
비식별자 관계
: 부모 엔티티의 식별자가 자식 엔티티의 주식별자가 아닌 일반 속성이 되는 관계
- 일반 속성의 속성값은 NULL이 될 수 있으므로 부모 엔티티가 없는 자식 엔티티 생성이 가능하고 마찬가지의 이유로 자식 엔티티가 존재하는 상태에서 부모 엔티티가 삭제될 수도 있다.
