토성에서 본 지구는 불량화소 같다.

저 작은 곳에서 사람들은 서로를 비교하며 죽으면 없어질 무형의 가치를 부여하며, 경쟁하듯 살고 있다.
가치가 나쁜 것만은 아니지만 그렇다고 만능은 아닌데 말이다.
잡고 있던 것을 놓고 조금만 멀리서 바라보면 더 많은 것들이 보일텐데...

행복하고 즐겁게 사는 것.
꼭 돈을 많이 벌고 남들 앞에 인정받기 위해 서야만 하는 걸까?

그것을 즐겁게 한다면 다행이지만 스트레스 받으며 억지로 살아가는 이유는 멀까.
사람마다 나름의 사는 방법이 있으니, 어찌보면 주제넘은 참견일지도....

행복을 가장한 가식, 보이지 않는 곳에서의 음습한 손길.
그런 것들을 조금이나마 떨처버릴수 있어서 행복하다.
숨을 쉴수 있고, 하루를 즐겁게 살 수 있다.

산 중턱에 내려오니 언덕이 바람을 막아주고, 조금 낮은 곳에서 사물의 섬세함을 느끼게 된다.
난 이런 새로운 것을 보는 즐거움에 또 다른 재미를 느낀다.

섬세함 속에서 또 하나의 지구를 발견한다.

튼튼한 구조 만들기


필드 정밀 조정
 
이름에 포함된 것?

• 필드는 데이터베이스에서 가장 기초적인 구조임.
• 점검 목록은 다음과 같다.
• 이름이 설명적이고 전체 조직에서 의미가 있는가?
• 필드 이름이 명확하고 명료한가?
• 도시의 경우(EmpCity, CustCity 등)
• 필드 이름으로 두문자어 또는 약어를 사용하고 있는가?
• 한 가지 이상의 특성을 암시적 또는 명시적으로 식별하는 이름을 사용하고 있는가?
• 마지막으로 필드 이름으로는 단수형을 사용할 것(복수형은 의미가 두 개이므로 단일 값을 나타내는 필드의 성격과 맞지 않음)

거친 모서리 다음기?

• 필드가 테이블 주제의 특별한 특성을 나타내는지 확인.
• 필드가 단일 값을 가지고 있는지 확인
• 다중 값 필드 : 같은 값들의 여러 인스턴스를 잠재적으로 저장할 수 있는 필드
• 다중 부분 필드 : 둘 이상의 서로 다른 값들을 잠재적으로 저장할 수 있는 필드
• 필드가 계산이나 연결 결과를 저장하지 않는지 확인한다.
• 계산값이 들어 있으면 수작업 또는 계산의 어떤 값이 변경될 때 마다 수행되는 절차적 코드가 필요해짐.
• 필드가 전체 데이터베이스에서 단 한번만 나타나도록 한다.
• 일관성 없는 데이터(다시 말해 데이터 변경시 다른 테이블의 해당 값을 잊어버리고 변경하지 못하는 실수가 발생하게 됨.)

다중 부분 필드 해결하기

• 다중 부분과 다중 값 필드는 데이터 무결성을 깨뜨림.
• 다중 부분 필드를 가지고 있는지는 어떻게 아는가?
• "이 필드의 현재 값을 취해서 더 작고 확실한 부분들로 분할할 수 있을까?"
• 예) 233 West Valley Hwy, San Diego, CA 92199

다중 값 필드 해결하기

• 거의 예외 없이 여러 개의 쉼표를 포함함.(예: 727, 737, 757, MD80)
• 데이터 무결성 문제에 직면할 경우가 발생함.
• SQL 쿼리로 이 필드에 대한 검색과 정렬을 수행하기 어려움.
• 다대다 관계 이므로 연결 테이블로 문제를 해결할 수 있음
• 다중 값 필드와 원본 테이블의 주 키 필드의 복사본을 기초로 사용함.
• 새 연결 테이블의 이름을 정하고 두 필드를 복합 주 키로 지정(양쪽 필드 값들의 결합만이 레코드를 유일하게 식별할 수 있음)

