자신이 좋아하는것

2010년 11월 28일 일요일

ER 모델링 에 관하여

ER 모델링 ( 개체 관계 모델링)
    
ER 모델링은 데이터베이스 설계를 용이하게 하기 위해 P.P.Chen 이 1976년에 제안한 후 많은 학자들이 이 모델을 강화시켰으며 현재는 EER(Enhanced Entity Relationship) 모델이 데이터베이스 설계 과정에 널리 사용되고 있습니다. 개념적 설계를 위한 인기 있는 모델로서, 높은 수준으로 추상화하며, 이해하기 쉬우며, 구문들의 표현력이 뛰어나고 사람들이 응용에 대해 생각하는 방식과 가깝고, 많은 CASE 도구들에서 지원이 됩니다.

ER 모델은 실세계를 엔티티, 애트리뷰트, 엔티티들 간의 관계로 표현하면 ER 다이어그램은 엔티티 타입, 관계 타입, 이들의 애트리뷰트들을 그래픽하게 표현합니다. ER 모델은 적은 노력으로 쉽게 배울 수 있고, 전문가가 아니어도 이해하기 쉬우며, 자연어보다는 좀 더 정형적으로, 구현에 독립적이어서 데이터베이스 설계자들이 최종 사용자들과 의사소통을 하는데 적합합니다.
 

ER 모델링 용어

- 엔티티(Entity) : 데이터베이스 테이블
- 속성(Attribute) : 데이터베이스 컬럼, 열
- 인스턴스(Instance) : 튜플, 행
- 주식별자(Primary identifier) : 기본키(Primary key)
- 외래식별자(Foreign identifier) : 외래키(Foreign key)


1. 엔티티 (개체, Entity)

엔티티란 사람, 장소, 사물, 사건 등과 같이 독립적으로 존재하면서 고유하게 식별이 가능한 실세계의 객체로 업무의 관심 대상이 되는 정보를 갖고 있거나 그에 대한 정보를 알아야 하는 유형, 무형의 사물이나 객체입니다. 엔티티의 종류는 실체가 있는 것도 있지만 생각이나 개념과 같이 추상적인 것도 있습니다.


유형 엔티티 
: 물리적인 형태가 있는 엔티티 (고객, 사원 등) 

무형 엔티티
: 물리적인 형태가 없고 개념적으로 존재하는 엔티티 (생산계획, 부서조직 등)

문서 엔티티
: 업무 절차상에서 사용되는 문서나 장부, 전표에 대한 엔티티 (거래명세서, 입출금전표, 주문서)

이력 엔티티
: 업무상 반복적으로 이루어지는 행위나 사건의 내용을 일자별, 시간별로 저장하기 위한 엔티티 (입고 이력, 출고 이력 등)

코드 엔티티
: 무형 엔티티의 일종으로 각종 코드를 관리하기 위한 엔티티 (국가코드, 색상 코드등)


엔티티를 정의할 때는 엔티티 안에 중복되는 데이터가 없어야 하며, 엔티티 이름을 지을 때는 한번에 알 수 있게 지어야 하고, 축약어를 쓸 경우 정해진 룰에 따라 지어야 합니다. 데이터의 중복은 데이터의 정합성을 해칠 가능성이 그 만큼 높아지며, 모호한 이름을 사용하는 경우와 축약어가 중구난방으로 쓰여진 경우에는 가독성을 해치게 됩니다. 
   
2. 애트리뷰트 (Attribute, 속성)

하나의 엔티티에 연관된 애트리뷰트들의 집합으로 한 애트리뷰트의 도메인은 그 애트리뷰트가 가질 수 있는 모든 가능한 값들의 집합을 의미합니다. 테이블에서 컬럼을 말하며 객체로 본다면 객체의 속성을 말합니다. 키 애트리뷰트는 한 애트리뷰트 또는 애트리뷰트들의 모임으로서 한 엔티티 타입 내에서 각 엔티티를 고유하게 식별합니다. ER 다이어그램에서 기본키에 속하는 애트리뷰트는 밑줄을 그어 표시합니다.

  • 기본 속성 : 업무 분석을 통해 현실 세계로 부터 얻어낸 속성 (제품명, 원가, 이름, 나이 등)
  • 설계 속성 : 현실 세계에 존재하지 않지만 설계 과정에서 만들어진 속성 (국가코드, 부서코드 등)
  • 유도 속성 : 다른 속성으로부터 계산이나 변형에 의해 나온 속성 (금액 = 수량 * 단가 등)
   
  
