데이터 모델링(ER다이어그램 )

하루입니다.

 

 

---

 

 

오늘 공부할 것은 데이터 모델링과 ER다이어그램. 

 

데이터 모델링

• 정보화 시스템을 구축할 때 어떤 데이터가 존재하고, 업무에 필요한 정보는 무엇인지 분석하는 작업.
• 분석한 정보의 내용을 ER다이어그램으로 표현했음.

 

 

이클립스에서 ER다이어그램 만들기

• 자바 프로젝트 생성 - new 누르고 other로 - ERMaster로 - 부모 프로젝트 선택 - DB 선택 (우리는 오라클) - finish

 

 

논리모델과 물리모델의 차이

 

• 논리모델 : 데이터 모델을 상세화하여 정보의 구조와 규칙을 표현하는 것? 
• 물리모델 : 특정 DB에 맞춘 것

음 ... 그러니까 하나의 논리모델으로 여러 DBMS의 물리모델이 생성될 수 있다고 이해함. 예를 들어 논리모델에서 숫자 데이터 형식이 나온다면 오라클에서는 number, mySQL에서는 int 이런 식으로 표현하는 것처럼. 따라서 물리모델은 해당 DB의 자료형, 문법적 요소들이 그대로 적용되어 있으며, 만약 이를 다른 물리모델(서버)로 들고 가면 사용이 불가능함.

 

 

데이터 모델링의 주요 내용

• 엔티티(Entity) 

 약간 데이터베이스의 테이블 느낌인데 그렇다고 테이블은 아님. 그러니까 특정DB에 종속된 개념이 아니라는 거임. 엔티티가 있으면 오라클db mySQL에서 자료형 이름 크기 식별자 등등이 다 다르다. 테이블은 특정DB에 종속된 개념이라면, 엔티티는 테이블에 해당되지만 좀 더 추상화되어있다.

 

 - 기본 엔티티 : 부서정보, 고객등급정보 등 잘 변하지 않는 값. 시스템 구동 전 이미 값 들어가 있다.

 - 중심 엔티티 : 기본 엔티티로부터 발생하는 엔티티. 업무의 중심역할을 수행한다. 예를 들면 고객정보, 상품정보.

 - 행위 엔티티 :  두 개 이상의 부모 엔티티로부터 발생한다. 고객이 리뷰하는 '행위', 상품 장바구니를 이용하는 '행위' 등을 통해 내용이 자주 변경된다.

 

• 속성

 엔티티에서 관리하고자 하는 최소 단위의 데이터. DB의 컬럼과 유사한 개념이다.

 

•  식별자

 각각의 엔티티를 구분할 수 있는 값. 

 

• 관계 

 두 엔티티 사이의 논리적인 관계. 업무의 흐름을 나타낸다. 

 고객은 상품에 대한 리뷰를 작성할 수 있다. 고객은 쿠폰을 보유할 수 있다. 고객은 리뷰에 댓글을 달 수 있다 등.

• 관계의 카디낼리티(Cardinality)

두 엔티티간의 관계에서 참여자의 수를 표현하는 것

1대1, 1대다, 다대다 관계 있다.

 

 

 

ER 다이어그램 만들기

 먼저 한 건 테이블 글로 정의하기. 예를 들어 고객은 고객번호, 아이디, 비밀번호, 등급 등이 있는데 등급은 고객등급을 참조한다. 댓글은 리뷰에 고객이 달 수 있는 것이다. 어떤 리뷰에 대한 댓글인지, 이 댓글을 쓴 사람은 누구인지 알아야 하기에 리뷰와 고객을 참조한다. 이런 식으로. 그 결과가 밑의 그림이다.

 

 

이 그림을 토대로 이클립스에서 ER다이어그램을 만들고 사용함. 

