데이터 관계와 모델링, ERD작성

데이터 모델링

비즈니스를  추상화, 단순화, 명확화 표기하기 위해서 분석하고 데이터화 시키는 것, 정보시스템을 구축하는 과정에서 계획.분석.설계 단계에서 업무를 분석하고 설계할 때 또한, 이후 구축.운영 단계에서 변경과 관리할 때 사용됨. 

데이터 모델링표기기법

• 1. 피터첸 : 엔터티를 사각형, 엔터티간 관계를 마름모, 엔터티의 속성을 타원형 으로 표현.
• 2. I/E Crow's Foot (까마귀발) : 

 

데이터 모델링 개념

• 엔터티 -객체, 실체, 사람, 장소, 물건, 사건, 개념 등의 명사에 해당.예를 들어,＂학생” 이라는 엔터티는 학번, 이름, 학점, 등록일, 생일, 주소, 전화번호 등의 속성으로 특징지을 수 있음
• 속성 -  업무에서 필요로 하는 인스턴스에서 관리하고자 하는 의미상 더이상 분리되지 않는 최소의 데이터 단위
• 도메인 - 속성이 갖을 수 있는 값
• 관계 - 엔터티의 인스턴스 사이의 논리적인 연관성으로서 존재의 형태로서나 행위로서 서로에게 연관성이 부여된 상태
  • 관계명 : 엔터티가 관계에 참여하는 형태. 두개의 관계가 있음. 관계시작점, 관계끝점
  • 관계차수 : 1: 1(ONE TO ONE), 1:M(ONE TO MANY), M:M(MANY TO MANY)
  • 관계선택사양 : 필수관계(1), 선택관계(0)

 

• One (|-----):
  • This indicates a mandatory one relationship. For every record in the entity on the left, there must be exactly one corresponding record in the entity on the right.
• Many (|-----<):
  • This represents a mandatory many relationship. Each record in the entity on the left is related to one or more records in the entity on the right.
• Only One (|-----||):
  • This is a mandatory and exclusive relationship. Each record on the left is associated with exactly one and only one record on the right. This typically represents a strict one-to-one relationship.
• One or Many (|-----<|):
  • This represents a mandatory one or many relationship. Every record in the entity on the left must be linked to at least one record in the entity on the right, but it could be linked to many.
• Zero or One (|-----o|):
  • This indicates an optional one relationship. Each record in the entity on the left can either be related to zero or one record in the entity on the right.
• Zero or Many (|-----o<):
  • This represents an optional many relationship. Each record in the entity on the left can be related to zero or many records in the entity on the right.
• Zero or One or Many (|-----o<|):
  • This represents an optional one or many relationship. Each record in the entity on the left can be related to zero, one, or many records in the entity on the right.

 

 

 

 

 

 

데이터 모델링 툴

• 사용툴 : erdCloud
  • 사용법 : https://inpa.tistory.com/entry/ERD-CLOUD-%E2%98%81%EF%B8%8F-ERD-%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8%EC%9D%84-%EC%98%A8%EB%9D%BC%EC%9D%B8%EC%97%90%EC%84%9C-%EA%B7%B8%EB%A0%A4%EB%B3%B4%EC%9E%90
  • erdcloud : https://www.erdcloud.com/
• 프로젝트 시작전에 데이터 모델링을 진행하여 엔티티, 속성, 관계들을 설계해두어야 DB와 함수들을 시행착오가 없도록 빠르게 구현할 수 있음.
• 엔티티를 생성하고 그 내부에 상단에 primarykey를 입력, 하단에 일반 key를 입력함.

 

 

• 키
  • PK
    • two primary keys typically refers to the concept of a composite primary key. A composite primary key is a primary key that consists of two or more columns in a table. This means that the combination of these columns uniquely identifies each row in the table.
  • FK

 

 

데이터 모델링 예시

• 논리적데이터 모델링 : key, 속성, 관계 등을 정확하게 표현 
  • 1. 우선적으로 엔터티들을 쭉 define 하는 것이 가장 먼저 할일
  • 2. 엔터티 간의 관계를 FK를 통해서 설정해준다. 서로 식별관계를 맺을지 비식별 관계를 맺을지 결정 a)한 엔터티의 PK가 타 엔터티의 FK가 되거나 PK가 되는 방식으로 관계를 설정.
• 물리적데이터 모델링 : 실제로 데이터베이스에 이식할 수 있을정도로 성능, 저장 등 물리적 성격을 결정 
  • 3. 이름표의 역할을 하던 논리적 라벨링을 물리적으로 실질적인 테이블명을 define해준다.
  • 4. 각 엔터티의 도메인과 데이터 타입을 결정해준다.
  • 5. 포워드 엔지니어링을 통해서 sql문으로 변환시켜서 
• 엔티티 
  • 1. 회원 : 회원아이디(PK), 이름, 연락처
  • 2. 상품 : 상품아이디(PK), 상품내용, 상품가격, 상품명
  • 3. 주문 : 주문아이디(PK),  주문일, 주문수량, 주문가격, 
• 관계
  • 주문이 회원아이디라는 정보를 담고 있기에, 주문은 회원아이디를 FK로 갖는다. 마찬가지로 주문은 상품의 아이디도 담고있기에 상품아이디를 FK로 갖는다.
  • 식별관계 : 관계를 맺는 엔터티 사이에 PK를 공유한다
  • 비식별관계 :  관계를 맺는 엔티티 사이에 키를 공유한다.

데이터 모델링 원칙

• 테이블 간의 관계는 primary key를 통해서 이루어지고, 다른 테이블의 특정 칼럼에 대한 조회는 primarykey를 통한 join문을 사용하는 것이 좋다. 
  
  • 단, PK ID는 내부적으로만 사용하는 것이며, 외부적으로 사용이 필요할때는 별도로 ID 칼럼을 하나 더 만드는 것이 좋다. ID에는 거래 건수와 같은 중요정보를 담고 있기 때문임.
• Normalization: Using primary keys and foreign keys to relate tables adheres to database normalization principles. Normalization reduces redundancy and dependency by organizing fields and table relationships. This ensures data integrity and consistency across the database.
  • Key Points of Normalization

1. Atomicity: Each table column should hold atomic (indivisible) values. This ensures that each piece of data is stored in its smallest possible unit.
2. Uniqueness: Each table should have a primary key that uniquely identifies each row. This primary key is typically a single column, but it can be a composite key (multiple columns) if necessary.
3. Relationships via Keys: Relationships between tables should be established using foreign keys that reference primary keys. This ensures referential integrity.
4. Avoid Redundancy: Each piece of information should be stored in only one place to avoid redundancy. This minimizes the risk of data anomalies and inconsistencies.