-
(edX stanfordOnline Databases: Modeling and Theory) UML to Relations컴퓨터/DB, SQL 2025. 5. 21. 01:27728x90반응형
https://www.edx.org/learn/databases/stanford-university-databases-modeling-and-theory
StanfordOnline: Databases: Modeling and Theory | edX
This course is one of five self-paced courses on the topic of Databases, originating as one of Stanford's three inaugural massive open online courses released in the fall of 2011. The original "Databases" courses are now all available on edx.org. This cour
www.edx.org
UML 모델링에서 관계형 스키마(modeling inter-relational schemas)로 디자인을 변환하는 것
In our case, we're looking at high level design in the UML data modeling subset which is then translated to relations and installed in a relational database system.
=> the UML data modling subset: UML 전체 중에서, 데이터 모델링에 관련된 부분만 따로 뽑은 부분 집합
translation process가 이 강의의 주제
5가지 개념을 사용한 설계가 하나의 조건만 만족하면, 자동으로 릴레이션(관계형 테이블)으로 변환될 수 있다.
조건: 모든 일반 클래스가 키를 가진다.
이제 5가지 개념을 배우고, 어떻게 릴레이션으로 변환되는지 배운다.
association을 translate 하는 법:
grabs a key from each side of the association
연관(association)을 기반으로 릴레이션을 만들었을 때 키는?
association: 두 클래스 간의 관계
if we have one dot dot one(1..1) or zero dot dot one(0..1) one on one side
then the other side would be the key.
The default key in the relation generated from an association is the combination of the PKs from the two classes in the association. When the association is many-one, the key can be made even smaller by eliminating the PK from the one side of the many-one association.
예시를 들어, 오른쪽 그려진 student - college association을 보자.
모든 학생들이 한 개 대학에만 지원할 수 있다고 하면 그림과 같이 표현된다.So that would tell us
that if we have this one dot dot one(1..1) on the right
that student ID would be a key for applied and indeedassociation relation을 굳이 만들지 않고, 한쪽 테이블에 fold in(병합)할 수 있다. fold: 릴레이션을 다른 관계 안으로 흡수하거나 병합할 수 있다.
보통 association을 따로 릴레이션으로 만드는데, 특정 조건이 충족되면 굳이 Association을 따로 만들지 않고 C1이나 C2 테이블에 합칠 수 있다.
왼쪽 그림: Each one on the right is related to exactly one on the left.
0..1 혹은 1..1인 side가 있다면,
Association 클래스를 지우고, 두 개 클래스만 남길 수도 있다
방법:
다 대 일에서 많은 쪽인 C2가 C1(0..1 혹은 1..1인 사이드)의 key까지 갖도록 하면 된다.
C2(k2,o2,k1)에서도 키는 k2다.
릴레이션에서 foreign key 사용과 같다.
k1은 foreign key다.
foreign key를 추가해서 별도의 릴레이션을 생략하는 것.
foreign key에 Null을 허용하면, 0..1인 케이스에도 사용할 수 있다.
언제 fold 할 수 있나?
- Association이 1:1 관계일 때
- 혹은 1:N 관계이고 "N" 쪽으로 A의 데이터를 넣을 수 있을 때
- 그리고 A가 단순한 연결 역할만 하고 있을 때 (속성이 많지 않거나 없음)
* 0..N일 때도 association을 fold-in 할 수 있긴 하다.
Q. Suppose we had 0..2 on the right-hand side, so students can apply to up to 2 colleges? Is there still a way to "fold in" the association relation in this case, or must we have a separate Applied relation?
A: Yes, there is a way.
Explanation
We might create relation Student(sID,sName,GPA,cName1,cName2), assuming null values are allowed. We can similarly fold in any 0..N or M..N multiplicity, although the bigger N is, the less sense this translation makes.
특별한 조건이 없으면,
관계 테이블은 두 foreign key의 조합만으로 키가 되고,
특별한 다중성이 없기 때문에 이 테이블을 다른 테이블에 흡수(fold)할 수도 없다
Applied에 date, decision 등 the attributes in the association class를 포함시킨다.
* "association 클래스: 연관되는 클래스 쌍 사이에 최대 하나의 관계가 있어야 한다"
The fact that UML assumes that when you have a relationship (association) between two classes,
there's at most one instance of that association between any two elements of the class.→ UML은 두 클래스 사이에 관계(association)가 있을 때,
→ 각 인스턴스 쌍 사이에는 최대 하나의 관계만 존재한다고 가정합니다.And that is, can be seen quite well in this relational schema
because we're assuming we have at most one relationship between any student and any college,
and then we have associated with that one relationship, the date and the decision.→ 이 가정은 관계형 스키마에서도 잘 드러나는데,
→ 학생과 대학교 간에는 최대 하나의 관계만 있다고 가정하고 있기 때문입니다.
→ 그리고 그 **하나의 관계(association)**에 대해, **날짜(date)**와 결정(decision) 같은 속성들이 연결되어 있습니다.cf) 한 학생이 여러 대학에 지원할 수 있다면, 추가 식별자가 필요하다.
* "자동 translation을 위해서, 일반 릴레이션(regular class)에 키가 필요하다"
association 클래스는 regular class가 아니다.
self-associations도 두 개의 서로 다른 테이블로부터 연관 클래스를 만들 때와 동일하게 만든다.
다만 attirubte name만 바꾸면 된다.
본캠퍼스와 분교 캠퍼스가 있을 때,
둘의 연관 클래스를 만들어보자.
이때 home: satellite의 관계는 1..1:0..10의 관계다
1..1이 있을 때 반대편이 키가 되므로
Branch 연관 클래스에서 satellite이 key다.
subclass를 디자인하는 3가지 방법 Translation 1 has one tuple for each object, plus one more for each time an object is in a subclass.
Translation 2 has one tuple for each object, plus one more each time an object is in more than one subclass.
Translation 3 has one tuple for each object regardless of subclassing.
Q. Consider a superclass S with some number of subclasses. Suppose the subclassing relationship is incomplete (partial) and overlapping. Let size1, size2, and size3 denote the total number of tuples using translation schemes 1, 2, and 3. How are these three values guaranteed to be related for any data?
A: size3 <= size2 <= size1
(2) 모든 정보가 sub class에 있다.
super class에는 super class이고 어느 sub class에도 속하지 않은 인스턴스들이 들어간다.
(super class will only be used for objects that are in the super class but not in any of the sub classes)
Best Translation은 sub class relationship의 properties에 따라 달라진다
overlapping vs disjoint, complete vs incomplete
overlapping: 여러 sub class에 포함될 수 있음
disjoint는 여러 sub class에 포함될 수 없는 것
complete: super class에 속하는 인스턴스는 sub class에도 포함됨
incomplete: 어떤 sub class에도 포함되지 않을 수 있음
어떤 디자인을 적용하는게 좋을까?
i) overlapping 특성을 가졌다면
3번 방식으로 디자인하는게 좋을 수 있다.
한번에 모든 특성을 파악할 수 있기 때문. assemble하지 않아도 된다.(rather than needing to assemble them from the different pieces)
ii) disjoint, complete 특성을 가졌다면
2번 방식(puts each object in individual sub class relation) 으로 디자인하되, super class를 따로 가지지 않아도 된다.(modified to only have sub class relations)
ss#: social security number
APStudent가 AP course를 1개 이상 들어야 한다는 현실 세계 조건이 있다면?
APStudent 클래스는 불필요한 클래스가 된다.
Took relation에 모두 있을 것이기 때문
could be eliminated based on the multiplicity
참가로 domestic Student 릴레이션에서 SSN도 unique하기 때문에 키가 될 수 있다.
이를 후보키(튜플을 고유하게 식별할 수 있는 속성 집합들)라 한다.
primary key가 아닌 다른 후보키 이기 때문에 alternate key(대체키)라고 한다.
하지만 지금 릴레이션을 작성한 방식에서는 오직 하나의 primary key만 보여주고 있어서
복수의 후보키를 정의하거나 명시적으로 구별하지 않는다.
CREATE TABLE Student (
student_id INT PRIMARY KEY,
ssn CHAR(11) UNIQUE, # sql에서 테이블 만들 때는, 이런 식으로 표현 가능
name TEXT
);용어 설명 candidate key 튜플을 고유하게 식별할 수 있는 속성 집합들 primary key candidate key 중 대표로 선택된 것 alternate key primary key가 아닌 다른 후보 키 sub class는 key가 없어도 된다.
super class에 key가 있기 때문.
association class도 key가 없어도 된다.
자동 translation을 위해서는 regular class에만 key가 있으면 된다.
(1) Composition
colleges contain departments.
solid diamond operator: composition operator
다이아몬드가 없는 쪽은 다이아몬드가 있는 쪽의 component다.
Department 릴레이션에 department가 속하는 college의 key를 쓴다
regular class가 아니기 때문에 department 릴레이션에 키가 없어도 된다.
* 다른 예시
(2) Aggregation
empty diamond: Aggregation operator
아파트 빌딩처럼.
belongs to 하는(속하는) 릴레이션의 key값인 attribute가 null일 수 있다는 차이점이 있다.
* 다른 예시
A country and a continent may have the same name.
PK specifies uniqueness within a class, so continent names must be unique only within continents, and ditto for countries.
모든 regular class에 key가 있다면 자동으로 릴레이션으로 변환될 수 있다.
반응형'컴퓨터 > DB, SQL' 카테고리의 다른 글