접두어를 붙여서 테이블명을 정한다
약자를 적는 곳도 많음
수강생 테이블 (stnt)
주석이 안 달려 있으면 영어 단어만으로 어떤 테이블인지 알 수가 없다

데이터를 분산시키는 이유 ⇒ 중복을 방지하기 위해서
데이터가 중복되면 데이터를 유지보수하기 힘들다
문제가 발생할 가능성이 높아진다
그래서 데이터를 중복되지 않게 한 단위별로 분리시키는 게 중요
여러 테이블로 쪼개서 넣는다
데이터와 데이터 사이에 관계가 형성됨

우편번호를 PK로 하면 안 됩니까?
같은 우편번호를 가질 수 있음. 유일한 값이 될 수 없어서 안 됨.

수강생 번호 stnt.mno (FK)
멤버 번호 memb.mno (PK)

강사 번호 tcher.mno (PK)
멤버 번호 memb.mno (FK)

강의 lect.mno (FK)
매니저 mgr.mno (PK)

강의 lect.rno (FK)
강의실 room.rno (PK)

매니저 mgr.mno (FK)
멤버 memb.mno (PK)

수강신청 lect_appl.mno (FK)
수강생 stnt.mno (PK)
수강생의 mno가 FK인데요?
수강생 테이블의 mno는 이 테이블에서 PK이면서 FK로 사용된다는 거

수강신청 lect_appl.lno (FK)
강의 lect.lno (PK)

강의실사진 room_phot.rno (FK)
강의실 room.rno (PK)

멤버 memb.ano (FK)
주소 addr.ano (PK)

강의배정 lect_tcher.mno (FK)
강사 tcher.mno (PK)
강사 테이블의 mno는 PK이면서 FK 역할을 한다

강의배정 lect_tcher.lno (FK)
강의 lect.lno (PK)

주소 테이블에는 기본 주소만 들어 있음
기본 주소니까 같은 도로명에 속할 수 있음
기본 주소 하나에 여러 회원이 살 수 있다
일대다

회원 테이블 - 매니저 테이블
매니저 테이블에서 mno는 FK면서 PK이다.
PK는 중복될 수 없으므로 회원 테이블과 매니저 테이블 관계는 일대일이다.

대응하는 데이터가 없음
주소에 대응하는 회원 데이터가 없음 (1대0)
1번 주소에 대해서 2개의 데이터가 대응 (일대다)
⇒ 이런 경우는 1 대 0 이상

일대다
일대다 관계에서 0 이상이냐 1 이상이냐가 중요
특별한 경우 아니면 다 1 대 0 이상

옥션
구매자 테이블
판매자 테이블
구매자가 판매자가 될 수 있음
똑같은 정보를 또 입력해야 됨
회원정보 테이블에 기본 정보를 두고 구매자만을 위한 정보를 따로 둔다
구매자의 배송지 정보
구매자가 판매자가 되는 순간 사업자 등록증
판매자 테이블에 사업자 등록증
기본 정보를 공유하면서 구매자 정보 따로 판매자 정보 따로 관리할 수 있다
공통 정보는 공통 테이블에 보관한다

판매자로 로그인을 따로 하는 시스템이면 테이블이 완전 따로 분리
같은 아이디로 구매자 판매자로 활동하는 거면 기본 정보를 공유하면서 구매자 정보 따로 판매자 정보 따로 관리하는 거

회원 mno 100 (PK)
매니저 mno 100 (FK면서 PK)
강사 mno 100 (PK면서 FK)
하나의 데이터에 대해서 한 개의 데이터와 관계를 맺고 있다

회원 테이블 - 매니저 테이블
1 대 0 또는 1 대 1의 관계
PK면서 FK면 일대일의 관계라는 거

PK면서 FK로 사용 안 되면 일대다의 관계

두 개 키를 묶어서 PK로
그래서 일대일의 관계로 끝난다

강의실마다 사진이 1개 이상 있어야 되면
없어도 되면 0 이상 앞에 동그라미 치기

강의실에 강의가 한 개도 배정 안 될 수도 있으니까 1 대 0 이상
FK면서 PK로 쓰일 수 있다

ERD를 그리거나 보여주는 도구
erwin
이클립스에 플러그인 형태로 exerd

Help - Install New Software

git/bitcamp-study/eomcs-docs/db/dbmodeling.md

DB 모델링

