Two-Rabbits

모듈(Module)은 독립된 하나의 소프트웨어 또는 하드웨어 단위를 지칭하는 용어입니다. 

모듈의 가장 큰 특징은 독립성을 가지고 있다는 것 입니다. 독립성이 높을 수록 수정에 있어서 다른 모듈에 영향을 주는게 적어지게 됩니다. 이때 모듈의 독립성을 측정하기 위해서는 결합도와 응집도가 이용하면 됩니다. 결합도는 약하고, 응집도는 높고, 모듈의 크기는 작을 수록 독립성이 높아집니다. 

그 외의 특징으로는 모듈은 독립적이기 때문에 재사용이 가능하며 모듈 내부에 모듈을 하나로 통합하는 조합이 존재할 수 있습니다.  

이런 모듈의 특징을 이용하여 소프트웨어의 성능을 향상시키거나 복잡한 시스템의 수정 또는 재사용, 유지 관리가 편하도록 기능 단위 모듈로 분해하는 설계 구현 기법을 모듈화(Modularity)라고 합니다.

공통모듈은 소프트웨어 개발에 있어 기능을 분할할 수 있고 추상화를 통한 성능향상과 유지보수를 효과적으로 하기 위한 공통 컴포넌트 구현 기법입니다.

공통 모듈의 독립성을 높이기 위해 결합도는 약하고 응집도는 높이는 구현을 권장합니다.

응집도(Cohesion)는 모듈 내부 구성 요소사이의 연관을 나타냅니다. 즉 응집도는 하나의 모듈이 하나의 기능을 수행하는지를 확인합니다.

응집도는 높을 수록 독립성이 높아지게 되며

우연적 응집도 < 논리적 응집도 < 시간적 응집도 < 절차적 응집도 < 통신적 응집도 < 순차적 응집도 < 기능적 응집도 으로 분류됩니다.

즉, 우연적일 수록 응집도가 낮아지며 기능적일 수록 응집도가 높아지며 독립성 또한 높아지게 됩니다.  

결합도(Coupling)는 외부 모듈과의 연관도입니다. 즉 소프트웨어 구조의 모듈 사이의 관련성을 측정하는 척도입니다.

결합도가 낮을수록 모듈의 독립성은 높아지게 됩니다.

내용 결합도 > 공통 결합도 >  외부 결합도 > 제어 결합도 > 스탬프 결합도 > 자료 결합도으로 분류되어 있습니다.

내용 결합도 일수록 독립성이 낮아지며 자료 결합도이면 결합도가 낮아지며 모듈의 독립성이 높아집니다.

MVC

공통 모듈을 구현하기 위해서는 반드시 MVC 패턴을 이해해야 합니다.

- 모델(Model): 모델은 내부 비즈니스 로직을 처리하기 위한 역할입니다. 모델에서는 애플리케이션이 무엇을 할 것인지를 정의하게 됩니다.

- 뷰(View): 뷰는 모델과 컨트롤러가 시각적으로 보려주기 위해 보낸 내용들은 화면을 이용해 보여주는 역할입니다.

- 컨트롤러(Controller): 컨트롤러의 역할은 뷰에 명령을 보내 화면 요청 결과를 전달하게 됩니다. 이 전달 결과를 통해 모델이 어떻게 처리해야 할지 알려주고 있습니다.

팬인(Fan-In)과 팬아웃(Fan-Out)

모듈을 계층적으로 분석해 시스템 복잡도를 측정하기 위해 팬인(Fan-In)과 팬아웃(Fan-Out)이 필요합니다.

시스템 복잡도를 최적화 하기 위해서는 팬인이 높아져야 하고 팬아웃이 낮게 설계해야합니다.

다음의 그림을 가지고 팬인(Fan-In)과 팬아웃(Fan-Out)에 대해 알아봅시다.

팬인(Fan-In)은 모듈을 제어 하는 모듈의 수를 의미합니다.

팬인이 높은 경우 재사용하기에는 설계는 잘되었습니다. 그러나 장애점이 발생할 수 있으며 관리비용과 테스트 비용도 증가하게 됩니다.

