[DATABASE] RDB Data Modeling

sunaaa·2021년 4월 13일
2

DATABASE

목록 보기
2/5

참고자료

데이터 모델링이란?

  • 무한히 복잡한 현실의 복잡성을 표에 담는 것, 그 방법론
  • 문제를 현실로부터 뜯어내서, 고도의 추상화과정을 거쳐서 그것을 컴퓨터라는 새로운 현실로 옮겨 담는 작업
  • 이 두 개의 세계는 서로 달라서, 처음 해결하려고 했던 문제가 표에 잘 담겼는지 확인하는 작업을 끊임없이 계속해서 해나가야 함
  • 하고 나면, 아무리 복잡한 정보도 표에 담을 수 있다는 자신감이 생길 것임!

MODEL이란?

  • 어떤 목적을 가지고 진짜를 모방한 것
  • 좋은 모델이란? 목적에 부합하는 모방
    => 표에 정보를 담는 것

데이터 모델링 순서

  • 업무 파악 -> 개념적 데이터 모델링 -> 논리적 데이터 모델링 -> 물리적 데이터 모델링
  1. 업무파악
    : 사용자 식별 / 데이터 베이스 용도 식별 / 사용자 요구 사항 수집 및 명세
  2. 개념적 데이터 모델링
    : 내가 하고자 하는 일에는 어떤 개념이 있고, 각각의 개념은 어떻게 상호작용 하는가 심사숙고하는 시간. ERD 다이어그램을 그리고, 그 다음 과정으로 가는 초석이 됨
    : 핵심 Entity(독립개체) 도출 / ERD 작성
  3. 논리적 데이터 모델링
    : 이 개념을 관계형데이터베이스 패러다임에 맞게 구성함. 표를 이상적으로 그린다고, 데이터 베이스가 되는 것은 아님.
    : 각 개념을 구체화
    : ERD-RDB 모델 사상 / 상세 속성 정의 / 정규화 등
  4. 물리적 데이터 모델링
    : 어떤 데이터베이스 제품을 선택할 지 정하고, 거기에 최적화된 표를 만드는 것이 물리적 데이터 모델링
    : DB 개체 정의 / 테이블 및 인덱스 등 설계

1. 업무파악

  • 컴퓨터라는 안똑똑한 기계에게 설명할 수 있을 정도로 업무를 이해해야 함
  • 그 분야의 실무자들과 정확하게 소통하는 것이 중요함
  • 실무자들도 그 분야에 대한 이해가 있다기보다는 익숙해져서 잘 하는 것일 수도 있음
  • 하지만 개발자는 이해를 했다면 설명도 할 수 있어야 함. 이해를 하기도 전에 익숙해지고 덮어버린 것임(나쁜 것은 아님! BUT 익숙함 만으로는 컴퓨터를 다룰 수 없음. 컴퓨터는 하나하나 컴퓨터가 해야할 일을 정확히 설명해줘야 동작하는 기계이기 때문)
  • 익숙해진 사람으로부터 정확한 정보를 끌어내기 위해서는, 많은 정보와 노하우가 필요함

=> 이는 소프트웨어 엔지니어가 공부를 멀리할 수 없고, 인간관계를 등한시 할 수 없는 이유이기도 함

  • 방법1 : UI(User Interface)를 같이 그려보는 것
    : 어플리케이션이 어떤 UI를 갖기를 바라는 지, 그려보는 과정에서 원하는 것을 분명하게 하고, 서로 생각하는 것을 일치시킬 수 있음.
    (말의 힘(기능)을 불신하기. 말을 불신할수록 말의 신뢰성은 높아짐)

  • Tool : Oven

2. 개념적 데이터 모델링

  • 파악한 업무에서 개념을 뽑아내는 과정
  • 일을 하는 순서와 공부를 하는 순서는 다를 수 있음
    : 물리적 모델링을 경험한 적 없는 사람이 개념적 모델링을 할 수는 없음. 관계적 데이터베이스 모델링 전체의 극치임. 논리적, 물리적 모델링은 기계적인 일임.
  • 느긋한 마음으로 언젠간 알게 되겠지 ~ 생각하기 생각하기

