조직의 가치관에 관해 좋은 글이 있어 퍼왔습니다.

인생은 참 어렵다.
가치관을 연구 전파하는 사람으로서 항상 느끼지만 개인의 인생에 비해 조직은 어렵지 않다. 아니, 조직은 어렵지 않아야 한다. 

국민행복시대

 

어려운 인생

많은 이들의 사랑을 받았던 유명 야구해설가가 스스로 세상을 등졌다. 야구에 대한 열정, 해박한 지식 여기에 친근감가는 말투와 좋은 인성으로 많은 팬이 그를 따랐다. 100억이 넘는 건물을 소유하였었고 KBO의 수장으로 한국프로야구 발전을 이끄는 중책도 수행했었다. 그러나 한 순간에 사기를 당해 건물을 잃고 빚더미에 앉아 파산선고를 받았다. 급기야 취업청탁 사기문제까지 발생하여 평생 쌓은 돈, 명예를 모두 잃는 처지에 놓였고 급기야 자살이라는 마지막 선택을 하게 되었다. 조직의 운명은 이렇게까지 어렵지 않다.

여고생 딸과 단 둘이 사는 엄마이야기다. 병으로 남편을 일찍 보내고 딸과 둘이서 살지만 행복했었다. 학원 한번 다니지 않고 중학교까지 전교 1~2등을 하던 모범생 딸이었다. 고등학교에 입학한 어느 날 딸은 학교 선배들에게 집단 폭행을 당했고 그 이후 딸은 전혀 다른 사람이 되었다. 자해를 하고 말을 잃고 멍하니 하늘을 보는 아이가 되었다. 체육시간에도 혼자 벤치에 앉아 초점 없는 눈으로 멍하니 하늘만 바라보고 있다. 엄마도 지병을 앓고 있어 거동도 힘든 상태다. 하루 아침에 인생이 변해버렸다.

추석 때 안타까운 뉴스가 많았다. 자식들도 찾지 않는 명절에 노부부가 연탄불을 피워 놓고 나란히 누워 세상을 떠났다. 지병을 앓고 있는 아내를 더 이상 돌보기 힘들었던 노부부의 선택이었다.

이런 극단적인 상황이 아니더라도 우리 주변에 대부분 사람들은 개인과 가족만 아는 아픈 사연이 많다. 부부 사이가 나쁘거나 부모와 자식 사이의 갈등, 형제들 간의 갈등 등, 가족 간에 크고 작은 문제들을 안고 살고 있다. 건강 문제도 있다. 정신적으로나 육체적으로 가족 중 누군가가 고통 받고 있다. 남들에게 자랑할 일이 아니기에 아무에게도 말하지 않으니 겉으로 보기에 모두가 평온한 가족으로 보일 뿐이다.

 

캐릭터와 조직

개인이 일을 하면서 가장 힘들어 하는 것은 자기가 가진 캐릭터다. 조직에서 발생하는 갈등 중 해결이 안 되는 갈등은 대부분 개인이 가진 캐릭터에 의해 생긴다. 소심하거나 거칠거나, 자신감이 없거나 타인을 지배하려고 들거나, 남의 말을 듣지 못하거나 자기 의견을 제대로 말하지 못하거나, 타인의 마음에 공감하지 못하거나 솔직하지 못하거나, 너무 급하거나 너무 느리거나 등등.

대부분 사람들은 자기 캐릭터 때문에 고민하면서, 자기의 약점이 남들에게 보이기를 바라지 않는다. 그래서 자기의 약점인 캐릭터를 가지고 일하거나 조직을 이끌게 되면 끊임없는 번민과 고통을 겪게 된다. 그리고 그것은 상대방을 힘들게 하는 것으로 드러난다. 

 

조직가치관이 중요한 이유

조직은 쉬워야 한다. 복잡 오묘한 개인의 인생과 엮이고 개성이 마구 충돌해서는 조직은 혼란스럽게 된다. 조직의 가치관은 ‘조직이 가장 중요하게 생각하는 것’으로서 성과를 판단하게 하는 기준이 된다. 조직의 목적(미션), 조직의 목표(비전), 조직의 우선순위(핵심가치)에 의해 조직이 움직이게 하는 것이 필요하다.

이것은 회사 전체도 그렇고 팀이나 부서도 마찬가지다. 조직이 원하는 성과를 만들어 내는 것에 모든 조직원은 집중해야 한다. 이를 위해 조직의 목적과 목표를 정확히 알고, 조직의 우선순위에 맞는 일하는 원칙과 기준이 바로 서 있으며, 그것이 제대로 내재화되는 것이 중요하다. 정해진 원칙, 합의된 기준에 의해서 경영자는 경영자로서, 리더는 리더로서, 직원은 직원으로서 자기의 역할을 다하면 된다.

이렇게 해야 안정적인 직장에 기반해서 어려운 개인의 인생을 잘 풀어나갈 수 있다. 조직이 꼬이고 복잡해서는 개인의 인생은 더 힘들고 어렵다. 개인의 행복은 점점 더 멀어질 뿐이다.

 

왜 ‘가치관경영’인가?

국가와 기업의 측면에서

대한민국은 현재 5천년 역사 이래 가장 잘 살고 영향력 있는 나라다. 해방 이후 70년 각고의 노력으로 민주화와 경제성장을 이루며 여기까지 왔다. 그런데 지금 우리는 혁신과 성장이 지체되고 있다. 강력했던 성장동력도 꺼지고 있다는 우려가 여기저기서 나온다. 성장 불씨가 꺼지고 나면 다시 불을 피우기 어렵고, 다시 불을 피워도 활활 태울 수 있다는 보장이 없다.

이를 극복하기 위해서는 기업의 경쟁력이 강화되어야 한다. 가치관경영은 기업의 성장 불씨를 계속 태우게 하는 중요한 일이다.

사회의 측면에서

다음 세대가 부모 세대보다 못 사는 최초의 시대가 될 것이라고 한다. 미래에 대한 희망을 보여주는 출산율이 세계 최저, 현재가 어렵다는 것을 보여주는 자살률이 세계 최고다. 사회가 삭막해지고 있다. 아파트 옆집에 누가 사는지 모르고, 엘리베이터에서 인사를 하는 사람은 점점 적어진다. 사회 공동체가 약해지고 오로지 개인과 가족만을 중요하게 생각하는 풍조가 생기고 있다.

이를 극복하기 위해서는 이웃과 사회에 공동체가 복원되어야 한다. 가치관경영은 기업에서부터 공동체를 복원하려는 움직임이다. 나만이 아니라 공동체(공동운명체)를 강조하는 것이 가치관경영이다.

개인의 측면에서

나는 왜 일하는가? 많은 얘기를 할 수 있지만, 꼭지점은 결국 개인의 행복과 성공을 위해서다. 그렇다면 우리는 어떻게 일하면서 행복과 성공을 얻을 수 있는가? 월급이 많아지는 것은 좋긴 좋다. 어느 정도의 행복감이 느껴질 수 있다. 하지만 월급이 많아진다고 행복하다고 하지는 않는다.

행복하려면 보람이 있어야 한다. 보람이 있으려면 일의 의미와 가치를 알아야 한다. 성공하려면 목표가 있어야 한다. 목표를 정하고 그것을 이루어낸 성취감이 있어야 한다. 조직가치관은 개인의 행복과 성공에 결정적 영향을 미친다.

원문: 정진호가치관경영연구소

   
지난 이삼십여년동안 큰 성장을 거둔 스타트업은 전체 검토한 기업의 1%도 되지 않는다.
1%의 기업들은 대부분 성공의 원인이 운(luck)이라고 한다.
운이 전부는 아니었겠지만 시점의 운, 대형 경쟁자의 눈에 띄지 않은 운, 갑자기 시장 상황이 바뀐 운, 예상치 못한 투자자가 찾아와 투자를 해준 운, 채널 판매자가 엄청난 성과를 만들어 갑자기 궤도에 오르게 된 운, 본래 하던 일이 아닌 사이드 프로젝트에서 폭발적 반응이 나오게 됨으로 커진 운....이런 운들이 만들어낸 결과라고들 한다.
반면 실패를 경험한 스타트업들은 운이 따르지 않았다고 할수도 있는 반면에 그러한 운을 얻지 못할 내부적 상황이 있었다.

1. 구체적 상황이 아닌 추상적 상상을 통해 비즈니스를 만들었다.
: 사용자의 삶의 현장에서 발생하는 실제적 문제가 아니라 사용자가 그럴수도 있을거라는 추상적인 상상으로 제품을 만들었고 팀원들 어느 누구도 확신이 없었다.

2. 사용자의 삶을 목표로 한 것이 아닌 내가 가진 아이디어/기술을 적용하는 것을 목표로 했다.
: 창업자가 생각한 아이디어나/기술은 사용자의 삶에 목적을 달성해줄 그저 도구일뿐이지 그 자체가 목적이 아닌데 창업자는 그것을 목적으로 내세워 팀을 이끌었다.

3.  PM들에게 권한을 주지 않고 창업자가 독선적으로 모든 결정을 내린다.
: 창업자는 전능하지 않다.모든 것의 답을 가지고 있지도 않다.모든 결정을 올바르게 한다는 보장도 없다.그럼에도 불구하고 권한 위임을 하지도 않고 PM을 키우지도 않는다.점점 통제불능 상태로 빠지게 되고 조직은 혼란에 빠짐으로 가라앉게 된다.

4. 제품 출시의 약속이 지켜지지 않는다.
: 제품 출시의 약속이 지켜지지 않는것을 당연하게 여기거나 여러 이유를 대면서 늦추는 것은 한마디로 조직이 제대로 운영되지 못한다는 것을 의미한다.누구의 책임인지를 떠나 조직역량이 목표를 달성하지 못할만큼 취약하다는 것을 의미한다.

5. 전략이 부재하다.
: 전략은 목표를 달성하는데 있어서 허들을 어떻게 넘을 것인가 그리고 원하는 것을 어떻게 얻을 것인가에 대한 매우 현실적이고 구체적인 방법론이다.제품과 일반적이고 전통적 방식의 마케팅 방법은 있으나 정말로 자신의 제품에 꼭 맞는 자기만의 독특한 전략이 없기 때문에 수많은 유사 제품/서비스에 가려 빛을 보지 못하고 사라지게 되었다.

6. 차별화에 신경쓰다 진짜 가치를 놓치다.
: 잘나가는 몇몇 서비스에서 발견된 Side issue를 해결하다가 진짜 중요한 본질을 놓침으로 그저 유사품으로 시장에서 낙인찍혀 사라져 버렸다.

7. 관리없는 열심이 모든걸 망쳤다.
: 사업의 성공은 자유함에 있는 것이 아니다.창의력과 혁신도 무분별하고 자유분방함에서 나오는 것이 아니라 끊임없이 연결하고 조직화하고 프로세스화하고 관리하는데서 형성되는 것이다.열심은 성공의 key가 아니다.목표라는 과녁을 맞추기 위해 아주 좁은 Route로 들어가야 하는데 그 Route를 치밀하고 조직적으로 설계하고 관리할때 비로소 궤도에 오르게 되는 것이다.