테이블 정밀 조정
이름에 포함된 것(두 번째)
- 정의에 의해 테이블 이름은 단일 주제를 나타내어야 한다.
- 만약 테이블 이름이 모호하거나 불명확하다면 테이블의 주제가 선정되지 않았다고 봄.

• 이름이 고유하고 전체 조직에서 의미가 있을 만큼 충분히 설명적인가?
• 이름이 정확하고 명확하고 모호하지 않게 테이블의 주제를 식별하는가?
• 이름이 물리적 특성을 나타내는 단어를 포함하는가?
• File, Record, Table과 같은단어는 피한다.
• 테이블 이름으로 두문자, 약어를 사용하는가?
• 암시적 또는 명시적으로 하나 이상의 주제를 식별하는 이름을 사용했는가?
• and, or와 같은 단어, 백스페이스, 하이픈 등은 사용하지 않는다.
• 테이블의 이름은 복수형을 사용한다.(Emplyees)

튼튼한 구조 확인하기

• 테이블이 단일 주제를 나타내는지 확인한다.
• 각 테이블이 주 키를 가지고 있음을 확인한다.
• 테이블에 의해 표현되는 것들이 개체 또는 사건임을 기억.
• 각 테이블이 주 키를 가지고 있음을 확인한다.
• 첫 째 : 각 레코드를 유일하게 식별해줌
• 둘 째 : 테이블 관계를 설정하는 데 사용.
• 테이블이 다중 부분 또는 다중 값 필드를 포함하지 않는지 확인한다.
• 테이블에 계산된 필드가 없는지 확인한다.
• 테이블에 불필요한 이중(duplicate) 필드가 없는 지 확인한다.

불필요한 이중 필드 해결하기

[Staff]

StaffID	StaffFirstName	StaffLastName	StaffStreetAddress	StaffCity	StaffState	<<other field>>
98014	James	Leverling	722 Moss Bay Blvd.	Kirkland	WA	...
98019	Laura	Callahan	901 Pine Avenue	Portland	OR	.....

[Classes] : 아래에서 빨간색 필드는 불필요.

ClassID	Class	ClassRoomID	StaffID	StaffLastName	StaffFirstName	<<other field>>
1031	Art History	1231	98014	Leverling	James	...
1030	Art History	1231	98014	Leverling	James	.....

위 테이블의 관계는 일대다 관계임. 따라서 클래스 테이블의 두 필드는 불필요.
관계형 데이터베이스에서 전체 데이터베이스에서 데이터는 오직 한번만 입력되어야 함.

식별하는 것은 키이다.

• 테이블 내의 각 레코드를 유일하게 식별하고, 데이터베이스 전체에서 테이블을 공식적으로 식별.
• 한 쌍의 테이블 사이의 관계를 설정하기도 함.
• 주 키는 단순키와 복합키로 구성됨.(가능하면 주 키 사용)
• 필드가 테이블 내의 각 레코드를 유일하게 식별하는가?
• 필드가 고유한 값을 가지는가?
• 필드가 미지의 값을 포함할 수 있는가?
• 필드의 값이 선택적 일 수 있는가?
• 다중 부분 필드인가?
• 필드의 값이 언젠가 수정될 수 있는가?

견실한 관계 설정하기

• 주 테이블의 주 키를 종속하는 테이블에 삽입(일대일 관계 설정)
• 일(one) 측 테이블의 주 키를 다(many) 측 테이블에 삽입(일대다 관계 설정)
• 연결 테이블을 만듬으로써 다대다 관계를 설정

삭제 규칙 설정하기

• 일대일 관계에서 '주' 테이블의 레코드나 일대다 관계의 '일' 측 레코드를 삭제해야 고아 레코드 방지.
• 제약과 연속 이라는 두 종류의 삭제 규칙을 지정할 수 있음.
• 제약 삭제 규칙 - 일대일 관계나 일대다 관계에서 종속 테이블의 데이터를 삭제하지 못하도록 막는다. 요청 레코드 삭제전에 연관 레코드를 삭제하도록 한다.
• 연속 삭제 규칙 - 일대일 관계에서 '종속' 테이블  또는 일대다 관계에서 '다' 측 테이블의 연관 레코드와 요청받은 레코드까지 삭제
• 매우 신중하게 적용.
• 질문 : 만약 고객 테이블에서 레코드가 삭제된다면 고객주문 테이블 내의 연관 테이블도 삭제 되어야 하는가?
• 예 : 연속 삭제 규칙 적용
• 아니오 : 제약 삭제 규칙 적용