각 모듈에 대한 팬인을 모두 정리하면 A=0, B=1, C=1, D=1, E=1, F=2, G=1, J=1, H=2, I=1 입니다.

A는 최상위 모듈이여서 어떠한 모듈에 의해서도 컨트롤 되지 않고 있으므로 팬인은 0이됩니다.

H의 경우 상위 모듈인 E와 F에 의해서 제어당하고 있으므로 팬인은 2가 됩니다.

다음으로 알아볼 내용은 팬아웃(Fan-Out)입니다. 팬아웃은 모듈에 의해 제어 되는 모듈의 수입니다.

팬아웃이 높아질 경우 불필요한 모듈 호출되는지 확인하고 단순화 가능한지를 확인해야 합니다.

각 모듈에 대한 팬아웃을 모두 정리하면 A=3, B=2, C=2, D=1, E=1, F=1, G=1, J=0, H=0, I=0 입니다.  

가장  높은 팬아웃은 B와 C, D 총 3개의 모듈을 제어하고 있는 A가 됩니다.

또한 가장 팬아웃이 낮은 경우는 모듈의 끝단들인 J와 H, I가 됩니다.

개발환경 구성 단계에서 요구사항을 정확히 이해한 후 개발 도구와 서버를 선정하고 선정 된 도구의 사용 편의성과 성능, 라이센스 등을 확인하는 걸 개발환경 구축이라합니다.

개발 환경 구성을 위한 개발 도구는 용도에 따라 크게 4가지로 분류할 수 있습니다.

빌드 도구는 작성 된 코드에 대해서 빌드와 배포를 수행하는 도구입니다. 빌드 도구로는 각 구성요소가 모듈에 대해 의존하는지를 확인하고 관리가 가능합니다.

대표적인 빌드 도구로는 Ant와 Maven, Gradle 등이 있습니다.

구현 도구를 이용하여 개발자는 프로그램의 코드를 작성하고 디버깅, 수정 등 전반적인 코드 구현과 관련된 도구가 여기에 포함됩니다.

구현 도구로는 JAVA 코드 작성시 이용하는 Eclipse와 C와 C++의 코드작성에 이용되는 Visual Studio, 이외에도 IntelliJ, Spring Tool Suite, NetBeans 등이 있습니다.

빌드와 구현 후 필요한 도구는 테스트 도구입니다. 테스트 도구를 통해 구현된 시스템의 전반적인 기능을 검증을 통해 전체적인 품질을 향상시킵니다. 테스트 도구는 테스트 실행 뿐만아니라 테스트 계획, 수행과 분석 등 테스트의 전반적인 내용을 담당하고 있습니다.

대표적인 테스트 도구들은 xUnit, PMD, Findbugs, Cppcheck, Sonar 등이 있습니다. 

마지막으로 필요한 도구는 형상관리 도구입니다. 형상관리 도구는 반드시 프로젝트 진행에 필요한 도구로 개발자들이 작성한 코드 등 산출물에 대한 버전 관리를 도와줍니다.

가장 유명한 형상관리 도구로는 Git과 CSV, Subversion이 있습니다.

서버 하드웨어의 개발환경

이제 서버 하드웨어의 개발환경에 대해서 알아봅시다. 서버 하드웨어 개발환경은 4가지로 웹 서버와, 웹 어플리케이션 서버, 데이터베이스 서버, 파일 서버가 있습니다.

- 웹 서버는 HTTP를 이용한 요청 및 응답을 처리합니다. WEB-WAS-DB 3계층 구조를 가지고 있으며 웹 상의 정적인 콘텐츠인 CSS, Javascript, Image를 처리합니다. 주요 웹 서버는 Apache 웹 서버, IIS 웹 서버, Google Web Server, Nginx가 있습니다.

- 웹 어플리케이션 서버는 정적 콘텐츠를 다루는 웹 서버와 는 달리 동적인 콘텐츠인 Servlet, JSP를 처리합니다. 주요 웹 어플리케이션 서버로는  Tomcat, Weblogic, Jeus, Resin등이 있습니다.

