DB 설계 전 필수로 알아야 하는 개념

DB 설계 전 필수로 알아야 하는 개념

데이터베이스 모델링(Database Modeling)이란?

데이터베이스 모델링은 애플리케이션 운영에 필요한 데이터를 효율적으로 저장하고 관리하기 위해 데이터를 체계적으로 분류하고 구조를 설계하는 과정입니다.

관계형 데이터베이스(RDBMS)의 기본 구성

테이블(Table)

• 정의: 데이터베이스에서 데이터를 저장하는 기본 단위로, 행과 열로 이루어진 2차원 구조를 가집니다.
• 특징:
  • 테이블은 특정 주제나 개념을 나타내며, 예를 들어 고객 정보를 저장하는 테이블은 '고객'이라는 주제를 가지고 있습니다.
  • 각 테이블은 고유한 이름을 가져야 하며, 데이터의 논리적인 구조를 제공합니다.
• 예시:
  • Customers 테이블:

    CustomerID	Name	Email	Phone
    1	Alice	alice@email.com	123-456-7890
    2	Bob	bob@email.com	987-654-3210

---

열(Column)

• 정의: 테이블의 세로 방향으로, 특정 속성(attribute)을 정의합니다. 각 열은 데이터의 한 가지 유형이나 특징을 나타냅니다.
• 특징:
  • 모든 열은 고유한 이름을 가져야 하며, 해당 열이 나타내는 데이터 타입(예: 문자열, 숫자, 날짜 등)을 정의합니다.
  • 예를 들어, CustomerID는 숫자 타입이고, Email은 문자열 타입으로 정의됩니다.
• 예시:
  • Customers 테이블의 열:
    • CustomerID: 고객의 고유 ID
    • Name: 고객의 이름
    • Email: 고객의 이메일 주소
    • Phone: 고객의 전화번호

---

행(Row)

• 정의: 테이블의 가로 방향으로, 하나의 레코드(record) 또는 데이터의 인스턴스를 나타냅니다. 행은 실제 데이터를 저장합니다.
• 특징:
  • 한 행은 테이블에 정의된 모든 열에 대해 데이터를 제공합니다.
  • 예를 들어, 한 행은 특정 고객의 모든 정보를 나타냅니다.
• 예시:
  • 위의 Customers 테이블에서 첫 번째 행:
    • CustomerID: 1, Name: Alice, Email: alice@email.com, Phone: 123-456-7890

---

PK(기본키), FK(외래키)

PK(Primary Key, 기본키)란?

Primary Key(기본키)는 데이터베이스 테이블에서 각 데이터를 고유하게 식별하기 위해 사용하는 속성입니다. 테이블 내에서 기본키는 유일성을 보장하며, 중복될 수 없고, 비어 있는 값(NULL)을 허용하지 않습니다.
즉, 기본키는 테이블에 저장된 데이터 레코드 하나하나를 구별하는 역할을 하며, 데이터 무결성을 유지하기 위한 핵심 요소입니다.

예시:
Customers 테이블에서 CustomerID 열이 기본키로 사용될 경우, 각 고객의 고유 식별자가 됩니다.

CustomerID | Name   | Email
-----------|--------|-------------------
1          | Alice  | alice@email.com
2          | Bob    | bob@email.com

현업에서 PK(Primary Key)는 어떻게 설정할까?

1. 고유한 값 설정

   • PK는 데이터의 고유성을 보장해야 하므로, 중복될 가능성이 없는 값을 선택합니다. 일반적으로 자동 증가(AUTO_INCREMENT) 값을 사용하거나 UUID를 활용하는 경우가 많습니다.

