|
1. Client/Server Architecture
이러한 C/S 구조는 시스템의 구성요소가 어떻게 구성되는가에 따라서 2계층 C/S 시스템과 다계층 C/S 시스템으로 나눌 수 있습니다. 얘기가 좀 어려운데요. 아래의 그림으로 설명을 드리겠습니다. 아래의 그림에서 보시는 바와 같이 서버로 접근하는 방법은 그림보다 더 많이 있을 것입니다. Client Computer A와 Server 간의 관계를 보겠습니다. 이것이 전통적인 Client/Server Architecture의 모습입니다. 이를 Client와 Server의 두 계층으로 나누어서 볼 수 있다고 해서, 2계층(2-Tier) C/S System이라고 합니다. 그럼 계층이 3개이면 3-tier C/S System이냐구요? 예.. 눈치가 빠르시군여. 맞습니다. 이렇게 System을 구성하는 구성요소들이 (물리적으로든지 논리적으로든지) 여러 계층으로 나누어져 있는 경우에는 다중계층(Multi-tier, n-tier) C/S System이라고 합니다. 이렇게 구성요소 들을 나누는 이유가 뭘까요? 뭔가 장점이 있으니까 복잡하게 나누는 것이겠죠. 전통적인 (2-tier) C/S System이 개발되고 실제 기업에서 사용하다 보니 시스템을 운용하는데 있어서 문제점이 발생되기 시작하였습니다. 사용자의 요구에 의해서 이런 기능, 저런 기능을 포함하다 보니, 사용자들 사이의 프로그램마다 서로 다른 버전을 가지고 있어 서로 다른 업무규칙이 적용되는 경우가 빈번히 발생되었고, 사용자의 컴퓨터에 있는 프로그램의 크기가 너무 커져버려서(Fat Client) 결국은 프로그램의 실행속도가 너무 느리게 되는 단점이 발생되었습니다. 이를 해결하기 위해서 아래의 그림에서 보는 것처럼 Middle Ware개념을 도입하기 시작하였습니다. 업무를 처리하는 대부분의 기능을 Middle Ware Server에 두고 사용자의 컴퓨터에는 사용자에게 보여주는 화면에 대한 처리만을 저장하도록 하여, 업무에 대한 변경이나 사용자의 변경요구가 있을 경우에는 Middle Ware의 업무처리 루틴(Business Logic, 업무규칙 이라고 합니다.)만을 변경하여, 동시에 모든 사용자에게 동일한 업무규칙을 적용할 수 있게 하고, 사용자의 컴퓨터는 더 이상의 변경이 필요 없게 하였습니다.(Thin Client) 이외에도 다중계층 System에 대한 장점은 더 있습니다. 이러한 데이터의 제공요구와 그에 대한 응답으로 데이터의 제공을 하는 시스템의 구조를 C/S System이라고 합니다. Client/Server Architecture
2. Database Architecture 처음 데이터베이스를 접했을 때에는 데이터베이스는 어떻게 저장이 될까 하는 의문을 가졌던 기억이 있습니다. HWP나 DOC는 파일처럼 저장이 되는데, 데이터베이스는 그런 것도 아니구. 아무튼 정말 궁금했습니다. 이 자리에서 자료구조에 대한 설명부터 드릴 수는 없구요. 간단하게 SQL Server가 Client에게 데이터를 보여줄 때, 어떠한 형식으로 저장된 데이터를 어떻게 보여주는 지를 알아보겠습니다. SQL Server의 Database Architecture는 실질적으로 데이터를 저장하기 위한 물리적인 부분과 데이터를 외부에 보여주기 위한 논리적인 부분으로 나뉘어져 있습니다. 이쯤에서 눈치가 빠르신 분은 데이터베이스의 3단계 구조(Schema)를 떠 올리시는 분이 계실텐데요.. 예. 관련지어 생각해보시죠. SQL Server는 데이터를 사용자에게 보여주기 위해서 데이터들을 논리적인 구성요소로 구성하여 데이터베이스 상에 만들어 놓습니다. 이런 것들에는 차후에 설명하게 될 View, Table, Stored Procedure 등이 있습니다. 이렇게 정의된 논리적인 정의들은 실제 물리적인 파일에 저장되게 되는데, 하나의 파일이 아닌 복수개의 파일의 형식으로 저장됩니다. 이에 대한 자세한 내용은 Database에서 알아보도록 하겠습니다. 3. Server Architecture SQL Server를 구성하고 있는 Server Component는 Client로부터 요청되어진 SQL문장을 받아서 해석하고 적절한 처리를 하여, 결과를 다시 Client로 반환(제공, Serve)하는 역할을 합니다. 즉 Server로 넘어 온 요청에 대한 처리를 반환하는 역할을 담당하고 있는 것이 Server Component의 역할입니다. 이러한 서버 측에서 이루어지는 작업에 대한 행위를 정의하는 것이 Server Architecture입니다. 4. Administration Architecture 사실 Microsoft에서는 MSSQL Server는 "그냥 놔두어도 좋다"라고 할 정도로 데이터베이스 관리에 대한 부분의 자동화에 많은 노력을 기울였다고 할 수 있습니다. SQL Server는 거의 대부분의 관리부분이 GUI(Graphic User Interface)로 구성되어 있고, 간단한 설정만으로 관리를 가능하게 하였습니다. 이는 차후 관리 마법사에 대한 기능에서 자세하게 설명 드리겠습니다. 반복적인 작업은 스케쥴러에 등록하여 반복작업에 대한 수행을 자동화 할 수 있습니다. 또한 이러한 마법사를 통한 설정 및 스케쥴러에 의한 작업의 수행결과를 사용자에게 반환할 수 있는 자동화도 제공하고 있습니다. 자세한 사항은 Administration의 자동화 부분에서 진행하도록 하겠습니다. 5. Replication Architecture 보통 데이터베이스에서의 복제의 개념은 일반 복사의 개념에서 크게 벗어난 것은 아니지만, Architecture 측면에서 볼 때 단순 복사 서비스와는 차원이 틀립니다. 데이터베이스에서의 복제 서비스는 보다 전략적인 측면이 있기 때문에 복제의 목적은 보통 서버 시스템의 하위 시스템으로의 분산, 엔터프라이즈 환경에서의 투명성 등입니다. 때문에 단순한 복사 서비스와는 달리, 모든 데이터베이스의 데이터의 일치성을 위한 특별한 기술이 첨가되어 있습니다. 또한 복제 서비스의 적용 범위가 지역 인트라넷에서부터 전세계적인 인터넷에 이르기까지 다양합니다. 복제에 대한 자세한 사항은 Administration의 복제에 대한 부분에서 자세하게 설명드리겠습니다. 6. Client Architecture - Application Development Architecture 앞서 Client는 Server로 데이터에 대한 요청을 하는 존재라고 설명을 하였습니다. 그렇다면 어떻게 요청을 할까요? Server로 전화를 걸어서 사원에 대한 정보를 달라고 해야만 하는가요? 물론 아니라는 걸 알고 계시죠? Client는 특정 Application을 통해서 Server로 데이터에 대한 요청을 합니다. Application은 Server의 Database로 요청을 전달하기 위해 2가지의 Component를 사용합니다. 우선 Database API에 대해서 말씀 드리겠습니다. Database API는 Application에서 Database로 연결하는 방법과 Database에 명령을 전달하는 방법을 정의해 놓은 것입니다. API Model은 주로 사용되는 언어에 의존하지 않으며, Objects, Property, Interface 등으로 정의 되어 있습니다.
또 다른 하나의 Component는 Database Language 입니다. Database로 보내어지는 명령에 대한 문법을 정의하여 놓은 것이 Database Language입니다. SQL Server에 의해서 지원되는 Database 언어는 Transact-SQL입니다. 차후 Transact-SQL에서 더 자세히 설명이 되겠지만, Transact-SQL은 SQL 92의 표준과 호환성을 지니고 있습니다. 지금까지 SQL Server의 Architecture에 대해서 알아보았습니다. 여기서 살펴본 모든 내용을 알고 계시지 않아도 좋습니다. 다만 C/S Architecture에 대한 개념만은 꼭 파악하고 계시기 바랍니다. 또한 여기서 자세하게 설명되지 않은 부분은 차후 강좌가 진행되면서 더 자세하게 설명될 것입니다. |
