믹스드코드랩:{나도개발자시리즈1}: 모델 & 데이터 모델링 & 데이터 베이스

4일차
4.1 모델 & 데이터 모델링 & 데이터 베이스
4.2 Microsoft SQL Server 기초
4.3 Entity Framework(EF) ORM 사용법
4.4 EF 기반 ASP.NET MVC DB Programming

정보관리시스템의 일반적인 개발방법론을 통해 모델링 과정과 개발과정을 이해하고 모델링과정을 통해 모델의 도출과정 과 모델의 종류 및 용도에 대해서 알아보겠습니다.

4.1.1 모델 과 모델링
MVC 패턴 및 MVC 기반 개발에서의 Model을 이해하기 위해서는 모델이 도출되는 과정을 이해할 필요가 있습니다.
모델이 도출되는 과정을 이해 함으로서 모델이 무엇이고 모델의 용도 및 유형이 어떤 것들이 존재하는지 알아가 보도록 하겠습니다.
모델은 간략히 말하면 모형 또는 형태를 말하며 현실 세계에 실재(실제 존재)하는 현상들을 모형화 하거나 그 형태를 나타낸 것을 말합니다.

모델을 도출하고 구체화하는 전체 과정을 모델링이라고 합니다.
모델링은 말 그대로 모형을 만드는 일 또는 그 과정을 말하며 실체를 만들기 위해 그와 관련한 실제 존재하는 현상들을 다양한 형태로 나타내는 모델화 과정을 통해 그 현상을 분석하고 구체적으로 설계하는 기법 및 과정을 말합니다.

모델링이 모델을 도출하고 분석하고 설계하는 과정이라면 개발은 모델을 이용해 실체를 구현 또는 만드는 과정이라고 합니다.

모델링을 쉽게 이해할 수 좋은 예로 아파트의 모델하우스를 예를 들 수 있습니다.
모델하우스는 아파트나 건물이라는 실체를 만들기 전 건물을 구성하는 실재하는 방,거실,인테리어등 을 다양한 모형으로 미리 만들어 실제 건물을 만들기 전에 볼 수 있게 전시해놓은 것을 말하는 것처럼 실체를 구현 하기 전 그 구성요소들의 형태를 구체화 하여 구현 시 문제점을 사전에 차단하고 관련 주체들의 이해를 돕게 하기위해 사용됩니다.

TIP)데이터 와 정보?
데이터란 실재하는 현상을 구성하는 모든 것을 말합니다.
정보란 실재하는 현상을 구성하는 모든 데이터 중에 정해진 목적에 부합하는 의미 있는 데이터를 말합니다.

노트북이란 실체가 있습니다.
노트북 관련 데이터로 는 브랜드 데이터,제조회사 데이터,판매자 데이터,소유자 데이터,하드웨어스펙 데이터등 다양 하지만 프로그램 개발에 적합한 노트북이란 목적에 부합한 정보로는 메모리 4G이상, CPU-i이상,해상도1600dpi이상 등 하드웨어 스펙 이 의미를 가지는 정보이며
브랜드,재질,판매자 데이터들은 정보로서의 의미가 없습니다.

Tip)DataStore & DBMS & RDBMS
데이터저장소(DataStore)란 세상에는 데이터를 저장하기 위한 다양한 데이터 저장소가 존재하며 작게는 의미 있는 메모를 적은 종이 한 장에서부터 워드문서,엑셀문서와 같이 문서형태의 데이터 저장소도 있고 크게는 ORACLE과 MSSQL 같이 전문적인 데이터 저장관리 수단인 데이터 베이스도 데이터 저장소의 하나의 종류입니다.

DBMS(Database Management System)는 각종 정보관리시스템 및 다양한 주체 및 수단에 의해 발생된 의미 있는 데이터를 자료항목의 중복을 없애고 자료를 구조화하여 저장함으로써 자료 검색과 갱신의 효율을 높여 영속(영구.지속)적으로 저장 관리해주는 시스템을 통칭해 말합니다. 보통 데이터 베이스라고 합니다.

RDBMS(Relationship Database Management System)는 DBMS 중 실제 데이터를 보관하는 주체인 테이블간의 관계를 기반으로 데이터를 효과적으로 관리해주는 DBMS를 관계 형 데이터 베이스 시스템이라고 합니다.
EX) Oracle ,MSSQL ,MYSQL.....