- 데이터베이스 서버는 데이터의 수집과 저장에 사용됩니다. 연계에 사용되는 주요 DBMS는 MySql, Oracle, MS-SQL, DB2 등이 있습니다.

- 파일 서버는 지금까지 설명한 다른 서버와는 달리 파일 저장을 위해 물리 저장장치를 활용한 서버입니다. 대표적인 파일 서버로는 HDD, SSD이 있습니다.

클라이언트 하드웨어 개발환경

서버 하드웨어 개발 환경에 대해서 알았으니 이제 서버 개발환경에서 제공된 서비스를 이용할 때 UI를 제공해주는 클라이언트 하드웨어 개발환경에 대해서 알아봅시다. 

- 클라이언트 프로그램은 프로그램 설치를 통해 사용자와 커뮤니케이션하도록 만들어졌습니다. 클라이언트 프로그램은 Visual Basic, C#, Delphi등으로 개발됩니다.

- 웹 브라우저는 우리가 자주보는 일반적인 웹 사이트입니다. 웹 서비스의 형태로 서버에서 웹 애플리케이션이 응답되면 브라우저를 이용해 사용자와 커뮤니케이션을 하게됩니다.

- 모바일 앱은 모바일 디바이스에 설치되어 작동하고 활용되는 어플리케이션을 말합니다.

- 모바일 웹은 모바일에 최적화되어 제공되는 웹 사이트입니다. 웹 브라우저와 동일한 형태로 만들어져있는 서비스를 모바일 웹브라우저를 통해 제공됩니다.

소프트웨어 개발환경

다음으로 기본적으로 개발을 위해 필요한 소프트웨어 개발환경 구성에 대해서 알아보겠습니다.

소프트웨어 개발환경은 운영체제와 미들웨어, DBMS가 포함되어 있습니다.

-  운영체제는 서버 하드웨어를 사용자가 편리하게 이용하도록 만들어주는 소프트웨어입니다. 운영체제는 프로그램의 성격에 따라 성격이 달라집니다. 운영체제는 우리가 현재 가장 많이 사용하는 도구인 Window와 Linux, Unix등이 있습니다.

- 미들웨어는 컴퓨터와 컴퓨터 사이의 연결에 필요한 소프트웨어입니다. 두 컴퓨터 사이의 연결을 쉽고 안전하게 만들어주고 연결 관리를 도와주는 역할을 합니다. 미들웨어로는 Tomcat, Weblogic, Webspehere, Jeus등이 있습니다.

- DBMS는 사용자와 데이터베이스 사이에 필요한 소프트웨어입니다. DBMS에서는 사용자의 요구에 따라 정보를 생성하고 데이터 베이스 관리를 담당하고있습니다. DBMS로는 Oracle과 MySQL, MS-SQL, PostgreSQL등이 있습니다.

형상관리

소프트웨어 개발의 전체 과정에서 발생되는 모든 변경사항을 관리하는 활동을 형상관리라합니다. 형상관리를 통해 소프트웨어의 생명주기 동안 체계적으로 관리하며 관리에 대한 산출물을 얻을 수 있습니다. 이 단계에서 나온 산출물을 이용하여 소프트웨어의 가시성과 추적성, 무결성 등의 품질 보장이 가능해집니다. 

형상관리 총 4단계로 진행됩니다.

가장먼저 해야할 일은 관리할 대상을 정의하는 형상식별 과정입니다. 

관리할 대상이 정해진 뒤 해야할 일은 형상통제입니다. 형상 통제에서는 베이스 라인을 관리하고 버전 관리를 위해 형상통제 위원회를 운영합니다.

다음은 소프트웨어 베이스 라인의 무결성 평가와 변경시 요구사항과 일치하는지 검토하는 단계인 형상감사입니다. 

여기까지 모든 과정을 끝냈으면 남은건 형상기록 단계입니다. 이 단계를 통해 형상 및 변경관리에 대한 각종 수행결과를 기록하며 보고서를 작성하게됩니다. 

1. 연계 데이터 구성

