8.관계형 데이터베이스(RDBMS) 이해..http://sqler.pe.kr/에서

<TABLE borderColor=black cellSpacing=0 borderColorDark=white cellPadding=4 borderColorLight=black border=1> <TBODY> <TR> <TD width=446> 1. 정보환경 들어가기 전에</TD></TR> <TR> <TD width=561>   오래간만에 강좌를 적네요. 뭐가 그리도 바쁜지 이리저리 뛰어다니느라 정말 정신이 하나도 없었습니다. 　 이번에 소개해 드릴 내용은 정보환경과 데이터베이스 설계라는 내용의 글입니다. 사실 이 부분의 글을 적을지 말지 대단히 많이 고민을 했답니다. 　 대부분의 SQLER 님들이 생각하는 모델링은 대단히 많은 기본 지식과 경험적인 부분이 필요한 부분 입니다. 말그대로 짬밥이 모든걸 해결해 주는 부분이지요. 예를들어 이런 부분을 생각해 보도록 하지요. 동호회 서비스를 만든다고 생각해 보도록 하지요. - 설마 동호회가 뭔지 모르시는 분은  없겠죠. 이때.. 동호회가 만개가 생길지 단 백개가 생길지 예측하기가 대단히  힘들어 집니다. 이때 동호회별로 여러개의 게시판 또는 자료실을 생성할 수 있는데요. 각각의 게시판 또는 자료실을 1개의 테이블로 생성할 수 있지요. - 맞습니다. 사실 SQL서버의 테이블 최대 갯수는 몇개인가를 가끔 물어 보시는 분들이 계신데요. 그 답은 논리적으로 9000경 정도까지 커버가 가능하다고 합니다. 하지만 대부분 이런 식으로 동호회 등을 개발하신다면 추후 유지 관리가 대단히 힘들어 지지요. 다른 방법으로 카테고리 별로 각각 1개씩의 게시판과 자료실을 만들고 구분하기 위한  컬럼을 하나 더 추가해 처리하는 방법도 얼마든지 있을 수 있지요. 이야기가 길어 졌지만.. 디자인이라는 부분은 실제 세계를 테이블과 컬럼과 로우의  데이터로 표현하는 한 방법 입니다. 문제는 적절하게 잘 반영할 수 있는가. 아울러 원하는 비지니스 프로세스를 모두 적용할 수 있는가 입니다. 　 하지만.. 주변을 둘러 보면서.. 많은 개발자 분들이 이런 디자인 적인 요소를 제대로  사용하지 못하고 어찌보면 주먹구구식의 개발 단계를 거쳐.. 대단히 많은 시간을  디버깅에 소모하는 모습을 많이 보았습니다. 트리거나 뷰.. 등등의 땜질 작업으로  근근히 돌아가게 유지하는 것이지요. 또한 대부분의 클라이언트들과 이야기를  할때는 더더욱 힘들 수 있습니다. 참조 제약등을 적절히 잘 이용할 경우는 물론 데이터의 무결성을 잘 보상 받을 수 있지만 자칫 실수를 해서 정확한 순차로 데이터를 넣지 않거나 참조 제약을 위배하는 값을 넣으려 할 경우 대단히 많은 에러를 겪을 수 있습니다. 특히나 SQL서버와 같은 관계형 DBMS에 익숙하지 못할 경우 더더욱 문제를 겪게 되지요. 이런 상황을 개발 작업을 해본적 없는 실제로 돈을 가지고 있는 클라이언트가 볼 경우 이해를 하지 못하게 됩니다. 개발은 자꾸 늦어지는 듯 하고.. 에러는 자꾸 나서 값은 잘 안들어 가고..  냠냠.. 　 말이 조금 길어 지는듯 하군요.  하지만 데이터베이스 디자인은 대단히 중요하며 크리티컬 합니다. 많은 경험을 가지고 하나씩 시도해 보시면 언젠가 결실을 분명히 맺으시리라 생각 합니다. 　 실제 개발상황에서의 디자인을 간략히 말씀 드리면.. 코난이는 대단히 "기획서"라는 장치에 의지 합니다. 가끔 이런 케이스가 있지요.. "저는 모사의 누구라고 합니다. (명함한장, 메모한장 건네줌 - 메모 내용 국내 유수의  사이트 몇개 적혀 있음) 이런 식과 같은 사이트를 만들려고 하는데요. "   라는 말을 듣습니다. 사실 현재의 국내 상황으로 볼때.. 대부분 개발을 해본적 없는 사람들이 아마도 여러분,  또는 여러분 회사의 클라이언트 일 겁니다. 돈은 그들이 가지고 있으니 할말 없지요.  그럼 저는 샘플 기획서를 보여주면서.. "이런이런 식으로 다시 만드세요." 라고 말합니다. 　 리스트 박스의 내용에 뭐가 들어가는지.. 검색의 조건에서 토씨 하나하나까지 다 체크하고 이런 기능을 할 것이다 라고 완전히 픽스가 되면 작업을 시작 하지요. 이때.. 기획서를 보고 디자인을 시작하게 됩니다. 전체 기획서 상의 모든 내용을 적용할 수 있도록.. 디자인에 실패하게 되면 대단히 많은 부분을 바꿔야 하므로 매우 조심스럽고 확실하게 작업이  되어야 하지요.  예를들어 1:1 로 매핑되던 두개의 테이블을 간단히 합쳐서 한개의 테이블로 만든다면 이 작업은 아무것도 아닐지 모르나.. 코딩 부분에서 대단히 많은 부분을 바꿔야 하는  난관을 겪게 됩니다.  간단히 생각해도 삭제, 수정, 삽입, 조회 루틴별로 각각 모두 수정이 있어야 하니 대단히 짜증이 날 수 있는 부분이지요. 이런 부분을 최소화 하기 위해 기획서를 받고 바로 DB 디자인 작업을 화면 디자인 작업과 함께 진행하고 이어서 ASP 코딩 등으로 디자인된 DB와 화면을 붙이는 작업을 하게 되지요. 물론 화면 디자인 역시 OK가  떨어진걸 해야 겠지요. 만약 ASP작업이 미리 들어갔다면.. 화면이 바뀌면서 역시나 ASP와 같은 코딩역시 바뀌게 되니 매우 조심스러워 지지요.  초기에 가장 힘든건 DB와 디자인이고.. 마지막에 힘든건 ASP등과 같은 어플 개발 팀이지요.. 냠.. 　 아.. 대단히 주절주절 떠들어 댔군요....   자 이만 주절주절을 끝내고.. 디자인에 대한 이야기를 풀어 나가도록 하지요. 참고로 이하 내용들은 SQL7 기본강좌의 내용과 거의 같다고 보셔도 됩니다. 많은 도움 되시길 바랍니다</TD></TR></TBODY></TABLE> ********************************************************************* <TABLE borderColor=black cellSpacing=0 borderColorDark=white cellPadding=4 borderColorLight=black border=1> <TBODY> <TR> <TD width=446> 2. 오늘날의 정보환경</TD></TR> <TR> <TD width=561>   사실 이부분은 MSSQL7 기본강좌의 내용과 비슷하다고 보시면 됩니다. 이전 강좌를 읽어보신분들은 그냥 부담없이 읽으시길 바라구요. 　 DB(DBMS)를 잘한다라는 기준이 무엇일가요..? 오라클이나 MSSQL서버를 잘 사용하면 DB를 잘한다라는 기준에 들어가는 걸가요? 제 대답은 "아니다"라는 겁니다... 비주얼 스튜디오 툴을 완전히... 첨부터 끝까지... 꿰고 있다고 해서 프로그래밍을 잘한다... 라는 말을 듣는건 아닐겁니다... .................................. 제가 하고싶은 말은요........... 내공을 쌓아야 한다........ 라는 겁니다.. ^_^ 내공을.... 쌓아야 대는데............   DB개론 강좌입니다. 개략적으로 한번 살펴 보시고 숙지하시길 바랍니다.   <HR> 정보환경 목차 데이터 vs. 정보 정보 처리 시스템 정보 처리 시스템 구조 정보 처리 시스템 종류 정보 처리 시스템 형태   <HR> 데이터 vs. 정보 데이터(Data)란 ? 현실 세계로부터 단순한 관찰이나 측정을 통해서 수집된 사실(facts)이나 값(value) (이석호) 정형화되고 기록될만한 가치가 있다고 판단되는 현실 세계의 어떤 현상이나 사건에 대한 묘사   정보(Information)란 ? 어떤 상황에 대한 적절한 의사 결정을 할 수 있게 하는 지식(knowledge)으로서, 데이터의 유효한 해석(interpretation)이나 데이터 상호간의 관계(이석호)   <HR> 정보 처리 시스템 정보 처리 시스템이란? 조직이나 개인이 필요로 하는 정보를 제공하는 시스템으로서, 데이타베이스와 DBMS, 이들을 이용하는 응용 프로그램 및 지원 소프트웨어로 이루어진 시스템   정보 처리 시스템 구조 <IMG height=297 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fwww.sqler.pe.kr%2Fsqllec%2Fimages%2F%EC%A0%95%EC%B2%98%EA%B5%AC%EC%A1%B0.jpg" width=450 border=1> 　 <HR>   정보 처리 시스템 종류 의사 결정 지원 시스템(Decision Support System) 지식 베이스 시스템(Knowledge based system) 전문가 시스템(Expert system),경영자 정보 시스템(Executive Information System:EIS) OLAP시스템. 　 응용 시스템 ( Application System) 도서관, 항공기 예약, 은행 시스템 등 응용범위는 실로 무궁무진 하지요...  　 <HR>  정보 처리 시스템 형태 (1) 처리 시점에 따라 일괄 처리 시스템 사전 준비 작업 후 처리 높은 시스템 성능, 낮은 처리 비용 요구 온라인 처리 시스템 실시간 처리 낮은 시스템 성능, 높은 처리 비용 요구 고속 자료수집 시스템, 미사일 유도 시스템 전화 교환 시스템, 환자 감시 시스템,  Etc.   　 <HR>   정보 처리 시스템 형태 (2) 처리 형태에 따라 중앙 집중 시스템(Centralized system) 작업 처리의 통합 관리가 용이 대규모 일괄 처리 방식에서 유리 지리적으로 분산되어 있는 데이터에 대한 처리가 어려움 분산 시스템(Distributed system) 지리적으로 분산되어 있는 상황에서 유리 각 지역은 로컬하게 작업 수행 여러 지역의 데이터가 필요한 경우에는 분산 처리기가 다른 지역의 데이터를네트웍을 통해  전송해 옴 분산 처리를 위한 많은 장치가 필요 　 <HR>   정보 처리 시스템 형태 (3) <IMG height=337 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fwww.sqler.pe.kr%2Fsqllec%2Fimages%2F%EC%A0%95%EC%B2%98%ED%98%95%ED%83%9C.jpg" width=450 border=1> 　 <HR>   정보 처리 시스템 형태 (참고)   <TABLE borderColor=#ffffff cellSpacing=0 borderColorDark=#ffffff cellPadding=5 borderColorLight=#000000 border=1> <TBODY> <TR> <TD width=179>  </TD> <TD width=179>  2Phase Commit      </TD> <TD width=179>   Replication</TD></TR> <TR> <TD width=179> 일관성</TD> <TD width=179>  Tight(엄격)  </TD> <TD width=179>  Loose(느슨)</TD></TR> <TR> <TD width=179> 분산트랜젝션</TD> <TD width=179> 가능</TD> <TD width=179> 불가능</TD></TR> <TR> <TD width=179> 동시수정</TD> <TD width=179> 가능   </TD> <TD width=179> 불가능   </TD></TR> <TR> <TD width=179> 서버부하</TD> <TD width=179> 많음</TD> <TD width=179> 적음</TD></TR> <TR> <TD width=179> 확장성 / 유연성</TD> <TD width=179> 보통  </TD> <TD width=179> 높음</TD></TR></TBODY></TABLE>        　 <HR>   정보 처리 시스템 형태 (참고) <IMG height=265 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fwww.sqler.pe.kr%2Fsqllec%2Fimages%2F%EC%B0%B8%EA%B3%A01.jpg" width=500 border=1> 　</TD></TR></TBODY></TABLE> ************************************************************************** <TABLE borderColor=black cellSpacing=0 borderColorDark=white cellPadding=4 borderColorLight=black border=1> <TBODY> <TR> <TD width=446> 3. 왜 DBMS인가.</TD></TR> <TR> <TD width=561> 　 그렇다면.. 왜 비싼 돈을 들여서 DBMS을 구입하고 힘들게 어플리케이션을 제작해 사용을 할까요? ^_^ 여기서 그 해답을 함 차자 보세요.. 　 목차 화일 & 화일 시스템 데이타베이스 시스템 <UL> 데이터베이스 데이타베이스 관리 시스템 데이타베이스 언어 데이터베이스 관리자 데이타베이스 기계</UL> 　 <HR>   Why File? 데이터의 집합을 왜 파일로 구성하는가? <UL> 데이터량이 너무 많다. 데이터 집합 전부를 주기억장치에 적재할 필요가 없다 데이터의 독립성을 유지한다.</UL> 종류 <UL> 마스터 파일(master file), 트랜잭션 파일(transaction file), 보고서 파일(report file),프로그램 파일(program file), etc.</UL>   <HR> 화일 & 화일 시스템 파일(File) <UL> 물리적 비트들의 연속 (사용자 측면) 서로 다른 언어에서 각각의 화일 연산자를 이용하여 조작.   예) in C, fread, fwrite, etc  </UL> 화일 시스템 <UL> 응용 프로그램은 논리적 화일 구조와 물리적 화일 구조가 일 대 일로 대응되어야 한다. 응용 프로그래머는 물리적 데이터 구조에 대해 잘 알고 있어야 한다. 한 화일은 서로 다른 시스템 간에 공유가 안되어, 특정 응용 프로그램에서만 사용 가능하다.</UL>   <HR> 화일 & 화일 시스템 : 구조 <IMG height=226 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fwww.sqler.pe.kr%2Fsqllec%2Fimages%2F%ED%99%94%EC%8B%9C%EA%B5%AC%EC%A1%B0.jpg" width=400 border=1>  이렇게 깔끔한 방식이면 좋겠지요? 하지만.. 문제가 아주 많이 발생해 버린답니다.... <HR> 화일 & 화일 시스템 : 문제점 (1) 데이터의 종속성(Data Dependency) <UL> 응용 프로그램과 데이터 간의 상호 의존 관계 데이터의 구성 방법이나 접근 방법을 변경하면 응용 프로그램도 함께 변경되어야 함</UL> 데이터의 중복성(Data Redundancy) <UL> 내용이 같은 데이터가 여러 곳에 저장, 관리되는 것 데이터의 일관성, 보안성, 경제성, 무결성을 만족시키지 못함</UL>   <HR> 화일 & 화일 시스템 : 문제점 (2) <IMG height=336 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fwww.sqler.pe.kr%2Fsqllec%2Fimages%2F%ED%99%94%EC%8B%9C%EB%AC%B8%EC%A0%9C.jpg" width=450 border=1>  아주 적나라 하지요.. -_-;;; 그럼 이러한 화일 시스템의 문제의 해결방안은 어떤게 있을까요? <HR> 화일 시스템 : 해결책 - FMS(1) 화일 관리 시스템 사용(File Management System) <UL> 여러 응용 프로그램들이 사용하는 모든 데이터 화일들에 대한 공동 접근 루틴을 제공 문제점 <UL> 같은 데이타에 대해 각 응용 프로그램이 요구하는 서로 다른 형태의 데이터 구조를 지원하지 못함. 같은 구조의 데이터 파일을 서로 다른 응용프로그램에서 사용하기 위해서 데이터를 복제. => 데이터의 중복성       (저장공간의 낭비, 데이터의 불일치 문제)</UL></UL>   <HR> 화일 시스템 : 해결책 - FMS(2) <IMG height=312 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fwww.sqler.pe.kr%2Fsqllec%2Fimages%2F%ED%99%94%EC%8B%9C%ED%95%B4%EA%B2%B0.jpg" width=450 border=1>  바로 화일 관리 시스템 이라는 공통의 접근 루틴을 두는 방법 입니다. 그러나... 과연 완벽할까요? <HR> 화일 시스템 : 해결책 - DBMS(1) 데이타베이스 관리 시스템(DBMS) 사용 <UL> 응용 프로그램들과 데이터의 중재자로서의 역할을 수행하는 소프트웨어 시스템 화일 관리 시스템이 해결하지 못한 모든 문제점(데이터의 종속성과 중복성)을 해결하기 위해 등장 화일이 아닌 데이타베이스에 대한 연산 수행</UL>   <HR> 화일 시스템 : 해결책 - DBMS(2) <IMG height=338 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fwww.sqler.pe.kr%2Fsqllec%2Fimages%2F%ED%95%B4%EA%B2%B0db.jpg" width=450 border=1>  어떠신지요? 아주 예날의 방법이긴 하지만... 어느정도 그림이 좋아진듯 합니다. ^_^ 좀더 알아보도록 할까요? <HR> 데이타베이스 시스템 (DBS) 데이터베이스(Database) 데이타베이스 관리 시스템(DBMS) 데이터 언어(Data language) 사용자(Users) 데이타베이스 관리자(DBA) 데이타베이스 기계(DB Machine)   구성하는 요소가 많은듯 합니다. 저희가 알아가야할 DBMS의 구성 요소들 이지요... 많은듯 하지요?  언제나 그렇듯 누구나 처음은 있다고 생각 합니다. 힘내시구요.. ^_^ <HR> 데이타베이스 시스템 : 구조 <IMG height=309 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fwww.sqler.pe.kr%2Fsqllec%2Fimages%2FDb%EC%97%90%EC%84%9C.jpg" width=450 border=1>  구조를 조금 편히 보실 수 있으실 겁니다. 대략적인 느낌이 오시지요? ^_^ <HR> DBS : 데이타베이스 - vs. 파일 화일 vs. 데이터베이스 <UL> 파일(File) <UL> 물리적 비트들의 연속 (사용자 측면) 서로 다른 언어에서 각각의 화일 연산자를 이용하여 조작 가능 in C, fread, fwrite, etc</UL> 데이터베이스 <UL> 논리적 구조의 데이터의 집합 (사용자 측면) 표준 언어를 이용하여 데이터 조작 가능 use SQL</UL></UL> 　 비교아닌 비교 입니다.... 코난이가 생각하는 데이터의 무결성이라면 어떨까요? 물론 DB이겠지요... 그렇다면 속도는 어떨까요? 물론 파일 시스템 입니다. 좀더 욕심을 부려서... 화일시스템만큼의 속도를 가지는 무결성을 보장받는 DB는 어떨까요? 제가 욕심이 너무 많은 건가요? ^_^ <HR> DBS : Database - 정의 어느 한 조직의 여러 응용 시스템들이 공용할 수 있도록 통합, 저장된 운영 데이타의 집합 (이석호) <UL> 통합된 데이터, 저장된 데이터, 운영 데이터, 공용 데이터</UL> An integrated collection of persistent data representing the information of interest for various programs that compose the computerized information system of an organization[Atzeni & De Antonellis]   그냥 이런거구나.. 라고 흘려 들으셔도 좋습니다. ^_^ <HR> DBS : Database - 특징 실시간 접근성(Real-time accessibility) <UL> 사용자의 요구에 대한 즉각적인 응답(Response)</UL> 계속적인 변화(Continuous evolution) <UL> 삽입,삭제,갱신 작업이 수시로 발생</UL> 동시 공용(Concurrent sharing) <UL> 여러 사용자가 동시에 자기가 원하는 데이터에 접근 가능</UL> 내용에 의한 참조(Content reference) <UL> 물리적 주소가 아닌, 데이터에 대한 조건으로 원하는 결과를 검출</UL>   인터넷상의 게시판을 생각해 보세요... 게시물을 볼때 실시간으로 보여 주지요? 누구나 글을 적을수 있지요? 누구나 동시에 사용이 가능하지요? 게시물 찾기를 할때... 01번 하드디스크 섹터 FEFF의 데이터를 차자라.. 라고 하나요? 글중에서 원하는 단어가 있는지.. 등으로 검색 하시나요? 중요한 특징이었답니다... <HR> DBS : Database - 스키마(1) 스키마 : 데이타베이스의 논리적 정의 3단계 스키마 외부 스키마(External schema) <UL> 각 사용자의 입장에서 본 데이타베이스 구조 사용자마다 서로 다른 데이타베이스 스키마를 가짐 개념 스키마에 대한 서브스키마(subschema)</UL> 개념 스키마(Conceptual schema) <UL> 조직 전체의 입장에서 본 데이타베이스 구조 한 개의 스키마만 존재하며, 서로 다른 사용자가 공유 데이터 객체(개체,관계), 제약조건에 대한 명세를 유지</UL>   스키마라는 단어를 그냥의 의미는 개념  내부 스키마를 의미한답니다. 테이블이나 테이블간의 관계, DB내부 객체들을 통틀어 보통 스키마라고 말을 하는 거지요.... 일반적일 뿐입니다. 실제로는 이 3가지 입니다. 이후 코난이가 스키마를 말씀드려도 그냥 개념스키마구나.. 라고 편히 생각해 주세요.. ^_^ <HR> DBS : Database - 스키마(2) 3단계 스키마(계속) 내부 스키마(Internal schema) <UL> 저장 장치의 입장에서 본 데이타베이스 구조 각 데이터 객체의 저장 구조를 표현함 <UL> 내부 레코드의 형식 인덱스의 유무 저장 데이터 항목의 표현 방법</UL></UL>   <HR> DBS : Database - 스키마(3) <IMG height=312 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fwww.sqler.pe.kr%2Fsqllec%2Fimages%2F%EC%8A%A4%ED%82%A4%EB%A7%881.jpg" width=450 border=1>  아주 잘 표현된 그림 이지요? ^_^ 외부스키마 , 개념 스키마 , 내부 스키마... 잘 구분이 되셨음 합니다... 　 <HR> DBS : DBMS - 정의 사용자와 데이터베이스 사이에 위치하여 사용자의 요구에 따라 데이터베이스를 조작하고 제어하는 기능을 제공하는 소프트웨어 <UL> => Data + Hardware + Software + User</UL> 구성 요소 : 질의 처리기, 트랜잭션 처리기, 저장 관리자, 동시성 제어자, 버퍼 관리자 등.   아주 중요한 부분 입니다... 이곳에서 한가지만 제외가 된다면... DBMS라고 할수가 없다라는 겁니다. 예를 들어.. 리눅스용 MySQL입니다. 코난이는 개인적으로 MySQL 팬이랍니다.. 하지만 그 한계 입니다... MySQL은 트랜젝션을 지원하지 않습니다. 데이터 무결성을 보장받을 수 없으며... 트랜젝션을 이용한 어떤 작업도 사용이 불가하다라는 의미 입니다. 온라인 트랜젝션, 트리거, Transactional 복제...  등등등.... 그 편리성과 속도로는 인정받을수 있더라도... DB이지 DBMS라고는 할수가 없답니다... 하지만 MySQL과 리눅스 기술은 계속 발전하는 중입니다. http://<A href="http://www.mysql.org/">www.mysql.org</A> 를 가보시면... TODO에 트랜젝션의 지원등... 많은 목표를 세워두고 있답니다... 여하간... 정확히 사용하고자하는 업무의 분석으로 어떤 DBMS의 기능이 필요한가.. 그리고 어떤 DBMS나 DB를 사용할 것인가를 명확하게 판단하셔야 합니다. 　 <HR> DBS : DBMS - 기능 정의 기능 <UL> 데이타베이스의 논리적, 물리적 구조를 정의할 수 있는 기능 제공</UL> 조작 기능 <UL> 사용자가 데이타베이스 내의 데이터를 조작할 수 있도록 하기 위한 기능 제공</UL> 제어 기능 <UL> 데이타베이스가 항상 정확하고 올바른 데이터를 유지하도록 하기 위한 기능 제공</UL>   당연한듯 하지만 이부분에서 DBMS선택에 많은 차이가 있습니다. 가격대가 결정이 된다라는 점이지요... 특히 +1을 한다면.. 바로 사용자 인터페이스 입니다. 항상 텔넷 화면과 같은 텍스트 화면만 보인다면... 힘들겠지요... 좀더 그래픽 유저 인터페이스라면?  좀더 가치가 있다.. 라는 의미 입니다. <HR> DBS : DBMS - 장점 데이터 중복의 최소화 데이터의 공용성 증대 데이터의 일관성 유지 데이터의 무결성 유지 데이터의 보안 보장 범기관적 표준화 가능 　 <HR> DBS : DBMS - 단점 운영비 증대 : 많은 시스템 자원 요구 자료 처리의 복잡화 : 고급 프로그래밍 요구 복잡한 예비와 회복 : 장애 발생 대비를 위한 작업 필요 시스템의 취약성 : 시스템의 성능에 따라 DBMS 성능이 좌우됨   <HR> DBS : Data Language - 정의 데이터베이스를 정의,조작,제어하기 위하여, 사용자와 데이터베이스 시스템 간에 사용하는 통신 수단 종류 <UL> 데이터 정의어(DDL) 데이터 조작어(DML) 데이터 제어어(DCL)</UL> 예) MSSQL서버의 T-SQL, 오라클의 SQL PLUS ...   <HR> DBS : Data Language     - Data Definition Language 데이터베이스 스키마를 정의하거나 수정하기 위해 사용하는 언어 데이터 객체와 객체들간의 관계, 제약들을 함께 표현 정의된 내용은 시스템 사전에 등록됨   <HR> DBS : Data Language     - Data Manipulation Language 데이터베이스 내의 데이터에 대한 연산을 위한 언어 데이터 삽입/삭제/갱신 작업이 가능 종류 <UL> 절차적 데이터 조작어. (What + How) 예) 관계형 대수 비절차적 데이터 조작어. (What) 예) 튜플 관계형 해석, 도메인 관계형 해석</UL>   가장 많이 싸우게될 부분 입니다. 이 부분이 배울 내용의 80% 정도가 된다고 보심 됩니다. <HR> DBS : Data Language     - Data Control Language 데이터베이스 내의 데이터를 올바르고 정확하게 유지하기 위한 언어 데이터 무결성, 보안성, 회복 등에 대한 작업이 가능 주로 DBA에 의해 사용됨   <HR> DBS : Users 일반 사용자 <UL> 질의어를 통한 단순한 데이터 검색,삽입,삭제,갱신 작업을 수행하는 사람</UL> 응용 프로그래머 <UL> 여러 형태의 언어와 데이터 조작어를 이용하여 데이터베이스를 접근하는 사람</UL> 데이터베이스 관리자 <UL> 데이터베이스의 관리에 대한 모든 책임을 지고 있는 사람</UL>   <HR> DBS : DBA 데이터베이스 설계와 운영 <UL> 데이터베이스 구성 요소 결정, 스키마 정의, 저장 구조와 접근 방법 설정, 보안 및 권한 부여 정책 결정, 백업, 회복 절차 수립 등의 작업 수행</UL> 행정 및 불평 해결 <UL> 사용자의 요구를 받아 분석하고 불만을 해소시킴</UL> 시스템 감시 및 성능 분석 <UL> 시스템 이용도, 병목 현상, 이용 패턴, 데이터 사용 추세, 각종 통계 등의 분석 작업 수행</UL>   보통 DB 관리자로 불리지요... <HR> DBS : DB Machine 데이터베이스 시스템의 성능을 향상시키기 위해 사용하는 후위 컴퓨터 대용량의 데이터에 대한 빠른 처리를 위해 사용됨</TD></TR></TBODY></TABLE> **************************************************************************** <TABLE borderColor=black cellSpacing=0 borderColorDark=white cellPadding=4 borderColorLight=black border=1> <TBODY> <TR> <TD width=446> 4. 관계형 모델이란?</TD></TR> <TR> <TD width=561> 　 코난이가 첨 DB를 접하면서 해맨 부분 이랍니다. 왜 관계란 녀석이 필요한가? 이녀석을 어디다가 써먹는가.... 어떻게 설정하는가? 이런 문제 랍니다. 무엇보다 개념이 중요한 부분이며.... 배울 부분에서 많은 비중을 차지하니... 정확히 봐 두시길 바랍니다. 　 목차 관계형 데이터 모델이란? 관계 데이터 구조 관계 데이터 제약 관계 데이터 연산 　 <HR> 관계형 데이터 모델이란? E.F.Codd <UL> “a Relational Model of Data for Large Shared Data Banks.” Communications of the ACM</UL> 테이블(Relation:관계)의 집합 <UL> ‘테이블, 행’ => ‘릴레이션, 튜플’</UL> Relation이라는 한 개의 구조만을 이용 Physical data independence 수학적이론 기반   말은 간단합니다... 테이블 , 컬럼 들과 같은 DB객체에 관계를 정의해 DB의 무결성과 성능을 높이자.. 라는 부분 입니다. 　 사실 수학적인 정의 부분이나... 컬럼, 도메인, 등의 말이 생소할 분도 계실 겁니다. 테이블, 필드, 레코드... 등의 단어에는 익숙하시겠지만요... 코난이가 드릴 딱 한가지는... 액세스나 기타 유저분들은... 필드 -> 컬럼 레코드 -> 로우  이정도는 반드시 기억해 두셔야.. 추후 문제가 없답니다. 다른 개념들은 다 잊어버리셔도... 요 두가지만은 꼭 숙지 하시길 바랍니다. 　 <HR> 관계 데이터 구조 애트리뷰트와 도메인 릴레이션의 개념 <UL> 릴레이션 릴레이션 스킴 릴레이션 인스턴스</UL> 릴레이션의 특성 관계 데이터베이스   　 <HR> 애트리뷰트와 도메인 애트리뷰트(attribute) <UL> 도메인의 역할 이름 한 릴레이션에서의 애트리뷰트 이름은 유일</UL> 도메인(domain) <UL> 애트리뷰트가 가질 수 있는 값들의 집합 단순 도메인(simple domain) <UL> : 원자값</UL> 복합 도메인(composite domain) <UL> (예) 날짜 : 연+월+일의 조합</UL></UL>   　 <HR> 릴레이션의 개념(1) 수학적 정의 <UL> 릴레이션 R: 주어진 도메인들의 카티젼 곱(cartesian product)의 부분집합 <IMG height=42 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fwww.sqler.pe.kr%2Fsqllec%2Fimages%2Fr1.JPG" width=350 border=1></UL> 　 개념적 정의 릴레이션 스킴 + 릴레이션 인스턴스   　 <HR> 릴레이션의 개념(2) 릴레이션 스킴(relation scheme) <UL> 데이터베이스의 논리적 설계를 의미 프로그래밍 언어의 형 정의 개념에 대응 정적 성질 : 시간에 무관 속성과 그 속성에 대응하는 도메인들의 리스트 이름 : 릴레이션 이름 + 애트리뷰트 이름</UL>   　 <HR> 릴레이션의 개념(3) 릴레이션 인스턴스 <UL> 일정시간에 데이터베이스내에 들어있는 데이터 어느 한 시점에서 릴레이션이 포함하고 있는 튜플들의 집합 동적 성질 <UL> 삽입, 삭제, 갱신 시간에 따라 변함 특정 릴레이션의 값</UL></UL>   　 <HR> 릴레이션의 특성 튜플의 유일성 <UL> 릴레이션 = 서로 다른 튜플들의 집합</UL> 튜플들의 무순서 애트리뷰트들의 무순서 애트리뷰트의 원자값 <UL> 분해불가능 복합도메인 : 값을 하나의 단위로 취급</UL>                      (예) Date Type   　 <HR> 릴레이션 데이터베이스 시간에 따라 그 내용(상태)이 변할 수 있는 데이터베이스를 릴레이션(테이블)으로 표현 관계 데이터베이스와 파일 시스템의 비교 <UL> 관계 데이터베이스    <->      파일 시스템 릴레이션        <->           파일 튜플           <->            레코드 애트리뷰트       <->          필드</UL>   　 <HR> 릴레이션 데이터베이스(예) 대학 관계 데이터베이스 <IMG height=259 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fwww.sqler.pe.kr%2Fsqllec%2Fimages%2F%EA%B4%80%EA%B3%84%EB%8C%80%ED%95%99.jpg" width=450 border=1> 　 　 <HR> 관계 데이터 제약 기본키 외래키 무결성제약 <UL> 개체 무결성 참조 무결성</UL>   이 제약이 약간 골치지요.... 처음 등장하니... 세세히 꼭 읽어 보세요... 　 <HR> 기본키(primary key) 각 튜플을 유일하게 식별할 수 있는 애트리뷰트 하나 또는 하나이상의 구성 후보키 중에서 최소성을 가지는 키 Null값을 가질 수 없음   　 <HR> 외래키(foreign key) 릴레이션 R1과 R2가 있을 때 릴레이션 R1에 속한 애트리뷰트(의 조합)가 참조릴레이션 R2의 기본키인 것 R1과 R2가 반드시 다를 필요는 없음 외래키와 참조 기본키의 도메인은 동일 <IMG height=36 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fwww.sqler.pe.kr%2Fsqllec%2Fimages%2Fr1r2n.JPG" width=200 border=1> <IMG height=56 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fwww.sqler.pe.kr%2Fsqllec%2Fimages%2FR1r2.jpg" width=450 border=1> <IMG height=41 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fwww.sqler.pe.kr%2Fsqllec%2Fimages%2Fr1r2rr.JPG" width=230 border=1> <IMG height=29 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fwww.sqler.pe.kr%2Fsqllec%2Fimages%2Fr1r21.JPG" width=450 border=1>   　 <HR> 무결성 제약 개체 무결성 <UL> 기본키 값은 언제 어느때고 Null일 수 없다.</UL> 참조 무결성 <UL> 외래키 값은 참조 릴레이션에 있는 기본키값과 같아야 한다. 외래키 값은 널일 수 있다.</UL> 무결성 제약의 유지 <UL> 시스템이 자동적으로 수행</UL>   무결성의 제약 입니다. 아주 난해하게 설명 되어 있지요? 찬찬히 배워 나가실 부분 입니다... 저말이 무엇인지는 강좌의 맨 처음 말 드렸듯이... 그러려니.. 하고 숙지만 하시길 바라구요... 　 <HR> 관계 데이터 연산 관계 대수란? 일반 집합 연산자 순수 관계 연산자 관계 대수의 질의문 표현   　 <HR> 관계 대수 릴레이션 조작을 위한 연산의 집합 폐쇄성질(Closure property) <UL> 피연산자와 결과가 모두 릴레이션 중첩된 수식의 표현이 가능</UL> 구성 : 릴레이션과 연산자 <UL> 일반집합 연산자 <UL> 합집합, 교집합, 차집합, 카티션 프로덕트</UL> 순수관계연산자 <UL> 셀렉트, 프로젝트, 죠인, 디비젼</UL></UL>   　 <HR> 일반집합 연산자(1) <IMG height=206 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fwww.sqler.pe.kr%2Fsqllec%2Fimages%2F%ED%95%A9%EC%A7%91%ED%95%A9.jpg" width=300 border=1>  그냥 보고 넘어가셔도 무방합니다. 수학과나... 자연계열 이시라면.. 아주 눈에 팍팍 들어 오실듯.... 　 <HR> 일반집합 연산자(2) <IMG height=213 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fwww.sqler.pe.kr%2Fsqllec%2Fimages%2F%ED%95%A9%EC%A7%912.jpg" width=400 border=1>  역시나.. 그러려니... 하고 보시길 바랍니다. <HR> 순수 관계 연산자(1) <IMG height=263 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fwww.sqler.pe.kr%2Fsqllec%2Fimages%2F%ED%95%A93.jpg" width=400 border=1>  수학과 분들은.. 아마 기분 좋으실듯... 엄청 해맸답니다... T.T 다시 그때의 악몽이 되살아 나는듯... 　 <HR> 순수 관계 연산자(2) <IMG height=139 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fwww.sqler.pe.kr%2Fsqllec%2Fimages%2F%ED%95%A94.jpg" width=400 border=1>  처음 보시는 분이라도... 그냥 죽죽 넘어가셔도 무방 합니다. 단지 개념일 뿐이니까요... 　 <HR> 관계대수의 질의문 표현 예(1) 모든 학생의 이름과 학과를 보여라. <IMG height=34 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fwww.sqler.pe.kr%2Fsqllec%2Fimages%2F%ED%95%A95.jpg" width=200 border=1> 과목번호가 C413인 과목에 등록한 학생의 이름과 성적은 무엇인가? <IMG height=45 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fwww.sqler.pe.kr%2Fsqllec%2Fimages%2F%ED%95%A96.jpg" width=400 border=1> ‘파일처리’ 과목을 가르치는 교수의 이름은? <IMG height=43 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fwww.sqler.pe.kr%2Fsqllec%2Fimages%2F%ED%95%A97.jpg" width=350 border=1>   　 <HR> 관계대수의 질의문 표현 예(2) 학번이 300, 이름이 ‘김명호’, 학년이 4인 학생을 삽입하라. <IMG height=33 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fwww.sqler.pe.kr%2Fsqllec%2Fimages%2F%ED%95%A98.jpg" width=290 border=1> 과목 ‘데이터베이스’를 삭제하라. <IMG height=45 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fwww.sqler.pe.kr%2Fsqllec%2Fimages%2F%ED%95%A99.jpg" width=380 border=1> 　</TD></TR></TBODY></TABLE> ********************************************************************* <TABLE borderColor=black cellSpacing=0 borderColorDark=white cellPadding=4 borderColorLight=black border=1> <TBODY> <TR> <TD width=446> 5. 데이터베이스 설계</TD></TR> <TR> <TD width=561>   그럼.. 데이터베이스의 계속되는 유지보수와... 데이터베이스의 설계의 단계는 어떻게 될까요? 찬찬히 보도록 하지요... ^_^ 　  목  차 데이터베이스 생명주기 데이터베이스 설계단계 <UL> 요구조건 분석 개념적 설계 논리적 설계 물리적 설계 데이터베이스 구현</UL>   <HR>   데이터베이스 생명 주기 <IMG height=290 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fsqler.pe.kr%2Fsqllec%2Fimages%2FDb%EC%83%9D%EB%AA%85.jpg" width=250 border=1>   보시기에...   느낌이...  끝이 없이 돌아가는 무한 루프 같지요?  ^_^ <HR>   데이터베이스 설계 단계(1) <IMG height=279 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fsqler.pe.kr%2Fsqllec%2Fimages%2F%EC%84%A4%EA%B3%84%EB%8B%A8%EA%B3%84.jpg" width=250 border=1>   설계 역시 마찬가지 이실 겁니다. ^_^ <HR>   데이터베이스 설계 단계(2) 사용자의 요구로부터 데이터베이스 구조를 도출하는 과정 <UL> 데이터 중심(Data driven) 설계 처리 중심(Processing driven) 설계 <UL> 작업 또는 프로세스의 관점과 그들 사이의 정보 흐름의 관점에서의 설계 예) 데이터 흐름도(DFD)</UL></UL>   코난이의 해석은 이러합니다.. 이는 DB 디자이너의 관점과... DB 개발자의 관점이라고 생각 합니다. DB 디자이너는 DB설계를 위해 훈련된 사람입니다. 정규화 기술등... 많은 DB의 룰과 제약을 사용해 잘 구축된 DB스키마를 구축해 내지요.. 아울러 DB개발자는 자신의 DB어플리케이션을 위해 DB를 설계 합니다. 몇개정도의 테이블에 데이터를 막말로 몰아 넣고... 자신의 어플리케이션 처리에 맞추어 DB를 설계해 내지요... 각각 장단점이 있습니다. 디자이너의 DB는 언뜻 복잡해 보이며... 이해에 많은 시간이 소요 될수 있습니다. DB 개발자의 설계는 간단하나 무결성과 중복 데이터 처리에 문제가 있을 수 있습니다. 무엇이 잘된것인가? 정확한 해답은 없다고 생각 하세요... ^_^ 정답을 향해 가고있다고 생각만 하시면 됩니다. <HR>   데이터베이스 설계 단계(2)    : 데이터-처리 결합 방법론 <IMG height=260 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fsqler.pe.kr%2Fsqllec%2Fimages%2F%EB%8D%B0%EB%B0%A9%EB%B2%95%EB%A1%A0.jpg" width=400 border=1>   <HR>   데이터베이스 설계 단계(3) 설계 목표 <UL> 특정 사용자와 응용의 정보 내용 요구를 만족시키는 것 자연스럽고 쉽게 이해할 수 있는 정보 구조를 제공하는 것 처리의 요구 조건과 응답 시간, 처리 시간, 저장 공간 등과 같은 성능 목적을 지원하는 것</UL>   완전한 오너의 요구와... 이해가 쉬운 스키마와... 빠른 속도와... 중복 데이터의 제거... 바로 이것 이지요... ^_^ 　 <HR>   데이터베이스 설계 단계(4) 고려 사항 <UL> 무결성 데이터베이스 내의 데이터에 대한 조작 작업 후에도 데이터가 항상 의미적으로 올바른 값을 가져야 한다. 일관성 저장된 데이터가 항상 물리적으로 올바른 데이터를 가져야 한다. 회복 시스템 고장이 발생했을 때, 고장 직전의 일관된 데이터베이스 상태로 복구할 수 있는 능력이 있어야 한다</UL>   <HR>   데이터베이스 설계 단계(5) 고려 사항(계속) <UL> 보안 고의적 혹은 우발적으로 데이터베이스 내의 데이터를 변경,손실, 노출시키는 것을 막아야 한다. 효율성 사용자의 요구에 대해 실시간의 응답 시간 제공, 저장 공간의 최소화 등 데이터베이스 확장 시스템에 영향을 주지 않으면서 새로운 데이터의 계속적인 추가가 쉬어야 한다.</UL>   <HR>   요구조건 분석 단계 <UL> 정보의 내용과 처리 요구 조건의 수집 응용 분야와 사용자 그룹 식별 업무와 그에 필요한 데이터의 종류, 데이터 용도, 처리 형태, 제약조건, 데이터 흐름, 등에 대한 정보 수집 범 기관적 경영 목표와 제약 조건의 식별 경영 정책, 조직 관리 형태 등을 파악 공식적인 요구 조건 명세의 작성 작업, 데이터, 그들 간의 관계 및 제약 조건 등을 명세 요구 조건 명세의 검토 HIPO, DFDS, Orr-Warnier 다이어그램 등을 사용하여 요구 조건 명세 분석</UL>   좋은 말은 전부 적혀 있는듯 하지요? ^_^ 한두마리가 아닌 모든 토끼를 신중해 생각해 잡아야 하는 고통이 있답니다.. ^_^ <HR>   개념적 설계 (1) DBMS 독립적인 개념 스키마 설계, 트랜잭션 모델링 개념 스키마 모델링 : E-R Diagram을 이용 <UL> 뷰 통합(View integration) 방법 응용이나 사용자 그룹을 기초로 각 부문별 뷰 식별하고 모델링 완성된 뷰 들을 통합하여 하나의 전체적인 스키마로 만듦 애트리뷰트 종합(Attribute synthesis) 방법 애트리뷰트들을 식별해서 분류 애트리뷰트 간의 관계를 파악하여 개체 생성, 관계 생성을 통해 전체적인 스키마 생성</UL>   <HR>   개념적 설계 (2) 트랜잭션 모델링 <UL> 트랜잭션의 입출력과 기능적 형태만 정의 입력 데이터, 출력 데이터, 내부적 제어 흐름 트랜잭션 유형 검색,갱신, 검색&갱신</UL>   <HR>   논리적 설계 (1) 목표 DBMS에 맞는 스키마 설계, 트랜잭션 인터페이스 설계 논리적 데이터 모델로 변환 <UL> 개념 모델링한 것을 반영할 논리 모델을 선택하여 해당 모델의 구조로 변환 논리 모델들 네트웍/계층/ 관계/객체 모델, 객체-관계 모델 관련된 DBMS들 ORACLE, INFORMIX, SYBASE, DB2, MS-SQL ... 설계 결과는 DDL로 기술된 스키마</UL>   <HR>   논리적 설계 (2) 트랜잭션 인터페이스 설계 <UL> 개념적 설계 단계에서 정의한 트랜잭션의 인터페이스를 설계</UL> 스키마의 평가 및 정제 <UL> 생성된 스키마를 정량적 정보와 성능 평가 기준에 따라 평가 정량적 정보 : 데이터의 양, 처리 빈도수, 처리 작업량 등 성능 평가 기준 : 논리적 레코드의 접근, 데이터 전송량, 데이터베이스 크기 등</UL>   <HR>   물리적 설계 목표 DBMS에 맞는 물리적 구조 설계, 트랜잭션 세부 설계 저장 레코드 양식 설계 <UL> 데이터 타입, 값의 분포, 사용될 응용, 접근 빈도를 고려</UL> 레코드 집중의 분석 및 설계 <UL> 레코드 집중 : 함께 접근되는 데이터를 물리적으로 인접한 곳에 순차적으로 저장</UL> 접근 경로 설계 <UL> 접근 경로 : 데이터를 찾아가기 위한 방법 응답시간, 저장 공간의 효율성 등을 고려</UL> DBMS 클래스와 특정 DBMS에 대한 설계의 종속성 <TABLE height=2 cellSpacing=0 cellPadding=0 border=1> <TBODY> <TR> <TD borderColorLight=black width=179 borderColorDark=black height=8> 종속성</TD> <TD borderColorLight=black width=179 borderColorDark=black height=8> DBMS클래스</TD> <TD borderColorLight=black width=179 borderColorDark=black height=8> 특정DBMS</TD></TR> <TR> <TD borderColorLight=black width=179 borderColorDark=black height=8> 개념적 설계</TD> <TD borderColorLight=black width=179 borderColorDark=black height=8> No</TD> <TD borderColorLight=black width=179 borderColorDark=black height=8> No</TD></TR> <TR> <TD borderColorLight=black width=179 borderColorDark=black height=8> 논리적 설계</TD> <TD borderColorLight=black width=179 borderColorDark=black height=8> Yes</TD> <TD borderColorLight=black width=179 borderColorDark=black height=8> No</TD></TR> <TR> <TD borderColorLight=black width=179 borderColorDark=black height=8> 물리적 설계</TD> <TD borderColorLight=black width=179 borderColorDark=black height=8> Yes</TD> <TD borderColorLight=black width=179 borderColorDark=black height=8> Yes</TD></TR></TBODY></TABLE>   <HR>   데이터베이스 구현 목표 DBMS DDL로 스키마 생성 트랜잭션(응용 프로그램) 작성 <UL> 응용 프로그램 작성,컴파일,수행</UL>   설계를 많이 하실 일은 없으실 겁니다... 정말 DB Admin을 원하신담?  다시함 찬찬히 읽어 보세요.. 아울러 학생시절 보셨던 먼지 쌓인 DB개론 책을 꺼내셔셔 찬찬히 다시 보심도 좋은 방법입니다.</TD></TR></TBODY></TABLE> ************************************************************************* <TABLE borderColor=black cellSpacing=0 borderColorDark=white cellPadding=4 borderColorLight=black border=1> <TBODY> <TR> <TD width=446> 5. 데이터베이스 설계</TD></TR> <TR> <TD width=561>   DB를 처음 접하시면서 가장 난해한 부분을 꼽으라면? 바로 이 개론 부분의 설계 입니다. DB설계를 잘해야 한다.  정규화를 잘 따라야 한다.  설계가 전체 DB 속도를 좌우한다..  등등등... 많은 이야기와 함께 아주아주 어려운 부담을 가지고 이곳 DB 개론과 설계를 보셨을 겁니다. 　 여기서 코난이의 생각은 약간 다르답니다. 조금더 쉽게 이부분을 가져가기 위해... 코난이가 얘기를 드리겠습니다. 　 DB디자이너의 이단자로 부르셔도 좋고... 이게 강좌냐 라고 하셔도 좋습니다. 코난이의 생각을 얘기 드리는 거니까요 ^_^ 　 논리적인 데이터베이스의 설계 이야기 입니다. 이런 생각을 해보세요... 바로 수강신청 입니다. 대부분의 분들이 대학 시절 수강신청을 해 보셨을 거에요... ^_^ 어느책에나 나와 있는 부분이지만..... - 수강신청은 어느 과목이나... 원하는 과목을 신청이 가능합니다. - 교수님은? 한과정 이상을 강의합니다. - 교수님은 자신만의 강의실에서 강의합니다. - 강의실은 한명의 교수님만 사용 합니다.. 　 어떠세요? 대략적으로 생각 나는데로... 이를 옮겨 볼까요? 일반적으로... 두개정도로 테이블을 생각하실 수 있을 겁니다. 학생 테이블 <TABLE borderColor=#000000 cellSpacing=0 borderColorDark=#ffffff cellPadding=5 width="100%" borderColorLight=#000000 border=1> <TBODY> <TR> <TD align=middle width="33%" bgColor=#c0c0c0> 이름</TD> <TD align=middle width="33%" bgColor=#c0c0c0> 학번</TD> <TD align=middle width="34%" bgColor=#c0c0c0> 등록한 과정</TD></TR> <TR> <TD width="33%"> 김대우</TD> <TD width="33%"> 941111</TD> <TD width="34%"> 데이터베이스 디자인 데이터베이스 어드민</TD></TR> <TR> <TD width="33%"> 김종원</TD> <TD width="33%"> 931234</TD> <TD width="34%"> 영상처리 데이터베이스 디자인</TD></TR> <TR> <TD width="33%"> 이수선</TD> <TD width="33%"> 994321</TD> <TD width="34%"> 영상처리</TD></TR></TBODY></TABLE> 　 과정 테이블 <TABLE cellSpacing=0 borderColorDark=#ffffff cellPadding=5 width="100%" borderColorLight=#000000 border=1> <TBODY> <TR> <TD align=middle width="33%" bgColor=#c0c0c0> 과정</TD> <TD align=middle width="33%" bgColor=#c0c0c0> 교수님</TD> <TD align=middle width="34%" bgColor=#c0c0c0> 강의실</TD></TR> <TR> <TD width="33%"> 데이터베이스 디자인</TD> <TD width="33%"> 우요섭</TD> <TD width="34%"> 520</TD></TR> <TR> <TD width="33%"> 데이터베이스 어드민</TD> <TD width="33%"> 우요섭</TD> <TD width="34%"> 520</TD></TR> <TR> <TD width="33%"> 자바플그래밍</TD> <TD width="33%"> 강현철</TD> <TD width="34%"> 519</TD></TR></TBODY></TABLE> 　 이렇게 되었다고 생각을 해 보세요? 아주 깔쌈하게 생성이 된듯~?? 하실 겁니다. 그렇다면 문제점이 무엇인지 짚어 보지요 ^_^ 　 먼저 학생테이블의 첫번째 문제 입니다. 학생이 등록할 수 있는 과목의 수는? 등록한 과정 컬럼 부분에 들어 갑니다. 즉 과목의 수는 등록한 과정 컬럼의 자료형의 크기(예를들면 varchar(100)) 에 제한이 됩니다. 한학생이 6과목(18학점)이건 8(24학점 평점 4.0 이 넘으면 신청이 가능하죠? 들어보는게 소원임당.. T.T) 과목이건...  등록한 과정 컬럼에 제한되며 등록한 과정 컬럼은 검색에 사용하기도, 계산에 사용되기도 거의 불가 입니다. 　 두번째 문제 입니다. 등록한 과정 컬럼에 각 과목이 반복되어 나타나게 됩니다. 이는 DB의 공간을 낭비하게 되며 만약... 입력자의 실수로 등록한 과정부분의 데이터가 잘못 들어 간다면? 과정테이블의 과정 컬럼과 틀려져  일관성 없는 데이터가 되며... 만약 데이터베이스 어드민이라는 과목명이 데이터베이스 어드미니스트레이터 로 변경이 된다면? 모든 학생 테이블의 등록한 과목명 부분이 수정이 되어야 겠지요? 　 세번째 문제 입니다. 학생의 이름으로 검색을 한다고 생각해 보지요.... 음음음... SQLER 주인장의 이름이... 잘 몰겠지만.. 김 모모 인데.... 이친구가 등록한 과목명이 궁금혀여~~~~ 이름으루 차자 볼가나아~~~ 할경우 색인구축이 김이라는 성과 대우라는 이름에 나누어져 있다면? 더욱 빠른 속도를 기대가 가능하나... 현재로는 불가 입니다. 　 네번째 문제 입니다. 만약... 자바 플그램이 이젠 필요가 없어져 이를 XML프로그래밍으로 바꾼다면? 자바 플그래밍에 관련된 로우인 교수님 - 강현철 강의실 - 519 모두가 사라지는 불상사가 생기게 됩니다. 　 다섯번째 문제 입니다. 우요섭 교수님의 강의실이 학과의 규정에 따라  420 호실로 바뀌게 되었습니다. 그럼? 모든 과정테이블의 우요섭교수님의 강의실이 520에서 420으로 변경이 다 되어야 겠지요? 하나라도 안바뀌면? 그 불상사는 이루 말할 수 없을 겁니다. 　 그렇다면??? 대략 이러한 5가지의 문제만을 따져 본다면? 어떻게 설계가 된다면? 이런 데이터베이스의 문제가 사라 질까용? 　 바로 정규화를 거치는 겁니다.... 어떻게? 이곳에서는 간단히... 결과를 우선 살펴 보지요... 학생 테이블 <TABLE cellSpacing=0 borderColorDark=#ffffff cellPadding=5 width="100%" borderColorLight=#000000 border=1> <TBODY> <TR> <TD align=left width="25%" bgColor=#c0c0c0> 학생ID</TD> <TD align=left width="25%" bgColor=#c0c0c0> 성</TD> <TD align=left width="25%" bgColor=#c0c0c0> 명</TD> <TD align=left width="25%" bgColor=#c0c0c0> 학번</TD></TR> <TR> <TD align=left width="25%"> 1</TD> <TD align=left width="25%"> 김</TD> <TD align=left width="25%"> 대우</TD> <TD align=left width="25%"> 941111</TD></TR> <TR> <TD align=left width="25%"> 2</TD> <TD align=left width="25%"> 김</TD> <TD align=left width="25%"> 종원</TD> <TD align=left width="25%"> 931234</TD></TR> <TR> <TD align=left width="25%"> 3</TD> <TD align=left width="25%"> 이</TD> <TD align=left width="25%"> 수선</TD> <TD align=left width="25%"> 994321</TD></TR></TBODY></TABLE> 　 과정 테이블 <TABLE cellSpacing=0 borderColorDark=#ffffff cellPadding=5 width="100%" borderColorLight=#000000 border=1> <TBODY> <TR> <TD width="33%" bgColor=#c0c0c0> 과정ID</TD> <TD width="33%" bgColor=#c0c0c0> 과정명</TD> <TD width="34%" bgColor=#c0c0c0> 교수님 ID</TD></TR> <TR> <TD width="33%"> 1</TD> <TD width="33%"> 데이터베이스 어드민</TD> <TD width="34%"> 1</TD></TR> <TR> <TD width="33%"> 2</TD> <TD width="33%"> 데이터베이스 디자인</TD> <TD width="34%"> 1</TD></TR> <TR> <TD width="33%"> 3</TD> <TD width="33%"> 자바플그래밍</TD> <TD width="34%"> 2</TD></TR></TBODY></TABLE> 　 교수님 테이블 <TABLE cellSpacing=0 borderColorDark=#ffffff cellPadding=5 width="100%" borderColorLight=#000000 border=1> <TBODY> <TR> <TD width="25%" bgColor=#c0c0c0> 교수님ID</TD> <TD width="25%" bgColor=#c0c0c0> 성</TD> <TD width="25%" bgColor=#c0c0c0> 명</TD> <TD width="25%" bgColor=#c0c0c0> 강의실</TD></TR> <TR> <TD width="25%"> 1</TD> <TD width="25%"> 우</TD> <TD width="25%"> 요섭</TD> <TD width="25%"> 520</TD></TR> <TR> <TD width="25%"> 2</TD> <TD width="25%"> 강</TD> <TD width="25%"> 현철</TD> <TD width="25%"> 519</TD></TR></TBODY></TABLE> 　 과정등록 테이블 <TABLE cellSpacing=0 borderColorDark=#ffffff cellPadding=5 width="100%" borderColorLight=#000000 border=1> <TBODY> <TR> <TD width="33%" bgColor=#c0c0c0> 등록ID</TD> <TD width="33%" bgColor=#c0c0c0> 학생ID</TD> <TD width="34%" bgColor=#c0c0c0> 과정ID</TD></TR> <TR> <TD width="33%"> 1</TD> <TD width="33%"> 1</TD> <TD width="34%"> 1</TD></TR> <TR> <TD width="33%"> 2</TD> <TD width="33%"> 1</TD> <TD width="34%"> 2</TD></TR> <TR> <TD width="33%"> 3</TD> <TD width="33%"> 2</TD> <TD width="34%"> 2</TD></TR> <TR> <TD width="33%"> 4</TD> <TD width="33%"> 2</TD> <TD width="34%"> 3</TD></TR> <TR> <TD width="33%"> 5</TD> <TD width="33%"> 3</TD> <TD width="34%"> 3</TD></TR></TBODY></TABLE> 이렇게라고 생각해 보지요!!!! 그럼 어떻게 바뀐 걸까요? 학생 - 과정 : 과정등록 테이블을 통한 다대다의 관계 학생 - 과정등록 : 일대다 과정 - 과정등록 : 일대다 교수님 - 과정 : 일대다 　 이렇게 바뀐거지요? 조금더 깊이 바라 보지요... - 각각의 테이블은 하나의 관계 데이터 셋만을 가지게 된다. - 각 테이블은 기본키를 가지게 된다 (ID로 표시된 컬럼) - 분해가능한 컬럼은 없다(좀더 깊이 바라보면 학번의 941111의 94는 입학년도 첫11은 학과번호 뒤의 11은 해당학과 94학번의 가나다순 순서로 볼수 도 있지요) - 반복되는 데이터는 없다 (과정의 데이터베이스 디자인은 한번만 나타남) - 다중값을 가지는 컬럼은 없다(이전 학생 테이블의 등록한 과정과 같은 여러 과정이 반복적으로 안나타나며 로우로 구분되 저장된다. - 모든 컬럼은 기본키에 완전 종속적이다. 　 그렇다면? 이렇게 정규화를 하고나서 보니... 뭔가 훨씬 더 잘 정리된듯 합니다. 이러한 처리가 정확히 어떠한 DB종속적인 장점이 있을까요? - 테이블이 약간더 작아지므로 정렬기능과 색인의 생성이 쉬우며 매우 효율적이다. - 많은 테이블이 고유 ID를 가지고 있으므로 개개 테이블에 완전한 클로스터드 색인을 생성이 가능하다 - 색인이 아주 작고 작은만큼 경제적이다. - 테이블의 작고 효율적인 색인은 UPDATE나 INSERT의 성능을 향상 시킨다. - 거의 NULL을 사용하지 않아 불필요한 데이터의 사용을 막으며 물리적으로 좀더 뭉쳐있어 검색시 빠른 속도를 가질 수 있다. - 더 적은 데이터에 영향을 주므로 테이블의 잠금이 아주 짧고 적은 데이터만 걸린다. 　 약간 어려운 잠금, 색인 등의 내용이었지만... 제 기본강좌부분 에서 설명을 차근차근 드린답니다. 　 그렇다면... 조금이나마 쉽게 아주 재미없은 DB개론 이야기를 마치셨다고 생각 합니다. 그렇다면? 이젠 개론 이야기를 건너건너 코난이의 이야기 입니다. 　 과연 정규화가 최고의 모범 답안인가? ???? 여지껏 정규화와 DB개론 이야기를 주절주절 떠들어 대고 이게 웬 뒤통수 때리는 얘기 냐구요? 이는 정규화가 잘못되었다나 나쁘다의 이야기가 아닙니다. 이미 정규화로 퍼포먼스를 높이고 처리함은 많이 논의 되었고 정확한 수치자료로 확인이 가능합니다.  이하 이야기는 코난이의 이야기일 뿐입니다. 　 먼저 비용면입니다. DB를 구축하고 그에 따르는 정규화 작업을 합니다. <IMG height=488 src="https://img1.daumcdn.net/relay/cafe/original/?fname=http%3A%2F%2Fwww.sqler.pe.kr%2Fsqllec%2Fimages%2Fs3.JPG" width=650 border=0> 코난이가 모정보통신 회사에서 구축한 테이블 전체 스키마 입니다. 전체 테이블중 단독 테이블을 제외한  메인 로직부분이 아주 흥미있게도 20여개의 테이블 스키마로 구성되어 있습니다. 아주아주 라고 할순 없지만 어느정도 유연성과 속도를 위한... 중복 데이터 제거를 위한 등의 정규화 로직에 따라 구축을 하였습니다. 깔끔한듯 하지요?   　 코난이의 문제 제기 입니다. 여기서의 문제는 비용 입니다. 과연 어느정도의 비용을 들이고 회사의 차원에선 금쪽과도 같은 시간을 줄여서 완성된 데이터베이스 스키마를 생성할 것인가?!!!! 비록 저러한 정규화의 로직으로 구축이 안되어도, DB 디자이너의 기획에 의한 디자인이 아닌  어플리케이션 개발자의 디자인 이라도 어느정도 수준의 어플리케이션 개발자라면? 원하는 아웃풋을 생성하기위한 DB설계는 생성이 가능하지 않은가? ....... ....... 　 다음은 유지보수 차원 입니다. 코난이가 DB설계를 저렇게 하고.... 관련 도큐먼트를 작성해 완전히 문서화 하였습니다. 추후 이 디비를 보수하기 위해 다시 이 회사로 불려 갔습니다. 그렇다면?  코난이는 이 DB로직을 다시 머리속에 띄우고  비용과 시간과의 싸움 입니다. 과연 얼마의 시간이 들어 갈까요? 　 중복데이터에 의한 부분 입니다. 최근의 개발추세를 생각해 보세요... 잘 만들어진 VB나 VC로 만들어진 어플리 케이션..... 대부분이 어떤 인터페이스를 사용 하나요? 리스트 박스나 셀렉트 박스를 이용해 이미 등록되어 있는(개발자가 만들어둔) 데이터를 고르게 합니다. 바로 집주소 입력 같은 경우 이지요... 이럴때 과연 DB상에 무결성이 깨져서 잘못된 데이터가 들어가는 문제가 생길까요? 하드디스크가 최근은 기본 20기가 입니다. 디스크 용량은 약간 다음 문제라는 겁니다. 문자열을 ID를 참조해(조인해) ID를 넣는게 빠를까요? 아님 문자열 자체를 테이블에 넣는게 빠를까요? 　 나누어진 테이블을 재구성할경우의 (조인할때) 시스템의 비용 입니다. 다음은 위의 제 정규화 예제에서.... 등록된 과목의 학생명과 교수명을 보로 싶으면 3개의 테이블을 조인해야 합니다. 조인의 부하를 느껴보신분은... 3개의 테이블을 조인할 경우와.. 4개의 테이블을 조인할 경우... 리턴 컬럼셋의 갯수에 따르는  조인의 부하를 느껴보신 분이라면? 아예 비정규화를 고려하시는 분들도 많이 계실 겁니다... 아울러... 일반적인 전사 환경의 데이터수인 10만~100만개(영업실적 테이블이라면?)의  로우가 있습니다. 이를 1000개 정도의(사원정보 테이블)과 조인해 영업실적별 사원명을 보려 합니다. 이때 조인을 실행 한다면? 이때 SELECT절의 후처리를 사용한다면? 영업실적테이블은 초당 5개의 잠금(삽입이나 수정)이 걸려 SELECT가 잠금대기를 해야 한다면? 　 과연 어디까지가 정답이며 어디까지가 오답인가? ... ... 　 다음 이야기로.. 데이터베이스 모델링 툴에 대한 이야기를 간단히 해보도록 하지요. 국내에서는 주로 ERWin 이라는 툴을 사용합니다. 저는 개인적으로 ER-Studio라는 걸 선호 하지만.. 뭐 그려려니 한답니다. ^_^ 　 중요한건 툴이 무엇인가가 아닙니다. ER-Win 툴으로 데이터베이스 디자인을 위해 로지컬 디자인에서.. 디자인을 이렇게 하고.. 엔티티를 이렇게 두고.. 피지컬 디자인에서 이리이리 한다.. 뭐 이런 이야기를 드리려 했지만.. 다시 앞을 돌아보면.. 대단히 많은 관계형 DB에 대한 선 지식이 필요하기  때문에 그냥 생략하도록 하겠습니다. 사실 컨설팅을 나가서 이쪽 ER-D 생성 및 유지보수 강좌를 하면.. 관계형 데이터베이스 등에 많은 경험이 없는 분들이... 대부분 이라.. 별로 효과를 본적이 없습니다. 컨설팅 나간 사이트 분들이 요청해..  세번정도 했었는데..  세번다 너무 어렵거나.. 뭐. 이런 이유로.. 이 이야기는 접으려 합니다. 나중에 추가 강좌를 적을때 한번 가능하면 이야기를 해 보도록 하지요. 그럼 이만</TD></TR></TBODY></TABLE>     <STYLE>P{margin-top:2px;margin-bottom:2px;}</STYLE>