CASSIE'S BLOG

패킷으로 현대정보들을 교환하고 있다. 이 방식을 패킷교환방식이라고 한다. 패킷은 많은 헤더들이 있고 이 계층형 프로토콜에 따라서 덧붙여지고 해석할 때는 때지면서 해석이 된다. 패킷을 보내는 주체를 클라이언트라고하고 패킷을 받는 주체를 서버라고 하겠대 구글, 네이버가 서버-클라이언트 구조를 갖고 있다고함. 역할이 딱 분리되어있다고함. 클라이언트는 요청을 보내기만하고 서버는 응답을 하기만하고 서버가 먼저 클라이언트한테 요청하는 거는 거의없다. 이게 그 토렌트 형식임 명확히 서버라는 주체가 없다. 다 분산되어있어서. 서버-클라이언트 구조에서 좀 확장된 형태 클라이언트가 요청을 하고 클라이언트는 클라이언트삼에게 요청을 보내고 싶은데 클라이언트3에게 요청을 바로 하는 것이 아니라 중간에 무조건 서버를 거치게 되어..

Xlookup 같은 식박한 게 있었음COUNTBLANK 통해서 빈셀의 갯수도 셀 수 있음 COUNTIF 여러 셀에 거쳐 사선 긋기 중복값만 색깔 표시했는데 평균이상도 컬러 표시 가능 오류 서식으로 골라내기 표 아무데나 누르고 ctrl + a -> alt + h + a + l 이건 왼쪽 정렬 글꼴 바꾸기 Alt + H + F + F 글자부분은 왼쪽 숫자부분은 오른쪽이 맞는 듯 차트 합계 표시하는게 좀 까탈스럽긴함

실습 건너뜀 강의 시작하자마자

각 유저마다 요구기능이 다를 수 있어서 복잡할 수 있다.      시나리오를 짜봐야지 어떤 db가 필요하고 어떻게 관리할지 그림이 그려짐 항공권과 항공편은 다른거다. 항공권 왕복이면 두개의 항공편이 있잖아예약과 결제같은 경우에는 이거를 엔티티로 보냐 안보냐도 충분히 논의주제가 될 수도 있다썜의 경우에는 예약과 결제같은 경우는 엔티티로 빼야 관리하기가 편하다고 생각하는 사람 중에 한명이라 함.다섯 개의 후보를 봅아봤다고 함.그래야 모델링을 시작할 수 있다함.  엔티티후보와 엔티티 무조건 똑같지않아도 된다함.  erdcloud.comdraw.io 두개 중에 하나로 그리면 되는데 draw.io를 선호한다고함 -user이 너무 general한 것 같아서 승객으로 따로 뺐다고함 1:1 발견2번째 문장에 여러 개 ..

HAVING으로 그룹화된 것들 조건으로 또 거는 것  관계형 db인 rdb의 관계에서 제일 중요한 것 2가지  rdb에서는 어떤 목적, 상하관계 이런 게 없다. 관계의 선택성 (관계의 중요성), 다중성 이거 밖에 없다.  페어링은 이 관계가 무조건 페어 즉 싱크를 맞추고 있어야하나 이 뜻 임.  동그라미랑 수직에 대해서 여태껏 몰랏네 자식에서 부모 방향으로 읽으면 수직바라서 "자식은 부모를 가져아한다" 가 되는 거임 동그라미같은 경우에는 가질 수 있다니까 0또는 1 이렇게 해석하면 되고수직바 2개면은 오른쪽 수직바는 그냥1이라는 뜻이고 왼쪽의 수직바는 mandatory 필수적인 1이다. one => 에 설명되어있는 뜻  까치발이 many뜻인데 동그라미가 있으면은 동그라미는 가질 수 있고 안 가질 수도 있..

신용장신용장방식은 수출자와 수입자가 서로 믿을 수 없을 때 은행으로 하여금 대금지급을 약속하는 방식이다. 즉 신용장이란 수입자를 대신에서 수입자가 거래하는 (개설은행)에서 수출자에게 대금을 지급하겠다고 약속하는 증서로서 수출자는 개설은행의 약속을 믿고 물건을 선적한 다음 신용장에서 요구하는 서류를 은행에 제출하고 대금을 지급받는다. 주의사항신용장방식의 거래가 신용장에서 요구하는 서류와 상환하여 대금결제가 이루어짐에 따라 수입자로서는 실제 선적한 물품이 계약내용과 다르더라도 서류상 문제가 없으면 대금지급을 거부할 수 없으며, 수출자로서는 물품을 제대로 선적하더라도 서류상 문제가 있으면 대금지급을 거부당할 수 있다. 최소불능신용장 (Irrevocable L/C)신용장 관련 당사자 전원의 합의 없이는 취소하거..