Ch.6: The Database Language SQL

1.Simple Queries in SQL

Select: projection

From: data를 어디서 가져올 것인가?

Where: selection

select A as B: A를 B로 rename

Like %a: 마지막에 a로 끝나는 string을 select

Like %``s%: 중간에 ‘s가 들어가는 string을 select

union, intersection, difference(SQL에서는 except, Oracle에서는 minus)

3. Subqueries

함수안에 함수를 선언하는 느낌

Conditions Involving Relations

• s IN R: s가 R에 있으면 True 아님 False
• EXIST R: relation R이 empty가 아니면 True
• s > ANY R: R에 s보다 큰 값이 1개라도 있으면 true
• s > ALL R: R에 있는 모든 값이 s보다 커야 true

SQL Join Expression

• A natural join B : natural join
• A join B on a.x < b.x(조건) : theta join
• A cross join B : product
• A full(left, right) outer join B

기본적으로 select, from, where는 bag이고 union, intersection, difference는 set임.

bag를 set으로는 distinct를 사용하고 set을 bag로는 union all처럼 뒤에 all을 붙여주면 된다.

Aggregation, group by, having

DB modification: insert, delete, update 3가지가 전부

###

6. Transaction in SQL

Serializability : waiting until finish

기차좌석 예약할 때 하나의 seat를 예약하고 잇으면 그 seat는 다른 user는 사용할 수 없음.

Lock system임. 처음 들어간 사람이 lock걸음.

Commit과 rollback. Rollback은 스크린 올리는거고 commit은 스크린 내리는거(뭔소리람?)

Commit: we changed real data

Roollback: undo

Atomicity: 동시에 하는거

계좌에서 송금할 때 동시에 보내는 계좌에서는 돈이 빠져나가야하고 받는 계좌에서는 돈이 들어와야 함.

User와 bank의 SQL이 각각있는데 그거를 하나의 SQL로 합쳐서 다뤄야 동시에 파바박 됨. 이게 Atomicity.

transaction: process가 작업중인데 data값의 수정이 일어나는 것.

dirty read: 아직 commit되지 않은 data의 수정이 일어나 잘못된 값이 commit 되는 경우

계좌 송금의 경우 dirty read가 일어나면 critical 하지만, 좌석 예약의 경우 한 명의 사용자가 예약을 실패할 뿐 그게 다임.

이건 그냥 외우자 달달달달달~달 무슨달~

Ch5. Algebraic and Logical Query Languages

1. Relational Operation on Bags

Relational algebra: operand가 relation인 algebra

Aggregate: sum, avg등

• Union, Intersection, Difference n: R의 원소 갯수, m: S의 원소 갯수

  • Union: R U S = n+m

    {1,2,1} U {1,2,3,3} = {1,1,1,2,2,3,3}

  • Intersection: R n S = min(n, m)

    {1,2,1,1} n {1,1,2,3,3} = {1,2}

  • Difference = {1,3,1,1} - {1,3,3,5} = {1, 1}

  bag에서는 분배법칙이 성립하지 않음.

• Projection

• Product

• Join

2. Extended Operators of Relational Algebra

• Distinct: 중복되는거는 하나만 나오게 한다. $\delta(R)$

• Aggregation(relational operator는 아님): Sum, Avg, Max, Min, Count

• Grouping: 어떤 attribute를 기준으로 group화 해서 sorting할 것인지 정함. L을 기준으로 R을 group $\gamma_L(R)$

• Extended Projection: projection을 한 번에 여러번 할 수 있음

• Sorting: 보통은 오름차순으로 sort. $\tau_L(R)$

• Outerjoin: join을 했을 때 서로 겹치는 게 없어도 data를 사라지지 않게 함.

R하고 S에 left outerjoin을 하면 R에 해당 하는 부분은 NULL이 없어야 하고 right는 S에 해당하는 부분에는 NULL이 없어야함.

3. A Logic for Relations

logical rule은 대부분의 정보를 합치는 시스템의 기반임

Predicate는 변수가 있고 그 변수의 값에 의해 True/False가 결정.