ER다이어그램 사용법

 1. 테이블 누르고 모눈종이 누르면 테이블 생성된다.

 2. 추가 누르고 물리명(DB에 들어갈 값?, 실제 테이블 명, 영어로 적어야 함), 논리명(테이블에 종속되지 않은 이름, 한글으로 적어도 됨), 형식(영어로 알파벳 치면 그 알파벳이 맨 앞인 형식들으로 이동한다), 길이가 필요하다면 길이, 설명, 기본값(sysdate, 'Y' 등)을 넣는다. 제약조건도 선택한다.

 3. 관계를 설정하고 싶은 경우는 관계 중 하나를 누르고 부모 테이블 - 자식 테이블 순으로 누르면 된다.

 4. n대 n 관계는 바로 연결이 불가하고 브릿지테이블(?)을 생성해야 한다. 물론 알아서 해 준다. 밑 그림의 리뷰 테이블, 댓글 테이블과 같은 경우. 

 5. 표시 - 뷰 모드 - 물리모델/논리모델 선택 가능. 

 6. 데이터베이스/파일에서 가져오기, 엑셀/DDL/자바 등으로 내보내기 가능

 

 

 

 

자 이 친구가 바로 ... ER다이어그램입니다. 

 

간략한 설명 (안 간략해요)

• 빨간 건 기본키, 초록색은 외래키
• users와 user_grade를 볼 때 user_grade쪽은 작대기 하나, user쪽은 화살표닭발모양이 있다. 이건 user_grade(등급)을 가진 고객은 여러명이고, 고객이 가진 등급은 하나라는 뜻이다. USER(자식)의 GRADE는 USER_GRADE(부모)의 GRADE 기본키를 참조했다. 
• 마찬가지로 ORDER_ITEMS와 PRODUCTS/ORDERS를 보자. ORDER_ITEMS의 ORDER_NO는 ORDERS의 ORDER_NO를, ORDERS의 PRODUCT_NO는 PRODUCTS의 PRODUCT_NO를 참조했다. 주문상품의 제품번호는 상품의 주문번호에 속하며, 주문상품의 주문번호는 주문의 주문번호에 속한다. 음 그러니까. 하나의 상품번호는 여러 주문된 상품들에서 사용 가능하겠지. A가 A제품, B가 A제품 이렇게 주문할 수 있으니까. 반대로 아무리 주문된 상품이 많아도 제품번호는 하나 뿐이다.
• USERS, PRODUCTS, REVIEWS를 보자. USERS와 PRODUCTS는 N:N 관계이다. 애석하게도 ER은 N대N에서 사이에 테이블을 꼭 넣어야 하고. REVIEW를 생성했다. 사용자는 여러 리뷰를 달 수 있고, 제품에는 여러 리뷰가 달린다.
• 사용된 쿠폰은 주문 번호를 참조한다. 사용된 쿠폰의 주문 번호는 주문의 주문번호를 중 하나이다. 만약 한 유저의 어느 쿠폰이 사용되엇다면 그 쿠폰을 사용하게 한 주문(번호)가 있겠지.  하나의 주문번호에는 여러 사용된 쿠폰이 참조되어 있다.
• ORDERS 옆의 검은 점은 0대 1이라고 해야 하나. USED_COUPONS의 ORDER_NO는 ORDERS의 ORDER_NO를 참조한다. 그런데 ORDERS의 ORDER_NO는 NOT NULL인데 USED_COUPONS의 ORDER_NO는 NULL이 허용되네. 이게 무슨 일이지?
• 이런 경우 검은 점이 나타난다. 포인트의 주문정보는 꼭 있는 정보가 아니다. 예를 들어 이벤트, 리뷰 적립금 등으로도 포인트를 받을 수 있기에 포인트의 주문정보는 NN이 아니다. 이렇듯 어느 상황에서 포인트가 늘어나는지 이런 것 잘 체크해야 한다. (우리가 미래 프로젝트에서 겪을 시행착오 1)

 

(이건 나중에 SQL에서 사용한 거)

DROP TABLE TB_CART CASCADE CONSTRAINTS;

이거 사용하면 부모고 자식이고 싹 지워진다.

원래는 자식 먼저 지우고 부모를 지워야 하나, 순서 상관없이 지워준다.

 

 

---

 

 

 

잘못된 정보에 대한 지적은 언제나 환영입니다. 

 

복습 끝!