728x90
- 양적인 측면에서 엔티티의 수 십 배에 해당하는 속성을 정의하는 데 많은 시간이 소요된다는 점이 부담스럽다.
- 속성을 하나씩 식별하여 정의하기 보다는 업무 요건에 해당하는 속성을 모두 도출하는 것이 우선이다.
- 속성 흐름
속성도출 -> 속성정의 -> pk -> domain(check)/type -> default -> Not null -> 검토
- 158p epdlxj ahepf cpzmfltmxm dPtl
1. 속성 도출
- 보이지 않는 속성이 뽑아내기가 어렵다
1.1. 핵심 엔티티 속성
- 핵심 엔티티 : 식별자, 명칭, 특성, 특징, 제원, 접촉정보, 위치정보, 약관/정책, 관계 속성을 포함
- 예시 고객, 상품 속성: 주민등록번호, 상품번호,
1.2. 중요 엔티티/행위 엔티티 속성
2. 속성명 부여
- 자명성 = 스스로 설명이 되야한다.
- 속성명: 속성을 가장 명확하게 설명할 수 있는 명칭을 부여
ex) 결재번호가 아니라 내부결재번호로 명명 - 속성명은 간결하면서 너무 일반적이지 않아야 한다.
ex) 처리일자 -> 입금처리일자 - 저자의 속성명 작성 방법 : 고객_전화번호 와 같이 단어와 단어 사이에 언더바를 붙여서 속성명을 작성
3. 속성 정의
- entity의 lifte cycle과 동일한 내용
- 일단 보류
4. 식별자 지정
- = pk 지정
- 유일(Unique), 식별 가능, 최소 속성(mininal), 변하지 않고(Unmitable), 반드시 존재(Not null)하는 값
- 모든 엔티티는 식별자를 가져야 하며, 식별자를 가지지 못하면, 정상적인 엔티티가 아닌 단순 데이터를 기록하는 로그 성격 데이터 혹은 임시 저장 성격의 데이터일 가능성ㅇ ㅣ높다
- 식별자 구분
- 본질 식별자: Email, 주민등록번호
- 인조 식별자: sequence
- 모든 식별자는 주 식별자 역할이든지 대체 식별자 역할이든지 데이터 발생 규칙을 정의하고, 실체무결성(Primary Key, Unique Key) 제약조건을 설계해야 한다.
5. 인조식별자를 정의하는 경우
- 딱히 할게 없을 경우
- Key column이 너무 많은 경우
- 엔티티를 통합할 때 통합 대상 엔티티 식별자가 서로 다르거나, 데이터 집합 단위가 다른 경우
- 암호화 식별자 대체 : 비밀변호의 경우
- 초기 Null 값이 있는 본질 식별자 대체
ex) 사업자 번호 - 고객을 맞춰줘야한다.
6. domain 및 data type 지정
- 도메인: 속성에서 도메인을 지정하거나 데이터타입을 지정하여 속성이 가질 수 있는 데이터 값의 범위를 정의, check(?)
- type: varchar, number, date, datetime, char 등등
7. 옵셔널리티(Not Null) 지정
- 제약조건
- Mandatory : 필수, not null
- Optional: 선택, null
8. Default 값 지정
- 데이터값을 입력하지 않을 때 기본값 - 선택값에만 들어간다.
9. 데이터 모델 검토
- 말그대로 검토