4.1.2 정보관리시스템 개발방법론
정보관리시스템은 특정 행위 또는 비즈니스 에 목적을 두고 비즈니스 에 존재하는 현상을 구성하는 데이터 중에 의미 있는 데이터인 정보를 추출하여 체계적으로 관리해주는 방법 및 수단을 통칭합니다.
현대의 정보관리시스템은 각종 비즈니스 돕기 위한 목적으로 해당 비즈니스 에서 발생하는 현상중에 의미 있는 정보를 체계적으로 관리해주는 방법 및 그 수단을 제공합니다.
일반적으로는 적정 이상 규모의 정보를 체계적인 방식으로 관리해주는 모든 시스템은 정보관리시스템이라 말할 수 있습니다.

아래절차는 일반적인 데이터 및 비즈니스 중심의 대표적인 정보통신 서비스 분야인 시스템 통합 서비스 분야의 정보관리시스템 개발절차를 보여줍니다.

[그림4-1] 정보관리시스템 개발방법론 절차

1)요구사항정의 단계
사용자의 요구사항을 접수하고 이해하고 정리합니다.
요구사항 중 기능적 요구사항과 비 기능적 요구사항을 구분하고 정의합니다.
관련 주체와 비즈니스 내용 및 비즈니스 의 프로세스를 정확히 파악 기록합니다.

2)분석단계
요구사항정의단계에서 파악된 비즈니스(도메인),기능 적 요구사항,관련주체,프로세스를 분석하여
해당 비즈니스의 실체(Entity)를 파악하고 실체의 특성(Attribute) 과 기능,실체 간의 관계인 개념모델을 분석 클래스로 도출합니다.
도출된 각종 실체의 특성 중(Attribute) 의미 있는 정보는 영구적으로 보관할 필요가 있는 경우 데이터 모델링 과정을 통해 데이터 논리모델로 추출합니다.
소프트웨어 아키텍처 개념을 이용 시스템의 기본적인 구조를 정의하고 수립합니다.
분석단계까지는 특정 개발언어/개발플랫폼과 같이 구현방법 및 환경에 구애 받지 않고 비즈니스 관점,모델링 관점, 아키텍처 관점 에서 비즈니스의 분석작업이나 시스템의 기초 구조를 정의합니다.

3)설계단계
설계단계는 분석단계에서 도출된 각종 실체(Entity)의 특성과 기능, 관계 등을 특정 개발 언어와 플랫폼에 맞는 용어와 기술 아키텍처를 통해 클래스 와 컴포넌트 등으로 구체적으로 표현하고 사용 기술환경에 맞게 어플리케이션 아키텍처를 설계합니다.
데이터 논리모델을 실제 사용할 RDBMS(ORACLE,MSSQL,MYSQL)에 맞게 데이터물리모델을 설계합니다.

4)개발단계
특정 개발언어와 개발플랫폼,개발도구,기술환경을 통해 모델링 과정에서 도출된 결과물인 설계 산출물을 이용 시스템을 개발 구현합니다.

5)테스트단계
단위/통합 테스트과정을 통해 문제를 해결합니다.

6)배포단계
-개발산출물을 배포합니다.

7)운영 및 유지보수 단계
시스템의 운영 및 지속 적인 시스템의 유지보수작업을 진행합니다.

위 단계 중 요구사항정의 단계, 분석단계, 설계단계를 모델링 과정이라 말하며 모델링 과정 산출물을 통해 개발이 이루어지며 이후 단계를 거쳐 하나의 정보관리 시스템이 개발 되어지고 유지되어집니다.
개발단계에서 코드중심의 구현을 위한 구체적인 방법인 개발언어(C#,Java) 및 개발툴(VisualStudio,Eclipse)을 사용하는 것 처럼 모델링 단계 또한 UML 이라는 국제 표준 모델링 언어와 각종 모델링 툴(RationalRose,Together,StarUML,Visio,Erwin)을 통해 그 과정이 진행됩니다.

상기 개발절차는 다양한 S/W개발방법론 중에 객체지향 컴포넌트 기반 개발방법론(Component Based Development)을 근간으로 설명 드렸으며 중 대형 SI 프로젝트는 위와 같은 개발 방법론을 정해놓고 시스템의 구축 절차와 방법 및 산출물 등 을 관리 함으로서 프로젝트의 시행착오와 위험을 줄이는 노력을 합니다.

TIP) 애자일(Agile) 기법 또는 개발방법론
S/W의 개발방법론은 상당히 다양한 종류가 있지만 프로젝트의 리스크 감소 및 현실적 문제에 대한 적극적인 대응을 위해 새로운 방법론들이 등장합니다.
대표적인 것이 요즘 유행하는 애자일 기법 또는 개발방법론입니다.
전통적인 개발방법론이 위에서 설명 드린 것 처럼 시스템 구축과정을 단계별로 정해두고 해당 단계가 끝나야 다음단계로 진행되는
순차적인 방법(WaterFall방식=순차진행형)을 사용했다면
애자일 기법 또는 방법론은 리스크가 있거나 중요도가 큰 요구사항위주로 요구사항접수,개발 과 테스트 과정을 하나의 스크럼(평균한달)으로 구성하고 각각의 스크럼을 90%이상 문제가 없을 때까지 스프린트 작업을 반복(요구사항변경-개발-테스트)하여 리스크 를 최소화합니다.
특징은 분석/설계과정을 최소화하고 요구사항관리 및 개발 및 테스트를 점진/반복적으로
진행 함으로서 요구사항의 변화에 대한 즉각적인 대응 및 개발 및 테스트중심으로 프로젝트를
진행하여 시스템의 문제를 조기에 해결하는 기법이자 개발방법론입니다.

