Dao는 DB작업을 하므로 SQL 코드를 수행하는 이름으로 메소드 이름을 지어주는 것이 좋음
Service 쪽은 기능에 맞춰 메소드 이름을 지어주는 것이 좋음
Service가 트랜잭션을 관리하므로
res = -1 부분 확인하기
🔍 DB 설계 형태
- 개념적 설계 👉🏻 기획단계의 요구사항을 보고
- 개체에 대한 기본 모델링 👉🏻 엔티티 설계
- 테이블 종류 파악
- DBMS에 독립적으로 설계
✔ 특정 DB에 속하지 않는 설계 표현으로 작성하는 단계
- 논리적 설계
- 개념적 설계의 결과물을 개발에 적합한 DBMS 맞게 적용
✔ 선택된 DBMS구조에 맞게 DB구조(스키마)를 설계
정규화 과정을 거치면서 이상현상을 제거
- 물리적 설계
- DBMS에 맞는 테이블 실제 구조도를 완성
- 필드의 데이터타입, 인덱스, 테이블 제약사항 등등을 구현할 수 있게 작성
✔ DBMS로 구현 가능한 정도로 설계
➰ 엔티티의 구성 조건
- 업무 프로세스(프로그램)에 관련있는 대상(사물)이어야 함
- 2개 이상의 인스턴스(행)를 가지도록 구성해야 함
- 적당한 속성(컬럼)을 가지고 있어야 함 ➡ 이유들이 다 있어야지~
userno / userid 처럼 어떤게 pk인지 헷갈리는,,
➰ 속성의 명명 규칙
- 무리한 약어를 사용하지 않도록
- 서술하는 형식을 사용하지 않도록
- 엔티티 내에서 유일한 식별자가 되도록 지정
- 속성이 의미를 가지도록 단어를 정함
➰ 주 식별자(Primary Key)의 특징
- 유일성 : Unique, 중복값이 없어야 함
- 최소성 : 최소한의 데이터로 서로를 식별 가능해야 함
- 불변성 : 변하지 않는 값으로 지정
- 존재성 : NOT NULL, 어떤 상황에서도 데이터 값이 존재해야 함
🔍 DB 정규화, Database Normalization
| class | teacher | subject | stdno | stdname |
|---|---|---|---|---|
| A | alice | 과학 | 1, 2 | apple, banana |
| B | bob | 수학 | 3, 4 | cherry, durian |
| C | clare | 과학 | 5 | grape |
| D | alice | 과학 | 6 | mango |
- DB설계 결과에 따라 작성된 테이블에 중복된 데이터나 NULL 값이 포함되는 구조가 발생할 수 있음
- 중복데이터, NULL값 때문에
이상 증상(이상 현상)이 발생할 수 있음이상 현상, Anomaly: 테이블들이 공통으로 가지는 데이터 중 한 쪽 테이블에 DML(삽입, 수정, 삭제)이 적용되었을 때 공통 데이터를 가지는 모든 테이블에 똑같이 적용되지 않는 현상(문제점)
- 정규화는 6단계 형태로 나눔
- 제 1정규화, 제 2정규화,제 3정규화, BCNF, 제 4정규화, 제 5정규화
- 1 ➡ 5 정규화 순서로 진행
BCNF: 3 정규화와 비슷하지만 단점을 보완한 형태 👉🏻 있을 수도 있고 없을 수도 있음- BCNF 정규화까지 마치면 대부분의 테이블들은 정규화 작업이 완료됨
👉🏻 BCNF를 목표로 정규화 작업을 수행
➰ 1NF, First Nomal From, 제 1 정규화
각 행의 컬럼마다 1개의 데이터만 가지도록 만듬 👉🏻 원자성 확보
| class | teacher | subject | stdno | stdname |
|---|---|---|---|---|
| A | alice | 과학 | 1 | apple |
| A | alice | 과학 | 2 | banana |
| B | bob | 수학 | 3 | cherry |
| B | bob | 수학 | 4 | durian |
| C | clare | 과학 | 5 | grape |
| D | alice | 과학 | 6 | mango |
➰ 2NF, 제 2 정규화
- 기본키의 데이터가 특정 컬럼들의 기준이 됨
👉🏻 이때, 기본키가 아닌 다른 컬럼이 특정 컬럼의 기준이 되지 않도록 만듬 - 기본키 데이터가 특정 컬럼에만 종속되는 경우를 제거해야 함
- 부분적 종속 제거
완전 종속으로
class를 단독 PK로 두고싶음 👉🏻 PK가 행을 구분하는 기준 컬럼이 될 수 있는지 판단함
- PK로 가정한 class 컬럼이 teacher, subject에 종속되어있음
- PK로 가정한 class 컬럼에 stdno, stdname이 종속되어있지 않음
👉🏻 하나의 PK로 종속이 가능하도록
[PK에 종속된 부분 컬럼들]
| class | teacher | subject |
|---|---|---|
| A | alice | 과학 |
| A | alice | 과학 |
| B | bob | 수학 |
| B | bob | 수학 |
| C | clare | 과학 |
| D | alice | 과학 |
[PK에 종속되지 않는 부분 컬럼들]
| class | stdno | stdname |
|---|---|---|
| A | 1 | apple |
| A | 2 | banana |
| B | 3 | cherry |
| B | 4 | durian |
| C | 5 | grape |
| D | 6 | mango |
➰ 3NF, 제 3 정규화
- 기본키(PK)가 아닌 컬럼들끼리 종속되지 않도록 만듬
- 기본키가 아닌 일반 컬럼이 다른 컬럼을 결정할 수 없도록 테이블을 분할
stdname컬럼이 PK인 class 컬럼에 종속되지 않고 일반 컬럼 stdno에 종속됨
👉🏻 (class-stdno) 테이블, (stdno-stdname) 테이블로 분할하기
[class-stdno 테이블]
| class | stdno |
|---|---|
| A | 1 |
| A | 2 |
| B | 3 |
| B | 4 |
| C | 5 |
| D | 6 |
[class-stdname 테이블]
| stdno | stdname |
|---|---|
| 1 | apple |
| 2 | banana |
| 3 | cherry |
| 4 | durian |
| 5 | grape |
| 6 | mango |
➰ BCNF
- 3 정규화를 만족하는 경우 중에서 일반 컬럼이 PK의 특성을 방해하지 않지만 일반 컬럼이 다른 컬럼을 종속시키고 있을 때 진행
- PK인 class 컬럼은 각 행을 구분하는 역할을 잘 수행하고 있음 👉🏻 3NF 유형에 적합
- but, 일반 컬럼인 teacher가 PK를 방해하지 않는 선에서 subject 컬럼을 결정하고 있음
teacher는 1개의 subject를 가진다고 가정 - (class-teacher) 테이블, (teacher-subject)테이블로 분할
[class-teacher 테이블]
| class | teacher |
|---|---|
| A | alice |
| B | bob |
| C | clare |
| D | alice |
[teacher-subject 테이블]
| teacher | subject |
|---|---|
| alice | 과학 |
| bob | 수학 |
| clare | 과학 |
| alice | 과학 |
➰ 최종ver.
[클래스별 수강 학생 정보 테이블]
| class | stdno |
|---|---|
| A | 1 |
| A | 2 |
| B | 3 |
| B | 4 |
| C | 5 |
| D | 6 |
[학생 정보 테이블]
| stdno | stdname |
|---|---|
| 1 | apple |
| 2 | banana |
| 3 | cherry |
| 4 | durian |
| 5 | grape |
| 6 | mango |
[클래스 담당 선생님 테이블]
| class | teacher |
|---|---|
| A | alice |
| B | bob |
| C | clare |
| D | alice |
[선생님 과목 정보 테이블]
| teacher | subject |
|---|---|
| alice | 과학 |
| bob | 수학 |
| clare | 과학 |
| alice | 과학 |
🔍 프로그래밍 아키텍쳐, Programming Architecture
- 소프트웨어(SW) 아키텍처
- 프로그램을 작성하는 구조
- 프로그램의 내부 구성방식
- 프로그램을 구성하는 코드들을 기능별, 목적별로 분류하여 구현하는 것을 뜻함
- 프로그램을 설계하고 구현할 때 사용되는 개발 패턴, 개발 기술들을 아키텍쳐라고 함
- MODEL 1 방식 : 비지니스 로직과 프레젠테이션 로직 하나로 합쳐놓은 구조
- MODEL 2 방식 : 비지니스 로직과 프레젠테이션 로직을 둘 이상으로 분리해놓은 구조
➰ 비지니스 로직, Business Logic
사용자에게 보이지 않는 코드 영역 ➡ 기능
- 데이터를 처리(가공)하는 응용프로그램의 일부 영역
- 주로 데이터베이스 처리 작업을 수행
👉🏻 게시글 조회 결과를 DB에서 프로그램으로 가져오는 작업
➰ 프레젠테이션 로직, Presentation Logic
사용자에게 보여지는 프로그램 영역 ➡ 화면
- 출력될(보여질) 화면을 구성하는 응용프로그램의 일부 영역
👉🏻 게시글 조회 결과를 사용자화면(UI)로 구성하는 작업
➰ 모델 1 아키텍처, MODEL 1
비지니스 로직 + 프레젠테이션 로직을 하나의 묶음(클래스, 파일, 패키지)로 구현
👉🏻 main()메소드 하나로 데이터를 가공하고 화면 출력까지 다 하는 것
- 장점
- 프로그램을 구성하는 파일들의 구조가 단순하고 직관적
- 초기 개발이 쉬움
- 소형 프로젝트에 잘 어울리는 편
- 단점
- 프로그램 코드가 한 곳에 섞여있어 유지보수가 어려움
- 프로젝트의 적응력이 떨어짐
- 프로젝트의 변화에 즉각 반응하기 어려움
- 코드 재사용성이 떨어짐
- 대형 프로젝트에 어울리지 않음
- 분업이 힘듬
➰ 모델 2 아키텍처, MODEL 2
비지니스 로직과 프레젠테이션 로직을 서로 다른 파일(클래스)로 분리한 형태
- 분업하기에 적절하며 대형 프로젝트에 잘 어울림
- 코드 재사용성을 높여서 개발하게 됨
✔ 단, MODEL 2 개발방식에 대한 이해가 있어야 함
👉🏻 기본 지식의 요구수준이 높은 편
👉🏻 프로그램 구현 이전에 설계가 반드시 필요
🔍 디자인 패턴, Design Pattern
프로그램을 구현하거나 설계할 때 발생하는 문제점(issue)들에 대한 해답(해결법)들을 문서화 한 것
- 자주 마주치는 프로그래밍 문제들을 해결하는 노하우
- 잘 알려진 알고리즘의 구현 해결법들을 정리한 것
- 재사용성을 높여 작성된 프로그래밍 솔루션
SW 아키텍처에 대한 디자인 패턴도 존재 👉🏻 MVC 패턴
MODEL 2 기반의 MVC 패턴이 적용된 Spring Framework Web Application 구현
🔍 MVC 패턴
프로그램의 구조(아키텍처)를 크게 세 가지 파트(역할)로 구분하여 개발하는 방법
- Model, View, Controller 로 분류되는 아키텍처 컴포넌트들의 약자
- 웹 어플리케이션 개발에 MVC 패턴을 많이 적용
(JSP, PHP, ASP 웹 언어)
➡ 우리는 자바를 이용한 MODEL 2 기반의 MVC 패턴을 이용하여 개발
자바의 웹 어플리케이션 개발 API : Servlet/JSP
➰ Model 파트
프로그램의 데이터를 관리하고 처리하는 파트
👉🏻 비지니스 로직을 담당
- 데이터베이스와 연동하여 데이터를 처리하는 경우가 많음
- Service 컴포넌트, Dao 컴포넌트가 모델 파트에 해당
➰ View 파트
사용자에게 보여지는 화면을 구성하는 파트
👉🏻 프레젠테이션 로직을 담당
➰ Controller 파트
사용자의 입력을 처리, 프로그램의 흐름을 제어하는 파트
주로 사용자와의 상호작용을 하는 파트