8. 치열함과 화목함을 구분하지 못했다.
: 올바르게 하기 위해서는 치열하게 토론하고 답을 찾기 위해 때로는 얼굴을 붉히거나 강하게 주장해야 한다.그러나 어디까지나 그것은 목표를 달성하기 위함이지 화목함을 깨기 위함은 아니다.많은 실패한 조직들은 목표를 이루기 위한 과정에서는 이상하게도 화목(때로는 포기?)하게 서로 넘어가지만 조직생활에서는 불필요하게 감정적으로 대하다가 무너지곤했다.

9. 처음 사업때 생각한 아이디어 수준을 넘어서지 못했다.
: 사업은 처음에 알지 못했던 새로운 교훈을 얻으면서 발전된다.그런데 창업자나 팀원들이 사업을 진행하면서 얻은 교훈을 정리하여 발전적 방향으로 적용하지 못하고 - 자신들은 교훈을 깨달았으니 적용하고 있다고 착각하거나 다른 사람들의 멋진 말들이나 SNS의 교훈들에 공감하니 마치 자신도 그러한것처럼 생각함으로 - 처음에 생각한 아이디어 수준을 넘어서지 못하였다.

10. 실행은 수동적 업무처리가 아니라 능동적 문제해결이다.
: 오늘 아침 내게 닥친 문제나 내가 발견한 문제를 해결하기 위해 난 무엇을 찾고 무엇을 고민하고 무엇에 시간을 투입해야 할까?그리고 얼마나 빠르게 그것을 해결해야할까?실행이란 그저 주어진 일들을 처리하는 것이 아니라 능동적으로 최선의 방법을 찾아 문제를 해결하는 것이다.실패한 기업들은 매일 매일 주어진 문제를 수동적으로 처리했기에 별다른 결과물이 나오지를 못했다.

공감하는 내용이라 발췌하였는데 어디인지 알 수가 없네요 ;;;  


   

7월엔~

Data도 확인 해야하고 ~

통계도 만들고 확인 해야 하며 ~

개발도 해야 하뉘 ~ 바쁘다 바뻐~ ㅠ.ㅠ

힐링이 필요 ~

 

 

   

예병일의 경제노트에서 예전에 보았던 베조스의 '후회 최소화의 법칙'에 관한 글이 있어 다시 남겨 봅니다.

 

 

 

사장의 만류에 고심하던 그때, 베조스의 결단을 이끌어낸 기준이 '후회 최소화의 법칙'이었다.

'
인생의 노년에 지난날을 돌아봤을 때, 어느 쪽을 택해야 덜 후회할까?'로 미래에 대한 판단을 내린 것이다


80
세가 되었을 때, 서른 살에 거액의 인센티브를 받지 못한 것을 아쉬워할까? 그렇지 않을 것이다.

그러고 나서 베조스는 다음과 같이 생각했다.


'
도전하지 않으면 분명히 후회한다. 그것은 부인할 수 없는 사실이다.' 


그렇다.

도전해보고 후회하는 건 납득할 수 있다.


하지만 도전하지 않은 후회는 되돌릴 수 없다.

 

베조스의 아마존 창업은 이렇게 시작되었다. (21)

 

니시무라 가쓰미의 '1분 베조스' 중에서(북스톤)

 

   


 

오랜 기간 경영자들과 학자들은 시장의 흐름을 가장 먼저 잡는 비즈니스의 '선발주자(First Mover)'들이 경쟁사들에 비해 엄청난 혜택을 누릴 수 있다고 주장했다.

1998년 스탠퍼드 대학의 마빈 리버만(Marvin Lieberman)과 데이비드 몽고메리(David Montgomery) 교수는 시장에 최초로 진입한 경쟁자는 독점적인 학습 기회를 얻고, 특허를 확보하고, 구매자 전환 비용을 설정할 기회를 잡을 수 있다고 설명하며 이 개념을 널리 전파했다.

이후 학자들은 선발주자가 상당한 브랜드 이점도 누릴 수 있으며, '오리지널'이라는 이미지를 통해 마케팅 측면에서 상당히 유리한 고지를 점할 수 있다고 덧붙였다.


리버만과 몽고메리 교수가 선발주자의 이점이라는 현상을 비즈니스계에 각인시킨 지 10년 뒤,

두 사람은 선발주자에게 이점만 있는 것은 아니라며 자신들의 결론에 이렇게 단서를 달았다.

"개척자는 기술과 시장의 불확실성 때문에 최고의 기회를 미처 보지 못하고 놓치는 경우가 많다.

사실 일찍 시장에 진입한 사람은 시장이 진화함에 따라 그다지 큰 가치를 얻을 수 없는 '쓸모없는' 자원을 손에 넣을 가능성이 높다."


한편 서던 캘리포니아 대학의 피터 골드(Peter Golder)와 제라드 텔리스(Gerard Tellis)라는 두 학자는 과연 시장 개척자들이 성공할 가능성이 더 높다는 주장을 뒷받침할 역사적인 증거가 있는지를 연구했다.

그들은 치약에서부터 비디오 레코더, 팩스 기계에서 추잉 껌에 이르기까지 50개 제품 카테고리의 500개 브랜드를 연구 대상으로 삼았다.


그 결과, 놀랍게도 선발주자의 47%가 실패했음이 밝혀졌다. 제품을 최초로 출시한 기업 중에서 5년 뒤에도 시장에서 1위를 유지한 기업은 절반 정도였고, 장기간 시장에서 우위를 점유한 기업은 선발주자의 11%에 불과했다. 반면 선발주자가 일단 시장을 개척해놓은 후 제품의 시장 점유율을 장악한 '빠른 후발주자(Fast Follower)'들의 실패율은 8%에 불과했다.

그리고 이들이 해당 제품 카테고리에서 시장 점유율 1위를 차지한 기간은 두 학자가 연구 대상으로 삼은 기간 중 무려 53%에 달했다.


선발주자에게는 고객 교육, 인프라 건설, 규제 승인, 실수를 통한 피드백 및 개선 과정 등을 거쳐야 한다는 부담이 있다.

반면 빠른 후발주자는 무임승차 효과를 누릴 수 있다.

그들은 선발주자의 성공을 차용하고, 그들의 실패 사례에서 객관적인 교훈을 얻으며, 다른 분야에 더욱 많은 노력을 쏟을 수 있다.

말하자면 선발주자는 후발주자가 더욱 세차게 질주할 수 있도록 길을 닦아주는 셈이다.


세계 제일의 정치 관련 웹사이트인 <허핑턴포스트>를 포함, 역사상 큰 성공을 이룬 기업의 상당수는 해당 분야의 빠른 후발주자였다.

기업가 정신을 연구하는 학자 스티브 블랭크(Steve Blank)는 <비즈니스 인사이더>에 기고한 '창시자보다는 빠른 후발주자가 되는 편이 더 낫다'라는 기사에서 빠른 후발주자였던 GM이 포드자동차를 앞질렀다는 사실을 지적했다.

구글, 페이스북, 마이크로소프트는 각각 오버추어, 마이스페이스, 애플을 앞지른(애플이 다시 돌풍을 이르킬 때까지) 각 기술 전문 영역의 빠른 후발주자였다.


그러나 후발주자가 잊지 말아야 할 것이 있다.

그것은 선발주자와의 적정한 거리를 유지하는 일이다.

너무 뒤쳐지게 되면 다른 주자들에게 자리를 빼앗겨 경쟁에서 밀려날 수 있으며, 그렇다고 무리하게 속도를 내다가는 자칫 사고가 날 수도 있기 때문이다.

이에 관해서는 애래에 링크한 글을 참고하기 바란다.


 

 

 

 

안개 낀 도로와 같은 경영 환경, 어떻게 대처할 것인가?
지금의 경영 환경을 안개 낀 도로에 비유할 수 있다. 도대체 저 앞에서 어떤 일이 벌어지고 있는지 캄캄할 뿐 아니라 당장 내 앞에서 무슨 일이 벌...
blog.naver.com
본문으로 이동

 

* 이 글은 'RHK'에서 펴낸 셰인 스노우(Shane Snow)의 《스마트컷》의 내용을 참고했습니다.

   

1.1. 엔티티 타입
정의 : 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 것으로 영속적으로 존재하는 단위

특징
1) 반드시 시스템을 구축하고자 하는 업무에서 필요하고 관리하고자 하는 정보이어야 한다.
2) 유일한 식별자에 의해 식별이 가능해야 한다.
3) 영속적으로 존재하는 엔티티의 집합이어야 한다.
4) 업무 프로세스는 그 엔티티타입을 반드시 이용해야 한다.
5) 엔티티타입에는 반드시 속성(Attribute)이 있어야 한다.
6) 엔티티타입은 다른 엔티티타입과 최소 한 개 이상의 관계가 있어야 한다.

분류
1) 유무형에 따른 분류 : 유형, 개념, 사건 엔티티타입
2) 발생시점에 따른 분류 : 기본, 중심, 행위 엔티티타입


1.2. 관계
정의 : 두 개의 엔티티타입 사이의 논리적인 관계 즉 엔티티와 엔티티가 존재의 형태나 행위로서 서로에게 영향을 주는 형태

1.3. 속성
정의 : 업무에 필요한 엔티티에서 관리하고자 하는 더 이상 분리되지 않는 최소의 데이터 단위

1.4. 엔티티 수퍼타입과 서브타입
정의 : 여러개의 엔티티 타입이 비슷하고 일부의 속성이나 관계만 다를 경우 여러 개의 엔티티타입을 한 개의 엔티티타입 안에 다른 엔티티타입의 모습을 서브타입으로 나뉘어 표시하는 경우가 있다. 이러한 것을 엔티티타입이 통합되었다라고 한다. 통합하여 표시하는 엔티티타입을 수퍼타입이라하고 수퍼타입 안에 포함되어 표시된 비슷한 성격의 엔티티타입을 서브타입이라 한다.

1.5. 서브젝트 에어리어
정의 : 해당 업무 내에서 연관이 많은 엔티티타입을 그룹으로 묶어 표시하는 개념이다.

1.6. 정규화
특징
1) 정규화는 적절한 엔티티타입에 각각의 속성들을 배치하고 엔티티타입을 충분히 도출해가는 단계적인 분석 방법이다.
2) 정규화 기술은 엔티티타입에 속성들이 상호 종속적인 관계를 갖는 것을 배경으로 종속 관계를 이용하여 엔티티타입을 정제하는 방법이다.
3) 각각의 속성들이 데이터 모델에 포함될 수 있는 정규화의 원리를 이용하여 데이터를 분석하는 방법에서 활용될 수 있다.
4) 정규화는 현재 데이터를 검증할 수 있고 엔티티타입을 데이터가 표현하는 관점에서 정의하는데 이용할 수 있다.
5) 정규화는 엔티티타입을 분석하는 관점이 오브젝트 별 분석하는 방법이 아닌 개별 데이터를 이용한 수학적인 접근 방법을 통해 분석하는 방법이다.

정규화 내용
1) 1차 정규화 : 복수의 속성값을 갖는 속성을 분리
2) 2차 정규화 : 주식별자에 종속적이지 않은 속성을 분리
3) 3차 정규화 : 속성에 종속적인 속성을 분리
4) 보이스-코드 정규화 : 다수의 주식별자 분리
5) 4차 정규화 : 다가 종속(Multi-Valued Dependency) 속성 분리
6) 5차 정규화 : 결합종속(Join Dependency)일 경우는 두개이상의 N개로 분리

