(1) 등장 배경

RDBMS가 현실 세계를 잘 반영하고 있는 것은 아닙니다. 관계형 데이터 모델(data model)에 부과된 제약에 의해 제한을 받게 되는데, 이러한 제약들로는 균일성(uniformity), 레코드 지향성(record orientation), 필드 값의 원자성(atomicity) 등이 있습니다. 또한 어떤 응용 프로그램의 경우 RDBMS가 지원하지 못하는 데이터 값이나 SQL보다 더 풍부한 표현력을 원할 때도 있습니다.

이상과 같은 관계형 시스템의 제한을 극복하고, 더 확장된 언어를 제공하기 위해 등장한 것이 객체지향(object-oriented) 모델입니다. 하지만 이 또한 완전한 모델이 아니기 때문에 질의 처리와 같은 관계형 모델의 많은 장점을 버려야 하는 단점을 안고 있습니다.


(2) 객체의 특징

6장에서는 객체의 정의에 대해서만 언급했는데, 여기서는 그 특징들에 대해서도 살펴보도록 하겠습니다. 우선 객체가 가지고 있는 특징을 대표하는 단어를 나열하면 다음과 같습니다.

캡슐화 (encapsulation)

6장에서 "객체는 변수들과 그와 관련된 메소드들의 묶음"이라고 정의했습니다. 현실 세계의 모든 사물(개념적인 사물도 포함)은 객체가 될 수 있기 때문에 자동차를 예로 들어보겠습니다.

자동차는 바퀴, 엔진, 의자 등의 또 다른 객체를 소유하고 있으며, 이들은 모두 객체의 변수로 생각할 수 있습니다. 이 변수에 지름이 70Cm인 바퀴, 2,500cc 엔진, 가죽 의자 등의 값이 들어가게 됩니다. 또한 자동차는 시동을 건다, 사람을 태운다, 달린다 등의 행위를 표현하는 메소드들을 가지고 있습니다. 즉, 자동차라는 객체는 내부(작은 원)에 ㅇ,ㅁ등으로 구성된 변수들이 있고, 그 주위를 메소드들이 둘러싸고 있다고 보시면 됩니다.

이와 같이 변수의 내용이 외부(큰 원 바깥)에 보여지지 않도록 보호하는 것을 캡슐화(encapsulation)라고 합니다.
캡슐화를 간단하게 정의하면 '자세하고, 세부적이지만 외부 세계에서는 크게 중요하지 않은 것을 외부로부터 숨기는 것'이라고 생각하시면 됩니다. 자동차에서 운전자가 볼트나 너트 등이 어디에 붙어 있는지, 연료가 어디로 이동되는지, 바퀴가 어떻게 회전하는지 등에 대해서는 알 필요가 없기 때문에 이것들에 대한 학습은 필요가 없다는 것이죠.

이러한 캡슐화의 첫번째 장점은 모듈화(modularity)가 가능하다는 것입니다. 모듈화란 객체에 대한 원시 프로그램(source program)이 다른 원시 프로그램과는 별개의 독립적인 프로그램으로 작성되고 유지될 수 있음을 의미합니다.

위에서 예를 든 자동차를 이용해서 설명하면, 자동차에 사용되는 바퀴, 나사, 의자, 오디오(각각이 모듈에 해당하겠죠!) 등은 하나의 공장에서 모두 제작하지 않고, 전문화된 공장에서 특정 상품을 생산하면 더 질 좋고 특화된 제품을 생산할 수 있을 것입니다. 이렇게 자동차의 생산에 사용되는 모든 부품 (모듈화된 객체)을 모듈화시켜 필요할 때 갖다 사용하게 하는 것입니다.

두번째 장점은 외부에 공개된 변수들과 메소드들 이외의 정보들에 대해서는 은닉 (information hiding)할 수 있다는 것입니다.

자동차 운전자는 자동차의 엔진이 어떻게 작동하는지, 바퀴와 차체가 어떻게 연결되어 있는지 등의 정보에 대해서는 알 필요가 없습니다. 만약 모두 다 알아야 한다면 우리 나라의 교통환경이 조금은 좋아지겠죠? 이렇게 내부의 세세한 정보를 알 필요 없이 그 사용법만 알면 사용할 수 있도록 제공해주는 캡슐화의 장점이 바로 정보의 은닉입니다.


메시지 (message)

 

앞에서 언급한 자동차는 하나의 객체로 구성된 것이 아니고, 바퀴라는 객체, 엔진이라는 객체, 차체라는 객체 등 다양한 객체들로 구성되어 있습니다. 즉, 최소 단위의 객체를 이용해서 또 다른 객체를 생성할 수 있으며, 이들을 서로 연관시켜 다른 기능과 특성을 갖는 또 다른 객체를 생성할 수 있습니다. 이렇게 여러 객체들을 모아서 다른 객체를 만들면, 객체들끼리의 의사소통이 필요하게 됩니다. 이렇게 객체들 간의 의사소통이나 통신을 하기 위해서 사용되는 것이 바로 메시지(message)입니다. 예를 들면 엔진이라는 객체의 회전 동작이 바퀴에 전달되는 과정이 바로 메시지에 의해서 발생된다는 것입니다.

