웹 기획
설계
화면 설계 - 와이어프레임 (툴 예시: figma)
디비 설계 - ER 다이어그램 (툴 예시: draw.io)
API 설계 - API 명세서 (툴 예시:swagger)
- 와이어프레임이란 UI/UX의 기초, 프로토타입
ERD (ER 다이어그램) 작성
데이터 모델은 데이터베이스에 독립적이다
정보 시스템을 개발하기 전에 보다 많은 아이디어를 도출하고 데이터베이스 설계의 이해를 높이기 위해 데이터모델링을 해야 한다
관계형 데이터 모델은 실체(Entity), 속성(Attribute), 관계(Relationship)로 구성된 ER Diagram으로 표현된다
실체(Entity) : 관리하고자 하는 정보의 실체
ㄴ둥근 사각형으로 작성
ㄴEntity 이름은 단수형이고 유일하며 대문자로 크게 표기 할 것. ( )안에 동의어 표기 가능
ㄴ모든 Entity는 하나 이상의 식별자 (UID : Unique Identifier)을 가져야한다
ㄴUID가 없다면 Entity가 아님
속성(Attribute) : Entity를 구성하고 있는 구성 요소
ㄴAttribute 이름은 소문자로 작게 표기할 것
ㄴEntity 이름과 Attribute 이름이 같으면 안됨
ㄴ"#" 은 UID. "*"는 필수(Mandatory). "o"는 선택(Optional) Attribute를 의미
ㄴ자신의 Attribute가 아니면서 Relation을 위해 자신의 Attribute로 표시해서는 안된다.
관계(Relationship) : Entity간의 관계
ㄴ 두 Entity 사이에 선을 긋고 관계 명칭을 기록한다
ㄴ 선택 사항을 표시한다
ㄴ 점선은 선택 (may be) 을 의미 (부서입장에서는 사원을 배치받을 수도 있고, 안받을 수도 있기 때문에)
ㄴ 실선은 필수 (must be) 를 의미 (사원입장에서는 반드시 부서에 배치되어야 하기 때문)
ㄴ 관계 형태를 표시한다
ㄴ 새 발 모양은 하나 이상 (one or more) 을 의미 (사원 여러명이 한 부서에 속할 수 있기때문)
ㄴ 단 선은 단 하나 (one and only one) 를 의미 (한명의 사원은 한 부서에만 소속될 수 있다)
관계 형태
(1) 1 : 1 관계
양쪽 방향 모두 단 하나씩 (one and only one)
1 : 1 관계는 실제로는 동일한 ENTITY일 경우가 많다
(2) M : 1 관계
한쪽 방향은 하나 이상 (one or more) (각 사원은 단 하나의 부서에 반드시 소속되어야 하고, 각 부서는 여러명의 사원을 배치받을 수 있다)
다른 방향은 단 하나씩 (one and only one)
(3) M : M 관계
양쪽 방향 모두 하나 이상 (one or more)
(각 학생은 하나이상의 교육과정에 신청할 수도 있고, 각 교육과정은 여러 학생을 등록 받을 수 있다)
📌참고
user : post = 1 : N
하나의 user는 여러개의 post를 작성 할 수 있다
하나의 post는 하나의 유저만 작성할 수 있다
post : media = N : M
하나의 post에 여러개의 media(사진 또는 영상)를 올릴 수 있다
(regram 가능할 경우) 하나의 media는 여러개의 post에 올라갈 수 있다
post : media = 1 : N
하나의 post에 여러개의 media(사진 또는 영상)를 올릴 수 있다
(regram 불가능할 경우) 하나의 media는 하나의 post에만 올라갈 수 있다
post : textcontent = 1 : 1
하나의 post는 하나의 textcontent를 작성할 수 있다
하나의 textcontent는 하나의 post에만 사용될 수 있다
post : comment = 1 : N
하나의 post는 여러개의 comment가 달릴 수 있다
하나의 comment는 하나의 post에만 달 수 있다
post : hashtag = N : M
하나의 post는 여러개의 hashtag를 가질 수 있다
하나의 hashtag는 여러개의 post에 달릴 수 있다
post : tagged_user = N : M
하나의 post는 여러명의 tagged_user를 가질 수 있다
하나의 tagged_user는 여러개의 post에 태그될 수 있다
user : like = 1 : N
하나의 user는 여러개의(여러 포스트에) like를 할 수 있다
하나의 like는 하나의 user(like를 한 주체)만 가질 수 있다
post(또는 comment) : like = 1 : N
하나의 post(또는 comment)는 여러개의 like를 받을 수 있다
하나의 like는 하나의 post(또는 comment)에만 보내질 수 있다
user : following = N : M
하나의 user는 여러명을 following 할 수 있다
하나의 following(된 대상)은 여러 user로부터 팔로잉 받을 수 있다
user : block = N : M
하나의 user는 여러명을 block 할 수 있다
하나의 block(대상)은 여러 user로부터 block 당할 수 있다
-
DB Primary Key(기본키)
-
DB Foreign Key(외래키)
Github pull requests
포크 후 터미널에서
$ git clone 포크한 나의 주소 git clone
원격 저장소 remote
- 내가 PR을 보낼 곳을 추가
- 원격 저장소의 git 주소는 fork를 하기 전 원래의 저장소를 의미
$ git remote add (저장소명) (포크해온 주소)PR용 branch 생성
$ git checkout -b test코드 수정 후 add, 커밋 메시지 작성
$ git add .
$ git commit -m "커밋메시지는 프로젝트의 정해진 규칙이 있다면 그것에 맞게 작성해 주세요"PR용 branch에 푸시
$ git push origin (브랜치 이름)
fork해온 나의 저장소에 들어가서 Compare & pull request 버튼 눌러서 활성화
-> 프로젝트의 양식과 규칙에 맞게 자신이 기여한 것들을 작성.
그 다음 Create pull request 버튼을 눌러서, 오픈소스 프로젝트에서 나의 PR이 승인되어 merge될 때 까지 기다리기
PR 승인이 되었다면 branch 삭제하기
# 코드 동기화
$ git pull (remote 이름) # 원본 remote 와 동기화
# branch 삭제
$ git branch -d (브랜치 이름) # 용무가 끝난 브랜치 삭제