데이터베이스 모델링

용어는 어떤 업무에서든 필수이다.

여러분이 법률을 다루는 변호사라면 법률용어를 사용하지 않고 일반용어를 사용할 수는 없을 것이다.

 

관계형 모델링에서 정의한 용어가 있다면 그것을 알아야 커뮤니케이션이 되고 알 수 있는 것이다.

 

관계데이터에서 가장 중요한 것은 테이블이다. 

테이블을 모델링 관점에서 만든 것이 realtion이다.

relationship은 두 객체간의 관계를 용어이고

각각의 테이블이 relation이라고 한다.

 

테이블의 columm이 아닌 relation의 속성이라고 쓴다.

 

(1) OOP 언어에서는 객체(Object) 라는 것을, 객체모델링을
    통해서 추출하고, 각 객체의 속성과 메소드를 모델링

(2) DB 모델링에서는, 개체(Entity)라는 것을, 관계형 데이터 모델링을 통해서 추출하고,

각 객체의 속성과, 두 객체간의 관계를 표현

 

 

 

도서 : 관계(relation)

속성 : 스키마(schema)

행 : 투플 이라고 부른다.

스키마(사전적 의미 : 구조) 중 하나 : 속성

속성의 갯수 : 차수(degree)

인스턴스의 갯수를 카디널리티라고 부른다.

 

튜플들의 모음을 인스턴스라고 부른다.

 

릴레이션 이름은 이렇게 해야 한다.

나이라면

domain은 0~120 길이는 최대 3자리

 

튜플들은 서로 중복되지 않아야 한다.

중복이란 무엇일까? 특정 속성 하나가 한 개 이상의 튜플에 동일한 값이 나오면 중복일까?

전체 속성에 대해서 다 동일해야 중복된 튜플이라고 표현해야 하는가?

중복의 기준이 무엇인가? 이것이 카운트 함수의 원리이다.

행을 새는 카운트 함수가 어떻게 새고, distinct라는 표현을 배웠다

distinct가 이 개념을 가지고 있다. 모든 튜플들은 중복이 없어야 한다라는 키워드가 distinct이다.

튜플들이 중복이 없어야 한다는 것은  모든 속성에 대해서 이다.

하나의 속성값이 아니라 속성의 수가 4개이면 4개의 속성의 값이 모두 같아야 중복이다.

 

 

릴레이션의 특징

중복된 투플은 허용하지 않는다. 

투플의 순서도 상관 없다.

 

 

키의 역활을 할 수 있는 정보 고객번호, 주민번호

고객번호와 주민번호를 합치면 키의 번호를 합칠 수 있다.

 

키는 한 개 이상의 속성들의 집합으로 구성된다.

전체를 구성하는 스키마 역시 키 역활을 할 수 있다.

전체 속성 중 키 속성이 한 개 이상 포함되어 있다는 전제하에....

 

슈퍼키

 

다 다르다..

후보키

고객번호는 중복될 수 있어서 키의 역활을 을 할 수 없다.

이 책의 전제는 한 명의 고객이 하나의 도서만 구매할 수 있다는 가정을 두었다.

도서번호는 키의 역활을 할 수 있을까 없을까?

 

같은 고객이 같은 도서를 구매하지 못 한다면 (고객번호 도서번호)가 슈퍼키가 될 수 있다

 

대리키

현업에서는 인조키 대리키로 구현하는 경우가 대부분이다.

 

외래키

회원 (회원번호(PK),이름,주소)
상품 (상품번호(PK),가격,사업자등록번호(FK))
배송업체 (사업자등록번호(PK),회사명,회사주소)
거래처  (사업자등록번호(PK), 회사명, 회사주소)
쿠폰 ( 일렬번호(PK), 쿠폰종류, 유효기간)

 

전자계산기 씨리얼넘버가 있다고 할 때 일련번호라고 짓고 

릴레이션이 이름이어서 사람의 이름은 무엇이라 물어보지 않는다.

쿠폰이면 쿠폰 등록번호로 사용하지 말고, 일련번호라고 사용하는 것이 좋다.

속성은 릴레이션 이름을 사용하지 않는다.

 

두 릴레이션의 관계를 확인하는 것은 동사로 확인할 수 있다.

먼저 개체를 전부 도출하고 그 다음에 관계를 도출하는 것이 순서이다.

 

 

 

-----------------------------------------------------------------------------------------------

 

무결성은 일관성 + 정확성이다.

 

foreign키라는 제약조건을 가지고 관계를 만들어주는 것.

 

1. 거부 2. 학생 삭제 3. default 4.아예 학과를 null로 만듦

 

관계대수

옵티마이저가 어떻게 처리할지 확인하는 것이 관계대수이다

sql언어를 던지는 입장에서 관계해석을 알아야 하는데 왜 관계대수가 나올까?

관계대수를 아는 것이 더 좋다. 관계대수를 알아야

옵티마이저가 어떻게 처리하는지 알아야 가장 좋은 코스트비용이 적은 

빠른 응답을 낼 수 있는, 데이터베이스 부하를 주지 않는 sql문장을 만드는 힌트를 제공하고,

