(edX stanfordOnline Databases: Modeling and Theory) UML Data Modeling, multiplicity

https://www.edx.org/learn/databases/stanford-university-databases-modeling-and-theory

StanfordOnline: Databases: Modeling and Theory | edX

 

UML은 데이터베이스 디자인 뿐만 아니라 프로그램 디자인에도 사용된다.

연관관계의 다중성

0..N: 0개에서 N개의 객체와 관계될 수 있다.

고객과 주문처럼 주문이 없을 수도 있고 여러 개일 수도 있다

 

0..*: 0이상 무한대 이하

다중성에 아무런 제한이 없음(basically no restrictions on the multiplicity)

*로 축약될 수 있다

 

1..1: 1로 축약 가능

UML에서 두 클래스가 관계를 가질 때, 다중성을 어느 쪽에 써야 하는지 헷갈릴 수 있다

(It really takes some thinking sometimes to remember which side to put the specification on.)

 

fan out: 어떤 하나의 객체가 여러 객체와 연결되는 가지처럼 퍼지는 구조

한 객체가 다른 객체 여러 개로 뻗어나가는 fan-out 구조가 시각화되도록 쓴다

fan out from left to right

 

* one to one: 모든 것이 관계되어야 한다는 의미 아님

최대 1개 관계된다는 뜻임

0..1이 양쪽에 있어야 함

 

* many-to-one

many elements of C1 related to at most one element of C2

*    0..1

 

* many-to-many

*  *

 

* complete

complete relationship is complementary to these others.

Every object must participate in the relationship.

 

complete one-to-one: 1..1   1..1

complete many-to-one: 1..*   1..1

complete many-to-many: 1..*   1..x

 

명시하지만 디폴트로 complete one-to-one relationship이다.

 

* multiplicity

UML에서 association(연관) 양쪽에 붙은 숫자는 **multiplicity (다중성)**이라고 부르며,

관계에 참여할 수 있는 **객체의 수(개수 범위)**를 의미한다.

Q .This UML diagram puts some constraints on the cardinalities of classes A, B, and C. Which of the following combinations of cardinalities is permitted? (Note: The cardinality of a class C, denoted |C|, indicates the number of objects in the class.)

 

A: |A| = 10; |B| = 1; |C| = 10

 

Explanation:

Association R says that for each A there is exactly one B.

Thus, if there are any A's at all, then there must be at least one B.

However, there are no other constrants relating |A| and |B|.

=> A의 cardinality가 양수이면, B의 cardinality도 양수여야 한다.

 

Q. UML에서 왼쪽(B)이 0..1, 오른쪽(C)이 1..1이면 무슨 뜻인가?

 

For each B there is exactly one C, and for each C there is at most one B.

Thus, |B| ≤ |C|.

=> 그럼 현실 예시로 B: 차, C: 주차 공간인듯

 

 

 

 

 

 

연관 클래스

관계자체에 정보가 붙는다.

두 클래스 사이의 관계에 자체 속성/정보를 부여하기 위한 특수 클래스

관계 자체를 '객체화'해서 속성을 담을 수 있도록 만든 클래스

 

예: 학생(Student) ↔ 수업(Course)

• 일반적인 association: 학생은 여러 수업을 듣는다
• 그런데 관계에 이런 속성이 필요할 경우:

관계 정보예시

등록일(Date)	학생이 수업에 등록한 날짜
성적(Grade)	수업에서 받은 점수
수강 여부(Decision)	수강 승인됨, 대기 중, 거절 등

 

→ 이런 정보는 학생-수업 관계에 붙지만, 학생이나 수업 단독 객체에는 해당 안 됨

→ 이럴 때 association class가 필요함!

 

* 왜 필요한가?

UML 제한 사항

동일한 두 객체 사이에 여러 개의 관계를 표현하는 데 제약이 있다

(What we cannot describe in UML is the possibility of having more than one relationship or association between the same student and the same college.)

• 현실에서는 "같은 두 객체 사이에 여러 번의 관계"가 자주 있음:
  • 고객이 같은 상품을 여러 번 구매
  • 학생이 같은 수업을 여러 학기에 수강
  • 환자가 같은 병원에서 여러 번 진료

하지만 UML의 일반 association으로는 이런 "복수 관계"를 표현하기 어렵다

이럴 때 association class를 사용하거나 중간 클래스를 직접 생성한다.

 

 

 

위 이미지에서 fan out이 아니라 fan in이어야 한다

Association Class의 attribute들을 C1 하위로 넣으면 seperate association class를 제거할 수 있다.

self association에서 각 end에 라벨을 붙일 수 있다. (home, satellite)

The little vertical line below Student should be an up-pointing arrow with a hollow arrowhead.

Association Took: one of AP students takes the course

disjoint (배타적)	하나의 인스턴스는 하나의 서브클래스에만 속할 수 있음
overlapping (겹침 가능)	하나의 인스턴스가 여러 서브클래스에 동시에 속할 수 있음
complete (완전)	슈퍼클래스의 모든 인스턴스가 반드시 어떤 서브클래스에 속함
incomplete (불완전)	슈퍼클래스의 인스턴스 중 일부는 어느 서브클래스에도 속하지 않을 수 있음

 

위 학생 예시에서 AP student 관련된게 없다면
=> complete, disjoint

 

위 학생 예시에서 foreign, domestic 이 없다면

=> incomplete

 

composition: 속이 찬 다이아몬드

부분이 전체에 종속됨 (전체가 사라지면 부분도 사라져야 함)

 

aggregation: 속이 빈 다이아몬드

연결만 되어 있고 독립적 존재

ex.아파트가 한 개 college에 속하거나 속하지 않거나 할 수 있다