데이터 모델링

백엔드 시스템은 데이터를 중심으로 구축됩니다. 사용자, 게시물, 주문, 결제 같은 모든 기능은 구조화된 정보를 안정적으로 저장하고 조회하는 데 의존합니다.

데이터베이스를 선택하거나 쿼리를 작성하기 전에, 엔지니어는 데이터 모델을 정의해야 합니다. 여기에는 어떤 데이터가 존재하는지, 서로 다른 데이터 조각들이 어떻게 서로 관련되는지, 그리고 모든 것을 어떻게 조직해야 하는지가 포함됩니다.

이 단계에서 선택한 구조는 장기적인 결과를 가져옵니다. 좋지 않은 데이터 모델은 비효율적인 쿼리, 중복 데이터, 그리고 시스템 확장 어려움을 초래합니다. 나중에 이를 수정하는 것은 비용이 많이 들며, 종종 대규모 리팩터링이 필요합니다.

흐름은 간단합니다. 애플리케이션이 요구사항을 정의하고, 데이터 모델이 그 요구사항을 정리하며, 데이터베이스가 그 결과를 저장합니다. 명확한 데이터 모델이 없으면 데이터베이스는 무질서해지고 유지보수가 어려워집니다.

엔티티는 모든 데이터 모델의 기반입니다. 엔티티는 사용자, 게시물, 댓글, 주문, 제품처럼 시스템에 존재하는 주요 객체를 나타냅니다. 이러한 객체는 애플리케이션이 지원해야 하는 요구사항에서 직접 도출됩니다.

각 엔티티는 관련된 데이터를 하나로 묶습니다. 예를 들어, User 엔티티에는 name, email, created date 같은 필드가 포함될 수 있고, Post 엔티티에는 title과 content가 포함될 수 있습니다. 이렇게 묶으면 데이터가 체계적이고 의미 있게 유지됩니다.

실제로 엔티티는 데이터베이스 구조에 매핑됩니다. 관계형 데이터베이스에서는 테이블이 되고, NoSQL 시스템에서는 컬렉션이나 문서로 표현될 수 있습니다. 이 매핑은 애플리케이션 개념과 실제 저장된 데이터를 연결해 줍니다.

엔티티를 초기에 명확하게 정의하는 것은 매우 중요합니다. 엔티티를 잘못 정의하면 이후 개발 과정에서 혼란, 중복 데이터, 비효율적인 쿼리가 발생합니다.

엔티티는 거의 독립적으로 존재하지 않습니다. 대부분의 시스템에서는 데이터가 연결되어 있어야 합니다. 예를 들어, 사용자는 게시물을 만들고, 게시물에는 댓글이 달립니다. 이러한 연결은 관계를 통해 정의됩니다.

일반적인 관계 유형은 여러 가지가 있습니다. 일대일 관계는 한 엔티티의 각 레코드가 다른 엔티티의 정확히 하나의 레코드와 대응된다는 뜻입니다. 예를 들어 사용자와 프로필이 이에 해당합니다. 일대다 관계는 하나의 엔티티가 여러 다른 엔티티와 연결될 수 있다는 뜻입니다. 예를 들어 사용자가 여러 게시물을 가질 수 있습니다. 다대다 관계는 양쪽의 여러 엔티티가 서로 연결될 수 있다는 뜻입니다. 예를 들어 학생이 여러 과목에 등록하는 경우입니다.

이러한 관계는 관계형 데이터베이스의 외래 키와 같은 참조를 사용해 구현됩니다. 이를 통해 시스템은 데이터를 불필요하게 중복하지 않고도 엔티티 간에 연결할 수 있습니다.

관계를 올바르게 정의하는 것은 데이터를 효율적으로 조회하는 데 매우 중요합니다. 이는 시스템이 관련 정보를 얼마나 쉽게 가져올 수 있는지를 결정하며, 성능과 데이터 일관성에 직접적인 영향을 줍니다.

스키마는 데이터가 데이터베이스에 저장되는 방식을 나타내는 청사진입니다. 어떤 필드가 존재하는지, 각 필드가 어떤 데이터 타입을 가지는지, 그리고 서로 다른 엔터티가 어떻게 연결되는지를 정의합니다.

예를 들어, Users 구조에는 id, email, created_at 같은 필드가 포함될 수 있고, Posts 구조에는 id, user_id, title, content가 포함될 수 있습니다. 각 필드는 string, integer, timestamp와 같은 정의된 데이터 타입을 가집니다.

스키마는 또한 제약 조건을 강제합니다. 이러한 규칙은 데이터 무결성을 보장합니다. 예를 들어, 특정 필드가 반드시 존재해야 하거나, 고유한 값을 강제하거나, 엔터티 간의 유효한 관계를 유지하도록 합니다.