sql을 문장을 선언할때 쓰이고, 옵티마이저가 실행플랜을 만들 때 쓰인다.

소프트웨어의 핵심은 정확한 기능과 데이터의 처리이지 ui는 그렇게 신경쓰지 않는다.

보통 차세대 시스템이라고 이야기하는데 은행권은 거의 5천억에서 6천억을 사용하는데,

ui는 아주 평이하고 그들에게는 정확한 숫자와 트랜잭션이 핵심이어서 ui에 신경을 쓰지 않는다.

 

비지니스 정보를 뽑아내는 것이 정보 모델링이며 개체와 개체들간의 상호작용을 관계를 통해서 하게 된다.

모든 개체가 상호작용하지는 않지만, 데이터를 담는 데이터 테이블은 테이블 간의 관계가 있다.

개체와 개체간의 관계가 있다면 반드시 찾아내야 한다.

관계라는 것이 아무렇게 찾아내는 것이 아니라 우리가 만들고자하는 서비스, 비지니스에 맞게 관계를 찾아내는 것이다.

모든 것의 중심은 비지니스이다. 비지니스 핵심 로직에 맞는 관계를 찾아내는 것이 핵심이다.

개체와 개체의 관계를 맺는것이 개념적 모델링이다. 그 산출물로 ER다이어그램이 나오게 된다.

이 과정이 잘 되어야 논리적 모델의 input데이터가 핵심이다.

이 input데이터를 중심으로 알고리즘 7단계가 erd다 보니까 erd가 잘못되면 알고리즘은 정한대로 뽑혀나온다.

근데 erd가 제대로 되었다는 가정하에 결과가 나오기 때문에 erd가 잘못되면 엉망이 된다.

 

그리고 물리적 모델링은 스토리지 타입과 속성에 맞게 만들어 놓은 것이다.

이 과정을 하기 위해서 데이터베이스는 라이프사이클을 가지고 라이프 사이클이 제대로 작동하기 위해선

데이터 모델링이 제대로 되어야 한다.

요구사항 수집 및 분석

1.고객이 개발사에게 돈을 주고 요구사항을 요청한다. 기능들을 요구한다.

2.고객사에서도 프로젝트 담당자가 생기고 사업부서에 한 명, it부서에 한 명 두명이 프로젝트 담당자로 지정된다.

3.it 부서에서 경험이 있는 사람, 사업부서에선 비지니스를 아는 사람이 요구사항을 요구한다.

4.그 요구사항을 협의한다. 요구사항 수집이 완성되면 요구사항 명세서를 만들고 법인도장을 찍는다.

5.그리고 요구사항명서세는 검수의 기반 자료가 된다 그래서 데이터베이스와 프로젝트의 범위가 된다.

 

설계

 

명서세를 기반으로 비지니스 프로세스를 불합리한 것을 바꾸거나 개선하고 새로 만들기도 한다.

그에 따라 업무프로세스의 개념들을 식별하는 것이 개념적 설계이다.

 

dbms를 설정하면 논리적인 설계로 개념적 산출물은 erd를 dbms에 맞게 변환작업을 하는 것이 논리적 설계이다.

그 후 데이터베이스 스키마를 도출한다.

 

구현

 

db객체를 생성하는 작업을 한다.

 

요구사항 분석은 우리 조의 서비스가 정해지면 서비스에 대해서 조원이 갑이되고 조장이 을이되어 받을 것이다.

요구사항 수집 및 분석으로 요구사항 명세서를 도출하고

여기서 식별할 것은 사용자 현재 서비스를 누가 사용할 것이라는 것을 식별하고

데이터베이스의 용도라는 요구사항 명세서가 나오게 된다.

 

입력 산출물을 통해 설계를 들어가고 개념적 모델링의 시작은 핵심 엔티티를 도출한다.

그들 간의 관계를 찾아내고, 그것이 모두 다 비지니스 로직을 중심으로 찾아내고

관계도 찾아내서 erd를 작성한다.

 

그 다음 dbms 설정하고 관계형 데이터베이스 설정하고 그에 맞게 개체와 관계를 관계형 데이터베이스에 맞게

매핑하는 것이 사상하는 것이다.

 

erd에선 엔티티를 만들기 위해 키 속성, 일반속성은 한 두개 정도 뽑아낸다.

어느 때 필요한 속성을 뽑아내냐면 논리적 속성에서 relation목록에서 각 목록의 비지니스 처리에 필요한 상세 속성을 추출한다.

 

최종 단계는 정규화를 시행한다.

제1 정규화부터 ~제 5정규화까지인데, 실전에선 보통 3정규화정도를 진행하면 무결성이 생기게 된다.

 

데이터베이스 생명주기는 한번 뿐 아니라 계속 돌아가는 것이다.

 

개념적 모델링에서 핵심 로직을 알게되고, 어떤 비지니스 로직으로 실행되어야 할지 업무를 알기 때문에,

업무라는 것 까지도 알게되고 업물르 통해 핵심적인 개념을 추출하고, 그 뼈대라는 것은 전체적인 뼈대라는 것은

반드시 이 비지니스 로직에 비지니스에 필요한 핵심 엔티티들을 뽑아내고 그들간의 관계를 구축하는 과정이다.