* 5차 정규화는 실제 프로젝트에서는 거의 발생하지 않는다.

1.7 ERD 표기법
ERD 작성 순서
엔티티타입을 그린다. -> 엔티티타입을 적걸하게 배치한다. -> 엔티티타입간 관계를 설정한다. -> 관계명을 기술한다. -> 관계의 참여도를 기술한다. -> 관계의 필수여부를 기술한다.

ERD에서 엔티티타입의 배치방법
1) 업무를 진행하는 순서에 따라 엔티티타입을 왼쪽 편부터 오른쪽으로 그리고 위에서 아래로 표시한다.
2) 업무 흐름에 중심이 되는 엔티티타입, 보통 업무 흐름에 있어 중심이 되는 엔티티타입은 타 엔티티타입과 많은 관계를 가지고 있으므로 중앙에 배치한다.
3) 업무를 진행하는 중심 엔티티타입과 관계를 갖는 엔티티타입들은 중심에 배치된 엔티티타입의 주위에 배치하도록 한다.

2.1. 엔티티타입 정의
분석 초기에 엔티티타입을 선정하기 위한 자료
1) 업무와 관련해서 설명한 업무 기술서를 이용한다.
2) 현업 담당자와의 인터뷰를 활용하라
3) 현업의 장표를 활용한다.
4) 기존 시스템이 이미 구축되어 있다면 기존 시스템의 산출물을 검토한다.
5) DFD를 통해 업무분석을 진행하였다면 DFD의 DATA STORE를 활용하여 엔티티타입을 도출할 수 있다.
6) 현업의 업무를 직접 견학하고 인터뷰와 업무기술서에서 누락된 정보가 있는지 검토해야 한다.

엔티티 선정 작업 방법
1) 업무기술서, 장표, 인터뷰 정리문서 등에서 명사를 구분한다.
2) 개념이 불분명한 것, 광범위한 것은 제거한다.
3) 엔티티타입의 특성이거나 속성의 값은 제거한다.
4) 업무 프로세스에 해당되는 명사는 제거한다.
5) 중복되는 명사는 제거한다.
6) 누락된 엔티티타입이 존재하는지 유추해 본다.

엔티티 정의서 작성 시 포함 항목
1) 엔티티타입명
2) 엔티티타입 설명
3) 동의어/ 유의어
4) 엔티티타입 구분

엔티티타입 분석 과정
1) 엔티티타입 도출 방법에 의해 엔티티타입을 선정한다.
2) 선정된 엔티티타입에 대한 초기 엔티티정의서를 작성한다.
3) 고객과 검증 회의를 한다.
4) ERD에 엔티티타입을 표현한다.

2.2. 관계 정의
관계에 있어서 중요한 점 3가지 : 방향, 카디낼리티(CARDINALITY), 선택도

엔티티타입 사이의 관계 선정 방법
1) 업무 기술서, 장표, 인터뷰 정리 문서 등에서 동사를 구분한다.
2) 도출된 엔티티타입과 관계를 이용하여 관계 정의서를 작성한다.
3) 고객에게 질문하여 관계를 더 세분화하고 정확하게 도출하는 작업을 한다.
4) 데이터모델링 툴이나 칠판, 포스트잇을 이용하여 모델을 직접 그려본다.
5) 고객과 질문하고 협의하여 모델을 검토하는 시간을 갖는다.

2.3 식별자 정의
엔티티타입의 식별자가 가지는 특징
1) 식별자에 의해 엔티티타입 내에 모든 엔티티들이 유일하게 구분되어야 한다.
2) 특정 엔티티타입의 식별자가 지정되면 그 식별자는 변하지 않아야 한다.
3) 식별자가 지정되면 반드시 데이터 값이 존재해야 한다.

식별자의 구분
1) 주식별자 / 보조식별자
2) 내부식별자 / 외부식별자
3) 단일식별자 / 복합식별자

주식별자 선정 기준
1) 가능하면 해당 업무에서 자주 이용되는 속성을 주식별자로 지정한다.
2) 명칭, 내역 등과 같이 이름으로 기술되는 것들은 가능하면 주식별자로 지정하지 않도록 한다.
3) 만약 주키로 선정하는 속성이 복합으로 구성되어 주식별자가 될 때 가능하면 주식별자를 선정하는 속성 수가 7~8개가 넘지 않도록 한다.

2.4. 속성 정의
속성의 중요한 원리 : 각각의 속성은 반드시 하나의 엔티티타입 속에 있어야 하고 전체 데이터모델에서 하나의 의미만을 가져야 한다.

속성을 발견할 수 있는 방법
1) 해당 업무의 자료를 수집하는 동안 업무 사실에 근거해서 속성을 발견할 수 있다.
2) 엔티티타입을 추출하는 동안(현 시스템 분석을 포함하여) 어느 정도 안정적이고 확실한 속성을 대략 60~70% 정도 분석할 수 있다.
3) 프로세스 모델링을 진행하는 동안 업무 기능에 따라 관련 있는 속성 정보를 10~20% 정도 얻을 수 있다.
4) 나머지 10% 정도는 데이터모델과 프로세스 모델 상호를 교차 검사하는 상관 모델링 단계에서 도출이 된다.

속성의 원칙
1) 엔티티타입 내에서 한 속성값으 ㄴ한 시점에 한 개의 값만 가지는 것이 원칙이다.
2) 시간에 따라 엔티티타입 내 속성값이 변할 수 있다. 이러한 속성을 '다중값 속성'이라 하며, 이경우 새로운 엔티티타입을 생성해야 한다.

속성을 더 상세하게 분석하고 적용하기 위한 방법
1) 데이터가 어떤 특징을 가지며, 어떤 부류에 속하는지 정의한다.(BASIC, DESIGNED, DERIVED)
2) 그 속성이 값을 반드시 필요로 하는지를 정의한다.
3) 그 속성은 반드시 정해진 값만 가져야 하는지를 정의한다.

2.5. 도메인 정의
도메인 : 데이터모델링에서 도메인이란 엔티티타입 내에 속성에 대한 데이터타입과 크기, 제약 사항을 지정하는 것이다.

도메인 정의에 대한 유형
1) 코드에 대한 도메인은 그룹으로 모으지 않고, 모두 개별로 도메인을 생성한다.
2) 번호, 일련번호 즉 데이터모델에서 주식별자 관리를 위해 인공적으로 생성한 속성에 대해 도메인을 별도로 부여하여 관리하는 것이다.
3) 일반적인 속성은 그 성격에 따라 그룹으로 묶되 길이나 데이터타입 별로 묶는 것보다는 속성이 의미하는 분류대로 도메인 분류를 구성하는 것이 좋다.

도메인 정의 방법
1) 데이터의 모든 속성을 나열한다.
2) 모든 속성 중에 뒤부터 2~4 정도를 분리해 본다.
3) 공통으로 발생하는 접미어를 분리하여 하나로 만든다.
4) 분리된 접미어를 비슷한 것끼리 묶어 그룹을 만들어 이름을 부여한다.
5) 각 도메인 별로 데이터 타입과 길이를 지정한다.
6) 각 엔티티타입의 속성에 도메인을 할당한다.

2.6. 용어사전 정의
용어 도출 과정
1) 엔티티타입의 속성명을 모두 한곳에 모아 기술한다.
2) 속성명을 업무에서 사용하는 단어의 단위로 분리한다.
3) 각각의 단위 속성에 의미를 기술하고 물리 속성명을 업무 특성에 적합하게 정의한다.
4) 물리 속성명 명명 규칙을 정한다.
5) 단위 속성명에 따라 엔티티타입의 모든 속성명에 대해 논리 속성명을 일치시키고 물리 속성명은 생성해 주도록 한다.

3.1. M:N 관계해소 방법
관계엔티티타입 : 프로젝트를 진행하는 도중 많이 발생되는 엔티티타입으로 대부분 도출되지 않은 업무 규칙이 새롭게 발견되었거나 이력 관리와 같이 업무 규칙을 추가하는 작업에 의해 많이 도출된다.

M:N 관계 해소 방법
1) 관계 엔티티타입 분리
2) PRIMARY KEY 통합
3) 부모 엔티티타입에 속성 추가

3.2. 1:1 관계 해소 방법
1) 별개의 엔티티타입으로 따로따로 표현하는 방법
2) 하나의 엔티티타입으로 완전히 통합하는 방법
3) 부분 통합을 하는 방법
4) 수퍼 엔티티타입 생성

3.3. 엔티티타입의 통합은 어떻게 할 것인가?
엔티티타입을 통합하는 목적
1) 여러 엔티티타입에 있는 비슷한 정보를 한군데서 표현하므로 종합적으로 정보를 조회하는 작업이 용이해진다.
2) 비슷한 속성이 합해지므로 엔티티타입 간 중복성이 제거된다.
3) 비슷한 유형의 엔티티타입이 발생할 경우 동일한 규칙에 따라 하나의 엔티티타입으로만 표현이 가능하다.

엔티티타입이 통합되었을 때 나타나는 문제점
1) 업무의 확장성이 감소할 수 있다.
2) 엔티티타입이 한 군데에 모두 표현되었기 때문에 업무 흐름을 데이터모델만 가지고 이해하기는 쉽지 않다
3) 시스템 성능이 저하될 수도 있다.
4) 여러 엔티티타입의 속성이 존재하므로 필요시 속성에 제약을 걸어야 하는데 제약을 걸지 못하는 경우가 발생한다.
5) 서로 다른 성격의 엔티티타입이 한 군데 있으므로 체크해야 할 조건이 늘어난다.
6) 두 개의 엔티티타입이 각각 다른 PK를 가지면서 통합되었을 경우 두 엔티티를 동시에 한 ROW로 표현하기 위해 조회해야 할 경우 SQL 문장은 작성하기 힘들거나 복잡해진다.

엔티티타입을 통합하는 순서
1) 엔티티타입과 PK 그리고 PK와 관련된 업무 규칙을 통합한다.
2) 관계와 관계에 의해 발생된 FK 그리고 FK와 관련된 업무규칙을 통합한다.
3) 속성과 속성에 관련된 업무규칙을 통합한다.

엔티티타입을 통합하는 경우
1) PK가 동일한 엔티티타입
2) 두 엔티티타입의 PK가 꼭 일치하지는 않지만 엔티티타입의 성격이 비슷하여 둘 중 하나의 PK를 선택하여 통합하여도 나머지 PK는 ALTERNATE KEY로 이용될 수 있는 경우에 두 엔티티타입은 통합 대상이 된다.
3) 두 엔티티타입의 PK가 일치하지는 않지만 도메인이 비슷하고 엔티티타입에 포함된 속성이 비슷할 경우 하나의 엔티티타입으로 통합할 수 있다.
4) 복합 PK를 가진 엔티티타입에서 두 엔티티타입의 PK 구성이 전혀 다르더라도 PK를 구성하는 복합 속성 중 일부의 비슷한 속성을 이용하여 통합 엔티티타입을 구성할 수 있다.

