프로그래머스 SQL/DB Essentials - ERD

mohadang·2022년 6월 22일
0

SQL/DB Essentials

목록 보기
2/7
post-thumbnail

데이터 베이스 설계 도면
개념적 DB 설계 도구

DB 설계

개념적 설계 : 사람이 이해하기 쉽게 데이터의 관계를 개념적으로 시각화

개체-관계 데이터 모델 : 데이터를 개체 타입과 관계 타입으로 추상화

관계 타입

  • 매핑
    • 1:1 = 남자와 여자의 결혼 관계, 남자 입장에서 여자는 1, 여자 입장에서 남자는 1
    • 1:n = 지도 교수와 학생, 지도 교수 입장에서는 학생은 n, 학생 입장에서는 지도 교수는 1
    • n:m = 학생과 과목, 학생 입장에서는 과목은 n, 과목 입장에서는 학생은 m
  • 참여
    • 부분 참여
      • 학생은 과목에 부분 참여, 학생은 듣고 싶은 과목이 없어서 등록을 안할 수 도 있다.
      • 과목은 학생에 부분 참여, 과목은 인기가 없어서 학생에게 등록되지 않을 수 있다.
    • 전체 참여
      • 학생은 지도에 전체 참여, 학생이라면 반드시 지도 교수를 갖는다.

개념적 ERD : 개념적 DB 설계를 위한 시각화 도구

  • 클래식 방식
    • 개체 타입(사각형), 속성(타원형), 관계 타입(마름모), 부분 참여(얇은선), 전체 참여(굵은선)
    • EX)
  • Crow's Foot
    • 관계는 마름모를 사용하지 않고 개체 타입을 선으로 직접 연결
    • 매핑 정보
      • crow's foot : n
      • vertical bar : 1
    • 참여 정보
      • empty circle : 부분 참여(optional)
      • bar : mandatory(전체 참여)
      • 참여 정보가 클래식 방식과 조금 헤깔린다. 참여 정보가 반대편에 위치한다
    • EX)
      • 전체 참여 : Person이라는 정보가 있으면 Location이라는 정보도 반드시 같이 있다.(사람은 반드시 어떤 장소엥서 태어난다)
      • 부분 참여 : Location이르는 정보가 있다 해서 반드시 Person이라는 정보도 같이 있지 않다.(어떤 장소는 사람이 한번도 태어난 적이 없을 수 있다)
    • 조합
      • (부분/전체참여 .. 매핑정보_1/n)

논리적 설계

컴퓨터에 저장한 데이터의 논리적 구조를 표현
관계 데이터 모델 : 데이터의 구조를 테이블로 구체화
변환 규칙을 이용하여 자동화
관계는 식별 관계와 비식별 관계로 구분

  • 비식별 관계

    • 관계가 튜플을 식별하는데 영향을 주지 않는다
      • 즉 관계가 없어도 테이블에서 튜플 식별에 문제가 없다
    • 자식 개체 타입에서 부모 개체 타입의 키를 참조하지만 이 키는 자식 개체 튜플의 유일성을 판별하는데 필요하지 않다.
      • 자식 개체 타입은 식별 관계에 부분 참여함.
    • 일반적으로 점선으로 표현
  • 식별 관계

    • 관계가 튜플을 식별하는데 영향을 준다
    • 부모 개체 타입의 키 값이 있어야만 자식 개체 타입에서 튜플들을 식별 가능
      • 자식 개체 타입은 식별 관계에 전체 참여함.
    • 부모 개체 타입은 부모 테이블, 자식 개체 타입은 자식 테이블로 변환, 이때 개체 타입의 키는 변환된 테이블에서 PK로 정의
    • 부모 테이블의 PK를 자식 테이블에 PK/FK로 추가
    • 일반적으로 실선으로 표시
  • 식별/비식별 관계의 매핑 정보는 일대일, 혹은 일대다 매핑

  • n:m 매핑을 표현할 수 없음

    • 관계 모델은 테이블에 다중값 속성을 허용하지 않음
    • 다대다 매핑은 두 개의 일대다 매핑으로 표현