서로 다른 두 시스템 · 장치 · 소프트웨어를 이어주는 연계 시스템 관련된 요구사항을 분석하는 과정을 연계 요구사항 분석이라 합니다. 

연계 요구사항을 분석하기 위해서는 사용자 인터뷰와 면담을 통해 식별하며 시스템 구성도와 테이블 정의서, 코드 정의서 등의 문서가 분석 참고자료가 됩니다.

연계 요구사항을 분석하기 위한 기법에 대해 자세하게 알아보겠습니다.

- 인터뷰: 인터뷰는 사용자 면담을 통해서 요구사항을 도출하는 기법입니다.

- 체크리스트: 체크리스트는 시스템의 운영 환경과 성능, 보안, 데이터 발생 주기 등을 기준으로 두고 리스트를 체크해서 분석하는 기법입니다.

- 설문지: 설문지는 서비스 활용목적에 따라 나눠진 연계에 필요한 데이터를 식별하고 연계 주기 등을 설문지를 통해 답을 받고 이를 분석하는 기법입니다.

- 델파이 기법: 델파이 기법은 각 분야의 전문가가 가진 경험을 통해 얻은 지식을 이용해 요구사항을 분석하는 기법입니다.

- 브레인 스토밍: 브레인 스토밍은 부담스럽지 않은 분위기에서 토론에서 제시된 아이디어를 이용하여 분석하는 기법입니다.

연계 요구사항을 분석을 위한 참고 자료는 다음과 같습니다.

- 코드 정의서: 코드 정의서는 코드ID, 코드명, 코드설명 등 공통된 코드에 대한 정의서입니다.

- 테이블 정의서: 테이블 정의서는 데이터 모델링 정의서와 테이블과 프로세스의 연관도, 테이블별 컬럼 속성 정의서가 있습니다.

- 응용 프로그램 구성도: 응용 프로그램 구성도는 애플리케이션의 메뉴구성도와 화면설계, 데이터의 발생 시점과 주기, 발생 패턴 등의 내용이 들어가있습니다.

- 시스템 구성도: 시스템 구성도는 하드웨어와 소프트웨어, 네트워크 등의 연계되는 대상에 대한 시스템 구성도입니다.

연계시스템의 구성에 대해서 알아보겠습니다. 연계 시스템은 송신 시스템과 수신 시스템으로 구성 할 수 있고 연계 방식에 따라서 중계 서버를 둘 수도 있습니다.

- 송신 시스템: 송신 시스템은 데이터베이스와 애플리케이션에서 나오는 걸 연계 테이블이나 파일 형태로 생성해서 송신하는 시스템입니다.

- 수신 시스템: 수신 시스템은 수신된 연계 데이터를 수신 시스템이 관리하는 형식에 맞춰 데이터를 변환해 데이터베이스에 저장하거나 애플리케이션에서 활용하도록 하는 시스템입니다.

- 중계 서버: 중계 서버는 송신 시스템과 수신 시스템 사이에서 데이터를 송수신합니다. 또한 송수신되는 연계 데이터를 모니터링 하는 시스템입니다.

2. 연계 메커니즘

응용 소프트웨어와 연계 대상의 모듈 사이의 데이터 연계에서 나온 요구사항을 고려해서 연계방법과 주기를 설계하는 매커니즘을 연계 매커니즘이라합니다.

연계 매커니즘을 통해서 운영 데이터베이스와 애플리케이션에서 연계 데이터를 테이블이나 파일로 생성하여 전송하는걸 송신 시스템이라 합니다. 송신 시스템에서 전송된 데이터를 수신하여 DB에 반영하기 위한 변환처리하는걸 수신 시스템이라 이야기합니다.

연계 방식은 바로 연결되는 방식인 직접 연계 방식과 중간에 중계서버가 있는 간접 연계 방식이 있습니다.

직접 연결되는 직접 연계 방식은 연계 및 통합이 단순하기 때문에 개발에 있어서 소요되는 비용과 기간이 짧다는 장점이 있습니다. 그리고 중계서버가 없기 때문에 연계에 있어서 처리 기능이 좋습니다. 

