#085_닷넷(.NET)_ ADO.NET - 관계형 DB & 객체형 DB

안녕하세요 삽잡이입니다.

이번 시간도 역시 ADO.NET에 들어가기 이전에

선행학습으로써 DB에 대해서 더 알아보고자 합니다.

이번에는 DB를 만들어낼 때 그 '규칙'에 대해서 알아보고자합니다.

DB는 크게 DBMS가 무엇이던지간에

두가지로 구성되게 되어있습니다.

즉, 규칙을 만들어내는 방법이 두가지라는 것입니다.

물론, 더 있을 수 있으나 가장 일반적인 두가지라는 것이죠.

이는 '관계형 DB'와 '객체형 DB'입니다.

DB는 규칙성 있는 데이터의 집합이고,

그 규칙성을 만들어낼 때에 일반적으로 사용하는 방법이 두가지라는 것입니다.

그런데, 현존하는 DBMS는 대부분 관계형 DBMS입니다.

그러니까 DBMS가 관계형 DB를 통해 규칙을 만들고 DB를 관리한다 이겁니다.

관계형 DB의 핵심은 두 가지 입니다.

바로, Table과 관계(Relative)이지요.

테이블은 또한 관계형 DB에서 나뉘어서 

Column이라는 보관되는 스키마와, Row로 나뉘게 됩니다.

스키마는 우리말로 번역하면 형식, 구조를 의미합니다.

스키마라는 것은 객체지향에서 Class와 같은 것이지요.

클래스는 객체에 대한 정의지요.

테이블의 스키마라고 하면 테이블이 어떻게 이루어져있겠다는 

형식, 구조를 나타낸다 이겁니다.

스키마의 핵심은 Column입니다.

예를 들어, 이름 Column, 학번 Column 나이 Column등의 

컬럼들을 가져야 테이블이 될 수 있지 않나 이겁니다.

Row는 컬럼을 보고 만들어진 '실제 데이터'들입니다.

이름은 삽잡이, 학번은 201055016, 나이는 25...

이런게 실제 데이터이며 Row라고 한다 이겁니다.

테이블의 구조는 Column에 의해서 결정됩니다.

테이블에는 해당 테이블에 맞는 Column들이 있을 것 아니겠습니까?

또한 위의 예제와 같이, 

삽잡이, 201055016등은 실제 데이터로써 존재하게 되지요.

그런데, 테이블이 관계형 DB의 모든 것을 나타낼까요?

정답을 말씀드리자면, 아닙니다.

각 테이블간의 관계도 필요합니다.

 

row에 값이 같지만, 실제로 다른 경우를 생각해보겠습니다.

둘은 이름이 똑같아도 ID인 생년월일이 다르다면?

다른 사람이라는 것이지요.

이처럼 테이블간에 관계가 성립될 수 있습니다.

서로 테이블간에 관계가 있다면,

즉, 테이블에 대한 ID가 연관성을 가지게 될 수 있다 이겁니다.

정리해보겠습니다.

관계형 DB에서 핵심은 '테이블'과 '관계'입니다.

테이블은 스키마(구조)를 이루는 필드들과, 

실제 테이블 내용물인 Contents 즉, 데이터를 이루는 row로 이루어집니다.

관계는 실제 내용물이 테이블에 써지면 여러가지 문제가 생길 수 있기 때문에

타른 테이블에서 정리해서 연결을 해준다는 것입니다.

따라서, Primary Key와 

다른 테이블에서 사용하는 Foreign Key를 사용할 수 있지요.

DB에서 스키마는 형식이나 구조를 뜻합니다.

스키마는 사용하는 곳마다 의미가 조금씩 달라질 수 있기 때문에

DB에 대한 스키마에 이해를 확실히 하시길 바랍니다.

니가 뭘 이해할걸 줬냐...

DB에서 스키마는...

테이블과 관계로 이루어져있습니다.

물론, 약속이라는 집합과 제약, 속성들의 집합으로 이루어져있지요.

A라는 DB의 스키마라고 하면,

'A' DB가 어떻게 이루어져있는지에 대한 구조와 형식이 포함되니, 

데이터는 포함되지 않습니다.

테이블의 Row는 데이터이기 때문에 스키마에 들어가지 않는다 이겁니다.

테이블과 어떤 테이블이 있는지에 대한 구조가 

바로, 스키마가 될 수 있다 이겁니다.

구조, 형식과 데이터는 무관합니다.

DB 용어에서 클래스는 객체의 스키마가 된다고 생각하시면됩니다.

한 DB를 이루고 있는 테이블중 하나가 빠진다면,

구조가 달라져 버리기 때문에 같은 DB라고 볼 수 없습니다.

따라서, 제일 우선적으로는 테이블과 관계에 대한 모든 스키마가 우선적이지요.

계속해서 반복적으로 말씀드리지만,

DB에 대한 스키마와 테이블에 대한 관계들이 DB의 스키마가 됩니다.

관계형 DB만 계속 말씀드렸군요...

객체형 DB는 진짜 객체처럼 다루는 것입니다.

DB를 조직화할 때, 규칙을 만들 때 모두 객체지향으로 만든다 이겁니다.

어플리케이션에서는 좋겠지만,

데이터를 Disk 상에서 관리할 때에는 불편합니다.

따라서, 아직도 DBMS에서는 대부분 관계형 DB를 사용하고 있지요.

물론, 안좋은 것만 있는 건 아닙니다.

DB에 있는 내용을 그대로 읽어들일시, 

객체지향의 어플리케이션 집합으로 바로 만들 수 있다는 장점이 있습니다.

즉, 변환하기 쉽다는 것이지요.

그런데, 대부분 데이터는 선형적으로 관리하는 것이 좋기 때문에

Disk 상에서 조직하는 것이 불편하고 비효율적이라는 단점을 가지고 있습니다.

아무튼... 

관계형 DB가 아직까지는 더 많이 사용되고 있습니다.

테이블과의 관계가 가장 중요하겠고,

테이블에서도 Column이 중요합니다.

Column 없이 데이터가 존재할 수 없지요.

데이터의 형식이 Column이니깐요.

테이블 없이 관계형 DB는 존재할 수 없습니다.

핵심적인 스키마이기 때문입니다.

관계없이도 역시 존재하기 힘듭니다.

하지만, 가장 큰 핵심은 테이블입니다.

이번 시간은 여기까지 하도록 하겠습니다.

이상 삽잡이였습니다!