3주차 학습 수업 내용 요약
1. DB 모델, 용어 정의
관계형 데이터베이스(RDB)를 구성하는 개체(Entity)나 관계(Relationship)을 모두 릴레이션(Relation)이라는 표(Table)로 표현한다. 이를 응용하여 ER diagram을 제작할 수 있다.
예시) 출석부(Entity) - 학생기록부(Entity)
=> 출석부와 학생기록부에 중복되는 속성(Attribute)가 있을 것이다.
이러한 data의 중복을 피하고 연결하여 사용하기 위해 Relational DB를 사용하는 것이다.
1) 관계형 데이터 베이스?
구조화된 데이터는 하나의 테이블로 표현할 수 있다.
사전에 정의된 테이블을 relation 이라고도 부르기 때문에, 테이블을 사용하는 데이터베이스를 관계형 데이터베이스(Relational database)라고 한다.
- 데이터(Data): 각 항목에 저장되는 값.
- 테이블(Table; 또는 relation) : 사전에 정의된 열의 데이터 타입대로 작성된 데이터가 행으로 축적된다.
- 칼럼(Column; 또는 field) : 테이블의 한 열. 일반적으로 개체의 한 특성을 서술하는 속성 값을 의미한다.
- 차수(Degree) : 속성(칼럼)의 개수
- 레코드(Record; 또는 tuple) : 테이블의 한 행에 저장된 데이터
- 기수(Cadinality) : 튜플의 수 (기수, 대응수라고도 함)
- 키(key) : 테이블의 각 레코드를 구분할 수 있는 값. 각 레코드마다 고유한 값을 가진다.
기본키(primary key)와 외래키(foreign key) 등이 있다 - 도메인(Domain) : 하나의 속성이 취할 수 있는 같은 타입의 원자값들의 집합이다. 도메인은 실제 애트리뷰트 값이 나타날 때 그 값의 합법 여부를 시스템이 검사하는 데에도 이용된다.
- 스키마(Schemna) : 테이블의 각 열에 대한 항목과 타입, 기본 키와 외래 키도 나타내는 등 테이블을 위한 청사진이다.
스키마는 개체-관계 다이어그램(entity-relationship diagram)이나 문자열로 표현할 수 있습니다. ex) Reservation(ID, Name, Date, RoomNum)
2) 엑셀 내 DB 비유
DB는 엑셀파일에 빗대어 보면 아래와 비슷하다고 생각할 수 있다.
- 엑셀내 칸 - 데이터 - DML과 연관 (Select, Update, Delete 등 데이터 조작)
- 엑셀 시트 - 테이블 - DDL과 연관 (Create, Alter, Drop 등 테이블 정의)
- 엑셀 파일 - 스키마 - DCL과 연관 (Grant, Rollback 등 권한 제어)
3) 데이터 모델 종류와 그 각각의 정의
정보출처 : 제씨스토리 블로그
데이터모델의 구성 요소
개체(Entity), 속성(Attribute), 관계(Relationship)
1) 개체(Entity)
-
개체는 데이터베이스에 표현하려는 것으로, 사람이 생각하는 개념이나 정보 단위 같은 현실 세계의 대상체이다.
-
개체는 실세계에 독립적으로 존재하는 유형, 무형의 정보로서 서로 연관된 몇 개의 속성으로 구성된다.
-
파일 시스템의 레코드에 대응하는 것으로 어떤 정보를 제공하는 역할을 수행한다.
-
독립적으로 존재하거나 그 자체로서도 구별 가능하다.
2) 속성(Attribute)
-
속성은 데이터의 가장 작은 논리적 단위로서 파일 구조상의 데이터 항목 또는 데이터 필드에 해당한다.
-
속성은 개체를 구성하는 항목이다.
-
ex) 교수번호, 성명, 전공, 소속으로 구성된 교수 개체
3) 관계(Relationship)
-
개체 간의 관계 또는 속성 간의 관계이다.
-
ex) 교수가 학생을 지도하는 관계
-
관계의 형태
-
일 대 일 : 개체 집합 A의 각 원소가 개체 집합 B의 원소 한 개와 대응하는 관계
-
일 대 다 : 개체 집합 A의 각 원소는 개체 집합 B의 원소 여러 개의 대응하고 있지만, 개체 집합 B의 각 원소는 개체 집합 A의 원소 한 개와 대응하는 관계
-
다 대 다 : 개체 집합 A의 각 원소는 개체 집합 B의 원소 여러 개와 대응하고 개체 집합 B의 각 원소도 개체 집합 A의 원소 여러 개와 대응하는 관계
2. 수업 간 생각해본 문제
1) Attribute와 Entity의 구분
- ex) 학생과 교과목
| Entity 이름 | 속성 |
|---|---|
| 학생 | 학번(pk), 이름,전공,학년... |
| 교과목 | 교과목코드(pk), 강의시간, 이수 학점 인정 수... |
이 두 Entity 테이블을 관계 지어서 어떤 학생이 어떤 과목을 듣는 지를 구현하고 싶다.
ex) 송승헌 - 컴퓨터공학개론을 듣는다.
이 때 연결고리를 의미하는 테이블을 제작하기 위해 중간에 관계형 테이블을 제작한다.
| Entity 이름 | 속성 |
|---|---|
| 학생 | 학번, 이름,전공,학년... |
| 교과목 | 강의시간, 이수 학점 인정 수... |
| 수강신청 | 학생학번(fk), 교과목 과목 코드(fk) |
이 때 관계는 N : M 관계이다.
학생테이블 -- 수강신청(R) -- 과목테이블
n m
→ 1명의 수강생이 여러 개를 수강신청 할 수 있음
→ 한 과목에 여러 학생들이 들을 수 있음
cf) pk의 경우 모든 테이블에 넣어주는 게 좋으나 직접 넣어주는 경우는 거의 없다.
(거의 고유의 값으로 저장하기 위해 테이블에 들어가는 순서 등을 고려해 각 레코드 값에 고유한 pk 값을 부여한다.)
2) 각 관계의 형태 간 테이블의 구성
1. 각 테이블이 1 대 1 관계일 경우
학생테이블 -- 자리테이블
1 1→ 1명의 수강생이 한 자리만 차지할 수 있음.
-
하나의 레코드가 다른 테이블의 레코드 한 개와 연결된 경우이다.
한 테이블 내에 다른 테이블의 pk를 불러와 fk로 사용한다. (주체 객체 상관 없음) -
학생 테이블의 경우
| 이름 | 학번(학생 pk) | 착석한 의자 번호(의자 테이블의 pk로 fk) |
|---|---|---|
| 김철수 | A06 | 1 (의자ID_1, fk) |
| 이영희 | A02 | 2 (의자ID_2, fk) |
| 박혁거세 | B01 | 3 (의자ID_3, fk) |
2. 각 테이블이 N 대 1 관계일 경우
선수 테이블 -- 팀 테이블
N 1→ 여러 선수들은 각각 한 팀에만 소속할 수 있음.
-
하나의 레코드가 서로 다른 여러 개의 레코드와 연결된 경우.
N 관계의 테이블에 1에 해당하는 테이블의 pk를 불러와 fk로 사용한다! -
선수 테이블에 소속 팀의 pk를 fk로 넣을 경우
| 이름 | 주민번호(선수 pk) | 소속 구단 코드 (팀 테이블의 pk로 fk) |
|---|---|---|
| 김철수 | 938303-xxxxxxx | KS1(수원 삼성) |
| 이영희 | 928103-xxxxxxx | SS1 (FC 서울) |
| 박혁거세 | 008303-xxxxxxx | KK1 (고양 원더러스) |
- 팀 테이블에 소속 선수의 pk를 fk로 넣을 경우
| 소속 구단 코드(pk) | 소속 팀원 주민번호(선수 pk로 fk이자 pk) |
|---|---|
| KS1(수원삼성) | 938303-xxxxxxx(김철수) |
| SS1(서울FC) | 928103-xxxxxxx(이영희) |
| KS1(수원삼성) | 008303-xxxxxxx (박혁거세) |
-> 데이터 중복발생! (Pk도 재고려해야..)
N 대 1 관계에 있어
데이터의 중복을 줄이기 위해선 N 관계 테이블에 1의 pk를 넣는 것이 좋다.
(공간 확보에 유리하나 성능 면에서는 느리다. 일단 공간 확보가 우선시라는 가정 하)
3. 각 테이블이 N 대 M 관계일 경우
N대 M의 경우 (위에서 예시를 들었으므로 생략)
학생테이블 -- 수강신청(R) -- 과목테이블
n m
→ 1명의 수강생이 여러 개를 수강신청 할 수 있음
→ 한 과목에 여러 학생들이 들을 수 있음
-
수강신청이라는 관계 테이블을 따로 제작해주어 관리해야한다.
3) 인스타그램 내 각 테이블에 대한 스키마를 제작해보면?
사진출처
해당 사진 내에서 2번 화면을 예시로, 우리가 Entity를 만들고 각 내부 속성을 생각을 해보자.
기본적으로 User, Follow, Post, PostImg, Comment, Like, CommentLike, Tag 등의 Entity를 제작할 수 있을 것이다..
이 때 각 Entity는 모두 createdAt, updatedAt, status (active, inactive , deleted)를 갖는다. (처음생성날짜, 업데이트날짜, 상태(보통 데이터를 삭제하지 않으므로 활성화중인지, 비활성화중인지, 삭제한 것처럼 보일지 속성 값을 만들어 삭제하지 않고 보관)
1 User
userId (PK),email, password, phone
profileImgUrl, age
nickName, name, message,
createdAt, updatedAt, status (active, inactive , deleted) ,
2. follow
followingId(userId- FK), followedId(userId-FK)
createdAt, status (active, inactive , deleted)
3. Post
postId (PK), content, 시간, userId(FK)
createdAt, updatedAt , status (active, inactive , deleted)
4. PostImg
postImgId(PK)
postId(fk)
createdAt, status (active, inactive , deleted)
5. Comment -
commentId (PK), userId(FK), postId(FK)
createdAt, status (active, inactive , deleted)
6. Like
likeId(PK), postId(FK), userId(FK)
createdAt, status (active, inactive , deleted)
7. commentLike
commentLike(PK), userId(FK).commentLIke(FK), createdAt, updatedAt , status (active, inactive , deleted)
8. Tag
userId, postId, x,y(좌표)3. DB 컬럼 타입
RDB(MS)로 Oracle, MySQL, MariaDB 등 다양한 게 있지만 MySQL 기준으로 참고
.
자세한 내용은 아래 링크를 통해 확인하자.
참조링크:신기한 사전 블로그
고려할 사항
이름
-> VARCHAR(10) 권장(글자수에 따라 가변)
- MySQL의 경우 4.1이전까지는 byte였다가 그 이후 글자수로 변경되었다.
(한글은 utf8에서 한글자당 3바이트를 차지함)
학점
-> Float or Double 권장 (소수점 표현)
휴대전화
-> VARCHAR 권장 (Int로 표현 시 앞자리 0이 구현 안되는 등 사유 + 다른 번호와 구별)
비밀번호
-> Text 권장 (자주 바뀌는 정보 + 입력한대로 노출된다면 이는 보안상 문제, 문자열 처리)
4. 느낀 점
이번 과제는 딱 듣기에도 어려움이 많을 과제였다.
1. AWS RDS 구축
2. App 선정 이후 DB ERD 설계 및 특정화면에 관해 한방쿼리 작성하기
크게 위 두 과제로 나뉘는데.. 1번을 후딱 하고 2번을 다음 주까지 계속 붙잡아야겠다..ㅎㅎ
일단 본인은 게시물 작성 기능, 사용자 정보 확인 기능, 게시글, 댓글, 채팅 기능 등의 작성할 내용이 꽤나 많아보이는 당근마켓으로 App을 선정했다.
