CMS를 사용하여 웹사이트를 구축할때는 제품의 전체 적용범위를 이해하고
절차에 맞는 구축을 하는 것이 중요하다.
XE를 이용한 웹사이트 구축 시에는 아래의 절차대로 하는것이 좋다.


배포처 : http://www.xpressengine.com/

1. 최신버전을 다운로드 받는다.

2. DB정보입력, 권한조정등을 거친 후 설치완료

3. 관리자 모드로 들어가서 구축을 시작한다.

4. 웹사이트 구축에 대한 구성도를 우선 가지고 있어야 한다.

5. 서비스관리>페이지 에서 Home 이라는 페이지를 우선 생성한다.

6. 우측상단의 Setting 으로 가서 조금전 생성한 Home 이라는 페이지를 시작모듈(사이트접속하면 처음나오도록)로 설정한다. Home 이라고 만든 페이지의 레이아웃을 메인페이지용 레이아웃으로 선택해야 한다.

7. 사이트설정>메뉴 에서 상단에 적용할 메인메뉴와 하단에쓰일 하단메뉴(보통 contact 등의 메뉴)를 각각 생성해둔다(추후 레이아웃에서 불러서 사용하기 위해서)

8. 서비스관리 메뉴에서 웹사이트에 사용될 페이지나 게시판등을 각각 만든다

9. 사이트설정>메뉴 에서 조금전 서비스관리에서 만든 페이지나 게시판과 연결해준다

10. 레이아웃과 스킨등을 수정해서 자신의 사이트로 만든다.


'삽질로그' 카테고리의 다른 글

캐즘  (0) 2009.06.09
도메인 등록해야 하나  (0) 2009.06.04
XE를 이용한 웹사이트 구축  (0) 2009.06.03
MS Outlook 2007 트레이에 숨기기  (0) 2009.05.29
온라인으로 사진 꾸미기  (0) 2009.05.23
GTD란 무엇인가?  (0) 2009.05.22

별도의 프로그램들을 이용하는 것 보다는 레지스트리를 수정하는 방법이 깔끔하다.

시작->실행->regedit 를 실행해서 레지스트리편집기를 연다.

아래의 경로를 찾아간다.

"HKEY_CURRENT_USER \ Software \ Microsoft \ Office \ 12.0 \ Outlook \ Preferences"

마우스 오른쪽 버튼을 눌러서 나타나는 팝업메뉴에서 새로만들기-> DWORD를 선택한다.

이름에 MintoTray 를 입력하고 값으로는 1을 입력한다.

아웃룩을 실행시키고 최소화를 해보면 트레이에 들어간다.


'삽질로그' 카테고리의 다른 글

도메인 등록해야 하나  (0) 2009.06.04
XE를 이용한 웹사이트 구축  (0) 2009.06.03
MS Outlook 2007 트레이에 숨기기  (0) 2009.05.29
온라인으로 사진 꾸미기  (0) 2009.05.23
GTD란 무엇인가?  (0) 2009.05.22
문서를 온라인으로 공유하는 방법들.  (0) 2009.05.12
몇해전 사진을 열어보니..
갑자기 포샵 도장툴을 쓰고싶은 욕망이 생긴다
쓱쓱..

그래도 먼가 부족한 느낌에..이리저리 검색해보니
온라인으로 사진을 꾸미는 서비스가 있다 ㅎㅎ

아래는 http://photofunia.com/ 를 이용해서 사진들..


GTD 는 Getting Things Done의 약자입니다. 이는 David Allen이 저술한 책의 제목으로서 그책에서 제시된 일정관리/정리법의 명칭이기도 합니다. Franklin Covey 와 같이 일정관리법이지만 다른점이 많습니다.

한글로도 GTD는 번역출판되어있는데 제목은 "끝도없는일 깔끔하게해치우기"입니다. (ISBN: 8950904896). 이링크를 따르시면 찾을수있습니다.


간단한 GTD 요점정리

1. 모든Stuff (만남약속, 읽어야되는 메모, e-mail, 음성메세지, 이런저런 청구서... = 업무.) 는 처음엔 INBOX로 들어간다.

2. 한번 본 INBOX 아이템은 다시 INBOX로 들어가지 않는다.

3. 모든 업무는 INBOX에 수집된후 검토 와 정리의 과정을통해 8목적지중 하나로 간다: Trash, Someday/Maybe, Reference, NextActions, Project, Waiting For, Calendar, Project Plans (그림참고 - 행동을 취할수있는지 없는지, Project인지 Next Action (다음행동) 인지 구분 가장중요). Next Actions (다음행동) 과 Calendar (달력일정) 으로 분류된 업무들은 실천된다.

4. Project = 목표 + 목표를 달성하는데 필요한 2가지 이상의 행동들

5. Project Next Action = "내가 오늘하루를 오로지 Project에 제시한 목표를 달성하는데 투자한다면 당장뭘하기시작할까?" 이질문의 답.

6. 2Minute Rule = 2분안에 끝낼수있는 Next Action은 당장해버린다.

7. InBox와 Next Action 폴더가 비면 아무것도 안해도 된다. 마음편히쉬어도 된다. 아무것도안할때에도 자기가 뭘안하고있는지 알고있으면 마음이 편하다.

8. Time Management - 시간관리 - 라는것은 없다. 아무리 관리해도 하루가 25시간이 되지않는다. 우리가 관리할수있는것은 자신의 행동이다.

9. 매일 계획을 세우지 않는다 - 계획은 실전을 살아남지 못한다.

10. 일에 Priority를 두지않는다 - 일은 중요한것부터 먼저하는것이 아니라 그일을 할수있는 상황에 처했을때 하는것이다 (사무실에서만 할수있는일이 아무리중요해도 집에서는 할수없다.) 시간적 압박이있는일은 달력에 입력한다.

11. Review는 일정한 기간마다 정기적으로 하는것이 아니고 필요한만큼한다 - 하루에 5번할수도 있고 일주일에 한번할수도 있다.