메시지는 다음과 같이 세 가지의 구성요소를 가집니다.


메시지를 받을 객체(바퀴)
메시지를 받아서 수행되는 메소드의 이름(바퀴 회전하기)
수행되는 메소드에서 필요로 하는 매개 변수 혹은 파라미터(시속 50Km로 회전)


메시지를 사용할 때의 장점으로는 다음의 두가지가 있습니다.

객체의 행동은 객체에 포함된 메소드들에 의해서 표현되는데, 메소드들 간의 메시지
    전달은 객체들간의 모든 상호 작용을 표현할 수 있습니다.

객체들간에 메시지를 주고 받기 위해서 객체들이 반드시 한 기계 내에 존재할 필요가
    없습니다.

자동차가 전진하고, 정지하고, 후진하는 모든 과정은 운전자가 브레이크, 엑셀레이터, 기어 등의 객체를 이용한 결과입니다. 이러한 객체들의 단순한 조작이 자동차를 움직이게 하기 위해서는 객체간에 힘과 방향이 전달되어야 합니다. 이 힘과 방향이 바로 객체들 사이의 메시지가 되는 것입니다. 전진하기 위해서는 기어를 바꿔주고 엑셀레이터를 밟으면 됩니다. 기어를 바꿀 때 '기어 변경'이라는 메시지가 전달되고, 엑셀레이터를 밟을 때, '엔진의 출력을 높여라'라는 메시지가 엔진에 전달되는 것입니다.

 

클래스 (class)

세상에는 동일한 종류의 많은 객체들이 존재하고 있습니다. 예를 들어 본인이 A사의 B 모델 차를 소유하고 있다면, 이 B모델의 차는 자동차라는 개념(최소 4개의 바퀴와 하나의 엔진, 운전석 등은 반드시 가짐)을 물려받은 하나의 구체적인 실체입니다.

컴퓨터적인 용어를 사용하면, B 모델의 차는 자동차라는 객체(틀) 클래스(class, 개념, 설계도)의 한 인스턴스(instance, 실체)입니다. 즉, 클래스라는 설계도를 바탕으로 객체라는 틀(자동차의 경우 생산 라인이 되겠죠!)을 제작한 후에, 이 틀에 맞춰 인스턴스라는 실제 자동차를 만든다라고 보시면 됩니다.

소프트웨어에서 클래스란 객체에 대한 설계도라고 할 수 있는데, 이에 대한 좀 더 정확한 정의를 내리면 '클래스는 같은 종류의 모든 객체들에 공통인 변수들과 메소드들을 정의한 설계도 또는 청사진이다'라고 할 수 있습니다.

자동차 객체를 사용하기 위해서는 그 자동차 객체가 있어야 하고, 자동차 객체를 생성하려면 자동차 클래스가 있어야 합니다. 객체가 생성될 때, 시스템은 그 객체에서 그 객체가 속한 클래스에 정의된 인스턴스 변수들을 위한 기억 공간을 할당하게 됩니다. 객체의 메소드들은 객체의 인스턴스 변수들을 사용하므로 객체가 생성되어야 그 객체의 인스턴스 메소드들을 사용할 수 있습니다. 인스턴스 변수들과 달리 객체의 메소드들은 객체마다 기억 공간을 잡으며 존재하지 않습니다.

요약하면, 제일 먼저 자동차에 대한 설계(클래스)가 이루어집니다. 이 설계도를 바탕으로 모형(객체)이 만들어지고, 모형이 성공적이면 이 모형에 맞춰 실제 제품(인스턴스)을 생산해서 판매(메모리 영역을 점유)하게 되는 것입니다.


객체와 클래스를 분명하게 구분하여 사용하는 사람은 드물기 때문에 일반적으로 혼용해서 많이 사용합니다. 여러분도 이해하시기 편하게 생각하시면 될 것입니다. 클래스는 재사용성(reusability)이라는 장점을 가지고 있으며, 어떻게 생각하면 객체의 장점이 클래스의 장점이 될 수도 있습니다. 즉, 설계도를 이용해서 자동차를 반복 생산할 수 있다고 보시면 됩니다.

 

상속 (inheritance)

 

일반적으로 객체가 속한 클래스를 알면 그 객체의 구조와 행동에 대해 알 수 있습니다. 객체 지향 시스템에서 새로운 클래스를 기존에 존재하는 클래스의 하위 클래스(서브클래스)로 만들 수 있습니다. 예를 들어 EF 소나타는 소나타 III, 소나타 II, 소나타 등의 후속으로 등장했기 때문에 EF 소나타는 소나타의 서브클래스라고 할 수 있습니다.