그러나 직접 연결 방식은 시스템 사이의 결합도가 높아져 시스템이 변경에 민감하고 암 · 복호화 처리가 불가능해 진다는 단점이있습니다.  

직접 연계 방식의 연계기술에 대해 설명하겠습니다.

첫번째 직접 연계 기술은 DB 링크(DB Link)입니다. 데이터베이스에서 제공되는 DB링크라는 객체를 이용하여 송 · 수신하는 방식입니다. 수신 시스템에서는 DB링크를 생성해서 전달하고 송신 시스템은 DB링크를 직접 참조합니다.

두번째 직접 연계 기술은 DB 연결 (DB Connection)입니다. DB연결의 송 · 수신은 DB커넥션 풀을 생성해 이용하게됩니다. 수신 시스템의 WAS에 DB커넥션 풀을 생성하고 생성된 DB커넥션 풀의 이름을 연계 프로그램이 이용합니다.

세번째 기술은 API이자 Open API기술입니다. Open API는 송신 시스템에서 DB의 데이터를 읽어 애플리케이션 프로그램과 인터페이스 프로그램에 제공합니다. 

네번째 직접 연계 기술은 JDBC입니다. JDBC는 자바에서 데이터베이스에 접근하는 시스템으로 JDBC드라이버를 이용하여 송 · 수신 시스템을 연결합니다. JDBC를 자바에 연결하기 위해서는 DBMS유형, DBMS 서버 IP와 Port, DB 인스턴스 정보가 반드시 필요합니다.

마지막 기술은 하이퍼 링크(Hyper Link)입니다. 하이퍼 링크기술은 현재 페이지에서 다른 곳으로 이동하게 만드는 기술입니다. 

간접 연계 방식은 중간에 중계 서버를 이용해 시스템을 연결 시키게 됩니다. 중계 서버가 있어 서로 다른 네트워크나 프로토콜 연계나 통합이 가능하며 인터페이스도 오류없이 자유롭게 변경가능합니다. 

간접 연계 방식의 단점으로는 연계 아키텍쳐가 매우 복잡하게 구성되어 있어 성능이 저하될 수 있습니다. 또한 개발시 드는 비용과 테스트 기간이 직접 연계 방식에 비해 많아집니다.  

간접 연계 방식은 다음과 같습니다.

첫번째로 많이 들어봤던 기술인 EAI입니다. EAI는 연계 솔루션 기술이라 불리며 어댑터를 이용한 연결로 기업에서 운영하는 서로 다른 플랫폼이나 애플리션 간의 정보 교환이 가능하게 합니다. 즉 이를 통해 연계와 통합이 쉬워지게 만드는 기술입니다.

다음 기술은 ESB와 Web Service입니다. 이 기술들은 웹에 대한 설명서인 WSDL과 SOAP 프로토콜을 이용해 시스템 간을 연결한 기술입니다.

마지막 기술은 소켓(Socket)입니다. 소켓을 생성 후 포트를 할당하면 클라이언트에 요청을 할 수 있게 되는데 이때 요청이 수락되면 연결이 되고 통신이 진행됩니다.

3. 연계 모듈 기능 구현

간접 연계 방식에 사용되는 연계 모듈 기능은 EAI방식과 ESB방식, 웹 서비스 방식으로 구분되어있습니다. 연계 모듈 기능은 개발하는 응용 소프트웨어와 연계 모듈간의 세부 설계서를 일관되게하고 정형화되도록 연계 기능을 구현해야 합니다.

EAI (Enterprise Application Integration)는 기업에서 운영되고 있는 서로 다른 플랫폼 간의 정보 전달이 가능하게 만들어줍니다. 또한 연계 통합을 가능하게 만들어주는 솔루션이기도 합니다. EAI 연계 모듈의 장점은 통합과 연계성을 높여서 각 시스템간의 확장성이 넓어지고 효율성도 좋아집니다.

