4.3. ERD의 구성요소
4.4. 엔티티 정의
4.5. 속성 정의
4.6. 식별자 지정
4.7. 엔티티간의 연결
4.8. Cardinality
4.9. Optionality
4.10. ERD 완성
4.11. Entity Relationship Diagram Helper
개념적 데이터 모델링 또는 ERD 에서는 엔티티(Entity)라고 부름 후에 table로 전환
글 이라는 엔티티는 실제 데이터가 아님.
구체적인 데이터는 제목, 생성일, 본문에 담겨있고 글 이라는 엔티티에 담겨있는 것
후에 표의 column이 됨
만약 저자의 이름만 우리 시스템에 필요하다면 저자의 이름은 속성이 되면 된다.
하지만 저자의 이름 뿐만 아니라 저자의 자기소개 가이드와 같은 정보가 필요하다면 저자는 이름 소개 가이드와 같은 속성을 포함하는 엔티티가 되는 것.
개념적 데이터 모델링은 개념을 집중하고 데이터베이스 페러다임으로부터 거리를 두고있기 때문에 용어가 실제 데이터베이스 제품들과는 다르다.
Entity => Table이 됨.
Attribute => Column이 됨.
Relation => PK(Primary key), FK(Foreign key)가 될 것임.
다이어그램상 표현되진 않지만 Tuple => Row
애플리케이션이 하나의 건물이라면 UI는 옥상 DB는 지하. 서로는 인과관계로 이루어져있다.
기획자가 구현자가 다르다면 데이터모델링까지는 최소한 함께하는것이 이상적이다.
- 기획서에서 Entity를 찾는 것
- 쓰기(글을 작성하는 입력)화면을 보면 우리가 표로 만들기에 좋은 엔티티가 대체로 드러남
- ERD(E-R Diagram)으로 옮겨보는 것
- 엔티티를 추출(저자, 글, 댓글) 후 적용
- 원으로 ERD의 속성을 표시해주고 (제목, 본문, 작성일, 가입일 ,이름, 자기소개)해당 엔티티와 연결시켜준다.
식별자(엔티티 속성중 대표자)는 그 대상을 제외한 누구도 같은 값을 가지고있으면 안됨. 이렇게 지정한 식별자는 훗날 Primary key(기본키)가 될 것임
인조키 : 중복되지 않는 값이지만 구별하기 위해 인위적으로 만들어낸 키.
후보키 : 식별자가 될 수 있는 후보.
기본키 : 후보키 중에서 우리가 선택한 식별자
대체키 : 기본키를 제외한 다른 키
중복키 : composite key라고 하며 기본키중 대체키를 제외한 나머지를 가리킨다.
- 식별자가 될 수 있는 요소가 없을경우 인조키를 생성하고 밑줄을 쳐서 표시해둔다.
- ERD에서 relationship을 표현할 땐 마름모꼴 도형으로 표현해준다.
relationship에서 꼭 따져봐야하는 Cardinality, Optionality
Cardinality : 1:1, 1:n, n:m같은 관계성을 표시
Optionality : 있을수도 없을수도 있다.
카디널리티의 속성도 반영되며, 상대 엔티티에 인스턴스가 반드시 존재해야 하는지(Mandatory)와
존재하지 않아도 되는지(Optional)를 표시한다.