3.4. 코드 엔티티타입 설계 방법
코드 : 업무적으로 또는 정보화시스템에서 구분하기 쉽도록 데이터들을 간단하게 구분해 놓은 단위

업무코드의 2가지 형식
1) 한 가지 코드값이 반복적으로 나타나는 경우
2) 한 가지 코드에 대해 여러 개의 속성이 반복되어 나타나는 경우

한 가지 코드 값이 반복적으로 나타나는 경우 데이터모델링 방법
1) 코드 구분에 대해서 먼저 설계한다.
2) 상세 코드와 코드값을 조사한다.
3) 엔티티타입을 설계한다.
4) 각각의 코드에 별도의 제약이 있을 수 있는 것을 가정하여 설계한다.

한 가지 코드에 대해 여러 개의 속성이 반복되어 나타나는 경향이 있는 유형에 대한 데이터 모델링
1) 보통 일반적인 엔티티타입 설계와 마찬가지로 설계한다.
2) 각각의 코드에 따라 여러 개의 속성이 존재하며 벼도의 엔티티타입으로 관리하도록 한다.

3.5. 도미노 속성에 대한 데이터모델링 방법
도미노 속성 : 앞의 값에 규칙적인 제약이 연쇄적으로 발생하는 경우

도미노 속성의 데이터 모델링 방법
1) 해당 업무에서 도미노가 발생할 수 있는 최대값을 정의하여 모델링하는 방법
2) 도미노 속성을 BOM을 이용하여 모델링하는 방법

도미노 속성의 활용
1) 도미노 속성 전체를 하나의 속성처럼 활용하는 형태이다.
2) 사용자 인터페이스에서 앞 값에 의해 뒤의 값이 한정되어 보여주는 경우이다.

3.6. 메시지 엔티티타입 설계 방법
메시지 데이터모델링 방법
1) 업무와 관련하여 개발하고자 하는 시스템과 연관된 모든 메시지를 조사한다
2) 메시지 성격에 맞게 데이터모델링을 진행한다.

3.7. 이력 엔티티타입 설계 방법
이력 관리 : 하나의 업무단위가 시간이 흐름에 따라 발생하는 과거와 현재 데이터를 지속적으로 유지하는 관리방법

이력이 발생하는 유형
1) 하나의 엔티티타입이 변경되었을 때 변경 이전과 이후의 데이터르 ㄹ모두 관리하는 변경 이력
2) 년,월,일 등 시간 순으로 발생하는 발생 이력
3) 업무 진행 상태에 따라 업무의 상태 정보를 관리하는 진행 이력

4.1. 업무 기능 분해
업무기능 : 기업의 임무를 한층 더 멀리 조명하여 하나로 표현하는 완벽한 단위 업무기능의 그룹 (ex:영업,회계)
프로세스 : 업무기능을 분해하면서 나타나는 각각의 업무기능 중 세분화된 업무 구분을 의미할 뿐만 아니라 업무의 실행 단위가 되면서 정보의 입출력이 되는 단위
업무기능 분해 : 업무기능을 단위 프로세스가 도출될 때까지 지속적으로 나누어 가는 과정

업무기능 분해의 목적
1) 정보화시스템을 구축하는 가장 최저 단위의 단위 프로세스를 도출하기 위함이다.
2) 전체 업무의 체계를 프로세스를 중심으로 도식화하여 업무에 대한 기능을 파악하는 것이다.

프로세스 판단 기준
1) 해당 업무 기능이 실행 단위인지 관리 단위인지 확인
2) 업무 기능에 입력과 출력의 행위가 이루어지는지를 확인

업무기능 분해 방법
1) 해당 업무에서 단일 업무기능으로 정의하고자 하는 큰 구분, 즉 뿌리 기능을 지정한다.
2) 단일기능ㅇ으로 정의해 놓은 업무기능을 더 세부적으로 쪼개어 나간다.
3) 기능들을 업무 발생 순서대로 업무기능 분해도에 배치한다.
4) 단위 프로세스가 도출될 때까지 모든 업무기능에 대해 위 작업들을 반복적으로 수행한다.

업무기능 분해를 하기 위한 자료
1) 해당 업무를 구체화하여 업무기능을 분해한다.
2) 업무기능의 생명주기를 분석하여 업무기능을 분해한다.
3) 엔티티의 상태를 이용하여 업무기능을 분해한다.
4) 업무 이벤트에 따라 기능을 분해한다.
5) 데이터의 구조에 따라 기능을 분해한다.

4.2. 단위 프로세스의 도출
단위 프로세스 검증 방법
1) 단위 프로세스의 실행은 업무 데이터를 변형하는데 모두 필요하고 모든 데이터의 무결성 규칙을 보장하는 변함없는 상태를 유지하는 역할을 한다.
2) 프로세스는 서로 밀접하게 관련이 있는 형제 프로세스와 동시에 데이터 집합에 작용한다.
3) 각각의 프로세스는 적어도 하나의 이벤트에 대해 응답이 존재해야 한다.
4) 어느 단위 프로세스도 데이터에 전혀 상관없이 독립적으로 수행해서는 안된다

4.3. 단위 프로세스와 데이터
CRUD 문서등을 통해 단위 프로세스와 엔티티타입 간의 관계를 정리해 볼 수 있다.

5.1. CRUD MATRIX 상관 모델링
CRUD MATRIX 체크사항
1) 모든 엔티티타입에 CRUD가 한 번 이상 표기되었는가?
2) 모든 엔티티타입에 "C"가 한 번 이상 존재하는가?
3) 모든 엔티티타입에 "R"가 한 번 이상 존재하는가?
4) 모든 단위 프로세스는 하나 이상의 엔티티타입에 표기가 되었는가?

CRUD MATRIX를 이용함으로써 프로젝트에서 얻을 수 있는 장점
1) 분석단계의 데이터모델과 프로세스 모델에 대한 작업을 검증하는 역할을 한다.
2) 시스템 구축단계에서 애플리케이션을 개발하는데 필요한 주요한 산출물이 된다.
3) 테스트 단계에서 개발한 애플리케이션을 객관적인 자료를 사용하여 테스트하는 데도 중요한 역할을 한다.
4) 전체 업무의 인터페이스를 파악할 수 있다.

5.2. 엔티티타입 생명 주기 분석
엔티티타입 생명 주기 분석 : 엔티티타입을 중심으로 엔티티타입과 관계된 프로세스만을 표기하여, 엔티티타입 내에 엔티티들이 어떠한 생명주기를 가지고 있는지 검증하는 방법이다.

2가지 측면의 검토
1) 업무적 측면의 검토 : 모델링이 시스템의 업무적 요건을 충분히 반영하고 있는지, 모델링의 관계가 해당 업무 프로세스에 잘 부합하는지 검토한다.
2) 모델규약 측면의 검토 : 데이터모델링이 갖추어야 할 모델링에 관한 일반적인 규약을 잘 준수하고 있는지 검토한다.

6.1. 엔티티타입 검토
엔티티타입 검토 시 검정해야 할 내역
1) 선정된 PK가 업무적으로 발생하는 자료의 유일성을 보장하는가?
2) 선정된 PK는 효율적인 모습을 가지고 있는가?
2.1) 선정된 속성은 해당 업무에 대해서 대표성을 가지는가?
2.2) 최소의 속성으로 자료의 유일성을 확보할 수 있는가?
3) 자료의 발생유형이 유사한 엔티티는 통합되었는가?
4) 독립된 엔티티타입이나 엔티티타입의 그룹은 존재하지 않는가?
5) 병합 또는 분리되어야 할 엔티티타입은 존재하지 않는가?
6) 추가적으로 도출되어야 하거나 불필요한 엔티티타입은 없는가?
7) 엔티티타입이 주변 여러 엔티티타입의 공통 엔티티타입의 경우, 자료 원천이 어느 엔티티타입인지 추적가능한가?

6.2. 속성 검토
속성에 대해 검증해야 할 내역
1) 반정규화된 속성은 식별되는가?
2) 반정규화는 시스템 복잡도와 성능을 고려하여 적절하게 이루어졌는가?
3) 명칭이 같은 속성의 타입과 크기는 동일한가?
4) 내부적인 속성을 갖고 있는 속성은 존재하지 않는가?
5) 병합되어야 할 속성은 존재하지 않는가?
6) 전후 레코드 간 영향을 미칠 수 있는 속성은 없는가?
7) 감사, 통계 등을 고려하여 속성이 정의되었는가? (코드화할 수 있는 텍스트는 코드화 되었는가?)

6.3. 관계 검토
관계들에 대해 검증해야 할 내역
1) 엔티티타입 간의 관계가 M:N인 속성은 없는가?
2) 엔티티타입 간의 관계는 업무적 흐름과 규약이 일치하는가?
3) 업무적 흐름에 비추어 미 도출된 관계는 없는가?
4) 관계에 대한 표현은 적절한 수준에서 이루어졌는가?

6.4. 도메인 검토
1) 도메인이 적절히 정의되어 관리되고 있는가?
2) 도메인의 변경에 따라 속성이 변경되고 있는가?

7.1. 관계형 테이블로 전환
ERD를 테이블 관계도로 변환하는 항목
1) 엔티티타입은 테이블로 전환한다.
2) 주식별자는 PK로 변환한다.
3) 속성은 컬럼으로 변환한다.
4) 관계에 의한 외부 식별자는 FK로 변환한다.

엔티티타입을 테이블로 구성하는 방법
1) 독립 엔티티타입은 독립 테이블로 전환한다.
2) 완전종속 엔티티타입은 완전종속 테이블로 전환된다.
3) 부분 종속 엔티티타입은 부분 종속 테이블로 전환된다.
4) 주식별자를 PK로 전환한다.
5) 관계는 FK로 변환된다.

물리 모델에서 PK의 특징
1) 데이터 모델의 주식별자는 PK로 전환된다.
2) 무결성제약을 유지시키는 역할을 한다.
3) PK는 테이블이 있는 각각의 ROW를 유일하게 식별한다. PK 이외에 로우를 유일하게 식별하게 하는 대체키가 존재할 수 있다.
4) PK는 NULL값을 갖지 않는다.
5) PK는 변경되지 않으며 업무적으로 변경이 발생한다는 것은 테이블에서는 삭제와 입력이 동시에 발생하는 것을 의미한다.
6) 가능하면 모든 테이블에 PK를 정의한다.

7.2. 반정규화
반정규화 : 정규화된 엔티티타입, 속성, 관계를 시스템의 성능 향상, 개발과 운영을 단순화하기 위해 데이터 모델을 통합하는 프로세스를 의미한다.

반정규화 절차
1) 반정규화의 대상을 조사한다.
2) 반정규화의 대상을 다른 방법으로 처리할 수 있는지 검토한다. (뷰, 클러스터링, 인덱스 조정, 파티셔닝 기법 등)
3) 반정규화를 적용한다.

반정규화 방법 3가지
1) 테이블 반정규화 방법 (테이블 병합, 테이블 분할, 테이블 추가)
2) 컬럼 반정규화 방법 (중복컬럼 추가 -> 파생컬럼추가 -> 이력 테이블 컬럼 추가 -> PK에 의한 컬럼 추가 -> 응용 시스템의 오작동 처리를 위한 컬럼 추가)
3) 관계 반정규화 방법 (데이터 조회 경로를 단축하기 위해 일반 컬럼 또는 PK 컬럼을 중복하는 방법)

