[DB 2장] View, 추상화, 독립성, 스키마, 모델

데이터 베이스에서 뷰란?

  뷰(=view)는 가상 테이블(=virtual relation)이라고도 한다.

---

자료의 추상화(data abstraction) 세 단계

  데이터베이스 관리 시스템과 사용자 사이의 상호 작용을 쉽게 풀이하기 위하여 데이터베이스의 자료를 추상화하며, 보통 다음과 같이 세 가지 수준으로 나눈다.

  하지만 이는 개념모델(reference model)이다. 즉 꼭 따라야 하는 것은 아니며 데이터 베이스의 모든 시스템이 이 모델에 의하여 구성된 것은 아니다.

  이는 마치 데이터통신에서(ISO OSI의 일곱 단계 통신모형에 맞는 통신 프로그램이 거의 없는 것이나 마찬가지이다.)

  1) 물리적 수준(physical level)

  자료가 실제로 저장되는 수준이며, 가장 아래 수준이다.

  2) 논리적 수준(logical level)

  이것은 데이터베이스 관리자(DBA : database administrator)이 처리하는 수준이다.

  3) 뷰(=가상 테이블) 수준(view level)

  일반 사용자가 쓰는 수준으로 볼 수 있다. 이런 것이다. 데이터란 결국 바이트단위로 처리를 하게 되는데. 이는 기계어로 보면 왠만해서는 알아볼 수 없다.

  하지만 문서처리 프로그램중 엑셀프로그램 처럼 도표로 사용자가 볼 수 있고 권한에 따라서 필요한 부분만 수정할 수 있다면? 이런 부분이 바로 view 수준이라고 한다.

  그런데 실제 상용 데이터베이스 관리 시스템에서 어떤 명령이 어느 수준에 해당하는지 명확하게 나누는 것은 쉽지 않다. 뷰 수준은 그런데로 쉽게 알 수 있지만 물리적 수준과 논리적 수준은 때때로 경계가 모호하다. 하지만 앞서 말했듯 위의 세가지 모델은 어디까지나 참조 모델일 뿐이므로, 구체적인 어떤 사용 데이터베이스 관리 시스템의 명령을 세단계로 나누는 문제에 너무 매달리지 말자.

---

자료의 독립성(data independence)

  일반적으로 자료의 독립성이란 어느 단계의 스키마를 바구었을 때, 그 위 단계의 스키마에 영향을 주지 않고 결국 응용 프로그램에 영향을 주지 않는 것을 가리킨다.

  c++로 친다면 클래스 간의 의존성 제거 객체지향적으로보면 리스코프 치환법칙과 의미가 통한다.

  자료의 독립성은 다음과 같이 두가지로 나타나게 된다.

  1) 물리적(physical) 자료 독립성

  맨 아래 단계인 물리적 스키마를 바꿔도, 그 위 단계인 논리적 단계 스키마에 영향을 주지 않는 것을 가리킨다. 당연히 논리적 스키마에 영향을 주지 않으므로 그 위 단계인 뷰 단계의 스키마에는 물론 영향을 주지 않는다.

  

  여기서 잠깐! 스키마란?

  데이터베이스 스키마(database schema)는 데이터베이스에서 자료의 구조, 자료의 표현 방법, 자료 간의 관계를 정의한 것을 말하는 전산학 용어이다. 데이터베이스 관리 시스템(DBMS)이 주어진 설정에 따라 데이터베이스 스키마를 만들어 내며, 데이터베이스 사용자가 자료를 저장, 조회, 삭제, 변경할 때 DBMS는 그것이 생성한 데이터베이스 스키마를 참조하여 명령을 수행한다.

  2) 논리적(logical) 자료 독립성.

  가운데 단계인 논리적 단계의 스키마를 바꿔도 그 윗 단계인 뷰 단계의 스키마에 영향을 주지 않는 것을 가리킨다. 뷰 단계 스키마에 영향을 주지 않기 때문에, 그 결과 응용 프로그램에도 영향을 주지 않는다.

  이때 이 두가지 독립성 단계에 대해서 제대로 설명하지 않는 부분이 많은데 그 이유는 상용 데이터 베이스 관리 시스템에서 물리적 단계와 논리적 단계를 나누기가 쉽지 않기 때문이다.

  하지만 SQL명령어 적으로 예를 들어 보겠다.

