'DATABASE/Articles'에 해당되는 글 4건

  1. 2020.06.05 Define a “Subtype”
  2. 2020.01.23 Can a conceptual data model contain attributes?
  3. 2016.02.13 Define a “Thing”
  4. 2014.04.21 Modifying Foreign Key Definitions

Define a “Subtype”

DATABASE/Articles 2020. 6. 5. 16:54

항상 그러하듯이 'Subtyping'에 대해 일단 정의부터 내려보자.

 

Subtyping은 엔터티가 독립성을 유지한 상태로 엔터티 內 공통속성을 그룹화화는 과정이다.

위 정의에는 데이터모델링에 대한(특히 엔터티에 대한) 많은 개념이 들어가 있다.

위 정의를 바탕으로 Subtype/Subtyping에 대해 살펴보자.

 

엔터티의 독립성1)을 유지한 상태로 엔터티 내 공통속성을 그룹화하는 과정이라고 했는데,

공통속성 그룹화를 하는 이유는(즉, Subtype을 도출하는 이유는) 아래와 같다.

- 커뮤니케이션을 향상 시킬 수 있다.

- 모델단에서 강제적으로 비즈니스 룰을 적용하여 향후 데이터 정합성을 향상 시킬 수 있다.

 

간혹, 엔터티 통합/분할의 관점에서 Subtype을 얘기하는 경우가 있는데

맞는 얘기이긴 하지만 이게 전부는 아닌데, 아래와 같이 정의하여 Subtype을 결과론적 '행위의 결과'로만 이해(오해)할 수 있게 하는것은 바람직하지 않다고 생각한다.

굳이 이 얘기를 하는 이유는 최근 국내에서 가장 많이 팔린 모델링 책 중 하나에서 아래와 같이 정의했기 때문이다.

엔터티를 통합하거나 분리하는 행위의 결과가 서브타입입니다.

 

3가지 관점에서 Subtype을 정리해 보면...

 

1. Subtype 장단점

- 장점: Subtype을 도출하는 이유와 같다.

  . 커뮤니케이션을 향상 시킬 수 있다.

  . 모델단에서 강제적으로 비즈니스 룰을 적용하여 향후 데이터 정합성을 향상 시킬 수 있다.

- 단점: 무분별하게 Subtype을 도출할 경우

  . 모델을 복잡하게 하고,

  . 그에 따라 이해도가 떨어지고, ex) "왜 Subtype을 도출했지?"라는 불필요한 생각에 따른 에너지 소비 등..

  . 물리 모델 전환 시, 쓸데없는 고민을 하게한다. ex) 하나의 엔터티에 3가지의 경우의 수가 발생한다.

 

2. Subtype 도출시점

위에서 얘기한 두 장점이 필요한 시점이라고 생각한다.(물론 장점은 더 있을 수 있다)

즉, 개념모델링 단계일 수 도 있고, 논리모델링 단계일 수 도 있다.(주로 논리모델링 단계에서 도출된다)

하지만, 물리모델링 단계에서는 원칙적으로 도출할 수 없다. 이유는 Subtype은 RDB(Relational Database)에서 존재하지 않는 개념이기 때문이다.

 

3. Subtype 물리모델 전환 방법(가정: Subtype은 두 개)

방법1) Rolling down

Super type 엔터티를 제거하고, 모든 데이터 element 및 관계들을 Subtype엔터티로 이동 시킨다.(2개 Table)

 

방법2) Rolling up 

Subtype엔터티를 제거하고 모든 데이터 element 및 관계들을 Supertype 엔터티로 이동 시킨다.(1개 Table)

 

방법3) Identity: 

Supertype, Subtype 엔터티들을 모두 유지한다.(3개 Table)

 

 

 

1) 엔터티의 독립성은 너무 중요한 개념이다. 이 주제만으로 정말 많은 얘기를 할 수 있고, 그 만큼 중요하다.

하지만 그 주제에 대해 깊이 들어가지 않겠다. 알고있다는 전제하에 얘기하고자 한다.(궁금하신 분은 구글링하면 엄청 나오니 찾아보시길 바란다)

