_soon.log

[스프링의 정석] - Spring MVC - 클라이언트 서버, HTTP 요청과 응답

Sun, 02 Apr 2023 13:08:50 GMT

원격 프로그램의 실행

브라우저에 URL을 입력한 후 호출하면 컴퓨터에 있는 WAS프로그램이 ip주소를 받아 실행한다.

로컬 환경이 아닌 외부에서 프로그램을 실행하기 위해서는 2가지 일을 해야한다.

프로그램 등록

URL과 프로그램을 연결

package com.fastcampus.ch2;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;

@Controller // 1. 프로그램 등록 public class Hello {

    @RequestMapping("/hello")  // 2. URL에 /hello를 호출하면 해당 main 메서드가 호출된다.
    public void main() {
            System.out.println("Hello");
    }

} // 브라우저 URL : localhost:8080/ch2

@Controller로 프로그램을 등록시켜줬으니 브라우저URL에 hello를 검색하면 main()메서드가 실행되어 main()메서드 안의 Hello가 호출된다.
이 때 main()메서드는 객체생성을 하지 않았지만, 톰캣에서 자체적으로 객체를 생성해주기 때문에 main()메서드의 호출이 가능하다.

## 클라이언트와 서버
---
> 
**클라이언트(client) : 서비스를 요청하는 애플리케이션 
    서버(server) : 서비스를 제공하는 애플리케이션**


### 서버의 종류
어떤 서비스를 제공하냐에 따라 달라진다.
Email Service를 제공하면 Email server고
File Service를 제공하면 File server고
browser를 이용한 모든 Service를 제공하는게 Web server다.

### 서버의 포트
1대의 PC에 여러가지 서버를 제공할 수 있는데, 포트번호를 통해 구분한다.
ip주소 뒤에 prot번호를 적으면 어떤 서버로 요청할건지 구분한다.
`ex`
111.22.33.44:25 `25` -> Email server
111.22.33.44:22  `22` -> File server
111.22.33.44:80  `80` -> Web server

### 웹 애플리케이션 서버(WAS)란?
웹 애플리케이션을 서비스하는 서버
**서버에 모든 프로그램을 설치해서 클라이언트가 프로그램을 사용할 수 있게 해준다.**

**📌 WAS에 프로그램을 설치하면 한곳에서 update를 하고 클라이언트의 설치용량도 필요없기 때문에 클라이언트에 프로그램을 설치하는 것보다 효율적이다.**

### Tomcat의 내부 구조
Tomcat Server안에는 Service가 있고, 그 서비스를 처리하는 것이 Engine(Catalina)이다.
Engine안에는 여러개의 Host가 존재하고, Host안에는 여러개의 Context가 있다. `Context는 Spring Project를 의미`
Context안에 있는 Servlet은 Controller로 생각할 수 있다.
요청이 들어오면 Server(Tomcat)안에 Thread Pool이 대기하고 있다가 한가한 Thread가 도맡아 작업한다.

