기획자 알쓸신잡(2조: DB와 SQL)

목차

1. IT 기획자가 DB를 알아야 하는 이유

1) 기획자가 DB구조를 제대로 고려하지 않았을 때 생기는 일

2) 주요 키워드

• DB

• DBMS

• RDMBS

• 정규화(Normalization)

• 키
• 기본키(primary key, PK)
• 슈퍼키
• 후보키
• 대체키
• 외래키

• ERM

• 스키마

• 뷰

• 인덱스

• SQL

• 트랜잭션

2. DB와 DBMS

1) 데이터베이스(DB:Database)

2) 데이터베이스의 특징

(1) 실시간 접근성(Real-Time Accessibility)

(2) 계속적인 변화(Continuous Evolution)

(3) 동시공용(Concurrent Sharing)

(4) 내용에 의한 참조(Content Reference)

3) 데이터베이스 모델의 종류

1. 계층형 DB 모델(Hierarchical database model) : Tree data model

└── src
      ├── main
      │   ├── java
      │   │   └── com
      │   │       └── example
      │   │           └── demo
      │   │               ├── DemoApplication.java
      │   │               ├── config
      │   │               ├── controller
      │   │               ├── dao
      │   │               ├── domain
      │   │               ├── exception
      │   │               └── service
      │   └── resources
      │       └── application.properties

• 계층형 데이터베이스는 데이터의 관계를 트리 구조로 조직 한 것을 말한다. 부모-자식 관계 형태를 갖는 일-대-다(1:n) 구조로 상위 1개 레코드가 1개 이상의 하위 레코드를 갖는 구조이다.
• 계층형 DB 모델은 초창기 메인프레임 컴퓨터와 초창기 이후 널리 쓰였으나, 오늘날에는 디렉터리 계층구조라는 이름으로 파일시스템, 윈도 레지스트리, 조직도, 주소록, 전화번호부, 명부, 구조화 문서(XML) 등에 쓰인다.
• 자식을 두지 못한 맨 마지막 레코드를 단말 노드(terminal node) 라고 한다. 자주 쓰이는 용어이니 알아두는게 좋다.
장점 - 디렉토리 서비스(어떤 이름을 기준으로 대상을 찾아 조회하거나 편집할 수 있는 서비스)에 최적화 되어 있다.
단점 - 유연성이 떨어진다.
• 어떤 레코드를 삭제 하면 그 자식들이 모두 따라 삭제된다.
• 레코드 중복이 심하다 → 무결성 유지가 어려워진다
 
• 대표적인 계층형 DBMS
• IBM 정보 관리 시스템(IBM Information Management System, IMS) - 1968년 아폴로 계획을 위해 처음 만들어 졌다. 현재 까지도 꾸준히 버전업 되어 DB2와 함께 IBM 메인프레임의 주요 DBMS로 사용되고 있다.
• 여러 디렉토리 서비스 : 이름 또는 ID를 기준으로 대상을 찾아 조회하거나 편집할 수 있는 서비스
• LDAP(Lightweight Directory Access Protocol, 경량 디렉터리 액세스 프로토콜) : 인터넷 표준 디렉터리 프로토콜
• DNS(Domain Name System, 도메인 네임 시스템) : LDAP를 이용해서 만든 도메인으로 ip 찾아주는 시스템.
• 액티브 디렉터리(Active Directory, AD) : MS에서 만든 윈도서버용 LDAP
• 애저 액티브 디렉터리(Azure AD) : MS에서 만든 애저 클라우드용 LDAP

2. 네트워크형 DB 모델(Network database model) : 망 데이터 모델.



• 네트워크형 데이터베이스 모델은 계층형과 비슷하나, 다-대-다(n:m)구조를 허용한다. 계층형을 부모-자식 관계라고 하는 것에 비해, 네트워크형은 오너-멤버 관계라고 한다.
• 강력하나, 메인프레임에서만 쓰고 PC에는 쓰지 않는 것 같다.