2. 자연 키(Natural Key) vs 대리 키(Surrogate Key)

   • 자연 키: 실제 데이터에서 의미를 가지는 속성을 PK로 설정합니다. 예: 주민등록번호, 이메일 주소 등.
     • 장점: 데이터 자체에 의미가 있어 직관적입니다.
     • 단점: 변경 가능성이 있고, 데이터 크기가 클 경우 성능 저하가 발생할 수 있습니다.
   • 대리 키: 데이터와 무관한 대체 식별자를 PK로 설정합니다. 예: AUTO_INCREMENT 값, UUID 등.
     • 장점: 단순하고 효율적이며, 데이터 변경 시에도 안전합니다.
     • 단점: 데이터 자체와 관련이 없으므로 별도의 식별자 관리를 필요로 합니다.

3. 복합 키(Composite Key)

   • 두 개 이상의 열을 조합해 고유한 값을 생성하여 PK로 설정합니다.
   • 주로 관계 테이블(중간 테이블)에서 사용되며, 두 열이 함께 고유성을 보장합니다.
   • 예: 주문 테이블에서 OrderID와 ProductID의 조합을 PK로 설정.

4. 결론

   • 주민등록번호, 이메일 주소같은 자연 키는 변경될 가능성이 존재합니다. PK(Primary Key)가 바뀌게 되면 특정 데이터를 식별하던 값이 바뀌어서 데이터를 관리하거나 사용되는 입장에서 혼란이 올 수 있습니다. 따라서 현업에서는 PK(Primary Key)를 주로 Auto Increment(숫자가 1씩 증가하는 방식)나 UUID(랜덤값)로 설정을 많이 합니다.
   • PK는 데이터 검색, 정렬, 인덱스 생성에 영향을 미치므로, 크기가 작고 간결한 값이 유리합니다.
   • PK 열에 자주 사용하는 조회 조건(WHERE 절)이 포함되도록 설계하면 효율성을 높일 수 있습니다.

---

FK(Foreign Key, 외래키)란?

Foreign Key(외래키)는 한 테이블의 열(Column)이 다른 테이블의 Primary Key(기본키)를 참조하는 데 사용됩니다.
외래키는 데이터베이스에서 두 테이블 간의 관계를 정의하며, 데이터 무결성을 유지하는 데 중요한 역할을 합니다.

특징:

1. 참조 무결성: 외래키는 반드시 참조하는 테이블의 기본키 또는 고유 키를 가리켜야 합니다.
2. 관계 유형:
   • 1:1 관계: 하나의 행이 다른 테이블의 하나의 행과 연결됩니다.
   • 1:N 관계: 하나의 행이 다른 테이블의 여러 행과 연결됩니다.
   • N:M 관계: 다대다 관계를 표현할 때 중간 테이블을 통해 외래키를 사용합니다.
3. 제약 조건:
   • ON DELETE CASCADE: 참조된 데이터가 삭제되면, 해당 외래키가 있는 데이터도 자동으로 삭제됩니다.
   • ON UPDATE CASCADE: 참조된 데이터가 수정되면, 해당 외래키가 있는 데이터도 자동으로 수정됩니다.

예시:
Orders 테이블에서 CustomerID 열이 Customers 테이블의 기본키를 참조하는 외래키로 설정된 경우.

Customers 테이블:
CustomerID | Name
-----------|--------
1          | Alice
2          | Bob

Orders 테이블:
OrderID | CustomerID | OrderDate
--------|------------|----------
101     | 1          | 2024-01-01
102     | 2          | 2024-01-02

데이터베이스 네이밍 규칙

테이블명, 컬럼명을 소문자로 작성한다.

• 이유:

  • 대소문자 구분이 있는 데이터베이스(MySQL 등)에서 일관성을 유지하고, 혼동을 줄이기 위함입니다.
  • 다양한 환경에서 소문자를 기본적으로 사용하는 경우가 많으므로 호환성을 높일 수 있습니다.

• 예시:

  • 테이블명: customers, orders
  • 컬럼명: customer_id, order_date

• Good vs Bad:

  • Good: customers, order_date
  • Bad: Customers, OrderDate

---

snake_case를 사용한다.

• 정의:

  • 여러 단어로 이루어진 이름을 작성할 때, 단어 간 구분을 밑줄(_)로 표시하는 네이밍 규칙입니다.
  • 소문자로 구성하며, 단어 간의 가독성을 높이는 효과가 있습니다.