![Tomcat내부구조](https://user-images.githubusercontent.com/103868639/229182545-bbfb1038-8872-482f-afea-875e6ca872e9.png)

### Tomcat의 설정파일 - server.xml, web.xml
- 톰캣설치경로/conf/server.xml  : Tomcat 서버 설정 파일
- 톰캣설치경로/conf/web.xml     : Tomcat의 모든 web app의 공통 설정
- 웹앱이름/WEB-INF/web.xml    : web app의 개별 설정

공통 설정을 먼저 한 후에 개별 설정을 한다.

## HTTP요청과 응답
--- 
### HttpServletRequest
- 웹 브라우저에서 URL을  입력 후 요청 → 톰캣이 HttpServletRequest객체 생성 후 URL 요청 정보를 담고 → main()의 매개변수로 넘겨준다.
우리는 request객체를 이용해서 요청정보를 알 수 있다.

### HttpServletRequest의 메서드

![HttpServletRequestMethod](https://user-images.githubusercontent.com/103868639/229183747-6fce9a34-6dbe-432d-930a-253c473e5885.png)
getQueryString()은 값을 전달할 때 사용한다.
![getQueryString](https://user-images.githubusercontent.com/103868639/229184043-6a12edf5-0f74-467f-8ab0-e0c5f58fe74a.png)
&은 구분자로 사용하고 year=2021이, month=10, day=1이 저장된다.

### 서버가 제공하는 리소스에는 2가지가 존재한다.
1. 동적 리소스
: 실행하는 프로그램, 스트리밍

2. 정적 리소스
: 이미지 *js, *.css, *html 등등




### 프로토콜(protocol)이란?
> 
- **서로 간의 통신을 위한 약속 규칙**
- **주고받을 데이터에 대한 형식을 정의한 것**


### HTTP(Hyper Text Transfer Protocol)란?
>
- **텍스트를 전송하기 위한 프로토콜 약속이다.**
- **단순하고 읽기 쉽다.**
- **상태를 유지하지 않는다. (stateless) - 같은 클라이언트에서 요청이 와도 알지 못함. 클라이언트의 정보를 저장하지 않음**
- **쿠키와 세션을 사용해 이를 보완한다.**
- **확장 가능하다. - 커스텀 헤더(header) 추가 기능, 우리가 원하는 대로 추가가 가능하다.**


### HTTP 메시지
브라우저에 URL을 입력해서 전송하면 요청 메시지가 서버로 전달된다.
```html

GET/ch2/hello HTTP/1.1
Host : 111.22.33.44.8080
Connection:keep-alive
Cache-Control:max-age=0
Accept-Encoding:gzip, deflate, br

서버는 요청을 받고 응답 메시지를 전송한다.


GET/ch2/hello HTTP/1.1
Host : 111.22.33.44.8080
Connection:keep-alive
Cache-Control:max-age=0
Accept-Encoding:gzip, deflate, br

HTTP 메시지 - 응답 메시지 형식

HTTP/1.1 200 OK  
Content-Length : 44
Content-Type : text/html
Date : Sat, 20 Oct 2021 19:03:38 GMT   



Hello

상태코드	의미
1XX	Informational
2XX	Success 성공
3XX	Redirect 다른 URL요청
4XX	Client Error 클라이언트 에러
5XX	Server Error 서버 처리중 에러

HTTP 메시지 - 요청 메시지


GET/ch2/getYoil?year=2021&month=12&day=1 HTTP/1.1
Host:111.22.33.44:8080
User-Agent:Mozilla/5.0(Windows NT 10.0)
Accept:text/html
Connection:keep-alive

쿼리스트링에 데이터를 직접 입력해서 보낸다. 바디에 첨부 X 리소스를 요청해서 데이터를 얻어오기 위함이며, read 읽기 전용


POST/ch2/getYoil HTTP/1.1
Host:111.22.33.44:8080
User-Agent:Mozilla/5.0(Windows NT 10.0)
Accept:text/html
Connection:keep-alive


year=2021&month=12&day=1

바디 부분에 데이터를 저장해서 서버로 보낸다. write글쓰기, 로그인, 회원가입, 파일첨부 등에 많이 사용

HTTP 메서드 - GET, POST

GET	POST
. 서버의 리소스를 가져오기 위해 설계	. 서버에 데이터를 올리기 위해 설계
. Query String을 통해 데이터를 전달 (소용량)	. 전송 데이터 크기의 제한이 없음 (대용량)
. URL에 데이터 노출되므로 보안에 취약함	. 데이터를 요청 메시지의 body에 담아 전송
. 데이터 공유에 유리	. 보안에 유리, 데이터 공유에는 불리
ex. 검색엔진에서 검색단어 전송에 이용	ex. 게시판에 글쓰기, 로그인, 회원가입에 사용

텍스트 파일 vs 바이너리 파일

바이너리 파일 : 문자와 숫자가 저장되어 있는 파일 텍스트 파일 : 문자만 저장되어 있는 파일, 사람이 읽기가 쉽다.

파일 종류	쓰기	읽기
바이너리	문자 → 문자 숫자 → 숫자	문자 → 문자 숫자 → 숫자
텍스트	문자 → 문자 숫자 → 문자	문자 → 문자 ~~문자 → 숫자~~

MIME ( Multipurpose Internet Mail Extensions )

텍스트 기반 프로토콜 바이너리 데이터이미지, 동영상를 전송하기 위해 고안한 것이다. HTTP의 Context-Type헤더에 사용한다. 데이터의 타입을 명시하는 것

Base64 - 64진법

바이너리 데이터를 텍스트 데이터로 변환할 때 사용 64진법은 ‘0’~~’9’, ‘A’~~’Z’, ‘a’~’z’, ‘+’, ‘/’ 모두 64개의 문자로 구성 26 + 26 + 10 + 2 = 64개 ( 6bit )의 문자로 구성

[핵심 데이터 모델링] - 물리 모델링

Sat, 18 Mar 2023 15:13:27 GMT

물리 모델링이란

📌** 논리 모델링 결과를 실제 업무에서 사용할 수 있게 바꾸는 것 성능이 제일 중요하다. 성능이 안좋으면 역정규화도 진행함**

** 물리 모델링은 논리 데이터 모델을 DB종류에 맞게 데이터를 저장할 수 있는 테이블 구조로 변환하는 과정이다.**
엔티티 및 서브타입을 테이블로 변환하고, 속성을 컬럼으로 변환해 데이터타입 및 길이를 지정

테이블 설계

📌 관계형 모델에서는 논리 데이터 모델을 테이블로 변환한다. 엔티티 -> 테이블 속성 -> 컬럼

테이블명은 엔티티명을 참고해 작성한다.
- 주제영역 약어와 엔티티명의 표준 영문 약어를 조합해서 만들거나
- 대, 중, 소 주제영역 약어와 일련번호를 조합해 만든다.
테이블은 로우Row와 컬럼Column으로 구성되며. 가장 기본적인 오브젝트이다. DB내 모든 데이터는 테이블에 저장되며, 로우행 or 컬럼열 방식으로 저장된다.

테이블에선 슈퍼타입/서브타입 구조를 직접 표현할 수 없다. 통합해서 설계하거나, 각각 엔티티를 각각의 테이블로 설계한다.

슈퍼타입 기준 테이블 설계
서브타입 엔티티를 -> 슈퍼타입 엔티티로 통합해 테이블 설계
순서..는 그냥 그림으로 설명한다.
주의할점
- 슈퍼타입 엔티티에서 공통으로 관리하는 속성이 많고, 서브타입이 몇개 없거나 속성이 많지 않을 때 사용
- 고객유형코드에 해당하는 경우만 주민등록번호 또는 법인등록번호 값이 있으므로 Not Null을 지정할 수 없다
  - 경우에 따라 인덱스도 각각 추가해야 한다.
    서브타입 기준 테이블 설계
슈퍼타입 속성 -> 서브타입으로 내려 서브타입 단위로 테이블을 생성
슈퍼타입 엔티티에 연결된 관계 대신 서브타입 엔티티에 관계를 추가
슈퍼타입 엔티티를 삭제하고 서브타입 엔티티에 테이블명을 준다.
주의할점
- 서브타입 엔티티 속성들이 명확히 구분되어야 한다.
- 전체 집합을 데이터 처리 시 두 집합을 UNION ALL 해야하고, 다른 테이블과 관계가 있으면 개별 서브타입에 관계를 추가해야한다.
- 이처럼 여러 테이블을 처리해야 한다면 프로그램이 복잡해진다.
  슈퍼타입/서브타입 테이블 설계
슈퍼타입과 서브타입 엔티티를 개별 테이블로 설계 -> 테이블 명을 부여하는 방식
슈퍼타입, 서브타입 테이블은 1 : 1 관계로 정의한다.
전체 데이터에 대해 공통적인 속성을 처리할 경우 -> 슈퍼타입 테이블을 읽어서 처리하고, 서브타입 테이블에서 관리하는 데이터를 화면에서 상세조회하는 경우 -> 서브타입 테이블을 읽어 처리한다. ex 고객이 보험에 가입한 보험 목록을 조회 -> 슈퍼타입 테이블 조회, 특정 보험계약을 선택할 경우 -> 서브타입 테이블 상세정보 조회

관계 설계

관계는 기본적인 관계, 상호배타적 관계, 순환 관계로 나눌 수 있다.

기본적인 관계
부모 테이블의 PK를 -> 자식테이블 PK나 FK로 상속받는다.

상호배타적 관계

DBMS는 상호배타적 관계를 지원 X
- 논리적인 상호배타적 관계를 DBMS가 수용할 수 있도록 테이블을 설계해야함
- 설계방법은, 1. 한 컬럼으로 통합하는 방법과 2. ~~개별 컬럼으로 분리하는 방법~~이 있다.
  - 분리하는 방법은 논리적 구조와 물리적 구조가 다르고, 프로그램이 복잡해져 되도록 통합해 설계한다.
자식 테이블 컬럼 통합/분리 설계
통합하는 방법은 관계에 참여한 모든 관계를 동일한 컬럼고객번호으로 변환하고, 별도 구분 컬럼고객유형코드을 추가해 구분한다.
분리하는 방법은 개별 컬럼개인번호/법인번호/단체번호으로 변환하고, 구분컬럼고객유형코드을 추가해 구분한다.
- 해당 관계에 대해 FK설정할 수 있으나, Not Null을 지정할 수 없고, 개별 컬럼마다 인덱스를 생성해야하는 단점이 있다.

관계 옵셔널리티 확정

논리 모델링 단계에서 정확하지 않거나, 모호하게 설계한 옵셔널리티를 검토하여 확정한다.
부모, 자식 엔티티가 Mandatory 관계인 경우 : 테이블에 데이터가 입력되는 시점을 기준으로 결정
- 부모 테이블에 데이터가 입력되면 자식 테이블도 동시에 입력된다.
자식 엔티티와 Optional 관계인 경우 : 부모 테이블 PK데이터가 자식 테이블에 없어도된다.
- 자식 테이블에 데이터가 입력될 때 부모 테이블에 해당 데이터가 이미 존재햐아 한다.
양쪽 엔티티가 Optional인 경우 : 부모 테이블 데이터가 없는 상태 -> 자식 테이블에 데이터가 발생하는 유형
- 나중에 부모 테이블에 데이터가 생성되면서 자식 테이블 참조 FK를 변경한다.

컬럼 설계

논리 데이터모델의 속성에 대해 표준용어, 표준단어, 표준도메인을 적용하는 작업이 끝

속성-컬럼 변환

일반적으로 논리 모델에서 정의한 속성은 거의 그대로 사용한다.
💡 시스템에서 데이터에 대한 변화를 추적하고, 트랜잭션을 관리하기 위해 시스템 컬럼을 추가할 수 있다.
- 최초등록일시, 최초등록자식별번호, 최종수정일시, 최종수정자식별번호 컬럼이 해당한다.
- 시스템 컬럼은 모든 테이블에 공통적으로 추가하며 테이블 가장 마지막에 위치하도록 한다.

데이터 타입 및 길이 지정

컬럼에 대한 데이터 타입 지정 관련해 몇 가지 살펴볼 이슈가 있다.
이슈 1 : CHAR고정길이, VARCHAR2가변길이중 어느것을 적용할 것인가? 고정 길이의 경우 CHAR로 하는게 좋을꺼 같지만, 빈칸을 공백으로 채우고, 값을 비교하는데 어려움이 있다. 혼용해서 사용하면 내부적인 형 변환등의 문제도 발생할 수 있다. 성능은 그리 고려할 필요는 없다. CHAR이 크게 나은 점도 없다. 결론은 그냥 VARCHAR2만 사용하는게 좋을 듯 하다.
이슈 2 : 일자YYYYMMDD컬럼을 VARCHAR2(8)로 할지 DATE형으로 할지에 대한 고민 데이터 타입을 정하는데 데이터 품질을 우선으로 할지 개발 생산성과 성능을 고려할 것인지도 고민된다. VARCHAR2(8)은 개발자들이 선호하지만 날짜가 아닌 데이터가 유입될 수 있고 날짜형 데이터 타입은 날짜를 문자형식으로 변환하는 일이 많아 생산성이 ↆ 되지만 오류 데이터가 들어올 가망은 거의 없다.(시분초까지 하면 오류가 입력될 여지는 있음) 품질이 우선이면 → DATE형, 생산성이 우선이면 → VARCHAR2(8) ＊CARCHAR2(8)로 한다면 제약조건을 추가하거나, 인덱스를 만들어 오류 데이터가 입력되는걸 방지한다.
```
alter table emp add constraint emp_ck_ent_dt
check (ent_dt = to_char(to_date(ent_dt, 'yyyyMMdd'), 'yyyyMMdd' ));
또는
create index emp_ix01 on emp( to_date(ent_dt), 'yyyyMMdd') );

insert into emp values('20190230');
-- ORA-01839 : date not valid for month specified
```

기본키(PK : Primary Key) 지정

📌 기본키는 Not Null 이어야 하고, Unique 해야한다.

논리 데이터 모델의 주 식별자를 기본키PK로 생성한다.
자체 컬럼으로 구성하는 경우 핵심 엔티티, 중요 엔티티에 해당하는 테이블이고, 데이터에 대한 일정한 채번규칙을 가지고 있어야 한다.
부모 테이블에서 상속받는 경우는 상속받은 컬럼에 숫자형 데이터타입을 가지는 일련번호 컬럼을 추가하는게 일반적이다.
다른 테이블들의 키로만 구성된 테이블은 교차 or 매핑 성격의 데이터를 가지는 테이블이다. 참조하는 컬럼과 동일한 데이터 타입과 길이로 정의한다.
- 다만, 기본키는 조회조건에서 가장 많이 쓰는 컬럼 순으로 구성하고, 값의 종류가 많은 컬럼이 먼저 오도록 구성한다.

데이터 무결성 설계

일관성 (Consistency) : 내 계좌에 100원이 나가면 상대방 계좌에 100원이 추가됨 무결성 (Integrity) : 제약조건으로 이상한 데이터가 들어오면 안된다.

데이터 무결성은 데이터를 저장하고 관리할 때 데이터의 정확성과 일관성을 유지하기 위해 정의한 규칙이다.
데이터 무결성은 아래 3가지가 있다.

실체 무결성 (Entity Integrity)
영역 무결성 (Domain Integrity)
참조 무결성 (Referential Integrity)

실체 무결성(Entity Integrity)

실체 무결성은 기본키PK와 관련된 제약조건으로 식별자 값은 Not Null, Unique 이여야 한다.

create table emp (
        emp_no   varchar2(6)   not null,
        emp_nm   varchar2(50)  not null, 
        brth_dt  varchar2(8) 
);
alter table emp add constraint emp_pk primary key (emp_no) ; 
alter table emp add constraint emp_uk unique (emp_nm, brth_dt) ;

영역 무결성(Domain Integrity)

데이터의 속성 값들은 정해진 데이터 범위를 벗어나지 않아야 하고, 데이터 타입, 길이, 유효값을 유지해야 한다.

Check, Default, Not Null 제약조건에 해당

create table emp (
        emp_no   varchar2(6)   not null,
        emp_nm   varchar2(50)  not null, 
        brth_dt  varchar2(8) ,
        reg_dtm  date          default sysdate not null
);
alter table emp add constraint emp_ck_brth_dt
check (brth_dt = to_char(to_date(brth_dt, 'yyyyMMdd'), 'yyyyMMdd'));

insert into emp values('000001', '홍길동', '20190231', sysdate); -- ORA-01847 : day of month must be between 1 and last day of month;

- 등록일시`reg_dtm` 데이터를 입력하지 않았을 경우 기본값을 sysdate, default로 지정된다.
    생년월일`brth_dt`은 문자형 데이터 타입이지만 check 제약조건을 통해 `yyyyMMdd` 날짜 형식 데이터가 아닌 경우 오류를 발생시킨다.
    2월 31일은 없는 날짜이므로 입력될 수 없다.

### 참조 무결성(Referential Integrity)
- 참조 무결성은 데이터 모델에서 정의된 실체 간의 관계조건을 유지하는 것
- 참조하는 테이블은 참조할 수 없는 외래 키`FK`를 가져갈 수 없고, 참조되는 테이블은 외래키가 존재하는 한 데이터를 삭제하거나 변경할 수 없다. FK제약조건에 해당
```sql
alter table emp add constraint emp_fk FOREIGN KEY (dept_cd)
    references dept(dept_cd) on delete set null ;

insert into emp(emp_no, dept_cd) values('000002', '0002');
-- ORA-02291 : integrity constraint violated - parent key not found

부서dept 테이블에 존재하지 않는 부서코드0002를 사원emp테이블에 입력할 경우 FK 제약조건에 걸려 오류 발생
FK 제약은 확실하고 간편한 방법이지만 성능적인 측, 관리적은 측면도 고려해야 한다. 보통은 FK를 설정하지 않고 개발한다음 나중에 개발이 마무리되면 FK를 설정한다.

성능을 고려한 데이터 구조

물리 모델링 단계에서 대량의 자주 데이터를 처리하거나, 특정 범위를 자주 처리하는 경우는 확인하여 테이블을 설계해야 한다. 필요할 경우 집계 테이블을 추가하는 정도?

집계/요약 테이블 추가

대량의 데이터를 실시간으로 읽어, 집계하고 처리할 경우 집계 테이블을 추가할 수 있음
- 성능적인 문제를 해결하면서 다양한 집계처리를 포함하고, 공통된 조건을 분석해 테이블을 설계한다.
- 배치 처리/작업 : 월간 데이터를 실시간이 아닌 월말이나 초에 정리하고 전월처리로 계산한다.

컬럼 추가

정규화를 잘 했으면 컬럼 중복으로 인한 오류 데이터 유입을 최소화 할 수 있다.
성능 문제 때문에 정규화를 일부 포기하고 반정규화 하거나 중복 컬럼을 추가해야 하는 경우도 있다. 적당한 타협선이 필요하다.
부모 테이블에서 인조 식별자를 기본키로 설계한 경우 기본키를 상속받으면서 본질 식별자에 해당하는 컬럼을 추가하거나, 자주 조회 조건으로 사용하는 컬럼을 자식 테이블에 추가하는 경우가 대표적이다.
부모 테이블에 컬럼을 추가하는 경우도 있다. 부모 테이블에서 자식 테이블의 집계된 값이나 최종 데이터 값을 가지고 있다면, 매번 자식 테이블에서 최소/최대, 건수/합계, 등 최종 데이터 값을 추출할 필요가 없으므로 성능이 향상된다.

테이블 분할

테이블은 컬럼가로과 로우세로로 구성되어 있고, 데이터를 처리할 때 가로 세로 면적이 처리범위가 된다. 면적을 줄이기 위해 가로, 세로를 줄이는 방법이 있다.

테이블 수직분할 : 가로를 줄이는 방법으로 테이블의 컬럼을 두 개 이상의 테이블로 나눠 관리하는 방법

  **1 :1 구조로 나누는 이유? : 성능과 보안 때문**
  `ex` 게시판 테이블
  게시물내용 컬럼은 아주 많은 문자가 입력되므로 게시판 데이터의 대부분을 차지한다.
  보통은 게시물 목록을 보여주고, 게시물 선택 시 → 게시물 내용 확인 순이다.
  게시물 목록 조회시 데이터는 가져오지 않지만, **컬럼이 포함되어 있어 불필요하게 큰 데이터를 처리할 수 밖에 없다.**
  이와 같이 사용하는 컬럼들끼리 묶어 다른 테이블로 분리하면 성능 향상에 도움이 된다.
  ![테이블수직분할](https://user-images.githubusercontent.com/103868639/225971781-ad3af109-3878-4391-8a56-61427a56d941.png)

물리 설계

물리 모델링 이후 DBMS 특성을 고려해 성능, 관리, 보안, 개발 생산성의 목적에 맞게 물리적인 설계를 한다.
프로젝트에서 주로 사용하는 DB오브젝트는 테이블, 인덱스, 뷰읽기전용, 시노님object 별명, 함수반환값O, 프로시저반환값X, 시퀀스 등이 있다.
테이블, 인덱스, 시노님은 설계 단계에서 DA/DBA가 설계하고, 뷰, 함수, 프로시저, 시퀀스는 개발 단계에서 개발자가 직접 생성하거나 DBA에게 요청한다. 데이터를 저장하고 관리하는 오브젝트는 테이블과 인덱스 등이 있다.

오브젝트 명명 규칙

테이블, 뷰, 시퀀스, 함수, 프로시저 등은 명명 규칙에 따라 영문 약어 및 일련번호 등을 조합하여 부여한다.
- ex TCM_CUST (테이블), VCM_CUST (뷰), SCM_CUST_NO_01 ( 시퀀스), FCM_CUST_NM (함수), PCM_CUST_DEL (프로시저)

[핵심 데이터 모델링] - 논리 모델링

Tue, 14 Mar 2023 12:31:56 GMT

논리 모델링이란?

📌 개념 모델링의 내용을 구체적으로 정의한다

비즈니스에서 필요로 하는 데이터를 명확하고 구체적으로 정의하는 과정
핵심 엔티티를 중심으로 업무에 필요한 하위 엔티티로 확장하면서 상세화 한다.
엔티티를 정의하고 관계를 명확히 하되, DBMS의 물리적인 특성까지 고려할 필요 X

방법

기초 논리 데이터 모델 설계
- 주제영역별 핵심 엔티티 도출
- 엔티티간 주요 속성 도출

논리 데이터 모델 설계
- 업무영역에 필요한 데이터 모델을 설계
- 시스템 관점 데이터는 반영 X
- 이력관리에 대해 꼭 관리할 필요가 있는지 반영해야함

엔티티 정의 및 상세화

핵심 엔티티 (Key Entity, 기준정보)

유형 및 분류 (Type & Category) : 각종 코드 정보, 데이터 집합을 유형화 하거나 계층적으로 분류하는 정보 ex 고객유형코드, 상품분류코드 등 각종 코드정보
업무규칙 및 지식 (Rule & Knowledge) : 업무처리를 위한 각종 규정과 지식 ex 직급별 연봉, 보험료 조건, 지역별 담당자
업무주체 및 대상 (Subject & Object) 핵심 엔티티 : 비즈니스 이벤트의 주체 또는 대상 ex 부서, 사원, 고객, 상품
장소 (Where) : 비즈니스 이벤트가 발생하는 장소. ex 물류창고, 공장, AS센터, 도로, 채널, 지역, 좌표 등등

중요 엔티티 (Main Entity, 업무기본)

업무 주체 고객, 직원 와 업무 대상상품 간의거래나 업무 행위에 의해 발생함
주문, 약정, 입출고 처럼 구별 가능한 업무 행위를 대표하는 엔티티

행위 엔티티 (Action Entity, 업무상세)

업무 행위에 대한 상세내역 및 업무 결과에 대한 상태를 나타내는 엔티티
- 상세 / 내역 - 주문 내역, 예산 내역처럼 항목 단위로 분류하거나, 더 작은 단위로 세분화한 엔티티
- 상태 - 시간의 간격을 두고 업무 단계별로 담당자가 처리하는 흐름
  - 시간의 흐름에 따른 정보의 상태, 내용 변경 면에서 이력 엔티티와 유사할 수 있다. but 이력 : 시간이 흐름에 따른 정보 변경, 상태 : 업무처리 흐름에 대한 상태 관리
- 이력 - 변경 전 데이터를 추가로 관리하는 엔티티
  - 이력관리가 필요한지 확인해 볼 필요는 있다.
- 이력관리
  - 전체 항목 이력관리 : from ~ to 방식, 기간을 작성
  - 점 이력 관리 : 변경 시점시작시점만 관리한다. ex 대출같이 언제 빌려갔는지는 점이력으로 관리한다.
  - 선분이력 관리 : 시작시점과 종료시점을 같이 관리한다. ex 가격은 계속 변하기 때문에 from ~ to 선분이력으로 관리 변경이 발생했을 때 이전 이력 '변경종료일자' -> ('99991231' -> '20190430')로 Update하고, 새로운 이력에 변경시작일자 ('20190501') 과 변경종료일자 ('99991231') 구간으로 관리한다.

엔티티 도출 및 식별

데이터를 분석하여 엔티티로 구체화하는 과정
현행 데이터 모델이 있는 경우, 불필요한 업무나 기능과 관련된 테이블을 식별 후 삭제 : 이미 그려진 그림을 지우는 건 생각보다 어렵다.
작업이 어느정도 마무리되면 현업과 인터뷰 전에 엔티티명, 관계선, 속성명을 정리하는 것이 좋다.

엔티티 명명

엔티티명은 테이블 내에서 유일하게 부여하며, 데이터를 가장 명확히 표한할 수 있도록 작성한다.
너무 길지 않아야 하고, 구체적인 용어를 사용하는게 좋음
유사한 엔티티를 별도로 설계한 경우 주제영역이나 수식어를 붙여서 구분한다. ex 여신과 수신업무에서 '계좌'를 정의한 경우 여신계좌, 수신계좌로 명확히 구분 여신:대출업무, 수신:예금업무

엔티티 명명규칙

엔티티 명은 단수형 명사를 사용한다. ex 고객, 부서, 상품, 주문, 계약
엔티티 범위와 내용을 정의하기 위해 수식어를 사용한다. ex 주소 -> 고객주소, 입급내역 -> 계약입금내역
교차 엔티티는 양쪽 엔티티명의 조합을 기본 이름으로 한다. ex 계약 + 상품 -> 계약상품
낱 단어는 정확한 의미를 파악하기 어려우므로 아주 예외적인 경우를 제외하고는 사용 X ex 고객별실적 -> 고객단위실적, 예산계획및실적 -> 예산계획실적
한글과 알파벳 대문자를 사용, 숫자, 언더바를 허용 O 띄어쓰기, 특수 문자 허용 X

관계 도출 및 정의

속성 도출 및 정의

모든 속성을 도출하고, 속성명, 성성정의, 설명, 필수여부, 데이터타입 등을 정의해야 함

속성 도출

요구사항이나 현행 ERD 등 엔티티를 도출하고 식별하는 과정과 유사함

식별자 지정

식별자는 유일하게 식별 가능하고, 최소 속성으로 구성, 변하지 않으며, 반드시 존재하는 값이어야 함
식별자는 존재하는 속성에 따라 본질 식별자와 대체보조 식별자로 구분한다.
본질식별자 : 엔티티에 원래 존재하는 속성으로 구성된 식별자 ex 사원 엔티티의 사원번호, 주민등록번호 아닌 경우도 있다.
ex 업무처리나 이벤트 성격의 데이터인 회원ID, 계좌번호
인조식별자는 결재번호처럼 결재를 보고할 때 본질식별자(사원번호 + 보고날짜) 대신 인위적으로 부여한 일련번호 형식의 식별자를 의미

인조식별자를 정의하는 경우

논리 데이터 모델은 업무 변경에 유연하게 대응하고 확장성을 가져야 한다.
서로 다른 본질 식별자를 가진 엔티티를 통합할 때 본질식별자를 그대로 사용하면 구조가 복잡해지고 데이터 값이 없는 경우도 발생함
인조식별자를 사용하면 식별자를 변경할 가능성이 낮아지고, 설계 변경을 최소화할 수 있어 유연하고 확장 가능한 모델을 설계할 수 있음

📌
식별관계 : 다른 table의 PK를 내 PK로 가져오는것 요약 : FK면서 PK FK : 다른 테이블의 PK*
식별관계 중 키가 많아지는 걸 방지하기 위해 없는 키를 생성하는데 이게 인조키다.

도메인 및 데이터타입 지정

📌 도메인 : 속성들이 가질 수 있는 값의 범위 속성 : 테이블을 구성하는 컬럼, 속성은 값을 얻는다. 예) 고객 엔티티의 속성은? 이름, 연락처, 주소, 가입일, 등등...

속성에서 도메인을 지정하거나, 데이터타입을 지정하여 속성이 가질 수 있는 데이터 값의 범위를 정의한다.

옵셔널리티(Not Null) 지정

엔티티에 데이터가 입력될 때 속성 값을 반드시 입력해야할 경우 Mandatory(필수, Not Null)지정
값을 가지지 않아도 되는 경우 Optional(선택, Null)로 지정

데이터 표준화

데이터에 대한 명칭과 의미를 정하고 활용하는 데이터에 대한 형식 및 범위를 규정하는 활동
구성원이 같은 용어를 동일한 의미로 사용하기 위함

단어 표준화

표준단어사전 < 블로그 참조

코드 표준화

업무에서 통계를 내거나 한정된 데이터 값을 목록화하여 관리하고자 하는 대상을 코드로 식별하여 정의
코드는 공통코드로 통합하거나, 개별 테이블 형태로 관리(목록성 코드라고 함)한다.
코드 표준화 대상은 목록성 코드와 공통코드 모두를 포함한다.
코드사전
코드 사전은 코드에 대한 코드유형ID, 코드유형명, 코드, 코드명 등을 정의
업무에서 동일한 의미로 사용하는 코드는 최대한 통합하여 단일 코드유형으로 정의 ex 거래은행("한국은행", "기업은행"), 이체은행("산업은행", "국민은행")이 있다면 은행("한국은행", "기업은행", "산업은행", "국민은행")으로 통합할 수 있음
여기서, 특정 업무에서 은행코드 중 일부만 사용한다고 하면, 코드유형ID를 별도로 등록 가능
- but 이 경우도 코드는 001(한국은행), 002(산업은행) 등 동일하게 부여하는게 좋다.
- 분류형 : 코드를 대/중/소 분류체계로 계층을 나누고, 상위 코드에 코드를 추가하는 방식
  - 코드 구성에 의미를 두어야 함, 직관적이나 코드 추가, 재분류시 관리하기가 어려움
  - ex 농업 : 01, 작물 재배업 : 001, 곡물 밑 식량작물 재배업 : 0111, 축산업 : 012
- 일련번호형 : 의미없이 순차적으로 일련번호를 부여하는 방식
  - 코드 추가 시 반영이 쉽다.
  - ex 고객유형, 개인 : 01, 법인 : 02, 기타 : 99
약어형 : 성별코드처럼 약어를 그대로 사용하는 방식
- 코드만 보고 무슨 데이터인지 알 수 있게 직관적으로 작성해야 함
- ex 성별, 남자 : M, 여자 : F
차용성 : 업무에서 사용하는 코드를 그대로 쓰는 방식
- 업무적으로 통용되는 코드나, 인터페이스를 위해 사전에 정한 코드를 사용함
- ex 은행코드, 한국은행 : 001, 산업은행 : 002, 기업은행 : 003
'사용여부', '사용유무'는 두가지 값을 가지며 Y/N, 1/0 처럼 코드로 관리하는게 좋다.

[핵심 데이터 모델링] - 개념 모델링

Mon, 13 Mar 2023 12:00:55 GMT

개념 모델링

📌 ** 개념 및 업무를 파악하는 용도로 사용함** ** 데이터를 식별하고 모형화 해 하나의 엔티티와 속성들로 표현하는 방식 **

데이터 모델링 접근 방법

하향식(Top-Down)
- 데이터를 업무 담당자별로 개념을 식별해 정의하는 방식
  - 개념 모델링 → 논리 모델링 → 물리 모델링 순
  - 큰 규모의 프로젝트나 업무별 담당자가 있을 경우 진행
  - 장점 : 현업과 의사소통을 해가면 진행 → 결과물에 대한 의견 일치
상향식(Bottom-Up)
- 작은 규모의 프로젝트나, 현업의 참여가 한정된 경우,
- 기존 ERD, 보고서, 매뉴얼, 업무지침서를 통해 모델링 진행
  - 주의 사항 : 모델링 과정을 관련자와 공유하면서 진행해야 설계 변경을 줄일 수 있다.
- 데이터를 업무 담당자 별로 개념을 식별해 정의하는 방식

데이터 모델링 순서

분석
1. 현행 분석
  1. 현행 업무 분석(AS-IS) 기존ERD가 있는지 확인
  2. 현행 데이터 분석
2. 요구사항 정의 (AS-IS ~ TO-BE 방식으로 어필)
3. 방향성 수립 (TO-BE)
설계
1. 개념 모델링
  1. 주제영역 정의
  2. 핵심엔티티 정의
2. 논리모델링
  1. 엔티티 정의
  2. 관계 정의
  3. 속성 정의
3. 물리 모델링 도메인, Type, PK, Not Null
  1. 테이블 설계
  2. 무결성 설계
  3. 인덱스 등 설계
데이터 표준
주로 관리해야 될 필요성이 있는 객체를 표준화 한다.
- 표준 단어 : 표준 단어를 관리함으로써 동일한 개념을을 의미하는 용어가 중복되지 않게 예방
- 표준 용어 : 업무적으로 사용하는 용어에 대한 표준을 정의해 용어 사용에 혼란을 방지함
- 표준 도메인 : 데이터 타입과 자릿수가 같은 것을 표준 도메인이라고 한다.
- 표준 코드 : 도메인의 한 유형으로, 특정 도메인 값(코드 값)이 이미 정의되어 있는 도메인. 따라서 코드에 대한 표준은 다른 표준과는 다르게 데이터 값(코드 값)까지 미리 정의해야 한다.
데이터 모델링은 요구사항을 수집하고 , 현행 시스템 데이터 구조 분석 → 문제점 및 개선 방향 도출
개념 모델링 데이터 주제영역 식별, 정의 → 높은 응집도 && 낮은 결합도 관점으로 주제 영역을 세분화 → 핵심 엔티티 및 식별자를 도출해 관계를 정의
리버스 모델 활용
- 기존에 물리 모델링을 리버스해서 논리 모델링을 수행하는 경우
- ERD가 없거나 현행화가 이루어지지 않은 경우 주로 사용.
- DB 정보를 이용해 엔티티 및 속성 도출, 관계 식별 ERD 작성한다.

개념 모델링

업무 영역으로부터 요구사항을 형상화하여 개념 도출
개념을 구체화하여 엔티티 식별
주제 영역을 확실히 정하는 것이 중요함

개념 모델링 순서

📌 ** 주제영역 도출 → 주제영역 분류 및 정의 → 핵심 엔티티 정의 및 관계 정의 **

주제영역

최상위 단계에서 분류한 데이터 집합
타 영역 데이터와 상호작용은 최소화하도록 정의 ex 정부 데이터

주제영역 도출

하향식 방법
- 상위 주제 영역을 식별 후 상위 주제 영역에 속하는 계층을 세분화해 나아가는 방법
상향식 방법
- 엔티티를 분류하고 그룹핑해 주제 영역을 도출하는 방법
ex 인터넷 뱅킹

주제영역 분류

주제영역 후보 도출 후 기준에 따라 데이터 분류 빛 통합
주제영역분류 종류
- 업무 기능 중심 분류
- 데이터 관점 분류
ex 인터넷 뱅킹

주제영역 정의

업무영역 전체
- 포함 여부 확인
- 중복 여부 확인
- 동일 기준 적용 검토
주제영역명 명명 규칙
1. 관리하는 정보를 설명하는 단수형 명사를 사용
2. 한글과 영문 대문자 사용, 숫자 및 특수 문자 사용 금지
3. 영문 약어는 알파벳 대문자와 숫자로 구성
4. 주제 영역은 영문 2자리로 구성
  - 하위 주제영역은 상위 약어에 숫자 2자리를 붙여 구성 ex CU01, CU0201
ex 인터넷 뱅킹
💡주제 영역을 정의할 때 어려운 점
개념 부족
- 주제 영역 개념에 대한 낮은 이해도
  - ⭐정의하기 전 현업을 대상으로 주제영역 개념에 관해 설명 필요
의견 차이
- 모델러 - 데이터 관점 접근
- 현업 - 실제 업무의 기능, 흐름 구현
  - ⭐다양한 관점에서 생각하는 습관 필요
확신 부족
- 주제 영역을 잘 정의했는지 판단하기 어려운 경우
  - ⭐ 일관된 기준을 작용하여 생각 차이를 좁힌다.
오너십
- 이해 불가

핵심 엔티티 식별

주제 영역별로 대표성을 갖는 핵심 엔티티를 도출하고 식별함

식별자 및 속성 정의

식별자는 엔티티 개념을 가장 명확하게 표한할 수 있는 속성으로 구성함 (PK)

[핵심 데이터 모델링] - 데이터 모델링이란?

Mon, 13 Mar 2023 07:35:17 GMT

데이터 모델링이란?

📌 현실에 있는것 → 프로그래밍화 시키는 과정

데이터 시스템 구조를 사람이 이해할 수 있게 형상화 하는 과정. 사람이 정보로 의미있는 대상을 식별(개념적) ➡️ 기호 등을 통해 추상화하여 표현(논리적) ➡️ DB구축을 위해 구체화(물리적) why? 현업 인터뷰, 업무 지침서 등 현행 업무를 파악하기 위해서 한다.

📌 데이터 모델의 종류

개체관계 모델(ER, Entity-Relationship Model)
관계 모델(Relational Model)
계층 모델(Hierarchical Model)
망 모델(network model)

📌 ** 모델링 순서** 개념 모델링 ➡️ 논리 모델링 ➡️ 물리 모델링

흔하게 보이는 영수증을 보게되면 생각보다 많은 정보들이 들어있다. ex 매장명, 주소, 전화번호, 주문 상품 수량, 금액, 카드사, 카드번호 등등…

영수증의 데이터에서 관리해야할 데이터를 식별하고 모형화하여 하나의 엔티티와 속성들로 표현할 수 있다. 이러한 과정을 개념 모델링이라고도 부른다. 개념 모델링은 개념을 파악하고 업무를 파악하는 용도로 사용된다.

논리 모델링은 엔티티와 속성이 나누어진 개념 모델링을 업무에서 사용할 수 있게 체계화 하고 구체화하여 데이터 모델로 표현한다.

물리 모델링은 논리 모델링을 업무와 타협하는 단계이다.

ER모델 (Entity-Relationship Model)

ER모델은 표현하고자 하는 현실 세계의 업무를 개체와 관계라는 두 가지 개념으로 표현하는 모델이다. ER표기법을 사용하여 표현한다. ERD : ER에서 사용하는 실체와 관계를 도식화한 것, 이를 알기 쉽게 도형으로 표현한다.

ER모델의 질적 특성

완전성(Completeness) : ER모델은 현실 세계의 모든 업무적인 요구사항을 표현하고 있어야 한다.
정확성(Correctness) : ER모델의 개념대로 데이터 모델을 작성해야 한다. 요구사항 확인을 잘해야 한다.
최소성(Minimality) : 요구사항의 모든 특성이 ER모델에 한번만 나타나도록 설계해야 한다. 중복이 없어야 한다.
자명성(Self-explanation) : 요구사항을 쉽게 반영할 수 있도록 유연한 모델을 설계해야한다.

ER모델 구성요소

📌 엔티티, 관계, 속성, 식별자

엔티티(Entity) 클래스와 비슷함
관계(Relationship)
속성(Attribute) iv와 비슷함
식별자(Identifier)

엔티티(Entity)

엔티티는 고객, 상품, 직원, 조직, 서비스, 직업처럼 개념적인 것이다. 객체지향개념의 클래스와 비슷하다. 엔티티는 반드시 각 인스턴스를 식별할 수 있는 속성이나 관계가 하나 이상 정의되어야 한다.

슈퍼타입, 서브타입 엔티티로 확장 가능하다. ex 고객 (슈퍼타입), 개인 고객, 법인 고객 (서브타입) Java로 예를 들면 서브타입은 슈퍼타입을 상속받았다.

엔티티의 일반화 여러개의 엔티티를 공통의 성격으로 묶어 하나의 엔티티로 재정의한다. 두개의 하위수준 엔티티를 합쳐 하나의 상위수준으로 바꾸는 상향식 접근방식
ex 개인고객, 법인고객 ➡️ 고객으로 합침 - join을 하지않아 개발 생산성 증대, but 속성의 의미가 불분명해 데이터 무결성 문제가 발생 할 수 있음 ↘️ 데이터 무결성 문제 : 잘못된 데이터가 들어올 수 있음

💡DB제약조건 무결성 : PK, FK, Not Null 등등.. (잘못된 데이터가 들어오지 않게하기 위함)

엔티티의 특수화 일반화의 반대 개념으로, 하나의 상위수준 엔티티를 둘로 쪼개 두개의 하위수준 엔티티로 나누는 하향식 접근방식
엔티티의 집단화 여러 엔티티가 하나의 엔티티로 취급하는 경우 ex 고객과 상품간의 관계를 단일 엔티티(주문상품)으로 재정의 해 배송과 관계를 맺는다.
엔티티의 다양한 분류
관계에 따른 분류
- 강한 엔티티 : 독립적으로 존재하며, 엔티티 내에서 고유하게 인스턴스를 식별할 수 있다. 고객, 상품 등
- 약한 엔티티 : 다른 엔티티에 종속적이며, 자체 식별자를 가질 수 없고, 다른 엔티티의 식별자를 상속받아 사용한다. 주문상품은 주문에서 주문번호를 상속받아 식별자로 사용

형태에 따른 분류
- 독립 엔티티 : 사람, 물건, 장소, 개념처럼 원래부터 현실에 존재하는 엔티티 고객, 상품, 창고, 조직
- 업무중심 엔티티 : 업무를 처리하면서 발생하는 데이터 주문, 결제, 배송, 청구
- 종속 엔티티 : 업무중심 엔티티에서 1차 정규화로 분리된 엔티티 주문상품, 주문배송
- 교차 엔티티 : 엔티티 간에 발생하는 트랜잭션에 의해 성성된 엔티티

생성 관점에 따른 분류
- 핵심 엔티티 : 고객, 상품, 조직처럼 부모 엔티티가 없는 독립적인 엔티티
- 중요 엔티티 : 핵심 엔티티간의 거래 관계에 의해 생성되는 엔티티, 업무에 핵심이 되는 엔티티 계약은 고객과 상품의 거래 관계에 의해 생성되며, 고객과 상품을 부모로 갖는다.
- 행위 엔티티 : 실제 업무 행위에 의해 지속해서 발생하는 거래 행위에 대한 엔티티

유무형에 따른 분류
- 실체 엔티티 : 고객, 상품과 같이 눈으로 볼 수 있는 물리적인 형태를 가지는 엔티티
- 비실체 엔티티
  - 개념 엔티티 : 조직, 보험상품, 서비스 등 형태는 없지만 개념적으로 존재하는 엔티티
  - 사건 엔티티 : 계약, 주문, 결제 등 업무 행위와 관련된 엔티티

📌 ER 모델의 구성요소

엔티티
관계 - 관계수, 선택성, 식별성, 관계명
속성

관계(Relationship)

엔티티와 엔티티 간에 존재하는 업무 규칙을 정의하고 엔티티 간에 어떤 관계가 이루어질 수 있는지 표현한다.

구성요소

관계수(cardinality)
선택성(optionality)
식별성(Identifier Inheritance)
관계명

관계수 (Cardinality)

엔티티간의 대응되는 최대 인스턴스 수 상대 엔티티 쪽에 까마귀 발 (Crow’s Foot)로 표시한다. 반드시 양쪽다 서로의 관계를 확인해야함

1 : 1 : 엔티티 하나가 다른 엔티티 하나와 관계를 가지는 경우다. ex 직원과 인턴과정, 중요한 문서가 있을 때, 테이블을 쪼개 보여줄 수 있는 부분과 보안상 가려야하는 부분 1 : 1로 join해서 관계를 맺는다.
1 : M : 엔티티 하나가 다른 엔티티 여러 개와 관계 ex 부서와 직원
M : N : A엔티티가 B엔티티 개체 여러개와 관련있고, B엔티티 개체 하나는 A엔티티 개체 여러개와 관계가 있다. ex 학생과 수강과목

선택성 (Optionality)

필수냐 선택이냐 로 구분이 가능하다. 엔티티 인스턴스에 대한 상대 엔티티 인스턴스 존재 유무를 나타낸다.

필수 — 필수 : A 엔티티의 인스턴스에 대해 B 엔티티 인스턴스가 반드시 존재해야 하고, B 엔티티의 인스턴스에 대해 A 엔티티의 인스턴스도 반드시 존재해야 한다. ex상품을 선택하지 않고 주문을 하는 경우는 없으므로, 주문은 주문상품이 반드시 존재해야 한다.
필수 — 선택 : A 엔티티의 인스턴스에 대해 B 엔티티 인스턴스가 존재하지 않아도 되고, B 엔티티 인스턴스에 대해 A 엔티티 인스턴스는 반드시 존재해야 한다. ex주문하지 않은 고객은 있을 수 있으나, 모든 주문은 반드시 주문한 고객이 있어야 한다.
선택 — 선택 : A 엔티티 인스턴스에 대해 B 엔티티 인스턴스가 존재하지 않아도 되고, B 엔티티 인스턴스에 대해 A엔티티 인스턴스도 존재하지 않아도 된다. ex사원은 소개사원으로 등록된 계좌가 존재하지 않을 수 있고, 고객이 펀드상품에 가입할 때 소개 사원을 지정하지 않아도 되므로 계좌는 소개 사원이 존재하지 않을 수 있다.

식별자 상속 (Identifier Inheritance)

식별자 상속은 식별관계와 비식별 관계로 구분할 수 있다.

식별 관계는 참조되는 상위 엔티티 식별자가 참조하는 하위 엔티티 식별자로 상속되는 경우를 말한다. ex) 고객주소의 고객번호(FK)가 주문 엔티티에서 고객번호(FK)로 상속된다.

비식별 관계는 식별자가 아닌 일반 속성으로 상속되는 관계를 말한다. *️⃣ 다른 테이블의 PK이자 내 테이블의 FK, FK인 동시에 PK인것

📌 ER 모델의 구성요소

엔티티
관계 - 관계수, 선택성, 식별성, 관계명
속성

속성

데이터를 표현하는 가장 작은 단위, 하나의 엔티티는 두개 이상의 속성을 가진다.

속성명 : 실체의 특성을 규정하는 속성 명칭
식별자 여부 : 해당 속성이 엔티티 식별자에 해당하는지 표시
옵셔널리티 : 엔티티에 인스턴스가 발생할 때 값을 가져야 하는지에 대한 구분.
도메인 : 속성이 허용하는 데이터 형식과 범위를 가지고 있다.

식별자

엔티티에서 인스턴스를 개별적으로 식별할 수 있는 속성들이다.

특징 : 유일성, 최소성, 불변성, 존재성(Not null)

📌 관계형 데이터 모델 (RDB)

Key
제약조건
함수종속
정규화

관계형 데이터 모델이론

데이터를 2차원 테이블(표) 형식으로 정의하고 표현한 모델이다. 테이블 == 릴레이션 릴레이션은 스키마헤더 와 실제 값은 인스턴스본문로 구성된다.

스키마 : 구조
- 릴레이션명
  - 표를 구성하는 각 열을 의미
- Attribute
  - 더는 쪼갤 수 없는 원자 값
  - 값이 서로 다르며 유일해야 함
인스턴스 : 실제 값
- Tuples
  - 릴레이션의 각 행
  - 중복된 튜플 허용 X
  - 값은 동일해도 OK

Key

슈퍼 키 (Super Key)

: 튜플을 고유하게 식별할 수 있는 속성 집합

릴레이션은 한 개 이상의 슈퍼 키를 가질 수 있음
슈퍼 키 값은 모든 튜플에서 유일해야 함 ex 사원번호 + 사원명 이 두개가 고유 값. 슈퍼키임

후보 키 (Candidate Key)

: 튜플을 고유하게 식별 할 수 있는 최소한의 속성 집합

모든 후보 키는 슈퍼 키지만, 모든 슈퍼 키가 후보 키는 아님 (슈퍼 키 가 후보 키 포함)

기본 키 (Primary Key)

: 하나 이상의 후보 키 중에서 선택된 단 한개의 키

유일성, 최소성을 가짐
NULL 값 불가능

대체 키 (Alternate Key)

: 후보 키 중에서 기본 키가 아닌 후보 키

외래 키 (Foreign Key)

: 어떤 릴레이션의 어트리뷰트 값이 → 다른 릴레이션에 속한 어트리뷰트의 기본 키를 참조하는 경우

NULL값 가능
중복된 튜플 OK

관계도

제약조건

📌 목적 : DB에 오염된 데이터가 들어오는걸 막기 위함

📌 PK, FK, Not Null, Unique, Domain <-외워

키 제약조건 (PK)
- 필드에 Unique와 Not Null 특징을 가짐
실체무결성 (Not Null)
- 필드에 NULL값을 저장할 수 없게 함
영역무결성 (Domain)
- 정의된 영역 내의 값만 받음
참조무결성 (FK)
- 외래키는 부모 릴레이션의 기본 키 값만 가능
Unique
- 중복값 X

함수종속

📌 관계형 DB설계 시, 정규화 과정에서 이 개념이 중요하게 사용된다.

ex “고객” 테이블이 { 고객번호, 고객명, 생년월일, 전화번호, 주소 } 속성을 가지고 있을 떄 고객번호 컬럼에 다른 컬럼들이 함수적으로 종속된다. 고객번호 → (고객명, 생년월일, 전화번호, 주소)

짧게 요약 테이블의 특정 컬럼 A의 값을 알게되면, 다른 컬럼 B의 값을 알 수 있을 때 컬럼 B는 A에 함수적 종속성이 있다. 고객번호를 알면 고객명을 알 수 있으며, “고객명은 고객번호에 함수적 종속성이 있다.”

정규화

📌 정규화 : 단계별로 테이블 쪼개기

중복을 없애기 위해 더 작은 단위의 테이블로 설계하는 과정

장점

데이터 입력, 수정, 삭제 과정에서 발생하는 이상 현상 최소화
데이터 구조 변경 시 유연성이 증가한다.
작은 단위로 세분화 할 경우 재활용성이 높아진다.
중복 최소화, 수행속도 향상

주의사항

: 성능의 저하가 심하면 어쩔 수 없이 다시 join한다. (역정규화)

제1정규형

: 중복되는 값이나, 중복열이 있을 경우 정규화 진행

같은 개념의 컬럼이 여러개, 다중 값을 가지는 경우 별도의 테이블로 분리함
엑셀에 데이터를 다 입력해서 중복값 찾아 정규화하기
분리된 테이블은 원 테이블의 기본키를 FK로 사용, 나머지 중 유일하게 식별 가능한 컬럼을 기본키로 추가.

제2정규형

: 제1정규형을 만족하고, 키가 아닌 어트리뷰트는 후보키 전체에 종속되어야 한다.

쉽게 “묶을 수 있는 걸 따로 묶어서 뺀다”

제3정규형

: 제2정규형을 만족하고, 키가 아닌 어트리뷰트들 간에는 서로 종속적인 관계가 없어야 한다.

키가 아닌 어트리뷰트가 다른 어트리뷰트에 포함되면 따로 테이블을 분리해야함

연결함정

: 정규화 과정에서 무손실 분해의 원칙이 지켜지지 않아,

원래 있던 관계성을 잃어 버리는 현상

부채꼴 함정
- 관계가 모호할 때가 있음
  
  ex 회사에서 물품을 구매한 공급사를 관리하고, 여러 상품을 구매한다. 각각, 관계를 표현했을 때 물품이 어느 공급사에서 구매한 것인지 알 수없는 현상이 발생
  
  해결방안 회사 → 공급사, 공급사 → 물품 간의 관계 변환
균열 함정
- 일부 엔티티와 엔티티 사이의 관계가 존재하지 않을 때 발생
  
  ex 공급사를 통하지 않고 직접 물품을 구매할 수는 없을까?
  
  해결방안 이럴 경우 회사 → 물품 관계를 맺어줘야 함

_soon.log

[스프링의 정석] - Spring MVC - 클라이언트 서버, HTTP 요청과 응답

원격 프로그램의 실행

HTTP 메시지 - 응답 메시지 형식

HTTP 메시지 - 요청 메시지

HTTP 메서드 - GET, POST

텍스트 파일 vs 바이너리 파일

MIME ( Multipurpose Internet Mail Extensions )

Base64 - 64진법

[핵심 데이터 모델링] - 물리 모델링

물리 모델링이란

테이블 설계

슈퍼타입 기준 테이블 설계

서브타입 기준 테이블 설계

슈퍼타입/서브타입 테이블 설계

관계 설계

기본적인 관계

상호배타적 관계

관계 옵셔널리티 확정

컬럼 설계

속성-컬럼 변환

데이터 타입 및 길이 지정

기본키(PK : Primary Key) 지정

데이터 무결성 설계

실체 무결성(Entity Integrity)

영역 무결성(Domain Integrity)

성능을 고려한 데이터 구조

집계/요약 테이블 추가

컬럼 추가

테이블 분할

물리 설계

오브젝트 명명 규칙

[핵심 데이터 모델링] - 논리 모델링

논리 모델링이란?

방법

엔티티 정의 및 상세화

핵심 엔티티 (Key Entity, 기준정보)

중요 엔티티 (Main Entity, 업무기본)

행위 엔티티 (Action Entity, 업무상세)

엔티티 도출 및 식별

엔티티 명명

엔티티 명명규칙

관계 도출 및 정의

속성 도출 및 정의

속성 도출

식별자 지정

인조식별자를 정의하는 경우

도메인 및 데이터타입 지정

옵셔널리티(Not Null) 지정

데이터 표준화

단어 표준화

코드 표준화

[핵심 데이터 모델링] - 개념 모델링

개념 모델링

데이터 모델링 접근 방법

데이터 모델링 순서

개념 모델링

개념 모델링 순서

주제영역

주제영역 도출

주제영역 분류

주제영역 정의

핵심 엔티티 식별

식별자 및 속성 정의

[핵심 데이터 모델링] - 데이터 모델링이란?

데이터 모델링이란?

ER모델 (Entity-Relationship Model)

ER모델의 질적 특성

ER모델 구성요소

엔티티(Entity)

관계(Relationship)

관계수 (Cardinality)

선택성 (Optionality)

식별자 상속 (Identifier Inheritance)

속성

식별자

관계형 데이터 모델이론

Key

슈퍼 키 (Super Key)

후보 키 (Candidate Key)