김용주님의 블로그

DB Chapter 4

19 Apr 2019 |

Ch.4:High-Level Database Models

1.The Entity/Relationship Model

E/R Model(Diagram)은 High-Level Design의 가장 대표적인 모델이다. 기본적으로 DB Modeling은 High-Level Design, Relational DB Schema, Relational DBMS 3가지를 통해 구현한다.

DB4_1

  • Rectangle : Entity(table)
  • Diamond: Relationship between entity
    • 어떻게 Relationship을 만들 것인가? 2개의 entity에서 모든 information을 가져올 필요 없이 각 entity의 primary key만을 가져오면 모든 정보에 접근 가능.
    • Relationship의 key의 설정은 지난 chapter에서 다뤘다.
  • Oval: Attribute
  • Multiplicity Relationship(Many:Many, Many:1, 1:1)
  • Arrow: M:1일때(Many to 1) 화살표가 가리키는 곳이 1
    • Round arrow: exactly one
    • Arrow pointing to: at most one(0 or 1)

Multiway Relationship

entity가 3개 이상인 relationship. 아래는 three-way relationship의 예시다. figure 2를 아래와 같이 표현할 수 있다.

DB4_2

위 그림에서 Movie를 예능이라고 생각하고 star에 해당하는 사람 중 유재석이 있다고 예를 들자. 그리고 그는 아래와 같이 계약을 맺었다.

  1. 유재석, 무한도전, MBC
  2. 유재석, 놀러와, MBC
  3. 유재석, 런닝맨, SBS
  4. 유재석, 해피투게더, KBS

특정한 star가 특정한 예능을 찍기 위해 특정한 studio와 계약을 했다. 그러면 Relationship인 Contract는 3가지의 entity에 영향을 받게 된다. 그리고 사람과 예능이 정해지면 studio는 자동으로 정해지기 때문에 studio쪽으로 arrow가 있다.

Roles in Relationship

하나의 entity의 정보에 따라 해석이(?) 다르면 그거도 way로 친다. 어려우니까 예시를 하나 들자. 아래의 그림에서 영화의 경우 첫 영화 다음 속편이 있는 경우가 있다. 그래서 original 영화와 sequel 영화의 접근이 relationship에게는 다른 것이다. 이 경우 2-way relationship이 된다.

DB4_4

뭔가 이해하기 어려우니까 예시를 하나 더 봅시다ㅏㅏ

DB4_3

교수님께서는 이거도 유재석을 예시로 설명해 주셨다. 유재석이 KBS와 전속계약을 맺었는데 MBC가 유재석과 무한도전이라는 프로그램을 하고 싶어한다. 그 경우 KBS가 허락을 해줘서 유재석은 MBC와 무한도전이라는 프로그램으로 계약을 하게 된다. 다른 프로그램의 경우 다 KBS지만 무한도전의 경우는 MBC인 것이다.

star: 소녀시대, movie: 해피투게더, studio of star: SM, producing studio: KBS

Attributes on Relationships

Relationship에도 attribute가 붙을 수 있다. attribute는 entity로 연결되는 것보다 attribute 자체가 relationship에 붙어 있는 것이 더 좋을 경우 붙인다. 아래 그림에서는 salary는 따로 entity를 만드는 것보다 attribute를 contract에 붙이는 것이 더 낫다. studio의 경우는 분리되어 있는 것이 더 낫다.

relationship에 attribute를 붙이냐 아니면 entity를 쓰냐는 중요하지 않다. 근데 편리해서 쓰는 것일 뿐이다.

DB4_5

salary가 movie에 붙어있으면, salary가 star에 붙어있으면, contract에 붙어있으면 각각 어떻게 될까 생각해보자

Converting Multiway Relationships to Binary

data model인 UML, ODL의 경우 relationship이 항상 binary여야만 한다. 그래서 binary 형태로 바꿔야 하는데 contract를 기준으로 movie, star, studio로 연결되는 relationship을 새로 만들어서 서로를 연결하는 다리로 사용하면 된다. contract는 relationship에서 entity로 바꾸고.