각 서브클래스는 그 클래스 자체의 상위 클래스(슈퍼클래스)로부터 변수들과 메소드들을 상속(inheritance) 받습니다. 즉, 슈퍼클래스에서 공통된 특성을 작성하고, 서브클래스들은 슈퍼클래스의 특성을 상속 받는 것입니다. 마치 자식들이 부모의 외모나 성격들을 상속 받는 것과 같은 이치라고 생각하시면 됩니다. 그렇다고 자식이 부모와 완전히 동일한 것은 아니죠. 자신에게 필요한 다른 성격을 가지는 것처럼 객체도 자신에게 더 필요한 변수들과 메소드들을 가질 수 있습니다.

상속은 하나의 슈퍼클래스를 상속 받는 단일 상속과 여러 슈퍼클래스로부터 상속 받는 다중 상속으로 구분되며, 상속을 받는 서브클래스는 슈퍼클래스의 속성과 메소드들을 상속 받습니다.

상속이 갖는 이점에는 다음의 두가지가 있습니다.

슈퍼클래스로부터 공통된 특성을 상속받기 때문에 슈퍼클래스의 코드를 여러번
    재사용할 수 있습니다.

다양한 융통성을 가질 수 있도록 프로그래밍할 수 있습니다.

이상의 내용이 약간은 어려우시겠지만 이해하고 있으면 상당히 유용하게 사용될 것 같아 장황하게 설명을 드렸습니다. 그럼 다시 데이터베이스적인 관점으로 넘어가도록 하겠습니다.

 


   
(3) 객체지향 모델

객체지향 모델은 앞에서 언급된 객체지향 프로그래밍에 근거를 두고 있습니다. 여기서는 모든 것을 언급하기 보다는 핵심적인 모델링 개념에 대해 간단히 요약하는 것으로 끝내겠습니다.

객체와 객체식별자
현실 세계에서 임의의 한 존재는 하나의 객체가 될 수 있으며, 각각의 객체는 하나의 객체 분류 시스템에서 유일한 이름(식별자 OID: Object Identifier)을 갖습니다. 즉, 한국 사람이라는 객체 분류 시스템에서 그 사람의 유일한 객체 식별자는 주민등록번호가 되는 것입니다.
속성과 메소드

객체는 하나 이상의 속성을 가지며, 속성 값상에서 작동할 수 있는 하나 이상의 메소드가 존재합니다. 객체의 속성 값 또한 객체입니다. 이때 속성은 하나의 값(더 이상 쪼갤 수 없는 최소 단위의 객체)을 가질 수도 있고, 여러 개의 값을 집합 형태(쪼갤 수 있는 객체)로 가질 수도 있습니다.
사람의 경우 눈이라는 객체는 망막, 수정체 등의 속성을 가지고, 본다, 굴린다 등의 메소드를 가지며, 망막은 더 작은 세포 단위의 객체로 나눌 수가 있는 것입니다.

캡슐화와 메시지 전달

어떤 객체의 속성값과 그 속성에 속한 메소드들에 접근하기 위해서는 그 객체로 메시지를 보내야 합니다. 각 객체에 명기된 공용 인터페이스를 통하지 않고는 그 객체에 접근할 수 없습니다.

클래스

같은 속성들과 메소드들을 공유하는 모든 객체는 하나의 클래스로 묶을 수 있습니다.

클래스의 상속

임의의 객체지향 시스템에서 클래스는 임의 개수의 하위 클래스를 가질 수 있습니다.

 


   


객체지향 개념은 각각 다른 세 분야에서 발전되어 왔습니다.

프로그래밍 언어
프로그래밍 언어에서는 Simula-67 을 객체지향 프로그래밍 언어의 효시로 보며, 이 분야에서도 기존의 프로그래밍 언어를 확장하는 방식과 새로운 객체지향 언어를 개발하는 방법으로 나누어져 개발되었습니다.
인공지능(AI : Artificial intelligence)

프로그래밍 언어에서 얼마나 사람의 사고를 잘 반영할 수 있느냐에 따라 인공지능 분야도 많은 영향을 받기 때문에, 인공지능 분야에서도 객체지향에 대한 연구가 많이 수행되었습니다. 초창기 LISP로부터 Prolog,이를 더 확장한 버전까지 개발되어 사용되고 있습니다.

데이터베이스 분야

데이터베이스 분야에서는 의미 데이터 모델(semantic data model) 연구에 의해 객체지향 프로그래밍 언어와 비슷한 데이터 모델링 개념을 추출하여, 이에 대한 확대 개발 연구가 계속 진행 중입니다.

여기서, 우리의 학습 대상인 데이터베이스쪽으로 시선을 돌려보겠습니다.