• 장점:

  1. 일관성: 네이밍 스타일을 통일함으로써 유지보수가 용이해집니다.
  2. 가독성: 단어 간 구분이 명확해져 이름을 쉽게 읽을 수 있습니다.
  3. 표준화: SQL에서 널리 사용하는 표준적인 방식으로, 협업 시 이해도를 높입니다.

• 예시:

  • 테이블명: user_profiles, product_reviews
  • 컬럼명: user_id, created_at, last_login_time

• Good vs Bad:

  • Good: user_profiles, last_login_time
  • Bad: UserProfiles, lastLoginTime

축약어를 사용하지 않는다

• 정의:

  • 테이블명이나 컬럼명에 축약어를 사용하지 않고, 전체 단어를 명확히 기재합니다.
  • 축약어는 혼동을 초래할 수 있으며, 협업 시 의미를 이해하기 어려울 수 있습니다.

• 이유:

  1. 가독성 향상: 축약어는 팀원마다 해석이 다를 수 있어 혼란을 초래합니다. 전체 이름을 사용하면 의도를 명확히 전달할 수 있습니다.
  2. 유지보수 용이: 축약어가 포함된 이름은 시간이 지나면 의미를 잊기 쉽습니다.
  3. 명확한 의사소통: 협업 환경에서 테이블과 컬럼명을 보고도 해당 데이터의 의미를 쉽게 알 수 있습니다.

• 예시:

  • 테이블명:
    • Good: customer_orders
    • Bad: cust_orders
  • 컬럼명:
    • Good: created_at
    • Bad: crt_at

• Good vs Bad:

  • Good: customer_orders, created_at
  • Bad: cust_orders, crt_at

SQL문을 작성할 때 예약어만 대문자로 표현해라

• 정의:
  SQL 문 작성 시 예약어(KEYWORD)는 대문자로, 테이블명과 컬럼명은 소문자로 작성합니다. 이를 통해 SQL 코드의 가독성을 높이고, 명확한 구조를 유지할 수 있습니다.

• 이유:

  1. 가독성 향상: 예약어와 사용자 정의 객체(테이블명, 컬럼명 등)를 명확히 구분하여 코드 읽기가 수월합니다.
  2. 일관성 유지: 코드 스타일을 통일하여 팀원 간 협업 시 혼란을 줄입니다.
  3. 표준화: SQL 작성에 있어 널리 사용되는 관례를 따릅니다.

• 예시:

  -- Good
  SELECT customer_id, order_date
  FROM customers
  WHERE status = 'active';
  
  -- Bad
  select CUSTOMER_ID, ORDER_DATE
  from CUSTOMERS
  where STATUS = 'active';

테이블명을 지을 때는 복수형을 사용한다. (선택)

• 정의:
  테이블명을 설정할 때 데이터가 여러 레코드(행)로 구성된다는 점을 강조하기 위해 복수형을 사용하는 것을 권장합니다. 예를 들어, 사용자 데이터를 저장하는 테이블은 users, 주문 데이터를 저장하는 테이블은 orders로 명명합니다.

• 이유:

  1. 의미 명확화: 테이블이 단일 엔티티가 아니라 여러 레코드(행)를 포함한다는 점을 암시합니다.
  2. 일관성 유지: 모든 테이블명을 복수형으로 통일하면 코드의 가독성과 유지보수가 용이합니다.
  3. ORM 도구 호환성: 많은 ORM(Object-Relational Mapping) 도구에서 복수형 테이블명을 기본으로 사용하기 때문에 호환성을 보장합니다.

• 예외:

  • 특정 비즈니스 로직이나 팀 규칙에 따라 단수형을 사용하는 경우도 있습니다. 예: user_profile (개별 사용자의 프로필만 저장하는 경우).

• 예시:

  • Good: users, products
  • Bad: user, product

• Good vs Bad:

  • Good:
    • customers, orders
    • articles, comments
  • Bad:
    • customer, order
    • article, comment