ESB (Enterprise Service Bus)는 기업에서 운영는 서로 다른 플랫폼을 하나의 시스템으로 관리하고 운영하도록 만들어주는 통합 아키텍쳐 기술입니다. 버스를 중심으로 각 프로토콜이 호환되도록 애플리케이션은 느슨한 결합방식으로 지원되고 있습니다.

웹 서비스 (Web Service)는 네트워크 상에 분산되어있는 정보를 서비스 형식으로 개방합니다. 그 후 개방된 정보를 표준화 하여 공유하는 기술으입니다.

웹 서비스 방식으로는 SOAP와 WSDL, UDDI가 있습니다.

- SOAP(Simple Object Access Protocol)는 HTTP, HTTPS, SMTP 등을 사용하여 XML기반 메세지들을 네트워크 상태에서 교환하는 프로토콜입니다.

- WSDL(Web Service Description Language)는 웹 서비스 명과 제공 위치, 프로토콜 정보 등 웹 서비스에 대한 상세한 정보를 기술하여 XML형식의 파일로 구현 후 공유하는 기술입니다.

- UDDI(Universal Description Discovery and Integration)는 웹 서비스에 대한 정보인 WSDL을 등록하고 검색하기 위한 저장소입니다. 또한 UDDI는 공개적으로 접근할 수 있고 검색이 가능한 레지스트리입니다.

1. 물리 데이터 모델링 

논리모델을(ER Model) 적용하기 위해서 적용 대상에 기술을 맞추고 상세화 하는 과정을 물리 데이터 모델링(Physical Model)이라 합니다.

물리 데이터 모델링으로 변환하는 절차는 다음과 같습니다.

개체(Entity)를 테이블(Table)로 변환 합니다. 또한 속성(Attribute)을 컬럼(Column)으로 변환하고 UID(User ID: 사용자 식별자)를 기본키(Primary Key)로 변환합니다. 그 후 관계(Relationship)를 외래키(Foreign Key)로 변환하면 논리 모델이 가지고 있던 모든 특징을 물리 데이터 모델링 형식으로 표현하게 됩니다.

여기에서 끝나는게 아니라 물리 데이터 모델링을 하기 위해서는 추가적으로 해야할 일이 있습니다. 먼저 속성이 변환된 컬럼(Column)에 대한 길이와 타입을 정의 합니다. 그리고 마지막으로 물리 데이터 모델링에서 제일 중요한 반 정규화가 수행되어야 합니다.

반 정규화는 정규화 된 엔티티와 속성, 관계에 대해서 성능을 향상시키고 개발 운영을 단순화하기 위해 중복통합과 분리 등을 수행하는 데이터 모델링 기법입니다. 즉, 정규화과정에서는 중복을 제거하고 합치는 행위를 통해 엔티티의 이상현상을 줄이지만 반 정규화는 그와 반대의 행위를 함으로 정규화 과정이 가져온 성능 저하를 개선하는 효과를 가져옵니다.

2. 참조무결성 제약조건 (Constraint) 

물리데이터 저장소를 구성하기 위해서는 DBMS 선정이 필요합니다. 이때 테이블에 거는 제약조건이 바로 참조무결성 제약조건입니다. 

릴레이션과 그 사이의 일관성을 위해 약속한 조건들을 참조 무결성 제약조건이라 말합니다. 두 릴레이션 A, B가 기본키와 외래키를 통해 참조 관계를 형성하고 있습니다. 이 경우 B의 외래키의 값은 참조되고 있는 릴레이션 A의 기본키로 있어야 합니다. 

다음과 같이 참조무결성을 지키기 위한 여러 방법들이 있습니다.

첫번째 방법은 제한(Restricted)입니다. 제한의 경우 참조무결성 원칙을 위배하는 연산을 거절하게 됩니다. 

두 릴레이션 A, B가 있으면 릴레이션 A가 릴레이션 B를 참조하고 있으면 현재 참조되고 있는 릴레이션 B의 튜플을 삭제하지 못하게 제한 합니다. 이처럼 참조 무결성 제약조건에 따라 삭제 연산을 거절하게 됩니다.