12. 메모하는 습관을 길러야한다 -- 머리속에남은 미완의 과제들은 스트레스의 근원이다. 모두 적어서 InBox에 넣어버려야한다. 그러하지 않는다면 InBox를 비워도 시원하지않고 찝찝함을 느낀다. 새로운 이시스템을 배우고 설치하는 이유는 일이끝난 시원함을 자주느끼게되기때문이다.

 

GTD WorkFlow Diagram

Jeff Kirvin 의 Palm GTD SetUp:

InBox = Todo 의 Unfiled Category Todo => (Linked To) ShadowLink GTD Outline 의 InBox (탑 레벌 아템)

Next Action = Todo 의 @Home, @Work, @ Computer 등등 Category => Datebk5 의 Saved Views를 스킨쓰듯이 각 상황마다 적절한 Todo보기에 쓴다.

Calendar = Datebk 5

Projects = ShadowLink GTD Outline 의 Project (탑 레벌 아템)

현재 내가 사용하고 있는 구글의 서비스

docs.google.com

- 워드,스프레트쉬트등의 문서를 웹상에서 편집하고 공유할수 있는기능.


http://www.scribd.com/my_docs
문서자료를 다양의 포멧으로 변환할 수 있고 공유가능
- OpenID 계정
인건비 보수 봉급,상여,정액수당
  기타직보수 계약직등의인건비
  일용임금 임시직보수
운영비 일반수용비 사무용품구입비
    인쇄비및유인비
    안내물등제작비
    소모품구입비
    간행물구입비
    비품수선비
    각종수수료
    업무위탁사례금
    공고료및광고료
    기타용역대가
  재료비 소모성재료비
    재료비매입대
    광물구입비
    종자구입비
    사료구입비
  복리후생비 법정부담금
    재해보상금
    동호회지원경비
    선택적복지제도
  시험연구비 시험연구경비
  기타운영비  
여비 국내여비  
  해외여비  
특수활동비 특정업무수행비  
직무수행경비 사업추진비 접대비
    연회비
    행사경비
  관서업무비 업무협의경비
연구개발비 연구개발비 연구용역비
    시스템개발경비
    연구위탁경비

 

자신만의 UCC 사이트를 구축하기 위해서 필요한 프로그램들을 나열하고 이들의 용도와 설치 방법, 사용 방법을 설명함으로써 동영상 사이트 만드는데 도움을 주고자 이글을 적습니다.

1. FFmpeg란?
FFmpeg은 stream audio와 video를 스트리밍하고, 레코딩하고, 컨버팅하는 오픈소스 솔루션입니다. 여기에는 또한 libavcodec라는 우수한 audio/video 라이브러리를 내장하고 있습니다.
거의 대부분의 OS에서 컴파일되므로 활용이 가능하다는 장점이 있죠.
ffplay multimedia player를 내장도 하고 있습니다. ffserver라는 스트리밍 서버 기능도 있고 다양한 파일 포멧(AVI, MPEG, OGG, Matroska, ASF, …)과 인코딩 포멧(MPEG, DivX, MPEG4, AC3, DV, …)을 지원합니다.
간략하게 요역하자면 아래와 같습니다.

  • ffmpeg: 비디오 파일 포맷을 다른 포맷으로 변환할 수 있는 커맨드라인 툴. TV 수신 카드로부터 실시간 영상을 받아 인코딩할 수 있음
  • ffserver: HTTP 프로토콜을 사용하는 스트리밍 서버이다. 실시간 재생 도중 재생 위치 변경 기능을 제공함
  • ffplay: SDL과 ffmpeg 를 사용해서 구현된 간단한 재생 프로그램임
  • libavcodec: ffmpeg에서 사용하는 모든 오디오/비디오 코덱이 들어있는 라이브러리이다. 최고의 효율과 코드 재사용성을 목표로 만들어졌음
  • libavformat: ffmpeg에서 사용하는 모든 오디오/비디오 코덱을 파싱하고 생성하는 루틴들이 들어있는 라이브러리

2. 필요한 라이브러리
ffmpegFLV audio codec은 mp3이다. 그래서 오디오 변환을 위해서 LAME 이 필요하고 flv를 플레이하기 위해서는 다양한 Metadata가 필요하다. 그래서 FLVTool2가 필요합니다. FLVTool2는 루비를 설치해야만 합니다. ^^ 그리고 php로 운영하신다면 ffmpeg-php가 필요하겠죠.
마지막으로 플레이를 하기 위해서는 FlowPlayer를 다운받아서 활용하시는게 좋을 겁니다.
그럼 LAME->FFmpeg->Ruby->FLVTool2->FlowPlayer 순으로 설치를 하시면 됩니다.

 - LAME 설치
   . shell>wget http://downloads.sourceforge.net/lame/lame-398.tar.gz?
            modtime=1215212728&big_mirror=0
   . shell>./configure --enable-shared --prefix=/home/k2/server/lame;make;make install
 - FFMpeg 설치
   . shell>svn checkout svn://svn.mplayerhq.hu/ffmpeg/trunk ffmpeg
   . shell>cd ffmpeg
   . shell>./configure --prefix=/home/k2/server/ffmpeg
            --enable-gpl --enable-shared --enable-mp3lam;make;make install
   . 사용 방법 : ffmpeg -i "mimul.avi" -vcodec flv -f flv -r 29.97 -s 320×240
          -aspect 4:3 -b 300kb -g 160 -cmp 2 -subcmp 2 -mbd 2 -flags
          +aic+cbp+mv0+mv4+trell -ac 1 -ar 22050 -ab 56k "mimul_avi.flv"
 - Ruby
   . shell>wget ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7-p22.tar.bz2
   . shell>./configue --prefix=/home/k2/server/ruby;make;make install
 - FLVTool2
   . shell>wget
   . shell>ruby setup.rb config;ruby setup.rb setup;ruby setup.rb install
   . 사용방법 : RUBYLIB=lib ruby bin/flvtool2 -U <path to>/movie.flv
 - Flowplayer
   . http://flowplayer.org/download.html 사이트에서 파일을 다운 받음
   . 사용방법