3. 관계형 DB 모델(Relational database model) : 표 데이터 모델.
• 관계형 데이터베이스 모델은 1969년 IBM에 근무하던 에드거 F. 커드 박사가 혼자 만들었다. 그러나 IBM은 IMS DBMS의 수익을 보호하기 위해 관계형 모델의 구현을 거부하였다. 그래서 커드 박사는 A Relational Model of Data for Large Shared Data Banks 라는 논문을 1년 뒤 외부에 발표하였고, 그 논문을 바탕으로 래리 앨리슨이 오라클 RDBMS를 만들었다. 그 덕분에 오라클은 현재 유닉스 환경에서 가장 널리 사용되는 RDBMS가 되었다.
• 관계형 DB 모델은 개체 집합에 대한 속성 관계를 표현하기 위해 모든 개체를 테이블(table)로 저장하고, 개체 집합들 사이의 관계를 공통 속성으로 연결함으로써 복잡한 관계를 표현한다.
• 데이터 검색, 추가, 삭제 작업 등이 이전 모델들과 비교하면 '매우' 편리하며
• 제약 조건이나 트리거 등의 장치를 통해 스스로 데이터의 무결성을 유지하는데다
• '배열'을 이용하기 때문에 첨자를 통한 작업으로, 속도까지 뽑을 만한 효율을 보이기 때문에
• 이후 빅데이터가 등장하기 전 까지 가장 많이 사용하는 데이터 모델이 되었다.
• 기본 용어
• 표 = 테이블 = 릴레이션
• 행 = 레코드 = 튜플
• 열 = 칼럼 = 애트리뷰트(속성)
• 차수 = degree : 한 릴레이션에 들어있는 애트리뷰트의 갯수. 잘 변하지 않는다.
• 카디날리티(Cardinality) : 한 릴레이션의 튜플의 개수. 자주 변한다.
• 도메인 : 한 릴레이션에서 속성 값으로 정의된 데이터 형식들을 그룹핑한 개념. 문자형, 숫자형, 일자형, 시간형 등.
• 릴레이션 스키마 : 릴레이션의 구조. 릴레이션의 이름과 릴레이션에 포함된 모든 애트리뷰트의 이름으로 정의한다.
• 릴레이션 인스턴스 : 어느 시점에 릴레이션에 존재하는 튜플들의 집합; 릴레이션 스키마에서 정의하는 각 속성에 대응하는 실제 값으로 구성되어있다.

• 키(Key)
• 열쇠는 무언가를 열거나 잠글 때 사용하는 것으로, 같은 것이 하나도 없다. 우리집 열쇠가 옆집의 열쇠랑 다르듯이 말이다.
• 이와 같이 키라는 것은 무언가를 식별하는 고유한 식별자(identifier) 기능을 한다.
• 즉, 키는 데이터베이스에서 조건에 만족하는 관계의 행을 찾거나 순서대로 정렬할 때 다른 행과 구별할 수 있는 기준이 되는 속성의 집합이다.
• 키의 종류
• 슈퍼키(Super Key, SK) : 테이블에서 각 행을 유일하게 식별할 수 있는 하나 또는 그 이상의 속성들의 집합이다.
• 슈퍼키는 유일성만 만족하면 슈퍼키가 될 수 있다.
• 유일성이란 하나의 키로 특정 행을 바로 찾아낼수 있는 고유한 데이터 속성을 말한다. 예를 들면 전국에서 나를 구별할 수 있는 유일하고 고유한 속성은 주민번호이듯이 말이다. 주민번호는 전국민이 모두 겹치지 않아 유일하고 고유한 구별 방법으로 쓰인다.
• 아래 사진을 보자. 7조라는 팀에 팀원은 4명이 있다. 이 4명을 구분할 수 있는 것은 절대 겹치지 않는 학번 일수도 있고, 주민번호일 수도 있다.
• 이름과 나이를 묶어서 하나의 속성으로 만드는 것도 가능하다. 이름과 나이를 합쳐서 7조안에서 중복만 되지 않으면 가능하기 때문이다. 이름과 나이를 합쳐서 4명을 구분할 수 있으면 슈퍼키가 될 수 있다.
• 학번과 주민번호를 묶어서 슈퍼키로 만들수도 있고, 학번과 주민번호과 이름을 합쳐서 슈퍼키로도 만들수 있고, 학번과 주민번호과 이름과 나이를 합쳐서 슈퍼키를 만들수도 있다. 어떤 속성끼리 묶던 중복값이 안나오고 서로 구별만 할 수 있으면 된다.