두번째 방법은 연쇄(Cascade)입니다. 연쇄의 경우는 참조무결성 원칙을 지키기 위해 연관성있는 튜플이 같이 희생됩니다. 위의 예시와 마찬가지로 두 릴레이션 A, B가 있고 릴레이션 A가 릴레이션 B를 참조하고 있다고 가정해봅시다. 연쇄의 경우 릴레이션 A가 참조하고 있는 릴레이션 B의 튜플에 삭제 연산을 주면 릴레이션 A에도 영향을 미쳐 참조되던 튜플도 삭제시킵니다. 이처럼 두 릴레이션을 건드려 참조 무결성을 지키는 것을 연쇄라고 합니다.

마지막 방법은 널 값(Nullify)입니다. 개인적으로 세 방법 중 가장 쉬운 방법으로 Null을 이용하여 참조 무결성을 지키는 방법입니다. 마지막 예시입니다. 두 릴레이션 A, B가 위와 같은 형태로 참조 중이고 삭제 연산이 일어나게 된다면 릴레이션 A가 가지고 있던 외래키에 Null을 넣어 참조 무결성을 지키게 됩니다.

세 방법을 한줄로 요약하자면 제한은 연산을 거절하고 연쇄는 두개가 다 영향을 미칩니다. 마지막으로 널 값은 Null을 이용해 참조가 없는 것으로 변경합니다. 각 특징을 이해하고 구분하셔야 합니다. 

3. 인덱스(Index)

인덱스는 저장공간에 영향을 끼치기 때문에 물리데이터 저장소를 구성할때 고려하셔야합니다.

데이터베이스 내부의 열에 대한 정보를 구성해 검색연산을 최적화하는 데이터 구조를 인덱스라합니다. 인덱스를 이용하면 불필요한 전체 데이터 검색이 아닌 필요한 정보에 대해서 빠른 접근이 가능해집니다.

데이터는 테이블에 평균적으로 분포되어 있어야합니다. 이를 확인하기 위해 분포도를 확인해야 하는데 이 분포도가 10~15% 사이여야 적절한 인덱스라 부릅니다. 즉 우리는 분포도를 통해 적절한 인덱스를 판별 가능합니다.

이 분포도가 적정한지 구하는식은 다음과 같습니다.

- 분포도 = (1 / (컬럼 값의 종류)) * 100

- 분포도 = (컬럼 값의 평균 Row 수) / (테이블의 총 Row 수) * 100

분포도가 범위 이상인 경우 전체처리가 아닌 부분처리 목적으로 이용하기 위해 인덱스에 적용하거나, 조회와 출력으로 사용되는 경우, 인덱스에서 자동생성된 기본기나 Unique Key의 제약조건을 사용할 경우 등에 인덱스에 적용할 수 있습니다.

결국 분포도는 인덱스 판별에 중요한 역할을 하지만 위와 같은 예외의 경우도 존재하므로 언제나 분포도를 따른다는 말은 맞지 않습니다. 

인덱스의 컬럼 선정시 가장 먼저 확인 해야할 사항은 수정 횟수와 위에서 설명한 분포도입니다. 수정이 드물거나 분포도가 좋으면 컬럼을 단독으로 생성합니다. 또한 자주 조합되는 컬럼이 생기면 이를 결합 인덱스로 만들게됩니다. 결합 인덱스가 되면 사용빈도와 유일성, 정렬등 컬럼 순서 선정에 특히 유의하셔야합니다. 

인덱스 설계시 지나치게 많은 인덱스가 생길 경우 오버헤드(Overhead)로 작용될 수 있음을 유의하셔야합니다. 범위가 넓은 인덱스를 처리할 경우에도 오버헤드가 발생할 수 있습니다. 또한 인덱스 설계시 인덱스가 추가적인 저장공간이 필요하다는걸 반드시 이해하시고 설계를 진행하셔야합니다. 마지막으로 고려해야할 점은 인덱스가 테이블의 저장공간과 분리되어 있도록 설계하면 됩니다.

이런 유의 사항들만 지키면 인덱스는 검색연산을 수행할 때 빠른 조회가 가능하게됩니다.