<object type="application/x-shockwave-flash" data="[your site]/FlowPlayer.swf"
width="320" height="263" id="FlowPlayer">
<param name="allowScriptAccess" value="sameDomain"/>
<param name="movie" value="[your site]/FlowPlayer.swf"/>
<param name="quality" value="high"/>
<param name="scale" value="noScale"/>
<param name="wmode" value="transparent"/>
<param name="flashvars" value="baseURL=[base URL]&amp;videoFile=movie.flv
&amp;autoPlay=false&amp;loop=false&amp;autoBuffering=false
&amp;splashImageFile=movie.jpg"/>
</object>
[참조 사이트]
  • http://lame.sourceforge.net/
  • http://ffmpeg.mplayerhq.hu/
  • http://www.ruby-lang.org/
  • http://flowplayer.org/

Toad DBA Suite로 패키징된 제품 중에서 먼저 TDM 제품에 대한 리뷰를 간략하게 작성해 보았다.

 

<먼저, 본 리뷰에서 언급한 사항 중에 툴에 대해서 깊이 있게 알지 못해서 혹은, 특정 기능을 찾지 못해서 잘못된 내용을 기술할 수도 있음을 미리 알린다. 나름 기능을 찾기 위해 매뉴얼도 찾아보고 했지만, 자료도 부족하고 영어 울렁증이 있어서 말이다.>

 

TDM은 데이터 모델링 툴이다. 대표적인 데이터 모델링 툴로는 국내에서 많이 사용하는 Allfusion ERWin, DA#(encore), ER/Studio(Embarcadero), PowerDesigner(Sybase), Visio(Microsoft) 등이 있으며 UML 툴에서 데이터모델링을 지원하거나 eclipse plug-in으로 나온 제품들도 있다.

 

예전에 TDM의 초기버전은 논리모델이 없었으며, 물리모델만을 모델링 할 수 있도록 구성되어 있었던 것으로 생각된다. 이번 버전은 기존의 기능에 논리모델 기능 및 여러가지 다양한 기능을 추가하여 나온 제품인 듯 하다.

<?xml:namespace prefix = o /> 

"百聞 不如一見"

 

 

TDM을 설치 후에 처음으로 실행한 화면이다.

TDM TOAD만큼 유명한 제품이 아니라서 그런지 샘플모델을 디폴트로 로드되도록 구성되어 있다. 첫 느낌은 색깔이 화려한게 일단 맘에 든다.

 

LDM & PDM

TDM이 다른 모델링 툴과 가장 차이점은 LDM(Logical Data Model) PDM(Physical Data Model)을 작성하고 관리하는 방식인 것 같다.

대부분의 모델링 툴은 LDM PDM을 동일한 구조를 갖도록 구성해야 한다.

 

위의 그림과 같이 Super Type Sub Type으로 구성된 논리모델이 있을 때, 물리모델에서는 테이블 단위로 구성되기 때문에 물리모델 단계에서 각 엔티티를 하나의 엔티티로 통합하거나 각각의 서브타입으로 분리하거나 하는 방식으로 변경을 한다.

Erwin이나 대부분의 모델링 툴에서는 논리모델시에 위의 그림처럼 Subtype으로 모델링을 하여도 최종 물리모델단계로 넘어가면서 엔티티를 통합/분리하므로 최종적으로는 하나의 엔티티가 어떤 서브타입으로 구성되어 있는지 모델만 봐서는 파악하기가 어려워진다.(물론 별도의 파일로 작성하면 가능은 하지만 상당히 관리가 불편해진다.) 그런 단점이 있으나 논리모델과 물리모델이 동일한 모습을 가지게 되므로 논리모델에서 물리모델로 전환이 쉬워지는 장점이 있으며 하나의 파일로 관리된다는 점도 장점 중 하나이다.

 

그러나 TDM은 일반적인 하나의 파일로 논리/물리를 관리하지 않으며 별개의 파일로 논리/물리모델을 구성/관리하도록 되어 있다.

 

위의 그림과 같이 간단히 논리모델을 TDM으로 작성하였다. 물리모델을 작성하기 위해서는 TDM에서는 Convertor를 이용하여 물리모델을 생성하여야 한다.

 

다음은 툴의 기능을 이용하여 물리모델을 작성한 화면이다.

두 모델을 비교하면 물리모델에서는 Subtype이 하나의 테이블로 통합되어 구성이 되어있다. TDM에서는 이렇게 비즈니스 로직을 담고 있는 논리모델과 테이블구조를 가지는 물리모델을 분리하여 관리하도록 하여 논리모델에서는 비즈니스 로직만을 충실히 담을 수 있도록 구성하여 기존 툴과의 차별성을 내세우고 있다.

 

그러나 데이터모델은 지속적으로 변경된다. TDM에서는 한번 변환한 모델간의 Alignment가 되지 않는다는 치명적인 단점이 있다.

가령 논리모델에서의 사용자아이디란 속성이 물리모델에서의 “USER_ID”란 컬럼으로 변경되어 있다는 정보를 툴이 인식을 하지 못한다. 그러므로 논리모델의 속성명이 변경되거나 컬럼사이즈가 변경, 컬럼의 추가 등의 변경이 발생하더라도 물리모델에서 인식을 하지 못하므로 개별적으로 두 모델을 따로 관리하여야 한다.

혹시 Convertor를 이용하면 되지 않을까? 열심히 궁리를 해보았지만 Convertor에서는 사용자아이디“USER_ID”가 완전히 서로 틀린 컬럼으로 인식하고 있어서 방법이 없었다.

 

[위의 그림처럼 좌측의 회원이 물리모델에서 존재하지 않는 것으로 나타나며, 우측의 USER 테이블에 해당되는 좌측의 논리모델도 존재하지 않는 것으로 나타난다.]

 

매뉴얼을 찾아보니 모델 변경시에는 물리모델을 먼저 변경하고 변경사항을 역으로 PDM -> LDM으로 병합해야 한다고 나와있었다.

그 말은 비즈니스 모델이 변경되었지만 물리모델에서 먼저 작업하고 비즈니스 로직을 나중에 고치라는 말도 안되는 방식을 툴은 강요하고 있는 것이다.