ER(Entity Relationship) 모델

  • 세상의 사물을 개체(Entity)와 개체의 관계로 표현함
  • 개체 : 독립적인 의미를 지니고 있는 유무형의 사람 또는 사물. 개체의 특성을 나타내는 속성(attribute)에 의해 식별됨. 개체끼리 서로 관계를 가짐.
  • JOIN을 통해 DB를 연결함

ERD(Entity Relationship Diagram)

  • 개체와 개체 간의 관계를 표준화된 그림으로 나타냄

  • 강한 개체(strong entity) : 다른 개체의 도움 없이 독자적으로 존재할 수 있는 개체

  • 약한 개체(weak entity) : 독자적으로는 존재할 수 없고 반드시 상위 개체 타입을 가짐

  • 속성(attribute) : 개체가 가진 성질

  • 관계(relationship) : 개체 사이의 연관성을 나타내는 개념

  • 관계 타입 : 개체 타입과 개체 타입 간의 연결 가능한 관계를 정의, 관계 집합은 관계로 연결된 집합을 의미

  • 개체는 직사각형으로 표현
  • 속성은 타원으로 표현
  • 개체 타입을 나타내는 직사각형실선으로 연결됨
  • 속성이 개체를 유일하게 식별할 수 있는 키일 경우 속성 이름에 밑줄 그음
  • 관계는 마름모로 표현

인조키(식별자)

  • 자연스럽게 식별자가 될 수 있는 키가 없는 경우 인조키를 만든다.(id값)

중복키

ERD로 보기

  • 식별자 -> ERD에서 밑줄침

엔티티간의 연결

  • Primary Key : 각각의 표에 행을 식별하는 유일무이한 식별자
  • Foreign Key : 외래 테이블과 연결할 때 사용하는 키(ex.글 테이블 저자 아이디 값)
  • 관계형데이터베이스의 relationship은 Primary KeyForeign Key가 연결되는 것을 통해 실제로 구현됨

ERD 표현 방법(마름모꼴 도형)

Cardinality(관계 대응수)

  • 1:1 관계

  • 1:N 관계

  • M:N 관계 (중간에 연결테이블을 만들어서 구현함)

Optionality

ERD 적용 사례

  • 기호에 엄격한 룰이 있지는 않음. 회사 컨벤션.

  • 학습 사이트 http://erd.yah.ac/

3. 논리적 데이터 모델링

Mapping Rule

  • ERD 통해서 표현한 내용을 관계형데이터베이스에 맞는 내용으로 전환할 때 사용할 수 있는 방법론
  • 포린키가 없는, 혼자서도 잘 지내는 테이블이 먼저 만들기 좋음
  • AI : Auto Increment
  • FK : Foreign Key
  • PK : Primary Key
  • Null : Is Nullable (NOT NULL은 미체크)
  • 자기자신의 Primary Key 값을 가지지 않아도 되는 경우, 넣지 않는 게 성능 등에 좋음(ex.휴면계정dormant 테이블을 만들 경우 휴면계정에는 별도 아이디값이 필요하지 않고, 유저 아이디를 참조하면 됨.)
  • 1:1 : 누가 Primary Key를 가질 것인가 헷갈림
  • 1:N : 가장 쉬움
  • N:M : 가장 어려움

4. 물리적 데이터 모델링

물리적 모델링 시 트랜잭션, 저장 공간 설계 측면에서 고려할 사항
1. 응답시간을 최소화
2. 얼마나 많은 트랜잭션을 동시에 발생시킬 수 있는지 검토
3. 데이터가 저장될 공간을 효율적으로 배치

profile
Be Playful Front-end Developer

0개의 댓글