ERD 디자이너

데이터베이스 서버 없이 관계형 스키마를 설계하세요: 테이블을 추가하고 타입·키·기본값이 있는 열을 준 뒤 관계로 연결하세요. 개체 관계 다이어그램은 입력에 따라 다시 그려지며 같은 모델이 MySQL, PostgreSQL, SQL Server, SQLite, Oracle용 CREATE TABLE DDL로, Mermaid erDiagram 소스로, 또는 여기서 다시 가져오거나 마이그레이션 생성기에서 열 수 있는 휴대 가능한 스키마 JSON으로 내보내집니다. 모든 것이 로컬에서 돕니다.
ERD란? ERD는 개체 관계 다이어그램의 약자로, 완성된 데이터베이스의 기록이 아니라 데이터베이스의 설계 도면입니다. 건축 청사진에 비유하면 이해하기 쉽습니다: 실행 중인 데이터베이스가 건물이고 ERD가 청사진이며, 아무도 콘크리트를 먼저 붓고 나중에 재지 않습니다. 이 페이지는 그 청사진을 그리는 제도판입니다 — 여기서 모델을 만들면 DDL, Mermaid 소스, 스키마 JSON이 모두 그 하나의 모델에서 출력되므로, 그림이 생성된 SQL과 어긋날 수 없습니다.
세 수준의 같은 다이어그램. 개념 ERD는 중요한 것과 그 관계만을 비프로그래머도 검증할 수 있는 말로 이름 짓습니다. 논리 ERD는 각 것을 식별하는 키를 더하고 다대다 연결을 풀면서도 어떤 엔진의 방언도 쓰지 않습니다. 물리 ERD는 하나의 제품이 요구하는 것을 채웁니다 — 타입 폭, 기본값, null 가능성, 고유 제약, 삭제 규칙 — 이것이 MySQL, PostgreSQL, SQL Server, SQLite, Oracle을 고를 때 여기서 내보내는 수준입니다.
상자가 어디서 오는가. 시스템 설명을 읽고 명사에 밑줄을 긋세요: 고객, 송장, 제품, 배송. 그것이 테이블입니다. 명사에 붙은 사실과 성질 — 송장 날짜, 단가, 이메일 주소 — 이 열입니다. 두 명사를 묶는 동사("주문은 고객이.place한다")가 관계이며 부모 행의 식별 키를 외래 키로 자식 행에 복사해 저장합니다.
연결이 다대다일 때. 하나의 레시피는 많은 재료를 쓰고 하나의 재료는 많은 레시피에 나타나므로 어느 테이블도 상대의 키를 반복 없이 가질 수 없습니다. 답은 그 둘을 짝 짓는 것이 유일한 임무인 세 번째 개체입니다 — 접합(연관) 테이블로 각 쪽의 외래 키 하나를 실으며 흔히 그 키 쌍을 자기 기본 키로 씁니다. 대부분 그런 짝짓기 테이블인 모델은 완전히 정상입니다. 화이트보드의 다대다 선은 실제 스키마에서 항상 상자가 되어야 합니다.
DDL이 존재하기 전에 왜 굳이? 도면의 잘못된 선은 지우는 데 1분이지만 출시 후 발견된 같은 실수는 실 데이터 위의 마이그레이션을 요구합니다. 다이어그램은 비개발자가 검토할 수 있는 유일한 산출물이며 관계 결함 — 반대로 된 카디널리티, 빠진 고유 키, 부모 없이 남을 수 있는 자식 행 — 은 여기서는 명백히 나쁜 선으로 드러나지만 400줄 DDL 파일에서는 제약 사이에 숨습니다.
순방향이냐 역방향이냐? 이 디자이너는 순방향입니다: 모델 먼저, DDL 아웃. 형제 페이지 SQL → ERD는 반대로 갑니다 — 기존 CREATE TABLE 문을 붙여넣으면 다이어그램을 다시 지어줍니다. 데이터베이스가 이미 존재한다면 그쪽이 더 빠른 길입니다.
1 — 테이블
편집 테이블 이름 열 관계 Actions
2 — 열
열 타입 PK AI NN UQ 기본값 Actions
PK = 기본 키, AI = 자동 증가 / identity, NN = NOT NULL
3 — 관계 (외래 키)
자식 테이블 자식 열 Actions 부모 테이블 부모 열 삭제 시 Actions
외래 키는 DDL에서 CONSTRAINT ... FOREIGN KEY 줄이 됩니다.
4 — 내보내기
Mermaid erDiagram 소스
JSON 모델은 데이터베이스 도구 family의 교환 형식입니다. 마이그레이션 생성기에 before/after 스키마로 붙여넣거나 여기 다시 가져와 나중에 편집을 계속하세요.