[D+31] JOIN, 모델링

 

 

국비지원 D+31

-  JOIN, 모델링 -

 

---

 

JOIN

- 둘 이상의 테이블을 참조하여 하나의 테이블을 만들어내는 연산

- 분리되어 있는 테이블의 데이터를 합치는 연산

 

• JOIN의 필요성

만약 내가 책과 작가를 소개하는 사이트를 만들기 위해 관련 테이블을 하나로 만든다고 가정해보자.

책에대한 정보와 작가에 대한 정보를 컬럼으로 만든다고 가정했을때 위와같은 구성으로 이루어져 있을 것이다.

 

자료형과 제약조건을 통해서 테이블을 만들고 데이터를 넣었을 경우 위와 같은 테이블이 완성되게 되는데 이 테이블은 틀린것은 아니지만 몇가지 문제점이 있다.

일단 한 작가가 여러개의 책을 썼을 경우에 작가에 대한 정보가 중복되어 나타나는 것을 볼 수 있다.

또한 이러한 문제로인해 추후에 작가의 정보가 변경되었을 경우 일일히 변경해줘야하는 단점이 있다.

 

위의 문제점을 해결하기 위해서 우리는 기존에 하나로 만들었던 테이블을 각 특성에 맞게 두개로 나눠주면 중복이 최소화되기 때문에 공간의 효율성이 올라가게 된다.

이때 주의해야할 점은 단순히 반으로 쪼갤경우 두 테이블간의 연관성이 없어지기 때문에 booktbl에서 회원정보를 authortbl에서 기본키로 사용되는 id를 booktbl의 author_id라는 외래키로 지정해줘서 booktbl이 authortbl과 연계될 수 있도록 하면된다.

 

우리는 이렇게 외래키를 불러와 두개로 나누어져 있는 테이블을 조회할 수 있는 것을 JOIN이라고 한다.

 

• LEFT OUTER JOIN

A테이블을 기준으로 A와 겹치는 B를 JOIN

 

• RIGHT OUTER JOIN

RIGHT OUTER JOIN은 LEFT OUTER JOIN의 다른 형태로 원의 위치만 다를 뿐 같은 조인이라고 봐도 무방하다.

 

• INNER JOIN

A, B에 공통적으로 존재하는 행을 JOIN하는 것이다.

NULL값이 제외되므로 성능상의 이점이 존재한다.

또한 NULL값이 제외된다는 의미는 연산의 대상 자체가 되지 않는 다는 것을 의미한다.

 

• FULL OUTER JOIN

A, B에 모두 존재하는 행으로 JOIN연산을 하는 것으로 LEFT OUTER JOIN + RIGHT OUTER JOIN이다.

 

---

모델링

- 특정 목적에 따라 대상의 중요한 것을 도출하여 이를 재구성하는 과정이다.

- 현실 세계에 존재하는 데이터를 컴퓨터 세계의 데이터베이스로 옮기는 변환과정을 데이터 모델링이라고 한다.

- 데이터 모델링의 목적은 현실 문제를 해결하기 위해 실세계의 대상에서 중요한 것을 도출하여 이를 테이블로 재구성하는 것이다.

- 단, 데이터 모델링을 바로 DB화하면 문제가 발생되기 때문에 우리는 특정 프로세스를 거치면서 모델링을 완성시켜야한다.

 

• 데이터 모델링 프로세스

요구사항분석 → 개념적 모델링 → 논리적 모델링 → 물리적 모델링

우리가 학습해야할 데이터모델링 프로세스에서 요구사항분석과 개념적 모델링에 개념적인 내용을 많이 포함하고 있으며, 논리 모델링과 물리 모델링은 이미 자동화가 잘 되어있기 때문에 기술적인 이슈가 없기 때문에 요구사항분석과 개념모델링에 기술적인 내용을 집중적으로 알아보려고 한다.

 

요구사항 분석

- 고객이 무엇을 원하는지 또는 시스템이 무엇을 원하는지 도출하고 이를 체계화 하는 과정이다.

- 이때, 여기서 나오는 체계화라는 것은 가시화해서 검증하는 것을 의미한다.

- 분석기법 ) 관찰, 인터뷰, 프로토타이핑, 포커스 그룹, 심층 워크샵

 

프로토타이핑

프로토타이핑은 요구사항 분석기법중에서 가장 대표적인 기법으로 요구사항의 적용 결과에 대한 모형(Prototype)을 만드는 것을 의미한다.

(위의 사진은 카카오오븐을 사용해 만든 프로토타입이다)

 

개념적 모델링

- 실세계에서 의미있는 개체를 도출하고 개체가 가지고 있는 속성을 파악하여 개체와 개체간의 관계를 도출해내는 모델링이다. => ERD(Entitiy-Relationship-Diagram)

 

개체(Entity)

- 사람, 사물, 개념, 사건과 같은 저장할 만한 가치가 있는 중요 데이터를 가지고 있는 실세계의 객체를 나타낸다.

- 보통 개체는 테이블로 표현된다.

- ERD에서 네모로 표현된다.

- 특징1) 유일한 식별자에 의해 식별가능 (식별가능)

- 특징2) 영속적으로 존재, 업무에 필요한 정보 (영속성)

- 특징3) 엔티티간의 관계가 존재 (관계성)

 

속성(Attribute)

- 개체가 가지고 있는 고유한 특성을 말한다.

- ERD에서 동그라미로 표현된다.

- 유형1) 기본속성 : 업무 분석단계에서 이미 가지고 있다.

- 유형2) 설계속성 : 설계과정에서 도출되는 것으로 테이블을 만들다보니 기본키나 외래키를 필요로해 추가적으로 지정해 주는 것이 이에 해당한다.

- 유형3) 파생속성 : 성능의 이슈나 비즈니스프로세스의 요구사항으로 인해 추가적으로 도출한 것이다.

 

관계(Relation)

- 개체와 개체가 맺고 있는 의미있는 연관성이다.

- 관계는 속성을 가질 수 있다.

- ERD에서 마름모로 표현된다.

 

• ERD (Entity Relationship Diagram)

개체-관계 모델로 구조화된 데터에 대한 일련의 표현이다.

쉽게 생각하면, 테이블간의 관계를 설명해주는 다이어그램이며 DB의 구조를 한눈에 파악이 가능하다.

 

관계를 설정할 때에는 두가지를 고려해야 하는데 바로 카디널리티와 옵셔널리티이다.

 

카디널리티는 두 엔티티사이에서 몇대몇 관계인지를 설정하는 것으로 ERD에서 오리발을 통해서 표현이 가능하다.

 

또한 옵셔널리티는 카디널리티를 설정한 다음에 진행하는 것으로 위의 그림을 예를 들어설명하자면 카디널리티를 통해서 한명의 저자는 여러 개의 댓글을 달 수 있고, 댓글입장에서 댓글은 한 저자를 통해서 달리는 1:n관계를 설정한 상태이다.

이후에 저자는 댓글을 반드시 적어야하는지, 댓글은 반드시 저자를 가지고 있어야되는지에 생각해봐야하는데 이게 옵셔널리티이다.

참고로 모든저자가 댓글을 다 가지고 있어야할 필요가 없으므로 댓글은 동그라미인 Optional로 표현해 줄 수 있으며, 반대로 댓글이 작성되어지기 위해서는 저자가 반드시 필요하기 때문에 저자는 작대기인 Mandatory로 표현해 줄 수 있다.

 

카디널리티와 옵셔널리티를 통해 ERD를 표현하면 이렇게 표현될 수 있다.