코드스테이츠 33일차 [ DB설계 실습 ]

Lumi·2021년 10월 20일
0
post-thumbnail

실제 DB는 어떻게 이루어 지는지 궁금하여 영상을 보고 공부를 하였다.

  • 이부분은 코드스테이츠 내용이 아니고 다른 유튜브 영상이라는 것을 알아두자!!

출처 : https://www.youtube.com/watch?v=GroeyzBNhfU

기본 개념

실무에서 프로젝트를 어떻게 시작을 하고 설계를 하는지 부터 다루어 보자

개발이라고 하면 흔히 6개의 단계로 이루어 지게 된다.
1. planning
2. analysis
3. design
4. implementation
5. testing and integration
6. maintenance

  • 이 6개 단계의 순서를 지키는 것은 아니고 필요에 따라서 전 상태로 돌아가기도 한다.

최초 인터뷰를 통해서 어떻게 어떤 기능을 원하는지에 대해서 정보를 얻고
업무 분석을 통해서 ideation회의를 하게 된다.

회의를 하면서 다이어그램, 기획서 등등이 작성이 된다.

  • 완전 초기 단계로 보면된다.

보통 회의를 통해서 기획자들이 서비스 틀을 생각하게 된다.
이후 디자이너들이 UI/UX를 설계하고 개발자들은 DB를 설계를 한다.

  • 모델링을 한다고 말하기도 한다.

설계가 모두 끝나면 인프라 설계를 하게된다.

  • 하지만 인프라는 보통 앞단계에서 얼추 설계가 끝나게 된다.

인프라가 구축되면 구현 과정을 거친다.

  • 변수, 스타일 표준, 언어 사용 들을 선택하고 개발을 하게 된다.

이후 테스트 및 오픈 및 운영을 하게 된다.

앞서 말했듯이 이 과정은 정해진 순서가 아니라 상황에 따라서 유연하게 이루어 진다.

Database Modeling

  1. 개념적 모델링
  • Entity도출
  • 어떤 테이블을 형성할지를 생각을 하는 단계
  1. 논리적 모델링
  • Data 구조 및 속성 정의
  • 무결성 정의 및 정규화
  1. 물리적 모델링
  • Schema, Table, index생성

순서가 이런식으로 이루어 진다는 거지 실제 순서를 지킬 필요는 없다.

하지만 모델링은 매우 중요하다.

  • 기능 추가, 변경을 할떄 문제가 생기는 이유는 대부분 모델링이 잘못된 경우이다.

그러므로 최초 모델링할떄 정규화 하는 과정이 매우 중요하다.

정규화

  • 중복 데이터를 없애고 관계를 단순하게 가져 가는 것을 말한다.

sql시험을 보는 경우에는 1~3정규화 등등을 외워야 하지만
실무에서는 이런내용은 필요가 없다.

처음에는 한 테이블에 많은 정보를 담는것이 간단하다.

  • 학생 + 수강신청 목록 을 한테이블에 담는것처럼

하지만 이 방법은 DB에 익숙해질수록 복잡하다고 한다.

  • 학생 따로, 수강신청 따로 관리하는것이 좋다.

foreign key까지 설정을 하면 보통 정규화가 끝나게 된다.

foreign key란 다른 테이블을 참고하고 있는 key를 말한다.

예를들면 건물1이라는 테이블에 임대인이 A라는 데이터가 들어가 있다.
하지만 후에 건물1이 팔리고 A라는 임대인은 건물2라는 건물을 구매하게 되었다.

그런데 문제는 팔린 건물1에는 A라는 임대인의 정보가 들어있고 건물2에도 A라는 정보가 있기 떄문에 
데이터의 중복이 일어나 정규화가 성립하지 않는다.

그러기 떄문에 임대인이라는 테이블을 따로 만들어서 건물 테이블에 임대인정보 데이터를 foreign key로 만들어 임대인 테이블과 연결해야 한다.

- 이 부분은 후에 실습을 통해서 자세히 다루어 보자!

모델링 기법(주의사항)