🔹 모델링
시스템을 분석하고 구조화시켜 글과 그림으로 표현(추상화)한 것

🔹 DB 모델링
데이터를 분석하고 구조화시켜 데이터 속성과 관계를 글과 그림으로 표현(추상화)한 것

중복 데이터를 제거 ⇒ 데이터의 안정성, 신뢰성을 높인다. ⇒ 일관성, 무결성을 유지한다.

추상적으로 표현한 거
추상적인 거

table = entity = relation

🔹 row : 여러 컬럼으로 이루어진 데이터 한 개
🔹 column : 데이터의 한 항목

보통 이렇게 짝 지어서 부름
row, column
tuple, attribute
record, field

🔹 key : 데이터를 구분할 때 사용할 식별자
‐ 수퍼키(super key)라고 부르기도 한다.
‐ 식별자 : 데이터를 구분할 때 사용하는 값 (주민번호, 학번 같은 거)
‐ 한 개 이상의 컬럼으로 구성된다.
‐ 식별자를 key 라고 부른다.

🔹 후보 키 (candidate key)
‐ super key들 중에서 선별된 최소키를 가리킨다.
‐ 최소키 : 최소한의 컬럼 값 만으로 식별이 가능한 key
주민번호만으로 식별 가능한데 굳이 다른 컬럼까지 있을 필요 없음

🔹 기본 키 / 주 키 (Primary Key; PK)
‐ 후보 키 중에서 데이터 식별자로 사용하기 위해 선정된 키

🔹 대체 키 (alternate key)
‐ 후보 키(candidate key) 중에서 PK로 선정된 키를 제외한 나머지 후보 키를 가리킨다.
‐ primary key는 아니지만 primary key처럼 쓸 수 있다.
‐ PK 대신 사용할 수 있는 키를 대체 키라 부른다.
‐ 대체 키는 테이블을 정의할 때 Unique 컬럼으로 지정된다.
‐ PK는 아니지만 값이 중복되면 안 되는 컬럼이기 때문에 중복되지 않도록 유니크 컬럼으로 지정한다.
핸드폰은 primary key는 아니지만 중복되면 안 되기 때문에 유니크 컬럼으로 설정해야 한다.
이메일 또한 primary key는 아니지만 중복되면 안 되기 때문에 유니크 컬럼으로 설정해야 한다.

🔹 대리 키(surrogate key) / 인공 키(artificial key)

🔹 외래 키 (Foreign Key; FK)
‐ 다른 테이블의 PK 값을 저장하는 컬럼
‐ FK가 있는 테이블을 자식 테이블이라 부르고,
‐ FK가 가리키는 PK 컬럼이 있는 테이블을 부모 테이블이라 부른다.
‐ 자식 테이블 쪽에 부모 테이블의 데이터를 가리키기 위해 외부 키 컬럼을 둔다.

일련번호와 같은 임의의 컬럼을 pk로 사용한다.

primary key는 아니지만

논리 모델을 먼저 작성한다.

논리 모델을 작성하기 위해서는
어떤 데이터를 입력 받고 어떤 데이터를 출력해야 되는지 알아야 됨
UI 프로토타입을 만들어야 된다

  1. 엔티티 식별 및 속성 식별

매니저, 강사, 수강생
교육과정 목록
수업을 누르면 상세정보 나옴
교육센터 강의실 상세 정보
강의실 사진

  1. 주 키 선정(Primary Key; PK)
    모든 테이블에는 반드시 PK가 있어야 한다.
    데이터를 구분할 때 사용할 식별자를 지정한다.
    인공 키 만듦

  2. 테이블 간의 관계 식별 - 포함관계 및 배타적 관계

포함 관계 및 배타적 관계

09-JDBC프로그래밍 / 23 페이지

회원이면서 수강생일 수도 있고 매니저일 수 있고 강사일 수 있다.
서로 포함
매니저가 회원을 포함하고
강사가 회원을 포함하고
수강생이 회원을 포함한다

부모 테이블과 자식 테이블이 중첩 관계를 맺는 것

① 포함 관계 (inclusive)
✓ 수퍼 타입 테이블과 서브 타입 테이블이 중첩 관계를 맺는 것

회원 테이블 (수퍼 타입 테이블)
매니저 테이블, 강사 테이블, 수강생 테이블 (서브 타입 테이블)