7.3. 무결성 제약 정의
참조 무결성의 종류
1) 입력 참조 무결성
2) 수정 참조 무결성
3) 삭제 참조 무결성

입력 참조 무결성 : 각 테이블에 레코드가 생성될 때 자신이 참조하고 있는 테이블의 PK에 대해 데이터의 정합성을 일치시켜 주는 기능

입력 참조 무결성을 유지하기 위한 방법
1) 의존 : 자신의 테이블에 데이터를 입력할 때, 참조하고 있는 테이블의 PK가 존재해야만 데이터 입력이 가능하다.
2) 자동 : 자신의 테이블에 데이터를 입력할 때, 참조하고 있는 테이블의 PK가 존재하지 않으면 PK를 생성하고 자신의 테이블에 데이터를 생성한다.
3) 기본 : 자신 테이블의 레코드를 입력할 때, 참조하는 테이블의 PK를 기본값으로 바꾼 후 자신의 레코드를 입력한다.
4) 지정 : 사용자가 정의 해 놓은 일정한 조건을 만족한 이후에 자신의 레코드를 입력한다.
5) NULL : 자신 테이블의 레코드를 입력할 때 참조하는 테이블의 PK가 없어도 그대로 입력한다.

수정 참조 무결성 : 자신이 참조되는 모든 테이블의 FK 정보와 일치를 위해 자신의 PK가 수정되면 관련된 모든 테이블의 FK 정보와 일치를 위해 자신의 PK가 수정되면 관련된 모든 테이블의 FK도 수정하여 데이터의 정합성을 유지하는 기능이다.

수정 참조 무결성을 유지하기 위한 기능
1) 제한 : 자신 테이블의 PK를 수정하면 자신을 참조하는 테이블의 FK가 없어야 한다.
2) 연쇄 : 자신 테이블의 PK를 수정하면 참조되는 모든 테이블의 FK를 수정하고 자신 DML PK도 수정한다.

삭제 참조 무결성 : 자신이 참조되는 모든 테이블의 FK 정보와 일치를 위해 자신의 PK가 삭제되면 관련된 모든 테이블의 FK를 기본값이나 NULL로 수정하여 데이터의 정합성을 유지하는 기능이다.

삭제 참조 무결성을 유지하기 위한 기능
1) 제한 : 자신 테이블의 레코드를 삭제하려면 자신을 참조하는 테이블의 레코드가 없어야 한다.
2) 연쇄 : 자신 테이블의 레코드를 삭제하려면 참조되는 모든 테이블의 레코드를 삭제하고 자신을 삭제한다.
3) 기본 : 자신 테이블의 레코드를 삭제할 때 참조되는 모든 테이블의 레코드를 기본값으로 바꾼 후 자신의 레코드를 삭제한다.
4) 지정 : 사용자가 정의 해 놓은 일정한 조건을 만족한 이후에 자신의 레코드를 삭제한다.
5) NULL : 자신 테이블의 레코드를 삭제할 때 참조되는 모든 테이블의 레코드를 NULL로 바꾼 후 자신의 레코드를 삭제한다.
6) 미지정 : 자신 테이블의 레코드를 삭제해도 특별한 참조 무결성 규칙을 적용하지 않는 경우이다.

참조 무결성 적용시 주의사항
1) DBMS에 참조 무결성 원칙을 과다하게 적용할 경우 데이터베이스의 성능을 저하시키는 주요한 이유가 될 수 있다.

FK 제약이 걸려 있는 컬럼들의 인덱스 생성
1) FK 제약이 걸려 있는 컬럼들은 가능하면 인덱스를 걸어 줄 것을 권유한다. (업무상 인덱스를 사용하지 않더라도 DBMS 내부적으로 사용)

7.4. 트랙잭션 분석
트랜잭션 분석 절차
1) 트랜잭션 정의 : 데이터베이스에 행해지는 작업의 논리적인 단위
2) 트랜잭션 분석 : 단위 프로세스와 CRUD MATRIX를 이용하여 트랜잭션 분석서를 작성한다.
3) 트랜잭션 분석도 이용 (용량 산정의 근거자료로서 이용, 디스크 구성의 이용, 데이터베이스와 연결되는 채널의 분산)

7.5. 뷰 설계
뷰의 특징
1) 테이블의 구조를 단순화한다.
2) 다양한 관점에서 데이터를 제시할 수 있다.
3) 데이터의 보안을 유지한다.
4) 논리적인 데이터의 독립성을 제공한다.

뷰의 정의
1) 뷰의 대상이 되는 테이블을 선정한다.
2) 뷰의 대상이 되는 컬럼을 선정한다.
3) 뷰 정의서를 작성한다.

7.6. 인덱스 설계
인덱스 대상 선정
1) 대상 테이블 선정 (테이블 크기가 64KB [1BLOCK 크기 * MULTI BLOCK READ] 이내인 경우 인덱스를 지정하지 않아도 된다. 단 테이블이 참조관계 또는 조인에 의해 처리되어야 하는 경우는 인덱스를 생성해 주어야 한다.)
2) PK 컬럼,FK 컬럼은 인덱스를 설정해야 한다. ( 각각 조인과 참조관계가 발생하기 때문이다.)
3) 테이블 내에서 자주 이용되며 분포도가 좋은 컬럼[평균 분포도 : 10~15%]은 인덱스 지정 대상 컬럼이 된다.
(분포도(%) = 데이터별 평균 로우 수 / 테이블의 총 로우 수 * 100)


인덱스 최적화
1) 인덱스 효율 검토
(인덱스 컬럼은 가능하면 수정이 자주 발생되지 않는 컬럼을 선정한다.
분포가 일정하지 않고 기형적으로 불균형하면 인덱스를 설정하지 않는 것이 낫다.
한 테이블에 인덱스 개수가 5개를 초과한 경우에는 테이블의 입력, 수정, 삭제가 자주 발생하는지 검증하고, 만약 자주 발생한다면 꼭 필요한 인덱스를 남기고 삭제하도록 한다.)
2) 인덱스 데이터 타입 적용 (길이가 가변일 경우 VARCHAR를 이용한다.)
3) 인덱스 정렬
4) 클러스터링 검토 (인덱스와 반대로 분포도가 넓은 것이 좋다. 나머지 성격은 인덱스와 비슷하며, 대량의 데이터 처리에는 적합하지 않다.)

인덱스 정의서 작성

7.7. 데이터베이스 용량 설계
데이터베이스 용량 설계 : 물리 데이터베이스 설계에서 데이터가 저장되는 공간을 정의하는 작업

데이터베이스 용량 분석의 목적
1) 정확한 데이터 용량을 산정하여 디스크 사용의 효율을 높인다.
2) 디스크 구성방법에 따라 디스크 입출력이 달라질 수 있지만 기본적으로 업무량이 집중되어 있는 디스크를 분리하여 설계함으로써 집중화된 디스크에 대한 입출력 부하를 분산시킬 수 있다.
3) 똑같은 자원에 여러 프로세스가 동시에 접근할 때 발생하는 디스크 입출력 경합을 최소화하여 데이터의 접근 성능을 향상시킨다.
4) 데이터베이스 오브젝트의 익스텐트 발생을 줄인다.

데이터베이스 용량 분석 절차
1) 용량 분석을 위한 기초 데이터를 수집한다. (ROW 길이, 보존기간, 초기건수, 발생건수, 발생주기, 년 증가율)
2) 기초 데이터를 이용하여 DBMS에 이용하는 오브젝트 별로 용량을 산정한다.

테이블 크기 계산 방법
1) 총 블럭 헤더 크기를 계산
TOTAL BLOCK HEADER   = BLOCK HEADER, PART A + BLOCK HEADER, PART B
BLOCK HEADER, PART A = (FIXED HEADER + VARIABLE TRANSACTION HEADER)
BLOCK HEADER, PART B = (TABLE DIRECTORY + ROW DIRECTORY)

- FIXED HEADER : 57 BYTE (고정된 블럭 헤드)
- VARIABLE TRANSACTION HEADER : 23 * I (I는 해당 TABLE의 INITRANS의 값)
- TABLE DIRECTORY : 4
- ROW DIRECTORY : 2*R (R은 블럭의 ROW 수-R(AVG.# OF ROWS/BLOCK))

2) 데이터 블럭 당 사용 가능한 데이터 영역을 계산
AVAILABLE DATA SPACE = (BLOCK SIZE - TOTAL BLOCK HEADER) - ((BLOCK SIZE - BLOCK HEADER, PART A) * (PCTFREE/100))

- BLOCK SIZE : 데이터베이스의 블럭 크기 (SVRMGRL의 SHOW PARAMETER에서 DB_BLOCK_SIZE를 확인)

3) 평균 ROW의 전체 컬럼의 길이를 계산
ROW 길이를 계산하기 위하여 테이블 정의에서 컬럼 수, 각 컬럼의 데이터 타입, 가변 길이 컬럼의 평균 크기 등을 참조한다.

D(DATA SPACE/AVERAGE ROW) : 테이블 ROW의 평균 길이

4) 총 평균 ROW 크기를 계산
BYTE/ROW = ROW HEADER + F + V + D

- ROW HEADER : ROW당 3BYTES (NON-CLUSTERED TABLE)
- F : 250 BYTES 이하를 사용하는 컬럼의 TOTAL LENGTH BYTES (각 컬럼 당 1 BYTE)
- V : 250 BYTES 이상를 사용하는 컬럼의 TOTAL LENGTH BYTES (각 컬럼 당 3 BYTE)
- D : D(DATA SPACE/AVERAGE ROW)

5) 데이터 블록 내의 평균 ROW 수를 계산
R(AVG.# OF ROWS/BLOCK) = AVAILABLE SPACE / AVERAGE ROW SIZE

- AVAILABLE SPACE : AVAILABLE DATA SPACE (데이터 블럭 당 사용 가능한 데이터 영역)
- AVERAGE ROW SIZE : BYTE/ROW (총 평균 ROW 크기)

6) 테이블에서 요구되는 블럭과 바이트 수를 계산
BLOCKS FOR TABLE = # ROWS / R

# ROWS : 테이블의 ROW 수
R : R(AVG.# OF ROWS/BLOCK)

BYTES FOR TABLE = # BLOCKS FOR TABLE * BLOCK SIZE

인덱스 크기 계산 방법
1) 블록 헤더 크기 계산
BLOCK HEADER SIZE = FIXED HEADER + VARIABLE TRANSACTION HEADER
- FIXED HEADER : 113 BYTE
- VARIABLE TRANSACTION HEADER : 27*I (I는 인덱스에 대한 INITRANS)

2) 데이터 블록 당 사용 가능한 데이터 영역 계산
AVAILABLE DATA SPACE PER BLOCK = (BLOCK SIZE - BLOCK HEADER SIZE) - ((BLOCK SIZE - BLOCK HEADER)*(PCTFREE/100))

3) 결합된 열 길이 계산
- 바이트 길이를 포함한 컬럼 크기 계산
COLUMN SIZE INCLUDING BYTE LENGTH = COLUMN SIZE + (IF COUUMN SIZE < 250 1 ELSE 3)