Atom: 각각의 독립변수(argument)에 의해 값이 결정되는 predicate

Datalog Rules: 2가지가 있음. 예시를 통해 봅시다.

S(x,y) <- R(x,z) AND R(z,y) AND NOT R(x,y)

여기서 S(x,y)를 head, <- 를 if, 오른쪽에 있는 애들을 body, 오른쪽의 atom(R(x,z) 등)을 subgoal이라 부름

R = {(1,2), (2,3)}

1. Variable-based

   R(x,z)가 R(1,2)가 되고, z가 그대로 R(z, y)에 들어가 R(2, y)가 됨. 그럼 R안에 2,y를 만족하는 값은 3이므로 y=3이 됨.

2. Tuple-based

   Tuple을 전부 나열하고 나서 관계 없는 값들을 지워나감.

   

   이 그림을 봤을 때 1,3,4번 tuple은 z의 값이 일치하지 않고, 1, 4번째 tuple은 R에 이미 같은 값이 있음. NOT R(x,y)인데 R(1,2)나 (2,3)이 R에 있으므로 제거. 그래서 2번만 남게 됨.

Safety

head나 negated relational subgoal이나 any arithmetic subgoal에 나타나는 any variable은 무조건 nonnegated, relational subgoal 에 나타나야 한다. 뭔소릴까요? 예시를 봅시당

P(x,y) <- Q(x,z) AND NOT R(w,x,z) AND x<y

여기서 head에 나타나는 variable은 x,y, negated relational subgoal에서는 w,x,z, arithmetic subgoal에는 x,y가 나온다.

그러면 하나씩 보는데 x와 z는 Q라는 nonnegated, relational subgoal에 나타나지만 w,y는 그러지 못하기 때문에 safe하지 못함.

Extensional and Intensional Predicates

Extensional: 실제로 DB에 저장되어 있는 predicate

Intensional: 그냥 룰만 지킴

Datalog Rules Applied to Bags

예시를 봅시다

위에꺼 만족하는거 3개, 아래꺼 만족하는거 1개, 겹쳐도 갠춘 합쳐서 4개~

###

4. Relational Algebra and Datalog

• Boolean operation(union, intersection, difference)

• Projection

  • Movies(t, y, l, g, s, p)에서 t, y, l을 projection 할 경우

    P(t, y, l) <- Movies(t, y, l, g, s, p)

• Selection

  • 길이가 100이상이고 s가 Fox인 애를 찾을 경우

    S(t,y,l,g,s,p) <- Movies(t, y, l, g, s, p) AND l >= 100 AND s = ‘Fox’

• Product( AND가 만능임 )
  • P(a,b,c,x,y,z) <- R(a,b,c) AND S(x,y,z)

• Join

  • J(a,b,c,,d) <- R(a,b) AND S(b,c,d) [알아서 join 잘해줌]

  theta join 예시

  

• Multiple Operations with Datalog

  Selection에 쓰인 예시를 나눠서 풀수도 있는데 그거도 방법이 있음. relational algebra랑 별차이 X

  

Comparison Between Datalog and Relational Algebra

Datalog는 data의 중복이 안됨.

Datalog는 relational algebra로 항상 바꿀 수 있지만 역은 안댐

Datalog는 recursion이 가능.

Ch.3: Design Theory for Relational Databases

Terminology

• Redundancy: 여분
• Decompose:분해하다
• Decomposition
• Instance: Student = Class, 김용주 = instance

1. Functional Dependencies(FD)

design theory how to improve our designs by the process of “decomposition”

left side와 right side를 나누고 그 관계를 정의할 수 있으면 functional dependency. left에 있는 것들이 정해지면 right에 있는 것은 항상 같을 경우 FD임.

EX) students(SID, name, Dongari, DongBang)

• Movies1의 instance들. 여기서 FD는 어떤것이 있는가?(Figure 6)

  

  • (title, year) → (length, genre, studioName)

    title, year가 같으면 오른쪽에 있는 것들은 항상 같음.

  • starName은 해당이 안된다. 그래서 이를 normalization.(분리해서 중복되는 tuple은 지움)

    

    title, year가 3개를 정의하므로 b에 해당하는 table을 만들어 더 간단하게 하고 title, year가 starName은 정의하지 못하니까 이를 기반으로 또 table Movies3을 만듬.