회원인데 매니저도 될 수 있고, 강사도 될 수 있고, 수강생도 될 수 있는 관계

수퍼 타입 테이블과 서브 타입 테이블이 중첩 관계를 맺는 것

✓ 회원 정보는 매니저, 강사, 수강생 정보와 동시에 관계를 맺을 수 있다.

✓ 예) 홍길동 회원은 매니저이면서 강사, 수강생일 수 있다.

자바에서 수퍼 클래스, 서브 클래스 생각하면 됨

② 배타적 관계 (exclusive)

회원 테이블
매니저 테이블, 강사 테이블, 수강생 테이블

회원이 매너지나 강사나 수강생이 될 수 있지만
동시에 매니저이면서 강사는 될 수 없음

만약에 홍길동이 매니저이면 홍길동은 강사나 수강생은 될 수 없다.

X 로 표시한다
동시에 관계 맺는 건 안 됨
안타깝게도 SQL 문법에서 배타적 관계를 통제할 수 있는 문법은 없다
FK로 구분할 수 없다

✓ SQL 문법으로는 포함 관계와 배타적 관계를 제어할 수 없다.
⇒ 프로그래밍에서 제어해야 한다.

프로그램에서 막아야 됨. 데이터베이스에서 막을 방법은 없다.

테이블의 공통점을 뽑아서 수퍼 타입 테이블로 추출

여러 테이블에 공통적으로 들어가는 게 있는지 찾는다
이름 ~ 상세주소까지 공통임

자바에서 generalization과 유사하다
여러 클래스에 공통되는 필드 및 메서드가 있다면
추출해서 수퍼 클래스로 만들고 부모 자식 관계를 맺는다

강사 테이블에서
회원번호와 강사번호를 다르게 할 건지
아니면 회원번호를 강사번호로 쓸 건지
결정해야 된다

'회원번호'를 식별자로 쓸 거면 기존에 있는 '강사번호'를 지우고
'회원번호'에서 오른쪽 버튼 눌러서 'PK 컬럼으로 지정'
FK 이름과 PK 이름이 반드시 같을 필요가 없으므로
컬럼 이름을 '회원번호'에서 '강사번호'로 바꾼다
선이 점선에서 실선으로 바뀜 (식별 관계가 되었다)

비식별 관계와 식별 관계

09-JDBC프로그래밍 / 24 페이지

① 비식별 관계 (non-identifying)
FK ≠ PK
점선으로 그린다.
1 대 0 이상

강의실 테이블
PK : 번호

강의실 사진 테이블
PK : 사진 번호
FK : 강의실 번호

강의실 사진 테이블에서 FK가 PK로 사용되지 않는다.

② 식별 관계 (identifying)
FK = PK
실선으로 그린다.
1 대 1 또는 1 대 0

테이블에서 FK면서 PK로 쓰일 때

회원 테이블
번호 : PK

학생 테이블
번호 : FK면서 PK

관계를 나타내는 컬럼이 식별자로 사용된다

식별자로 쓰인다는 것은 FK 컬럼의 값이 중복이 안 된다는 거
여러 개의 데이터와 관계를 맺을 수 없음
중복될 수 없기 때문에 '일 대 다'가 될 수 없다.
'1 대 1' 또는 '1 대 0'

SQL 문법에 배타적 관계를 통제하는 문법은 없다. 프로그램으로 처리해야 한다.

주석을 다는 수 밖에...

강의 테이블 - 강사 테이블
하나의 강의에 강사가 참여
한 강사는 여러 수업에 참여

일반 관계
두 테이블 사이의 관계를 식별하여 연결한다
부모-자식 관계로 정의한다
데이터를 참조하는 쪽이 자식 테이블이다
데이터를 참조 당하는 쪽이 부모 테이블이다

강의 테이블 - 강사 테이블
한 명의 강사는 0개 이상의 강의에 참가할 수 있다
하나의 강의에는 여러 명의 강사가 투입될 수 있다
다대다

수강생 테이블 - 강의 테이블
한 명의 수강생은 여러 개의 강의에 참여한다

하나의 강의에는 여러 명의 수강생이 참여한다
하나의 강의에 한 명 이상의 수강생이 참여한다

한 명의 매니저는 0개 이상의 강의를 관리한다
1개의 강의를 여러 명의 매니저가 관리하지는 않는다
1 대 0 이상