• 후보키(Candidate Key, CK) : 테이블에서 각 행을 유일하게 식별할 수 있는 최소한의 속성들의 집합
• 후보키는 기본키가 될 수 있는 후보들이며 유일성과 최소성을 동시에 만족해야한다.
• 아래 사진을 보자. 7조라는 팀에 팀원은 4명이 있다. 이 4명을 구분하는 슈퍼키들이 모여 있는데, 슈퍼키들 중에서 속성은 최소한의 갯수로 4명을 구분할 수 있어야 후보키가 될 수 있다.기본
• 학번 슈퍼키와 주민번호 슈퍼키는 속성들이 각 1개씩 이루어져 있다. 하지만 이름+나이 슈퍼키는 이름과 나이를 묶어서 2개의 속성으로 되어 있다. 이름+나이 슈퍼키는 2개 이므로 각 1개의 속성인 주민번호와 학번 슈퍼키가 최소성을 만족한다고 할 수 있다.
• 따라서 이름+나이 슈퍼키는 갯수가 다른 것보다 많기 때문에 최소성을 만족하지 못해서 후보키가 될 수 없다.
• 기본키(Primary Key, PK) : 후보키들 중에서 하나를 선택한 키로 최소성과 유일성을 만족하는 속성이다.
• 테이블에서 기본키는 오직 1개만 지정할 수 있다; 기본키는 테이블 안에서 각 행들을 구별하는 유일한 키로 정해지기 때문이다.
• 기본키는 NULL 값을 절대 가질수 없고, 중복된 값을 가질 수 없다; 각 행들을 구별하려면 값이 없어선 안되고, 중복되어서도 안되기 때문이다.
• 대체키(Alternate Key, AK) : 기본키로 선정되지 않은 후보키를 대체키라한다.



• 위 사진을 보자. 7조라는 팀에 팀원은 4명이다. 후보키로 학번과 주민번호가 뽑혔고, 둘 중에서 기본키는 학번이 되었다. 학번이 기본키가 되고 남은 후보키인 주민번호는 대체키가 될 수 있다. 학번 기본키가 없어지게 되면 주민번호는 없어진 기본키를 대체할 수 있게된다.



• 외래키(Foreign Key, FK) : 다른 테이블의 데이터를 참조하여 테이블간의 관계를 연결하는데 사용되는 속성이다.
• 외래키가 참조할 부모 속성은 기본키여야만 한다. 할당 되기 전에는 null을 허용한다.
• 참조 무결성을 위해 사용한다 - 다른 테이블의 데이터를 참조할 때 없는 값을 참조할 수 없도록 제약을 주는 것이다.
• 참조 될 부모 테이블(A)이 먼저 만들어지고 참조하는 자식 테이블(B)에 값이 입력되어야 한다.
• 이때, 참조될(A) 열의 값은 참조될(A) 테이블에서 기본키(Primary Key)로 설정되어 있어야한다.
• 외래키는 참조되는 테이블의 기본키와 동일한 키 속성을 가진다.
• 참조되는 부모테이블이 먼저 생성된 뒤 데이터를 넣고, 참조하는 자식 테이블이 다음에 생겨야된다.
• 부모 테이블 먼저 삭제될 수 없다. 왜냐하면 부모테이블을 참조하는데 부모테이블이 삭제되면 자식테이블은 참조하는 것이 없어지기 때문에 외래키 오류가 생긴다.
• 외래키 관계에서 부모테이블을 삭제하려면 자식테이블 먼저 삭제한 후 부모테이블을 삭제해야한다.
• 아래 사진을 보자. 부모 테이블은 학생 테이블이고, 자식 테이블은 수강 테이블이다.
• 학생테이블은 학번이 기본키이자 참조되는 참조키이다.
• 수강테이블은 학번이 참조하는 키이자 외래키이다.



• 데이터베이스 정규화(Normalization)
💁🏻‍♂️
- 관계형 데이터베이스의 설계에서 중복을 최소화하게 데이터를 구조화하는 프로세스를 정규화(Normalization)라고 한다. - 데이터베이스 정규화의 목표는 이상이 있는 관계를 재구성하여 작고 잘 조직된 관계를 생성하는 것에 있다. - 일반적으로 정규화란 크고, 제대로 조직되지 않은 테이블들과 관계들을 작고 잘 조직된 테이블과 관계들로 나누는 것을 포함한다. - 정규화의 목적은 하나의 테이블에서의 데이터의 삽입, 삭제, 변경이 정의된 관계들로 인하여 데이터베이스의 나머지 부분들로 전파되게 하는 것이다.
정규화하는 방법을 정리한 것을 정규형(Normal Form)이라고 하고, 정규형에는 6가지가 있다.
• 제1정규형(First Normal Form, 1NF) : 중복되는 항목이 없어야 한다.
• 제2정규형(2nd Normal Form, 2NF) : 1NF 테이블은 한 개 이상의 속성들로 구성된 후보 키값이 없으면 2NF이다.
• 제3정규형(3rd Normal Form, 3NF) : 2NF 테이블이 테이블 내의 모든 속성이 기본 키에만 의존하며, 다른 후보 키에 의존하지 않는다.
[DB 이론] 데이터베이스 정규화란? (이상 문제, 함수적 종속, 정규화 과정)
이상 문제를 해결하기 위해 속성들 끼리의 종속 관계를 분석하여 여러개의 릴레이션으로 분해하는 과정 입니다. 일반적으로 테이블을 여러개로 분해하면 속도는 상대적으로 느려질 수 있지만, 분해하지 않으면 이상 문제들이 발생 합니다.