데이터 모델은 실세계 엔티티와 그들의 제약 조건 및 관계들을 논리적으로 조직하는 것으로, 객체지향 개념을 갖고 있는 데이터 모델을 객체지향 데이터 모델이라고 합니다. 1장에서 언급한 것처럼 관계형 데이터베이스에서 사용된 데이터는 다른 데이터와 관계가 없는 경우 무의미한(정보가 없는) 자료가 됩니다. 하지만 객체는 객체 자체가 하나의 정보단위로 의미를 가지고 있습니다.(위에서 언급한 의미 데이터 모델이란 말이 이를 나타내고 있습니다!)

객체지향 데이터베이스는 객체들의 집합이며, 객체지향 데이터 모델에 따라 객체들의 동작 및 상태와 관계를 정의하고 있습니다. 객체지향 데이터베이스 시스템(OODBMS)은 객체지향 데이터베이스를 정의하고 조작할 수 있는 데이터베이스 시스템인 것입니다.



   


객체지향 데이터베이스(OODB : Object-oriented Database)에 대해서 아직까지 정확한 개념이 정립되지 못했는데, 그 원인은 다음과 같습니다.

첫째 , 객체지향 데이터 모델에 대한 표준이 없다는 것입니다.

객체지향 데이터 모델의 표준이 명확하게 정의되지 못한 원인은 객체지향 프로그래밍 언어의 표준이 명확하게 정의되지 못한 데서 찾을 수 있습니다. 즉, 꼬리에 꼬리를 무는 결과를 가져왔다는 얘기가 됩니다.

좀더 자세히 살펴보면, 프로그래밍 언어 분야에서나 데이터베이스 분야에서 객체지향 개념을 위한 의미의 단일 표준에 동의하지 않고 있는 실정입니다. 그렇기 때문에 상업적으로 성공한 몇 개의 프로그래밍 언어, 예를 들어 LISP나 C++에 의해 객체지향 개념의 표준이 흔들리고 있다는 것입니다. 이렇게 객체지향 프로그래밍 언어가 힘의 논리에 지배되기 때문에 데이터베이스 시스템도 표준이 명확하게 마련되지 않고, 그 결과 OODBMS 시장이 혼란한 상황에 부딪혀 있습니다.

둘째 , 비객체지향 데이터베이스 내에 미미하나마 기본적인 객체지향 개념이
    존재한다는 이유에서입니다.

CAD(Computer Aided Design), CASE(Computer Aided Software Engineering) 등도 데이터베이스화 할 수 있습니다. 또한 혼합문서의 경우도 데이터베이스화 할 수 있습니다. 하지만 이런 종류의 응용 프로그램에 관계 데이터베이스 기술을 적용하기에는 많은 제한이 있습니다. 혼합문서의 경우 단순 텍스트뿐 아니라 그림, 음성 등의 데이터도 저장할 수 있기 때문에 이런 데이터는 관계 데이터 모델에서는 구현하기가 어렵기 때문입니다. 그렇다고 객체지향 데이터베이스 기술을 적용하기도 어렵습니다. OODB의 경우 관계 데이터 모델을 사용하기 어렵기 때문에, CAD나 CASE의 경우 설계 객체의 모든 관계나 혼합 문서 내의 모든 요소들간의 관계를 모델링하기에는 불충분합니다.

또한 관계형 데이터베이스이지만 객체지향 개념을 갖도록 관계형 모델, 언어를 확장하려는 노력이 이미 존재했습니다. 그 결과 POSTGRES라는 무료 DBMS의 경우 RDBMS이지만 여기에 객체지향 개념을 많이 내포하고 있습니다.

객체지향 데이터베이스는 앞서 언급한 바와 같이 표준화가 아직 완성되지 않았고, 사용상의 문제점을 안고 있으므로 아직 적극적으로 사용하기에는 무리가 있다고 할 수 있습니다. 그러나 향후에는 객체지향 데이터베이스가 시장 전반을 점유하게 될 것으로 예상되고 있습니다.


객체 캡슐화에 의한 모듈화 정보 은닉의 장점이 있습니다.
객체들 간의 정보 전달은 메시지를 통해서 이루어집니다.

인스턴스는 객체가 실제적으로 구현된 상태입니다.

클래스는 객체들의 공통 변수들과 메소드들을 정의한 객체의 설계도라고 할 수 있습니다.

클래스의 사용으로 발생되는 장점은 재사용할 수 있다는 점입니다.

클래스는 슈퍼클래스의 속성이나 메소드들을 상속 받을 수 있습니다.

객체지향 모델링은 객체와 객체 식별자, 속성과 메소드, 캡슐화와 메시지,
클래스, 상속 등에 대한 개념을 필요로 합니다.

신고
document.write("");
Posted by 사우람


티스토리 툴바