3. 뷰(View) 

뷰는 사용자에게 기존 테이블에서 제한 된 자료를 보여주기 위해 유도된 가상 테이블입니다. 가상 테이블이므로 물리적으로 존재하지 않지만 Join사용을 최소화해 편의성이 늘어나는 특징이 있습니다.

뷰에서 주로 사용하는 속성은 다음과 같습니다.

뷰가 이미 존재하는 경우 재생성 하는 REPLACE와 테이블의 존재여부를 따지지 않고 무조건 뷰를 생성하는 FORCE. 마지막으로 기존의 테이블이 반드시 존재해야지만 뷰를 생성하는 NOFORCE로 나눠져 있습니다.

뷰를 설계할때에는 반드시 최적의 액세스 경로를 사용해야하며 잘못 수행할 경우 수행속도가 문제가 발생할 수 있으므로 이점을 유의하시면서 설계하시면 됩니다.

4. 클러스터 (Cluster)

인덱스는 대부분 분포도가 10~15%라는 적정범위안에 드는걸 선호합니다. 하지만 클러스터의 경우는 분포도가 넓은 경우를 선호하는 설계기법입니다.

분포도가 넓은 테이블을 클러스터로 만들게 되면 생기는 장점은 저장공간이 절약되며 대량의 범위 액세스에 유리해집니다. 또한 인덱스가 가진 검색속도의 향상도 가져옵니다.

그러나 완벽해보이는 클러스터도 유의해야할점이 존재합니다. 입력하거나 수정, 삭제시에 부하가 증가하게 되며 UNION과 DISTINCT, ORDER BY, GROUP BY가 빈번한 컬럼이면 검토대상이됩니다. 또한 수정이 자주 발생하지 않더라도 검토대상에 들어가게 됩니다.

5. 파티션 (Partition)

마지막기법은 파티션닝입니다. 파티셔닝을 통해 데이터 베이스를 분산 처리하여 성능 저하를 방지하고 관리를 수월하게 할 수 있습니다. 

파티션은 레인지 파티셔닝, 해시 파티셔닝, 리스트 파티셔닝, 컴포지트 파티셔닝으로 나눠집니다.

가장 먼저 레인지 파티셔닝(Range Partitioning)에 대해 이야기 해보겠습니다. 레인지 파티셔닝은 연속되는 숫자나 날짜를 기준으로 나누는 파티션 기법입니다. 장점으로는 관리가 쉬워 관리 시간을 단축시킬수 있습니다.

두번째는 해시 파티셔닝(Hash Partitioning)입니다. 해시 파티셔닝은 해시 함수 값을 파티션 키로 두는 파티션 기법입니다. 해시 파티셔닝은 균등하게 나눌수 있으며 질의 성능도 향상시킬 수 있다는 장점이 있습니다.

다음은 리스트 파티셔닝(List Partitioning)입니다. 리스트 파티셔닝은 파티션에 저장 될 데이터에 대해 명시적으로 제어 가능한 파티셔닝 기법입니다. 리스트 파티셔닝은 분포도가 대략적으로 비슷하며 많은 데이터나 컬럼 조건이 많을 경우에 좋은 성능을 보여줍니다.

마지막은 컴포지트 파티셔닝(Composite Partitioning)입니다. 컴포지트 파티셔닝은 범위로 분할 후 해시 함수를 적용시켜 재분할하는 파티션 기법입니다. 컴포지트 파티셔닝은 큰 파티션을 여러 파티션으로 분산 할 수 있다는 장점이있습니다.

파티션을 이용하면 데이터의 액세스 범위가 줄어 성능이 향상되고 데이터의 훼손 가능성이 낮아져 가용성이 향상됩니다. 또한 분할 된 영역이 각자 백업과 복구가 가능하고 디스트 컨트롤러에 대한 경합이 현저히 감소하게 되는 장점이 있습니다.

6. 디스크(Disk)

디스크는 정확한 용량만 사용해 디스크 사용효율을 높이고 입출력에 대한 경합이 최소화하여 데이터의 접근 성능을 향상시키게 됩니다.