---

  create table 유저 {순서인덱스 cahr(7), 아이디 cahr(20)};

  위의 create table 명령은 순서인덱스와 아이디이라는 속성으로 이루어진 학생이라는 테이블을 만든다. 그 뒤 아래에 select 명령을 쓰면, 아이디가 '홍길동'이라는 유저의 이름을 보여준다.

  select *

    form 유저

    where 아이디 = '홍길동';

  자료의 독립성에 관한 구체적인 첫번째 보기는 색인(= 찾아보기, index)이다. 색인이 있으면 검색속도가 빨라지게 되는데.

  보기를 들어 유저수가 10000명인데 유저자료가 아이디 순서대로 간추려져 있다면 이름에 대한 색인이 없다고 한다면 create index 명령을 써서 이름에 대한 색인을 만들어 둔뒤 '홍길동'을 찾으면,색인이 없을 때보다 검색 속도가 훨씬 빨라진다.

  create index 이름_색인

  on 학생(이름);

  select *

  form 유저

  where 아이디 = '홍길동';

  

  그런데, 여기서 중요한 것은 색인이 새로 만들어 지더라도, 위의 select 명령을 전혀 바꾸지 않고 꼭 같은 결과를 얻을수 있지만, 색인이 있든 없든, select 명령은 바뀌지 않고 그대로 이고, 다만 실행 속도가 달라질 뿐이다.

  자료 독립성에 관한 구체적인 둘째 보기는 뷰에 관한 것이다. 보기를 들어, 아래와 같이 순서 인덱스, 아이디, 패스워드로 이루어진 유저이라는 테이블이 있고, 학생이라는 테이블에서 create view 명령을 써서, 학번과 이름만으로 이루어진 학생_view라는 뷰를 정의했다고 하자

  create table 유저 {순서 인덱스 char(7), 아이디 char(10), 패스워드 char(15)};

  create view 유저_view as

   select 순서 인덱스, 아이디

     from 유저;

  이렇게 하면 응용 프로그램에서는 유저_view라는 뷰를 다음과 같이 쓸 수 있다.

  

  select *

    from dbwj_view

    where 순서인덱스 = '9902101';

  그런데 학생에 휴대전화라는 속성이 하나 더 들어가서 유저의 스키마가 다음과 같이 바뀌었다고 하자.

  

  유저 {순서 인덱스 char(7), 아이디 char(10), 패스워드 char(15), 휴대전화 char(15)};

  

  유저의 스키마가 이렇게 바뀌더라도 결국 유저_view를 정의하는 create view 명령을 바꿀 필요가 없으며, 또한 유저_view를 쓰는 응용프로그램에서 select 문장을 전혀 바꾸지 않아도 결과는 제대로 나온다. 유저의 스키마가 바뀌었지만, 유저_view의 정의를 바꿀 필요가 없으며, 유저_view 뷰를 쓰는 응용프로그램에서 SQL문장을 전혀 바꿀 필요가 없다.

  이를 고급프로그래밍 언어 C++에서 처리한다고 생각해보자.

found=0 ; 

for 0=1; (= num_records ; i++) { 

read from 유저_view 순서인덱스 , 아이디) ; 

if (아이디 = 홍길동’) { 

printf (학번, 01 름) ; found++ ; 

} // endif 

} // end for 

if (tound == 0) 

  printf 홍길동 학생이 없습니다 ) ;

식으로 짜며 당연히 다형성이나 그때그때 필요한 코드를 또다시 짜야만 할것이다.

