DB 설계 규칙 정리

DB 네이밍 규칙 테이블명, 컬럼명은 소문자로 작성하고 snake_case를 사용한다. 테이블명은 복수형을 사용하자. (선택사항) 여러 개 데이터를 가지고 있음을 표현 회사마다 규칙이 갈리므로, 복수형이든 단수형이든 일관성 있게만 사용하면 됨 축약어를 사용하지 않는다. SQL문은 예약어만 대문자로 작성하자. (SELECT, FROM, WHERE…) DB 설계 핵심 원칙 핵심 원칙: 중복 없애기 (정규화) 데이터 간 모순(이상 현상)의 근본적 원인은 데이터 중복이고, 정규화는 데이터 중복을 제거 e.g. 두 테이블에 작성자 컬럼이 있는데, 모두 수정하다가 한 데이터를 빼먹으면 갱신 이상 발생 DB 설계 과정 저장해야 하는 데이터 파악하기 대략적인 UI 디자인 기획을 보고 필요한 데이터 파악 가끔 글로만 정리된 요구사항이 있을 수 있지만, 놓치는 부분이 생길 수 있어 좋지 않은 방식 기준: 나중에 조회해서 쓸 일이 있겠다 싶은 데이터를 전부 저장 그룹핑해서 분류하기 관련 있는 것들끼리 묶어 상위 개념을 찾음 (= 엔터티 = 테이블) 따로 법칙이 있다기보다 인간이 모두 가지고 있는 보편적인 분류 능력을 따르자 e.g. 아이디, 패스워드, 이름, 이메일 → 사용자 (엔터티) 영화 이름, 영화에 출연한 배우, 영화 상영 시간 → 영화 (엔터티) 게시글 제목, 게시글 내용, 게시글 생성 시간 → 게시글 (엔터티) 6가지 규칙을 적용하며 테이블 분리해나가기 유의점 데이터 예시를 입력하며 파악하자 규칙 1 + 규칙 2의 결과는 규칙 3의 결과 동일 (무얼 선택해도 괜찮음!) 처음에 완벽한 설계가 안돼도 추후 데이터 중복을 발견해 수정 가능하니 불안해하지 말자 연관 관계 파악 관련 규칙 규칙 1: 한 칸에 한 가지 정보만 들어가야 한다 (제1정규형) 한 칸에 두 가지 정보가 있을 시, 테이블을 분리하고 FK를 적용 FK 적용이 규칙 1을 어길 경우, 반대쪽 테이블에도 FK를 적용해보자 ‘한 가지 정보’의 기준은 절대적이지 않아서, 자신의 서비스에 맞게 판단해야 함 e.g. 손/흥민 or 손흥민, 01012341234 or 010/1234/1234 규칙 2: 어떤 테이블에 FK를 넣어도 ‘규칙 1’을 못 지킬 때는 중간 테이블을 하나 더 만들자 양쪽 테이블의 FK를 중간 테이블로 옮기기 중간 테이블의 이름은 동사를활용하면 좋음 (직관성, 가독성 상승) e.g. students & courses -> course_registrations {id(PK), student_id(FK), course_id(FK)} movies & actors -> casting {id(PK), movie_id(FK), actor_id(FK)} 규칙 3: 헷갈릴 땐 연관 관계를 파악해보자 (1:1, 1:N, N:M) 판단 방법 엔터티 간에 어울리는 동사를 찾기 (A가 B를 ___.) e.g. 사용자가 이메일을 소유한다. 이메일은 사용자에 의해 소유되어진다. 적절한 단어 찾기 (하나의 or 여러개의) e.g. ‘하나의’를 고정해서 따져보기 하나의 사용자는 ___ 이메일을 소유한다. 하나의 이메일은 ___ 사용자에 의해 소유되어진다. 관계 파악하기 (1:1, 1:N, N:M) e.g. 사용자와 이메일은 1: N 관계 1:N 관계 N 쪽 테이블에 FK 들어가야 함 N:M 관계 중간 테이블이 있어야 하고, 중간 테이블에 두 테이블의 FK가 들어가야 함 (1:N으로 해소) 1:1 관계 아무 테이블에 FK를 넣어도 됨 합쳐도 되는지 고려해보자 (왠만하면 1:1 관계로 분리하지 않는 걸 추천) 통쨰로 조회하는 일이 많다면 합치는게 좋음 만약 각각 따로 조회할 일이 많다면 분리하는게 좋음 중복 없애기 관련 규칙 규칙 4: 데이터 중복이 발생하는 컬럼이 있는지 확인하자 임의의 데이터를 넣고 시뮬레이션해서 데이터 중복 발생 여부 파악 e.g. 게시물 테이블의 작성자 데이터가 중복됨 중복이 있다면 테이블 분리하고 FK 적용 수정 포인트가 하나가 되므로, 갱신 이상 여지가 사라짐 규칙 5: 가짜 중복과 진짜 중복 구별하기 실제 서비스에서 A 데이터 값을 수정하면, B 데이터 값도 같이 수정되어야 하는가? e.g. id 1 게시물의 작성자를 수정하면, id 2 게시물의 작성자도 수정해야 하나? 같이 수정되어야 하면 진짜 중복, 아니라면 가짜 중복 진짜 중복인 경우 테이블 분리해야 함 규칙 6: 숨어있는 중복을 찾아라 숨어 있는 중복 겉으로는 중복이 아닌 것 같지만, 무언가 수정해야할 때 같이 수정해야 하는 경우 e.g. users & posts -> likes (중간 테이블) 좋아요를 제거할 때, 게시글의 좋아요 수도 같이 수정해야 함 주로 통계치(합계, 평균, 최대값 등)를 낼 때 발생 해결 방법: 테이블에서 통계치 칼럼을 없애야 함 e.g. 좋아요 수 없애기 좋아요 수를 알고 싶다면, 좋아요 테이블에서 필터링하여 개수 카운팅하자 DB 설계 반영 지침 최대한 정규화를 지켜서 DB 설계하자 정규화 적용하지 않은 케이스의 의견들 정규화를 지키면 테이블 개수가 많아져서 관리가 불편해요. → 데이터 중복으로 인해 발생하는 단점들이 훨씬 크고 관리하기가 더 어렵다. JOIN을 많이 하면 할수록 성능이 안 좋아져서 정규화를 안 했어요. → 실제로 JOIN을 많이 했을 때 성능이 안 좋아지는 경우도 존재한다. 하지만 이렇게 얘기하는 사람치고 실제로 성능 측정해본 사람이 아무도 없다. (추측만 했을 뿐) 즉, 이상 현상 방지에 가장 초점을 두자 데이터 중복으로 인해 실수로 데이터가 잘못 관리되는 문제가 더 큼 성능 개선은 느려지기 전까지 최대한 안 건드리는 게 Best! 필요성을 느낀다면 반드시 ‘측정’을 기반으로 해야 함 역정규화는 정말 구조로 인한 성능 문제가 클 때만 사용하라 ERD 표기 지침 DB 설계 시 ERD 그리는 게 필수가 아니어서, 보고 해석하는 방법 정도만 알아도 충분 홀로할 때는 편하고 빠른 방법으로 진행 (엑셀, A4지…) 협업할 때는 툴 사용 (ERD Clould, dbdiagram…) 1:1 관계인지 1:N 관계인지만 파악할 수 있으면 됨 (그 외 표기는 잘 안쓰임) 데이터 타입 실전 활용 지침 (MySQL 기준) 주요 사용 타입 정수를 저장해야 하는 경우 : INT 10억이 넘어가는 정수를 저장해야 될 수도 있는 경우 : BIGINT 실수를 저장하고 싶은 경우 : DECIMAL 문자를 저장해야 하는 경우 : VARCHAR(글자수) 6만이 넘어가는 문자를 저장해야 하는 경우 : LONGTEXT TimeZone을 고려하지 않고 날짜/시간 데이터만 저장하면 되는 경우 : DATETIME ex) 국내 서비스 TimeZone을 고려하면서 날짜/시간 데이터를 저장해야 하는 경우 : TIMESTAMP ex) 글로벌 서비스 True, False의 형태를 저장하고 싶은 경우 : TINYINT(1) 참고: 숫자는 숫자로 저장할 수도 있고 문자로 저장할 수도 있음 DB 관점에서는 “계산에서 쓰는 값인지 안 쓰는 값인지”를 기준으로 선택 휴대폰 번호는 문자로 저장 (숫자를 더해서 사용하지 않고 단순히 고유의 값으로 사용할 뿐) 주민등록번호도 마찬가지로 문자로 저장 현업에서 잘 사용하지 않는 데이터 타입 : CHAR, FLOAT, DOUBLE, TEXT 등 Reference 비전공자도 이해할 수 있는 DB 설계 입문/실전