차기 버전에서 가장 개선되어야 할 부분이 아닌가 싶다.

LDM PDM을 별도의 파일로 관리하는 모델링툴의 대표적인 사례는 DA#이 있다. 이 툴은 논리모델의 변경사항을 한번의 클릭으로 물리모델에서 정확히 인식하며 엔티티 레벨, 속성 레벨의 변경정보를 정확히 모델러에게 알려준다.

 

엔티티 속성 편집창

다음은 LDM  엔티티 속성 편집창의 모습이다.

 

 

일반적인 엔티티의 속성 정보를 저장할 수 있는 UI이다.

Caption 항목은 속성의 설명정보를 담는 항목이다. 대부분의 툴에서는 Description 이름으로 제공하고 있다.

모델링을 하다 보면 Caption Description 기능이 모두 필요하다.

특히 우리나라 같이 비 영문 국가에서는 테이블 생성시에 Comment 객체에 컬럼의 한글명을 기입하고 논리모델에서는 컬럼의 상세한 업무규칙 및 컬럼의 정의를 할 수 있다면 가장 best 하지만 아쉽게도 그렇게 구별하여 지원하는 툴은 아직까지는 보지 못한 것 같다.(나만 필요하다고 느끼는 것인지도 모르겠다)

 

컬럼편집

TDM에서는 컬럼별로 복사를 할 방법이 없다. 엔티티 레벨에서는 복사가 가능하나 LDM에서 특정 속성만을 선택하여 다른 엔티티로 컬럼을 복사할 방법이 없다. 등록일자/수정일자 같은 시스템 공통속성을 전 엔티티에 모두 두기 위해서는 각 엔티티마다 모두 입력하는 방법밖에 없다. 이 부분도 반드시 차기 버전에는 들어가야 될 기능이 아닐까 싶다.

 

데이터 표준화 지원

TDM의 또 다른 단점 중 하나는 데이터 표준화에 대한 지원이다.

TDM에서 도메인을 지원하기는 하나 계층적으로 구성할 수가 없고 별도의 도메인타입을 만들 수 가 없어서 모든 도메인을 1차원적으로 구성해야 한다. 조금은 아쉬운 부분이다.

또한, 물리모델 생성시에 단어 및 용어 표준화를 지원하지 않는다. 툴을 열심히 뒤졌것만 찾을 수가 없었다. 특히 우리나라같이 한글로 논리모델을 작성하고 영문컬럼명으로 물리모델을 변환해서 사용해야 하는 환경에서 영문컬럼명 변환을 매번 모든 컬럼을 클릭하여 입력한다는 것은 엄청난 노가다다.  용어사전을 생성하여 두고 자동으로 변환되지 않는다면 엔티티가 100개만 넘어가더라도..(생각하기도 싫다)

이 부분도 차기 버전에 반드시 들어가야 될 기능이 아닌가 싶다.

 

WorkSpace & UI

TDM에서는 주제영역(Subject Area) Workspace란 명칭으로 사용한다. eclipse의 영향인 것 같기도 하다. 거의 모든 툴에서 subject area란 용어를 사용하는데 말이다.

TDM의 편리한 점 중 하나는 여러 모델을 tab 방식으로 조회를 할 수 있는 점인 것 같다.

그리고 TDM에서는 실행취소 기능을 제공한다. 이게 얼마나 편리한 기능인지는 이 기능이 없는 툴을 사용해 본 사람이면 공감을 할 것이다. Erwin의 경우에도 아직도 많은 사람들이 사용하고 있는 v4.xxx 버전에서는 이 기능이 없다. r7 버전부터 이 기능을 제공하고 있으니 말이다. 엔코아의 모델링 툴인 da# 의 경우도 실행취소 기능이 없어서 어떤 땐 무지 짜증이 날 때도 있다. TDM에서는 이 기능을 제공해 주니 그래도 쓸만은 하다.

 

Reverse Engineering

리버스 엔지니어링은 초기 AS-IS 데이터 모델 분석시에 반드시 필요한 부분이다. 특히 엔티티가 몇 백개씩 되는 대형 사이트에서는 이 기능이 없으면 DB 분석시에 엄청난 시간이 걸릴것이다. 리버스 엔지니어링과 관련하여 또 반드시 필요한 기능은 테이블 정렬 기능이다. 몇 백개 되는 테이블이 아무런 연관없이 이름을 툴위에 쭉 나열한다면 테이블을 거의 분석하기가 힘들것이다. 대부분의 시스템에서 명식적인 FK를 설정하지 않고 데이터베이스를 구성하기 때문에 툴에서 컬럼명을 기준으로 가상의 Relation을 생성해주고, 사용자가 지정하는 Key Entity 혹은 Main Entity를 중심으로 주변에 Action Entity를 배치하게 해준다면 리버스 된 모델이 사용자가 인지하기 쉬운 구조로 재배치되어 많은 도움이 되리라 생각된다.

TDM에서는 리버스 기능은 훌륭하나 테이블 정렬기능은 단순정렬밖에 제공되고 있지 않아 아쉬움이 남는다.

아래 그림은 운영하고 있는 시스템을 리버스로 물리모델을 생성하는 과정을 담고 있는 화면이다.

 

 

설치시에 데이터소스를 오라클과 MS-SQL만으로 한정하였기에 해당되는 항목이 위의 정보만 나타난다. MS-SQL 2008 ORACLE11도 출시되었으니 조만간에 추가되지 않을까 싶다. 또한 QUEST사의 대표적인 제품인 TOAD와 연동할 수 있는 기능이 눈에 띈다.

 

Data Provider 및 접속정보를 입력한 후 Reverse해야 될 대상을 선택하는 화면이다.

 

다음은 리버스에 대한 옵션을 선택하는 화면이다.

 

최종적으로 리버스해야될 테이블은 선택하고 나서 Execute 버튼을 클릭하면 TDM은 리버스를 시작한다.

 

 

위의 그림은 최종적으로 리버스된 물리모델의 모습이다.

 

테이블 속성편집 창

리버스된 테이블의 속성 편집창이다.