https://nirsa.tistory.com/107?category=873185

4. NOSQL
• NoSQL의 장점
• 대용량 데이터
• 데이터 분산 처리
• Cloud Computing
• 빠른 읽기/쓰기 속도
• 유연한 데이터 모델링
1. 키-값형(KV store)
Key-value Stores - DB-Engines Encyclopedia
Encyclopedia > Article Key-value stores are probably the simplest form of database management systems. They can only store pairs of keys and values, as well as retrieve values when a key is known. These simple systems are normally not adequate for complex applications.

https://db-engines.com/en/article/Key-value+Stores

모든 데이터를 키(Key)와 값(Value)의 쌍으로 매핑한다. Key를 어떻게 인덱싱했느냐에 따라 다르지만 보통 특정 값 하나를 찾아내는 데에는 가장 뛰어난 성능을 보인다. 하지만 데이터를 그룹화하고 정렬하는 기능은 없다시피하다. 대신 RDBMS에 비해 가볍고, 빠르고, 다루기 쉽다.
언뜻 보면 1차원 데이터만 다룰 수 있을 것 같이 생겼지만 Value에 넣을 수 있는 값이 자기 자신의 Key를 포함하여 Any object이기 때문에(크기 제한은 있을 수 있다) 대부분의 데이터를 다룰 수 있다. 물론 다른 DBMS는 이런 데이터 조직화를 도와주는 각종 도구를 제공하므로 2차원 이상 데이터는 KV store 말고 다른 걸 찾아보는 게 좋다.
웹 캐시나 세션 데이터, 쇼핑몰의 장바구니 데이터 등을 담는 데에 최적인 DB여서 이쪽으로 활용을 많이 한다. 그 외에 KV store는 데이터베이스의 크기가 상대적으로 작아 메모리에 통째로 올려놓고 구동하는 것도 쉽기 때문에 인-메모리 데이터베이스로 많이 사용된다. 인-메모리 데이터베이스는 그 특성상 매우 고속으로 동작하는 대신 데이터의 안정성을 전혀 보장하지 않는데 장바구니 같은 건 날아가도 상관없는 데이터이면서 반응이 즉시 와야 하는 성격이라 주로 선택된다. KV store로 세션을 처리하는 웹 서버도 하드디스크에 부담을 상당히 덜어주면서 반응이 아주 빠르다. 그러니까 일종의 '임시 데이터' 저장소로서의 입지를 굳게 다지고 있다.
 
2. 객체형(Object)
Object oriented DBMS - DB-Engines Encyclopedia
Encyclopedia > Article Object oriented database management systems (often referred to as object databases) were developed in the 1980s motivated by the common use of object-oriented programming languages. The goal was to be able to simply store the objects in a database in a way that corresponds to their representation in a programming language, without the need of conversion or decomposition.

https://db-engines.com/en/article/Object+oriented+DBMS

프로그래밍 언어에서 객체지향의 개념이 포함되었듯이, 관계형 데이터베이스 이후, 데이터베이스에서도 객체지향을 구현한 것이 바로 객체형 데이터베이스이다. 이러한 DBMS를 ODBMS라고 한다.
3. 문서형(Document)
Document Stores - DB-Engines Encyclopedia
Encyclopedia > Article Document stores, also called document-oriented database systems, are characterized by their schema-free organization of data. That means: Records do not need to have a uniform structure, i.e. different records may have different columns. The types of the values ​​of individual columns can be different for each record.

https://db-engines.com/en/article/Document+Stores