3. 관계와 관계 타입 (Relationship)

개체와 다른 개체와의 연관 관계를 표현합니다. 즉, 객체 집합 구성원소 사이의 대응성을 mapping 합니다. 관계성에는 일대일(One-to-One), 일대다(One-to-Many), 다대다(Many-to-Many) 관계가 있습니다.

  
- 일대일 ( One-to-One ) 관계 








회원 = { 회원 인덱스 + 이름 } , 회원정보 = { 회원 인덱스 + 나이 + 주소 + 성별 } 이렇게 두 테이블이 있다면 이 두 테이블은 일대일 대응관계를 가지고 있습니다. 이럴 때는 하나의 테이블로 통합하여 관리하는 것이 좋습니다. 테이블을 통합하거나 유지할 때는 용도, 편리성, 저장 공간을 고려하여 결정해야 합니다.


- 일대다 ( One-to-Many ) 관계 








회원 = { 인덱스 + 이름 }, 취미 = { 회원 인덱스 + 취미 } 이 경우는 회원이 가질 수 있는 취미의 종류가 많기 때문에 한 회원이 다양한 취미를 가질 수 있습니다. 이런 관계가 일대다 관계인데요. 하나에 해당하는 테이블에는 기본키를 가지고 다에 해당하는 테이블에는 기본키를 외래키로 추가하여 연결하는 방법입니다. 하나로 관리하면 Null 값이 많이 생겨 공간의 낭비가 발생할 때 새로운 테이블을 생성하여 테이블을 나누는 것이라 볼 수 있습니다.


- 다대다 ( Many-to-Many ) 관계








다대다 관계는 회원 = { 이름 + 나이 + 주소 }, 상품 = { 상품명 + 제조사 + 가격 } 같이 상품을 구매하는 경우 발생합니다. 이 때는 각각의 개체를 테이블로 작성한 후 기본키를 새로 작성한 구매 = { 회원(FK) + 상품(FK) + 수량 } 테이블을 생성하여 테이블의 관계를 맺는 방법을 사용합니다. 
 
 
 
ER모델링이란 세상에 존재하는 모든 사실이나 현상을 실체와 관계라는 개념으로 표현하는 것입니다.  연구실과 학생이라는 실체는 소속이라는 관계에 의해 연관되어 있다고 할때  '학생은 연구실에 소속되어 있다'라는 사실로 표현할 수 있습니다.
 
그리고 ER 모델링에서 표현하는 방법도 찾아 보았는데요.
 
ER 모델링에서 표현하는 방법은 여러가지가 있으며 대표적인 것은
ER 모델링을 제창한 P.chen 에 의한 표기법과 
Crow's Foot 표기법,
Rein85표기법, 
IDEF1X 라는 표기법의  4가지가 있습니다.                                                                         4. IDEF1X ERD
 
 
 
                                                        ER 모델링 표현 상징 사이의 차이점




                                                                             1. Chen ERD




                                                                  2. The Crow's Foot ERD




                                                                             3. The Rein85












http://blog.naver.com/e_life2000?Redirect=Log&logNo=120095439833  - 그림 출처 (PDF파일)
http://hell_titan.blog.me/130095290141
http://blog.naver.com/pinkpigsong?Redirect=Log&logNo=80118179132
 

2010년 11월 21일 일요일

file extension

file extension (파일 확장자)

파일 확장자는 컴퓨터 파일의 이름에서 파일의 종류와 그 역할을 표시하기 위해 사용하는 부분이다. 많은 운영체제들은 파일 이름에서 마지막 점(.) 뒤에 나타나는 부분을 확장자로 인식한다. (예를 들어, readme.txt의 확장자는 txt이며, index.ko.html의 확장자는 html이다.)