Keys of Relation

key는 uniqueness와 minimality를 만족함. 만약 key가 uniqueness만 만족하면 super key.

위의 그림을 예시로 들자면 key는 {title, year, starName}. 이 셋 attribute의 data가 정해지면 relation의 모든 component가 정해짐. super key는 {title, year, starName, length, genre} 같이 minimality는 만족하지 못함. 물론 key역시 super key에 포함됨.

• {T, Y} → {SN}이 {T, Y} → {SN, T, Y} 가능

  Many to one에서는 Many에 해당하는 key가 key. Many에 있는 key의 값이 결정되면 one에 있는 것은 자동으로 결정되기 때문.

  Many to many relationship의 경우 relationship에 있는 attribute 모두가 key. 애초에 many to many에서 가져온 attribute 자체가 모두 key임.

  One to one relationship의 경우 아무거나 해도 됨. 둘 중 하나가 나머지 하나를 정의해주기 때문.

2.Rules About FD

FD를 통해 알 수 있는 것

1. FD인 S와 T의 instance가 모두 같으면 equivalent
2. S의 instance가 T의 instance에 모두 포함되면 follow

Trivial FD

FD의 집합은 FD의 부분집합도 정의가 가능하다.

• {T, Y, SN} → {T} or {T, Y} or {T, Y, SN} 등등이 가능

Computing the Closure of Attributes

Closure: FD에 의해 포함되는 attribute들의 집합. 표기는 아래와 같다. $S^+$

주어진 FD가 A → B, BC → D라고 하자. 그러면 closure들은 이렇게 정의가 가능하다.

Algorithm 7 : Closure of a Set of Attributes

S는 FD의 집합이고, X는 처음 주어지는 closure라고 하자.

• figure 6을 이용해 Algo7을 확인해보자.
  1. {title, year} -> {length, genre, studioName}
  2. {title, year} -> {StarName} 은 포함 안댐. 즉, closure of {title, year}에 포함이 안댐(element가 아님).
  3. X = {title, year, length, genre, studioName}

Why the Closure Algorithm Works

• proof by induction

  1. {title, year} -> title, {title, year} -> year : trivial FD에 의해 basis condition 증명

  2. 그리고 set {title, year} -> {length}, {length} -> {genre}가 주어졌다고 했다고 가정

  3. {title,year} -> {length}고 {length} -> {genre}니까 {title,year} -> {genre}가 가능!(근데 이게 증명이 되남 암튼 이렇게 알아들엇읍니다)

• proof by contradiction

  R:	title	year	length	genre	studioName	starName
  t:	111	11	111	1111	11111	0000
  s:	111	11	111	1111	11111	1111

  S: title, year -> length, genre, studioName

  가정: title, year -> starName 이지만 closure에 포함되지 않음.

  instance인 t, s에 나타나 있는 starName의 값은 다르지만 가정에 의해 {title,year}의 closure에 들어가게 된다. 여기 어렵다… 모르겠어요ㅠ

Transitive Rule

FD는 transitivity를 가짐. A -> B, B -> C면 A -> C.

Closing Sets of FD

Minimal basis는 아래 3개를 만족하는 relation(B)

1. FD에서 우측에 있는 모든 값은 하나만 있어야 한다(singleton). ex) ABC -> D
2. B에서 FD 하나 지우면 얘는 더이상 basis가 아님.
3. XY -> Z가 basis라 해도 X -> Z, Y -> Z는 basis가 아님.

Minimal basis를 구하는 방법

1. Relation R에 의해 나올 수 있는 FD를 모두 구한다
2. transitive를 통해 나올 수 있는 애들은 다 제거해서 크기를 줄인다.
3. 더이상 제거할 수 없을 때 = minimal basis

Projecting FD

implied FD: 주어진 FD를 통해 새롭게 찾아낸 FD들

Alogorithm 12: Projecting a Set of FD