MongoDB의 방식. 위의 객체형과 비슷하다. 문서의 구조를 나타내는 스키마가 필수가 아닌 것이 특징이다.
스키마가 없기 때문에 인덱스 필드를 제외하고(인덱스를 해제하는 건 가능하다) 필드를 마음대로 넣거나 뺄 수 있다. 기존 데이터에 해당 필드가 있든 없든 상관없고 그런 데이터를 상대로도 조회, 그룹핑 등의 작업이 가능하다.
객체 지향 프로그래밍이 주류인 현재, 데이터를 따로 매핑할 필요 없이 그냥 집어넣으면 알아서 잘 저장되는 객체형, 문서형 데이터베이스가 주목받고 있다.
그러나 저장한 상태 그대로의 문서를 뽑아내는 게 아니라 뭔가 데이터를 가공하려고 하면 잘 되지 않는다. 예를 들어 Group by나 Join 쿼리 등. 또한 데이터를 지속적으로 '쌓아 올리는' 응용(예를 들어 금융거래 기록 저장)에서는 성능이 상당히 떨어진다. 이런 건 RDBMS가 가장 잘 하는 분야.
데이터의 스키마가 자주 바뀌고 데이터가 다계층의 객체 형태이면서 대부분의 업무가 갱신, 삽입(문서단위), 조회에 집중돼있고 통계 연산에 쓰일 일이 많지 않은 곳에서 사용하기 좋다. 통계 연산이 가끔 필요한 곳에서는 필요한 데이터를 추출해 RDBMS에 옮기고 SQL로 처리한다. 아니면 DBMS에서 자체 제공하는 map/reduce 연산을 쓰던지.
한마디로 바인더 서류철과 비슷한 성격을 가졌다. 바인더철에 추가로 종이를 꽂거나(삽입), 꽂힌 종이를 다른 걸로 갈아넣거나(갱신), 종이를 찾거나(조회) 하는 일에는 뛰어나지만 한 종이 안에 적힌 데이터가 계속 늘어나거나(추가), 여러 종이에 걸쳐 있는 어떤 값을 다 더하거나(통계) 하는 일에는 취약하다. RDBMS는 여기서 '종이'에 해당하는 놈이 무한한 두루마리와 같아서 데이터의 추가 작업이나 특정 필드를 대상으로 한 통계 및 그룹화 작업이 쉽다. 대신 RDBMS는 2차원을 넘어가는 데이터(트리 구조 데이터 등)를 저장할 때 두루마리를 여러 개 준비해야 하는 게 단점이다. 중간에 형식이 다른 데이터를 끼워넣는 건 불가능하고. 문서형 DB는 종이 하나에 모든 관련 데이터를 다 담아두므로 다른 종이에 무슨 데이터가 어떻게 저장되든 상관하지 않는다. 조회를 위한 인덱스만 하나 이상 있으면 OK.
4. 컬럼 패밀리형(Column Family)
컬럼 패밀리는 컬럼들의 집합이다. 해쉬 테이블을 생각하면 되는데,하나의 테이블에 식별하기 위한 Key와 여러개의 컬럼이 달려 있는 형태의 컬럼 패밀리이다.
관계형은 하나의 테이블에 식별이 가능한 기본키와 어러개의 컬럼을 가질 수 있지만 기본키는 필수가 아니고 같은 종류의 컬럼을 가져야 한다. Hive가 대표적인 컬럼 패밀리형 DB이다.
컬럼 패밀리형은 관계형 데이터베이스에 비해 데이터를 검색, 분석을 빠르게 할 수 있도록 다양한 서버와 네트워크 시스템을 이해하고 구축해야 한다. 이에 따라 초보자는 클라우드 컴퓨팅 서비스로 제공되는 제품으로 가져다 쓰는 것이 좋다.
 

3) DBMS(DB Management System)

4) RDBMS(Relational DBMS)

• 테이블 기반의 DBMS

• 테이블과 테이블 간의 연관관계(외래키)를 이용해 필요한 정보를 구하는 방식

• 엔티티-관계 모형(ERM)을 사용

3. ERM과 스키마

1) ERM

엔티티-관계 모델(E-R Model) 1 - 엔티티와 속성

《 엔티티-관계 모델 》엔티티-관계 다이어그램(E-R Diagram)이라고도 불리는 엔티티-관계 모델(E-R ...

https://m.blog.naver.com/PostView.nhn?blogId=qbxlvnf11&logNo=221227386956&proxyReferer=https:%2F%2Fwww.google.com%2F

엔티티-관계 모델(E-R Model) 2 - 관계

저번 글에서는 엔티티-관계 모델(E-R Model)의 개체(엔티티)와 속성(애트리뷰트)에 대해 알아보았는데요...

https://m.blog.naver.com/PostView.nhn?blogId=qbxlvnf11&logNo=221262853930&categoryNo=34&proxyReferer=https:%2F%2Fwww.google.com%2F

 

논리적 데이터 모델링 1 - 관계형 데이터 모델링

ER diagram을 관계형 데이터베이스 모델에 어울리게 변환하는 과정을 다루고 있는 수업입니다. 여기서는 Mapping rule을 중점적으로 공부합니다.

https://opentutorials.org/module/4134/25279

2) 스키마

• 외부스키마: 사용자가 본인의 입장에서 필요로 하는 데이터베이스의 논리적 구조를 정의한 것

• 개념스키마: 데이터베이스의 전체적인 논리적 구조로서, 개체 간의 관계나 제약 조건을 나타내고 데이터베이스의 접근 권한, 보안 및 무결성 규칙에 관한 명세를 정의한다.

