트랜잭션

- 트랜잭션 : 하나의 단위로 취급하는 SQL 문장들의 모임. -> 많은 사람들이 동시에 DB에 접근해서 사용하는데 번호표를 다 지정해줘. -한 번에 하나씩 하면 ㅈㄴ오래걸리겠지. 동시에 트랜잭션을 허용해야함. - DB를 쓰는 도중에 죽었따 살아났따 어떡할거냐! 절대로 데이터베이스에 뭔가가 깨지는걸 냅둬서는 안된다. - 500명이 재직. 급여협상. - 500명의 레코드가 한 블록에 다 들어가느냐? 4,8kb잡아도 500명분이 다 들어갈 순 없겠지. - 한 블록에 20개, 25개의 블록을 디스크에서 주기억장치 버퍼로 가져와서 모두 버퍼에 읽어서 급여를 6% 올려서 하다가, 25개를 다 버퍼에 올릴 수 있으면 다 올리면 되지. - 뭐 그랬다 치더라도 이걸 디스크에 동시에 기록하는건 불가능하지. 16번째 블록..

• format_list_bulleted UOS/UOS@DB
• · 2023. 12. 19.
• textsms

8장 뷰와 시스템 카탈로그

- 여기서의 뷰는 1장에서의 3단계 아키텍쳐 뷰가 아니라 다른 릴레이션으로부터 유도된 릴레이션! - 뷰를 만든 목적 : 1 보안 메커니즘 2 복잡한 질의 간단 표현 - 시스템 카탈로그는 시스템 내의 객체에 관한 정보를 가짐 -> 카탈로그를 잘 이해하고 활용하면 효율적이고, 편하다. - 관계 DB에서 뷰는 한 사용자가 DB를 보는 전체 관점이 아니라, 하나의 가상 릴레이션임. - create table해서 만드는게 기본 릴레이션임. 실제 릴레이션은 디스크에 레코드를 갖고 있는 릴레이션 -> 그럼 뷰는? 실제 레코드를 갖고있지 않음 .create view로 만듦. 창문을 통해 밖의 상태를 쉽게 알 수 있듯이, 뷰는 기본 릴레이션을 바탕으로 정의를 내림. 혹은 또 다른 뷰를 참조할 수도 있음. - 뷰는 레코드..

• format_list_bulleted UOS/UOS@DB
• · 2023. 12. 16.
• textsms

7장 릴레이션 정규화

- DB를 대충 설계하면 제어할 수 없는 데이터 중복이 일어남 -> 갱신 이상을 유발 - 정규화를 통해 이를 최소화 하나 정규화가 진행될수록 효율성이 떨어짐 -> 갱신 이상이 발생하지 않도록 한 다음 어디까지 정규화 할 것인지를 생각. - 스키마가 (a,b,c)라면 (a,b)만 추가하는게 불가능. (b,c)도 추가해야 (a,b,c)가 만들어짐. - 삭제도 마찬가지. (b,c)만 지우고 싶은데 (a,b)도 같이 지워짐. -> 일부만 수정하면 데이터의 불일치 발생 - 사원+부서에 관한 컬럼들이 있음. 여기서 부서를 3개까지 속할 수 있다고 한다던가, 부서를 하나로 제한한다고 한다면 컬럼의 변화가 생김 -> 부서 문제인데 사원 릴레이션이 영향을 받음. - 이번엔 김창섭 레코드가 2개가 된다. 부서 추가/삭제를..

• format_list_bulleted UOS/UOS@DB
• · 2023. 12. 15.
• textsms

6장 물리적 DB 설계(버퍼,디스크,인덱스 등)

- 논리설계의 결과로 릴레이션들의 모임이 정해지면, 그걸 채우는 레코드들이 디스크에 저장됨. 어떻게 릴레이션에 해당하는 파일의 구조를 디스크에 표현할 것인가 -> 인덱스(저장구조) - 기록 : 즉시 < 나중 → RAM에서 데이터가 변경될 때 마다 디스크에 기록한다? → 디스크 접근 시간은 많이 걸리기 때문에 최대한 늦췄다가 한번 기록하는게 좋음. - 디스크에서 블록을 읽어오는데는 seek time, rotation delay, transfer time(거의 무시) - 버퍼는 디스크블록들을 저장하는데 사용하는 주기억장치 공간. - 버퍼 관리자(매니저) : 운영체제의 구성요소. - LRU : 랜덤 접근할 땐 괜찮은데, 데이터베이스에서는 순차로 읽고 바로 버려도 됨. → LRU는 또 읽을지 모르니까 버퍼에 두..

