Fundamental›Database

데이터베이스는 다수의 사용자가 동시에 사용하더라도 항상 모순이 없는 정확한 데이터를 유지해야 한다. 장애 상황에서 마찬가지다. DBMS는 데이터가 정확하고 일관된 상태를 유지할 수 있도록 다양한 기능을 제공하는데 그 중에 하나가 트랜잭션이다. 트랜잭션은 한 작업을 수행하는 데 필요한 데이터베이스의 연산들을 모아놓은 것으로 데이터베이스에서 논리적인 작업의 단위가 된다. 장애 발생시 복구하는 작업의 단위도 된다. 데이터베이스의 무결성과 일관성을 보장하기 위한 4가지 특성이 있다. → 원자성, 일관성, 격리성, 지속성 앞의 4글자를 가져

정규화는 데이터베이스를 설계한 후 설계 결과물을 검증하기 위해 사용하기도 한다. 잘못 설계된 데이터베이스는 이상현상이 발생할 수 있다. 새 데이터를 삽입하기 위해 불필요한 데이터도 함께 삽입해야 하는 문제 위 릴레이션에서 새로운 tuple을 삽입하려면 이벤트번호과 당첨여부까지 삽입해야 하는 이상현상. 중복 tuple 중 일부만 변경하여 데이터가 불일치하게 되는 모순의 문제 위 릴레이션에서 tuple중 일부만 수정되어 데이터가 불일치 하게 되는 이상현상이다. tuple을 삭제하면 꼭 필요한 데이터까지 함께 삭제되는 데이터 손실의 문제

데이터베이스 설계는 사용자들의 요구사항을 고려하여 데이터베이스를 생성하는 과정이다. 데이터베이스에 실제로 데이터가 저장되기 시작하면 구조를 변경하기 매우 어렵다. 저장된 데이터와 설계된 구조를 모두 지우고 데이터베이스 scheme을 재작성 해야하는 것은 물론, 어플리케이션에서 데이터베이스에 접근하는 코드 역시 수정이 필요하기 때문이다. 많은 라이브에서 데이터베이스에서 계속 사용중이기 때문에 일관성과 무결성을 지키며 무중단으로 migration 하는 것은 어렵다. RDB모델을 기반으로 두고 데이터베이스를 설계할 때는 두 가지 방법을

릴레이션의 예시 Attribute 속성 : 각 데이터를 의미하는 이름 Tuple 투플 : entity instance, record. Domain 도메인 : 속성의 타입을 의미한다. 예를들어 age는 int로 정의할 수 있다. Null Degree 차수 : attribute의 갯수 여기서는 7개다 Cardinality 카디널리티 : tuple(entity instance)의 갯수 Tuple의 유일성 : 하나의 relation에는 동일한 tuple이 존재 할 수 없다. Tuple의 무순서 : tuple간에는 순서가 없다. 효율을 위해

개념적 모델링 : 추상화 과정을 통해 중요한 데이터를 추출해 나열한다. 논리적 모델링 : 나열한 데이터의 구조를 결정하고 표시한다. 이 과정을 굳이 분리하지 않고 데이터 모델링으로 이야기한다. 데이터 모델은 데이터 모델리의 결과물을 표현하는 도구. 개념적 데이터 모델 : 사람이 이해할 수 있는 모델링을 통해 개념적 구조로 표현 논리적 데이터 모델 : 데이터베이스의 논리적 구조로 표현 entity 개념 = 테이블의 record 개세는 사람과 사물처럼 물리적으로 존재하는 것만을 의미하지 않는다. 개체는 다른 개체와 구별되는 이름을 가지

RDB는 오랜시간 대표적인 DBMS의 자리를 지켜왔다. 그러나 소셜서비스의 규모가 커짐에 따라 비정형 데이터를 이용하고자 하는 빅데이터 개념과 인프라 에코시스템도 클라우드 컴퓨팅의 바람이 불어오면서 기존의 RDB가 가진 단점들이 부각되기 시작했다. RDB를 유지하면서 스케일업 하는것은 한계가 있기 때문이다. 시대적 흐름이 NoSQL의 등장을 이끌었다. RDB의 특징인 ACID 일부를 포기 하고 스키마를 없앴다. 이로인해 비정형 데이터를 신속하게 저장하고 처리하는데 적합했다. 정합성을 포기하며 분산 처리로 인해 뛰어난 확장성 또한 장

위와 같이 미디어 타입으로 언급된 것은 다음과 같은 고민이 있기 때문이다. 미디어와 글을 같은 타입으로 볼 것인가 → 전통적인 CMS와 다르게 모든 글을 가지고 올 때 개별 사진을 같이 가지고 왔으면 좋겠다. 즉, 글이 주가되는 CMS가 아니라 사진이 주를 이루는 CMS. 미디어에 캡션을 얼마나 부착할 것인가 → 가령 한장의 사진이나 유투브 영상에 담긴 스토리에 대한 reference 결론적으로 미디어도 하나의 글(객체)이면 좋겠다. 아래와 같이 고쳐본다 아래와 같이 linkedDocument로 따로 관리한다. 왠만하면 마크다운을

MongoDB에서는 속성의 네이밍을 최대한 줄인다. (성능이슈) install MongoDB 기본 db path는 /usr/local/var/mongodb다. 꼭 설치하지 않아도 기본 쿼리 몇가지는 웹에서 날려볼 수 있다. 스키마가 없다. 그래서 하나의 collection(즉, 테이블) 안에 다양한 구조의 document(즉, 데이터)를 밀어넣을 수 있다. 데이터는 구조로 표시된다. 중첩구조가 가능하다 (value, dictionary, list…) EAV패턴은 짧게 정리하면 데이터 구조의 변화 없이 속성(attribute)을 확장