개념적 ERD에서 논리적 ERD(관계 스키마)

고려사항

  • 검색 효율성을 고려
  • 관계의 개수가 작을수록 검색 연산이 효율적임. 성능을 생각 한다면 전체 관계의 개수를 줄이도록 지향

원칙

  • 개체 타입 : 테이블로 변환
  • 관계 타입 : 일대일, 일대다 관계는 관계 테이블로 변환하지 않고, FK를 추가함
  • 다중값을 허용하지 않도록 주의
  • 다대다 관계는 관계 테이블을 생성

PK-FK 관계의 표현

  • 비식별 관계 : 점선
  • 식별 관계 : 실선
  • PK-FK 관계의 매핑과 참여 정보 : Crow's foot 표기법으로 시각화함.

비 식별관계, 개념점 설계 -> 논리적 설계

1) 개념적 설계

  • FK 개념이 없음

2) 논리적 설계

  • FK 개념 생김
  • SSN 만으로 식별 가능하여서 비식별 관계
  • 비식별 관계여서 점선

식별관계(n:m), 개념점 설계 -> 논리적 설계

1) 개념적 설계

2) 논리적 설계

  • 개념적 설계에서 Employee가 Project에 부분 참여 하기 때문에 Works_on에도 부분 참여
  • Projec가 Employee에 전체 참여 하기 떄문에 Works_on에도 전체 참여
  • Works_on의 키들은 FK이자 PK이다. FK로 식별할 수 있기에 식별관계
  • 식별관계여서 실선
  • Employee가 있다고 해서 반드시 Works_on에 있는 것은 아니다(직원이라고 해서 반드시 일하고 있지 않다)
  • Project가 있으면 반드시 Works_on에 있다(프로젝트가 생기면 반드시 일이 진행 중이다)

ETC

  • 선이 연결 될때마다
    • 관계가 생긴다
    • PK/FK가 생긴다
    • 관계를 표현하는 곳은 한군데만 표현한다. 바로 자식 테이블쪽
  • 부모 테이블의 부분/전체 여부는 중요하지 않다. 실제 SQL 형태에는 영향을 주지 않는다.
  • join 전에 select를 먼저 처리하여 튜플 갯수를 줄이는게 성능 면에서 좋다

EX)

  • 참여

    • 마름모 : 부분 참여
    • 동그라미 : 자식테이블
    • 아무것도 없음 : 전체 참여
  • 관계

    • 실선 : 식별관게
    • 점선 : 비식별관계

  • customers(테이블)은 employeeId(PK)를 salesRepId(FK)로 참조하고 있음
  • customers는 employee에 부분참여(마름모)하고 있음
    • 그래서 salesRepId는 NULL일 수 있음
  • employees는 customers에게 부모 테이블임(동그라미)

  • employees는 재귀 참조를 하고 있어서 테이블에서 나가서 다시 들어오는 선이 있음
  • employeeId(PK)를 managerId(FK)로 참조하고 있음
    • employee는 누군가의 manager일 수 있다.
  • 동그라미가 managerId(FK) 자식 쪽이다
  • 마름모가 employeeId(PK), 부모 쪽이다
  • managerId 는 FK이고 FK는 자식 테이블에서 갖고 있으니까. NULL 가능

  • customerId는 PK이자 FK이다. 식별 관계이다. 그래서 실선이다.
  • 식별 관계에서는 자식 테이블을 둥글게 표현

  • products 입장에서 orerDetaills는 자식

  • orders 입장에서 orerDetaills는 자식

  • 부모 자식 관계과 굉장히 쉽게 보여진다.

  • orderDetails의 PK/FK는 NULL일 수 없다

  • 모두 실선이라서 전체 참여 관계이다.

  • 1:N 관계는 그렇게 중요하지 않다. 자식쪽이 N일 것이기 때문에

profile
mohadang

0개의 댓글