데이터 베이스 기초(모델링)

1. 데이터베이스의 기초 이해

• 컴퓨터 시스템에 저장된 정보, 데이터의 집합
• 데이터 베이스와 반대가 되는 개념은 메모리 개념. 메모리에 저장을 하게 되면 컴퓨터 종료 시 데이터가 저장되지 않는다. 하지만 메모리는 속도가 데이터 베이스보다는 빠르다.
• 데이터에 접근 및 관리를 편하게 하기 위해 사용

2. 관계형 데이터 베이스 (RDBMS, Relational DataBase Management System)

• 일반적으로 데이터 베이스에는 크게 관계형 데이터베이스와 비관계형 데이터 베이스가 있다고 한다. 체계적으로 저장할 수 있고 데이터의 완전성 보장 트렌젝션을 통해 안정성을 보장한다.
• 단점은 테이블 구조 변화에 덜 유연해 확장성이 쉽지가 않음(서버의 성능을 올리는 것으로 확장성을 보강)
• 이름 그대로, 관계형 데이터 모델에 기초를 둔 데이터 베이스 시스템
  • ex) MySQL, Postgres, Oracle DB
• Column(열), Row(행) 구성
• 각 row는 고유한 키(Primary Key)값을 가지며, 해당 로우를 찾거나 인용하는데 쓰인다. 각각의 테이블이 구성되는 모습이 서로가 서로에게 연결되어 있는 상호관련성을 통해 이루어진다.
• 전자상거래 정보 거래 정보 등에 사용이 된다
• 아주 간단하게 비관계형 데이터베이스에 대해서도 살펴보자면, 1) 데이터 구조 변화에 유연 / 서버의 수를 늘리면 확장이 가능 2) 데이터를 저장할 때 정리를 하지 않고 방대하게 저장을 할 수 있음, 이로 인해 안정성은 적은 편

3. 관계형 데이터 베이스의 3가지 종류

1. One to One (1대1 매칭)
   

• users라는 행 안에 id라는 로우(열)이 있고 이 부분은 다시 user_profile이라는 행 안의 로우와 매칭이 된다. id 는 user_profile를 가르킨다.
• 앞서 본 one to one 예에서 user_profiles 테이블의 user_id 컬럼은 users 테이블에 걸려있는 외부 키라고 지정합니다 -> 그럼 이건 어제 이해한 것과 다른 건데? -> 이 부분이 살짝 이해가 안된다.

2. One to Many
   

• 하나의 정보를 여러 개의 데이터로 연결 관계를 지을 수가 있다.
• 주문은 여러 개가 생성이 되지만, 주문을 한 고객은 한명이다.
• 밑에서 나올 스타벅스 모델링 과제의 카테고리라고 생각을 하면 될 것 같다. 카테고리는 하나이지만 그 안의 음료는 여러 개가 있기 때문에. (하나의 카테고리에 여러 제품이 들어 있는 관계도 마찬가지이다)

3. Many to Many
   

• Many to Many 모델에 대해서는 밑의 스타벅스 모델링 과제로 자세하게 알아보도록 하겠다.

4. 스타벅스 모델링 리뷰

1. 위의 모델링 구조는 조별 과제로 해결했었던 것인데, 모델링에 대한 이해도가 조금 부족해 다시 공부해야할 필요성을 느꼈다. 피드백 받았었던 부분을 중심으로 데이터 모델링에 대한 이해도를 높이고 수정해 보도록 한다.

2. 우선 가장 처음 수정되어야 할 부분으로 Code Convention이 있다.

   1. 영어로 작성
   2. 카테고리명은 소문자 + 복수형
   3. 복합적인 명칭을 사용할 때는 _ 붙여서

   등을 지켜주면 될 것 같다(이외에도 많이 있겠지만...ㅜ)

3. 우선 위의 모델링은 메인이 되는 모델을 중심으로 전체적으로 다 밖으로 나가는 방향으로 처리를 했는데 그렇게 하지 않아도 될 것 같다.

• 수정사항) 이미지 방향 반대. one to many로 설정하여 이미지 파일을 관리하는 부분에서 업데이트가 되고, 메인?쪽에서 정보를 받아올 수 있도록.

• 수정사항) 음료 설명은 따로 데이터를 연결하지 않아도 될 것 같음. 메뉴 하나당 하나만 있는 값이어서.

• 수정사항) 신상유무도 반대로 연결. 정보를 받아서 온다는 개념으로. (신상유무는 tinyinteger 사용. 있는지, 없는지, 아주 작은 값을 저장할 때 사용이 된다고 함)

• 수정사항) 알러지 유무는 중간에 테이블을 하나 더 만들어서, 있는지 없는지를 서로 참조할 수 있도록 정리.

• 수정사항) 메뉴 이미지에 대한 저장은 varchar로 하되, url을 저장할 경우에 2000자 정도로 제한을 걸어주면 좋음.

• 수정사항) 개별 항목들에 대한 수정이 생겼을 때, 어떻게 하면 효율적으로 관리를 해야 하는가에 대한 생각을 해야함. 알러지 종류가 어떻게 되어 있고.. 보다는 primary key 에서 해당 항목들을 잘 참고할 수 있도록 정리.

4. 

• 일단 위에 것들만 다시 이해하면서 정리한 표인데, 아직까지 pk, fk 등을 잘 이해하지 못한 것 같다. 추가적으로 계속 학습을 해야할 것 같다...