강의 테이블 - 강의실 테이블
한 개의 강의는 한 개의 강의실을 사용
한 개의 강의실은 여러 개의 강의와 관계를 맺는다
우리 강의실은 토요일마다 시험장으로 사용된다
부모 테이블 : 강의실
자식 테이블 : 강의

하나의 강의실은 여러 강의에 사용된다
부모 쪽에서 자식 그리기

'일대다'일 때 '일'이 부모고 '다'가 자식

다대다 관계에서는 누가 부모고 누가 자식인지 구분 안 함
데이터베이스 테이블에서 다대다 관계를 저장하기 힘듦
그래서 다대다 관계를 끊어버려야 됨

수강생과 강의는 다대다 관계
한 명의 수강생은 여러 강의를 들을 수 있다
한 강의에 여러 수강생이 참여할 수 있다

강사와 강의도 다대다 관계
한 명의 강사가 여러 강의에 투입될 수 있고
한 강의에 여러 강사가 투입될 수 있다

'일대일'일 때는 기본이 되는 게 부모고 확장하는 게 자식
부모 테이블 : 회원
자식 테이블 : 매니저
서브 타입 클래스가 자식이 된다

업무에 대한 이해도가 있어야 DB 모델링

  1. 제1정규화

제1정규화

🔹 정규화
데이터 중복을 찾아내어 별도의 테이블로 데이터를 분리시키는 것

🔹 제1정규화
중복 데이터 또는 중복 컬럼을 별도의 테이블로 분리하여 부모-자식 관계를 맺는다.

강의실 테이블에서 교육센터 컬럼에 계속 중복되는 값이 있음
교육센터 컬럼을 분리한다

센터명을 Primary Key로 하면 나중에 값을 못 바꾼다

artificial key(인공 키) / surrogate key(대체 키)

정규화 : 중복 데이터 제거

중복된 데이터가 발생하지 않도록 테이블을 분리

매니저 테이블에 부서명 컬럼이 중복된다
부서명 컬럼을 분리한다

부서명을 PK로 하면 부서명을 못 바꾸기 때문에
artificial key(인공 키) / surrogate key(대체 키)

Foreign Key가 일반 컬럼이면 비식별 관계 (FK가 식별자로 안 쓰인다는 거)

Foreign Key가 Primary Key로 쓰인다면 식별 관계 (FK가 식별자로 쓰인다는 거)

매니저 테이블에서 '직급' 컬럼도 분리한다

수강생 테이블에서 '최종학력' 컬럼 분리하기

전공이나 학교이름은 바뀔 수 있으니까 그냥 두겠음

강사 테이블에서 '고용형태' 컬럼 분리하기

부서, 직급, 학력, 고용형태 테이블 같이
기준이 되는 데이터를 저장하는 테이블을 '마스터 테이블'이라고 한다.

중복 데이터 또는 중복 컬럼

중복 컬럼?
사진1
사진2
사진3
사진4

강의실 테이블에 사진에 대한 컬럼이 여러 개가 중복되어 있는데
이 중복 컬럼의 단점이
어떤 강의실은 사진이 없다
사진이 없음에도 불구하고 컬럼 4개가 존재하기 때문에 메모리 낭비됨
어떤 강의실은 사진이 6개 들어간다
사진을 6개 넣고 싶은데 사진 컬럼이 4개 밖에 없기 때문에 2개의 사진을 못 집어넣는다
그래서 중복 컬럼인 경우에는 별도로 분리시킨다

강의실에 사진이 없으면 강의실 사진 테이블에 데이터가 없을 거고
사진이 10개면 강의실 사진 테이블에 10개의 데이터가 있을 거

­05. 제2정규화
PK가 여러 컬럼으로 이루어진 경우에 수행

우리가 만든 예제에는 제2정규화에 해당되는 게 없으므로 넘어간다

06. 제3정규화

어떤 컬럼이 PK가 아닌 다른 일반 컬럼에 종속되는 경우가 있다면,
별도 테이블로 분리하여 부모-자식 관계를 맺는다.

기본주소는 회원이 바뀐다고 바뀌는 게 아니라
우편번호가 바뀌면 바뀐다

회원 테이블에서 우편번호와 기본주소를 분리시킨다

우편번호는 Primary Key가 될 수 없음

artificial key(인공 키) / surrogate key(대체 키)

상세주소는 회원마다 다름