물론 이런 것을 감안하고 프로그래밍 할 수는 있지만 그것은 이미 존재하는 데이터 베이스 시스템과 같은 역할을 하는 파일입출력 프로그램을 고급언어로 다시 짠다는 것인데 엄청난 노력과 시간이 들어가게 될 것이다.

---

스키마(schema)와 인스턴스(instance)?

  데이터 베이스와 관련하여 스키마와 인스턴스는 구별되어야 하는데 관계형 데이터 베이스의 경우에는 관계(= 테이블, relation)와 데이터베이스 각각에서 스키마와 인스턴스 개념이 적용된다. 다시 말하여 테이블의 스키마와 테이블의 인스턴스가 존재하며 또한 데이터 베이스의 스키마와 데이터베이스의 인스턴스라는 개념이 존재한다는 것이다.

  관계형 데이터베이스 환경에서 관계의 스키마와 관계의 인스턴스를 비교해보자. 아홉 자리를 차지하는 순번 인덱스이라는 속성(attribute), 스무 자리를 차지하는 아이디이라는 속성, 그리고 열 다섯 자리를 차지하는 패스워드라는 속성으로 이루어진 학생이라는 관계를 만드는 SQL 문장 create table가 아래에 나와있다.

---

  create table 유저 {순서 인덱스 char(7), 아이디 char(10), 패스워드 char(15)};  

  이 문장은 학생이라는 테이블에 어떤 속성(순서 인덱스, 이름, 집전화)가 있으며, 각 속성의 자료형(data type)가 무엇인지만 나타낸다. 다시 말하면 테이블의 틀(=뼈대)을 나타낼 뿐, 그 테이블 안에 어떤 자료가 실제로 들어있고 어떤 식으로 데이터베이스의 로직이 이루어지는지는 알수가 없다.

  이처럼 테이블에 있어서 속성 이름과 자료형 등에 관하여 규정하는 것을 관계(=관계)의 스키마라고 한다. 위의 create table라는 SQL 명령은 학생이라는 테이블(=관계)의 스키마를 만드는 명령이다.

  위에 설명한 단어의 원론적인 설명과 다르게 데이터베이스에서 스키마(SCHEMA)는, 틀, 뼈대 등의 뜻이 있으며 보통 한글로 옮기지 않고 스키마라는 용어를 그대로 사용한다.

  데이터 베이스는 일반적으로 도표형식으로 내용을 볼 수 있는데.

  유저   순서인덱스    아이디    패스워드

          0000000001   ID1        23451123

        00000000012   ID2       123456

  

  이런식으로 어떤 특정 시점에 테이블 안에 있는 구체적인 값의 집합을 관계(=테이블)의 인스턴스라고 한다.

  그런데 일반적으로 테이블의 스키마는 처음 만들 때 잘 생각해서 만들기 때문에, 일단 스키마를 한번 만들면 잘 바꾸지 않는다. 거기에 비해서 테이블의 인스턴스는 상대적으로 스키마보다는 많이 바귀게 된다.

일단 스키마가 바뀌는 경우를 보도록 하자. 

• 현재 있는 학번, 이름, 집전화 속성 가운데 어떤 속성을 빼기 . 

보기 . 패스워드를 뺀다

  create table 유저 {순서 인덱스 char(7), 아이디 char(10)};  

·현재 없는 속성을 더 넣기 . 

보기 : 보유 캐릭터 개수를 더 넣는다. 

  create table 유저 {순서 인덱스 char(7), 아이디 char(10), 패스워드 char(15), 보유 캐릭터 개수 int };  

휴대전화 char(15)); 

• 속성의 자료형을 바꾼다, 

