IT 대장장이

• 읽고, 구상하고, 전하고, 실행 하라. 
• 이 네가지 모두 힘들지만, 전하고, 실행하기가 정말 힘든것 같다. 
• 모두 나의 마음과 같기를 바라지만, 그렇게 만들기가 어렵고
• 다른 사람들은 제자리 걸음인데, 내가 앞서 실행 하기는 더욱 어려운것 같다. 
• 사업가는 몽상가가 아니라 실행가임이 틀림 없다. 

필름 사라져도 잘되는 후지 회장의 ‘4분면 분석법’

TTimes=이해진 기자

출처flickr(@miki yoshihito)

출처afp

출처afp

출처bloomberg

출처pixabay

출처imagetoday

출처bloomberg

출처fujiflim homepage

출처fujiflim facebook

출처fujifilm

출처fujiflim homepage

• 왜 하는지 알아야 하며, 
• Top이 먼저 해야 한다는 강한의지가 있어야 한다. 
• 한번 실패해도 다시 시도해야 한다. 
• 아래 1, 2단계에서 많은 시간을 소요 하더라도 설득과정이 필요하다. 
• 동의 없는 실행은 무의미 하다. 

1. OKR의 기본
   1. 목표는 왜 중요한가?
   2. OKR은 무엇인가?
      • 목표와 핵심 결과 지표. 
      • OKR의 4원칙 (집중F, 정렬A, 추적T, 도전S)
   3. OKR이 성과를 만들어 내는 구조
      • 공격적 목표관리
      • 달성하면 큰 성과가 나온다. 
      • 실패가 허용된다. 
      • 새로운 아이디어가 창출되기 쉽다. 
      • 대립하기 어려워 진다. 
   4. OKR에 관한 오해
      • 스타트업만 사용한다.?
      • 기업차원에서 사용하는 시스템?
      • 개인의 실적 평가에 사용한다?
      • 관리부서가 지표를 정한다?
      • 리더가 결정한 지표를 구성원이 준수한다?
   5. OKR의 장점
      • 큰성과를 얻을 수 있다. 
      • 구성원이 책임 의식을 가지고 일할 수 있다. 
      • 도전하기 쉬워진다. 
      • 활동의 진척 상황이 보인다. 
      • 다른부서나 팀과 협력하기 쉬워진다. 
2. OKR의 시작
   1. 목표 결정 프로세스
   2. 팀의 범위를 결정한다. 
   3. 팀의 미션을 결정한다. 
      • 미션은 팀 전원이 결정한다. 
      • 미션을 정하는 방법(포스트잇 의견모으고 문장화)
   4. 마일스톤을 정한다. 
      • 미션의 유형을 확인한다. 
      • Objective는 가슴 설레는 내용으로 한다. (수치는 무미건조하다. )
   5. 모델을 작성한다. 
      • ex)아마존 플라이휠
   6. 목표를 결정한다. 
      • 어떤 지표에 주목할지 결정한다. 
      • 구체적인 수피 목표를 정하고 Key results로 한다. 
   7. 핵심 결과지표는 SMART로 생각한다. 
      • S(Specific)-구체적으로
      • M(Measurable)-측정가능한
      • A(Achievable --> Ambitious)-야심차게
      • R(Relevant)-관련된-목표를 달성하는데 필요한 내용이어야 한다. 
      • T(Time-bound)-기한이 있는-보통 3개월
   8. OKR의 설정 사례
      • 병동 간호사
      • 주문식 무한리필 음식점
      • 시스템 통합 업체 인재 채용. 