참여 종류 설정하기

• 다른 테이블에 레코드를 삽입하기 전에 그 테이블에 레코드가 있어야 하는지 여부를 결정.
• 강제적 : 다른 테이블에 레코드를 입력하기 전에 이 테이블에 적어도 하나의 레코드가 반드시 있어야 함.
• 선택적 : 다른 테이블에 레코드를 입력하기 전에 이 테이블에 어떤 레코드가 있어야 할 필요가 없음.
• 다대다 관계에서 적용.

참여 수준 설정하기

• 관계는 알았지만 수준은?
• 다른 테이블의 단일 레코드에 연관될 수 있는 한 테이블의 최소 및 최대 레코드 수를 파악함으로써 수행.(참여수준을 식별)
• 쉼표로 분리하고 괄호로 둘러싸인 두 개의 숫자로 표시.
• (예 1, 12) - 참여 수준 연관 레코드가 1개이고, 최대 레코드 갯수가 12개임.

Reference : SQL Queries for Mere Mortals(운명적 존재를 위한 SQL 쿼리)

데이터베이스의 종류

데이터베이스란? - 조직이나 조직 내의 프로세스를 모델링 하는데 사용하는 조직화된 데이터의 집합

운영 데이터베이
- 저장되는 데이터가 동적임.(소매점, 출판사, 제조업체, 병원과 클리닉 등)

분석 데이터베이스
- 역사적이고 시간에 의존적인 데이터를 저장하고 추적. 정적 데이터(화학 실험실, 지질학 회사, 마케팅 분석 등)

최초의 관계형 데이터베이스는?
- 1969년에 태동, 창시자는 에드거 F. 코드(IBM 연구소, 박사)
- 데이터 중복성, 취약한 데이터 무결성, 물리적 구현에 대한 데이터베이스 구조의 의존성 문제 해결을 위해 고민.
- 1970년 6월에 '대규모 공유 데이터뱅크를 위한데이터의 관계형 모델' 연구에서 관계형 모델 제시.
- 집합 이론과 1차 술어논리 라는 수학 분야를 기초에 둠.

관계형 데이터베이스 소프트웨어
- 19070년대의 메인 프레임 컴퓨터는 IBM이 개발한 System R과 버클리에서 개발된 INGRES를 사용.
- 메인 프레임용 RDBMS는 80년대의 오라클의 Oracle과 IBM의 DB2로 이어짐
- 이후 PC붐에 의해 dBase(에스톤 테이트), Paradox(앤사 소프트웨어), R:BASE(마이크로림) 가 등장
- 서버/컴퓨팅 개념에 의해 Oracle 8i와 MS의 SQL Server 7 등장
- 인터넷 시대에 웹 중심 데이터베이스 등장함, Cold Fusion(어르), Sybase(사이베이스), 비주얼 인터데브(MS)

관계형 데이터베이스의 해부
- 관계형 모델에서 관계형 데이터베이스 내의 데이터는 릴레이션내에 저장됨.
- 릴레이션은? - 투플(레코드), 속성(필드)로 구성됨.

테이블
- 데이터베이스의 주요 구조.
- 각 테이블은 항상 하나의 특정 주제를 나타냄.
- 각 테이블은 하나의 주 키(레코드 식별자)라는 필드를 포함함.
- 테이블이 나타내는 주제는 객체(Object) 또는 사건(Event)일 수 있음.
- 주제가 객체라면? 사람, 장소, 사물처럼 실제적인 것을 나타냄.
- 주제가 사건이라면? 주어진 시점에 발생한 어떤 것을 저장함.(재판 공청, 자금 배포, 실험 테스트 결과, 지질학
  조사등)