'DATABASE > Articles' 카테고리의 다른 글

Can a conceptual data model contain attributes?  (0) 2020.01.23
Define a “Thing”  (0) 2016.02.13
Modifying Foreign Key Definitions  (0) 2014.04.21
: Comments 0

Write a comment


Can a conceptual data model contain attributes?

DATABASE/Articles 2020. 1. 23. 18:11

이번에 소개할 내용은 

개념 데이터 모델(CDM, Conceptual Data Model)에 속성(Attribute) 도출을 해야하는가?

이다.

 

사실 필자는 개념 데이터 모델에 속성을 도출하는것을 지양하는 편이다.

이유는 개념 데이터 모델(이하 CDM)의 정의에서 찾을 수 있는데, 개념 데이터 모델의 정의를 먼저 살펴보도록 하자.

 

개념 데이터 모델(CDM, Conceptual Data Model) : 기호나 텍스트1)로 비즈니스의 개념을 잘 표현한 데이터 모델

즉, CDM으로 비즈니스의 개념을 잘 파악할 수 있어야 하는데, 속성이 도출되어 있을 경우 핵심인 '비즈니스의 개념'보다 해당 속성에 포커싱이 맞추어지는(또는 이슈가 되는) 경우가 생각보다 많이 발생한다는 것이다. 이와 같은 이유로 필자는 가급적 불필요한 논쟁(?)을 피하고자 CDM에서는 속성을 도출하지 않는 편이다. 여기에서 주의할 것은 일반적으로 이렇게 한다는 것이지 반드시 그렇다는 것은 아니다. 프로젝트 초기에 CDM을, 일반적으로 우리가 생각하는 CDM과 LDM2)사이로 정의한다면 CDM에 식별자 또는 후보식별자(Natural key, Business key 등)를 포함한 중요 속성도 함께 도출해야 한다. 이후 계속, 지겹게 얘기하겠지만, 데이터 모델링에 정확한 규칙이나 방법3)은 없다. 다양한 비즈니스 환경에 맞게 유연하게 진행해야한다. 그렇기 때문에 데이터 모델링이 어려운 것이다.  

 

원문

https://stevehoberman.com/can-a-cdm-contain-attributes/

 

1) 여기에서 '기호나 텍스트'는 데이터 모델링 표기법(Notation)을 말한다.

2) LDM(Logical Data Model)

3) 물론 정확한 규칙이나 방법은 없지만, 방법론, 기업 및 집단의 표준화된 규칙이나 방법은 존재한다.

'DATABASE > Articles' 카테고리의 다른 글

Define a “Subtype”  (0) 2020.06.05
Define a “Thing”  (0) 2016.02.13
Modifying Foreign Key Definitions  (0) 2014.04.21
: Comments 0

Write a comment


Define a “Thing”

DATABASE/Articles 2016. 2. 13. 18:28

세계적으로 유명한 데이터 모델러 중 한 사람인 스티브 호버만(Steve Hoberman)이라는 사람이 있다.

개인적으로 가장 좋아하는 데이터 모델러이기도 하다. 그의 블로그에는 데이터 모델링의 개념에 대해 여러 사람의 의견을 종합하여 쓴 컬럼을 연재하고 있는데, 그 중 괜찮다고 생각하는 글을 골라 소개하고자 한다.


첫 번째로, 데이터 모델링 관점에서 바라보는 "Thing"에 대해 얘기해보고자 한다.

사실 'Thing'에 대해 얘기하기 이전에 'Thing' 이라는 용어(Term) 자체의 의미를 이해하는 것도 쉬운게 아니다. 국내 유명 서적이나 업체에서 이를 '것'으로 번역 하기도 하는데, 필자는 올바른 번역이 아니라 생각한다. 아래는 Naver사전에서 검색한 Thing에대한 내용이다. 무려 10개 이상의 뜻이 있는데, 좀 길지만 잘 살펴보기 바란다. 생각보다 많은 것을 얻을 수 있다. 기본은 기본에서 시작해야한다.

그리고 중요한 개념이나 아이디어는 의외의 '곳'에서 얻어지곤 한다라는 생각을 새삼느꼈다.