그 과정의 결과물로 바로 추출된 핵심 엔티티(개체)를 추출하고 관계를 정의하는 것이 뼈대를 만드는 것이다.

그렇게 ER다이어그램 핵심 엔티티간의 관계를 표현하게 된다.

 

 

고객은 도서를 주문하다.

주문은 엔티티가 아니라 고객이 상품을 주문하는 것 즉 관계이다......

개체가 있어야 관계를 있을지 없을지 판단가능하고 있다면 관계를 뽑아내야 한다.

즉 개념적 모델링의 핵심이다.

 

ERD가 있다면 두개의 코어 엔티티와 주문간 관계가 있으면

논리적 모델링을 거치면 3개의 relation이 나오게 된다.

논리적 모델링을 거치치 않고서는 그림이 나오지 않는다.

이거 가지고 정규화를 하면 무손실 분해가 발생하는데 그럼 relation이 또 쪼개지고 최종적으로 정규화까지 거친

relation목록을 가지고 그림을 그리게 된다.

얼마나 데이터 메모리 네트워크등의 하드웨어 자원을 효율적으로 사용하게 구성하느냐가 시스템관리자와 dba이고

이들이 모여 있는 곳이 운영부서이다. 운영부서에서 물리적 모델링의 최종 산출물을 만들게 된다.

ER모델

비지니스 명세서에는 요구사항이 나와있다.

어떤 서비스를 만들고 요구기능이 무엇이고 요구기능을 달성하기 위한 프로세스를 알고 만들어야 한다.

ER다이어그램을 뽑기위한 개념적 모델링의 시작이다

개체와 개체타입 속성은 개체의 속성

개체의 관계가 나오고 관계타입 

Weekentity, Strongentity

정보공학 표기법은 개념적 모델링인 erd를 그릴때는 사용하지 않고

논리적 모델링이 끝난 후에 IE표기법으로 전환하는 것이 좋다.

세상은 개체와 개체간의 인터렉션을 통해서 돌아간다고 생각했다.

개념이 OOP의 개념이고 데이터베이스에는 속성과 관계가 있다.

개체는 독립적이어야 한다. 개체는 독립적이지 않고서는 Weekentitiy 타입으로 나오게 된다.

눈에 보이던 보이지 않던 사람 또는 사물을 이야기 한다. 독립적이서 개체는 개체의 특성을 갖고

특성을 oop에서 객체의 속성도 영어로 같은 attribute이다.

 

독립적인 특성을 갖는 개체의 속성을 가져다 attribute라고 하고 모두 식별해야 한다.

 

코어 엔티티를 가지고 식별해내고 그들간의 관계를 그려내게 된다. 

피터챈 표기법

개체들을 뽑아내는 것이 정보모델링이다.

정보모델링을 통해 얻은 개체들간의 관계를 짓는 것이 개념적 모델링이다.

개체를 뽑아냈다는 가정하에 관계를 정하는것이 개념적 모델링

개념적 모델링의 최종 산출물인 ER다이어그램 표준화된 모델링 기호로 나타낸 그림이다.

만약 코어 엔티티로 직원과 프로젝트를 뽑아낸다면 

개체라면 키속성과 일반속성을 뽑아내고, 그 다음에 관계를 가져다 그리려고 한다.

 

이 떄 중요한건 개체들간의 관계이기 때문에 속성을 다 뽑아내지는 않는다.

직원과 프로젝트간의 관계는 무엇일까? 그 관계는 서비스와 비지니스로직

요구사항 명세에 맞는 관계를 찾아내는 것이다.

비슷한 속성의 개체타입을 구성한다.

우리가 개체 객체를 알았지, 개체타입이 나왔다.

우리가 뽑은 개체는 개체타입이다.

개별적인 도서의 공통 이름이 도서이고 개체타입 entitiy 타입이라고 한다.

개체라는 거은 entiti라고 한다 entitiy가 모여 entitiy set이라는 걸 이룬다.

 

관계타입은 요구사항 명세서에 맞춰서 뽑아내야 한다.

 

최대 한 개만 사용할 수 있는지만 표현할 수 있다.

 

1대 다 관계

 

위의 1과 n은 반대편에 그리고 0~*개까지 참여한다?

순화적 관계는 재귀관계에 가깝다.

세발 표기법을 가능한 사용하지 말고, peter chan을 사용하라!

관계는 정보공합 표기법에서 나타나지 않는다. 그게 단점이다.

 

ER모델을 관계 데이터 모델로 사상

1단계 : 강한객체 타입은 정규 객체타입이라고 부른다.

강한객체 타입은 한개의 릴레이션으로 뽑으라!

 

2단계 : 퍼셜키가 존재한다.약한 개체 타입에 생성된 릴래이션은 강한 개체 타입의 키를 외래키로 사상하여

자의 기본키를 구성한다.

 

관계타입 사상

방법4는 다대다 관계를 푸는 방법

관계타입 R을 릴레이션R로 사상하는 방법

 

3단계 가능하면 방법1과 2를 사용하라

4단계 가능하면 방법1을 사용하라!

교차릴레이션