ERD, 어렵지 않게 만들기

안녕하세요 〰️ 

이 번 포스팅에서는 여러모로 쓸모있는!

ERD를 알아보고 표기법에 대해 이야기해볼 예정입니다.

 

****************  INDEX  *****************

 

💼 ERD❓ 

⏳ ERD, 언제 사용할까❓

🤖 ERD Notation

 

******************************************** 

 

💼 ERD

ERD는 Entity Relationship Diagram의 약자입니다.

ERD는 데이터베이스 구조를 한 눈에 알아보기 위해 그려놓는 다이어그램입니다.

ER Diagram이라고도 부릅니다 〰️ 

 

ERD는 단어에서 의미하는 그대로 ' Entity 개체  '와 'Relationship 관계 '를 중점적으로 표시하는 다이어그램입니다.

데이터베이스를 설계할 때, 테이블과 그 속에 정의된 여러 관계를 다이어그램으로 나타내니, 보기 굉장히 편하겠죠?

 

아래는 MySQL Workbench에서 예시로 보여주는 완성된 다이어그램입니다. 

대충보면 어떤 건지 아시겠나요 ?

모르셔도 됩니다 〰️ 지금부터 같이 알아보도록해요 !

 

example ER Diagram

 

 

 

⏳ ERD, 언제 사용할까?

개체와 관계를 나타내는 다이어그램은 언제 사용될까요?

왜 만드는지, 언제 만드는지 알아봐야 그릴 때 의문이 안생기겠죠?

 

✔️ design

데이터베이스를 설계할 때, 다양한 테이블들과 해당 테이블들간의 관계들을 결정합니다.

이 때, 테이블을 하나하나 그리면서 설계하기에는 시간 효율이 굉장히 떨어지죠.

예를들어 A 테이블을 그렸는데 수정해야 한다면? 혹은, 데이터베이스 전체 설계를 마친 후 수정이 필요하다면?

 

우리가 생각하는대로 바로 적용하기에는 큰 무리가 있습니다.

그렇기 때문에 ERD를 사용하여 전체 데이터 베이스의 구조를 먼저 잡고 진행할 수 있습니다.

 

혹은, 데이터베이스를 사용하다가 수정이 필요할 때가 생길 수 있겠죠? 이 때는 데이터가 사라질 수 있으니, 굉장히 신중하게 사용해야 합니다.사용 중 수정을 할 때에도, ERD를 먼저 보고 적용해보면 어느 부분을 어떻게 수정해야 할지 비교적 쉽고 빠르게 반영할 수 있습니다.

 

✔️ debugging 

데이터베이스를 사용하다보면 굉장히 복잡한 쿼리문을 작성해야 할 때가 생깁니다.

 

가령, 두 세번 이상의 JOIN이나 subquery를 사용해야 한다고 생각해보세요.

자신의 머리속에 있는 테이블들을 구조화하면서 쿼리문을 짤 수 있을까요? 

홈즈라면 가능하겠지만,,,,일단 저는 못합니다 🤣

 

이러한 상황에도 ERD는 큰 도움을 줍니다.

구조화된 다이어그램에서 각 Entity의 속성이 바로 보이기 때문에 굉장히 간편하게 사용할 수 있게되죠.

 

✔️ creation and patching 

ERD를 사용하다보면 굉장히 편하다는 것을 느낄 수 있는데요.

그래서 ERD를 사용하여 데이터베이스를 생성하고 수정하기도 합니다.

 

다양한 툴이 있을텐데, 몇가지만 이야기 해보면 MySQL Workbench나 ERWin 프로그램이나 인터넷에서 Aquerytool을 바로 사용할 수도 있습니다.

더 다양한 툴들이 있으니, 필요하다면 찾아보세요 〰️ 

 

✔️ Aid in requirements gathering

데이터 수집을 할 때, 테이터의 요구사항이나 흐름 등을 도와줄 수 있습니다.

 

데이터를 수집할 때, 반드시 먼저 저장되어야하는 데이터들이 생길 수 있는데요.

데이터의 흐름에 대한 도움을 받을 수 있습니다.

혹은, 데이터의 다양한 특징을 바로 볼 수 있기 때문에 그에 대한 요구사항에 맞춰 개발을 할 수 있겠죠.

 

 

 

위와 같이 4가지의 상황을 들어보았습니다.

자, 이제는 직접 보고 만들어보면서 ERD를 완전히 파악하는 시간을 가져보겠습니다 〰️ 

 

 

 

 

🤖 ERD Notation 

이제부터는 ERD 표기법에 대해 알아보도록 하겠습니다.

사실, 표기법이 하나로 지정되어 있지는 않지만 가장 많이 사용되는 IE 표기법을 알아볼 예정입니다.

 

IE 표기법은 Information Engineering 의 약자입니다. 

diagram 특성상 crow-feet 표기법이라고도 합니다. 그 이유는 금방 아시게 될 거에요 〰️ 

정보공학 표기 방식으로 일반적으로 모델링을 할 때 가장 많이 사용하는 유형입니다.

 

자, 이제부터 표기법을 알아볼 예정입니다. 

 

✔️ Entity

Entity는 정의 가능한 사물 또는 개념을 의미합니다. 사람이나, 객체 혹은 개념이나 이벤트 등을 Entity로 둘 수 있습니다.

객체에는 가구나 자동차를 예시로 들 수 있을 것 같아요.

개념은 프로필이나 자기소개서 등이 있을 수 있겠고, 이벤트에는 거래 등이 있을 수 있습니다.

 

데이터베이스를 설계할 때, '테이블'이 Entity로 정의될 수 있습니다.Entity는 아래의 그림과 같이 표현됩니다.

 

 

✔️ Entity Attribute

각각의 Entity에는 속성을 포함하고 있습니다.

