1.3 DBMS 발전 과정 파일시스템 : 70이전 하이브리드 : 80중반까지 관계 모델 : 80후반까지 객체 모델 : 90중반까지 객체관계 모델 : 90후반까지. - 데이터 모델 : 데이터베이스의 구조를 기술하는데 사용되는 개념들의 집합인 구조(테이터 타입과 관계), 이 구조 위에서 동작하는 연산자들, 무결성 제약조건들 고수준 또는 개념적 데이터 모델 : 사람이 인식하는것과 유사하게 DB의 전체적인 논리적 구조를 명시 ex) 앤티티관계(ER모델*) 데이터 모델과 객체지향 데이터 모델 표현(구현)데이터 모델 : 최종 사용자가 이해하는 개념이면서 컴퓨터 내에서 데이터가 조직되는 방식과 멀리 떨어져 있진 않음 ex) 계층/네트워크/관계* 데이터 모델 저수준 또는 물리적 데이터 모델 : 데이터가 어떻게 저장되는..
데이터베이스 : 조직체의 응용 시스템들이 공유해서 사용하는 운영 데이터들이 구조적으로 통합된 모임. 중복을 배제하여 잘 모아놓은 것. -> 화일 시스템 이후에 등장, 방데한 데이터를 빠르게 처리하는 데 약점이 있음. 운영 데이터 : 일시적인(입출력중인) 데이터를 제외하고, 조직체가 생존을 위해 늘 필요로 하는 데이터 - 데이터의 대규모 저장소, 여러 사용자가 동시에 사용 - 모든 데이터가 중복 최소화하며 통합됨 - 한 조직체의 운영데이터뿐만 아니라 데이터에 대한 설명(DB 스키마)를 포함 - 프로그램과 데이터 간 독립성 제공 - 효율적 접근, 질의 가능 - 데이터베이스 스키마 : 전체적인 데이터베이스 구조, 데이터 베이스의 모든 가능한 상태를 미리 정의 -> 내포(intention) 괄호 속에 필드=at..
CPU와 메모리는 버스로 연결. a : 가장 기본적인 형태. CPU가 많아질수록 병목이 생김 b : 슈퍼컴퓨터 -> 컴퓨팅모드(메모리+CPU합체)가 따로 존재 -> 인터커넥트라는 빠른 버스로 서로 연결 c : 분산 시스템 -> 분리되어 인터넷으로 연결 : 클라우드 컴퓨팅 환경 -> 데이터 복사시 여러번 복사하니 오버헤드가 클 수 있음 우리는 a,b형태에 집중. a는 메모리 접근시간 거의 동일하지만 b는 로컬이냐 원격이냐에따라 차이. 어떻게 관리할 지, 스케쥴링 할 지 중요해짐 UMA : cpu에서 메모리 접근 속도가 동일 NUMA : 로컬메모리 접근 속도랑 원격지 메모리 접근 속도랑 다르다. a : cpu가 많아질수록 하나의 메모리에 접근하니 병목 발생. b : CPU에 캐시가 있음 : cash cohe..
Preemtable : 사용 도중 자원을 다른 프로세스에게 줄 수 있는 자원 / 메모리, CPU Nonpreemtable : 실행도중 다른 프로세스에게 줄 수 없는 리소스 -> 데드락 발생 -> 안걸리게 할 수 있다. b : 자원이 2개라면 down : 1,2 요청하고 -> 쓰고 -> 2,1 순으로 해제 리소스 1에서부터 경쟁 -> 이긴 프로세스가 2까지 가져가서 작업, 진 프로세스는 sleep -> 이후 해제하면 진 애가 a가 1받고 이제 2 받아야 하는데 b가 2를 이미 받았다면 -> 둘 다 sleep : 이 상황이 deadlock ->그럴수도, 그러지 않을 수도 있음. 즉 잠재적으로 일어날 가능성이 있다. 데드락 상황 : 집합에 있는 각 프로세스가 다른 프로세스가 발생시킬 수 있는 이벤트를 기다림...
디스크에서 최적화 하는 알고리즘. lotation delay와 transfer time은 줄이기 힘듦. 거의 고정, 에러 체킹은 컨트롤러에서 하니까 빼고. 실제 dominent(지배적인)한 sector는 seek time이 i/o time에 영향을 끼침 -> seek time을 줄여야 함. work conserving : 해야할 일이 있을 때 계속 하는 것. ex) CPU non-work conserving : 디스크는 해야할 일이 있어도 기다리는게 이득일 수 있음. request order : 읽어야 할 트랙 번호. FIFO: 온 순서대로 처리 -> 공정하지만, (헤드 이동 거리)시크타임은 커짐 SSTF: 헤드 이동거리가 가장 짧은 요청 선택하여 처리 -> 시크타임이 짧아지나, starvation 발생..
I/O 장치는 굉장히 많고 장치마다 특성이 다르다 -> 운영체제는 크게 두가지로 나눠서 관리 1. 블록 디바이스 - 빠름 -> 읽기쓰기가 블록 단위 -> 블록마다 주소 부여 - 오퍼레이션 : 읽기/쓰기, 탐색 등 2. 캐릭터 디바이스 - 입출력하는 펜/키보드/마우스 등의 장치 : 입출력 단위가 문자 -> 주소가 아닌 입출력 순서대로 처리. 이런 형태에 따라 드라이버 작성 규칙이 정해져 있음. 운영체제의 일부인 디바이스 드라이버가 컨트롤러를 작동시켜 입출력을 수행 - 프로세스에서 전송한 데이터를 컨트롤러를 통해 디바이스에 전송(버스를 통해 비트스트림으로) -> 비트스트림을 블록장치라면 블록 단위로 변환. 깨지는걸 방지하기 위해 ECC 코드를 추가로 붙여서 전송 -> 오퍼레이션 : 컨트롤 레지스터에 기록된 ..
디렉토리 구현. a 윈도우즈 : 엔트리에 파일이름 + 속성정보, 엔트리 단위 저장. -> 아래 이미지 보면, First block number가 파일의 시작 데이터가 저장되어있는 블록번호를 저장한 것. 가운데 리저브드 영역도 이후 확장되면서 사용됨. b 유닉스 : 파일이름, 아이노드번호 -> 아이노드에 속성정보와 인덱싱 정보 저장. -> 파일 이름이 8+3이라 너무 짧아. 그래서 255바이트까지 확장 -> 엔트리가 커질 수 있어야 하여 가변 구조가 됨. a : 디렉토리 안에 엔트리를 표현. 한 덩어리가 하나의 엔트리. -> 파일1의 엔트리 길이 + 속성 + 파일 이름(4바이트씩 커짐, x는 null)+ 안쓰는 부분 회색. 이렇게 하다보니 안쓰여지는 공간이 존재. 그래서 b를 제시 b : 파일1의 이름 위..