Log IN
어셈블리어, 그 더 이전으로 가면 0과 1, 트랜지스터로 되어있겠지만 어느 시점에서 High level language(컴퓨터와 가까울 수록 Low, 인간과 가까울 수록 High. Low는 우리가 이해할 수가 없다. 하는 사람들도 간혹 있겠지...??)로 올라오고 그 language들도 각각의 종류가 있다. 그 중 우리는 데이터베이스에 쓰이는 언어는 사실 우리가 눈에 보는 화면보다는 구조에 더 가까운 언어이다. DB를 깊게 알기 전에 먼저 청사진을 그려보았던 시간 같다.
1. 데이터베이스란??
데이터베이스는 여러 사람이 공유하여 사용할 목적으로 체계화해 통합, 관리하는 데이터의 집합이다. 작성된 목록으로써 여러 응용 시스템들의 통합된 정보들을 저장하여 운영할 수 있는 공용 데이터들의 묶음이다. -Wiki
자료 파일들을 조직적으로 통합하여 자료 항목의 중복을 없애고 자료를 구조화하여 기억시켜 놓은 자료의 집합체라고 할 수 있다. 쉽게 말해 데이터 기지이다. 2000년대 초반만해도 Front-End와 Back-End의 개념이 없었던 것처럼 맨 처음 컴퓨터가 만들어졌을 때는 우리가 사용하는 GUI도 심지어 CLI도 아니었다. 지금의 자바나 파이썬, 심지어 C언어 이전에는 정확히는 몰라도 어떠한 경로로 컴퓨터에 접속해서 기계의 힘을 빌렸을 것이다. 이때는 데이터를 하나의 객체로 묶을 생각은 못했던 것 같다. 물론 워낙 초창기이기도 했을 것이고. 1950년 대에 역시나 미군의 필요에 의해 데이터베이스가 만들어졌고 현재 우리가 많이 쓰는 관계형 데이터는 E.F. Codd에 의해서 발전되었다. (1981년 Turing Award)
"데이터를 한 곳에 모은다."라는 것과 "데이터끼리의 관계"라는 두 가지로 간단히 정리해 볼 수 있을 것 같다.
2.데이터베이스의 특징
- 실시간 접근성
- 지속적인 변화
- 동시 공유
- 내용에 대한 참조
- 데이터 논리적 독립성
라고 하는데 이것은 더 만져봐야 알 것 같다.
직관적으로 생각한다면
'데이터를 반영구적으로 저장하는 독립된 공간'으로 줄여볼 수 있을 것 같다.
3. 관계형 데이터베이스
키(key)와 값(value)들의 간단한 관계를 테이블화 시킨 매우 간단한 원칙의 전산정보 데이터베이스이다.
(흠... 이래서 모든 프로그래밍 언어들은 Dictionary라는 형태를 가지고 있나..?)
0과 1이 결국 Y or N로 모든 것을 표현하겠다는 것처럼 데이터는 행과 열로 표현할 수 있다고 한다. 사실 엑셀도 그렇고 많은 경우 우리는 어떤형태의 데이터건 우리가 보기편하게 만드는데 그것이 표의 형식이라는 것은 너무나도 당연한 소리일 지도 모르겠다.
우선 이 테이블에서 볼 때 가장 없어서 안되는 것이 무엇일까 라고 묻는다면?? 어떤 대답을 들을까?
답은 ID이다. 많은 경우 '당연한'것들이 가장 중요하다. 공기가 가장 중요하듯 엑셀에서도 가장 왼쪽의 1,2,3,4,5,... 의 값은 테이블에서 기본으로 지정되어있다. id값이 겹친다면 끔찍한 일이 일어날 것 같다. 마치 내 엄마가 두명 같은.
--> 이 id를 고유한 값. Prime Key (PK)라고 부른다. 축구에서도 PK가 아주 중요하니까 그렇게 외워보자. 개소리다.
3-1. 관계의 종류
관계의 종류는 크게 3가지이다.
1. One-To-One
위의 그림은 스타벅스의 메뉴테이블 중 4개만 캡쳐했다.
이 그림은 나이트로 콜드 브루(맛있음. R매장에서만 팔던거 같은데 선릉역 10번 앞에 R매장 있음.) 의 제품 영양 정보이다. 각 음료들에게 영양정보는 1:1의 관계를 가진다.
함수에서 1:1의 관계랑 같은 이야기이다.
함수는 싫어하는 사람들이 많으니 설명 건너뛰자.
2. One - To - Many
1:다의 관계 1:N이라고도 쓴다.(1:ㅜ. 울고싶다.)
나이트로 콜드브루 같은 경우는 카테고리로 볼때 콜드 브루 커피에도 들어가고 에스프레소에도 들어간다.
이런 경우에 나이트로 콜드브루를 NC라고 부르고 Category의 콜드 브루 커피를 Category: CBC, Category의 에스프레소를 Category: ESP라고 부른다고 해보면
NC는 CBC에도 들어가고 ESP에도 들어간다. 이런 경우를 1:N이라고 부른다 카더라.
자동차의 번호표가 고유하게 있다고해서(같은 번호는 발급 안됨.) 색상이 동일하지 말라는 법은 없다.(동일하지 않은게 더 신기한데;;)
3. Many to Many
제일 짜증나는 녀석. 연애도 양다리까지는 그러려니 하는데 동물의 왕국이 되어버리면 총체적 난국이 된다는 무슨 공부나하자.
Many to Many, N:N은 말그대로 A라는 테이블의 요소와 B라는 테이블의 요소가 서로가 얽히고 섥히는 관계이다.
이 구조는 WECODE의 NOTION에서 정말 잘 설명해주고 있다.
저자로이 테이블을 뜯어보면
김코드 - 위코드와 함께 시작하는 웹개발 13000
김코드 - 좋은 개발자가 일하는 방법 23000
유개발 - 위코드와 함께 시작하는 웹개발 13000
유개발 - 기술 블로그, 꼭 써야 하나요? 16000
송코딩 - 좋은 개발자가 일하는 방법 23000
송코딩 - 기술 블로그, 꼭 써야 하나요? 16000
이디비 - 기술 블로그, 꼭 써야 하나요? 16000
이렇게 쪼개진다.
여기서는 Title로 쪼갰네.
여튼. 이런 경우는 N:1 , 1:N의 관계를 다시 정립해줘야지 데이터로 접근이 가능하다. N:N에서 바로 접근하는 무언가를 만들어낸다면 대박이긴 하겠네.
Author, Author Book, Book으로 쪼갰을 때
Author랑 Book은 겹치는 것이 없게 만든다.
그리고 중간 테이블을 하나 더 만들어서 각각 매칭을 시켜준다.
말이 쉽지 나는 쉽지 않더라.
3-2 데이터끼리의 연결
아까 PK(Primary Key)는 각 테이블당 고유하게 한번씩만 들어가는 요소로 가지고 있어야 된다고 했다. 그리고 각 테이블에 FK(Foreign Key)를 설정해준다. 그리고 서로 연결되는 테이블의 관계에 따라 FK를 연결해준다. 
근데 이건 해보는게 가장 빠르다.
그나마 쉽게 설명하자면 PK는 각자 하나밖에 못가지는데 FK는 여러번 줄 수도 있다고 생각하면 그나마 쉬울 것 같다.
LOG-OUT
스타벅스과제를 하다보면 어떤 것이 1:1, 1:N, N:N인지가 헷갈린다. 나도 모르게 영양정보 그 자체를 놓고 보는 것이 아니라 영양정보 속의 또 다른 요소를 보다보면 엇 이건??? 이러면서 1:N으로 생각해버리기가 쉬운데 내가 했던 방법을 이야기 하자면 Table 명만 보았다. 영양정보라고 하면 하위는 빼고 그냥 영양정보만. 영양정보는 각 음료에 한번씩 들어가니까 1:1. 카테고리랑 음료명을 보게된다고 하면 카테고리는 1번씩 있는데 음료명은 그 카테고리에 몇번 들어갈 수도 있으니까 1:N. 알러지와 음료의 관계는 N:N(왜냐하면 알러지가 같은 음료에 두개가 들어갈 수도 있고, 알러지 자체는 다른 음료에 여러번 들어가기도 하니까)그러면 N:N은 다시 N:1, 1:N으로 어떻게 쪼갤까.
이런식으로 고민하다보면 다시 DB라는 것을 놓칠 수도 있는데 결론은 여러번 복습해보는 것이 가장 좋은 것 같다.
그래도 0,1 트랜지스터 안건드리는 것이 어디냐 하면서 감사하자.