상당히 많은 탭이 보인다.

 

SQL Preview 기능은 다른 툴에서는 잘 없는 기능인데 편리한 기능인 것 같다.

 

테이블의 속성정보 (위 그림은 파티션정보이다.)을 콤보박스나 그리드 같은 UI를 사용하지 않고 Text로 입력하도록 구성되어 있는 모습이다.

 

 

리버스한 정보 중 오라클 패키지의 SQL Preview화면이다. 주석의 일부분이 진한갈색으로 보이는건 왜 그런지 모르지만 리버스는 훌륭히 수행한 것 같다.

 

모델 Compare Alter Script Generation

극히 일부의 모델링툴에서만 제공하는(Erwin) 편리한 기능이 TDM에도 탑재되어 있다. 모델간의 비교 및 비교를 통한 Alter Script를 생성해주는 기능이다. 변경되는 양이 적을 경우에는 툴보다는 손으로 스크립트를 작성하는게 편리하다. 그러나 큰 규모의 변경이 일어나는 경우에는 툴의 기능을 이용하면 편리하게 업무를 처리할 수 있다.

 

 

위의 그림은 물리모델에서 하나의 컬럼을 추가한 후 ALTER SCRIPT를 생성하기 위해 Convertor를 실행시킨 모습이다.

 

 

최종적으로 생성된 Alter 스크립트이다. 변경된 부분 중에서 필요한 부분만 선택하여서 Alter 스크립트를 생성할 수 있다.

 

Reporting

프로젝트 개발시에 모델링에 대한 산출물은 필수산출물이다. 나는 대체로 별도로 산출물을 작성하지 않으며 ER모델을 아주 상세하게 작성한 후 고객사의 양식에 맞게끔 툴로 Generation하여 제출하는 편이다. 그러므로 이 기능은 아주 필요한 기능이다.

TDM HTML 방식과 rtf 파일을 제공하고 있다.

 

위의 그림은 Report 생성시에 필요한 사항을 선택하는 화면이다.

최종적으로 Reporting된 화면은 아래와 같다

 

 

내부 프로젝트나 별도의 양식이 없는 프로젝트의 경우에는 사용이 가능하나 고객사 혹은 내부 산출물 양식이 지정되어 있는 경우는 이정도 레포팅 기능으로는 부족하지 않나 싶다.

별도의 양식을 디자인하는 기능이나 혹은 Erwin처럼 별도의 API를 제공은 고사하더라도 최소한 엔티티나 테이블의 정보를 엑셀로 출력하는 기능정도는 있어야 하지 않을까 싶다.

 

총평

Toad Data Modeler(TDM)은 버전 3으로 오면서 많은 기능이 추가되었지만, 아직까지는 부족한 기능이 많은 편이다. 소규모 프로젝트에서는 가능한 수준이 아닌가 싶다. 그러나 데이터베이스 관련한 SW의 노하우가 많은 Quest사의 제품이니만큼 그리 오래지 않아 필요한 기능들이 모두 추가되고 TDM만이 제공하는 특별한 기능까지. 향후에는 Toad와 같은 명성을 TDM도 얻을 수 있으리라 생각한다.


1. 데이터 모델
  1.1 데이터 모델의 정의
데이터의 집합을 기술하는데 사용되는 개념이며, 데이터를 조작할 수 있는 연산들의 모임을 의미한다. 데이터는 키(주 식별자)와 일반 칼럼(속성, Attribute)올 표현이 되며 키와 칼럼들이 모인 로우(레코드), 하나 이상의 로우가 모인 테이블(모델링 단계에서는 엔티티)이 되는데, 모든 용어들이 데이터의 표현에 사용된다.
  1.2 데이터 모델의 종류
가. 개념적 모델(Conceptual Model)
현실 세계의 업무규칙(업무처리흐름상의 규칙, 양식 등의 자료를 구성하는 데이터들의 상관관계 규칙)을 개략적으로 데이터 모델을 사용하여 표현을 하되, 각각의 사업장, 부서 등에 대해서 개별적인 데이터 모델이 작성될 수 있다.
나. 논리적 모델(Logical Model)
개념적 데이터 모델을 통합한 것으로써, 각각의 사업장, 부서 등의 데이터를 구성하는 속성들의
도메인(자릿수, 형태, 초기 값 등)이 통합되어 표현 된다.

논리적 데이터 모델은 특히 다음과 같은 특성을 가지고 있다.
? 데이터베이스 설계 시 사용
? 주어진 현실세계로부터 개념의 집합을 명세
? 높은 수준의 추상화에서 현실세계를 표현하는 도구
? 현실세계를 이해하기 쉽고 해석하기 쉽도록 현실세계를 명세

논리적 데이터 모델의 평가기준은 다음과 같다.
? 표현성(Expressiveness)
? 단순성(Simplicity)
? 최소성(Minimality)
? 정형성((Formality)

다. 물리적 모델(Physical Model)
논리적 데이터 모델과 비교한 물리적 데이터 모델의 특징은 다음과 같다.
? 특정 DBMS에 의해 지원됨
? 컴퓨터에 의해 처리될 수 있는 데이터 명세를 지원
? 종류 : 계층형 모델, CODASYL 모델, 관계형 모델

  1.3 데이터베이스 구축과정으로 본 데이터 모델의 의의
데이터베이스 구축과정은 현실세계의 데이터와 업무를 데이터 모델의 세계로 Mapping시키는 과정이라고 할 수 있다. 데이터베이스는 현실 세계의 데이터와 업무를 그들의 세계로 안내하는데 있어서 그들이 채택한 모델을 통하여 안내한다. 즉, 모델의 표현규칙, 작성규칙을 따라 현실세계의 자료와 업무가 표현된다. 다시 말하면 컴퓨터세계와 현실세계의 연결다리 역할을 하는 것이 바로 이 모델이다. 데이터베이스 관리시스템(DBMS) 또한 이 모델을 근거로 각종 자동화 처리기를 제작했다. 따라서, 데이터베이스 시스템을 구축 시에 필수적으로 그들이 채택한 데이터 모델에 대하여 정통할 필요가 있다.
2. 데이터 모델링
  2.1 데이터 모델링 절차
다음은 일반적인 데이터 모델링 절차이다.
일반론적인 데이터 모델링 절차 그림에서 '데이터 모델 콘테스트' 및 '업종별 표준 데이터 모델'의 제작과 관련하여 엔티티 정의, 관계 정의, 엔티티-관계도 작성, 주/부 식별자 정의, 외부 식별자 정의, 세부속성 정의에 대해서만 설명하기로 한다. 나머지 부분들은 일반 책자들에 잘 설명이 되어 있으므로 참고하기 바란다.
  2.2 엔티티 정의
가. 엔티티의 종류
엔티티의 종류는 독립 엔티티(Kernel Entity, Master Entity), 업무중심 엔티티(Transaction Entity), 종속 엔티티(Dependent Entity), 교차 엔티티(Associative Entity, Relative Entity)의 4종류로 분류된다.
1) 독립 엔티티(Kernel Entity, Master Entity)
    사람, 물건, 장소, 개념처럼 원래부터 현실세계에 존재하는 엔티티.
    예) 사원, 고객, 영업부, 창고, 생산계획, 계정과목 …

