데이터 베이스 설계 요약
1. E/R모델링
엔티티 간의 관계 패턴에 대한 추론 및 발견
엔티티 ? 각 독립적인 개체 (독립적으로 구분할 수 있는 아이템)
엔티티를 잡았는데 어떠한 릴레이션쉽이 없다 -> 이러한 엔티티는 없다.
우리가 만드는 데이터 베이스에는 2개이상의 엔티티가 있고 풀 커넥트는 아닐수도 있다.
• Strong relationship
-> 1:1, 1:N, M:N
ex) 학생,과목,교수 (매우 강한 Strong한 엔티티)
• Multi-valued Attribues
• Architype/Instance
• Weak Entity : Strong 타입에 의존하는 엔티티도 존재
• Recursive relationship
총 7가지의 relationship 엔티티들을 잘 이용하여 설계 해보자.
Strong Relationship
• 1:1 관계
예) 개인: 면허증, 자동차: 자동차 등록증, 국가: 수도
• 1:N 관계
예) 부모: 자녀, 회사: 직원, 유튜버: 유튜브 동영상
• M:N 관계
예) 학생 : 과목, 배우: 영화, 상품: 주문, 프로젝트: 팀원
Multi-valed Attribues
예) 학생-전화번호, 영화-영화제목
Architype/Instance
예) 과목-개설된강의, 자동차모델-출시된자동차
Weak Entity
예) 환자 – 진료기록, 은행고객 – 계좌
Recursive Relationship
예)
- Employee 엔티티 안에서 상사-부하의 1:N 관계
- User 엔티티 안에서 친구라는 M:N 관계
- Part 엔티티 안에서 상위부품-하위부품 간의 M:N 관계
이렇게 관계가 명확해졌으면 테이블로 엔티티간의 관계를 표현할 때 설계할 수 있다.
ID-Dependent/NonID-Dependent Entity
• 식별관계: parent entity의 identifier를 자신의 identifier 를
구성하는데 사용
• 비식별관계: parent entity 의 identifier를 자신의 identifier를
구성하는데 사용하지 않음
• Multi-valued Attribues, Architype/Instance, Weak Entity: 식별관계
혹은 비식별관계로 구성할 수 있음
Association Pattern
• 1:1, 1:N, M:N 관계에 있는 엔티티의 간의 상호작용을 표현하기 위한 방법
• 식별관계 엔티티로 구성
• 추가적인 속성을 포함
• 예)
-> 직원과 프로젝트는 1:N이 될수도 M:N이 될수도 있다.그러므로 새로운 엔티티 생성
- 직원과 프로젝트 간의 관계 -> EmployeeProject (새로운 엔티티 생성)
- Employee(Employee ID, Name, Position)
- Project(Project ID, Project Name, Start Date, End Date)
- EmployeeProject(Employee ID, Project ID, Role, HoursWorked)
• 학생과 과목 간의 관계 -> Enrol
E/R 다이어그램 --> Relational Tables
• (somehow) automatic process
• 1:1, 1:N Strong relationships
• Foreign key or Association table
• M:N strong relationships
• Intersection table or Association table
• Weak, ID-dependent entities • Weak entity
• NonID-dependent: foreign key 추가 필요
• ID-dependent: 기본키의 일부로 포함되어 있음
• Recursive relationships
• Same as strong relationships
데이터베이스 설계 연습
• SNS: 트위터, 인스타그램, 페이스북
• 커뮤니티: 네이버카페, 클리앙
• 가격비교: 다나와
커뮤니티를 예로
Strong 엔티티
1. user
2. article (유저가 쓰는글)
3. Comments (댓글들)
어떠한 관계들이 숨어있는지 알아보자.
- User(user_id,user_name, phone ( 표시는 멀티 밸류), reg_date)
- Article(article_id,content,reg_date)
- Comment(article_id, comment_id,content,reg_date)
-> 여기서 phone* 을 없애고 새로운 엔티티를 만들어서 식별관계 생성
E-R 모델링
- Entity
- User(user_id,user_name, reg_date)
- UserPhone(phone_id ,phone_number)
- Article(article_id, content, reg_date)
- Comment(article_id, comment_id, content, reg_date)
- Follow(follower_id,followed_id,start_date)
-Relationship
- User - UserPhone: multi-valued atrrtribute, nonID-dependent
- User - Article : 1:N strong relationship
- Article - Comment : weak entity, ID-dependent(식별관계)
- User - Uer : follow 라는 M:N relationship ,Association Pattern 등장, 비식별관계 처리함
Relational Database 설계
-Table (기본키는 굵은 글씨)
- User(user_id,user_name, reg_date)
- UserPhone(phone_id, phone_number, user_id)
- Article(article_id, content, reg_date)
- Comment(article_id, comment_id, content, reg_date)
- Follow (id,follower_id, followed_id, start_date)
-> follower_id , followed_id 는 각각 외래키로 지정하고
-> follower_id,followed_id를 합쳐서 기본키로 지정하고 비식별관계 처리
관계형 데이터베이스가 아닌 데이터 구조 ?
• 관계형 데이터베이스 • Strict한 스키마: 애트리뷰트의 종류와 타입이 데이터 저장 전에 지정되어야 함.
• 숫자와 제한된 길이의 텍스트 애트리뷰트
• 읽기와 쓰기가 동시에 일어나는 online-transaction 처리에 최적화
• 검색은 상대적으로 느릴 수 있음
• NoSQL: unstructured/semi-structured documents • 임의 구조의 데이터를 스키마 없이도 저장 가능
• <key, value> 형식의 데이터 저장 구조
• Document 를 포함한 임의의 데이터 저장 및 관리에 용이
• Mongo DB, AWS DynamoDB
• 검색에 최적화된 Data Store • Elasticsearch
• 융통성있는 스키마, NoSQL 의 일종
• 읽기 성능에 최적화