잘 정의된 스키마는 일관되지 않거나 유효하지 않은 데이터가 시스템에 들어오는 것을 방지합니다. 이는 애플리케이션과 데이터베이스 사이에 명확한 계약을 제공하여, 시스템을 더 쉽게 이해하고 유지보수할 수 있게 합니다.

정규화는 각 정보가 한 번만 저장되도록 데이터를 구조화하는 과정입니다. 같은 데이터를 여러 레코드에 반복하는 대신, 서로 다른 엔티티로 분리합니다.

예를 들어, 이름 같은 사용자 정보는 모든 게시물에 반복해서 저장하면 안 됩니다. 대신 사용자 데이터는 Users 구조에 저장하고, 게시물은 user_id를 통해 사용자를 참조합니다.

이 방식은 중복을 줄이고 일관성을 보장합니다. 사용자의 이름이 바뀌면 여러 레코드를 수정할 필요 없이 한 곳만 업데이트하면 됩니다.

정규화는 저장 효율성을 높이고 업데이트를 단순화합니다. 하지만 조회할 때 여러 엔티티를 조인해야 하는 경우가 많아, 이를 적절히 관리하지 않으면 성능에 영향을 줄 수 있습니다.

비정규화는 정규화와 반대되는 접근 방식입니다. 데이터를 엄격하게 분리하는 대신, 쿼리를 더 빠르게 만들기 위해 일부 정보를 엔티티 간에 의도적으로 중복 저장합니다.

예를 들어, posts에 user_id만 저장하는 대신 시스템은 Posts 구조에 user_name도 직접 저장할 수 있습니다. 이렇게 하면 posts를 조회할 때마다 Users 데이터와 조인할 필요가 없습니다.

이 접근 방식은 특히 데이터베이스 조인을 최소화하는 것이 중요한 읽기 중심 시스템에서 성능을 향상시킵니다. 또한 필요한 모든 데이터를 한 번의 작업으로 가져올 수 있는 경우가 많아 쿼리 로직도 단순해집니다.

단점은 일관성입니다. 사용자 이름처럼 중복된 데이터가 변경되면 여러 위치에서 업데이트해야 합니다. 이를 제대로 처리하지 않으면 시스템 전반에 오래되었거나 불일치한 데이터가 생길 수 있습니다.

일반적인 소셜 시스템은 사용자, 게시물, 댓글이라는 세 가지 주요 엔티티로 모델링할 수 있습니다. 각 엔티티는 애플리케이션 기능의 서로 다른 부분을 나타냅니다.

사용자는 게시물을 만들고, 게시물에는 여러 댓글이 달릴 수 있습니다. 댓글은 해당 게시물과 댓글을 작성한 사용자 모두와 연결됩니다. 이러한 관계는 데이터가 시스템을 통해 어떻게 흐르는지를 정의합니다.

데이터베이스에서는 이 구조가 Users, Posts, Comments와 같은 별도의 테이블 또는 컬렉션으로 표현됩니다. 관계는 게시물의 사용자 식별자와 댓글의 게시물 식별자 같은 참조를 사용해 구현됩니다.

이 예시는 엔티티와 관계 같은 추상적인 개념이 실제로 어떻게 결합되는지를 보여줍니다. 잘 구조화된 데이터 모델은 애플리케이션의 동작 방식을 반영하여 데이터를 더 쉽게 저장, 조회, 관리할 수 있게 합니다.

데이터 모델 설계는 애플리케이션의 요구사항을 이해하는 것에서 시작합니다. 엔지니어는 먼저 사용자, 주문, 제품과 같이 시스템에 필요한 주요 엔터티를 식별합니다.

다음으로, 이러한 엔터티 간의 관계를 정의합니다. 이는 데이터가 어떻게 연결되는지와 어떻게 조회될지를 결정합니다. 명확한 관계는 효율적이고 이해하기 쉬운 시스템을 구축하는 데 필수적입니다.

엔터티와 관계가 정해지면 스키마를 설계합니다. 여기에는 필드, 데이터 타입, 제약 조건을 정의하는 것이 포함되며, 이후 중복을 줄이고 일관성을 높이기 위해 정규화를 수행합니다.

마지막으로, 일반적인 쿼리의 성능을 최적화하기 위해 인덱스를 추가합니다. 이 단계는 시스템이 실제 사용 환경에서 효율적으로 확장되고 처리할 수 있도록 보장합니다.

이 전체 과정은 높은 수준의 애플리케이션 요구사항을 데이터베이스가 안정적으로 저장하고 제공할 수 있는 구조화된 데이터 모델로 바꿉니다.