1. PK가 가장 중요하다.

  • 유일값을 갖는 기본키
  • 변경이 없는 안정적인 값(null 불가능)
  • 가능한 1개의 컬럼 실수 보다는 정수형으로(자동증가 컬럼!)

2. 적절한 정규화

  • 최대한 중복 데이터를 줄이고 계산 결과 컬럼을 최대한 자제
  • Null이 필요 없다면 왠만하면 Not Null을 설정해 두자

3. 참조(데이터) 무결성을 위해 FK를 정의하자.

4. 서로 다른 성격의 컬럼들은 테이블을 분리하자

이정도만 지켜도 성공적인 모델링이 된다.

실습

  • 개발할 시스템이 이런 형태라고 생각을 해보자

UseCase Diagram작성

Entites

  • 물건, 매물
  • 임차인/매수인/세입자
  • 임대인/매도인
  • 복덕방
  • 중개인
  • 관리자
  • 관심물건

Behavior(queries)

  • 사용자 및 관리자 로그인
  • 물건 올리기
  • 물건 검색, 물건 상세보기
  • 계약, 이사하기
  • 임대인 승인하기

생성 테이블 및 컬럼

  • 복덕방 : 번호, 사무소이름, 대표자, 전화번호, 기타 번호, 등록번호, 사무소, 소재지, 특징
  • 중개인 : 중개인 번호, 가입일, 이름, 연락처, 소속, 직급(권한), 로그인 아이디, 패스워드, 탈퇴일
  • 사용자 : 사용자번호, 가입일, 이름, 연락처, 거주지, 로그인 아이디, 패스워드, 탈퇴일, 주민번호
  • 물건 : 물건번호, 형태, 우편번호, 물건명, 물건 위치(동,층,번지), 크기, 금액, 월세, 관리비, 이사 날, 욕실수, 주차 유무 등등
  • 관심물건 : ID, 등록일, 사용자번호, 물건번호
  • 계약서 : 계약번호, 계약일자, 인도일자, 물건번호, 계약금, 중도금, 잔금, 융자금, 특약사항

이 데이터들은 모두 회의를 거쳐서 나왔다고 가정한다.

  • 나는 단순히 실습이기 떄문에!!

  • 실제로 저 많은 데이터를 표현할수는 없기 떄문에 맛보기 용으로 조금이나마 작성을 해보았다.
일단 상황은 모든 사용자가 로그인이 되엇다고 가정을 하였다.

집주인이 물건을 올리면 물건이 데이터상에 나타날것이고

데이터 상에 있는 물건중 중개인이 중개인 등록을 통해서 중개인과 집주인이 매칭될 것이다.

이후 세입자가 물건을 검색하여 원하는 물건에 계약 신청을 하게 된다.
- 원하는 경우에는 관심물건으로 등록할수 있다.

계약신청이 되면 집주인에게 알림이 가고 모두 계약이라는 인스턴스에 참여하게 된다.
- 이 계약이라는 인스턴스에는 추가적으로 자료, 검증 이라는 정보를 제출할수도 있다.

이후 서로의 합의하에 계약서를 작성하게 된다.

`보면 알수 있듯이 굉장히 작게 표현을 해보았다.`

  • building : 물건, Agent: 중개인

간단한 실습이다.

테이블을 두개 만들어서 서로 연간관계를 맺어 주는 것이다.

부동산이 삭제가 되면(팔리던가) 중개인도 사라져야 하기 떄문에 foreign key를 설정 해준 것이다.

  • 추가적인 연관관계를 맺어준 것이다.

중개인과 또다른 item을 연결을 해주었고 item의 주인까지 지정을 해주었다.

더 추가적인 작업도 가능하지만
너무 복잡하고 내가 잘 못따라갈꺼 같아서 이쯤에서 마무리 하였다.

  • 사실 저런 연관관계를 맺는것을 계속해서 하는 것이다.

어떤 느낌인지를 얼추 알껏 같다는 느낌이 든다!!

profile
[기술 블로그가 아닌 하루하루 기록용 블로그]

0개의 댓글