걸음마부터 달리기
DB-6/27 본문
3절 속성
속성: 업무에서 필요로 하는 인스턴스로 관리하고자(구성요소) 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위
속성의 특징:
마지막 특징은 1 정규화에서 하는 행동이니 즉 하나의 속성에는 한개의 값만을 가진다고 하는것이다.
속성의 분류
기본속성: 업무분석을 통해 바로 정의한 속성
설계속성: 업무상 존재는 하지 않지만 설계를 하면서 도출해내는 속성(일련번호)
파생속성: 계산,변형에 의해 생성되는 속성 (팔린 전체 용기 수)
특히나 파생속성은 어떤 엔티티에, 어떤 속성에 영향을 받고 있는지 정의되어야 하고, 계산방법 또한 명시되어야 함.
엔티티를 구성하는 방식으로 구분한 속성
1) PK: 엔티티를 식별할 수 있는 속성
2) FK: 다른 엔티티와의 관계에서 포함된 속성
3) 일반속성: PK FK 제외한 나머지 속성
복합속성: 여러 세부 속성들로 구성된 속성 (주소 속성은 시 구 번 동 번지와 같은 속성들로 구성됨)
단순속성: 더 이상 다른 속성들로 구분 안되는 속성
단일값: 속성에 값으로 하나만 가능 >> 단일값 속성
다중값: 속성에 값으로 여러개 가능 >> 다중값 속성 >> 결국엔 정규화 해서 단일값 속성으로 만들거나 따로 엔티티 분리해야함
도메인: 각 속성이 값을 가질 수 있는 범위 (성별이면 남,여 값만 가능)
모든 명명법은 마찬가지로 단순명사를 사용하고 약어 사용 안되고 모델에서 유일성을 가지는 이름이어야 함
설계속성 vs 인조속성
설계 속성은 업무상 필요한 데이터 이외에 데이터 모델링을 위해, 업무를 규칙화하기 위해 속성을 새로 만들거나 변형하여 정의하는 속성입니다. 인조 속성은 속성의 종류 중 하나로, 속성의 값이 여러 종류를 가지고 있을 때 그 값들의 종류 하나하나를 개체라고 부르고, 이 개체들을 구성요소로 하는 집합을 인조 속성이라고 합니다.
4절 관계
관계의 패어링: 엔티티뿐만 아니라 개별 인스턴스가 각각 다른 종류의 관계를 가지고 있을 수도 있음. 이러면 두 엔티티 사이에 두 개 이상의 관계가 형성됨. >> 어커런스(레코드,튜플) 관계 페어링
이러한 인스턴스의 각개의 관계를 집합으로 표현한게 관계임
최초의 ERD 에서는 관계 자체가 속성을 가질 수 있었음. 근데 요즘 이러한 표기는 잘 쓰지 않음. (정처기때 개념적 모델링을 논리적 모델링으로 바꾸는 문제들이 그거였구나)
관계의 분류
존재한다와 행위한다.
관계의 표기법
https://dataonair.or.kr/db-tech-reference/d-guide/da-guide/?mod=document&uid=278 참고
관계명:
관계차수 (1:M , 1:1 , M:N ) :
두 엔티티간의 관계에서 참여자의 수를 표현하는 것을 관계차수라고 함.
한 개가 참여하는 경우 실선, 다수가 참여하는 경우는 까마귀발과 같은 모양으로 표기
선택필수 참여관계:
외래키쪽에 NULL 포함시키는 케이스
표현법:
내가 조심해야될건 점선! 0개도 포함됨