Subclasses in the E/R Model

subclass = special case = fewer entities = more properties.

예를 들어 학생은 학번을 가지고 있지만 군필인 학생은 군번도 가지고 있다. 이 학생은 special한 case다. 또 다른 예로는 새 책과 중고책이 있다. 새 책이 가지고 있는 정보 + 이전 사용자의 정보까지 가지고 있다면 중고책인 것이드아아아아. 세모로 isa를 표시해서 사용한다.

DB4_6

다른 예시로는 영화가 있다. 카툰의 경우는 성우의 목소리가, 미스테리의 경우는 살인에 사용한 무기가 보통 영화에 비해 더 추가가 된다. 그러면 카툰이면서 미스테리인 경우에는 attribute가 movie에 있는 4가지에 voice, weapon이 더해져 6개가 된다.

Subclasses를 relation으로 바꾸는 방법에는 3가지가 있다.

  • E/R style
  • Object-oriented: 각각의 class가 entity를 가진다. 모든 attribute를 그 클래스에 다 넣는다.
  • Use nulls

사실 이해하기 어려우니까 예시가 직빵이다.

DB4_7

중고책이라는 subclass에 대한 E/R Diagram이다. 이를 위에 나타난 3가지를 적용해서 relation을 만들면 아래와 같다.

DB4_8

이건 section 6에서 더 다룰 것이다.

2. Design Principle

5가지의 원칙

  • Faithfulness: 현실에 있을만한 거로
  • Avoiding Redundancy: 중복은 피하자
  • Silplicity Count: 진짜 필요한 element만. 필요없는 애는 다 지워라.
  • Choosing the Right Relationships: relationship이 필요없으면 지워도 된다. data를 원하는 사람이 어떤 정보를 원하냐에 따라 필요한 relationship
    • figure 2에서 하나의 star가 하나의 영화에만 나오면 stars-in은 굳이 필요없음
  • Picking the Right Kind of Element: 아래의 조건을 entity E가 만족하면 attribute로 나타낼 수 있다.
    • E는 many to one에서 one에 해당해야 한다
    • E의 attribute가 2개 이상이면 모두 key여야 한다.
    • E랑 연결된 relationship은 하나만 있어야 한다

3. Constraints in the E/R Model

  • Key: E/R Diagram에서 key에 해당하는 모든 attribute는 밑줄로 표시.
  • Single-value constraints
  • Referential integrity constraints: round arrow는 null이 허용되지 않는다.
  • Domain constraints
  • General constraints

4. Weak Entity Sets

entity에 있는 attribute만으로는 정보를 정확하게 표현할 수 없는 entity. double rectangle로 표현. 이럴 경우 supporting을 해서 다른 relation과 연결해 줘야한다. 이 도와주는 친구를 supoorting relationship이라고 하고 double diamond로 표현.

DB4_9

contracts의 salary만 가지고는 아무것도 할 수 없다. 그래서 3개의 supporting을 통해 weak entity에 있는 attribute가 쓸모있어 지게 된다.

5. From E/R to Relational Designs

entity는 모든 attribute를 relation(표)에 표현한다. relationship은 각 entity의 key들을 attribute로 해서 relation을 표현한다. 맨위에 있는 그림인 figure 2를 예시로 들면 movie(title, year, length, genre), own(tite, year, studioname)이다. Roles in relation에 나오는 그림의 contract의 경우는 contracts(starName, title, year, studioOfStar, producingStudio) 이렇게 나타낼 수 있다.

Combining Relations

Relation 두개를 짬뽕하는 것인데 netural join을 생각하면 된다. many to many의 경우 tuple이 너무 많아질 수 있으니 가능하면 many to many는 따로 분리하고 many to one의 경우만 합치자.

Handling Weak Entity Sets

Weak entity의 경우는 아래의 예시를 통해 확인하자.

DB4_10

  • weak entity: crew(number, crewChief, studioName)
  • supporting relationship: unit-of(number, stuioName, name)
  • entity: studios(name, addr)