2) 업무중심 엔티티(Transaction Entity)
    업무가 실행되면서 발생하는 엔티티
    예) 주문, 납품, 대금청구, 대금지급 …

3) 종속 엔티티(Dependent Entity)
    주로 1차 정규화(1st Normalization)로 인하여 관련 중심엔티티로 부터 분리된 엔티티
    예) 주문품목, 납품품목 …

4) 교차 엔티티(Associative Entity, Relative Entity)
    다:다 관계를 해소하려는 목적으로 인위적으로 만들어진 엔티티

나. 엔티티의 자격조건
엔티티의 종류는 독립 엔티티(Kernel Entity, Master Entity), 업무중심 엔티티(Transaction Entity), 종속 엔티티(Dependent Entity), 교차 엔티티(Associative Entity, Relative Entity)의 4종류로 분류된다.

다. 엔티티의 예
다음 표는 엔티티의 사례를 보여주는 표이다.
① 사람 (사원(직원, 행원, 공원,…), 계약자(가입자, 회원,…), 이용자(학생, 환자,…))
② 물건 (재료(부품, 원자재, 연료, …), 상품(제품,…), 시설(건물, 창고, 운송센터,…), 지점(영업소, 소매점,…))
③ 사건 (계약(수주,발주,…), 작업(공정, 보관, 선전, 광고,…), 사고(재해, 고장,…))
④ 장소 (구획(창고, 선반, 진열케이스, 생산라인, …), 지역(판매구역, 관할구, 선거구,…), 하천, 항만(부두, 선창,…))
⑤ 개념 (목표, 계획(지침, 방침, 지표, 판매목표, 생산계획, 판매계획, 인원계획,…), 시간(월, 일, 년, 시각, 시각분할,…), 평가(기준, 지표))
⑥ 금전 (예입금(구좌,…), 예산(년간예산, 수정예산, 실행예산,…), 차입(단기, 장기,…), 융자(단기, 장기,…))

  2.3 관계(Relationship) 정의
가. 기수성(Cardinality)
기수성은 다음과 같이 정의된다.
? 1:1, 1:M, M:N 관계
? 해당엔티티 1건에 대한 상대엔티티의 기수성을 상대 엔티티쪽에 표기
? 표기 방법(James Martine 표기법)

나. 선택성(Optionality)
선택성은 다음과 같이 정의된다.
? 집합의미 (포함, 불포함)
? 1:0 (Optional), 1:1 (Mandatory)
? 해당엔티티 1건에 대한 상대엔티티의 기수성을 상대엔티티쪽에 표기
? 표기 방법(James Martine 표기법)

다. 관계의 완성 : 기수성과 선택성의 통합 [James Martin]
기수성과 선택성을 통합하면 관계가 완성이 된다.
? 해당 엔티티를 기준으로 기수성의 경우의 수와 선택성의 경우의 수를 합하여 최소값과
  최대값의 경우의 수를 구한 후 해당 엔티티쪽에 최대값을 바깥쪽에 최소값을 표기한다.
? 상대 엔티티도 유사한 방법으로 표기한다.

라. 관계의 완성 사례
다음은 '고객'엔티티와 '주문'엔티티에 대하여 관계를 작성하는 절차를 보여주는 사례이다.
? 기수성 : 각 고객은 하나 이상의 주문을 할 수도 있고 안 할 수도 있다.
? 선택성 : 각 주문은 고객이 하는 것도 있고 그렇지 않을 수도 있다. (사원이 할 수도 있다.)

관계를 완성할 때 흔히 나올 수 있는 경우에 대한 대처 방법을 설명하기로 한다.
첫째, 기수성과 선택성의 통합 시 다:다 관계가 나올 수가 있는데 이는 Table Join이 안되므
        로 (외부 키의 표시가 불능) 교차 엔티티를 이용하여 표기한다.

둘째, 관계는 두 엔티티간의 업무규칙(Business Rule)을 토대로 인위적인 방법으로 기수성
        과 선택성을 구하여 이를 통합하여 완성된다.

셋째, 관계(Relationship) 표기의 의미는 두 엔티티 중에서 외부키(Foreign Key)가 놓이는
        자식 엔티티를 구분하기 위한 것이 첫째 임무이다. 외부키는 부모엔티티의 기본키(Pri
        mary Key)가 되기 때문이다. 둘째 임무는 외부키 무결성(관계무결성)을 구하기 위한
        것이다.

넷째, 기수성 표기, 선택성 표기, 관계통합 표기 방법이 각 교수나 RDBMS 업체에 따라 다를
        수 있는데 큰 문제가 되지 않는다. 왜 관계(Relationship)를 구하는 가의 이유만 알면
        되기 때문이다.

  2.4 엔티티-관계도(Entity Relationship Diagram)의 작성