• 내부스키마: 실제로 데이터베이스에 저장될 레코드의 물리적인 구조를 정의하고, 저장 데이터 항목의 표현 방법, 내부 레코드의 물리적 순서 등을 나타낸다.

4. 뷰와 인덱스

1) 뷰

2) 인덱스

B-Tree

5. SQL

/*
학생정보 테이블에서 이름, 1중간평균, 1기말평균, 2중간평균, 2기말평균 데이터를 가져오는데
1중간평균이 65이상인 학생의 데이터만 가져와.
그 조회결과로 뷰를 만들건데 이름을 '쫌하는애들점수'로 하겠어.
이 뷰는 읽기전용이고 편집을 못하게 할거야.
*/

CREATE VIEW 쫌하는애들점수
AS
	SELECT 이름, 1중간평균, 1기말평균, 2중간평균, 2기말평균
	FROM 학생정보
	WHERE 1중간평균 >= 65
WITH READ ONLY;

-- 테이블에서 서울지역의 전화번호 가져와.
SELECT 전화번호
FROM 전화번호부
WHERE 지역='서울'

-- 전화번호부에서 지역을 기준으로 인덱스 생성하기
CREATE INDEX IDX_LOCATION ON 전화번호부(지역);

1) SQL의 종류

(1) 데이터 정의어(DDL, Data Definition Language)

• CREATE: 테이블을 생성

CREATE TABLE STUDENT(
	STUDENT_NUM NUMBER(3) AUTO_INCREMENT PRIMARY KEY,
	STUDENT_NAME VARCHAR(10) NOT NULL,
	STUDENT_CIRCLES VARCHAR(20),
	STUDENT_BIRTH DATE NOT NULL
	CONSTRAINT ID_PK PRIMARY KEY (STUDENT_ID)
	);

• ALTER: 테이블의 속성을 변경(컬럼 추가 등)

ALTER TABLE STUDENT ADD STUDENT_ADDRESS VARCHAR2(30);

• RENAME: 테이블의 이름을 변경

RENAME STUDENT TO STUDENT_INFO;

• DROP: 테이블, 제약조건, 인덱스, 뷰 등 DB 객체를 삭제

DROP TABLE STUDENT_INFO;

(2) 데이터 조작어(DML, Data manipulation Language)

• INSERT: 테이블에 레코드를 입력

INSERT INTO STUDENT_INFO(
	STUDENT_NAME, STUDENT_CIRCLES, STUDENT_BIRTH, STUDENT_ADDRESS
	)
VALUE(
	'홍길동', '활빈당', '91/01/16', '서울시 은평구'
	);

• UPDATE: 입력된 레코드 값을 수정

UPDATE STUDENT_INFO
SET STUDENT_ADDRESS = '서울시 마포구'
WHERE STUDENT_NUM = 1 ;

• SELECT: 입력된 레코드 값을 조회

SELECT STUDENT_NAME, STUDENT_CIRCLES FROM STUDENT_INFO WHERE STUDENT_NUM = 1 ;

• DELETE: 입력된 레코드 값을 삭제

DELETE FROM STUDENT_INFO WHERE STUDENT_NUM = 1 ;
SELECT * FROM STUDENT_INFO ;

(3) 데이터 제어어(DCL, Data Control Language)

• GRANT: 특정 사용자에게 특정 데이터베이스의 이용 권한을 부여

/*
모든 ip로 접속하는 YEONGGI 사용자에게
SCHOOL DB의 STUDENT_INFO 테이블에 대한 모든 권한 부여
*/
GRANT ALL PRIVILEGES ON SCHOOL.STUDENT_INFO TO YEONGGI@'%'IDENTIFIED BY 'PASSWORD';

/*
'197.240'으로 시작하는 IP로 접속하는 YEONGGI 사용자에게
SCHOOL DB의 모든 테이블에 대해 SELECT 질의만 할 수 있는 권한 부여
*/
GRANT SELECT ON SCHOOL.* TO YEONGGI@'197.240.%' IDENTIFIED BY 'PASSWORD';

• REVOKE: 특정 데이터베이스에 대한 특정 사용자의 이용 권한을 박탈

REVOKE ALL PRIVILEGES ON SCHOOL.STUDENT_INFO TO YEONGGI@'%' ;

트랜잭션

• COMMIT: 트랜잭션의 처리 결과를 데이터베이스에 영구저장(기본적으로 AUTOCOMMIT 설정되있어 데이터조작 시 따로 COMMIT할 필요가 없음)

• ROLLBACK: 트랜잭션의 처리 결과를 취소하고 이전 COMMIT한 시점으로 데이터 상태를 원복함

ACID