4.1.3 데이터 모델링
데이터 모델링은 모델링 전 과정(요구사항정의/분석/설계)중 특히 분석/설계단계에서 데이터 관점에서 진행되는 모델링 기법으로 일반적으로 개념모델 정의단계,논리모델 정의단계,물리모델 정의단계등의 과정을 통해 모델링이 이루어집니다.
이번 데이터 모델링 장에서는 향후 DB 프로그래밍 실습에서 사용할 회원정보와 게시 글 정보관리를 위한 데이터 모델링 작업을 직접 동시에 진행해보도록 하겠습니다.

1)데이터 모델링
A)개념모델 정의
분석단계를 통해 도출된 비즈니스의 실체들(Domain Entity)을 말하며 실체의 특성(Attribute)을 비즈니스 관점에서 도출하고 실체와 실체간 관계를 정의하는 일입니다.

[그림4-2] 웹사이트 게시글 관련 개념모델

상기 개념모델은 회원제 기반 게시글 관리 웹사이트를 구성하는 게시글 관련 도출된 개념모델 엔티티들을 나타내며 고객 엔티티는 최소 1명이상은 존재해야하며 고객들은 게시글을 입력하지 않을수 있거나 1개이상 입력할수 있는 있다는 엔티티간 관계(Entity Relation Diagram = ERD) 다이어그램 으로 표현하였습니다.
개념모델링 작업은 비즈니스 관점에서의 해당 비즈니스를 구성하는 주요 엔티티를 도출하고 해당 엔티티를 구성하는 특성(Attribute=속성=Property=Field=Column)을 도출한 후 엔티티간 관계를 설정합니다.

B)논리모델 정의
논리모델링 작업은 비즈니스 관점이 아닌 비즈니스 및 관리에 필요한 모든 데이터 관점에서 모델링이 진행되어야하기 때문에 사용자IP주소나 ViewCount같은 사용자와 관련 없는 시스템 관리 관점에서 필요한 데이터 속성들까지도 모델링에 반영해야합니다.
논리모델링 작업은 개념모델정의 에서 파악 된 실체들의 세부 특성을 데이터 관점에서 파악하여 데이터 정규화란 과정을 통해 진행합니다.

정규화 과정이란 관계 형 데이터베이스(RDBMS)에서 데이터의 보존 성 을 높이고, 중복성은 줄여 저장공간의 최소화를 꾀하고 조회속도 등을 향상 시키기 위한 테이블을 구성하는 일련의 과정을 말합니다.
정규화는 1 ~ 5 단계의 정규화 과정과 반 정규화 과정이 있으며 보통 특수하고 복잡한 자료구조가 아니라면 3정규화 과정까지 진행하면 정규화 모델링이 완료됩니다.
정규화 과정을 통해 도출된 엔티티의 속성들의 기본 데이터 유형들을 지정합니다.
기본적인 속성들의 데이터 유형에는 문자형,숫자형,날짜형등이 있습니다.
논리모델 단계에서는 실제 사용할 DBMS 시스템 유형은 고려하지 않습니다.

제1정규화 : 속성 원자 값 원칙 및 중복성 제거 원칙 및 PK설정 원칙을 준수합니다.
모든 엔티티는 유일키(Uniqu Key)이자 데이터간 구분자 값인 PK(기본키=Primary Key) 가 존재 해야합니다.
모든 속성 값은 원자성,즉 단일값형태로 데이터 형태가 표현 되어야 한다.
모든 속성 값은 중복 되어서는 안됩니다.
값이 중복되는 2개이상 속성들은 별도의 엔티티로 분리해야합니다.

[그림4-3] 제 1정규화 예시