가. 작도방법
다음은 엔티티-관계도를 효과적으로 작성하는 기법을 설명하기로 한다.
? 사각형의 도형 안에 엔티티명을 기록
? 업무흐름의 진행순서와 관련된 엔티티는 진행순서를 고려하여 좌에서 우 또는 상에서 하로   중심부에 배열 ("주문"→ "출고")
? 중심에 배열된 엔티티와 관계를 가진 연관엔티티(종속엔티티)를 가까운 쪽으로 배열
  ("주문" : "주문품목", "출고" : "출고품목")
? 배열된 엔티티와 관계를 갖는 핵심엔티티(Kernal Entity)를 외곽으로 전개
  ("주문", "고객", "영업담당자", "창고", "품목", "제품")
? 해당엔티티의 한 건에 대한 상대엔티티의 기수성(Cardinality)을 상대 엔티티쪽에 표기함으
  로써 관계의 기수성을 표기 :
? 해당엔티티의 한 건에 대한 상대엔티티의 선택성(Optionality)을 상대 엔티티쪽에 표기함으
  로써 관계의 선택성을 표기 :

나. 주요성공요소
엔티티-관계도를 작성하는데 있어서 주요성공요소는 다음과 같다.
? 엔티티를 식별하고, 관계를 도출한 후 ERD작도법에 맞추어 ERD를 작성
? 업무흐름 및 업무규칙의 ERD작도 시 활용

다. 엔티티-관계도와 관련된 실무적인 의미 및 검증기준
다음은 엔티티-관계도의 실무적인 의미와 작성시 유의사항이다.
첫째, 엔티티-관계도는 데이터베이스의 형상(Schema)을 결정하는 매우 중요한 그림이다.
둘째, 엔티티-관계도는 업무흐름을 나타낼 수 있어야 하며, 중요한 데이터속성들이 모두 표현되어 있어야 한다. 따라서 엔티티-관계도는 표현규칙 및 작성규칙에 충실하게 따라서 작성이 되어야 한다.
셋째, 엔티티-관계도를 그리다 보면 선이 겹치는 경우가 많이 발생하는데, 이는 상기한 작도방법을 따르지 않은 것으로 많은 문제를 야기할 수 있다.

다음은 실무적으로 엔티티-관계도를 효과적으로 작성하는 절차이다.
? 엔티티의 배열
? 관계의 연결
? 기수성 정의 (기수성명 표기)
? 선택성 정의 (선택성명 표기)
? 기수성과 선택성의 통합 : 엔티티-관계도의 완성
? 관계가 다:다일 경우에 교차엔티티를 이용하여 일대다로 분리함

다음은 엔티티-관계도의 검증기준이다.
? 작성규칙 및 데이터모델 표현규칙 적합성, 단순성, 확장성, 비중복성, 공유성
? 모든 속성의 표현
? 관계표기의 적합성
? 사용자의 데이터요구(화면, 보고서 등)에의 성능 우수성

  2.5 주식별자(Primary Identifier, primary Key, 주키) 정의
다음은 주식별자에 대한 정의절차이다. 이해하기 쉬우므로 간략하게 절차만 설명한다.
 
? 각 엔티티별로 하나의 주식별자 선택
? 후보 식별자 중 가장 중요한 하나를 주식별자로, 나머지를 대체키로 지정
? Subtype엔티티의 주식별자는 Supertype엔티티의 주식별자와 동일하게 선택
? 데이터 이름에 대한 표준약어목록의 이용

  2.6 외부식별자(Foreign Identifier, Foreign Key, 외부키) 정의
가. 외부식별자의 특징
외부식별자는 다음과 같은 특징을 가진다.
? 두 엔티티간의 관계를 결정하여 주는 속성으로 관계에 의한 자식엔티티에 위치하며 부모엔
  티티의 주식별자가 같은 값을 갖는다.
? 논리적 데이터 모델내의 모든 관계에 관련된 외부키를 규명한다.

나. 외부식별자의 표기 사례
다음 그림은 외부식별자의 표기 예를 보여준다.

  2.7 속성 정의
가. 속성 정의
속성이란 엔티티를 구성하는 더 이상 분리될 수 없는 정보단위로 식별자 종류(기본, 대체, 외부 키)와 비식별자(non-key)로 구분한다.

나. 효과적인 속성 정의방법
다음과 같은 방법으로 속성을 찾아 정의한다.
? 정보 분석단계에서 수집된 각종자료 참조
? 엔티티, 관계 정의시 파악
? 기존 정보시스템 분석 - 관련 DB나 file의 field
? 속성의 이름을 부여 - 표준화 규칙 사용, 자료사전에 기록

다. 속성 정의 예
다음 표는 제품 엔티티에 대한 속성 정의 예이다.
엔티티 속성 속성유형 식별자구분 비고
제품 제품코드 설계 PK
  제품명 기초  
  기대수요 기초    
  재주문요구 기초    

  2.8 데이터 모델 검증 및 주요성공요소
가. 데이터 모델 검증 방법
데이터 모델 검증은 아래와 같은 범위의 품질기준에 맞추어 검증한다.
? Group Check
Business rule에 의한 완전한 이해와 E-R Modeling에 대한 완전한 이해를 가진 숙련된 분석가가 최선의 답이며, Project 팀 내의 동료끼리 상호 모델을 Check하고 오류를 찾아 본다.
? 사용자(End User) 확인
정기적으로 사용자에게 모델을 제시하면서 확인하거나, 사용자를 참여시켜 Error와 누락된 것을 check한다.
? 업무규칙(Business Rule)
? 엔티티품질 검증
? 속성품질 검증
? 관계품질 검증
? 완전성 검증
사용자 INTERVIEW, 서류양식, 장표, 보고서 등과 비교 점검하여 추가되거나 누락된 것이 없는지를 확인하고, 향후 입력, 출력보고서가 모두 적용될 수 있는지를 점검한다.

나. 주요성공요소
데이터 모델링을 잘하기 위하여 다음과 같은 내용들을 숙지한다.
첫째,
분석단계의 Data Modeling(산출물: Logical ERD)과 설계단계(산출물: Physical ERD)의 구분
? Business Rule이 같기 때문에 분석단계의 ERD(Entity로 표시)와 설계단계의
  ERD(Table로 표시)의 근본구조는 달라지지 않는다.