Computer Science · 2025-01-15

데이터베이스 첫걸음

Computer Science · 2024-04-29

MySQL 주요 명령

MySQL 주요 관리명령 show status MySQL의 상태에 대한 여러 정보 확인 Threads_connected 커넥션의 상태 및 수 Uptime 서버 가동 후 경과 시간 Queries 실행한 SQL의 수 show databases 데이터베이스 목록 보기 show tables 테이블 목록 보기 show table status 통계정보 보기 show create table 테이블명\G 테이블 정의 보기 explain SQL문 해당 SQL문의 실행계획 취득 show index from 테이블명 인덱스를 표시 desc 테이블명 테이블 열 정보 보기 use 데이터베이스 이름 특정 데이터베이스 사용하기 quit 로그오프 MySQL 주요 SQL CREATE TABLE 테이블명 1 LIKE 테이블 2; 테이블 구조만 복제해 생성하기 INSERT INTO 테이블명 VALUES (..., ..., ...), (..., ..., ...), (..., ..., ...); 복수 행 입력 (Multi row insert) INSERT 문 처리를 1번으로 정리해서 기존 INSERT 문 복수 회 실행 보다 처리시간이 더 짧음 다른 DBMS도 구현되어 있는 경우가 있음 (PostgreSQL, SQLServer, DB2…)