무슨 생각이 드는가? 힌트는 푸른색 글씨를 잘 살펴보면 중요한 개념을 쉽게 이해할 수 있다.




명사

1.OBJECT | [C] (사물을 가리키는) 것[거]

Can you pass me that thing over there?

저기 있는 저거 나한테 좀 건네 주겠니?

She's very fond of sweet things.

그녀는 단것을 아주 좋아한다.

He's just bought one of those exercise things.

그가 얼마 전에 운동 기구인가 뭐 그런 것을 하나 샀다.

Turn that thing off while I'm talking to you!

내가 너한테 이야기 할 때는 그것 좀 꺼!

2.OBJECT | [C] (생명이 없는) 물건, 사물

Don't treat her like thatshe's a personnot a thing!

그녀를 그렇게 대하지 말아요. 그녀는 사람이지 물건이 아니란 말예요!

He's good at making things with his hands.

그는 손으로 물건들을 만드는 것을 잘 한다.

She took no interest in the people and things around her.

그녀는 자기 주변의 사람들과 사물들에 관심을 갖지 않았다.

3.POSSESSIONS/EQUIPMENT | [pl.] things (개인 소유의・특정한 용도를 위한) 물건, 소지품, 용품

Shall I help you pack your things?

네 물건들[짐] 싸는 거 도와줄까?

Bring your swimming things with you.

수영에 필요한 용품을 가지고 오너라.

I'll just clear away the breakfast things.

아침 먹은 것[그릇]들만 좀 치울게요.

Put your things on and let's go.

(외투 등 필요한) 옷을 입고 가자.

4.ANYTHING | [sing.] a thing (부정문에서 강조의 의미로 쓰여) 하나[아무것]

haven't got a thing to wear!

난 입을 게[옷이] 하나도 없어요!

There wasn't a thing we could do to help.

우리가 도울 수 있는 게 하나[아무것]도 없었다.

Ignore what he saidit doesn't mean a thing.

그가 한 말은 무시해. 아무 뜻도 없으니까.

5.FACT/EVENT/SITUATION/ACTION | [C] (사실・사건・상황・행동 등을 가리키는) 것, 일; 말; 생각

like campingclimbing and that sort of thing.

나는 캠핑, 등산 그런 것들을 좋아한다.

She said the first thing that came into her head.

그녀는 머리속에 맨 처음 드는 생각을 말했다.

Why did you tell her our secret?' ‘I did no such thing!'

“넌 왜 그녀에게 우리 비밀을 말했니?” “난 그런 짓[말] 안 했어!”

Let's forget the whole thing.

우리 모든 걸 다 잊어버리자.

There are a lot of things she doesn't know about me.

그녀가 나에 대해 모르는 것이 많다.

There's another thing I'd like to ask you.

제가 (당신께) 여쭤 보고 싶은 것이 또 한 가지 있어요.

A terrible thing happened last night.

간밤에 끔찍한 일이 발생했다.

He found the whole thing very boring.

그는 그 모든 것[일]이 아주 지루했다.

I've got loads of things to do today.

난 오늘 할 일이 태산 같다.

The main thing to remember is to switch off the burglar alarm.

기억해야 할 주요한 것이 도난 경보기를 끄는 것이다.

6.FACT/EVENT/SITUATION/ACTION | [pl.] things (어떤 사람에게 영향을 미치는) 상황[사정/형편]

All things consideredshe's done very well.

모든 사정을 고려해 보면 그녀가 아주 잘 했다.

Why do you make things so difficult for yourself?

당신은 왜 상황을 당신 자신에게 그렇게 힘들게 만들어요?

Things haven't gone entirely to plan.

상황이 전적으로 계획대로 되지는 않았다.

HiJaneHow are things?

안녕하세요, 제인! 요즘 (형편이) 어떠세요?

Think things over before you decide.

결정을 하기 전에 상황을 잘 따져 보아라.

As things stand at presenthe seems certain to win.

상황이 현재와 같다면 그가 확실히 우승할 것 같다.

