http://guldook.blogspot.com/2005/02/identity-7.html
이 논의에 참가한 많은 사람들은 얼마나 "identity가 정황(context) 의존적인가"에 대해서 얘기했다. Scott C. Lemon은 그의 두번째 원칙에 서 "identity는 커뮤니티의 정황(context)을 고려하지 않고는 존재하지 않는다"고 극단적으로 논평했다. 그리고 Jamie Lewis는 Identity 제 4 법칙을 전할 때 "정황은 모든 것이다"라고 했다. 그는 또한 좋은 예제들을 주었다:
나는 오디오/비디오 광이다, 그래서 나는 Audio Visual Sciences 포럼의 멤버이다.
내 가 가입할 때 나는 내 identity를 스스로 넣었다, 그리고 그것은 AVSForum에 대해서는 괜찮다. 내가 포럼의 규칙들을 따르는 한, 포럼을 운영하는 사람들은 내가 내 자신을 위해 제시한 identity가 무엇이든 간에 그 identity를 사용해서 돌아다니는 것을 허용한다. AVSForum에 있는 평판 시스템은 많은 통제 문제들을 해결한다. 포럼의 중재자들과 관리자들은 그들이 필요할 때는 모든 권한을 가지고 들어간다.
하지만 은행에 대해서도 self-assertion할꺼냐? 아마 아닐 것이다. 그렇다, AVS Forum이 은행이 발급한 identity에 의존할 수 있지만 나는 사회적인 정황(context)에서 판단했을 때 그런 명확한 (그리고 가치있는) identity를 사용하기를 원하지 않을 것이다. 그리고 AVSForum이 왜 그렇게 해야 하느냐? 그렇게 함으로써 얻는 이익보다 비용이 훨씬 더 클 수 있다. 당신이 과거에 등록하고 나서, 서로 매우 다른 정황들에 따라 identity를 전달하고 사용할 때, 필요한 정책(credential 종류 및 강도), 속성들 그리고 관리 시스템은 차이가 있다. 넓게 보면, 이런 것들은 need-driven이어야 하고, 만병통치약은 없다.
다 른 말로 하면, identity는 당신이 상상할 수 있는 한 가장 정황 의존적인 요소이다; 사실상, 모든 사회 활동은 굉장히 정황 의존적이다, 특히 온라인은. 내가 누구이며, 무엇을 공유할 것이며, 어떤 얼굴을 보여줄 것인가 하는 것은 전체적으로 우리가 활동하는 정황에 따라 다르다.
활동영역은 점점 늘어날 것이고, 그 활동영역들은 자신의 영역내에서 고유하고 적당한 identity 메커니즘과 식별자를 가질 것은 자명하다.
이 예제들에 함축된 객관적인 제약조건들이 이전의
Identity 법칙들에 담겨있다.
제 3 법칙은, "identity 관계를 고려해서, 필요하고 정당한 경우에 있는 상대방"에게만 개인 정보의 공개를 해야한다는 것이다. 여기서 identity 관계는 명백히 정황이다. 제 4 법칙은, 왜 metasystem이 사적인 관계에서, 이것도 특정 상황이다, 사용될 수 있도록 "unidirectional 식별자"를 지원해야 하는 지를 설명한다. 그리고
제 5 법칙은, 서로 다른 party들에 의해서 운영되는 서로 다른 시스템들이 공존해야 하는 다원적인 metasystem의 필요성을 언급한다.
하지만 지금 좀 더 구체화해보자. 상황별로 여러 개의 식별자들을 가지게 될 미래를 생각해보자. 나는 Jamie가 임의의 identity 집합을 제거하고 선택하는 것을 언급할 것인 데, 그것은 아주 편해보인다:
- 브라우징: 웹을 돌아다닐 때 스스로 입력한 identity (실제 데이터는 아무 것도 주지 않는)
- 개인: 지속적이지만 사적인 관계를 원하는 사이트들에 입력한 identity (이름과 장기간 사용할 전자우편 주소를 포함하는)
- 커뮤니티: 다른 사람들과 협력하는 것과 블로깅을 위한 공개 identity (커뮤니티 명과 장기간 사용할 전자우편 주소를 포함하는)
- 프로페셔널: 고용주에 의해 발급된, 협업을 위한 공개 identity
- 신용 카드: 은행에서 발급된 identity
- 시민: 정부가 발급한 identity
모 든 사람이 내가 사용한 것과 같은 identity 집합을 선택한다면 아주 간단할 것이다. 하지만 당연히 그렇지 않다. Jamie는 개인 identity를 사용하지 않았다. 내 형의 고용주는 프로페셔널 identity를 발급하지 않는다. Marc는 시민 identity를 적용하지 않고 계획도 없다. 그리고 우리는 우리 자신을 identify할 수 많은 방법들로 혼란하다.
지금, 당신은 이것을 믿지 않으려 하겠지만, 이런
혼란은 좋은 것이다. 그것은 우리의 다양성에 부합한다. 우리는 그것에 대해서 흥분할 필요는 없고 그것을 받아들여야 한다.
당신은 다양성을 어떻게 처리하는가?
다양성이 기술적인 문제를 낳지 않는다고 가정하고 시작하자. 이것이 처음에는 stretch일 것임을 안다, 하지만 "내일"까지는 나와 함께 참고 다른 이슈들을 살펴보자.
어 떤 형식의 identity를 받을 것인가에 대한 답은 "relying party"가 가지고 있다. 다른 말로 하면, 각 웹 사이트가 어떤 종류의 identity들을 받아들일 것인 지를 결정한다. 다시, 예제가 도움이 될 것이니 몇 가지 예제를 들어보겠다.
"Kim Cameron's Identity Weblog"를 가지고 출발하자. Kim's weblog는 어떤 identity를 받을 것인가? 당신은 그것을 명명하고 - 나는 그것을 받아들일 것이다. 너에게 가용한 뭐든 나는 좋다 - 나는 (내 웹로그에서) 논의가 이루어지기를 원한다.
다른 한편, 당신이 eBay와 같은 사이트로 갔다고 하자. 그 사이트는 윈도우 쇼핑을 위해 어떤 identity (또는 no identity)도 사용할 수 있도록 할 것이다. 하지만 당신이 구입을 원할 때는 신용 카드 identity를 기대할 것이다. 그리고 당신이 어떤 물건을 판매하려고 하면, 사이트는, 평판이 가미된, 커뮤니티 identity를 제시할 것을 요구할 것이다.
시민 identity의 사용 예는, 사회 보장 제도 기여금에 대한 정보에 접근하는 경우를 들 수 있다. 또한 컨퍼런스에 들어가기 위해 프로페셔널 identity를 사용하는 예제를 들 수 있다.
그래서 두 가지 것이 명확하게 된다.
- 하나의 relying party는 종종 한 가지 이상의 identity를 받기를 원할 것이다.
- 사용자는 선택 옵션들을 이해하고 정황에 최적인 identity를 선택하기를 원할 것이다.
지금 여섯번째 법칙 - 인간 통합의 법칙 - 을 고려할 필요가 있다. 이것은 identity 정보의 요청, 선택 그리고 제공이, relying party(예: 웹 사이트)와 (
첫번째 및
두번째 법칙에 부합하는 방법으로) 정보를 제공하는 사용자 사이에 형성된, 안전한 채널을 통해서 이루어져야 하고 선택 옵션들은 일관되고 명확해야 한다는 것이다. 이런 제약조건 모두를 동시에 고려하면서 우리는 일곱번째 법칙을 접해야 한다:
조화로운 정황 자율성의 법칙 (The Law of Harmonious Contextual Autonomy)
통일된(unifying) identity metasystem은 relying party와 특정 identity를 가진 사용자 간의 협상과, 통일된 시스템이 서로 다른 정황에서 identity의 자율성를 허용하면서 조화롭고 기술적인 인간 인터페이스를 제시하는 그러한 관련 인코딩을 제공해야 한다.
이게 아주 어렵게 들리냐? 어렵다, 하지만 당신이 이후의 포스팅에서 보겠지만, 나는 이 산업계가 이것을 하는 데 필요한 도구들을 가지고 있다고 생각한다. 하지만, 통일된 identity metasystem을 가지지 않은 것의 댓가는 기하급수적으로 커져갈 것이다.
Doc Searls가 metadirectory에 관한 내 작업을 세심히 살피고 다음과 같이 말한 것이 아마 8년 전일 것이다.
"Kim. 그것은 간단하다. 우리는 다수의 시스템에 다수의 identity들을 가진다, 하지만그것들을 통합할 방법은 없다. 이런 일이 실세계에서 일어났다면, 우리는 다수의 인격 장애를 가졌을 것이다. 인터넷은 여전히 정신병적이다."
이런 생각이 결코 떠나지 않는다. 틀림없이 나는 사용자로써 우리가 여러 가지 identity들을
(소수만이 서로 독립적인 정황들에 대한 필요성을 유의하는) 통합된 세계의 일부로써 볼 필요가 있음을 납득했다.
http://database.sarang.net/?inc=read&aid=20928&criteria=oracle&subcrit=qna&id=&limit=20&keyword=&page=1
FK의 옵션에 따라서 다르게 반영됩니다.
물론 마스터테이블이 변경될때, FK테이블이 같이 변경되게 세팅된다면 그런 현상이 발생할수 있습니다.
그렇지 않게 세팅할수도 있습니다.
다만, FK를 걸어서 얻게되는 이익이 그리 크지 않습니다. 구지 거셔야한다면 꼭걸어야 하겠지만, DBA의 말대로 데이터일관성 측면에서는 FK보다는 프로그램으로 처리하는 경향이 많습니다.
또한, FK가 조인의 성능에 미치는 영향이 미미하기 때문에 실제로 FK를 걸어서 얻는이익은 그것을 생성해서 발생하는 cost보다 많지 않습니다.
참고만하세요,