VMS, CP/M 과 그로부터 파생된 도스 등의 운영체제 - 확장자가 실제로는 파일 이름과 분리되어 있으며, 확장자를 실행 파일을 나타내는 등의 특수한 용도로 사용한다.

유닉스 계열 운영체제 - 확장자가 파일 이름의 일부분일 뿐으로, 도스 등의 운영체제보다는 확장자에 덜 의존한다.

그래픽 사용자 인터페이스(GUI) (마이크로스프트 윈도, 맥 오에스 텐, GNOME, KDE등) -
파일 확장자를 단순히 종류를 나타내는 것뿐만이 아니라 인터페이스 상에서 파일의 아이콘이나 그에 연관된 작업들을 결정하는 데 사용한다.
 예를 들어서 특정한 파일을 열었을 때, .txt 확장자는 텍스트 편집기를, .htm이나 .html 확장자는 웹 브라우저를, .png, .gif 등의 확장자는 그래픽 편집기를, .doc, .odt 등의 확장자는 워드 프로세서를 실행하는 등의 동작을 지정할 수 있다. 특히 마이크로소프트 도스와 윈도 운영체제에서는 .exe, .com, .bat, .cmd 등의 확장자를 가진 파일을 실행 파일로 인식한다.

이런 특성 때문에 파일 확장자는 일종의 메타데이터로 볼 수 있다.

파일 확장자의 대안

맥 오에스에서는 전통적으로 파일 확장자를 쓰지 않고, 파일의 종류를 나타내는 타입코드와 그 파일을 열었을 때 어떤 응용 프로그램이 실행될지를 나타내는 크리에이터 코드를 대신 썼다. 하지만 NEXTSTEP에서 기반한 현재의 맥 오에스 텐에서는 유닉스 계열 운영체제와 같이 파일 확장자를 사용하며, 맥 오에스 텐 10.4부터는 옛 타입 코드와 크리에이터 코드와 유사한  고유 종류 식별자(UTI)를 지원한다.

네트워크 상에서 전달되는 데이터들은 비트들의 연속으로 간주되며 별도의 파일 이름이나 확장자를 가지지 않는다. 하지만 HTTP 등의 여러 프로토콜에서는 MIME Content - Type 헤더를 사용하여 데이터의 종류를 전달한다. BeOS등의 일부 운영체제에서는 이런 MIME Content-Type 값을 파일의 메타데이터에 기록할 수 있다.

     여기서 뜬금없이 mime content type (혹은MIME) 이라는 단어가 나와서 검색을 해보았더니
     MIME (Multipurpose Internet Mail Extension Type) 이란 다음과 같았다.
 
MIME은 아스키 데이터만을 처리할 수 있는 원래의 인터넷 전자우편 프로토콜, 즉 SMTP(Simple Mail Transfer Protocol : 메일 전송 프로토콜)를 확장하여 오디오, 비디오, 이미지, 응용프로그램, 기타 여러가지 종류의 데이터 파일들을 주고받을 수 있도록 기능이 확장된 프로토콜이다
1991년에 SMTP를 확장하여 인터넷 클라이언트 및 서버들이 아스키 텍스트 이외의 다른 종류의 데이터들도 인식하고 처리할 수 있도록 할 것을, 벨 코어의 Nathan Borenstein Internet Engineering Task Force에 제안하였다. 그 결과로, 새로운 파일 형식들이 IP가 지원하는 파일 형식으로서 메일에 추가되었다.

서버들은 어떤 웹 전송에라도 시작부분에 MIME 헤더를 집어넣으며, 클라이언트들은 헤더가 나타내는 데이터 형식에 따라 이를 재생시키기 위한 적절한 응용프로그램을 선택한다. 이러한 재생용 프로그램들 중 일부는 웹 클라이언트, 즉 브라우저에 기본적으로 탑재되며 (예를 들어 모든 브라우저는 HTML 파일의 처리뿐 아니라 GIF와 JPG 이미지를 보여줄 수 있는 능력을 가지고 있다), 그 외의 프로그램들은 필요할 때마다 다운로드된다.  새로운 MIME 데이터 형식들이 생기면 IANA 에 등록된다.