7.WHAT IS NEEDED/RIGHT | [C] [주로 단수로] <필요한 것・사회적으로 마땅한 일>

You need something to cheer you up—I know just the thing!

당신에겐 기분을 북돋워 줄 뭔가가 필요한데, 내가 바로 그것을 알고 있어요!

to say the right/wrong thing

옳은/잘못된[해서는 안 될] 말을 하다

The best thing to do is to apologize.

가장 좋은 것은 사과를 하는 것이다.

8.THINGS OF PARTICULAR TYPE | [pl.] things [뒤에 형용사가 함께 쓰여] (격식) <그 형용사로 묘사될 수 있는 모든 것들>

She loves all things Japanese.

그녀는 일본 것이라면 뭐든 아주 좋아한다.

9.CREATURE | [C] [형용사와 함께 쓰여] 생물

All living things are composed of cells.

모든 생물체는 세포로 구성되어 있다.

10.PERSON/ANIMAL | [C] [형용사와 함께 써서] (비격식) 것(어떤 감정과 함께 사람・동물을 가리킬 때)

You silly thing!

이 멍청한 것!

You must be starvingyou poor things.

배가 아주 고프겠구나, 이 불쌍한 것.

The cat's very illpoor old thing.

고양이가 아주 많이 아파요, 불쌍한 게 나이가 들어서.





위에서 말한 것 처럼 Thing을 '것'으로 번역한 이유는, 가장 많이 쓰이는 표현이 사물을 가리키는

즉, Object의 의미로서 Thing을 '것'으로 표현한 것으로 생각되는데... 5,6번째 뜻에서 'Action'이라는 단어에 주목하길 바란다. 보통 데이터 모델링을 할때 Action은 주로 관계로 표현 한다.. Thing에는 단순히 Object의 의미뿐만 아니라 Action의 의미도 내포하고 있다는 것을 알 수 있다. 이러한 이유로 필자는 Thing을 '것'으로 번역하는것을 옳지 않다고 생각한다. 글쓴이는 국외 IT용어를 무리하게 한글화하는 것은 지양해야한다는 지론을 가지고 있다. 특히 데이터 모델링은 개념에 대한 용어들이 많은데 이를 한글화 할 경우 의미를 너무 축소 또는 변질할 수 있는 가능성이 크기 때문이다. 사설이 길었다. Thing에 대한 개념들은 아래와 같은데 그 정의를 한 번 내려보자.



1. Party

'Party'는 비즈니스와 관련있는 사람 또는 조직이고, 비즈니스를 수행하는 구성원이자 주체이다.


예) 

사원, 고객, 담당자, 업체


관계어)

Involved Party, Legal Entity, Business Partner


2. Document

'Document'는 비즈니스적으로 중요한 것이 기록된 물리 또는 전자적 지식/정보 항목이다.

실제로 존재하는 문서일 수도 있고, 가상형태로 존재할 수 도 있다.


예) 

종이/전자 청구서(송장)


관계어)

계약(Contract), 합의(Agreement)


3. Classification

'Classification'이란 비즈니스에 관계된 events/activities/things를 어떤 목적을 위해 공통적인 속성이나 기능 등을 중심으로 분류하여 그룹화 하는 과정(arrangement)이다.


예)

사업부 내의 부서, 연봉 등급 등


4. Association

업무와 관련이 있는 두 개 이상의 'Thing'간의 관계


예) 

전통적인 예로서 교사와 학생을 들 수 있고, 강의실에서 그 둘 간의 관계가 형성된다.


관계어)

Relation


※중요

'Association' 이라는 개념은 신중히 사용해야한다. 매우 모호한 용어이기때문에 Party같이 상위 개념을 연결할 때만 사용하는것이 좋다.


5. Transaction 

- 저장해야한 비즈니스 이벤트(작은 단위의 이벤트라도 그만한 가치가 있다면 저장할 필요가 있다)

- 상황의 변화를 주는 어떤 사건의 발생


예) 거래, 현금이체, 물품, 이미 정의된 상품 또는 서비스의 거래


관계어)

비즈니스 이벤트, 활동(Activity)




원문

