8장 뷰와 시스템 카탈로그

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

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

Sponsored search market

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

• format_list_bulleted 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@DB
• · 2023. 12. 15.
• textsms

Matching Market

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

• format_list_bulleted 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@SW APP
• · 2023. 12. 11.
• textsms

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

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

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

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

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

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