여기서 unit-of의 경우 studioName과 name의 data가 동일해서 사실상 2개의 attribute만 남아있는데 이는 전부 crew에서 표현될 수 있다. 그래서 굳이 unit-of의 relation은 만들지 않는다. 그리고 가끔 entity까지도 weak entity의 부분집합이 되는 경우가 있는데 그렇다면 entity도 굳이 안만들어도 되지만 실제로는 그럴일이 거의 없다. 실제에서는 data가 엄청나게 많이 연결되어 있을 거니까.

6. Subclass to Relations

section 5는 사실 이것을 하기 위해 만들어졌다. 앞에서도 잠깐 다뤘는데 3가지 접근 방식이 있다.

  • E/R style: isa를 사용해서 key를 뽑아서 entity에 합쳐 만듦
  • Object-oriented(OO): 각각의 entity마다 class를 하나씩 만듦.
  • Use nulls: relation 하나에 다 때려박음

역시 이런건 예시를 통해 봐야 직빵이다. figure 10을 다시보자.

DB4_6

3가지 접근으로 했을 때 어떤 Relation이 생길지 확인해 보겠다.

E/R Style Conversion

  • Movies(title, year, genre, length)
  • Cartoons(title, year): voice가 왜 없냐 하겟지만 그 정보는 따로 저장해 놓고 사용한다.
  • Murder-Mysteries(title, year, weapon)
  • Voices(title, year, starName)

Cartoon은 어차피 저거 2개밖에 없으면 지워도 되는게 아니냐 하겠지만 소리가 없는 무성카툰(톰과제리 같은거)의 data는 cartoon에만 들어있기 때문에 지우면 안된다. Design priciple 1번인 faithfulness를 기억하자.

OO Approach

  • Movies(title, year, genre, length)
  • MovieC(title, year, genre, length)
  • MovieM(title, year, genre, length, weapon)
  • MovieMC(title, year, genre, length, weapon)
  • Voices(title, year, starName)

아예 각각 따로 모든 정보를 가지고 있다. 너무 정없어 보인다.

여기서 Movie와 MovieC가 똑같다고 해서 합치려고 하면 안된다. 안에 들어있는 data가 다르기 때문. 합치고 싶으면 non-cartoon이라는 relation을 새로 만들어야 할 것이다.

만약 voice가 many to one이라면 cartoon의 정보가 들어가있는 relation에 voice attribute를 다 넣고 voice는 지워도 된다. 즉, MovieC(title, year, genre, length, starName) 여기서 voice는 relationship임을 잊지 말자.

Using Null

Movie(title, year, length, genre, weapon)

없는 정보에는 null을 채워놓으면 된다. 엄청나게 큰 하나의 table.

Comparison of Approaches

이게 하이라이트인데, 저 세 가지 방법 중 어떤 방법이 가장 좋을 것인가에 대한 문제다. 당연히 우리는 relation을 적게 보고 싶고 필요한 data만을 보고 싶다. 예시를 보자.

  1. 2008년에 개봉한 영화 중 150분 이상 상영되는 영화는?
  2. 상영 시간이 150분 넘는 카툰에서 살인에 사용한 무기는?

1번에 대해 E/R로 접근하면 movie만 확인하면 되지만 OO로 접근할 경우 4개의 relation을 다 확인해야 한다. 반면에 2번의 경우 E/R로 접근하면 3가지를 다 연결시켜서 확인해야 하지만 OO의 경우 MovieMC만 확인하면 한방에 가능하다.

그러면 null의 경우는 어떻게 되냐? null은 왠만해서 다 접근이 가능하다. 모두 다 때려박아서 wasting time, abnormalize등이 일어날 수는 있지만 relation은 항상 한개다. 근데 문제는 필요 없는 데이터도 너무 많다는 것이다. attribute도, tuple도 너무 TMI고 중복되는 값도 있기 때문에 가능하면 E/R, OO로 하자.

Related Posts