1. Atomicity(원자성): 트랜잭션을 이루는 모든 연산은 모두 실행되거나, 아예 실행되지 말아야 합니다. 트랜잭션은 작업의 가장 작은 단위이기 때문입니다. 위의 예를 따른다면 차감만 되고 상대방 계좌에 추가가 안되는 일은 있어선 안된다는 의미입니다.

2. Consistency(일관성): '계좌이체'라는 트랜잭션을 이루는 연산의 내용은 미리 정의된 규칙을 따라야 하며, 성공적으로 수행되면 그 데이터베이스 상태가 일관성이 있어야 한다는 뜻입니다. 계좌에 숫자가 아닌 문자가 입금되는 일이 없어야 한다는 의미입니다.

3. Isolation(독립성): 트랜잭션이 수행되는 동안 다른 트랜잭션의 연산작업이 끼어들어 수행 중인 트랜잭션에 영향을 주면 안 됩니다. 두 사람 간의 계좌이체가 100번 연속으로 이뤄지는 트랜잭션이 있다고 할 때 DB관리자라 할지라도 트랜잭션이 수행되는 동안 그 중간 데이터를 확인할 수 없다는 의미입니다.

4. Durability(지속성): 성공적으로 수행된 트랜잭션의 결과는 안정적으로 보존되어야 한다는 특성으로, 이에 따르면 모든 트랜잭션은 로그로 남아야 하고 장애 발생 시 발생 전으로 되돌릴 수 있어야 합니다.

6. DB 설계의 역사와 현재 트랜드

• 60년 이전 : 컴퓨터가 개발된 초기 시대에는 데이터는 종이 테이프(Paper tape), 천공 카드(Punched card), 자기 테이프(magnetic tape)와 같은 순차적으로 정보를 저장하는 미디어 장비에 저장하였다. 그 결과 초반 정보 관리를 위한 노력은 파일의 구조와 정렬을 위한 알고리즘 개발을 중심으로 이루어졌다.

• 1960년대 초반 : GE(General Electric)의 Bachman에 의해 개발된 Integrated Data Store(IDS)이라는 최초의 범용 데이터베이스 관리 시스템이 소개되어 많은 인기를 끌었다. IDS의 개발은 CODASYL(the Conference on Data Systems Language)의 표준 데이터 모델 개발을 위한 주요 원동력이 되었다.

• 1960년대 중반 : 디스크와 메모리 개발에 의한 용량 증가와 가격 하락은 많은 양의 데이터 저장과 최적화된 데이터 접근을 가능하게 하였으며, IBM은 대규모 데이터베이스에 데이터 통신 기능이 추가된 정보관리시스템(IMS)를 출시하였다. IMS는 아메리카 항공과 협력하여 항공 예약 시스템 SABRE 개발에 사용되었다. IMS는 네트워크 기반 설계로 많은 사용자들의 동시 접속을 지원하였다.

• 1970년대 초중반 : 대표 컴퓨터 생산업체에서 각 업체별 메인 데이터베이스 시스템을 생산해 공급하였으며, 주요 학술 연구 영역에서 데이터베이스 시스템 연구가 활발하게 이루어졌다. 에드거 F 커드(E.F Codd)는 모든 데이터베이스 이론의 기초가 되는 관계형 모델(Relational Model)을 발표하였으며, 1975년 크리소토퍼 J 데이트(C.J Date)에 의해 최초로 관계형 데이터베이스 서적이 출판되었다. 같은 시기 피터 첸(Peter Chen)은 객체-관계 모델 데이터 설명을 다이어그램으로 표현하는 방법을 제안하였다.

• 1970년대 후반 : 관계형 모델은 주요 산업과 학술 연구 활동의 주제가 되었으며, IBM의 시스템 R 그룹에서 관계형 데이터베이스가 성능저하 없이 응용프로그램의 요청을 유동적으로 처리할 수 있다는 것을 보여주었고, 효과적인 클라이언트-서버 모델, 동시 접속 사용자 와 대용량 데이터 처리, 질의어 최적화에 의한 성공적인 성능향상을 시연해 보여주었다.

• 1980년대 초반 : 오라클(Oracle), 인그레스(Ingres), 사이베이스(Sybase), 인포믹스(Informix)등 관계형 데이터베이스 시스템을 개발하는 소프트웨어 회사들이 아주 많아 졌으며, 성능저하 없이 하드웨어 독립적인 데이터베이스 시스템 개발이 가능하다는 것을 보여주었다. 80년대는 PC(Personal Computer)의 대중화가 본격화 되면서 DBase, Paradox 같은 PC용 데이터베이스 시스템이 개발되었다.

• 1980년대 : 1985년 최초의 표준 SQL 언어가 발표되었다. 데이터 정의어(DDL), 데이터 조작어(DML)의 표준화는 신생 데이터베이스 소프트웨어 산업의 신뢰를 증대시켰다.