• format_list_bulleted UOS/UOS@DB
• · 2023. 12. 7.
• textsms

5장 데이터베이스 설계와 ER모델(설계 사례 분석 및 릴레이션으로의 사상)

- 각 사원에 대해서, 사원번호 = 쪼갤 수 없음, 이름 = 쪼갤 수 없음, 직책 = 쪼갤 수 없음, 급여 = 쪼갤 수 없음, 주소 = 세분 가능 → 사원은 훌륭한 엔티티다. - 부양가족 엔티티 : 이름과 성별 저장 - 회사는 여러 프로젝트를 진행, 프로젝트는 여러 위치에서 진행 -> 위치는 다치 애트리뷰트 -> 총 3개의 엔티티 - 부품마다 이름, 가격 등의 정보 - 공급자마다 공급자 번호, 이름, 신용도를 나타냄 - 사원과 부양가족의 관계 : 속한다 - 프로젝트마다 여러 사원이 일을 함 : M:N 관계 - 각 사원이 프로젝트마다 다른 역할 -> 관계가 갖는 컬럼 : 어떤 역할 수행했는가 - 각 프로젝트마다 사원 중에 관리자 -> 사원은 부분참여, 프로젝트는 전체 참여 - 한 부서에 여러 사원이 근무 ..

• format_list_bulleted UOS/UOS@DB
• · 2023. 12. 3.
• textsms

5장 데이터베이스 설계와 ER모델(DB설계 개요, ER모델)

데이터베이스 설계 : 개념적 설계와 물리적 설계로 구분 - 개념적 : 실제로 데이터베이스를 어떻게 구현할 것인가와는 별개로 독립적으로 정보 사용의 모델을 개발하는 과정 -> 전체 업무에 관련된 엔티티와 릴레이션십(관계)으로 이루어진 설계 도면을 만드는 것 - 물리적 : 물리적인 저장 장치와 접근 방식을 다룸 -> 적절한 인덱스를 만들거나 불필요한 인덱스를 지우는 것 - 엔티티 : 서로 구분되는 데이터베이스에 나타나는 객체 - 개념적 수준의 모델 : 특정 데이터 모델(ex. 객체 데이터모델)과 독립적으로 응용세계를 모델링 -> DB 구조나 스키마를 탑-다운 방식으로 개발할 수 있는 틀을 제공 -> ER 모델과 같은 개념적 데이터 모델을 다수의 구현 데이터 모델로 사상(관계 구현단계에서)시킴. 설계 단계 :..

• format_list_bulleted UOS/UOS@DB
• · 2023. 11. 27.
• textsms

4장 관계대수와 SQL(트리거, 내포된 SQL)

- 트리거 : 명시된 이벤트가 발생할 때 마다 DBMS가 자동으로 수행하는 프로시저 -> 사용자 정의대로 수행되고, DB의 무결성 유지를 위한 일반적이고 강력한 도구임 - ECA(이벤트-조건-동작) 규칙이라고도 부름 - 트리거를 활성화 시키는 사건인 이벤트, 활성화 되었을 때 수행되는 조건, 활성화 되고 조건이 참일 때 수행되는 프로시저인 동작을 표현해야 함(조건이 만족되는지 테스트 후 만족되면 트리거 동작 수행) - AFTER : 이벤트 수행 후 트리거, BEFORE : 이벤트 수행 전 트리거 -> 활성화는 무조건 이벤트 수행 전에 됨. - 조건 : 임의의 프레디키트(논리적 식, 표현) - 50만원이라면, 늘어도 55만원 -> 완벽한 트리거는 아님 -> 앞의 문법과 조금 다름.. AFTER도 없다! F..

• format_list_bulleted UOS/UOS@DB
• · 2023. 11. 5.
• textsms