Attribute는 개체가 갖고있는 속성이죠.

 

예를 들어 사람이라면 나이, 이름, 생년월일 등을 포함할 수 있겠죠?

 

여기서, 하나 더 필요한 건 데이터의 타입입니다.

데이터 타입을 같이 명시해줘야 하며 이 때, RDBMS가 지원하는 타입에 맞게 적어주세요!

 

위의 그림은 Entity에 속성을 포함한 그림입니다.

직관적으로 느낌이 오시죠❓ 

 

 

 

✔️ Constraint - PK & NN

이번엔 제약조건을 표시해보도록 하겠습니다.
관계에 대한 자세한 사항은 이 게시글을 참고하시면 됩니다.

 

+ 관계에 대한 설명을 조금 더 추가해볼게요.

서점을 예시로 들어볼까요? 서점에서 새로운 책들을 구비해두려고 합니다.

그럼 서점에서는 추가할 책들을 주문하겠죠. 

이 데이터를 저장한다고 생각을 해보세요. 일단 눈에 띄는 개체라고 정의할 수 있는 건 서점과 책이죠.

서점에서 책을 살 때 15000원짜리 A책을 10권 구매하고 20000만원짜리 B 책을 15권 구매한다고 했을 때,

이 데이터들은 어느 개체에 포함될 수 있을까요?

서점, 책 둘 다 포함하기 어려워요. 물론 할 수는 있겠지만 비효율적이구요. (정규화를 알아보세요)

그래서 주문데이터를 저장하는 주문 개체를 하나 만듭니다.

그럼 이 때 개체들 사이의 관계를 집중적으로 보면

한 서점에서는 여러개의 주문을 넣을 수 있고, 하나의 주문에는 여러 가지의 책을 포함할 수 있어요.

개체들 사이의 관계를 말하는 것이 바로 이번 섹션에서 다룰 부분이에요.

더 자세한 내용을 아래에 추가해두겠습니다.

 

 

 

 

먼저 PKprimary key부터 표시해볼까요❓ 

 

🔑 PK primary key 

PK notation

 

대부분 위의 그림과 같이 열쇠의 그림으로 표시해줍니다.

이 번엔 NOT NULL을 표시해보도록 합시다 〰️ 

 

❌ NOT NULL

 

NN notation

 

Null 을 허용한다면, N을 적지 않으셔도 됩니다.

 

이번엔 가장 까다롭지만, 가장 중요한! Foreign Key에 대해 알아보도록 하겠습니다.

 

 

 

✔️ Constraint - FK

✈️ FK Foreign Key

Foreign key를 표시할 때에는 선을 사용하는데요. 

 

여기서 잠깐, ERD를 표시할 때에는 두가지를 표시한다고 했습니다.

바로 개체와 관계죠.

이 때 관계가 바로 FK입니다. 

 

일단, 관계를 어떻게 그려야 하는지 알아볼게요.

 

✍🏻 두 개체의 관계 - 선

 

 

먼저, 두 관계중 부모의 키를 PK로 받는지 안받는지에 따라서 선의 종류 (점 or 실) 가 다릅니다.

 

낯설지만 생각보다 간단한 개념인데요, 그림을 잘보시면 바로 이해하실 수 있어요.

Address 개체에서 address_id가 PK로 설정이 되어있는데 Store 개체가 address_id를 가지려고 합니다.

 

이 때 식별자 관계에서는 FK를 PK로 설정(🔑)을 했고,

비식별자 관계에서는 일반 속성(🔹)으로 가지고 온 것을 확인할 수 있습니다.

 

(FK를 PK로 사용할 수 있다는 점을 알고 있어야 조금 더 쉽게 이해할 수 있겠죠 ~)

참고로, FK를 PK로 지정할 때가 언제 있을까요?

하나의 예시로 자식 테이블에서 할아버지/할머니 테이블을 참조할 때가 있을 수 있어요.

물론, 상황에 따라 필요할 수도 있고 필요없을 수도 있습니다.

 

 

 

 

✍🏻 두 개체의 관계 - 선의 끝

Cardinality

Cardinality는 한 개체에서 발생할 수 있는 발생 횟수를 정의하며, 다른 개체에서 발생할 수 있는 발생 횟수와 연관됩니다.

1대1관계, 1대N관계, N대N 관계가 있죠.

 

 

 

✔️  One-to-One Cardinality

 

1:1 관계에서는 아래와 같이 표기합니다.

One-to-One Cardinality

 

 

 

✔️  One-to-Many Cardinality

 

1:N 관계에서는 아래와 같이 표기합니다.

여러개가 될 수 있는 개체에는 까마귀의 발과 같이 그려줍니다.이제, 왜 crow-feet라고도 불리는 지 아시겠죠 ❓

 

 

 

✔️  Many-to-Many Cardinality

N:M 관계에서는 아래와 같이 표기합니다.

 

 

Many-to-Many Cardinality

 

 

지금까지 Cardinality를 살펴보았는데요.

마지막으로 하나만 더 보고 마치겠습니다.

 

 

마지막으로, 필수참여 조건입니다 〰️ 

'|' 표시가 있는 곳은 반드시 있어야 하는 개체, 'O' 표시가 있다면 없어도 되는 개체입니다 !

 

 

inventory 개체가 없어도 store 개체는 있을 수 있고, store 개체가 없다면 inventory 개체도 있을 수 없습니다.

 

 

 

 

그럼, 이렇게 포스팅을 마치도록 하겠습니다 〰️ 

ERD 여러모로 필요한데 난해한 기호로 헷갈렸을 것 같아 포스팅해보았습니다 ❗️ 

 

 

 

 

참고 - https://www.visual-paradigm.com/guide/data-modeling/what-is-entity-relationship-diagram/