하나의 게시글이 두개의 분류를 가진다면 Case1의 분류코드와 분류설명 속성정보는 단일속성 단일값 원칙인 원자값 규치에 위배됩니다.
Case2의 경우 Case1의 문제는 해결되었지만 다중속성의 값이 중복되어 나타나 중복성 원칙에 위배되어 중복되는 속성들을 별도의 게시글 엔티티 와 분류코드정보 엔티티로 분리하였습니다.

제2정규화: 부분적 함수의 종속성 속성 제거원칙을 준수합니다.
기본키가 2개 이상으로 구성된 엔티티에서 일반속성이 PK속성들중 일부 속성에 대해서만 부분적 종속성이 있는 속성일 경우 해당 속성을 제거합니다.

[그림4-4] 제2정규화 예시

게시글 분류정보 엔티티에서 분류설명 속성은 PK인 글번호 및 분류코드 모두에 대해서 종속성이 있지 않고 분류코드에만 부분적 종속성이 있으므로 별도 테이블로 분리합니다.
PK(기본키)가 1개인 엔티티는 제 2정규화 대상에서 제외됩니다.

제3정규화: 이행적 함수의 종속성 제거원칙을 준수합니다.
기본적으로 엔티티내 모든 속성들은 기본키에 의존성을 가져야합니다.
기본키에 의존하지 않고 일반속성에 의존하는 속성을 제거 또는 분리합니다.
메일주소는 글번호에 의존하지 않고 고객아이디에 의존하기 떄문에 분리합니다.

[그림4-5] 제3정규화 예시

반정규화: 진행 된 정규화 과정을 무시하고 특수 목적에 의해 의도적으로 정규화 과정을 되돌리는 정규화를 말합니다.

아래는 회원제 기반 게시글 관리 시스템을 위한 데이터 모델링 과정 중 논리모델 단계에서 데이터 정규화 기법을 통해 도출된 최종 논리 ERD(Entity Relation Diagram) 입니다.

[그림4-6] 게시글 관련 논리 ERD 모델

C)물리모델 정의
-물리모델링은 데이터를 실제 영구적으로 저장하고 관리하는 ORACLE,MSSQL,MYSQL 등과 같은 RDBMS 환경에 맞게 명칭 및 데이터 타입을 논리모델링 산출물을 기반으로 지정합니다.
사용하는 RDBMS 에따라 다소 데이터를 관리하는 방법 및 데이터 타입 명칭등이 다소 상이하기 때문에 여러분이 사용할 실제 RDBMS 환경에 최적화된 물리적 테이블명 과 컬럼명 그리고 데이터 타입등을 정확히 지정합니다.

[그림4-7] 게시글 관련 물리 ERD 모델

상기 물리 ERD 는 MS SQL RDBMS 환경 기준의 물리적 테이블 관계도를 보여줍니다.
상기 물리 ERD 모델링 산출물을 이용하여 실제 DATABASE에 테이블을 만들과 컬럼을 만드는 과정을 다음장에서 진행하도록 하겠습니다.

TIP) 데이터 모델링 툴 소개
데이터 모델링 과정을 파워포인트와 같은 오피스 프로그램으로도 가능하지만 모델링 전문 툴을 사용하시면 정규화 과정이나 프로세스 이해에 도움이 더 될수 있습니다.
일반적인 UML 툴로는 StarUML,Visio 등이 있으며 전문 데이터 모델링 툴로는 CA사의 ErWin 툴이 있습니다. 모두 Trial 버전이나 무료버전 또는 Community 버전을 제공하고 있으므로 다운받아서 사용해 보실것도 권장드립니다.

2.모델의 유형 및 용도
상기 모델링 과정을 통해 도출된 논리,물리 모델을 근간으로 모델은 도출됩니다.
도출된 각종 모델들은 비즈니스의 실체의 기능을 프로그램 언어를 이용 클래스로 정의하여 비즈니스를 프로그래밍하는 용도로 사용될수 있고 데이터가 실제 저장되는 실체인 데이터 베이스 내 테이블의 구조를 정의하는데 사용될수도 있으며 DB 테이블 구조를 프로그래밍이 가능한 클래스로 표현하여 데이터들 담는 데이터 모델 클래스로도 사용하는등 다양한 용도로 개발 전체 과정에서 사용되어집니다.

다음은 데이터 처리 관점에서 사용되는 모델의 다양한 유형 및 용도에 대해 설명 드립니다.

A.비즈니스 도메인 모델 : Entity Model
개념 모델링을 통해 도출된 비즈니스 관점에서 바라 본 모델을 일반적으로 엔티티 또는 엔티티 모델이라 합니다.
비즈니스 실체의 특성을 표현한 것으로 비즈니스 관점에서만 기술된 엔티티 모델입니다.
사용자는 글을 입력한다 는 행위를 비즈니스 관점에 바라보면 게시글 엔티티의 주요 특성으로는 제목,작성자,메일주소,전화번호 ,글 내용 정도입니다.
게시글 작성자의 현재 IP주소는 고려대상이 되지 않습니다.

