[정리] 데이터PM에 대하여 #DB #DBMS #스키마 #SQL

Program: 어떤 문제를 해결하기 위해 컴퓨터에게 주어지는 처리 방버봐 순서를 기술한 일련의 명령문 집합체

• Service = UI + Front end/Back end (Client/Server) + DB

 📢 DB (Data base)

• 컴퓨터 시스템에 전자 방식으로 저장된 구조화된 데이터의 체계적인 집합
• DB = Data server + DBMS(관리 system) + SQL (언어)
• (EX=AWS+MySQL+SQL(언어))

데이터 분석 process

1. Concept: 어떤 목적으로, 어떻게 수집해야 하는가?
2. Collection: 수집 절차를 어떻게 구성해야 하는가? (방법, 절차 등)
3. Processing: 입력된 데이터를 어떻게 변형할 것인가? (양 확인, 정보 요약, 기록)
4. Distribution: 처리한 데이터를 어떻게 봐야 하는가?
5. Discovery: 데이터의 분포를 바탕으로 결과 도출 (데이터 정리, 인사이트/특이점 도출)
6. Anaysis: 처리하고 발견한 결과에서 유의미한 분석을 도출하는 단계 (어째서, 왜 이런 결과가 나왔는지)

• 부족함이 있다면 → Repurposing (재시도) ⇒ Step 3 ⇒ Achiving ⇒ Step 4

데이터 기반 PM

• 데이터 기반 인사이트를 바탕으로 제품 및 기능을 설계, 통계 뿐석을 위한 시각화 도구로 데이터 시각화, 가설 테스트 및 모델링을 통해 변수 간의 고유한 관계 식별
• 업무
  1. 시장 지식 데이터 활용 → 제품 개발 확대
  2. 데이터 과학 기술, 데이터 엔지니어링 프로세스, 시장 테스트를 적용하여 맞춤형 제품 경험 제공
  3. Data warehousing 및 시각화 우수성 활용 → 제품 전략 알리기
  4. Data pipeline 및 warehousing 전략 개발
  5. A/B테스트 설계 및 변수 테스트 설계/실행 방법 포함 실제 데이터 평가 기술 학습
  6. 통계 분석에서 포착한 출력 평가, 이를 인사이트로 변환하여 제품 결정 알리기
• 협업 동료
  • Data Analyst: 데이터를 받아 유의미한 인사이트를 발견하는 사람
  • Data Scientist: 머신러닝, 통계분석 등을 이용해 유의미하게 가공
  • Data Engineer: 데이터와 관련된 기술, DB 구축 업무, Data pipeline 구축(=데이터와 관련 서버를 만들고 연결시키기)
  • SW Engineer: SW 개발

 

읽기자료

[웹기획가이드] 데이터베이스(DB), 어렵지 않아요~!!

DB 효율화를 위한 기획자의 참여 범위

1. 데이터 수집 범위 정의
2. 수집한 데이터 운용/관리정책 수립

 

DB 운용 단계: Writing > Save > View > Edit

• (ex) Step 2(Save)에서의 정책적 고민
  • 서비스를 구성하는데 있어, 저장해야 할 데이터가 필요한 데이터인지 아닌지
  • (동일한 관점에서) 지금 받아야만 하는 데이터인지 나중에 받아도 되는지
• Data를 어떻게 사용하느냐에 대한 정책을 수립하는 것이 기획자의 범주
  • ex. 새 글에 ‘N’ 아이콘을 몇 일이나 노출시킬지, 글 제목은 몇 자까지 노출시키고 그 이후는 ...으로 표기할 것인지 등
  • 스토리보드(화면 설계) 과정 이전에 모두 정의되어야 함 (그래야 DB 설계시 기획적인 정책 반영 가능)

 

 

 

읽기자료

IT 회사에서 데이터 직군은 데이터를 어떻게 관리할까?

• DW = 가공된 데이터를 저장하는 창고 (DB의 일종)
• DW도 가공되어있다 하지만 여전히 복잡해 보이기에 BI(Biz Intelligence)툴을 이용해 시각화

 

 

읽기자료

개념 정리 - (9) 데이터베이스 편

• DB 스키마
  • 외부 스키마: 각 사용자의 관점에서
  • 개념 스키마: 모든 사용자의 관점에서
  • 내부 스키마: 물리적으로 DB에 접근하는 관점

---

📢 R-DBMS (관계형 데이터 베이스)

R-DBMS

• 데이터를 따로 기록하고 기본키를 사용해 상호간의 관계를 기록하는 DM
  • 각 데이터 별로 고유한 ‘기본키’ 값을 갖도록 하는 컬럼을 하나 두고 해당 컬럼의 값을 연결해 기록함으로써 데이터 기록 양을 줄이면서도 데이터를 연관해서 살펴볼 수 있는 구조.
  • 기본키: 주민번호와 같이 모두에게 겹치지 않으면서 해당 값을 알면 다른 정보들을 모두 확인하게 해 줄 수 있는 값
• E-R 다이어그램: 각 데이터 베이스별로 항목의 구성, 기본키, 각 데이터베이스별 관계를 이해하기 쉽게 그림으로 표현한 것
• 스키마
  • 데이터베이스의 구조와 제약조건에 관해 전반적인 명세를 기술한 것
  • 스키마가 정의하는 정보
    • 개체의 특성을 나타내는 속성(Attribute)
    • 속성들의 집합으로 이루어진 개체(Entity)
    • 개체 사이에 존재하는 관계(Relation)에 대한 정의
    • 이들이 유지해야 할 제약조건(Constrant)

 

📢 SQL

• 관계형 DBMS의 데이터를 관리하기 위해 설계된 특수 목적의 프로그래밍 언어
• 실습 사이트: https://www.w3schools.com/sql/default.asp
• 종류
  • 데이터 조작어 (얘만 이해해도 충분!)
  • 데이터 정의어
  • 데이터 제어어
  • 트랜잭션 제어어
• NoSQL: 관계형 DB와 SQL을 사용하지 않고 데이터를 관리하는 DBMS

	SQL	NoSQL
장점	사용/구성 용이 범용적으로 사용 높은 트래픽 감당에 적합 구조화된 데이터 적합	디자인 절차 필요 X 빠른 개발 주기 일반적으로 SQL보다 빠름 클라우드 서비스에 적합
단점	데이터간 관계가 중요한 경우 부적합 기술적으로 성숙도 낮음 응답시간이 느림	데이터간 관계가 중요한 경우 부적합 기술적으로 성숙도 낮음 응답시간이 느림

 

📢 PM이 데이터를 다룰 때의 유의사항

• ★ 어떤 데이터를 어떻게 가져올지를 기획/설계/분석하는 능력
• 유의점
  1. 관계형 DB 특성 이해
     : 한 번에 모든 데이터를 보기 어렵기 때문에, 확인해야 할 DB와 스키마에 대한 충분한 이해 필요 (스키마, 기본키, 제약조건, DB 구성 등)
  2. DB 스키마는 수정이 거의 불가능하다 (한 번 정하면 바꿀 수 X)
     : 처음 수립 시 적당한 확장성과 비용을 생각하는 것이 중요
     : 한 번 수립하면 이후 수정하기 위해서 인력, 물질적 비용 발생
  3. 수집된 데이터는 항상 가공 필요
     : 원하는 기간, 설정, 분석 등을 통해 가공, 알고 싶은 내용 도출할 수 있어야 함

읽기 자료

데이터 프로덕트 매니저의 부상

 

읽기 자료

관계형 데이터베이스 설계 및 구축

• 요구사항 정의서와 스키마 설계