• 1990년대 : 대략 1990년 중반기를 전후하여 오픈 시스템인 클라이언트 서버 환경으로 전환되면서 그때까지 활용하였던 파일 시스템과 계층형 데이터베이스가 관계형 데이터베이스로 빠르게 전환되었다. 90년대 후반에 들어와서는 데이터베이스와 관계형 데이터베이스가 동의어로 느껴질 정도로 모든 분야에서 관계형 데이터베이스가 유일무이하게 사용되면서 오라클의 경우 세계에서 두 번째로 큰 소프트웨어 업체로 급부상하게 되었다. 데이터베이스에 대한 산업분야와 학문분야에서의 방대하고 활발한 연구는 누구도 예상하지 못할 정도로 품질과 관계형 모델의 응용력을 향상시켰다.

• 2000년대 : 객체지향 파라다임이 등장하면서 기존 관계형 DBMS의 공급업체들도 시장을 점유하기 위해 관계형 DBMS에 객체지향의 기능을 지원하는 ORDBMS(객체관계형 DBMS)로 전환하였다. 그러나 C나 코볼(COBOL)과 같은 구조적 개발 언어를 이용하여 시스템을 구성하는 세대에서 C++과 자바(JAVA)와 같은 객체지향 개발 언어로 시스템을 구성하는 것이 일반화된 반면, 데이터베이스는 ORDMS를 많이 사용하지만 기능은 대부분 RDBMS를 사용하고 있는 것이 2000년 초기 정보 기술의 추세다.
2000년 중반 부터 클라이언트 서버 환경에서 웹 환경의 시스템으로 시스템의 구성 흐름과 개발 방법론이 바뀌어 적용되는 것이 일반화되었으나 DBMS의 구조는 객체지향형 DBMS로 전환되지 않고 역시 4세대 DBMS인 관계형 DBMS를 여전히 사용하고 있다.
객체지향 기반의 데이터베이스는 XML과 지리정보시스템인 GIS 시스템에서 주로 쓰이고 있으며 일반적인 기업의 업무를 처리하는 단위에서는 대부분 관계형 데이터베이스를 활용하여 정보 시스템을 구성하고 있다.

• 2010년대 : 모바일 혁명과 클라우드-빅데이터의 등장으로 말미암아 관계형 데이터베이스의 여러 규칙들을 크게 파훼시킨 NOSQL이 모바일과 클라우드에서 대두되었다.

7. 상황에 따라 적합한 DB 구조 고르는 길라잡이

• MS-SQL Server / Microsoft

• MySQL / Oracle (구 Sun)

• Maria DB / MariaDB 재단

• DB2 / IBM

• Sybase / Sybase

DB-Engines Ranking

Ranking > Complete Ranking The DB-Engines Ranking ranks database management systems according to their popularity. The ranking is updated monthly. Read more about the method of calculating the scores. Share this page

https://db-engines.com/en/ranking

# DA와 DBA

• 데이터관리자(DA, Data Administrator) - 데이터 매니저의 역할. PM의 역할.

• 데이터베이스관리자(DBA, DataBase Administrator) - 데이터 개발운영자. 개발자의 역할.

#

#꿀팁 : 데이터 기획을 쉽게 하는 2가지 툴

이제 소개될 파워쿼리와 Notion 의 데이터베이스 기능은 위에서 언급한 수많은 개념중 딱 하나만 알아도 결과적으로 여러분들을 데이터베이스 기획에 실패하지 않게 해 줄 것입니다.

1. 파워쿼리

• 파워쿼리 소개
이 동영상 잠깐 보세요. 7분 짜리라서 금방 보실거예요. https://www.youtube.com/watch?v=xpvuAv55UEc



 
위에거 다보면 이것도 보세요 ^^ https://youtu.be/hbUNa8jVao0

2. Notion.so 의 데이터베이스 기능

 

(연재) 노션 좀 써볼까 #3 Database Relation & Rollup 1편

노션 page 에서 /data 라고 입력하면 Database 블록으로 들어갈 수 있습니다. Inline은 현재 작업하고 있는 페이지에 테이블을 생성하며 Full page는 다른 페이지를 생성하고 전체 화면으로 테이블을 작업하게 됩니다. 오늘 주제는 Database 전체에 언급하는 것은 아니고 Relation에 대해서만 언급하는 것이므로 개념과 실전으로...

https://medium.com/@paullabkorea/연재-노션-좀-써볼까-3-database-relation-rollup-1편-22406d4f0d52

• Thanks to Edgar Frank "Ted" Codd.