Database; 모델링, RDB

오늘 한 것

1. 미디어 관련 모델링 (MongoDB)

• MongoDB에서는 속성의 네이밍을 최대한 줄인다. (성능이슈)

// 미디어 schema
{
    mediaId: UUID(),
    media: {
        mediaPath : "uri or url string",
        mediaMetadata: {
            mediaType:"dedicate,cloud,publish",
            mediaTitle:"media title string",
            uploadDate: ObjectId.getTimestamp(),
            modifiedDate: "timedate",
            exif:{ //EXIF데이터가 들어가면 좋겠다 
            },
        }
    }
},
// 카테고리 schema
{
    categoryId: UUID(),
    categoryTitle: "category title string",
    categoryMetadata:{
        description: "string"
    }
    includeMedia: [mediaId1, mediaId2, mediaId3, categoryId2]
}

2. 실습용 MongoDB 준비

• install MongoDB

brew install mongodb-community
brew services start mongodb-community
mongo

• 기본 db path는 /usr/local/var/mongodb다.
• 꼭 설치하지 않아도 기본 쿼리 몇가지는 웹에서 날려볼 수 있다.

---

습득한 지식

1. NoSQL과 RDB의 구조적 차이점

RDBMS	MongoDB
Database	Database
Table	Collection
Tuple / Row	Document
Column	Key / Field
Table Join	Embedded Documents
Primary Key	Primary Key (_id)
Database Server & Client
mysqld	mongod
mysql	mongo

2. NoSQL만의 특징

• 스키마가 없다. 그래서 하나의 collection(즉, 테이블) 안에 다양한 구조의 document(즉, 데이터)를 밀어넣을 수 있다.
• 데이터는 구조로 표시된다.
• 중첩구조가 가능하다 (value, dictionary, list…)

3. EAV패턴 (데이터 모델링)

• EAV패턴은 짧게 정리하면 데이터 구조의 변화 없이 속성(attribute)을 확장할 수 있다.
• 속성에 대한 테이블을 따로 관리함으로써 구조에 종속되지 않고 유연한 데이터를 만들 수 있다.
• 짤막한 예시를 들어보자.

• 위와 같이 users와 attributes가 있을 때 users에 attribute를 추가하는것이 아니라 userdata용도로 데이터를 연결할 수 있는 테이블을 하나 더 만들어서 관계를 맺어준다.
• 그러면 users의 구조를 변경하지 않아도 필요한 데이터를 유연하게 추가할 수 있다.
• 가령 데이터가 여러가지 중복되는 취미같은 것들.

4. UUID

• universally unique identifier
• 128bit 의 수를 표시한다. 32개의 16진수로 표현된다.
• 8자리-4자리-4자리-4자리-12자리의 레코드 그룹으로 표기된다
• 각 레코드의 그룹 내용
• 왠만한 언어, 프레임워크, 서비스 등등에서 UUID생성자를 내장 함수로 제공한다.

5. 전통적인 엔터티 관계 (데이터 모델링)

1) 1:1 관계

• 부부관계
• 주민등록번호 관계

2) 1:N 관계

• 부모관계 (형제가 둘 이상일 수 있다)
• 조직도, 직급
• 담임선생님과 학생

3) N:M 관계

• 직원들의 취미 (중복 가능)
• 맨 위의 카테고리 관계