1.  프로젝트의 진행단계

​

👩🏻‍🚀 프로젝트 project란 대규모의 프로그램을 작성하기 위한 전체과정

  ⚡️ 분석과 설계 작업을 등한시하는 소프트웨어 분야의 고질적인 문제점 때문에 소프트웨어 개발 방법론이 제시됨

​

👩🏻‍🚀 소프트웨어 공학에서 제시하는 소프트웨어 개발 모델로 '폭포수 모델 Waterfall Model' 이 있다.

  ⚡️ 장점 : 단계가 명확히 구분되어서 프로젝트의 진행단계가 명확해짐

  ⚡️ 단점 : 문제점이 발생될 경우 다시 앞 단계로 거슬러 올라가기 어렵다.

👩🏻‍🚀 이 모델에서 가장 핵심적인 단계는 '업무 분석과 시스템 설계'

​

1) 프로젝트 계획

​

- 어떤 프로그램을 누가 어떻게 작성할지 계획을 세우며 요구 기능, 예산, 개발 기간을 결정.

​

2) 업무 분석

​

- DB 응용 프로그램은 원래 사람이 하던 일을 전산화한 것. 따라서 현실 세계의 수작업을 면밀히 분석하는 업무 파악 부터 시작.

- 업무의 개요와 목적, 수행 방법, 규칙과 절차 등의 비즈니스 로직(Business Logic)을 문서로 정리

    ex. 쇼핑몰 시스템을 구축하려면 회원 관리, 가격 책정, 배송 및 반품, 마일리지 체계 등의 업무부터 알아야 함

- 은행이나 증권사, 병원의 업무는 고도의 전문 지식이 필요해 실무자와 같이 분석.

​

3) 시스템 설계

​

- 설계 단계에서는 분석 문서를 참조하여 구현 방법을 결정

- 규모에 맞는 하드웨어와 소프트웨어를 선정하고 업무에 필요한 사물을 추출

- 비즈니스 로직에 따라 실세계의 사물을 테이블로 정의하고 관계를 설정하는 작업을 모델링이라고 함

  📌 모델링은 건축의 설계도에 해당. 구현 과정이 신속 정확하려면 모델링이 완벽해야 함

  📌 모델링은 일반화된 모범 답안이 없어 숙련된 노하우를 요하는 고급 기술

​

4) 프로그램 구현

​

- 모델링한 데이터를 테이블로 구체화하고 효율적인 운영을위한 인덱스, 프로시저 등을 정의하는 단계

- 데이터를 실제 사용하고 입출력하는 클라이언트 응용 프로그램을 개발하고 사용자를 위한 설명서와 유지/보수를위한 문서까지 작성

​

5) 유지보수

​

- 구현 완료한 프로그램을 실제 업무에 사용하는 단계

- 미처 예상하지 못한 문제나 버그가 발견되고 기능 개선요구도 발생할 수 있다.

- 현실 세계가 계속 변하기 때문에 개발 완료한 프로젝트도 지속적인 관리가 필요함

​

2.  데이터베이스 모델링

​

1) 개념

  - 현 세계에서 사용되는 작업이나 사물들을 DBMS의 데이터베이스 개체로 옮기기 위한 과정

  - 데이터베이스 모델링은 상당히 어려운 작업, 구현하고자 하는 업무에 대한 폭넓고 정확한 지식이 필요하기 때문

  - 일반적으로 모델링 담당하는 사람은 프로젝트 경험이 많거나 데이터베이스 관련 지식이 있는 사람

​

2) 데이터 베이스 모델링 분류

​

- 데이터베이스 모델링은 개념적 모델링, 논리적 모델링, 물리적 모델링으로 나눌 수 있다.

​

⚡️ 개념적 모델링은 주로 업무 분석단계에 포함

      ➡️ 비즈니스 개념과 규칙을 구성하고 범위를 지정하고 정의

⚡️ 논리적 모델링은 업무 분석의 후반부와 시스템 설계의 전반부에 걸쳐 진행

      ➡️ 규칙 및 데이터 구조의 기술 맵을 개발하는 단계

⚡️ 물리적 모델링은 시스템 설계의 후반부에 주로 진행

      ➡️ 데이터베이스의 실제 구현 단계

​

​

​

​

4.  관계

​

👩🏻‍🚀  각각의 엔티티는 독립적으로 존재하지 않고 업무적으로 서로 연관

   ⚡️ 고객은 상품을 주문하며 쇼핑몰은 주문받은 상품을 배송하는 것

👩🏻‍🚀  엔티티를 정의한 후에는 비즈니스 로직에 따라 엔티티간의 관계를 설정

👩🏻‍🚀  관계(Relation)는 엔티티간의 연결 형태이며 관계형 DB의특징을 결정하는 핵심이다.

   ⚡️ 관계는 양쪽 엔티티의 인스턴스 개수에 따라 1) 1:1관계 2) 1:다 관계, 3) 다:다 관계로 분류

   ⚡️ 반드시 연결해야 하는 필수 관계와 필요할 때만 연결하는 선택 관계가 있음

​

1) 1:1 관계

​

👾 1:1 관계는 양쪽 테이블의 인스턴스를 하나씩 연결

👾 1:1 관계의 현실적인 예는 엔티티의 정보가 너무 많아 테이블을 분할할 때

      ➡️ 필드가 많으면 보기에도 정신없고 레코드가 거대해져 성능도 떨어짐

      ➡️ 자주 참조하는 정보와 부가적인 정보로 분할하면 참조하지 않는 속성은 필요할 때만 읽으면 되니 성능이 향상됨

           ex. 회원 데이터의 경우 자주 사용하는 로그인 관련 정보와 상대적으로 사용이 적은 상세 정보를 분리

    ⚡️ 이때 두 테이블의 레코드끼리 짝을 찾을 수 있는 연결 고리가 필요

    ⚡️ 관계형 DB에서 레코드의 순서는 의미가 없어 순서로 연결 x

    ⚡️ 양쪽 테이블에 똑같은 키를 만들어 두면 연결 관계를 알 수 있는데 이런 용도로는 학번이 적합

           ➡️ 상세 정보를 알고 싶을 때 학생 테이블의 학번을 조사한 후 상세 테이블에서 학번이 같은 레코드를 참조

                ex. 김학생의 체중을 알고 싶다면 학번인 1234로 상세 테이블을 검색

                        두 테이블은 학번이라는 외래키로 연결되어 있음.

​

2) 1:다 관계

​

👩🏻‍🚀  가장 흔하게 존재하는 관계는 1:다 관계이며 부서와 직원의 관계가 대표적이다.

       ➡️ 직원은 한 부서에 소속되며 한 부서에는 여러 명의 직원이 있음

3) 다:다 관계

​

​

​

​

​



[ 내용 참고 : 책 '이것이 MySQL 이다' 및 IT 학원 강의 ]