Computer Science · 2024-04-13

관계형 데이터베이스 모델 개념

Relational Data Model & Relational Database Relation in Mathematics Set 서로 다른 elements를 가지는 collection elements의 순서는 중요하지 않음 Cartesian Product Set A & Set B의 element로 만들 수 있는 모든 pair의 조합 Relation Cartesian product의 부분 집합 (subset of Cartesian product) n-ary relation: n개의 Set에 대한 cartesian product의 부분집합 tuple들의 집합 (set of tuples) tuple은 하나의 pair를 의미 Relational Data Model Relation이 Relational Data Model에서는 Table로 표시 Relation = Table = Set of Tuples tuple(행) & attribute(열) Relation Schema Relation의 구조를 나타냄 (constraints 포함) e.g. Student(id, name, grade, major, phone_num, emer_phone_num) Degree of Relation Relation schema에서 attributes의 수 Relational Database Relational data model에 기반하여 구조화된 database (여러개의 relations로 구성) Relational Database Schema relation schemas set + integrity constraints set Constraints Implicit constraints Relational Data Model 자체가 가지는 제약 Explicit constraints (Schema-based Constraints) 주로 DDL을 통해 schema에 직접 명시 종류 Domain Constraints Attribute value는 해당 attribute가 가질 수 있는 value여야 함 Key Constraints 서로 다른 tuple은 같은 key 값을 가질 수 없음 Null value Constraints Attribute가 NOT NULL로 명시 됐다면, NULL을 값으로 가질 수 없음 Entity Integrity Constraints Primary key는 NULL을 가질 수 없음 Referential Integrity Constraints FK는 PK에 없는 value를 값으로 가질 수 없음

Computer Science · 2023-10-03

데이터베이스 기본 용어