- 열 크기 계산
ROWSIZE = ROW HEADER(3*UB1) + SUM(COLUMN SIZE INCLUDING BYTE LENGTH)

- 행 당 사용되는 영역
SPACE USED PER ROW (ROWSPACE) = MIN(UB1*3 + UB4 + SB2, ROWSIZE) + SB2

4) 인덱스 값 크기의 전체 평균 계산
BYTES/ENTRY = ENTRY HEADER + ROWID LENGTH + F + V + D
- ENTRY HEADER : 2 BYTE
- ROWID LENGTH : 6 BYTE
- F : 127 BYTE 이하를 저장하는 모든 열의 전체 길이 바이트, 이 유형의 열에 필요한 길이 바이트 수는 1 BYTE
- V : 127 BYTE 이상를 저장하는 모든 열의 전체 길이 바이트, 이 유형의 열에 필요한 길이 바이트 수는 2 BYTE
- D : 테이블 ROW의 평균 길이

5) 인덱스 값 크기의 전체 평균 계산
BLOCK FOR INDEX = 1.05 * NOT NULL ROWS / FLOOR(AVAILABLE DATA SPACE PER BLOCK / AVG. ENTRY SIZE)

테이블 스페이스 용량 산정방법
테이블스페이스 내에 생성되는 테이블의 용량을 더한 값에다 추가로 40%를 더한 값을 기입한다.


디스크 용량 산정방법
데이터베이스에 저장될 모든 데이터 용량과 데이터베이스를 설치하고 관리하기 위한 시스템 용량을 더하여 여유있게 산정한다.

7.8. 접근방법 설계
접급 방법 구분
직접 접근 : 스캔
간접 접근 : B-TREE 인덱스, 비트맵 인덱스, 해싱
저장 방법에 따른 접근 : 클러스터링

스캔방식
테이블에 있는 데이터를 검색할 때 순차적으로 로우를 비교하여 원하는 데이터를 가져오는 접근 방법이다.
전체스캔과 범위스캔이 있다.

스캔 방식을 적용하는 경우
1) 테이블의 크기가 작을 때, 즉 물리적인 블록에 6블록 정도까지 데이터가 점유하고 있을 때는 스캔 방식으로 데이터를 읽어도 처리 속도가 빠르다.
2) 테이블의 가져오려는 데이터의 분포도가 20%를 초과할 때 스캔 방식으로 처리한다.

B-TREE 인덱스의 기본구조
B-TREE 인덱스는 TREE 구조를 가지고 있다. TREE는 LEAF BLOCK, BRANCHED BLOCK, ROOT BLOCK로 구성되어 있다.
1) LEAF BLOCK : 테이블의 각 레코드의 인덱스 정보를 가지고 있는 블럭이다.
2) BRANCHED BLOCK : LEAF BLOCK과 ROOT BLOCK의 중간에서 블럭 사이의 정보에 대한 다리 역할을 하는 블럭이다.
3) ROOT BLOCK : TREE의 최상위 수준에 위치하며, 조회, 입력, 수정, 삭제가 발생하면 제일 먼저 접근된다.

비트맵 인덱스
컬럼정보를 0과 1을 이용하여 별도의 인덱스로 저장하는 방법으로, WHERE 조건의 AND나 OR 연산에 의해 데이터를 검색하는 방법이다.

비트맵 인덱스의 검색 원리
비트맵 인덱스는 레코드의 물리적인 ROW ID 값을 가지고 있지 않지만 ROW ID 값을 계산해서 추적할 수 있다.

B-TREE 인덱스와 비트맵 인덱스 비교
1) B-TREE : 인덱스의 크기가 크므로 상대적으로 소량의 데이터를 검색할 때 유리하다. TREE 알고리즘에 의해 손쉽게 입력, 수정, 삭제가 가능하다. AND 연산에는 좋은 성능을 나타내나, OR, != 등에서는 성능에 취약하다. 데이터 분포도가 높은 컬럼에 적합하다. OLAP에 유리
2) 비트맵 : 인덱스의 크기가 작으므로 상대적으로 대량의 데이터를 읽을 때 유리하다. 입력, 수정, 삭제는 전체 인덱스를 조정해야 하는 부담이 있다. 비트맵 인덱스는 비트 연산을 통해 or ,!= 등에서도 빠르게 처리할 수 있다. 데이터 분포도가 아주 낮은 컬럼에 적합하다. DSS에 유리

해싱 기법 적용
데이터의 빠른 접근을 위해 해시 알고리즘에 의해 테이블 정보를 읽는 것을 말한다.

해시 인덱스의 특징
1) 6블럭 이상 물리적인 블럭의 크기를 갖는 테이블에 적용한다.
2) 정렬 순서에 따른 접근 방식이 아니라 임의대로 접근하는 경우가 많이 발생되는 경우에 적용한다.
3) 변경이 자주 되지 않는 컬럼값에 대해 해시키를 적용한다.
4) 클러스터 키를 사용하는 비슷한 검색 조건으로부터 해시 클러스터 인덱스는 인덱스 클러스터보다 훨씬 빠른 성능을 제공한다.
5) 하나의 테이블에는 하나의 해시키만을 가질 수 있으므로 가장 많이 조회하거나 중요한 컬럼에 대해 해시키를 지정한다.
6) 해시 알고리즘은 값의 범위로 표시될 때는 사용할 수 없다.
7) 정렬되어 테이블의 데이터를 조회할 때 해시 알고리즘은 이용되지 않는다.
8) 여러 개의 컬럼을 하나의 해시키로 구성하였을 때 만약 일부에 대해서만 비교한다면 해시알고리즘은 이용되지 않는다.

클러스터링
클러스터링된 테이블이라 할지라도 인덱스를 지정하지 않으면 전체 스캔이 발생하게 되므로 클러스터링 인덱스를 생성도록 한다.

클러스터링의 특징
1) 6블럭 이상의 테이블에 적용한다.
2) 인덱스만을 이용하여 처리하기에는 데이터의 분포도가 낮은 경우에 적용한다.
3) 일정한 순서로 조회되는 경우가 많을 때 적용한다.
4) 입력, 수정, 삭제가 자주 발생되지 않을 때 적용한다.
5) 클러스터링을 생성한 기준값은 수정되지 않아야 한다.
6) 테이블이 분할되어 있지만 거의 동시에 조인하여 조회하는 때가 많은 경우에 적용한다.
7) 전체 테이블을 스캔할 경우에 일반적인 테이블보다 저장 공간을 많이 차지하게 되므로 클러스터링을 적용한 테이블의 검색속도가 더 느리다.

클러스티링을 적용하면 안 되는 경우
1) 테이블에 대해 전체 스캔이 종종 발생한다면 클러스터링을 적용하지 않는다.
2) 파티셔닝을 적용하면 클러스터링 기능을 사용할 수 없다.
3) 동일한 클러스티키를 가진 클러스터드된 데이터의 크기가 하나의 블록을 초과할 경우 클러스터링을 적용하지 않는다.

7.9. 데이터베이스 분산 설계
분산 데이터베이스 : 데이터베이스를 한 곳에 집중시켜 관리하던 중앙집중식 시스템 환경구축에서 빨라진 네트워크를 이용하여 데이터베이스를 여러 서버나 지역에 분산시켜 놓고 하나의 데이터베이스처럼 사용할 수 있게 만든 데이터베이스 체계

테이블 위치 분산
1) 테이블 위치 분산에서는 테이블의 구조는 변하지 않는다.
2) 테이블이 다른 데이터베이스에 중복되어 생성되지 않는다.
3) 설계된 테이블의 위치를 각각 다르게 위치시키는 것이다.

테이블 분할 분산
1) 각각의 테이블을 쪼개어 분산하는 방법이다.
2) 테이블을 로우 단위로 분리하는 수평분할과 컬럼 단위로 분할하는 수직분할이 있다.

테이블 복제 분산
1) 동일한 테이블을 다른 지역이나 서버에서 동시에 생성하여 관리하는 유형이다.
2) 마스터 데이터베이스에서 테이블의 일부 내용만 다른 지역이나 서버에 위치시키는 부분복제가 있고, 마스터 데이터베이스의 테이블 내용을 각 지역이나 서버에 존재시키는 광역복제가 있다.
3) 데이터를 복제하는 방버은 데이터를 복제하는 데 많은 시간이 소요되고, 데이터베이스와 서버에 부하가 발생하므로, 보통 실시간 처리로 복사하는 것보다는 야간에 배치 작업으로 수행되는 경우가 많다.

테이블 요약 분산
1) 지역 간에 또는 서버 간에 데이터가 비슷하지만 서로 다른 유형으로 존재하는 경우이다.
2) 테이블 구조가 동일하면서, 분산되어 있는 내용이 동일한 데이터를 이용하여 통합된 데이터를 산출하는 방식의 분석 요약과 분산되어 있으며 내용이 다른 데이터를 이용하여 통합된 데이터를 산출하는 방식의 통합 요약이 있다.
3) 일반 업무가 종료되는 야간에 테이블 요약 분석 작업을 수행한다.

8.1. 데이터베이스 구축을 위한 사전 준비
데이터베이스 구축을 위한 자료 : 데이터베이스 환경 정의서, 용량 산정서, 각종 오브젝트 설계서, 분산 환경 설계서

설계 단계에서 작성된 산출물 : ERD, 테이블 정의서, 인덱스 정의서, 뷰 정의서, 테이블스페이스 용량 산정서, 인덱스페이스 용량 산정서, 데이터파일 용량 산정서, 분산 설계서, 데이터베이스 환경 설계서, 시스템 파일 용량 설계서

8.2. 데이터베이스 생성
오라클에서 데이터베이스 생성하는 방법
1) 환경 파일 등을 스크립트에 지정하여 수작업으로 생성
2) ODCA 그래픽 툴을 사용하여 생성하는 방법

8.3. 테이블스페이스 생성
테이블스페이스 : 설계단계에서 정의한 각종 오브젝트가 실제 데이터 파일에 저장되기 위한 공간을 정의하는 데이터베이스 오브젝트

테이블스페이스 생성 확인
SELECT * FROM DBA_DATA_FILES

8.4. 사용자 및 역할과 권한 지정
사용자 및 역할과 권한 지정 절차
1) 사용자 생성 및 확인 (SELECT * FROM DBA_USERS)
2) 역할 생성 및 확인 (SELECT * FROM DBA_ROLES)
3) 사용자에게 권한 부여 및 확인 (SELECT * FROM DBA_ROLE_PRIVS)

8.5. 오브젝트 생성
오브젝트 생성 절차 :테이블 생성 -> 인덱스 생성 -> 뷰 생성

테이블 생성 확인
1) 테이블 확인
SELECT SEGMENT_NAME, ROUND(INITIAL_EXTENT/1024,0) INI_KB,
ROUND(NEXT_EXTENT/1024,0) NXT_KB, ROUND(BYTES/1024,0) TOT_KB,
PCT_INCREASE PCT, EXTENTS, TABLESPACE_NAME
FROM USER_SEGMENTS
WHERE SEGMENT_TYPE = 'TABLE';


