TIL(2021.04.07 - 04.09)

한국·2021년 4월 24일
0

TIL

목록 보기
30/33
post-thumbnail

3 Tier Architecture?


*출처 codeStates

  • 3계층 구조에서, 각 계층은 물리적으로 독립적으로 존재하고, 각 계층의 변화가, 다른 계층에 의존하지 않는 것을 뜻한다.

Database

  • 통합하여 관리되는 데이터의 집합체
  • 자료를 구조화 하여, 효율적인 처리를 할수 있도록 관리된다.
  • 데이터베이스는 미들웨어에 의해 관리되며 해당 미들웨어를 데이터베이스 관리시스템(DBMS)이라 부른다.
  • DBMS:사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해주고 데이터베이스를 관리할 수 있게 해주는 소프트웨어

Database는 왜 필요한가?

  • In-momory : 끄면 데이터가 사라진다.
  • File I/O : 원하는 데이터만 가져올 수 없고, 항상 모든 데이터를 가져온 뒤 서버에서 필터링 필요. 서버에 부하가 많이 걸린다.
  • 이에 반해 Database는 필터링 외에도 File I/O로 구현이 힘든 관리를 위한 여러 기능들을 가지고 있는 데이터에 특화된 서버이다.

SQL

  • Structured Query Language -> 구조화된 쿼리 언어를 뜻한다.
  • 주로 관계형 데이터베이스에서 사용이 되며, MySQL, Oracale,SQLite,PostreSQL등이 있다.
  • 데이터베이스에 query를 보내 원하는 데이터만을 뽑아 올수 있다.
  • Query: 저장되어 있는 정보를 필터하기 위한 질문(친숙한 예시로는 검색창에 적는 검색어를 들수있다.)
  • SQL문 관련 링크

트랜잭션

  • 여러 개의 작업들을 하나의 실행 유닛으로 묶어준 것.
  • 각 트랜잭션은 하나의 특정 작업으로 시작을 해 묶여 있는 모든 작업들을 다 완료해야 끝나게 되어있다 . 만약에 한 개의 작업이라도 실패하게 된다면 전부 실패를 하게 됩니다. 다시 말해 작업이 하나라도 실패를 하게 되면 트랜잭션도 실패이고 모든 작업이 성공적이면 트랜잭션 또한 성공적이게 된다.
  • 트랜잭션은 성공 혹은 실패 이 두 개의 결과만 존재합니다. 즉, 트랜잭션은 미완료된 단계 없이 전부를 성공해야 한다. 이러한 데이터베이스 트랜잭션의 정의는 ACID 특성들을 가지고 있습니다.

ACID

  • Atomicity, Consistency, Isolation, Durability 를 가리킵니다. 각 단어는 데이터베이스 내에서 일어나는 하나의 트랜잭션 (transaction) 의 안전성을 보장하기 위해 필요한 성질

    • Atomicity(원자성) : 하나의 트랜잭션이 전부 성공하거나 전부 실패해야 된다.부분적으로 실행이 되면 안되는 성질
    • Consistency(일관성) : 하나의 트랜잭션 이전과 이후 데이터베이스 상태는 이전과 같이 유효해야 한다. 예를 들어 각 고객은 이름이 있어야 하는 데이터베이스 제약이 있다라고 할때
      • 다음과 같은 트랜잭션들은 해당 성질을 위반한다.
        이름 없는 새로운 고객을 추가하는 쿼리
        기존 고객의 이름을 삭제하는 쿼리
  • Isolation(고립성) : 하나의 트랜잭션이 다른 트랜잭션과 독립되어야 한다.

    • 예를 들어 계좌에 1만원이 있다고 가정을 했을때
      • 해당 계좌로부터 계좌 B 로 6천 원의 계좌 이체와 계좌 C 에 6천 원의 계좌 이체를 동시에 하는 경우 연속으로 계좌 B 에 먼저 보낸 뒤 계좌 C 에 보내는 결과와 동일해야 한다는 뜻
  • Durability(지속성) : 하나의 트랜잭션이 성공적으로 수행되었다면 해당 트랜잭션에 대한 로그가 남고 런타임 오류나 시스템 오류가 발생해도 해당 기록은 영구적이어야 한다

    • 예로 은행에서 계좌이체를 성공적으로 한 뒤에 해당 은행 데이터베이스에 오류가 발생해 종료되어도 계좌이체 내역은 남아야 하며
    • 계좌이체를 로그로 기록하기 전에 시스템 오류 등에 의해 종료가 된다면 해당 이체 내역은 실패로 돌아가고 각 계좌들은 계좌이체 이전 상태들로 돌아가야 한다.

