-
ERD(Entity Relationship Diagram)
: '데이터들의 관계를 나타낸 도표'이다!
API에 요청 - 데이터베이스와 교류 - CRUD .. 방대한 데이터베이스를 설계할 때 시각적으로 나타내고 표현할 줄 알아야 한다. 그러기 위해서는 ER Diagram을 잘 이해해야 한다.- Entity : 존재하고 있는 것 - Attribute : 특성, 속성 - Relationship : 관계 = ERD는 '데이터들의 관계를 나타낸 도표'이다!
- ERD의 규칙
1. A는 부모, B는 자식의 관계를 가진 ERD이다. A 테이블의 기본키를 B 테이블이 가지고 있다면 A=부모, B=자식 이다! 2. 실선 : 부모 테이블의 기본키를 자식 테이블이 가지고 있으며 이를 기본키로 사용하는 경우 3. 점선 : 부모 테이블의 기본키를 자식 테이블이 가지고 있지만 이를 기본키로 사용하지 않을 때
이제 바로 예전에 만들어둔 비디오 대여점 테이블이 있는데 이걸 예시로 한 번 만들어보자!!!
하나의 고객의 ID로는 빌리지않거나, 여러 개의 비디오를 빌릴 수 있기 때문에 연결의 시작 부분은 - (1개) 끝은 0을 의미하는 동그라미와 n개를 의미하는 까마귀 손이 붙어있는 것이다! 이를 통해 CUSTOMER와 RENTAL의 관계를 나타낼 수 있다. (One-to-Many Relationship)
OPERATOR은 아직까지는 RENTAL과의 직접적인 관계가 없어 독립적으로 표현됐다.
하지만 이 ERD를 작성하다보니 OPERATOR에서 RENTAL의 대여기록 등을 관리하려면 어떻게 할 수 있나? 하는 의문이 들었다.
단순하게 비디오 기록 정도만 관리를 한다면 일반적인 CRUD 작업을 통해 데이터를 가져오고 변경해서 비디오 관리를 할 수 있는데
1. 비디오 생성(Create): 새로운 비디오 정보를 데이터베이스에 추가한다
2. 비디오 조회(Read): 데이터베이스에서 비디오 정보를 검색하고 조회한다
3. 비디오 업데이트(Update): 기존 비디오 정보를 수정하거나 업데이트한다
4. 비디오 삭제(Delete): 데이터베이스에서 비디오 정보를 삭제한다예를 들어서, 어떤 고객이 어떤 비디오를 빌렸고 언제 반납했는가? 같은 복잡한 관계가 있다면? 이때는 어떻게 해야할까? 이런 경우에는 RENTAL 테이블에서 COUSTOMER_ID와 OPERATOD_ID 뿐만 아니라 VIDEO_ID도 사용해야 한다!
이때 RENTAL_ID, CUSTOMER_ID를 조합해서 복합 기본키로 만들어 각 행을 고유하게 식별할 수 있도록 만들어야 한다.
여기에서 항상 하나의 테이블에 어떻게 기본키가 여러 개 존재할 수 있지? 라는 의문이 있었는데
"테이블은 오직 하나의 PK를 가질 수 있다"라는 것은 정확한 정의가 맞다! 근데 여기에서 포인트는 PK를 오직 하나의 컬럼으로만 설정할 수 있다는 것으로 잘못 해석해서는 안 된다는 것이다!!! 🫨🫨🫨'RENTAL_ID', 'CUSTOMER_ID'은 두 칼럼이 각각이 유니크하게 중복되면 안 되는 것이 아니라, 둘을 합쳐서 봤을때 중복이 아니라면 무결성의 원칙이 지켜진다는 것이다. (예를 들어서 '[10번 비디오, 김철수], [10번 비디오, 김영희] 는 중복된 것이 아님)
즉, 정확히는 복합키를 만드는 것이지 기본키가 복수라는 것은 잘못된 표현이라는 것이다. (기본키를 구성하는 칼럼은 복수일 수 있지만, 기본키가 복수일 수는 없다.)
<기존 테이블에서 추가될 내용>
1. RENTAL 테이블:
- 필드: **Rental_ID, Customer_ID, Operator_ID, Video_ID**, rental_date, return_date
2. VIDEO 테이블:
- 필드: **Video_ID**, title, Description
1. RENTAL 테이블은 OPERATER, CUSTOMER, VIDEO 각각의 자식이다.
2. RENTAL 테이블은 기본키로 RENTAL_NO을 가지고 있고 복합키로 (CUSTOMER_ID와 RENTAL_NO)를 가지고 있다.
외래키는 CUSTOMER_ID, OPERATOR_ID, VIDEO_ID가 있다.
3. CUSTOER_ID는 복합PK로 사용하기 때문에 실선으로 연결을 한다.
4. OPERATOR_ID, VIDEO_ID는 FK만 있기 때문에 점선으로 연결을 한다.
5. CUSTOMER_ID와 VIDEO_ID는 null을 허용하기 때문에 o을 붙여준다.
6. OPERATOR_ID는 RENTAL테이블에서 수정, 추가 등의 작업을 할 때 OPERATOR_ID의 운영자 아이디가 맞는 지
확인하고 맞을 경우에만 데이터를 손댈 수 있게 보안의 용도로 참조를 한 것이다.
7. OPERATOR는 One-to-One Relationship이고 CUSTOMER, VIDEO는 One-to-Many Relationship이다.
- Customer가 대여를 할 수도 있고 안할 수도 있음.
- VIDEO를 할 수도 있고 안할 수도 있음.여기까지가 내가 이해한 ERD 설계하는 방법이다! 아직 예시로 만들어낸 테이블을 토대로 설계를 해본게다지만 앞으로는 프로젝트를 구상할 때 꼭 ERD를 제일 먼저 설계해야하는 이유를 어느정도는 알 것 같다.
- 데이터 중복 최소화: 각 테이블은 고유한 기본키(PK)를 가지고 있고 데이터 중복이 최소화된다. - 데이터 무결성 유지: 외래키(FK) 제약을 통해 데이터 무결성이 유지된다. 즉, 유효하지 않은 값을 가지는 외래키가 사용되는 것을 방지한다. - 관리 용이성: 테이블 간의 관계가 명확하게 정의되어 있으므로 데이터베이스의 관리와 유지보수가 용이해진다. - 성능 향상: 적절한 인덱스 및 관계 정의를 통해 쿼리 성능이 향상되고, 데이터베이스의 성능이 최적화된다. - 보안 강화: 접근 권한을 관리하고 데이터를 보호하기 위해 데이터베이스 사용자의 권한을 관리할 수 있다.