7개 타입으로 구성되며 각각 text, multipart, message, application, image, audio, video 이다. 그리고 각 타입의 하위로 그 아래의 타입들이 존재한다.

                                                                  출처 http://orozsun.blog.me/140097291022


유닉스 계열 운영체제들은 파일 확장자와 관계 없이 파일의 내용을 바탕으로 그 종류를 추측하는 file(1) 프로그램을 지원한다. 이 프로그램은 파일 포맷들이 자신을 나타내기 위해 사용하는 고유한 매직 넘버를 바탕으로 경험적 방법을 통해 결과를 반환한다. GNOME과 KDE에서는 이 결과를 토대로 MIME Content-Type 값을 추출하여 사용한다.

이번 과제를 시작하면서 평소 보던 파일 확장자라 해봤자 .exe .hwp .mp3 .avi .smi .txt 등 뿐이라 조금 편하게 file extension 에 대해 조사를 해보았는데 의외로 관련된 내용이 많았다. 각 운영체제들 사이에도 파일확장자를 나타내는 방법이 달랐고 파일 확장자와 그 의미가 유사한  MIME 라는 것이 있는것도 새롭게 알게 되어 뿌듯한것 같다. 


출처

위키백과
http://blog.naver.com/pyukcho?Redirect=Log&logNo=100027537093  ( MIME type by content type)

2010년 11월 12일 금요일

address binding 에 관하여

10단원에서는 operating system 에 대해서 배웠는데 이 단원을 마치고

과제를 하기에 앞서 운영체제에 대해 검색해보았습니다.


운영체제(Operating System)은 하드웨어와 사용자 프로그램 사이에서 자원의 활용을 극대화 하고 시스템을 비롯한 프로그램 사용을 용이하게 해주는 것 이다. 뭐... 쉽게 말해서 컴퓨터를 사람(개발자 혹은 사용자)이 편리하게 사용하게 해주는 시스템이다.
라고 한다.. 이제껏 운영체제는 윈도, 리눅스등등으로만 어렴풋이 알고 있었던는데...

아무튼 운영 체제에 대한 완전한 정의는 없다고 하니 이번 단원은 운영체제가

무엇인지 보다는 운영체제가 무엇을 하는지에 관심을 가지고 공부해야겠다.
아무튼 이번에는 memory management  부분에서 address binding 에 관하여 조사를 해보았다.

전공 관련 프로그래밍 시간에 c언어교재나 java교재에는


 source file을 컴파일 해서 기계어로 되어 있는 object file을 만든다. 이러한 여러 object file들과 start-up code를 Link시켜 execution file을 만든다. 그렇게 만들어진 execution(실행) file을 실행하면 실행된다.

 그리고 자료형과 함수 배열등을 배우는 동안 memory의 얼마를 차지하며 무슨 영역에 자리 잡는다는 등의 설명이 불쑥 튀어 나온다. 또한 일반적으로 많이 사용하는 지역변수 영역(stack)과 동적 할당 영역(heap)에 대해 언급하는 것이 주를 이룬다.


라는 부분이 나온다.

프로세스(간단히 말해서 실행중인 프로그램)가 생성되어 실행되기 위해서는 실행 프로그램 파일을 메모리(RAM)에 적재해야 한다.

(why??? -  프로세스의 실행은 결국 CPU가 하는데 이 CPU는 Bus라는 녀석으로 Main-Memory와 연결되어 의사소통을 하기 때문이다.)
이렇게 메모리에 적재 된 실행 프로그램 파일은 CPU에 의해 처리되며 비로소 프로세스라는 명칭으로 불릴 수 있는 것이다.
 하지만, 이러한 실행 프로그램 파일을 무턱대고 메모리에 적재하는 것이 아니라
 [코드 영역][데이터 영역][스텍영역]으로 분류 되어 적재된다.

▷ 코드 영역:  기계어 코드로된 프로그램 실행코드가 적재 되는 영역이며 CPU는
    이 영역의명령을 읽어들여 차례로 프로그램을 수행하게 된다.

▷ 데이터 영역: 전역변수아 같이 프로세스가 종료될 때까지 게속 사용되는 변수들을
    위한 영역