2) PK 확인
SELECT a.table_name, b.constraint_name
FROM user_tables a, user_constraints b
WHERE a.table_name = b.table_name(+)
AND b.constraint_type(+) = 'P';


3) FK 확인
SELECT CONSTRAINT_NAME, R_CONSTRAINT_NAME,STATUS
FROM USER_CONSTRAINTS;


인덱스 생성
1) 인덱스 생성 확인
SELECT SEGMENT_NAME, ROUND(INITIAL_EXTENT/1024,0) INI_KB,
ROUND(NEXT_EXTENT/1024,0) NXT_KB, ROUND(BYTES/1024,0) TOT_KB,
PCT_INCREASE PCT, EXTENTS, TABLESPACE_NAME
FROM USER_SEGMENTS
WHERE SEGMENT_TYPE = 'INDEX';


뷰 생성
1) 뷰 생성 확인
SELECT OBJECT_NAME, OBJECT_TYPE, STATUS
FROM USER_OBJECTS
WHERE OBJECT_TYPE = 'VIEW';


8.6. 분산 환경 생성
오라클의 데이터베이스 간 통신을 위한 분산 환경 구성 시 전제 사항
1) 연결 대상인 데이터베이스 쪽 서버에 리스너가 기동되어 있어야 한다.
2) 연결하고자 하는 쪽에서는 오라클 클라이언트가 설치되어 있으면서 Tnsnames.ora 파일이 구성되어야 한다.
3) 로컬 데이터베이스와 원격 데이터베이스 간 데이터베이스 링크를 설정하면 분산 환경 구성이 완료된다.

스냅샷 테이블
스냅샷 테이블을 이용하여 원격 상의 테이블 내용을 동기화한다.

9.1. 데이터베이스 튜닝의 목적
튜닝을 수행하는 목적
1) 업무적인 환경과 시스템적 환경에 적합한 데이터베이스 파라미터를 설정한다.
2) 데이터베이스에 접근하는 SQL 문장은 가능한 한 디스크 블록에 최소로 접금하도록 한다.
3) 디스크 블록에서 한 번 읽은 데이터는 가능하면 메모리 영역에 보관하여 나중에 데이터를 빨리 가져오게 한다.
4) 모든 사용자의 SQL 문장은 공유가 가능하도록 대소문자 등 명명 표준을 준수하여 작성한다.
5) 잠금 발새이 최소가 되도록 한다.
6) 배치작업과 백업 작업 수행을 빠른 시간 안에 완료할 수 있어야 한다.

9.2. 데이터베이스 설계 단계에서 튜닝하기
설계단계 튜닝
1) 데이터 정합성을 유지할 수 있는 대책을 마련하고, 성능을 위해 필요하다면 테이블, 컬럼, 관계에 대해 반정규화를 적용한다.
2) 대용량 테이블의 경우 필요한 데이터에 대해서는 파티셔닝을 이용하여 테이블 분할을 검토한다.
3) 이력을 관리해야 하는 테이블에 대해서는 필요하다면 시작과 종료나 현재 진행상태 등을 명확하게 명시하여 SQL 문장의 실행 성능을 보장하도록 한다.
4) 테이블 접근 유형에 따라 전체 스캔 방식이나 B-TREE 인덱스, 비트맵 인덱스, 클러스터링과 해싱 적용 등을 고려한다.
5) 테이블이 조회를 주로 하는지 입력, 수정, 삭제 작업이 주로 발생하는지를 고려하여 적당한 인덱스 개수를 지정해야 한다.
6) 분산 데이터베이스를 적용했을 경우 원격 데이터베이스를 이용할 때 서능저하가 예산된다면 스냅샷을 이용한 복제 테이블 생성 등을 고려한다.
7) 공통적으로 관리하는 코드 데이터에 대한 접근이 빈번하다면 응용 애플리케이션의 메모리에 상주시키고 함수를 사용하여 코드 변환을 하도록 유도한다.
8) PK는 일반적으로 지정된 순서대로 인덱스를 생성하므로 KEY를 구성하는 컬럼 순서를 복합 컬럼 인덱스를 지정하는 규칙에 따라 나열한다.
9) FK에 대해서는 가급적 인덱스를 생성하여 전체 스캔이 발생하는 경우와 불필요하게 발생하는 잠금을 피하도록 한다.
10) SYSTEM 테이블스페이스에는 데이터를 관리하는 딕셔너리 정보만 포함하고, 일반 오브젝트는 저장하지 않도록 한다.
11) 테이블을 위한 테이블 스페이스와 인덱스를 위한 테이블 스페이스를 분리한다.
12) 롤백 세그먼트에 대한 경합을 피하기 위해 롤백 세그먼트를 여러 개로 구성한다.
13) 자주 수정되거나 변경 혹은 삭제되는 불안전한 데이터는 별도의 테이블 스페이스를 만들어 생성한다.

9.3. 데이터베이스 환경 튜닝
공유풀 영역 : SQL문장과 PL/SQL 문장이 저장되는 라이브러리 캐시와 데이터베이스에 관련된 각종 정보들을 저장하는 딕셔너리 캐시로 구분된다.

1) 라이브러리 캐시튜닝
1.1) SQL 문장을 재사용하는 비율 확인
SELECT GETHITRATIO FROM V$LIBRARYCACHE
WHERE namespace = 'SQL AREA'

(수치가 90% 이상 나와야 한다.)
1.2) MISS RATE 확인
SELECT SUM(reloads)/sum(pins) * 100 FROM V$LIBRARYCACHE
(MISS 비율이 1%보다 작게 나와야 한다.)
1.3) 캐시 HIT율 높이는 방법 : init.ora 파일에서 SHARED_POOL_SIZE를 늘려준다. SQL 문장에 대한 명명표준을 준수하여 동일한 문장에 대해 재파싱 작업이 일어나지 않도록 한다.
2) 딕셔너리 캐시튜닝
2.1) 딕셔너리 캐시 MISS 비율 확인
SELECT SUM(GETMISSES)/SUM(GETS) * 100
FROM V$ROWCACHE

(MISS 비율이 15%보다 작게 나와야 한다.)
2.2) MISS 비율 낮추는 방법 : SHARED_POOL_SIZE를 늘려준다.

데이터베이스 버퍼 캐시 튜닝
1) 버퍼 캐시 : SQL 문장을 실행하면 오라클은 디스크에서 데이터를 읽어들여 이를 데이터베이스 버퍼 캐시에 저장한다.
2) 버퍼 캐시 재 사용율
SELECT (1-(c.value / (a.value + b.value))) * 100
FROM v$sysstat a, v$sysstat b, v$sysstat c
WHERE a.name = 'db block gets' AND b.name = 'consistent gets' AND c.name = 'physical reads'

(80% 이하로 값이 나올 경우 DB_BLOCK_BUFFER 크기를 조절한다.)

리두로그 버퍼 튜닝
1) 리두로그 버퍼 : 모든 SQL 문장이 실행될 때 이용하는 메모리 영역
2) 리두 할당 대기율
SELECT b.misses/b.gets * 100
FROM v$latchname a, v$latch b
WHERE a.name = 'redo allocation'
AND a.latch# = b.latch#

(1% 이상 나오면 리두로그가 발생할 때 경합이 발생한 경우이다.)
3) 리두로그 버퍼를 획득하기 위해 기다린 회수
SELECT value
FROM v$sysstat
WHERE name = 'redo log space requests'


디스크 I/O 튜닝
1) 데이터 파일에 대한 I/O 현황
SELECT name,phyrds, phywrts, phyblkrd, phyblkwrt
FROM v$filestat a, v$datafile b
WHERE a.file# = b.file#


2) 데이터베이스 디스크 I/O를 줄이기 위한 방법
2.1) 시스템 테이블 스페이스를 별도로 생성한다.
2.2) 임시 테이블 스페이스는 테이블과 인덱스의 테이블 스페이스와 분리하여 생성한다
2.3) 롤백 세그먼트와 온라인 리두로그 파일은 분리하여 생성한다.
2.4) 온라인 리두로그 파일과 아카이브 리두로그 파일은 분리하여 생성한다.
2.5) 롤백 세그먼트와 테이블과 인덱스 테이블 스페이스와 분리하여 생성한다.
2.6) 테이블의 테이블스페이스와 인덱스의 테이블스페이스는 분리하여 생성한다.
2.7) 리두로그 파일은 지속적으로 I/O가 발생하므로 I/O가 가장적은 디스크에 배치한다.
2.8) 테이블과 인덱스 테이블 스페이스 중에 I/O가 많은 테이블스페이스는 별도의 디스크에 배치한다.

로우 마이그레이션과 로우 체이닝
1) 로우 마이그레이션 : 데이터 블록에서 수정이 발생하면 수정된 데이터를 해당 데이터 블럭에 저장하지 못하고, 다른 블록의 빈 공간을 찾아 데이터를 저장하는 방식

2) 로우 체이닝 : 로우 길이가 너무 길어서 데이터 블록 하나에 데이터가 모두 저장되지 않고, 두 개 이상의 블록에 걸쳐 하나의 로우가 저장되어 있는 형태

3) 로우 마이그레이션 확인
analyze table [테이블명칭] compute statistics;

SELECT num_rows, chain_cnt
FROM dba_tables
WHERE table_name = '[테이블명칭]'

(로우 마이그레이션 건수가 많은 경우 PCTFREE를 증가시킨다.)

9.4. SQL 문장 튜닝
SQL 문장 작성 시 주의사항
1) 접근 경로에 대한 우선순위를 알고 있어야 한다
2) 옵티마이져 모드가 비용기반 모드인지 규칙기반 모드인지 알고 있어야 한다
3) 숫자 형식은 숫자 형식의 타입으로 문자 형식은 문자 형식 타입으로 비교한다.
4) WHERE 절 안에 비교하는 조건에 인덱스를 이용해야 할 경우 인덱스 컬럼을 기술한다.
5) 여러 개의 컬럼이 인덱스 하나로 지정된 경우 WHERE절에 모두 기술한다.
6) 여러 개의 컬럼이 인덱스 하나로 지정된 경우 앞쪽에 있는 컬럼을 모두 지정하여 인덱스 범위를 조회할 수 있게 한다.
7) 인덱스를 이용하고자 하는 컬럼에 대해 변형을 하지 않는다.
8) 인덱스 컬럼에 NULL 값을 사용하지 않는다.
9) 부정형으로 지정할 경우에는 인덱스를 사용하지 않는다.
10) OR을 사용하면 인덱스를 이용하지 않을 수 있다.
11) 불필요하게 DUAL 테이블을 이용하지 않는다.
12) WHERE 조건 절에 걸린 인덱스가 데이터를 20% 이상 반환하리라 예상되면 인덱스 스캔을 피한다.
13) 불필요하게 DBMS에서 제공하는 함수를 사용하지 않는다.
14) 인덱스가 걸려있는 컬럼에 대해 LIKE 형식으로 비교하는 경우에는 반드시 뒷쪽에 비교자(%)가 위치해야 하며, 앞쪽에 위치할 경우에는 인덱스를 이용하지 않는다.
15) 힌트를 적절하게 사용한다.