Relation R, 주어진 FD`s set인 S, R에 projection을 적용한 relation인 R1이 주어졌을 때, S를 통해 새롭게 구한 FD들을 포함한 모든 FD는 R1에도 똑같이 적용된다. 그리고 R1에 적용된 FD들은 basis지만 minimal basis는 아니다. 그래서 아래의 2가지 행동을 반복하면서 minimal basis를 찾는다.

1. transtive
2. AC -> B, A -> B일 경우 A -> B를 뽑는다.

• Example 13

하나 더 예시를 봅시다ㅏㅏ

3. Design of Relational DB schemas

BCNF: FD가 A1A2…An -> B1B2..Bn일 때 왼쪽에 있는게 superkey면 BCNF를 만족. 만약 nontrivial FD가 있으면 nontrivial FD만 적용, 없으면 BCNF 만족

FD: title, year -> length, genre, studioname

여기서 title, year가 superkey인가? superkey면 BCNF를 만족하고 아니면 BCNF를 만족하지 않음. 여기서 key는 title, year, starName이므로 superkey가 아님. 그래서 이 table을 decomposition하는게 좋음. 어떻게 나눌것인가? 이렇게~

(b)의 경우 title, year -> length, genre, studioName이라는 FD가 있는데 이는 BCNF를 만족

(c)의 경우 모든 attribute가 key임. 그래서 FD는 trivial한거밖에 없음. 이거도 BCNF를 만족

X+와 X(R-Y) 2개로 나뉨. 예를 들자면 Title, year이 X, length, genre, stdname이 Y면 X+는 저거 5개임. 근데 starname은 저기에 포함이 안됨!! X+기준으로 relation하나 만들고 안들어온애 기준으로 하나 또 만들고~ 이걸 더 이상 안쪼개질때까지 반복

Decomposition

1. Elimination of Anomalies
2. Recoverability of Information
3. Preservation of Dependencies

Lossless join

abc를 ab, bc로 나눈다음 다시 join면 abc가 되는데 이를 lossless join이라고 함. 근데 이는 너무 이상적.

General case로는 t(a,b,c), v(d,b,e)처럼 b의 값이 중복될 경우 AB, BC로 projection을 하고 다시 join을 하면 t, v말고 x(a,b,e)랑 y(d,b,c)같이 이전에 없던 친구들이 튀어나옴. 이런 친구들을 bogus tuple이라고 부름.

근데 FD B -> C가 있다면? B가 정해지면 C의 값도 정해지게 되므로 t(a,b,c)와 x(a,b,e)를 볼 때 c=e가 된다. 그래서 FD를 기준으로 나눠야 한다 이말이야.

Chase test

그러면 Relation을 나눴을 때, lossless join이 생기는지 안생기는지 어떻게 알 것인가? 그 방법이 chase test. 방법은 예시를 통해서~

R(ABCD)가 있고, S1(AD), S2(AC), S3(BCD) 3개로 나눌 것. FD는 A->B, B->C, CD->A가 주어짐. 그래서 tableau는 아래와 같음.(S1, S2, S3를 기준으로 각각 tuple 전개)

여기서 FD A->B를 적용할 수 있는 친구를 찾아보니 첫번째, 두번째 tuple의 A에 해당하는 값이 같음을 볼 수 있음. 그래서 b1=b2가 됨.

그 다음에 다시 살펴보면 B->C를 1,2번째 tuple에 적용 가능해서 적용하면 c1 = c가 됨.

이 다음에 CD->A를 적용할 수 있나 찾아보니 1,3번째 tuple에 적용 가능. 그래서 a = a3가 됨

맨 마지막 tuple이 a,b,c,d가 되었다는 것은 이 decomposition of relation이 lossless join을 갖고 있음을 의미. test 종료! Since there is an unsubscripted row, the decomposition for R has a losslsss join.

근데 만약 lossless join이 없다면? 마지막 tableau를 기준으로 S1, S2, S3, … Sn을 기준으로 Relation을 새롭게 만든 다음 서로 join시키면서 합쳐나감. 그럼 원래 Relation인 R보다 크게 되는데 그 안에 a,b,c,d 로만 이루어진 tuple이 있음.

5. 3NF

BCNF를 적용해서 제대로 나눴는데도 문제가 생길 수 있음. 그래서 거기서 한단계 더 발전한 것이 3NF. BCNF의 조건인 leftside가 superkey여야 한다를 만족하거나 rightside가 member of key(prime)이면 나눌 수 있다.

그러면 3NF로는 어떻게 나눌 것인가? 일단 FD를 모두 minimal basis FD로 바꾼다. 그 다음은 FD를 기준으로 나눈다.(synthesis of 3NF - algorithm 26) 마지막으로 key만 갖고 있는 relation을 하나 더 추가하면 끝~ 예시를 봅시당

R(ABCDE), FD: AB -> C, C -> B, A -> D

3NF의 경우 FD가 다 relation schema임 그래서 S1(ABC), S2(BC), S3(AD) 3개로 나눔.

Key:ABE, ACE 이므로 이 중 하나를 선택해서 S4를 만듦. 난 ABE선택

S2는 S1의 subset이니 지워도 댐. 그래서 R은 최종적으로 S1(ABC), S3(AD), S4(ABE)로 나눌 수 있음.

3NF 말고 1NF 2NF 등등도 있다!

1NF: 모든 data의 값은 1개씩만 갖고 있어야 한다

2NF: AB가 key고 A -> C면 FD의 왼쪽이 key가 아니니까 나눠야 함 AB, AC로

4NF: 곧 다룰 예정

6.MVD

MVD는 X ->-> Y처럼 2개의 화살표로 나타내는데 2개의 tuple을 스까서 새로운 2개를 만든다라고 이해하면 된다. 뭐든 예시가 직빵이므로 교수님께서 쓰신 예시를 가져와 보겠다.

여기서 주어진 MVD는 name ->-> street, city다.

tuple t하고 u를 보면 A에 해당하는 attribute의 값은 모두 같고 B와 Others에 해당하는 tuple은 다르다. 그러면 B와 Others에 해당하는 애들을 둘이 섞어서 w와 v라는 tuple을 만들 수가 있는데, 이 tuple들이 이미 전체 relation R에 있다는 것이 MVD가 의미하는 것이다.

MVD Rules

1. Every FD is an MVD
2. Complementation: 만약 X->->Y고 Z가 X나 Y의 attribute에 포함이 안되있다면 X->->Z다.

4NF

그러면 이 MVD가 왜 필요한가? 고거슨 4NF에서 사용하기 때문. 4NF는 MVD를 FD처럼 다뤄서 decomposition에 사용한다. X->->Y가 nontrivial MVD일 경우, X가 superkey가 아니라면 XY로 하나 만들고 X(R-Y)로 하나 만들고. 즉, MVD를 기준으로 BCNF를 한다고 보면 된다.

위의 그림을 예시로 들면 name ->-> street, city는 nontrivial MVD인데 X가 superkey가 아니다. 그래서 S1{name, street, city}과 S2{name, title, year}로 나눈다. 그 다음 또 검사하는데 S1에 MVD를 적용하면 name ->-> street, city의 경우 others가 없으므로 trivial MVD가 된다. S2의 경우에도 nontrivial MVD가 없으므로 이렇게 2개로 나누고 끝~

Chase for 4NF

4NF에도 chase test가 있다는 사실!(두둥) 근데 이거 설명하기 어려우니까 그냥 넘어갈께용~

만약 설명이 필요하시다면 연락주세요 한번 올려볼게유…

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가지를 통해 구현한다.

• 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를 아래와 같이 표현할 수 있다.

위 그림에서 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이 된다.

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

교수님께서는 이거도 유재석을 예시로 설명해 주셨다. 유재석이 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를 쓰냐는 중요하지 않다. 근데 편리해서 쓰는 것일 뿐이다.

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를 표시해서 사용한다.

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

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

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

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

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

이건 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로 표현.

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의 경우는 아래의 예시를 통해 확인하자.

• 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을 다시보자.

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로 하자.

CH.2: The Relational Model of Data

2-2. Basics of the Relational Data Model

Relation = Table

Attributes = Column headers(맨 위에 있는 것)

Tuple = Row

Instance : Row에 있는 data들.

Component : data

Domain: data type(int, char등)

2-3. Defining a Relation Schema in SQL

Table 은 결과를 저장, View는 과정을 저장.

Declaring Keys

• Primary Key: 테이블에 최대 1개 있을 수 있고, primary key로 지정된 것은 unique해야 하며 null이 허용되지 않음. 즉, 중복되는 값이 없어야 함.

• Unique Key: null이 허용되는 primary key

• EX) Table에 서점, 책, 가격의 attribute가 있고 primary key로 서점, 책이 설정 되었을 경우

  Pohang, DB, 24000 (O), Handong, DB, 30000 (O), Pohang, DB, 30000 (X) - pohang, db는 이미 24000이라는 고유의 값을 가지고 있기 때문에 중복되면 안됨.

  

  Unique(bookstore, book)일 경우 (Pohang, DB), 24000와 (Handong, DB), 30000은 다르지만

  밑에거는 Pohang, DB, 24000과 Handong, DB, 30000은 불가능

• Primary Key의 장점: 수많은 데이터에서 원하는 table의 데이터로 접근할 수 있게 도와줌.

2-4. An Algebraic Query Language

Algebra: How to compute

Decomposition: 분해

Relational Algebra 관계연산자 예시

• Projection: 원하는 key를 선택해서 사용.(column)

  $$R_1 = \pi_L(R_2)$$

• Selection: 원하는 데이터를 선택해서 사용(row)

  $$R_1 = \sigma_c(R_2)$$

• Cartesian Product: 모든 tuple을 서로 곱함. set의 곱과 똑같음.

  $$R = R_1 X R_2$$

• Natural Join

  

  R1과 R2를 서로 연결해서 R이라는 새로운 table을 생성.

• Theta Join

  

  C는 여기서 조건에 해당. 조건을 만족하는 애들만 Cartesian Product를 실행. 아래식과 동일

  $$R = \sigma_c(R_1 X R_2)$$

• Renaming: R에 있는 attribute들의 이름을 A1, A2, … , An 으로 바꾸고 table의 이름도 S로 바꿈 $\rho_{S(A_1,...,A_n)}(R) \\ \rho_{R_1}(R)$

  아래의 경우 attribute의 이름은 그대로지만 relation의 이름을 바꿈

• Union, Intersection, Difference : set과 동일

• 연산자 우선순위

  1. Selection, Projection, Rename
  2. Natural join, Theta join, Cartesian product
  3. Union, Intersection, Difference

Linear Notation for Expression

algebraic expression을 이용해 새로운 relation을 만듬.

2.5 Constraints on Relation

Referential Integrity Constraints

Relation에 있는 value가 다른 relation에도 있다면 두 relation은 서로 관계가 있다. 어떤 relation A의 tuple이 다른 Relation B의 tuple을 참조하려면 그 tuple은 Relation B 내에 존재해야 한다.

Relation이 주어지면 그 Relation에 value는 적어도 하나는 존재해야 한다.

• 동그란 화살표 = exact one, 그냥 화살표 = zero도 가능
• 위의 관계는 둘 다 동그란 화살표 = one to one
• 이 그림에서는 서로 primary key가 연결되어 있는데 하나의 relation을 지우려면 연관되어 있는 다른 한쪽 역시 지워야만 함. M이 존재하기 위해서는 F가 있어야만 하기 때문.

Key Constraints

서로 다른 tuple은 동일한 key attribute를 가지면 안된다. name과 address라는 attribute가 있을 때, tuple의 name이 같으면 address도 같아야 한다.

Additional Constraints

사용자 지정 제약. 한 줄로 주어진 제약을 모두 표시하고 = 공집합 꼴로 표시.

요약(?)

Schema

• How to create table

Expression

• How to express query linear algebra

• How to express relational algebra

Constraints

• How to setting the constraint

  • Relation integrity Constraint

    table이 주어지면 그 table의 value는 적어도 하나는 있어야함.

  • Key Constraint

  • Additional Constraint

수식정리