트랜잭션

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

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

Link Analysis and Web Search

그래프 데이터는 map, SNS, … 데이터 하나하나가 노드인데, 데이터 간 연관상황이 생기는 것. 이걸 그래프로 표현할 때 제일 간단명료하게 표현할 수 있다. 웹그래프에서 노드를 분석할수도 있지만, 노드는 각각 분리된 정보들. 재밌는 일은 이 노드들이 복잡하게 연결되어서 벌어지는 거니까, 그래프 중에서도 노드가 아니라 링크 분석임. 인포메이션 리트리벌이라는 말 알아둬라. 줄임말 IR → document쪽에서 많은 document가 모여있을 때 키워드 중에서 document를 뽑아내는 분야가 IR. 라이브러리 사이언스와 같은 학과에서 이게 가장 중요함. Synonymy : 파(양파 쪽파 대파 등등 종류) Polysemy : 재규어 -> 동물, 차 등등 사람들이 똑같은 생각을 가져도 검색어를 똑같이 쓰지 ..

• format_list_bulleted UOS/UOS@SW APP
• · 2023. 12. 16.
• textsms

8장 뷰와 시스템 카탈로그

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

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

Sponsored search market

- 이러한 키워드 기반 검색으로 한정하여, 어떻게 광고하는 것인지 볼 것! - 돈은 어떻게 내는가? 클릭 당 가격! -> 이 가격은 클릭 당 기대수익이 어떻게 되는가에 대한 것을 고려하여 책정됨. - 키워드가 너무 많고 조합까지 할 수 있으니, 너무 많음 -> 각 키워드에 관심있는 회사는 많지 않다 -> 광고주들이 바라는 것들이 변화하는 상황에서 price 책정이 어려우므로 옥션으로 결정! -> 슬롯이 하나였다면 sealed-bid second-price 옥션, 여러개면 복잡! 서치회사의 광고 슬롯의 가치가 다를 수 있다. 서치 회사가 각 애드버타이저들의 클릭당 밸류에이션을 알고 있으면 → 바로 매칭 마켓 문제가 됨. 어떤 슬랏을 어느 애드버타이저한테 매칭시킬지가 됨. 애드버타이저의 클릭 당 밸류에이션을..

• format_list_bulleted UOS/UOS@SW APP
• · 2023. 12. 15.
• 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

Matching Market

- 바이팔타이트 : 노드 타입이 두가지인 그래프. 방과 사람 두 편이 있는데, 나는 이 방에 관심있어요 하는게 링크임. -> 전형적으로 쇼핑몰에서 서치엔진 같은 것 생각할때도, 고객들이 있고 물건들이 있음. 누가 무슨 물건 샀다 하는 정보를 이용해서 추천을 함. 이것도 물건이 물건을 살 순 없잖아? - 모든 사람에게 모든 방을 배치할 경우에는 우측 굵은 링크대로 하면 각1방 배정받게 됨. 이런 상황을 퍼펙트매칭이라고 한다. - 여기서의 어사인먼트(누구에게 무엇을 준다 하는 내용 자체 = 할당) : 매칭, 배정시키는 것. -> 같은 개수의 방과 사람인 바이팔타이트 그래프라고 했을 때 오른쪽 사람들에게 왼쪽 노드를 어사인하는 것. - 퍼펙트매칭의 조건 : 각 노드는 한개의 노드로 반대노드와 연결되어야하고, ..

• format_list_bulleted UOS/UOS@SW APP
• · 2023. 12. 12.
• textsms

Auction

1. Ascending-bid : 오름차순 -> 가격 올리면서 일반적인 경매 2. Descending-bid : 더치 경매. 판매자가 가격 내리면서 구매자가 딱 수락하는 지점에서 3. First price sealed-bid : 비밀로 함 -> 가장 높은 가격 낙찰 4. Second-price sealed-bid : 비밀로 함 + 가장 높은 가격 낸 사람이 두번째 사람 가격을 내고 낙찰 - Ascending-Bid and Second-Price Auctions : 실제 가치에 도달하는 정확한 순간까지 오름차순 입찰 경매에 참여해야 한다는 것을 나타냄 -> 요점은 첫 번째 가격 경매의 입찰자는 두 번째 가격 경매에서보다 낮은 입찰을하는 경향이 있으며 실제로 이러한 입찰가 하락은 낙찰 가격의 차이처럼 보일 ..

• format_list_bulleted UOS/UOS@SW APP
• · 2023. 12. 11.
• textsms