필드
- 데이터베이스의 가장 작은 구조
- 테이블의 주제의 한 가지 특성을 나타냄
- 데이터를 저장하는데 실제적으로 사용되는 구조.
- 필드 자체의 무결성과 데이터 무결성을 확인하는 데 바친 시간의 양 -> 정보의 질

레코드
- 테이블 주제의 고유한 인스턴스
- 테이블 내의 모든 필드로 구성(주제와 무관함)

키
- 테이블 내에서의 목적을 결정
- 주 키와 외래 키
- 주 키 : 테이블 내의 각 레코드를 고유하게 식별하는 하나의 필드 또는 필드 그룹
- 주 키의 중요성(2가지) : 전체 데이터베이스에서 특정 레코드를 식별하고 그 필드는 데이터베이스에서 주어진
                                   테이블을 식별함
- 데이터베이스 내의 테이블간 관계에서 주 키는 다른 테이블의 외래키가 됨으로써 관계를 설정하고, 관계 수준의
  무결성을 보장하는 데이 도움이 됨.

뷰
- 데이터베이스 내의 하나 이상의 테이블들의 필드로 구성되는 가상적인 테이블
- 기반 테이블(Base Table)로 구성함.
- 기반 테이블에서 데이터를 추출하여 정보를 여러 측면에서 볼 수 있도록 해주고 많은 융통성을 줌.
- 저장된 쿼리, 또는 쿼리라고 부름

관계
- 주어진 테이블의 레코드들을 다른 테이블의 레코드들과 연관을 맺게 하는 방법.
- 일대일, 일대다, 다대다 3가지 종류가 있음.
- 일대일 : 첫 번째 테이블의 한 레코드가 두 번째 테이블의 오직 한 레코드와 연관된 것(역으로도 마찬가지)
              관계에서 주 테이블(primary table)과 종속 테이블(secondary table)로 불림.
              외래키는 종속 테이블의 주키 역할도 수행함.
- 일대다 : 첫 번째 테이블의 한 레코드가 두 번째 테이블의 여러 레코드들과 연관될 수 있음.
              두 번째 테이블은 첫 번째 테이블의 한 레코드하고 밖에 연결이 안됨.
- 다대다: 첫 번째 테이블의 한 레코드가 두 번째 테이블의 여러 레코드와 관계를 가지고 거꾸고 두 번째 테이블의
              한 레코드가 첫 번째 테이블의 여러 레코드와 관계를 가짐. 
              이 관계를 설정하기 위해 연결 테이블(linking table)이 필요함.
              부적절하게 설정된 관계는 '해결되지 않는다.' -> 해결방법은? 연결 테이블은 만든다.
 

HCI는 다 아시다시피 Human Interaction Computer의 약자 입니다.
'인간과 컴퓨터의 상호작용' 이 의미가 중요한데요.

컴퓨터 분야에서 '기술'은 빼놓을 수 없는 아주 중요한 대상입니다.
무언가를 구현해서 사람들에게 이로움을 주는 도구가 되기 위해 도구로서의 충실한 기능이 보장되어야 했고, 그런 도구를 만들기 위해선 '기술' 이라는 것이 강조되어야 했었습니다.

기술의 발전은 도구의 복잡함을 야기했고, 인간은 도구를 통해 편리한 생활을 보장받아야 함에도 그렇지 못했습니다. 기술적 관점도 결코 소홀히 할 순 없지만 컴퓨터가 도구가 됨에 있어 그 동안 간과되었던 인간에 대한 배려가 도구에 녹아들기 시작합니다.

Human Computer Interaction은 '사람'을 이해하는 학문으로써 기술적 요구의 충족은 기본이고, 거기에 추가적으로 도구를 사용하는 사람들의 의견도 중요시 하는 분야입니다.

갑자기 몸살이 생기면서 늘어난 약봉지.

현재 몸에 나타난 병만 총 5가지네요.
지난 주말을 기점으로 갑자기 몸이 여기저기 고장나버렸습니다.

이관염
기관지염
몸살(발열, 오한, 어지러움 등등)
코막힘
목감기