Database 전자적으로 저장되고 사용되는 관련있는 데이터들의 조직화된 집합 Electronically, Related, Organized collection DBMS (Database Management System) 사용자에게 DB를 정의 및 관리하는 기능을 제공하는 소프트웨어 시스템 PostgreSQL, MySQL, Oracle Database, SQL Server Metadata(=Catalog, Data about Data) DB를 설명하는 데이터 (Descriptive) DBMS를 통해 관리됨 e.g. 데이터 유형, 구조, 제약 조건, 보안, 저장, 인덱스, 사용자 그룹 etc… Database System Database + DBMS + 연관된 applications 포괄적으로 database라고 부르기도 함 Data Model DB의 구조를 추상화해 설명하는 모형 (DB 구조: 데이터 유형, 데이터 관계, 제약 사항 etc…) DB 기본 Operations(CRUD)를 포함 종류 Conceptual Data Model (=high-level) 일반 사용자들이 쉽게 이해할 수 있게 DB를 구조화 (추상화 수준이 가장 높음) 비즈니스 요구사항 기술에 사용 Logical Data Model (=representational) 특정 DBMS에 종속되지 않는 수준에서 디테일하고 이해하기 쉽게 DB를 구조화 실제 DB 설계를 할 수 있는 수준 종류 (DBMS가 채택) relational data model (MySQL, Oracle DB, SQL Server) object data model object-relational data model (PostgreSQL) Physical Data Model (=low-level) 컴퓨터에 데이터가 어떻게 파일 형태로 저장되는지를 기술 data format, data orderings, access path(e.g. index…) Database Schema Data Model을 바탕으로 database의 구조를 기술한 것 Database State (=Snapshot =현재 instances의 집합) 특정 시점에 database에 있는 실제 데이터 Three-Schema Architecture User Application으로 부터 물리적인 database를 분리 각 레벨을 독립시켜 어느 레벨의 변화가 상위 레벨에 영향을 주지 않게 함 (안정적인 데이터베이스 운영) Database system을 구축하는 architecture 중 하나로 가장 많이 사용됨 대부분의 DBMS가 어느정도 따르나 three level을 완벽하게 나누지는 않음 Conceptual 변화는 External Level에 영향을 안 미치는 것이 상대적으로 힘들기 때문 각각의 Schema는 DB 구조를 표현만 함. 데이터가 실제 존재하는 곳은 internal level 분류 external schemas at external level (user view) 특정 유저들이 필요로 하는 데이터만 표현 (그 외 데이터는 숨김) logical data model을 통해 표현 conceptual schemas at conceptual level internal schema를 추상화해서 물리적인 저장 구조 내용은 숨기고 전체 DB 구조를 기술 entities, data types, relationships, user operations, constraints에 집중 logical data model을 통해 표현 internal schemas at internal level 물리적으로 데이터가 어떻게 저장되는지 physical data model을 통해 표현 data storage, data structure, access path 등 실체가 있는 내용 기술 Database Language 오늘날 DBMS는 DML, VDL, DDL이 따로 존재하기 보다는 통합된 언어로 존재 (e.g. SQL) 언어 종류 DDL (Data Definition Language) Conceptual Schema를 정의하기 위해 사용하는 언어 SDL (Storage Definition Language) Internal Schema를 정의하기 위해 사용하는 언어 최근엔 파라미터 설정으로 대체 (SDL은 거의 없음) VDL (View Definition Language) External Schema를 정의하기 위해 사용하는 언어 대부분의 DBMS에서 DDL이 VDL 역할까지 수행 DML (Data Manipulation Language) Database에 있는 실제 data를 활용하기 위한 언어 (CRUD)

Computer Science · 2023-10-01

데이터베이스

Computer Science · 2021-06-21

Lucian Log

Contact

DB

DB 설계 규칙 정리

데이터베이스 첫걸음

MySQL 주요 명령

관계형 데이터베이스 모델 개념

데이터베이스 기본 용어

데이터베이스