http://stevehoberman.com/2014/12/define-a-thing/#comments


'DATABASE > Articles' 카테고리의 다른 글

Define a “Subtype”  (0) 2020.06.05
Can a conceptual data model contain attributes?  (0) 2020.01.23
Modifying Foreign Key Definitions  (0) 2014.04.21
: Comments 0

Write a comment


Modifying Foreign Key Definitions

DATABASE/Articles 2014. 4. 21. 16:32

최근 Information Management 스티브 호버만(Steve Hoberman)이 재미있는 글을 하나 올려서 소개합니다.

 

대충 내용은 ERWin등 모델링 툴에서 부모테이블의 Primary key를 자식테이블에서 Foreign Key로 지정했을때, 

부모테이블 컬럼의 definition을 자식테이블에서

  - 그대로 사용하느냐?

  - 마느냐? 

  - 아니면 재정의 하느냐?

에 대해 여러 모델러, 아키텍트들의 의견 입니다.

보통 모델링을 하면서 이 부분은 크게 문제삼지 않거나, 그냥 넘어가는 경우가 많은데...

이 내용으로 3페이지 분량을 다루고 있는게 흥미롭네요^^

 

참고로 저는

  1) 초기에는 부모테이블의 Key definition을 정의하고, 상속받을 경우 자식테이블의 Foreign key definition을 수정하지 않습니다.

    - 이 시기에는 부모테이블의 컬럼의 정의가 변경될 경우가 많기 때문

    - Rolename 지정 컬럼 포함

  2) 관계명을 표기합니다.

  3) 모델검토 완료 후 definition 재정의

    - 단일관계 : 재정의가 필요하다고 판단되는 경우에 한해서만 재정의

    - 다중관계 : 무조건 재정의

와같이 작업을 합니다.

여러분은 어떠하신지요?



When we create a one-to-many relationship between two entities, we copy the primary key from the entity on the one side (the parent entity) over as a foreign key to the entity on the many side (the child entity). We traditionally copy over all of the metadata associated with the primary key such as name, format and definition. The one exception where a foreign key can have a different name than its primary key is when there is more than one relationship from the same entity. To avoid having two or more data elements with the same name in the same entity, we "role name," meaning giving the foreign key a different name than its primary key.

For example, in the data model below, in Employee we have a foreign key back to Employee Type which has the same name as its primary key (Employee Type Code), and we have two foreign keys in Customer that point back to Employee. These two foreign keys are role-named to avoid having Employee ID twice in the Customer entity and to provide additional meaning as to what the foreign key represents. Primary Contact Employee ID points back to the Employee who is the primary contact for this Customer, and Initial Contact Employee ID points back to theEmployee who initially made contact with this Customer. 

In this data model, the definition for Employee Type Code is as follows:

Employee Type Code is a numeric value assigned to each organization-wide understood category for an Employee. These codes have business significance and are for human resources internal use only. Examples:

01 = Full time

02 = Part time

03 = Retired

And the definition for Employee ID is:

Employee ID is the unique, mandatory and stable business key for each Employee. It is assigned by human resources and used throughout the organization. Example: Bob Jones is assigned the Employee ID 123-AB-872123

Definitions also copy over from primary key to foreign key, so the Employee Type Code foreign key in Employeehas the same definition as Employee Type Code in Employee Type, and Primary Contact Employee ID andInitial Contact Employee ID have the same definition as Employee ID in Employee.


The Challenge

Should we at times modify the foreign key definitions so they are more relevant to the relationship they represent? After all, if I just see the Employee ID definition in Primary Contact Employee ID, it is not very descriptive.

What guidelines would you apply in deciding whether a foreign key should have a different definition than its primary key?


전문은 아래와 같고, 회원가입을 하셔야 보실 수 있습니다.

http://www.information-management.com/news/modifying-foreign-key-definitions-10025585-1.html





'DATABASE > Articles' 카테고리의 다른 글

Define a “Subtype”  (0) 2020.06.05
Can a conceptual data model contain attributes?  (0) 2020.01.23
Define a “Thing”  (0) 2016.02.13
: Comments 0

Write a comment