? 분석단계의 ERD에서 약 20%내외만이 수정이 되어 설계단계의 ERD로 바뀐다.
? 설계단계에서는 성능(Performance)을 고려한 Summary, Duplicate, Processin
  g Table이 만들어진다.
둘째,
엔티티-관계도(ERD) 작성 및 검증요령
? 현재의 장표, 양식, 업무 매뉴얼, 보고서, 사용자인터뷰 내용 등에서 Entity추출
  기준 (정보관리대상, 유일한 키의 존재, 키 이외의 속성 가질 것) 엔티티(Entity)
  를 추출 하여 적어 놓는다.)
? 엔티티 사이의 Business Rule을 분석하여 그들 사이의 관계를 찾는다.
관계유형>
▶ Dynamic flow(업무흐름도에 의존 :주문→생산지시→제품입고 → 출고 →납품)
▶ Static flow(데이터 자체의 관계 : BOM Type, Super-Sub Type)
▶ Transient flow(시간이 가면 변하는 것 : 정산-미정산 분개의 확정 시점)
? 향후 입력화면, 출력보고서가 현재의 ERD에서 추측될 수가 있고 계산하기 편한
  가 등의 기준으로 엔티티-관계도를 검증한다.
세째,
엔티티(Entity, Table)를 분해한 후 합칠 수 있다
? 엔티티-관계도 작성시 핵심엔티티(독립엔티티, 코드엔티티 : kernel Entity)를
  구별함
? Sub-system만 제작한 다음 나중에 통합할 수 있다.
네째,
엔티티-관계도를 제대로 못 그리는 이유 : Business Rule을 제대로 분석하지 못했기 때문
? Business Rule에 숨어있는 Data를 분석해내지 못했고 그들 Data사이의 관계를
  분석하지 못했기 때문
? ER 방법론 미 숙지
? Business Rule해독 90%, ER방법론 숙지 10%
다섯째,
관계형 데이터베이스 모델링은 속성(Attribute)끼리의 Logical Model이다
? 속성(Attribute끼리의 Business Rule → Relationship
? 물리적 의미(Physical meaning) → Relational Key(외부키)의 정의
여섯째,
관계형 데이터베이스는 속성(Attribute)접근 방식이지 Pointer접근방식(COBOL문의 OCCURS, Redefine)이 아님, 즉 같은 TYPE의 속성은 중복되면 안 된다.
일곱째,
엔티티-관계도(ERD)작성시 속성 검출 및 정규화 유의사항
? 속성(Attribute)은 가장 최소로 자른다. (예 : 년월일→년, 월, 일)
? 주키(Primary Key)가 나누어지는 것은 분석이 잘못되었기 때문이다
? 1차, 2차, 3차 정규화를 잘 할 것
여덟째,
다대다(Many to Many)관계가 해소되어야 하는 이유와 해소 방법
? 속성(Attribute)사이에만 관계(Relationship)가 생성하는데, Many to Many는
  관계를 맞출 수가 없다.
? 비교엔티티 (연결엔티티, 교차엔티티)를 집어넣어준다
  : 양쪽의 엔티티(Entity)와 속성(Attribute)이 서로 key나 Data부분의 속성
  (Attribute)으로 들어가기만 하면 된다.
아홉째,
Logical Design(Data중심)과 Physical Design(사용하는 DBMS, System 중심)을 완전히 분리할 것
? Summary Table은 Relationship으로 표시가 불가하다.
(Logical Data Modeling에서는 표시가 안됨)
? Physical개념 : Processing 개념
열째,
엔티티-관계도 (ERD)를 작성시 Top-Down과 Bottom-up을 병행하면서 진행한다. 왜냐하면 Entity의 분할과 Attribute의 상세한 define이 발생하기 때문이다.
열한째,
엔티티-관계도 작성시 선택성(Optionality)을 구분해줄 필요가 있으나 치명적이지 않다.

'삽질로그' 카테고리의 다른 글

나만의 UCC 사이트 구축하기  (0) 2008.12.26
Toad DBA Suite 사용후기 - Toad Data Modeler[TDM] 리뷰  (0) 2008.11.28
데이터모델링  (0) 2008.11.28
자바스크립트로 UI 구현하기  (0) 2008.10.11
검색의 혁명 Search 2.0  (0) 2008.09.24
GDB 사용하기  (0) 2008.04.17
Jack Slocum란 분이 야후의 yui((Yahoo! UI library)를 확장하여 만든 자바스크립트 라이브러리인데 자주 사용되는 기능들 거의 다 있고 아주 막강합니다. 1.0부터는 이름을 Ext JS로 바꾸고 yui에 의존하지 않고 개발을 진행할 예정인것 같습니다.

단, 아직 개발중이라 변경이 많아서 실무에 적용하기 좀 어려운것 같습니다. 그러나 자바스크립트로 웹UI개발을 하는 개발자분이시면 예제만 보셔도 개발에 많은 도움이 될것 같아서 이렇게 올립니다.

개발자 블로그: http://www.jackslocum.com/

문서와 예제: http://www.yui-ext.com/deploy/yui-ext/docs/

공식 사이트: http://www.extjs.com/ (첫페지만 달랑, 현재 공사중인것 같습니다.^^)

1.0 Alpha 3 - Rev 2 다운로드: http://www.yui-ext.com/deploy/ext-1.0-alpha3.zip

1.0 Alpha 3 - Rev 2 문서: http://www.yui-ext.com/deploy/ext-1.0-alpha3/docs/
 
 

'삽질로그' 카테고리의 다른 글

Toad DBA Suite 사용후기 - Toad Data Modeler[TDM] 리뷰  (0) 2008.11.28
데이터모델링  (0) 2008.11.28
자바스크립트로 UI 구현하기  (0) 2008.10.11
검색의 혁명 Search 2.0  (0) 2008.09.24
GDB 사용하기  (0) 2008.04.17
레베카프로 드라이버-데탑용 웹캠  (0) 2008.01.22

+ Recent posts