21. 속성
업무에서 필요로 하는 인스턴스로 관리하고자 하는 의미상 분리되지 않는 최소의 데이터 단위
22. 속성의 특징
1) 업무에서 필요하고 관리하고자 하는 정보
2) 주식별자에 함수적 종속성을 가져야 함
3) 1개의 속성 → 1개의 속성 값을 가짐
23. 속성의 분류
1) 기본 : 업무에서 추출한 모든 일반적인 속성
(제외 : 코드성 데이터, 식별 일련번호, 타 속성을 계산, 영향을 받아 생성된 속성)
2) 설계 : 업무를 규칙화 하기 위해 새로 만들거나 변형, 정의하는 속성 (Ex : SAP에서 9코드, 7코드)
3) 파생 : 다른 속성에 영향을 받아 발생한 속성, 빠른 성능을 낼 수 있도록 원래 속성의 값을 계산, 적을수록 좋음 (Ex : sum)
24. 속성 구성 방식의 분류
1) PK(prime key) : 엔터티를 식별 가능한 속성 (Ex : 사원번호)
2) FK(Foreign key) : 관계에서 포함된 속성 (Ex : 부서코드)
3) 일반 : PK, FK에 속하지 않은 속성 (Ex : 사원명, 우편번호)
4) 단순형 : 나이, 성별 등은 더 이상 다른 속성으로 구성 불가한 단순 속성
5) 복합형 : 주소의 도, 시, 구, 동 등 여러 세부 속성들로 구성 가능한 속성
5) 단일값 : 속성 하나에 한개의 값을 가지는 경우 (Ex : 주민등록번호)
6) 다중값 : 속성 하나에 여러 개의 값을 가지는 경우 (Ex : 전화번호)
25. 도메인
속성의 데이터타입, 크기, 제약사항, 지정 속성의 명명 (Ex : 글자수제한)
26. 속성의 명명
1) 해당업무에서 사용하는 이름 부여
2) 명사형 이용 및 소유격, 서술식 속성명 사용 금지
3) 약어 사용 금지
4) 구체적으로 명명하여 데이터 모델에서 유일성 확보
27. 관계 (Relationship)
엔터티의 인스턴스 사이의 논리적인 연관성으로써 존재의 형태나 행위로 상호 간 연관성이 부여된 상태, 관계 페어링의 집합 (Ex : 강사 (엔터티) - 가르친다 (행위) - 수강생 (엔터티))
28. 패어링
엔터티 내 인스턴스가 개별적으로 관계를 가지는 것으로, 개별 인스턴스가 각각 다른 종류의 관계가 있다면 두 엔터티 간 두 개 이상의 관계 형성 가능
29. UML(통합 모델링 언어)에서의 관계
1) 연관관계 (실선) : 항상 이용하는 존재적 관계 (Ex : 소속된다)
2) 의존관계 (점선) : 상대 행위에 의해 발생하는 관계 (Ex : 주문한다)
30. 관계의 표기법
1) 관계명 : 관계의 이름
2) 관계차수 : 1:1 (실선), 1:M & M:N (까마귀 발)
3) 관계선택성 (관계선택사양)
(1)필수참여관계 : 모든 참여자가 반드시 관계를 가지고 타 엔터티의 참여
자와 연결 되어야 하는 관계 (Ex : 수주등록을 위해 발주서가 있어야 함)(2)선택참여관계 : 선택참여된 항목은 물리속성에서 FK로 연결될 경우
Null을 허용할 수 있음, 만약 선택참여로 지정해야할 것을 필수참여로
한다면 앱에서 데이터가 발생할 때 반드시 한 개의 트랜잭션으로 제어야
해야 하는 제약사항이 발생 (Ex : A제품과 a 오더, a’ 오더)
31. 관계 체크사항
1) 2개의 엔터티 사이에 관심있는 연관 규칙이 발생했는가?
2) 2개의 엔터티 사이에 정보의 조합이 발생되는가?
3) 업무기술서, 장표에 관계연결에 대한 규칙이 서술됐는가?
4) 업무기술서, 장표에 관계연결을 가능케 하는 동사가 있는가?
32. 관계 읽는 방법
(1)기준 엔터티를 한 개, 각으로 읽는다 (Ex : 각 사원, 한 부서)
(2)대상 엔터티의 관계참여도, 개수를 읽는다 (Ex : 각각의 사원은 한 부서에)
(3)관계선택사양과 관계명을 읽는다 (Ex : 때때로 소속한다)
33. 식별자
나의 엔터티에 구성된 여러 개의 속성 중 엔터티를 대표할 수 있는 속성을 의미하며 하나의 엔터티에 반드시 하나의 유일한 식별자가 존재해야 함
(식별자 : 논리 데이터 모델링 단계 사용 / Key : 물리적 데이터 모델링 단계 사용)
34. 식별자의 특징
1) 유일성 : 주식별자에 의해 모든 인스턴스들이 유일하게 구분 (Ex : 사번)
2) 최소성 : 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 함 (Ex : 사원분류코드+사번의 구성 x)
3) 불변성 : 지정된 주식별자의 값은 자주 변하지 않아야 하며,변하면 이전 기록 말소됨
4) 존재성 : 주식별자가 지정되면 반드시 값이 들어와야 함 (Null 안 됨)
35. 식별자 분류
1) 대표성 여부
(1)주식별자 : 엔터티 내에서 각 어커런스를 구분할 수 있는 구분자로,타 엔터티와 참조관계를 연결
(2)보조 식별자 : 엔터티 내 각 어커런스를 구분할 수 있으나 대표성이 없고, 참조관계 연결 못 함
2) 스스로 생성여부
(1) 내부 : 스스로 생성되는 식별자
(2) 외부 : 타 엔터티로부터 받아오는 식별자
3) 속성의 수
(1) 단일 : 하나의 속성으로 구성
(2) 복합 : 2개 이상의 속성으로 구성
4) 대체 여부
(1) 본질 : 업무에 의해 만들어지는 식별자
(2) 인조 : 인위적으로 만든 식별자
36. 주식별자 도출기준
1) 해당 업무에서 자주 이용되는 속성
2) 명칭, 내역 등과 같이 이름으로 기술되는 것은 지양
→ 만약, 부서이름을 주식별자로 선정하면 물리DB로 테이블을 생성하여 데이터를 읽을 때 항상 부서 이름이 WHERE 조건절에 기술되는 현상 발생, 따라서 이 경우 보통 일련번호와 코드를 많이 사용
3) 복합으로 주식별자로 구성할 경우 너무 많은 속성 포함 안 됨
→ 너무 많으면 인조식별자 생성 (Ex : 자격증 접수번호를 인조식별자 대체하면 SQL문장이 간단해짐)
37. 식별자 관계
1) 주식별자 : 부모의 주식별자를 자식의 주식별자에 상속
→ 문제점 : 식별자 관계로만 설정 시, 주식별자 증가로 오류 유발
2) 비식별자 : 부모 속성을 자식의 일반속성으로 사용
• 부모없는 자식이 생성될 수 있는 경우
• 부모와 자식의 생명주기가 다른 경우 (부모가 별도로 소멸된 경우)
• 여러 개의 엔터티가 하나의 엔터티로 통합되어 표현 되었는데 각각의
- 엔터티가 별도의 관계를 가진 경우
• 자식엔터티에 별도의 주식별자를 생성하는 것이 더 유리한 경우
• SQL 문장이 길어져 복잡성 증가되는 것 방지
→ 문제점 : 비식별자 관계로만 설정 시, 부모 엔터티와 조인하여 성능저하
3) 식별자관계와 비식별자 관계의 모델링
→ 비식별자 관계 선택 프로세스 : 식별자 관계로 모든 관계가 연결되면서 다음 조건에 해당하는 경우, 비식별자 관계로 조정
4) 식별자와 비식별자를 적절히 선택한 균형감있는 데이터 모델