▷ 스택 영역: 함수 호출 과정과 같이 임시로 존재하는 변수들을 저장하는 영역


( CPU에 의한 메모리 읽기/쓰기 )


  전형적인 명령어 실행은 먼저 메모리로 부터 한 명령어를 가져오는 데서부터 시작된다. 명령어를 읽어오는 과정에서는 명령어 주소 레지스터(IP: Instruction Pointer, 또는 PC: Program Counter)에 있는 코드 영역의 주소를 메모리에 전달하고 읽기 작업을 실행한다. 그 다음 명령어를 해독하고, 메모리에서 피연산자(operand)를 가져와 피연산자에 대해 명령어를 실행한 후에 계산 결과를 메모리에 다시 저장한다. 전역 변수에 대응되는 데이터 영역의 주소나 스택 주소 레지스터(SP: Stack Pointer)에 기록된 스택 영역의 주소를 메모리에 전달하고 읽기나 쓰기 작업을 실행한다.

 이처럼 CPU가 Memory를 읽거나 쓰는 작업을 하기 위해선 메모리에 로드 된 실행프로그램파일의 명령코드나 데이터의 저장 주소를 알아야 한다. 즉, [Figure.02]와 같이 소스프로그램이 메모리에 적재될때까지의 과정중에 저장되어야 할 코드의 주소들은 여러가지 다른 표현 방식을 거치게 되고, 코드 영역이나 데이터 영역이 적재될 주소가 결정되면, 코드 영역의 내용 중에 함수의 주소나 변수의 주소가 있는 부분을 결정된 주소에 맞게 수정해야 하며 이러한 작업을 주소 바인딩(address binding)이라고 한다.


( 소스파일에서 메모리 적재 까지의 처리 과정 )



소스 프로그램에서 주소는 숫자가 아닌 심볼 형태로 표현되고, 컴파일러는 이 심볼 주소를 재배치 가능 주소(예를 들면 "이 모듈의 첫번째 바이트로부터 열네번째 바이트 주소")로 바인딩시키고, 추후에 연결 편집기(linkage editor)나 로더(loader)가 이 재배치 가능 주소를 절대 주소(예를 들면 74014번지)로 바인딩 시킨다. 
 


또한, 메모리 주소 공간에서 명령어와 데이터의 바인딩은 그 바인딩이 이루어지는 시점에 따라 다음과 같이 구분된다.
  • 컴파일 타임(compile time) 바인딩
    프로세스가 메모리 내에 들어갈 위치를 컴파일 시간에 미리 알 수 있으면 컴파일러는 절대 코드를 생성할 수 있다. 예를 들면 사용자 프로세스가 R번지부터 시작한다는 것을 미리 알 수 있다면 컴파일러는 번역할 코드를 그 위치에서 시작해 나간다. 그러나 만일 이 위치가 변경되어야 한다면 이 코드는 다시 컴파일 되어야 한다. 예)MS-DOS의 .COM양식 프로그램
  • 적재 시간(load time) 바인딩
    컴파일 시점에서 메모리 적재 위치를 알지 못하면 컴파일러는 일단 이진 코드를 재배치 가능 코드로 만들고 심볼과 진짜 번지와의 바인딩은 프로그램이 메모리로 실제로 적재되는 시간에 이루어지게 된다. 이렇게 만들어진재배치 가능 코드는 시작 주소가 변경되면 아무 때나 사용자 코드를 다시 적재하면 된다.
  • 실행 시간(execution time) 바인딩프로세스가 실행하는 중간에 메모리 내의 한 세그먼트로부터 다른 세그먼트로 옮겨질 수 있으려면 "바인딩이 반드시 실행 시간까지 연기되어야 한다". 요즈음 대부분의 운영체제는 이 방식의 바인딩을 체택하고 있다.

이렇게 내가 조사한 address binding 기법은 이것만 이해하면 되는게 아니라 이 기법을

가능하게 하는 하드웨어인 MMU(Memory Management Unit)에 대해서도 함께 알아야 한단다.

복잡하지만 이부분은 나중에 좀더 조사를 해봐야 겠다.