3. 팀내 OKR의 사용
   1. 목표를 향한 프로세스를 확인한다. 
   2. 운용을 설계한다. 
      • 브리핑, 개인면담, OKR매일점검 등의 시간을 미리 계획한다. 
   3. 행동을 결정한다. 
      • 해야할 업무과제를 설정. 
      • 업무과제의 규모는 하루 이내에 완료 할 수 있는것으로. 
      • 태스크 보드를 활용한다. (Kanban)(To do, Doing, Done) - 날짜기입 해야 함. 완료시 날짜기입
   4. 행동한다. 
   5. 달성 상황을 평가한다. 
      • 손가락 평가하기. 0~5점 다른 사람의 자기 평가에 흔들리지 않기 위해 동시에
      • 그리고, 평균점 산출. 
      • KR의 달성 상황을 평가한다. (X축 3개월 시간축, Y축 달성율(기준선과 비교)
   6. 행동을 재검토 한다. 
   7. 최종적인 달성 상황을 평가한다. 
   8. OKR 브리핑의 진행 방법
      • KPTA검토법으로 되돌아 본다. 
      • KPTA검토법 (지속->문제->시도->개선)(Keep-->Problem-->Try --> Action)
      • KPTA의 구체적인 공부가 필요함
   9. OKR을 매일점검 하는 방법
      • 하루의 작전을 세우자. 
      • 1단계 : 각자 보고한다. 
      • 2단계 : 장애물에 대한 대응을 검토한다. 
   10. 개인 면담을 진행하는 방법
       • 구성원과 대화를 나누자
       • 1단계 구성원이 최근 가장 좋았다고 생각하는 일을 듣는다. 
       • 2단계 구성원이 자신의 성장에 관해 걱정하는 일을 듣는다. 
       • 3단계 구성원과 함께 다음에 실행할 업무 대책을 생각한다. 
       • 4단계 구성원이 다음에 실행할 업무 대책을 듣는다. 
   11. OKR 매니지먼트 보드의 활용. 
4. 조직 내 OKR의 사용
   1. OKR의 조직 도입 패턴
      • 기획
      • 전개
      • 정착
   2. 1단계 : 기획 진행 방법
      • 추진팀을 구성한다. 
      • 추진팀의 OKR을 설정한다. 
      • 지침서를 작성한다. 
      • 전문가 강연회나 같은 뜻을 지닌 사람들이 모여 공부 모임을 개최한다. 
      • 최초의 도입 부서를 결정한다. 
      • 연수를 실시한다. 
      • 도입을 지원한다. 
      • 사례발표회를 개최한다. 
   3. 2단계 : 전개 진행 방법
      • 연수를 실시한다. 
      • 도입을 지원한다. 
      • 사례발표회를 개최한다. 
      • 다음 도입 부서를 결정한다. 
   4. 3단계 : 정착 진행 방법
      • OKR을 제도화 한다. 
      • OKR추진팀을 해산한다. 
   5. 계층형 조직의 OKR
   6. 매트릭스 조직의 OKR

• OKR이 모든 직원들이 받아 들이고,
• 팀을 넘어서, 전사에 적용되는 시점에 Collabee를 이용하는 것이 좋다고 생각한다.
• Collabee, OKR 두개 모두 낯선 상황에서 동시에 진행하는 것이 어려울 것이다. 

아래 내용은 Collabee 블로그에서 제공하는 자료이다. 

실리콘밸리의 성공 법칙, OKR 정복하기

1. OKR이란?

2. OKR 세우는 법 3. 설정할 때 자주하는 실수 4. 설정한 OKR 관리 방법

1. OKR이란?

Objective Key Results의 약자로 1970년대 인텔에서 처음 시작되었다고 합니다. 실리콘밸리의 전설로 불리는 인텔의 전회장 앤디 그로브(Andy Crove)의 유명한 저서 'High Output Management'에도 소개된 전략인데요. 지금은 구글의 성장 원동력 근원으로 소문난 성공 법칙이 되었죠. 구글 뿐 아니라, 우리가 잘 아는 링크드인/플립보드/스포티파이 등 실리콘밸리의 다양한 스타트업이 실행하고 있는 방법입니다. 'KPI와 같은게 아닌가?'라고 생각하는 분들도 있는데요. KPI는 성과를 측정하기 위한 하나의 '지표'라고 할 수 있고, OKR은 성과를 내기 위해 실행 '방법'이라 할 수 있습니다. 지금 '목표'를 위해 '무엇'을 해야할 지, 무엇을 하지 않아야 할 지 알 수 있는 명확한 계획입니다.

2. OKR 세우는 법

OKR의 Objective는 다소 추상적이지만 의욕적이고 진취적인 목표가 되어야 합니다. 많은 것을 포괄할 수 있는 하나의 틀이라는 개념으로 생각하시면 됩니다. Key Results는 큰 목표이지만 노력과 방법으로 실현이 가능해야 합니다. Key Results 목표가 달성되지 않으면 보다 상위 개념인 Objective가 달성될 수 없기 때문입니다. 또한, 구체적인 행동을 연상시킬만한 목표여야 합니다. 개념이나 추상적인 목표가 되어서는 안됩니다.

3. 설정할 때 자주하는 실수

가장 효과적인 OKR을 완성한 존 도어는 단 2가지를 강조하고 있습니다. 하나는 목표가 구체적일 것, 하나는 목표를 도달하기 위해 설정한 결과에 대해서 구체적으로 예측할 것입니다. 목표하는 결과는 반드시 측정이 가능해야합니다. 이를 위해 행동을 통해 만들어진 결과의 구체적인 수치를 설정하는 것이 효과적입니다. 또한, Key Results가 Objective에 꼭 필요한지, 가장 효과적인 목표인지 판단하고 설정하는게 가장 중요합니다. 제대로 검토되지 않은 상태에서 설정하고 일을 해나갔을 때 OKR이 실패할 확률이 높기 때문이죠. 또한, OKR을 설정했다고 끝나는 것이 아닙니다. 분기별, 월별, 주별 작은 단위로 목표를 점검하고 조직 내에서 얼마나 잘 실행되고 있는지 확인하는 것이 가장 중요한데요. 하반기로 갈수록 처음 세웠던 목표가 흐릿해지는 경우가 많습니다. Objective는 설정한 기간동안 불변할만한 가치 있어야만 합니다. 도중에 Objective보다 더 필요한 목표가 생기면 모든 의욕이 사라지기 마련이니까요.

4. 설정한 OKR 관리 방법

OKR을 세웠다면 이제 어떻게 실행하느냐가 가장 중요하게 됩니다. 명확한 목표가 있으니 관리가 쉬울거라 생각하지만 조직 인원이 20명만 넘어가도 관리자는 모든 OKR을 관리하기 어렵습니다. 때문에 실리콘밸리에서는 다양한 OKR 관리 서비스가 개발됐는데요. 한국어 버전을 지원하거나 구축용이 가능한 서비스는 아직 없고  비용도 높은 편이라 국내에서는 활용이 어렵습니다. 협업툴 콜라비를 이용하고 계신다면 별도의 서비스 도입 없이 콜라비 내의 기능을 활용하여 OKR을 충분히 관리할 수 있습니다. 방법은 간단합니다.

먼저, 'OKR'이라는 협업 공간에 각자의 Key Results 페이지를 만듭니다. 페이지 내에서는 Key Results를 위한 세부적인 할 일을 생성하여 구체적인 업무를 관리합니다. 지정한 할 일에는 목표 기한을 별도로 설정할 수 있고 진행 상황을 업데이트 할 수 있어 스스로의 OKR 현황을 쉽게 체크할 수 있습니다. Key Results를 완료한 경우에도 이슈 페이지의 진행 상태를 업데이트하여 아이콘으로 표시하고 모든 진행 상태는 칸반 기능을 통해 한 눈에 볼 수 있습니다. 콜라비는 업무 관리를 위한 다양한 기능을 갖추고 있기 때문에 이러한 활용이 가능한데요. 업무 내역 작성을 위해서만 콜라비를 이용하고 계신다면 칸반과 이슈, 할 일 관리 기능을 통해 업무 관리도 진행해보길 바랍니다.

산업 모니터링에 관한 다른 Contents도 확인 하세요. 

다음 표는 SCDA와 DCS의 차이점을 나타내는 표입니다.

그러나, 현재는 하드웨어의 사양들이 상당히 좋아지고 새로운 장비들이 출시되고 있어서 SCADA와 DCS의 구분이 없다고 합니다.

SCADA 대 HMI

SCADA 및 HMI는 모든 조직에서 사용되는 제어 시스템입니다. SCADA는 감독 제어 및 데이터 수집을 의미하지만 HMI는 단순히 휴먼 머신 인터페이스입니다. 산업 및 인프라 프로세스는 일반적으로 컴퓨터로 모니터링됩니다. SCADA는 제조, 생산, 발전, 정제 및 기타 여러 경제 부문에 응용 프로그램을 가지고 있으며 이러한 제어 및 모니터링은 요구 사항에 따라 연속적이거나 개별적 일 수 있습니다. 공항, 철도역, 선박 및 우주 정거장과 같은 시설의 시설 프로세스조차도 SCADA를 사용하여 다양한 프로세스를 모니터링하고 제어합니다.

본격적인 SCADA는 여러 부분으로 구성됩니다. 다음과 같습니다.

HMI

이는 모든 프로세스와 연결 한 다음이 데이터를 작업자에게 제공하는 데 사용됩니다. 운영자는 모든 데이터를 사용하므로 모든 프로세스를 모니터링하고 제어합니다.

PLC

이들은 일반적으로 필드 장치로 사용되는 프로그래밍 가능한 논리 컨트롤러입니다. 이들은 저렴하고 유연한 장치입니다.

Advertisement

RTU

프로세스에 사용되는 센서를 연결하는 원격 터미널 장치입니다. 신호를 디지털 데이터로 변환하여 감시 시스템으로 보냅니다.

컴퓨터 시스템

이것은 모든 데이터를 수집하고 시스템에 명령을 보내는 감독 시스템입니다.

HMI가 단순히 SCADA의 일부라는 것은 위에서 분명히 알 수 있습니다. 실제로 인간과 기계 사이의 인터페이스입니다. 인터페이스는 휴대폰에서 원자로까지 매우 다양하며 엔지니어가 인터페이스를 인간에게 간단하고 쾌적하며 흥미롭게 만드는 것은 어려운 일입니다.

HMI는 모든 데이터를 작업자에게 제공하므로 SCADA의 성공에 매우 중요합니다. 운영자는이 입력을 분석하여 그에 따라 프로세스를 결정합니다. HMI는 SCADA의 데이터베이스와 연결되어 있으며 유지 관리 및 문제 해결에 중요한 정보를 제공합니다. 운영자는 일반적으로 HMI에서 그래프 또는 모방 다이어그램의 형태로 정보를받습니다.

산업 모니터링에 관한 다른 Contents도 확인 하세요. 

Following are the main differences between functions and procedures:

프로시저는 서버에서 실행 되고, 함수는 클라이언트에서 실해 되기 때문에, 프로시저의 속도가 더 빠르다. 

Chapter 1. WHERE 1=1이 뭐야??

우선, WHERE는 조회하려는 데이터들의 조건을 거는 문법이에요.

1 = 1은 말그대로 참을 의미해요.

그럼 위 쿼리를 아래와 같이 바꿀 수 있죠.

해석해보면,

CUSTOMERID가 '3'인 데이터들을 모두(참) 조회한다.

즉, 1=1이란 조건은 있으나마나 한 조건이라는 의미죠.

Chapter2. 그렇다면 왜 WHERE 1=1절을 쓸까?

① 쿼리 디버깅 시, 주석처리가 편하다.

아래와 같은 쿼리가 있다고 하죠.

저는 COMPANYNAME LIKE 'L%'인 데이터가 잘 조회되는지 확인하기 위해

CUSTOMERID = '3'인 조건행을 잠시 주석처리하고 싶어요.

그럼 아래와 같이 처리하겠죠.

흠.. 저는 주석을 두번이나 달아야해서 좀 귀찮네요.

여기서 WHERE 1=1을 사용하면 비교적 쉽게 주석처리하면서 디버깅을 할 수 있어요.

② 동적쿼리에서 특정상황마다 WHERE절을 다르게 작성해줘야 할때 편리하다.

우선, 특정상황마다 WHERE절을 다르게 작성해야 할때란

흔히 조회조건이 있는 조회기능을 떠올리면 편합니다.

예를 들어,

사용자가 CUSTOMERID를 조회조건으로 선택한 후 조회를 할 때는 CUSTOMERID로

COMPANYNAME을 조회조건으로 선택한 경우에는 COMPANYID로 

WHERE절의 조건을 걸어줘야하는 경우이죠.

JAVA를 사용해서 소스를 만들어보면 아래와 같습니다.

query1 = "SELECT * FROM CUSTOMER "

if(!cusotmerID.equals("") {
	query2 = "WHERE CUSTOMERID = '" + customerID + "'"
}
if(!companyName.equals("") {
	if(!customerId.equals("") {
    	query3 = "AND"
    } else {
    	query3 = "WHERE"
    }
	query4 = "COMPANAYNAME = '" + companayname + "'"
}

첫 조건에 WHERE가 붙어야하기 때문에 소스가 복잡해졌습니다.

지금은 조건이 2개밖에 없지만

3개, 4개로 늘어나면 더 복잡해질거에요.

이때, WHERE 1=1을 사용하면 단순한 소스로 수정할 수 있습니다.

query1 = "SELECT * FROM CUSTOMER WHERE 1=1 "

if(!cusotmerID.equals("") {
	query2 = "AND CUSTOMERID = '" + customerID + "'"
}
if(!companyName.equals("") {
	query2 = "AND COMPANYNAME = '" + companyName + "'"
}

• 다른 서버로 이동시에 해당 DBMS를 Detach한 다음. 
• mdf, Ldf 파일을 이동하고, 
• 옮겨진 서버에서 Attach파일 하면 DBMS를 이동 할 수 있다. 
• DB생성시 다른 Drive에 각각 생성 하는 것이 바람직 하다. 

MSSQL에서 관리되는 파일은 다음과 같이 3가지 타입임

1. Primary Data File(.mdf)

- 주 데이터 파일은 데이터베이스의 시작 지점이며 데이터베이스의 나머지 파일을 가리킴

- 모든 데이터베이스에는 하나의 주 데이터 파일이 있음

2. Secondary Data File(.ndf)

- 보조 데이터 파일은 주 데이터 파일이 아닌 모든 데이터 파일을 구성함

- 데이터베이스에 따라 보조 데이터 파일이 없을 수도, 여러 개 있을수도 있음

3. Log File(.ldf)

- 데이터베이스를 복구하는 데 사용되는 모든 로그 정보가 들어가있음

- 완전한 데이터, 즉 데이터베이스의 무결성 때문에 로그파일을 씀

- 모든 행위에 대하여 기록을 남기는 것이 아니라, INSERT등 데이터의 변화가 생길 시 기록 남김

- 로그 파일이 두 개 이상 있을 수 있으며 적어도 하나의 로그 파일이 있어야함

산업 모니터링에 관한 다른 Contents도 확인 하세요. 

스키마 설계 방법론

• 중복된 Data 제거 : 중복 Data를 제거하여 리소스를 효과적으로 사용. 
• Primary Key : 테이블에 PK설정으로 중복 Data입력 방지, 조회시 속도 향상. 
• 외래키 사용 : 중복 Data최소화하고, 연관관계를 만들어 연관성을 깨는 Data삭제 방지. 
• 필드명 통일 : 같은 Data는 같은 필드명으로 한다. 어떤곳에는 Code, EqName, EQ_Name 등으로 하면, Procedure및 View작성시 혼란을 만든다. 
• 일단 관계형 데이터베이스 모델을 설계할때는 보통 두가지 방법으로 설계 하는 것 같다. E-R Model And Relation 변환 규칙 또는 정규화를 이용한 데이터베이스 설계 방식

요구 사항 분석

• 해당 조직에서 어떤 사람들이 데이터베이스를 요구하는 지 조사한다.
• 사용자의 범위가 결정되면 조직에서 해당 사용자가 수행하는 업무를 조사한다.
• 조사가 끝난다면 결과로 요구 사항 명서세로 보통 문서화된다.
• 이 과정에서 올바르게 설계 되어야 후에 고생하지 않을 확률이 높으므로 여기서 시간이 오래걸리더라도 오랜시간 검토해보라고 말한다. 사실 이게 맞는 말이다. 데이터 베이스를 응용프로그래머들이 이용할텐데, 설계가 잘못되어 있다면 데이터베이스를 바꾸는 일이 일어날 것이고, 그것은 결국 프로그래머들의 코드도 바뀔 수 있다는 이야기가 된다.

도출된 요구사항

1. Roach 마트에 가입하려면 고객은 회원아이디, 비밀번호, 나이, 직업을 입력해야한다.

2. 가입한 회원에게는 등급과 적립금이 부여된다.

3. 회원은 회원아이디로 식별한다.

4. 상품에 대한 상품번호, 상품명, 재고량, 단가정보를 유지해야 한다.

5. 상품은 상품번호로 식별한다.

6. 회원은 여러 상품을 주문할 수 있고, 하나의 상품을 여러 회원이 주문할 수 있다.

7. 회원이 상품을 주문하면 주문에 대한 주문번호, 주문수량, 배송지, 주문일자 정보를 유지해야 한다.

8. 각 상품은 한 제조업체가 공급하고, 제조업체 하나는 여러 상품을 공급할 수 있다.

9. 제조업체가 상품을 공급하면 공급일자와 공급량 정보를 유지해야 한다.

10. 제조업체에 대한 제조업체명, 전화번호, 위치, 담당자 정보를 유지해야 한다.

11. 제조업체는 제조업체명으로 식별한다.

12. 회원은 게시글을 여러개 작성할 수 있고, 게시글 하나는 한 명의 회원만 작성할 수 있다.

13. 게시글에 대한 글번호, 글제목, 글내용, 작성일자 정보를 유지해야 한다.

14. 게시글은 글 번호로 식별한다.

개념적 설계

• 요구사항 중 데이터베이스에 저장해둘 필요가 있다고 판단되는 데이터 요소를 추출하고, 데이터 요소간의 관계를 파악하여 이를 표현한 것이다. 일반적으로 개념적 데이터 모델로 E-R 모델식의 표현법을 많이 사용한다고 한다.
• 보통 명사를 찾는게 좋다고 한다. 그러면 우리가 적어놓은 1~3 까지에서 Entity 로 뽑을 만한 요소들이 무엇이 있을까?
  • Roach 마트에 가입하려면 고객은 회원아이디, 비밀번호, 나이, 직업을 입력해야한다.
• 근데 여기서 보면 마트와 고객은 따로 Entity 로서 추출해낼 수 있지만 회원 아이디, 비밀번호, 나이, 직업은 Attribute 가 된다.
  • 가입한 회원에게는 등급과 적립금이 부여된다.
  • 회원은 회원아이디로 식별한다
• 2 번도 등급의 경우 따로 분리할 수 있겠다. 만약 등급에 따른 적립금이 퍼센티지가 있다면 등급 테이블의 주 키를 등급으로 두고, 적립금을 속성 해당 등급에 종속시키면 될것이다. 그리고 고객마다 해당 등급을 외래키로 가지며, 적립금에 대한 퍼센티지는 등급 테이블에서 참조하면 될것이다.
• 3 번은 고객 테이블의 unique 키를 회원아이디로 두어라 라고 말하고 있다.

추출 후

일단은 위처럼 요구사항 명세에 적혀있는 부분들을 개체로 빼낸 상태에서 표를 만들었다.

관계 추출

• 이제 여기서 관계를 추출해 내야한다. 어떤 관계를 가질 수 있는지를
  • 6. 회원은 여러 상품을 주문할 수 있고, 하나의 상품을 여러 회원이 주문할 수 있다.
  • 위의 문장이 상품과 회원사이에 N:M 의 관계를 가질 수 있음을 나타내고 있다.
    • 회원과 상품은 모두 주문이라는 하나의 개체에 선택적으로 참여하고 있다. 그러므로 주문이라는 개체에 상품과 회원을 인지할 수 있는 어떠한 속성이 추가되야 할것이다.
  • 8. 각 상품은 한 제조업체가 공급하고, 제조업체 하나는 여러 상품을 공급할 수 있다.
    • 여기서 제조업체와 상품의 관계는 1:N 임을 알 수 있다.
  • 12. 회원은 게시글을 여러개 작성할 수 있고, 게시글 하나는 한 명의 회원만 작성할 수 있다.
    • 여기서 회원과 게시글의 관계는 1:N 임을 알 수 있다.

논리적 설계

• 논리적 설계는 위의 개념적 설계에서 도출된 E-R 모델(혹은 다른 방법으로 표기된 관계도) 를 통해서 논리적 스키마를 설계하는 단계이다.
• 여기서 설명하는 방식을 따라서 개념적 설계로 도출된 모델을 논리적 스키마로 바꿔볼 것이다

도출된 E-R 모델을 Relation 으로 변환하라.

상품(상품번호(PK), 상품명, 재고량, 단가) 고객(고객번호(PK), 이름, 등급, 주소)

• 명심할 점은 우리는 아직 어떤 DBMS 로 구현할지 정하지 않았다는 거다!

N:M 관계는 릴레이션으로 변환한다.

주문(주문번호(PK), 고객번호(FK), 상품번호(FK), 주문수량)

1:N 관계는 외래키로 표현한다.

제조업체(제조업체명(PK), 전화번호, 위치, 담당자) 상품(상품번호(PK), 상품명, 재고량, 단가, 제조업체명(FK), 공급 수량)

• 릴레이션 규약상 N 측 기본키를 외래키로 이용할 수 없다. 외래키가 다중값을 가져서 규약에 위배된다.

1:1 관계는 외래키로 표현한다

• 1:1 관계에서는 외래키를 서로 주고받을 수 있다.
  • 이 부분은 음 나한테 귀속된 아이템은 내 정보를 지니고, 난 아이템 정보를 지니고 간단하게 이정도로.. 아이템이 1:N 이지 않나요? 이러면 그게 맞는말인데, 그니까 문맥상으로 저런 느낌이란거다.
  • 실제 예시를 찾아보면 더 쉽게 이해할 수 있을 것이다.
• 하지만 똑같이 한곳의 키만 주고 받을 수 잇다. 이런 경우는 자신이 잘 판단하자!

주의할 점

• 릴레이션이 많이 늘어날 수록 DBMS 에 가해지는 부담이 클 수가 있다. 따라서 불필요한 릴레이션을 생성한 것이 아닌지 꼭 생각하면서 설계해야 한다. 솔직히 처음 단계부터 이번 단계까지가 정말 중요한 단계라고 생각한다.

DB 구현체 고르기

고객(고객번호(PK), 이름, 등급, 우편번호, 주소)

주문(주문번호(PK), 고객번호(FK), 상품번호(FK), 주문수량)

제조업체(제조업체명(PK), 전화번호, 위치, 담당자)

상품(상품번호(PK), 상품명, 재고량, 단가, 제조업체명(FK), 공급 수량)

create table Product(

       id VARCHAR(20),

       name VARCHAR(20),

       count INT,

       prince INT,

       company_id VARCHAR(20),

       supply_quantity INT,

       CONSTRAINT product_id PRIMARY KEY(id),

       CONSTRAINT FOREIGN KEY(company_id) REFERENCES Company(id)

);

create table Customer(

       id VARCHAR(20),

       name VARCHAR(20),

       grade VARCHAR(10),

       adresss VARCHAR(30),

       CONSTRAINT customer_id PRIMARY KEY(id)

);

create table Orders(

       id VARCHAR(20),

       customer_id VARCHAR(20),

       product_id VARCHAR(20),

       count int,

       CONSTRAINT orders_id PRIMARY KEY(id),

       CONSTRAINT FOREIGN KEY(customer_id) REFERENCES Customer(id),

       CONSTRAINT FOREIGN KEY(product_id) REFERENCES Product(id)

);

create table Company(

       id VARCHAR(20),

       phone_number VARCHAR(20),

       address VARCHAR(30),

       manager VARCHAR(20),

       CONSTRAINT company_id PRIMARY KEY(id)

);

산업 모니터링에 관한 다른 Contents도 확인 하세요.