실무에서 주소 정보를 저장할 때는 이렇게 하면 안 됨

주소 체계가 계속 바뀜

실무에서는 각 회원마다 중복되는 한이 있더라도
회원 테이블에 우편번호, 기본주소, 상세주소를 그냥 저장한다

도로명 주소
지번 주소

우편번호는 너무 자주 바뀌기 때문에

프로젝트할 때는 회원 테이블에서 우편번호 분리시키지 말기
우편번호, 기본주소가 중복되더라도 그냥 그대로 두기

회원가입 할 때
자바스크립트 Daum 주소 API
받아서 DB에 집어넣기

07. 다대다 관계 - 관계 테이블

수강생 - 강의 (다대다 관계)

한 명의 수강생은 여러 개의 강의에 참여할 수 있고
한 개의 강의에는 여러 학생이 참여할 수 있다

다대다 관계는 테이블을 정의할 수 없다

다대다 관계는 테이블을 정의할 방법이 없다

✓ 다대다 관계의 데이터를 다루기 어렵다.

'수강신청' 테이블을 만든다

관계에 대한 정보를 보관 ⇒ 관계 테이블

관계 테이블을 만들어서 일대다 관계로 바꾼다

강의 테이블과 수강생 테이블 관계 선은 삭제한다

근데 한 강의에 같은 수강생이 여러 번 등록되면 안 됨

두 개의 컬럼을 묶어서 중복되지 않도록 Primary Key로 만들거나 유니크 컬럼으로 만든다

두 컬럼 선택한 다음에 Primary Key로 만들기

Primary Key로 바꾸니까 수강신청 테이블 관계 선이 실선으로 바뀌었다

이게 다대다 관계 해소

강사와 강의
하나의 강의에는 여러 강사가 투입될 수 있고
한 강사가 여러 강의에 투입될 수 있는다

강사배정 테이블을 만든다

강의 테이블과 강사 테이블의 관계 선은 지운다

한 강의에 같은 강사가 여러 번 등록되면 안 됨

두 컬럼을 선택하고 PK로 만든다

강사배정 테이블은 기존의 테이블과 다르다. 관계를 나타내는 테이블이다.

관계를 표현하는 테이블은 색을 변경해준다.

08. 관계 차수 설정

만약에 FK가 필수 입력(not null)이라면
반드시 데이터 1개와 관계를 맺는다
1 대 0 이상

강의실 데이터 1개가 교육센터 데이터 몇 개와 관계를 맺느냐

강의
강의실번호가 필수인가
필수는 아님
강의실 번호를 지정하지 않고 강의 정보를 넣어도 됨
null 허용
강의실 번호가 없다는 것은 이 강의 데이터와 관련된 강의실 데이터가 존재하지 않는다는 거
강의실을 나중에 배정할 수도 있음

강의 정보를 등록할 때 매니저를 나중에 등록할 수도 있음
매니저 번호 null 허용

회원 중에서 수강생이 아닌 경우 수강생 번호 null

주소는 선택사항

FK가 필수냐 선택사항이냐에 따라

FK 컬럼이 필수냐 아니냐에 따라 차수 그리는 게 달라진다

PK는 아니지만 중복되면 안 되는 컬럼 (alternate key - 대체 키)
Unique column

유니크 컬럼

N·N = NOT NULL

0 또는 1 이니까 NULL 가능

­11. 인덱스 컬럼 지정

ERD대로 SQL문을 작성한다.

논리 모델

논리 모델
DBMS 비종속
DBMS의 능력을 고려하지 않은 상태에서 데이터 모델을 설계
물리 모델을 설계할 때 논리 모델을 재사용한다.

물리 모델
특정 DBMS 모델에 맞워 모델을 변환한다.
DBMS의 능력을 최대한으로 끌어내는 방식으로 설계한다.
MS-SQL용 물리 모델
Oracle용 물리 모델
Tibero용 물리 모델

논리 모델과 물리 모델을 분리하는 이유

논리 모델을 만들어 놓으면 DBMS에 맞춰서 물리 모델을
시간이 덜 걸림
밑그림 작업

처음부터 물리 모델을 만들어도 상관 없는데
Oralce용 만들 때 처음부터 만들어야 됨

  1. DBMS에 맞춰서 테이블명과 컬럼명을 설정한다.

거꾸로 DB ---> ERD (reverse engineering)

0개의 댓글