테이블에 있는 인덱스 컬럼 조회
SELECT TABLE_NAME,INDEX_NAME, COLUMN_NAME
FROM USER_IND_COLUMNS
ORDER BY TABLE_NAME,INDEX_NAME, COLUMN_POSITION


9.5. 기타 빈번하게 성능에 영향을 주는 요소
테이블에 일련번호(순번)을 증가시키는 방법
1) 두 개의 SQL 문장으로 처리 : SELECT -> INSERT
2) MAX(컬럼) + 1을 이용한 채번 방법 : INSERT .. SELECT MAX(컬럼) +1
3) 시퀀스 테이블을 이용하는 방법
4) 채번 테이블을 이용한 채번 방법 (신규 일련번호 채번 -> 본 테이블에 데이터입력 -> 채번 테이블 수정)
5) 인덱스 역방향 정렬을 이용한 채번 방법

인덱스 관리 방안
1) 인덱스 레벨 검사
ANALYZE INDEX [인덱스명] ESTIMATE STATISTICS;

SELECT BLEVEL, LEAF_BLOCKS FROM USER_INDEXES
WHERE INDEX_NAME = '[인덱스명]'


2) 인덱스 재생성
ALTER INDEX SYS_C001724 REBUILD;

10.1. 데이터베이스의 기동과 종료
데이터베이스 기동 단계
1) 데이터베이스 NOMOUNT 단계
2) 데이터베이스 MOUNT 단계
3) 데이터베이스 OPEN 단계

데이터베이스 NOMOUNT 단계
1) 데이터베이스의 파라미터 파일을 읽는다.
2) TRACE 파일 및 ALERT 파일을 연다. 생성 정보를 alert.log 파일에 기록한다.
3) 오라클 데이터베이스에서 이용되는 공유 메모리 구조인 SGA(SYSTEM GLOBAL AREA)를 할당한다.
4) 백그라운드 프로세스를 생성한다.
5) 데이터베이스는 생성된 메모리 구조화 프로세스들과 아직 연결이 되어 있지 않다.

데이터베이스 MOUNT 단계
1) 데이터베이스를 구성하는 정보가 모두 있는 컨트롤 파일의 정보를 읽어서 디스크에 데이터 파일이나 리두 로그 파일 등이 올바로 존재하는지 또한 각 파일이 현재 사용가능한지 점검한다.
2) 데이터베이스의 백업이나 복구 시점에 많이 이용된다.
3) 데이터 파일명 변경, 리두 로그 파일 추가, 삭제, 이름변경, 아카이브모드 옵션의 변경, 전체 데이터베이스의 복구, 백업하여 데이터베이스 재생성, 불완전 데이터베이스 복구 등이 가능하다.
4) MOUNT 단계는 일반 사용자가 데이터베이스를 접속할 수 없다.

데이터베이스 OPEN 단계
1) 컨트롤 파일에 기술된 모든 데이터 파일 및 리두 로그 파일 등을 연다.
2) 일반 사용자가 데이터베이스를 이용할 수 있는 상태이다.
3) 만약 종료 시점에 테이블스페이스가 오프라인이었다면 데이터베이스를 기동하여도 해당 테이블스페이스는 오프라인 상태이다.
4) 인스텐스가 데이터베이스를 연 이후 하나 이상의 롤백 세그먼트를 확보한다.

데이터베이스 종료
오라클의 데이터베이스 종료 방법
1) SHUTDOWN NORMAL : 정상적으로 데이터베이스를 종료하는 방법, 별도의 복구작업이 필요없음
2) SHUTDOWN IMMEDIATE : 데이터베이스를 관리할 때 가장 많이 사용하는 정지 옵션, COMMIT 되지 않은 문장은 ROLLBACK 시킴, 현재 사용자가 접속을 해제하는 것을 기다리지 않음, 잘못된 애플리케이션에 의해 부득이 데이터베이스를 정지하는데 사용, 다음 기동 시 별도의 복구 작업이 필요하지 않음
3) SHUTDOWN TRANSACTIONAL : 현재 작업중인 모든 트랜잭션이 정상적으로 수행되어 종료될때까지 기다린다. 별도의 복구작업이 필요없음
4) SHUTDOWN ABORT : 연결된 모든 세션을 강제로 종료, COMMIT되지 않은 문장은 ROLLBACK도 되지 않음, 백업과 복구 작업이 필요한 경우에 사용, 다음 기동 시 별도의 복구 작업이 필요함

10.3. 데이터베이스 운영 시 정기적으로 점검해야 할 사항
매일 점검해야 할 항목
1) 모든 데이터베이스 인스턴스가 기동되었는지 확인한다.
2) ALERT LOG를 확인한다.
3) 데이터베이스가 성공적으로 백업되었는지 확인한다.
4) 데이터베이스의 아카이브 로그 파일이 성공적으로 테이프에 백업되었는지 확인한다.
5) 데이터베이스 성능을 위해 충분한 리소스가 존재하는지 확인한다.
6) 데이터베이스 매뉴얼을 하루에 한 시간씩 탐독한다.

주 단위로 점검해야 할 항목
1) 잘못된 규칙에 의해 오브젝트가 존재하는지 확인
2) 보완관리가 잘 유지되고 있는지 확인
3) 클라이언트 쪽의 로그 파일(SQLNET.log)는 에러나 이슈 사항은 없는지 확인한다.
4) 모든 Alert 로그파일을 보관한다.

월 단위로 점검해야 할 항목
1) 데이터베이스의 비정상적인 현상이 발생하는지 확인한다.
2) 튜닝해야 할 부분이 있는지 확인한다.
3) I/O CONTENTION이 존재하는지 확인한다.
4) 단편화 현상이 존재하는지 확인한다.

10.3. 데이터베이스 문제 발생 및 해결 방법
ROLLBACK 세그먼트 EXTENT 에러
1) 예상했던 ROLLBACK 세그먼트의 크기보다 더 많은 작업량이 발생하거나 다른 트랜잭션이 롤백 세그먼트를 할당받지 못해 에러가 발생된다.
2) ROLLBACK 세그먼트 상태를 확인한다.
SELECT segment_name, extents, bytes/(1024*1024) FROM dba_segments
WHERE segment_type = 'ROLLBACK';

SELECT r.name, l.sid, p.sid,nvl(p.username,'NO TRANSACTION'), p.terminal
FROM v$lock l, v$session p, v$rollname r
WHERE l.sid=p.sid(+)
AND trunc(l.id1(+)/65536) = r.usn
AND l.type(+) = 'TX'
AND l.lmode(+) = 6
ORDER BY 1;


3) 특정 ROLLBACK 세그먼트에 EXTENTION이 많이 발생하여 이를 RELEASE하려면 다음과 같이 한다.
ALTER ROLLBACK SEGMENT SHRINK;

SNAPSHOT TOO OLD 에러
1) 배치 작업 중 과도하게 ROLLBACK 세그먼트를 사용할 경우 발생한다.
2) 데이터베이스에 변경을 가하는 트랜잭션은 만혹, ROLLBACK 세그먼트는 크기도 작고, 개수도 적은 경우에 발생한다.
3) 개발자나, 운영자가 긴 트랜잭션을 발생시켰다면 ROLLBACK 세그먼트를 사용하지 않는 다른 시간에 작업을 수행할 수 있는지를 협의한다.
4) 긴 배치 트랜잭션을 기동하기 위해서는 별도의 큰 ROLLBACK 세그먼트를 생성하여, 해당 트랜잭션에서 사용하도록 한다.
4.1) 큰 ROLLBACK 세그먼트 생성
CREATE ROLLBACK SEGMENT vldb_rbs
STORAGE(INITIAL 100M NEXT 5M)
TABLESPACE vldb_rbs;

4.2) 평상시에는 OFFLINE 상태유지
ALTER ROLLBACK SEGMENT vldb_rbs OFFLINE;
4.3) 배치작업 수행시 ONLINE 상태로 변경
ALTER ROLLBACK SEGMENT vldb_rbs ONLINE;
4.4) 각 작업문장이나 세션에서 ROLLBACK 세그먼트 지정
SET TRANSATION USE ROLLBACK SEGMENT vldb_rbs;
4.5) 작업후 OFFLINE으로 변경
ALTER ROLLBACK SEGMENT vldb_rbs OFFLINE;

5) ROLLBACK 세그먼트 크기를 크게 하거나 개수를 늘리면, ROLLBACK 세그먼트가 도는 주기가 늦어져 덮어쓸 확률이 적어진다.
6) 권장하는 ROLLBACK 세그먼트의 개수는 최고 200 명의 사용자의 경우 동시에 4개의 트랜잭션이 데이터베이스에 발생한다고 가정할 때 한 개의 ROLLBACK 세그먼트가 필요하다.
7) 해당 시스템에 발생되는 동시 트랜잭션 양과 트랜잭션 길이에 따라 적절하게 선정하도록 한다.

테이블스페이스 EXTENT 에러
1) 용량 산정이 잘못되었거나 개발중 지나치게 많은 테스트 데이터가 존재할 경우 발생된다.
2) 테이블이나 인덱스의 테이블스페이스를 잘못 지정하여 특정 테이블스페이스에 데이터가 계속 누적될 경우에도 발생한다.
3) 해결을 위해 테이블스페이스의 여유 공간을 조회한다.
SELECT tablespace_name, max(bytes) "여유공간", sum(bytes) "전체공간"
FROM dba_free_space
GROUP BY tablespace_name;


4) 테이블스페이스를 사용하는 오브젝트를 조회한다.
SELECT tablespace_name, segment_name, bytes
FROM dba_segments
ORDER BY tablespace_name, segment_name


5) 테이블스페이스를 크기를 변경하거나 추가한다.
ALTER DATABASE DATAFILE [데이터파일명] RESIZE [MB 용량]M; -- 크기 변경
ALTER TABLESPACE [테이블스페이스명] ADD DATAFILE [데이터파일명]; -- 추가


잠금 문제
1) 테이블에 잠금이 설정되어 DML작업과 DDL작업이 수행되지 못하는 경우가 발생한다.
2) 현재 걸려 있는 잠금을 조회한다.
SELECT a.sid, a.serial#
FROM v$session a, v$lock b, dba_objects c
WHERE a.sid = b.sid
AND b.id1 = c.object_id
AND b.type='TM'
AND c.object_name='테이블명칭';


3) 세션을 KILL 시킨다.
alter system kill session 'sid, serial#';


   

사업아이템을 추진할 때 필요한 세 가지 조건


1. 깊은 열정을 가질 수 있어야 하고,

2. 최고가 될 수 있는 일이어야 하고,

3. 돈이 되는 일이어야 한다.

 

일을 시작 할 때 적용!

1. 어디서부터 시작하고,

2. 어떻게 출발 하고,

3. 어떤 목표를 정해야 하고,

4. 목표달성 기한은 언제까지 인가?


 


 


'사회생활' 카테고리의 다른 글

7월은 바쁘다 바뻐~ @@;;  (0) 2016.07.06
베조스와 '후회 최소화의 법칙  (0) 2016.05.10
펌] 선발주자보다는 빠른 후발주자가 돼라  (0) 2016.03.15
데이터베이스 설계  (0) 2015.11.07
2014년 시무식  (0) 2014.01.01
   



 

   

+ Recent posts