준비
객관식 50문항 (1시간 30분) 평균 60점 이상 합격
데이터 모델링의 이해 |
- 데이터 모델의 이해 - 엔터티 - 속성 - 관계 - 식별자 |
| 데이터 모델과 SQL | - 정규화 - 관계와 조인의 이해 - 모델이 표현하는 트랜젝션의 이해 - Null 속성의 이해 - 본질식별자 vs 인조식별자 |
데이터 모델의 이해
현실 세계의 비즈니스 프로세스와 데이터 요구 사항을 추상적이고 구조화된 형태로 표현하는 과정
모델링 특징
1. 단순화
- 핵심 요소에 집중해서 불필요한 세부 사항을 제거
2. 추상화
- 현실세계를 일정한 형식에 맞추어 간략하게 대략적으로 표현하는 과정
3. 명확화
- 대상에 대한 애매모호함을 최대한 제거하고 정확하게 현상을 기술하는 과정
데이터 모델링 유의점
1. 중복
- 한 테이블 또는 여러 테이블에 같은 정보를 저장하지 않도록 설계
2. 비유연성
- 사소한 업무 변화에 대해서도 잦은 모델변경이 되지 않도록 주의
3. 비일관성
- 데이터베이스 내의 정보가 모순되거나 상반된 내용을 갖는 상태
- 데이터의 상호연관 관계를 명확히 정의 (데이터 품질 관리 필요)
데이터 모델링 3가지 요소
- 대상 : 대상
- 속성 : 대상이 갖는 속성 (학생 이름 전화번호 주소)
- 관계 : 대상들과의 관계 (선생 -학생과 같은 관계)
데이터 모델링의 3단계
1. 개념적 모델링
- 추상화 수준이 가장 높음
- 업무를 분석 뒤 업무의 핵심 엔터티를 추출하는 단계
2. 논리적 모델링
- 개념적 모델링의 결과를 토대로 세부 속성, 식별자, 관계 등을 표현하는 단계
- 데이터 정규화 수행
3. 물리적 모델링
- 논리 모델링이 끝나면 이를 물리적으로 생성하는 과정
- 추상화 수준이 가장 낮음(가장 구체적인 모델링이라서)
데이터 모델의 표기법 (ERD)
- 엔터티와 엔터티간의 관계를 시각적으로 표현한 다이어그램
ERD작성 절차
1. 엔터티를 도출한 후 그린다
2. 엔터티 배치
3. 엔터티 간의 관계를 설정
4. 관계명을 서술
5. 관계의 참여도 기술
6. 관계의 필수 여부를 확인
엔터티
엔터티의 개념
- 현실 세계에서 독립적으로 식별 가능하는 객체나 사물을 나타냄
엔터티 : 학생
속성 : 학번, 이름, 학과 등
식별자 : 학번(고유한 학번으로 각 학생을 식별)
인스턴스 : 특정 학생의 데이터
- 학번:202100001 / 이름: 강아지 / 학과: 컴퓨터 공학
엔터티의 특징
1. 유일한 식별자에 의해 식별 가능 (사번)
2. 해당업무에 필요하고 관리하고자하는 정보
3. 인스턴스들의 집합
- 영속적으로 존재하는 2개이상의 인스턴스 집합
4. 엔터티는 반드시 속성을 가짐
- 각 엔터티는 2개 이상의 속성을 가짐
- 하나의 인스턴스는 각각의 속성들에 대한 1개의 속성 값만을 가짐
5. 엔터티는 업무 프로세스에 의해 이용
- 업무적으로 필요해 선정했지만 실제 사용되지 않으면 잘못 설계된 것
- 누락된 프로세스의 경우 추후 해당 프로세스 추가
- 반대로 사용되지 않은 고립 엔터티는 제거 필요
6. 다른 엔터티와 최소 1개 이상의 관계 성립
- 업무적 연관성을 갖고 다른 엔터티와 연관의 의미를 가짐
- 관계가 없는 엔터티 도출은 부적절한 엔터티거나 적절한 관계를 찾지 못한 것
엔터티의 분류
1. 유형과 무형에 다른 분류
| 유형 엔터티 | - 물리적 형태가 있음 (실체가 있는 대상) - 사원, 물품, 감사 등 |
| 개념 엔터티 | - 물리적 형태 없음 - 조직, 보험상품 등 |
| 사건 엔터티 | - 업무를 수행에 따라 발생하는 엔터티 - 주문, 청구, 미납 등 |
2. 발생 시점에 따른 분류
| 기본 엔터티 | - 그 업무에 원래 존재하는 정보 - 독립적인 생성 - 자신의 고유한 주식별자를 가짐 - 사원, 부서, 고객, 상품 |
| 중심 엔터티 | - 기본 엔터티로부터 발생, 그 업무에서 중심적인 역할 - 많은 데이터가 발생하고 다른 엔터티와의 관계를 통해 많은 행위 엔터티를 생성 - 계약, 사고, 청구, 주문, 매출 |
| 행위 엔터티 | - 2개 이상의 부모 엔터티로부터 발생 - 자주 내용이 바뀌거나 데이터 양이 증가 - 주문(고객과 상품 엔터티로부터 발생하므로 행위 엔터티이기도함), 사원변경이력, 이력 |
엔터티의 명명
1. 현업에서 사용하는 용어
2. 가능하면 약자 사용은 자제
3. 단수 명사 사용
4. 유일하게 이름 부여 (중복 없는 이름)
5. 엔터티 생성 의미대로 이름 부여
엔터티와 인스턴스 표기법
- 사각형으로 표현
속성
속성의 개념
- 업무에서 필요한 고유한 성질, 특징을 의미 (컬럼으로 표현할 수 있는 단위)
- 업무상 인스턴스로 관리 하고자 하는 더 이상 분리되지 않는 최소의 데이터 단위
엔터티, 인스턴스, 속성, 속성값의 관계
- 한개의 엔터티는 2개 이상의 인스턴스
- 한개의 엔터티는 2개이상의 속성
- 한개의 속성은 1개의 속성 값을 가짐 (수학 <-> 과학은 다름)
- 속성은 구체적인 값을 가짐
속성의 특징
- 업무적으로 필요
- 정해진 주식별자에 함수적 종속성을 가져야함 (학번 > 학생 종속성)
- 원자성 : 각 속성이 하나의 값을 가지고 있음, 단일하고 명확한 값을 가지는 것
함수적 종속성
1. 완전 함수적 종속
- PK를 구성하는 칼럼이 2개 이상일 경우 PK값 모두에 의해 종속 관계를 나타낼때 완전 함수 종속성 만족
2. 부분 함수적 종속
- 기본키 일부에 대해 종속될때를 말함
속성의 분류
1. 속성의 특징에 따른 분류
| 기본 속성 | - 업무로 부터 추출된 모든 속성 - 원금, 예치기간 등 |
| 설계 속성 | - 기본 속성 외에 업무를 규칙화 하기 위해 새로 만들어지거나 기본 속성을 변형하여 만들어지는 속성 - 상품코드, 지점 코드, 예금 분류 등 |
| 파생 속성 | - 다른 속성에 의해 만들어지는 속성 - 합계, 평균, 이자 등 |
2. 엔터티 구성 방식에 따른 분류
| PK (기본키) | - 인스턴스를 식별 할 수 있는 속성 |
| FK (외래키) | - 다른 엔터티와의 관계에서 포함된 속성 |
| 일반 속성 | - 엔터티에 포함되어 있고 PK/FC에 포함되지 않는 속성 |
3. 분해 여부에 다른 속성
| 단일 속성 | - 하나의 의미로 구성된 경우 - 회원 아이디, 이름 등 |
| 복합 속성 | - 여러개의 의미로 구성된 경우 - 주소(시, 구, 동 등으로 분해 가능) |
| 다중값 속성 | - 속성에 여러개의 값을 가질 수 있는 경우 - 상품 리스트 등 |
속성의 명명 규칙
1. 업무에서 사용하는 이름
2. 서술식 속성명은 사용하지 않음
3. 약어의 사용은 제한
4. 전체 데이터 모델에서 유일한 명칭
도메인
- 각 속성이 가질 수 없는 값의 범위를 의미
- 엔터티 내에서 속성에 대한 데이터 타입의 크기, 제약사항을 지정
관계
- 관계는 엔터티간의 연관성을 나타낸 개념
- 인스턴스 간의 논리적인 연관성을 파악하여 정의
- 엔터티를 어떻게 정의하냐에 따라 변경되기도 함
관계의 종류
1. 존재적 관계
- 한 엔터티의 존재가 다른 엔터티의 존재의 영향을 미치는 관계
- ex. 부서 엔터티가 삭제되면 사원 엔터티의 존재에 영향을 미침
2. 행위적 관계
- 엔터티 간의 어떤 행위가 있는 것을 의미
- ex. 고객 엔터티의 행동에 의해 주문 엔터티가 발생
*ERD에서는 존재 관계와 행위관계를 구분하지 않음
관계의 구성
1. 관계명 (ex. 학생이 어떤 강의를 듣는지? 수강하는 강의)
2. 차수 (ex. 1대 다, 1:1)
3. 선택성 (ex. 필요한 단계인지 아닌지 필수, 선택)
관계의 차수
- 한 엔터티의 레코드(인스턴스)가 다른 엔터티의 레코드(인스턴스)와 어떻게 연결되는지 나타내는 표현
1. 1대 1 관계
- 완전 1대 1 관계
: 하나의 엔터티의 관계되는 엔터티가 반드시 하나로 존재하는 경우
: 사원은 반드시 소속 부서가 있어야 함
- 선택적 1대 1 관계
: 하나의 엔터티에 관계되는 엔터티가 하나이거나 없을 수 있는 경우
: 부서 입장에서 사원을 바라봄 (사원은 하나의 소속 부서가 있거나 아직 발령전이면 없을 수 없다)
2. 1대 N관계
- 엔터티에 하나의 행에 다른 엔터티의 값이 여러 개 있는 관계
- ex. 고객은 여러개 계좌를 소유할 수 있음
3. M대 N의 관계
- 두 엔터티가 다대다의 연결 관계를 가지고 있음
- 이 경우 조인 시 카테시안 곱이 발생, 두 엔터티를 연결하는 연결 엔터티의 추가로 1대 N관계로 해소할 필요가 있음
- ex. 한 학생이 여러 강의를 수강할 할 수 있고, 한 강의 기준으로도 여러 학생을 보유할 수 있음
: 이 두 엔터티의 연결엔터티로는 수강이력 or 구매이력 엔터티가 필요함
관계의 페어링 (집합을 의미)
- 엔터티 안에 인스턴스가 개별적으로 관계를 가짐
* 관계의 차수, 페어링 차이
- 관계의 차수는 하나의 엔터티와 다른 엔터티 간의 레코드 연결방식을 나나태는 반면, 관계 페어링은 두 엔터티간의 특정 연결을 설명하고 추가 정보를 제공하는 용도로 사용
- ex. 한 학생은 여러 강의를 수강할 수 있고, 한 강강의도 여러 학생에게 수강될 수 있으므로 M대 N의 관계이며, 이때 차수는 M:N이 됨
인스턴스 관계를 보면 "학생 A가 강의 B를 2023년 1학기에 수강했고 성적은 'A+'를 받았다"와 같은 특정한 페어링이 형성
식별자
- 하나의 엔터티에 구성된 여러개 속성 중 엔터티를 대표할 수 있는 속성을 나타 냄
- 하나의 유일한 유일 식별자가 존재
- 식별자는 논리 모델링에서 사용하는 용어, 물리 모델링에서는 키(Key)라고 표현
- ex. 학생 엔터티의 주식별자는 학생 번호 속성(논리 모델링) -> 학생 테이블의 기본키는 학생 번호 컬럼(물리 모델링)
주식별자의 특징
1. 유일성 : 주식별자에 의해 모든 인스턴스를 유일하게 구분함
ex. 학생 엔터티에서 이름속성은 동명이인이 발생할 수 있음, 모든 인스턴스를 완벽하게 구분할 수 없으므로 학생 번호와 같은 유일한 식별자를 주식별자로 사용
2. 최소성 : 주식별자를 구성하는 속성은 유일성을 만족하는 최소한의 속성으로 구성
ex. 학생 엔터티의 주식별자는 학생 번호만으로 충분한데, 학생번호 + 이름으로 구성할 필요 없음
3. 불변성 : 주식별자가 한 번 엔터티에 지정되면 그 식별자의 값은 변하지 않아야 함
ex. 학생 엔티티에 주식별자인 학생 번호가 때에 따라 변경되서는 안됨
4. 존재성 : 주식별자가 지정되면 반드시 값이 존재해야 하며 NULL은 허용 안 됨
식별자 분류
1. 대표성 여부에 따른 식별자의 종류
| 주식별자 | 보조식별자 |
| - 유일성과 최소성을 만족하면서 엔터티를 대표하는 식별자 - 엔터티 내에서 각 인스턴스를 유일하게 구분할 수 있는 식별자 - 타 엔터티와 참조관계를 연결할 수 있는 식별자 |
- 엔터티 내에서 각 인스턴스를 구분할 수 있는 구분자지만, 대표성을 가지지 못해 참조 관계 연결을 할 수 없는 식별자 - 유일성과 최소성을 만족하지만 대표성을 만족하지 못하는 식별자 ex. 주민 번호는 유일성과 최소성을 가지지만 식별자로 쓸 수 없음, 식별은 조회 시 사용되는 구분인데 보안의 문제가 있음 (보조 식별자) |
2. 생성 여부에 따른 식별자 종류
| 내부식별자 | 외부식별자 |
| - 다른 엔터티 참조 없이 엔터티 내부에서 스스로 생성되는 식별자 | - 다른 엔터티와 관계로인해 만들어 지는 식별자 (외래키) - ex. 우편번호 |
3. 속성 수에 따른 식별자 종류
| 단일식별자 | 복합식별자 |
| - 하나의 속성으로 구성 | - 2개 이상의 속성으로 구성 |
4. 대체 여부에 따른 식별자의 종류
| 본질식별자 | 인조식별자 |
| - 비즈니스 프로세스에서 만들어지는 식별자 - ex. 부서코드 : 부서식별에 필요한 본질식별자 |
- 인위적으로 만들어지는 식별자 - 자동 증가하는 일련번호 같은 형태 - ex. 주문 번호 : 주문일자 + 주문순서 + 상품코드 대신 만든 인조 식별자 |
식별자 표기법
주식별자 도출기준
1. 해당 업무에서 자주 이용되는 속성을 주식별자로 지정
2. 명칭이나 내역등과 같은 이름은 피함
-ex. 부서명 보다는 부서 코드를 부여하여 부서코드로 주식별자로 사용
3. 속성의 수를 최대한 적게 구성
- 주식별자를 너무 많은 속성으로 구성 시, 조인으로 인한 성능 저하 발생 우려
관계간 엔터티 구분
1. 강한개체
- 독립적으로 존재할 수 있는 엔터티
- 고객과 계좌 엔터티 중, 고객은 독립적으로 존재할 수 있음
2. 약한 개체
- 독립적으로 존재할 수 없는 엔터티
- 고객과 계좌 엔터티 중, 계좌는 독립적으로 존재할 수 없음 (고객에 의해 파생되는 엔터티)
식별관계와 비식별 관계
1. 식별관계
- 하나의 엔터티의 기본키를 다른 엔터티가 기본키의 하나로 공유
- 식별 관계에는 ERD에서 실선으로 표시
- 사원과 교육이력 엔터티에서 양쪽 모두 기본키 중 일부가 사원번호
사원 교육이력
#사원번호 # 사원번호 (FK)
# 수강일자
2. 비식별관계
- 강한 개체의 기본키를 다른 엔터티의 기본키가 아닌 일반 속성으로 관계를 가지는 것
- 비식별관계는 ERD에서 점선으로 표시
- 부서와 사원의 관계에서 부서의 부서번호(기본키)를 사원 엔터티에서는 일반키로 가짐 (사원에서는 사원번호가 기본키)
정규화
개념
- 최소한의 데이터만을 하나의 엔터티에 넣는 식으로 데이터를 분해하는 과정
- 데이터의 중복을 제거하고 데이터 모델의 독립성 확보
- 데이터 이상현상을 줄이기 위한 데이터베이스 설계 기법
- 엔터티를 상세화하는 과정으로 논리 데이터 모델링 수행 시점에서 고려됨
- 제 1 정규화부터 제 5 정규화까지 존재, 실질적으로는 제 3정규화까지만 수행
이상현상
- 정규화를 하지 않아 발생하는 현상 (삽입이상, 갱신이상, 삭제이상)
- ex. 사원 + 부서 엔티티를 합쳐놓고 사원번호, 사원 이름, 전화번호, 부서번호, 부서명, 부서위치의 속성이 존재할때 새로운 사원값이 추가 될때 정해지지 않은 정보 (부서번호, 부서명, 부서위치) 모두 입의값 or Null이 삽입되어야함
반대로 부서가 새로 추가될 경우 소속사원이 없어도 사원과 관련된 속성이 불필요하게 값이 입력됨
- 이럴경우 불필요한 값까지 추가되는 것을 삽입이상, 갱신이상
- 부서 정보까지 삭제하면 되는데 관련된 사원 정보까지 함께 삭제되는게 삭제 이상
정규화
1. 제 1정규화
- 원자성(한 속성이 하나의 값을 갖는 특성)
2. 제 2정규화
- 제 1 정규화를 진행한 테이블에 대해 완전 함수 종속을 만들도록 테이블을 분해
- 완전 함수 종속이란, 기본키를 구성하는 모든 칼럼의 값이 다른 칼럼을 결정 짓는 상태
- 즉 PK가 2개 이상일 때 발생하며 PK의 일부와 종속되는 관계가 있다면 분리
ex. 기본키 (학생번호 + 강의명) 중 강의명에 의해 강의실이 결정 -> 완전함수 종속성을 위배(부분 함수 종속성을 가짐)
3. 제 3정규화
- 제 2 정규화를 진행한 테이블에 대해 이행적 종속을 없애도록 테이블을 분히
- 이행적 종속성이란 A->B, B->C의 관계가 성립할때, A->C가 성립되는 것을 말함
- (A,B) 와 (B,C)로 분리하는게 제 3정규화
ex. 고객번호에 의해 상품명이 결정, 상품명에 의해 가격이 결정되는데 고객 번호에 의해서도 구매가격이 결정
따라서 (고객번호 + 상품명) 과 (상품명 + 가격)으로 분리하는 것이 제 3정규화
4. BCNF(Boyce - Codd Normal Form) 정규화
- 모든 결정자가 후보키가 되도록 테이블을 분해하는 것 (결정자가 후보키가 아닌 다른 칼럼에 종속되면 안됨)
5. 제 4정규화
- 여러 칼럼들이 하나의 칼람을 종속시키는 경우 분해하여 다중값 종속성을 제거
6. 제 5정규화
- 조인에 의해서 종속성이 발생되는 경우 분해
7. 반정규화 = 역정규화 개념
- 너무데이터가 세세하게 분리하게되면 결과적으로 합쳐서 출력하게 될때 조인이 잦아져서, 성능을 저하시키는 문제
- 데이터를 다시 결합하기도 함
반정규화 수행케이스
- 수행 속도가 느려지는 경우
- 다량으 범위를 자주 처리해하는 경우
- 특정 범위의 데이터만 자주 처리하는 경우
- 요약/집계 정보가 자주 요구되는 경우
관계
엔터티의 인스턴스 사이의 논리적인 연관성
- 관계를 맺는다는 의미는 부모의 식별자를 자식에 상속하고, 상속된 속성을 매핑키(조인키)로 활용 (부모 - 자식을 연결)
관계의 분류
- 관계는 존재에 의한 관계와 행위에 의한 관계로 분류
1. 존재 관계
- 엔터티 간의 상태를 의미 (사원 엔터티는 부서 엔터티에 소속)
2. 행위 관계
- 엔터티 간의 어떤 행위가 있는 것을 의미 (주문은 고객이 주문할 때 발생)
조인의 의미
- 결국 중복을 피하기 위해 정규화로 분리가 되었는데 두개의 데이터를 동시에 출력해야할때
- 연결되어있는 두개의 코드로 출력하는 것
계층형 데이터 모델
- 자기 자신끼리 관계가 발생
상호베타적 관계
- 두 테이블 중 하나의 관계를 말함
트랜잭션
트랜잭션이란 하나의 연속적인 업무 단위를 말함
- 트랜잭션에 의한 관계는 필수적인 관계 형태를 가짐
- 하나의 트랜잭션에는 여러 SELECT, INSERT, DELETE, UPDATE등이 포함될 수 있음
*주의
- 서로 독립적으로 발생하면 안됨
- 부분 COMMIT불가 (동시 COMMIT 또는 ROLLBACK 처리)
필수적, 선택적 관계와 ERD
- 두 엔터티의 관계가 서로 필수적일때 하나의 트랜잭션이 형성
- 두 엔터티가 서로 독립적 수행이 가능하다면 선택적 관계로 표현
IE 표기법
- 원을 사용하여 필수적 관계와 선택적 관계를 구분
- 필수적 관계에는 원을 그리지 않음
- 선택적 관계에는 관계선 끝에 원을 그림
바커표기법
- 실선과 점선으로 구분
- 필수적 관계는 관계선을 실선으로 표기
- 선택적 관계는 관계선을 점선으로 표기
NULL
- DBMS에서 아직 정해지지 않은 값을 의미
- 0과는 다른 개념
NULL의 특성
1. NULL포함한 연간셜과는 항상 NULL
- 치환이 필요 ex. NVL(COMM,0)
2. 집계함수는 NULL을 제외한 연산 결과 리턴
- sum, avg, min, max 등의 함수는 항상 null을 무시
NULL의 ERD표기법
- IE표기법에서는 NULL 허용여부를 알 수 없음
- 바커 표기법에서는 속성앞에 동그라미가 NULL허용 속성을 의미
식별자 구분
본질 식별자
- 업무에 의해 만들어지는 식별자 (꼭 필요한 식별자)
인조식별자
- 인위적으로 만들어지는 식별자 (꼭 필요하지는 않지만 관리의 편이성 등의 이유로 인위적으로 만들어지는 식별자)
- 본질 식별자가 복잡한 구성을 가질때 인위적으로 생성
- 주로 각 행을 구분하기 위해 기본키로 사용되며 자동으로 증가하는 일련번호 같은 형태
ex. 주문과 주문상세에 대한 엔터티
주문이 들어오면 주문엔터티에는 (주문번호+고객번호)를 저장, 이때 pk는 주문번호이다
주문 상세에는 각 주문별로 어떤 상품이, 언제, 몇개, 주문됐는지 등을 기록
어떻게 PK를 정해야할까??
1. PK : 주문번호 + 상품번호로 설계
- 주문을 하면 주문번호와 상품번호가 필요하므로 본질식별자(주문번호 + 상품번호) 가 됨
- 하지만 PK가 주문번호 + 상품번호 이면 하나의 주문번호로 같은 상품의 주문 결과를 저장할 수 없음
-> 실제로 쇼핑을하면 동일한 장바구니에 a상품을 5개 주문했는데 추후에 a 상품을 3개를 추가로 주문하기도 함
2. PK : 주문번호 + 주문순번(주문 순번이라는 칼럼을 생성)
- 하나의 주문에 여러 상품에 대한 주문 결과 저장 가능 -> 주문 순번으로 인해 구매
-> 매 주문마다 동일한 상품 주문 시 주문 순번을 정하기 위해 상품의 주문횟수를 세야하는 점이 매우 불편,
즉, 사과를 총 3번 구매했으니 주문 순번은 1,2,3 순서대로 입력돼야 함
3. PK : 주문 상세번호(인조 식별자 생성)
- 주문 상세번호로 각 주문이력을 구분하기 때문에 같은 주문의 같은 상품이력이 저장될 수 있음
- 주문 상세번호만이 주식별자이므로 나머지 정보들이 불필요하게 중복 저장될 위험 발생
- 실제 업무와 상관없는 주문 상세번호를 주식별자로 생성하면 쓸모없는 index가 생성됨
-> 따라서 인조식별자는 다음의 단점을 가짐
1. 중복데이터 발생 가능 -> 데이터 품질 저하
2. 불필요한 인덱스 생성 -> 저장공간 낭비 및 DML 성능 저하
*인덱스는 원래 조회 성능을 향상시키이 위한 객체이며, 인덱스 (DML (INSERT, UPDATE, DELETE)시 INDEX SPLIT (인덱스가 쪼개지는 형상) 현상으로 인해 성능이 저하된다.
출처
'혼자 고민해보기_ 서비스 기획 > SQL' 카테고리의 다른 글
| 4주차_ Subquery 사용하기 (0) | 2023.05.01 |
|---|---|
| 3주차_ Left Join, Inner Join 사용해보기 (0) | 2023.05.01 |
| 2주차_ Group by, Order by 사용해보기 (0) | 2023.05.01 |
| 1주차_ Select, Where 절 등 문법 연습해보기 (1) | 2023.05.01 |