보기: 패스우드의 자료형을 char(15) 에서 char(20) 로 바꾸었다. 

  create table 유저 {순서 인덱스 char(7), 아이디 char(10), 패스워드 char(20), 보유 캐릭터 개수 int };  

  당연히 데이터 베이스의 테이블이 많아질수록 수많은 유저들의 정보가 통채로 입력되므로 그에 맞는 정보를 입력해줘야 한다. 유저수가 많으면 많을 수록 보통 번거로운 것이 아닐 것이다. 거기에 비해서 테이블의 인스턴스는 상대적으로 많이 바뀌지 않는다. 인스턴스가 바뀌는 경우에 대해서 예를 들어본다면

  유저가 한명 추가되어 맨 마지막줄에 새로운 유저가 들어오는 경우.

  혹은 한명의 유저의 패스워드가 변경된 경우.

  이외 등등등.

  과 같은 경우 인스턴스가 바뀌었다고 하는데. 일반적으로 테스블의 한 행이 바뀌거나, 추가되거나, 삭제되면 인스턴스가 바뀐다고 하며 예상해봐서 알겠지만 당연히 인스턴스는 자주 바뀐다.

---

  자료 모델?

  데이터베이스에서 자료를 나타내는 방식은 여러가지가 있으며, 책에 따라 나누는 기준이나 방법도 다르다. 

  어떻게 나누냐는 덮어 두고 실제 쓰여졌던 데이터 베이스의 모델들에 대해서 알아보겠다.

  개체 - 관계모델(E-R : entity - relationship model)

  개체 - 관계 모델은 데이터베이스 설계(data base design) 때 많이 쓰인다. 그렇지만 개체 - 관계 모델에 따른 데이터 베이스 관리 시스템 프로그램이 개발되어 있지 않기 때문에, 실제 자료를 처리하기 위하여 우리가 개체 - 관계 모델을 쓰지는 않는다.

   개체 관계 모델은 실제 세계에 대한 인식을 바탕으로 한다 객체지향프로그래밍과 닮은 방향성을 가지고 있어 보인다. 이 모델은 첫째, 개체(entity), 둘째 개체와 개체 사이의 관계(relationship), 이 두가지를 기본으로 하고 있어서 개체 - 관계 모델이라고 부른다.

  개체란, 학생, 과목, 은행 계정, 회사 등과같이 실제 세상에 있는 객체를 가리키며, 각 객체는 다른 객체와 구별된다. 개체는 하나 또는 여러개의 속성으로 나타내게 된다. 유저를 패스워드 순서 인덱스 아이디라고 나눈 것과 같다.

  이에 쓰이는 용어는 개체 집합, 관계 집합, 개체 사이의 사상(=매핑) 크기(mapping cardinality) 제약, 개체 - 관계 모델 그림 (diagram) 등이 있다.

  

  객체지향 모델(OO model, object - oriented model)

  객체지향 모델은 개체-관계 모델을 수용하고 거기에 실행할 수 있는 프로그램까지 모두 포함한다.

  관계형 모델 (relational model)

  관계형 모델은 오늘날 가장 널리 쓰이고 있는 관계형 데이터베이스의 바탕이 되는 모델이다.

  자료(data)를 나타낼 때, 그리고 자료사이의 관계(relationship)를 나타낼 때 모두 관계(relation, 또는 테이블 : table, 표)를 쓰기 때문에, 관계형 모델이라고 부른다. 관계형 데이터베이스는 1970 년대에 연구가 시작되어 오늘날 가장 널리 쓰고 있다.

  네트웍 모델(network model)

  관계형 모델이 나오기 전에, 네트웍 모델에 바탕을 둔 사용 프로그램을 1960년대 후반부터 썼지만, 요즘은 이 모델을 사용하여 제작되는 데이터 베이스는 거의 없다.

  계층적 모델(hierarchical model)

  관계형 모델이 나오기 전에 계층적 모델에 바탕을 둔 사용 프로그램을 1960년대 후반부터 썼지만, 요즘 새로만들 때 역시나 이 모델을 쓰는 곳은 거의 없다.