B.데이터 모델 : Data Model or Model
데이터 베이스에 저장되는 데이터의 구조를 프로그램 구조로 정의 한 것입니다.
즉 데이터 베이스의 데이터를 저장하는 실체인 테이블의 구조와 컬럼이 1:1맵핑되는 모델 클래스로 데이터 처리 프로그래밍 시 주로 사용되는 모델유형입니다.
-모델을 비즈니스 관점이 아닌 비즈니스 실체의 실질적으로 관리 되어져야하는 데이터 관리관점에서 바라본 모델이며 일반적으로 각종 DB Objects(Table,View,SP,Function)의 구조와 맵핑되는 구조를 제공합니다.
MVC,MVVM 개발 패턴에서의 Model은 일반적으로 데이터 모델을 말하며 OOP(객체지향 프로그래밍) 환경에서 프로그래밍을 통해 데이터의 구조를 정의하고 DB에 데이터를 전달할때 또는 DB에서 전달된 실제 데이터를 담는 컨테이너 클래스로 사용됩니다.

C.데이터 전송 모델 : Data Transfer Model(Object)=DTO
데이터 또는 데이터 모델을 전송하기 위한 구조를 정의하고 데이터를 담기 위한 모델입니다.
사용자가 화면(UI)을 통해 데이터를 입력하면 바로 DATABASE 에 데이터를 입력하고 조회할수도 있지만 정보관리시스템이 대형화 되고 다양한 시스템과의 통합(인터페이스)이 필요하고 개발된 리소스의 재사용이 필요한 시점이 되면 유지보수의 효율성을 높이기 위해 일반적으로 시스템을 화면영역(UI)과 서비스(서비스레이어+비즈니스로직처리레이어+데이터처리레이어) 처리 영역 과 데이터베이스 영역을 분리하는 시스템의 구조(아키텍처= Architecture)를 만들어 개발 운영합니다.

이런 개발 및 서비스 방식을 Layered 아키텍쳐(Layer) 또는 분산 아키텍쳐(Tier) 라 말하며 해당 아키텍쳐 환경에서는 화면에서 발생한 데이터를 DATABASE에 전달하거나 반대인 상황에서도 논리적이던 물리적이던 1개이상의 중간 계층을 거쳐 데이터가 최종 전달되기 때문에 한번에 데이터를 전송할 때 최대한 많은양의 데이터를 담아 전달해야 시스템의 효율 및 성능이 담보됩니다.

DTO 모델은 실제 저장되는 데이터의 구조를 정의 하는게 아닌 데이터 및 기 정의된 데이터 모델들을 좀더 효율적이고 생산적으로 계층간 데이터 전송을 하기 위해 별도의 모델 구조를 정의하고 정의된 DTO모델에 다량의 다종의 데이터 및 데이터 모델을 한꺼번에 담아 계층간 전달하기 위한 용도로 사용됩니다.

사용자가 게시글을 입력하고 첨부파일을 선택하고 게시글 분류를 선택 후 저장버튼을 클릭하면 사실상 게시글기본정보 와 첨부파일정보, 그리고 분류정보가 한번에 웹서버에 전달됩니다.
전달된 3종류의 데이터를 DB에 저장하기 위해 순차적으로 각전달하여 처리 가능하지만 서버의 어플리케이션 구조가 계층화 되어 있다면 3개의 정보를 별도의 DTO 모델에 담아 한번에 전달한다면 효율성 이 개선될수 있습니다.

D.뷰모델(뷰전용모델) : View Model
뷰모델이란 MVC에서의 View, MVVM에서의 View에서 사용하는 즉 화면에서만 사용되는 UI전용 데이터 모델을 말합니다.
간단한 예를 들면 화면에는 표현요소가 있지만 DB를 통해 관리 저장할 필요가 없는 요소가 있습니다.
고객의 구매상세 내역 화면이 있다고 가정 시 단일 주문에 대한 상품구매가, 배송비 ,총결제 금액을 표기해야 하는 상황에서 DB에는 상품 구매가 , 배송비 항목만 존재합니다.
데이터 모델에는 총결제금액 특성이 없어도 되지만 화면에 출력하기 위해서는 총결제금액 특성이 존재 해 야합니다.
이런 속성이 많다면 화면전용 데이터 모델인 뷰모델 을 만들어 사용합니다.