이관염 땜시 최대한 스트레스 덜 받고, 운동도 자제하고 있었는데 순식간에 병이 +4가 되었어요.

주말에 몸살 발병을 시작으로 하루에 하나씩 발병합니다.
다리 뼈 쑤시는 건 기본이고, 골반까지 쑤셔대는데 정신이 하나도 없어요.ㅎㅎ
토요일은 약 먹고 취해서 내리 혼수상태였고, 일요일날 정신 잠깐 들었다가 다시 혼수상태....

월요일날 출근 못할 뻔 하다가 땀 삐질삐질 흘리면서 오기로 출근하고, 다시 정신줄 놔버리고..ㅋㅋ
몸 구석구석 여기저기서 빨간불 막 들어옵니다. ㅡ.ㅡ;;;
약국 아저씨가 "아니 어케 하루마다 병이 새로 생겨요?" 하시면서 의아해 하심다. ㅜ.ㅜ

오늘도 약국가서 2가지 약을 더 추가 했어요.
복통과 설사...ㅡ.ㅡ;;;

아 이 고통이 언제 끝날련지....어흑....
그 좋아라 하던 담배를 하루에 딱 두 대 밖에 못 피우고 있으니, 그나마 건강해지는 부분도 있긴 합니다. ^^
환절기 감기 조심하시구, 예방 주사 미리 맞으세요.

넘 고통스럽습니다. 아흑....

관련 링크 : http://www.slideshare.net/chrisbernard/microsoft-ux-platform-and-tool-overview-by-chris-bernard

올해는 유네스코가 지정한 세계 천문의 해 입니다.
그래서 1년 내내 천문 관련 행사가 아주아주 많이 있습니다.^^

지난 달에는 TWAN 이라는 행사가 서울 청계창작 갤러리에서 있었습니다.
TWAN 프로젝트는 The World at Night 라고 하는데요~
이것의 주목적은 세계 여러 지역의 오래된 문화유적, 명소, 아름다운 자연을 배경으로 밤하늘의 별들이 어우러진 모습을 사진으로 기록하고 전시하는 국제 프로젝트 입니다.

검색하다보니 네이버 갤러리에 관련 코너가 만들어져 있네요.
네이버와 함께하는 TWAN프로젝트 : http://photo.naver.com/galleryn/46

유네스코가 지정한 행사임에도 국내 다른 포털들은 관심이 별로 없어 보이는데 그나마 네이버가 유일하게 천문관련 코너를 마련했네요.
음. 멋진데요?
개인적으로 이런 코너가 개설된 점이 정말 기쁩니다.^^
우주/천문 분야는 중요한 분야임에도 당장 돈이 되지 않다보니 일반인의 관심이나 기업의 관심이 적은게 사실 입니다. 돈이 안되는 부분임에도 갤러리라는 코너에서 천체사진을 일반인에게 소개해준 네이버에 하늘을 사랑하는 한 사람으로써 고마움을 느낍니다. (이걸 다른 곳에도 제안했었는데 거기선 이런 거 별로 라고 생각해서 그랬는지 아무튼 안된다는 반응을 보였었죠.)

아무튼 그건 그거고 당장 금주 4월 4일(토)에는 과천중앙과학관과 4월 5일(일) 남산타워, 마로니에 공원, 한강시민공원, 서울역 등에서 '100 시간 천문학' 행사가 있습니다.
 

과천중앙과학관 행사는 한국의 아마추어 천문가 들이 모여 행사를 진행하게 됩니다.
낮에는 태양을 보고 밤에는 별을 보여준다고 하니 관심 있는 분들은 시간을 내서 가보시는 것도 좋을 것 같습니다.

[1] 100시간 천문학 : http://www.astronomy2009.kr/archive/calendar/20090402_125320/20090402_125320.aspx
[2] 2009 세계 천문의 해 한국 위원회 : http://www.astronomy2009.kr
[3] 세계 천문의 해 년간 행사 : http://www.astronomy2009.kr/blog2/calendar_list.aspx
[4] 한국천문연구원 : http://www.kasi.re.kr