Schema & Query Design


*출처 codeStates

  • 스키마(schema)는 데이터베이스에서 데이터가 구성되는 방식과 서로 다른 엔티티 간의 관계에 대한 설명이다. 즉 "데이터 베이스의 청사진"과 같다.
    • 엔티티(Entity) : 고유한 정보단위, 데이터베이스에선 테이블로 표시할 수 있다. (위 그림에서는 Teachers, Classes, Students)
    • 테이블 안에있는 열의 정보들은 필드(Field)라고 한다. (위 그림에서는 Name, Room Number 등)
    • 레코드(Record)는 테이블에 저장된 항목이다. 행렬에서의 행(row)라고 볼수 있다. (위 그림에서 Teachers의 레코드를 본다고 가정할때 선생님의 이름은 Cynthia , 학과는 Music 이라고 정의내릴수 있겠다.)

  • 선생님과 수업의 관계를 통해 각 테이블의 관계에 대해 더 알아보자.

  • 여러명의 선생님이 한개의 과목을 가르친다? 뭔가 이상하다. 보통은 한명이 한개의 강의를 하고,
    한명의 선생님이 여러개의 과목을 가르치는 경우는 가능하다 이런경우를 1대 다의 관계라고 하며 1:N으로 표현한다.

  • 다른테이블에서 테이블의 기본 키(primary key)를 참조할 때 해당 값을 외래 키 (foreign key)라고 한다. 이 예시에서 ClassID라는 필드는 Classes테이블에서 특정 레코드를 고유하게 식별하는 외래 키다.

  • 여기서 발생하는 문제는? 한 선생님이 몇개의 수업을 하는지 알수가 없다. 최대 수업수가 기하급수적으로 늘게되면 어떻게 될까? 열의 크기는 고정되기때문에 수업id를 담을 공간이 없을수 있다. 그렇기 때문에 1:N의 관계일 때는 위와 같이 N의 테이블에 1의 foreign key를 들고와서 대입시켜주는 것이 좋다.

  • 그렇다면 수업과 학생들의 관계는 어떨까? 한명의 학생이 여러수업듣는것 가능하고 여러수업을 한한생이 듣는다 이것도 가능하다. 이런경우 다대 다의 관계라 부르며 N:N 으로 칭한다.
  • N:N 이럴땐 어떻게 해야할까? 서로의 테이블로는 불가능하다.

  • 위의 테이블을 이렇게 좌표 형식으로 변경해보는건 어떨까?

  • 이렇게 생긴 테이블을 조인테이블이라 부르며 한 학생이 조인 테이블에서 여러번 등장하기 때문에 Students 테이블과, Classes/Students 테이블 또한 일대 다 의 관계라고 볼수 있다.

  • 완성된 스키마 디자인이다. 새롭게 추가된 조인 테이블이 기존의 다대 다의 관계를 두개의 일대 다의 관계로 나눈것을 확인 할 수 있다.
  • 스키마 작성할때 https://dbdiagram.io/home 해당 링크를 통하면 한눈에 보이게 작성할 수 있다.

*출처 코드스테이츠

profile
소통하는 개발자를 꿈꾸는

0개의 댓글