Spring을 배우던 중, webflow에서 발생했던 404 에러를 두시간 가까이 해결하지 못했었다. 사유는 404, 그저 매핑이 되지 않는다는 이유였는데 지금까지 배워 오면서 매핑이 안되는 이유? 그런 기초적인 것을 놓칠 리 없다는 생각 때문인지 도저히 해결방안을 찾지 못했었다. 하지만 이는 webflow에 대해 완벽히 이해하지 못해서 생긴 일이었는데...

 

   일단 먼저 요청 주소를 살펴보자.

	<div>
		<form:form name="clearForm" method="delete">
			<a href="javascript:clearCart()" class="btn btn-danger pull-left">삭제하기</a>
		</form:form>
		<a href="<c:url value="/order?cartId=${cartId}"/>"
		class="btn btn-success float-right">주문하기</a>
	</div>

 

   여기서 주문하기에 연결된 주소가 webflow 주소였다. 하지만 이걸 작성하면서도 이를 어떻게 webflow에 연결된다는 건지 이해하지 못했는데 아니나 다를까, 스스로도 매핑될 컨트롤러를 몰라서인지 404 에러가 열심히 떠주며 연결할 수 없다고 못을 박아버리는 것... 찾다가 찾다가 다시 초기로 돌아가 xml 설정 파일로 돌아가 보았다.

<webflow:flow-registry id="flowRegistry" flow-builder-services="flowBuilderServices">
	<webflow:flow-location path="/WEB-INF/flows/order/order-flow.xml"></webflow:flow-location>
</webflow:flow-registry>

 

   웹 플로우를 지정하는 곳을 잘 살펴보니...

   매핑을 받을 부분을 정해주지 않았던 것이었다...

<webflow:flow-location path="/WEB-INF/flows/order/order-flow.xml" id="order"></webflow:flow-location>

 

   여기서 id 부분이 매핑되는 주소가 되는 것을 기억하자... 404는 매핑을 아예 시켜주지 않기 때문에 코드의 흐름을 읽어낼 방법이 없어 500이든 501이든 서버측에서 터지는 에러보다 더 곤란할 때가 있는 것 같다.

'오류노트' 카테고리의 다른 글

Java의 Null 처리에 관하여  (0) 2024.11.12
mySQL update 및 delete가 안될 때  (0) 2024.11.10
Tiles.xml 설정 주의 사항  (0) 2024.11.09
Downloading external resources is disabled  (0) 2024.11.08
java.lang.NullPointerException  (0) 2024.10.29
ERROR 1175 (HY000): You are using safe update mode and you tried to delete a row without a WHERE that uses a KEY column

 

   mySQL을 처음 시작했다면 기본적으로 지정된 설정 때문에 업데이트나 삭제를 진행할 수 없다는 에러를 만날 수 있을 것이다. 이는 [Edit] > [Preferences] 탭으로 들어가 아래 사진에 체크되어 있는 항목을 해제해주면 그 때부터 정상적으로 사용할 수 있다.

 

 

'오류노트' 카테고리의 다른 글

Java의 Null 처리에 관하여  (0) 2024.11.12
webflow Http Status 404 Error  (0) 2024.11.11
Tiles.xml 설정 주의 사항  (0) 2024.11.09
Downloading external resources is disabled  (0) 2024.11.08
java.lang.NullPointerException  (0) 2024.10.29

모델링의 개념 및 특징

  • 현실 세계의 비즈니스 프로세스와 데이터 요구 사항을 추상적 및 구조화 된 형태로 표현하는 과정
  • 데이터베이스의 구조와 관계를 정의하여 데이터의 저장 / 조작 / 관리 방법을 명확하게 정의

 

   1. 단순화(Simplification)

  • 현실을 단순화하여 핵심 요소에 집중하고 불필요한 세부 사항을 제거
  • 단순화를 통해 복잡한 현실 세계를 이해하고 표현

   2. 추상화(Abstraction)

  • 현실세계를 일정한 형식에 맞추어 간략하게 표현하는 과정
  • 다양한 현상을 일정한 양식인 표기법에 따라 표현

   3. 명확화(Clarity)

  • 대상에 대한 애매모호함을 최대한 제거하고 정확하게 현상을 기술
  • 명확화를 통해 모델을 이해하는 이들의 의사소통을 원활하게 함

 

데이터 모델링 3가지 관점
데이터 관점 말 그대로 데이터의 입장에서 바라보는 관점, 데이터가 어떻게 저장되고 접근되며 관리되는지 정의함
프로세스 관점 데이터가 시스템 내에서 어떻게 흐르고 변화되는지에 대해 확인
데이터와 프로세스 관점 특정 프로세스가 어떤 데이터를 사용하는지, 데이터는 어떻게 생성되고 변경되는지를 정의함

 

데이터 모델링 유의점

 

1. 중복(Duplication)이 일어나면 안된다.

  • 한 테이블 혹은 여러 테이블에 동일한 정보를 저장하지 않도록 설계해야 한다.

   

2. 비유연성(Inflexibility)이 되면 안된다.

  • 사소한 변화에도 모델 자체가 변경되지 않도록 유연성 있게 설계해야 한다.
  • 예시로, 학생이 수강하는 과목에 대해서 국어, 수학, 영어 등 과목을 컬럼으로 지정하게 되면 새로운 과목이 추가될 때마다 컬럼이 추가된다. 이는 모델 자체가 변경되는 것이니 옳은 설계가 아니며, '과목' 하나의 컬럼을 만들고 인스턴스가 새로 추가되는 형식이야말로 유연한 설계라고 할 수 있다.

3. 비일관성(Inconsistency)이 되면 안된다.

  • 데이터베이스 내의 정보가 모순되거나 상반된 내용을 갖게 되선 안되며, 이는 중복을 피하더라도 비일관성이 발생할 수 있기 때문에 데이터간 상호 연관 관계를 명확히 정의하고 품질 관리가 필요하다.

 

데이터 모델링 3가지 요소
대상, 엔터티 (Entitiy) 업무가 관리하고자 하는 대상 (객체, 엔터티)

-  현실 세계에서 독립적으로 식별 가능한 객체나 사물을 나타냄
유일한 식별자에 의해 식별 가능 
-  영속적으로 존재하는 2개 이상의 인스턴스의 집합체
-  엔터티는 2개 이상의 속성을 가져야 함
-  업무 프로세스에 의해 이용되어야 함
-  타 엔터티와 최소 1개 이상의 관계가 성립해야 함
속성, 컬럼 (Attribute) 대상이 갖는 속성 (하나의 특징으로 정의될 수 있는 것) 

-  업무에서 필요로 하는 고유한 성질, 특징을 의미 (컬럼으로 표현할 수 있는 단위)
정해진 주식별자에 함수적 종속성을 띄고 있어야 함
-  인스턴스로 관리하고자 하는 더 이상 분리되지 않는최소의 데이터 단위
한 개의 속성은 1개의 속성 값을 갖는다 (속성의 원자) 
인스턴스를 이루는 구성 요소를 일컫음
    (ex. 학생 엔터티의 속성은 이름 / 학번 / 학과번호 등)
관계 (Realationship) 엔터티간의 연관성을 나타낸 개념

-  관계를 정의할 때 인스턴스간의 논리적인 연관성을 파악하여 정의함
존재적 관계 : 한 엔터티의 존재가 다른 엔터티의 존재에 영향을 미치는 관계
    (ex. 부서 엔터티가 삭제되면 사원 엔터티의 존재에 영향을 미침)
행위적 관계 : 엔터티 간의 어떤 행위가 있는 관계
    (ex. 고객 엔터티의 행동에 의해 주문 엔터티가 발생)
-  관계의 구성요소는 관계명 / 차수(Cardinality) / 선택성(Optionality)이 있음
차수(Cardinality) : 1대1 / 1대N(1대다) / M대N(다대다)
    (차수는 하나의 엔터티와 다른 엔터티 간의 레코드 연결 방식)
관계의 페어링 : 엔터티 내의 인스턴스가 개별적으로 관계를 가지는 것
    (페어링은 두 엔터티 간의 특정한 인스턴스를 설명하고 추가 정보를 제공)

 

   엔터티의 분류   

1. 유형과 무형에 따른 분류

  • 유형 엔터티 : 물리적인 형태가 있으며, 안정적이고 지속적으로 사용되는 엔터티 (ex. 사원, 물품 등)
  • 개념 엔터티 : 물리적인 형태가 없으며, 관리해야 할 개념적 정보로부터 구분되는 엔터티 (ex. 조직, 보험상품 등)
  • 사건 엔터티 : 업무 수행에 따라 발생하는 엔터티로서 발생량이 많고, 통계자료에 이용됨 (ex. 주문, 청구 등) 

2. 발생 시점에 따른 분류

  • 기본 엔터티 : 태초부터 존재하던 정보로 다른 엔터티와 관계에 의해 생성되지 않고 독립적으로 생성됨. 따라서 타 엔터티의 부모 역할을 할 수 있으며, 자신만의 고유한 주식별자를 가지고 있음 (ex. 사원, 고객, 상품 등)
  • 중심 엔터티 : 기본 엔터티로부터 발생되어 해당 업무에서 중심적인 역할을 하는 엔터티. 이 또한 많은 데이터가 발생하고, 다른 엔터티와의 관계를 맺으며 다양한 행위 엔터티를 생성할 수 있음 (ex. 계약, 청구, 매출 등)
  •  행위 엔터티 : 2개 이상의 부모 엔터티로부터 발생하는 엔터티 (ex. 주문, 사원변경이력 등)

 

   함수의 종속성   

   속성은 정해진 주식별자에 함수적 종속성을 가져야 한다

  • 한 속성의 값이 다른 속성의 값에 종속적인 관계를 갖는 특징을 말한다.
  • A속성의 값에 의해 B속성의 값도 바뀐다면, B는 A에 함수적으로 종속됐다 하고, 이를 수식으로 A → B로 표현됨.

1. 완전 함수적 종속

  • 특정 컬럼이 기본키에 대해 완전히 종속될 때를 말한다.
  • PK를 구성하는 컬럼이 2개 이상일 경우, PK 값 모두에 의한 종속관계를 나타낼 때
  • 제품코드 + 제품명이 PK일 때 유통기한 속성은 두 개의 PK값에 의해 바뀌므로 완전 함수적 종속 관계

2. 부분 함수적 종속

  • 기본키 전체가 아니라, 기본키 일부에 대해 종속될 때를 말한다.
  • 학생번호 + 과목이 PK일 때 강사 속성은 학생번호가 아닌 과목에 따라 결정되므로 부분 함수적 종속 관계

0. 도메인(Domain)

  • 도메인이란, 각 속성이 가질 수 있는 값의 범위를 의미한다.
  • 엔터티 내에서 속성에 대한 데이터 타입과 크기, 제약사항을 지정하는 것을 말한다. 

 

   속성의 분류   

1. 속성의 특징에 따른 분류

기본 속성 -  업무로부터 추출된 모든 속성
-  엔터티에 가장 일반적으로 많이 존재하는 속성
    (ex. 원금, 예치기간 등) 
설계 속성 -  기본 속성 외에 업무를 규칙화 하기 위해 새로 만들어지거나 기본 속성을 변형하여 만든 속성
    (ex. 상품코드, 지점코드 등)
파생 속성 -  다른 속성에 의해 만들어지며, 일반적으로 계산된 값들이 할당된 속성
-  데이터 정합성을 유지하기 위해 가급적 적게 정의하는 것이 좋음
    (ex. 합계, 평균 등)

 

2. 엔터티 구성 방식에 따른 분류

  • PK(Primary Key, 기본키) : 인스턴스를 식별할 수 있는 속성 (중복과 Null값을 허용하지 않음) 
  • FK(Foreign Key, 외래키) : 다른 엔터티와의 관계에 포함되어 있는 속성
  • 일반 속성 : 엔터티의 일반적인 속성 (PK/FK가 아님) 

3. 분해 여부에 따른 속성

  • 단일 속성 : 하나의의미로 구성된 경우를 말함 (ex. 회원 아이디는 임의로 분해할 수 없기 때문에 단일 속성)  
  • 복합 속성 : 여러개의 의미로 구성된 경우를 말함 (ex. 주소는 도, 시, 구 등으로 분해가능하기 때문에 복합 속성)
  • 다중값 속성 : 속성에 여러 개의 값을 가질 수 있는 경우, 이 경우는 엔터티로 분해해야 함

 

데이터 모델링의 3단계

개념이 있어야 논리를 세울 수 있고, 세워진 논리는 물리적인 형태를 갖출 수 있다!

 

1. 개념적 모델링

  • 업무 중심적이고 포괄적인 수준을 말한다.
  • 추상화 수준이 가장 높으며, 업무에 필요한 핵심 엔터티를 추출하는 단계이다.
  • 추출된 엔터티들간의 관계들을 표현하기 위해 ERD를 작성한다.  

2. 논리적 모델링

  • 개념적 모델링의 결과를 바탕으로 세부속성, 식별자, 관계 등을 표현하는 단계이다.
  • 데이터의 구조를 정의하기 때문에 비슷한 업무 혹은 프로젝트에서 동일한 형태를 갖추고 있다면 재사용이 가능한데, 재사용성이 높을수록 유지보수에 용이해진다.
  • 데이터 정규화를 수행한다.

3. 물리적 모델링

  • 논리 모델링이 끝나면 직접 물리적으로 생성하는 단계이다.
  • 데이터 베이스의 성능, 디스크의 저장구조, 하드웨어의 보안성을 고려해야 한다.
  • 가장 구체적인 모델링이기 때문에 추상화 수준이 가장 낮다.

0. ERD 작성 절차 (Entity Relationship Diagram)

     ERD란? 엔터티와 엔터티 간의 관계(Relationship)를 시각적으로 표현한 다이어그램

  1. 엔터티를 도출한 후 그리기
  2. 엔터티 배치하기
  3. 엔터티 간의 관계를 설정하기
  4. 관계명을 서술하기
  5. 관계의참여도 기술하기
  6. 관계의 필수 여부를 확인하기

 

   식별자 란?   

  • 하나의 엔터티에 구성된 여러개의 속성 중에 해당 엔터티를 대표할 수 있는 속성을 말한다.
  • 엔터티는 하나의 유일한 식별자가 존재해야 한다.
  • 식별자는 논리 모델링 단계에서 사용하는 용어이며, 물리 모델링에서는 키(Key)라고 한다.

 

   식별자 분류   

대표성 여부에
따른 분류
주식별자
(기본키)
유일성과 최소성을 만족하면서 엔터티를 대표하는 식별자
-  엔터티 내에서 각 인스턴스를 유일하게 구분할수 있는 식별자
-  타 엔터티와 참조관계를 연결할 수 있는 식별자 
보조 식별자
(후보키)
-  유일성과 최소성은 만족하지만 대표성을 만족하지 못하는 식별자
-  엔터티 내에서 각 인스턴스를 구분할 수 있지만 참조 관계를 연결할 수 없음  
생성 여부에
따른 분류
내부 식별자 -  타 엔터티 참조 없이 엔터티 내부에서 스스로 생성되는 식별자
외부 식별자 타 엔터티와의 관계로 인하여 만들어지는 식별자, 즉 외래키(FK)
속성 수에
따른 분류 
단일 식별자 하나의 속성으로 구성
복합 식별자 두 개 이상의 속성으로 구성
대체 여부에
따른 분류
본질 식별자 -  원조 식별자
-  비즈니스 프로세스(업무)에서 만들어지는 식별자로 반드시 필요한 식별자
인조 식별자 인위적으로 만들어지는 식별자 (꼭 필요하진 않지만 편의성 등의 이유로 만들어짐)
-  각 행을 구분하기 위해 사용되며, 자동 증가하는 일련번호와 같은 성질을 띔
중복 데이터 발생 가능성이 높아지며 이에 따라 불필요한 인덱스가 낭비되기도 함

 

 

주식별자 특징

  1. 유일성 : 주식별자에 의해 모든 인스턴스를 유일하게 구분할 수 있어야 한다.
  2. 최소성 : 주식별자를 구성하는 속성은 유일성을 만족하는 최소한의 속성으로 구성되어야 한다.
  3. 불변성 : 주식별자의 값은 변해선 안되며 항상 고유의 값으로 존재해야 한다.
  4. 존재성 : 반드시 값이 존재해야 하기 때문에 Null을 허용하지 않는다. (Null - 값이 없음)

주식별자 도출기준

  1. 업무에서 자주 이용되는 속성을 주식별자로 지정한다.
  2. 명칭이나 내역과 같은 이름은 피하는게 옳다. (이 때 마땅한 속성이 없다면 인조 식별자를 만듦)  
  3. 속성의 수를 최소한으로 설정해야 한다.

 

   식별 관계와 비식별 관계   

1. 식별 관계 (Identification Relationship)

  • 하나의 엔터티의 기본키를 다른 엔터티가 기본키의 하나로 공유하는 관계
  • 식별 관계는 ERD에서 실선으로 표시함

2. 비식별 관계 (Non-identification Relationship)

      강한 개체 : 독립적으로 존재할 수 있는 엔터티

      약한 개체 : 독립적으로 존재할 수 없는 엔터티 

  • 강한 개체의 기본키를 약한 개체에선 기본키가 아닌 일반속성으로 관계를 가지는 것을 말함
  • 비식별 관계는 ERD에서 점선으로 표시함

정규화

  • 최소한의 데이터를 하나의 엔터티에 넣는 식으로 데이터를 분해하는 과정
  • 데이터의 일관성, 최소한의 데이터 중복 및 유연성을 위한 과정
  • 데이터의 중복을 제거하고 이상현상을 줄이기 위한 데이터베이스 설계 기법
  • 논리 데이터 모델링 수행 시점에서 고려되며 제 1 정규화부터 제 5 정규화까지 존재 (보통 제 3정규화 까지 다룸)

0. 이상현상(Abnormality)

정규화를 하지 않아 발생하는 현상으로 삽입이상, 갱신이상, 삭제이상 등이 있다!

  • 삽입이상 : 특정 인스턴스가 삽입 될 때 정의되지 않아도 될 속성까지 반드시 입력해야 하는 상황
  • 삭제이상 : 특정 정보만 삭제하려 했으나, 연관된 다른 데이터까지 삭제되는 상황

 

   정규화 단계   

1. 제 1 정규화 (1NF)

  • 테이블의 컬럼이 원자성(한 속성이 하나의 값만 갖는특성)을 갖도록 테이블을 분해하는 단계
  • 즉, 하나의 행이 가진 컬럼의값이 반드시 한 값만 입력되도록 행을 분리하는 단계

2. 제 2 정규화(2NF)

  • 제 1 정규화를 진행한 테이블에 대해 완전 함수 종속을 만들도록 테이블을 분해하는 단계
  • PK(기본키)가 2개 이상의 컬럼일 경우, 기본키 컬럼의 일부와 종속되는 관계가 존재하면 분리하는 단계

3. 제 3 정규화(3NF)

  • 제 2 정규화를 진행한 테이블에 대해 이행적 종속을 없애도록 테이블을 분해하는 단계
  • 이행적 종속이란 B가 A에 함수적으로 종속되고, C가 B에 함수적으로 종속된 경우, C가 A에도 함수적으로 종속이 되는 경우가 성립할 때를 말함 (즉, AB와 BC로 분리하는 과정이며 주로 A는 PK상태이다)
  • 주식별자가 아닌 모든 속성 간에는 서로 종속될 수 없음

 

0. 조인(Join)

  • 데이터의 중복을 피하기 위해 테이블은 정규화에 의해 분리되며, 분리된 두 테이블은 서로 관계성을 갖게 된다. 그리고 다시 이 두 테이블의 데이터를 동시에 출력하거나, 관계가 있는 테이블을 참조하기 위해서는 데이터를 연결해야 하는 이 과정을 조인(Join)이라고 한다.
  • 계층형 데이터 모델 : 하나의 엔터티 내의 인스턴스끼리 계층 구조를 갖는 경우를 말함 (즉, 셀프조인)

 

Request processing failed; nested exception is org.apache.tiles.request.render.CannotRenderException:

 

 

   교본을 따라 작성했던 내가 발생했던 오류는 아니지만 동기분의 오류를 같이 해결하다가 발견한 것.

 

   위 오류는 Tiles에서 해당 요청을 처리할 수 없을 경우 무수한 에러를 만들어내며 파일이 깨지는 경험을 할 수 있다. 해당 오류가 발생하는 원인으로는 다음 세가지의 문제를 꼽을 수 있는데...

 

   1. 템플릿 경로 이상 : 지정된 템플릿 파일이 존재하지 않거나 잘못된 경로를 사용

   2. 설정 이상 : Tiles.xml파일 등과 같이 정의 파일의 내용이 잘못됨

   3. 의존성 문제 : 필요 라이브러리 혹은 의존성이 누락되거나 호환이 안됨

 

   이 중에서 이번 에러는 2번, 설정 이상인 것 같다.

	<definition name="books" extends="base_Template">
		<put-attribute name="title" value="Books"></put-attribute>
		<put-attribute name="heading" value="도서 목록"></put-attribute>
		<put-attribute name="subheading" value="Books List"></put-attribute>
		<put-attribute name="content" value="/WEB-INF/views/books.jsp"></put-attribute>
	</definition>

 

   위는 스프링에서 Tiles를 설정하는 xml파일의 일부이다. 원하는 파일에 필요한 정보를 바꾸는 것으로, 사실 에러가 발생 할 부분이 없지만 의외로...? subheading부분의 value값을 definition name 부분의 value값과 똑같이 적어주게 되면 console창에서 무수히 많은 에러가 치솟는 것을 볼 수 있을 것이다...

	<definition name="addBook" extends="base_Template">
		<put-attribute name="title" value="Books"></put-attribute>
		<put-attribute name="heading" value="도서 등록"></put-attribute>
		<put-attribute name="subheading" value="addBook"></put-attribute>
		<put-attribute name="content" value="/WEB-INF/views/addBook.jsp"></put-attribute>
	</definition>

 

   에러가 난 부분은 이렇게 작성되어 있었고, 여기서 subheading부분의 값을 addBook이 아닌 다른 값으로 교체하자 정상적으로 작동되는 것을 확인할 수 있었다.

<put-attribute name="subheading" value="Book Addition"></put-attribute>
<!-- 해당 Value값을 수정 -->

'오류노트' 카테고리의 다른 글

webflow Http Status 404 Error  (0) 2024.11.11
mySQL update 및 delete가 안될 때  (0) 2024.11.10
Downloading external resources is disabled  (0) 2024.11.08
java.lang.NullPointerException  (0) 2024.10.29
Type mismatch & Cannot cast  (0) 2024.10.27
다운로드 외부 리소스가 비활성화되어 있습니다.

 

 

   xml파일에서 외부 리소스 링크를 삽입하면 알아서 dtd 혹은 xsd파일을 다운받게 되어 있는데, 이는 이클립스 자체 내에서 기본적으로(아마도) 비활성화 되어 있는 부분이라 처음 환경설정 할 때 풀어주어야 한다. 상단에서 [Window] - [Preferences] 에 들어간 후, 왼쪽 목록에서 XML (Wild Web Developer) 항목을 선택한다. 그리고 Download external resources like referenced DTD, XSD 항목을 체크해주면 xml에 명시된 파일들을 다운받을 수 있다.

 

   하지만 이렇게 설정 했음에도 간혹 알 수 없는 오류로 해당 파일 다운로드에 실패할 때가 있다. 이는 외부에서 파일을 다운 받는 도중 인터넷이 불안정하거나 혹은 처리하는 과정에서 데이터가 꼬이면서 원활하게 데이터를 다운받는 데 실패하여 xml파일 자체가 먹통이 되는 경우인데 이럴 때는 해당 외부 리소스 파일이 어디에 다운받아지는 지 알고 있으면 간단하다!

 

C:\Users\PC\.lemminx\cache\http\www.springframework.org\schema

 

   사용자의 C드라이브 내 Users(사용자)항목을 따라 들어가면 숨겨진 폴더 lemminx에서 해당 경로로 찾아 들어가게 되면 xml파일에서 다운받은 외부라이브러리를 확인할 수 있다. schema폴더에 사용하고자 하는 xsd파일이 제대로 들어있는지 확인하고, 오류가 나는 파일을 확인하여 그냥 제거후 다시 xml을 실행하면 정상적으로 다운받는 것을 확인할 수 있다.

 

   schema 오류는 대부분 위와 같은 자잘한 이유로 오류를 발생시키는데, 이 외에 xml에서 발생할 수 있는 오류로는 서블렛 버전과 톰캣사양에 따른 DTD설정(호환성)을 확인해 보는 것이 좋다.

 

 

버전(Version)별로 DTD선언 정리 in web.xml

web.xml은 웹서버의 환경설정을 담는 곳으로써 , '배포 설명자'라고도 하며, 웹서버를 구성하는 웹 컴포넌트들에 대한 구성 및 자원의 관계 설정 정보 등을 기술합니다. 특히 URL이 을 어떻게 처리

sayit.tistory.com

 

 

'오류노트' 카테고리의 다른 글

webflow Http Status 404 Error  (0) 2024.11.11
mySQL update 및 delete가 안될 때  (0) 2024.11.10
Tiles.xml 설정 주의 사항  (0) 2024.11.09
java.lang.NullPointerException  (0) 2024.10.29
Type mismatch & Cannot cast  (0) 2024.10.27

 

   DDL   

:: 데이터베이스의 객체에 관하여 생성/수정/삭제를 할 수 있는 용어를 뜻함

명령어 설명 ex
CREATE 생성 CREATE DATABASE, CREATE TABLE ...
ALTER 수정 ALTER TABLE (원본 명) RENAME TO (수정 명) ...
DROP 삭제 DROP DATABASE, DROP TABLE ...

 

   테이블을 생성할 때는 괄호() 안에 컬럼 명과 해당 컬럼의 데이터 타입 및 제약 조건을 지정할 수 있다.

 

   데이터 타입은 JAVA를 사용했을 때와 다른 점이 없으며, 그 중에서 CHAR와 VARCHAR의 차이만 이해하고 넘어가면 된다. CHAR타입은 지정된 크기보다 작은 값의 데이터가 들어와도 저장될 때 지정된 크기로만 저장이 된다. 반명 VARCHAR는 지정된 크기보다 작은 값의 데이터가 들어오면 해당 데이터의 크기로만 저장이 된다. 따라서 공간 효율은 VARCHAR이 더 우수한 편이지만, 대신 처리속도가 느리다는 단점이 있다.

 

제약 조건 설명
NOT NULL 해당 컬럼에 NULL값을 허용하지 않는다.
UNIQUE 해당 컬럼에 중복된 값을 허용하지 않는다.
PRIMARY KEY 줄여서 PK라고 부르며, NOT NULL과 UNIQUE의 조건을 모두 갖춘 유일한 값을 말한다.
FOREIGN KEY 줄여서 FK라고 부르며, 다른 테이블과의 관계를 증명할 수 있는 외래키로 사용된다.
CHECK 해당 컬럼에 특정 조건을 만들어 조건식에 해당하는 값만 허용한다.
DEFAULT 해당 컬럼에 값이 입력되지 않을 경우 기본으로 지정되는 값을 설정한다.
AUTO_INCREMENT 자동으로 증가하는 숫자를 입력해준다. 값을 할당 할 시, 해당 숫자부터 카운터를 시작한다.

 

 

   DML   

:: 테이블 데이터에 관하여 생성/수정/선택/삭제를 할 수 있는 용어를 뜻함

명령어 설명 ex
INSERT 테이블에 값을 삽입할 때 사용 INSERT INTO (테이블) VALUES( ... )
SELECT 원하는 테이블의 값을 선택하여 RESERT 화면에 출력할 때 사용 SELECT * FROM (테이블)
UPDATE 특정, 혹은 전체 테이블의 값을 바꿀 때 사용 UPDATE (테이블) SET ( ... ) WHERE
DELETE 특정 테이블의 값을 삭제할 때 사용 DELETE FROM (테이블) WHERE

 

   가장 많이 쓰이는 명령어로 이 중에서 SELECT 명령문이 가장 많이 사용된다. 데이터베이스는 개인이 사용할 수도 있겠지만, 보통 대량의 정보를 저장하는 공간으로 사용하기 때문에 수 천, 수 만건에 달하는 데이터를 모두 가져와서 확인하는 일은 효율도 떨어지고 그렇게 쉬운 일이 아니기 때문이다. 따라서 SELECT를 사용하여 필요한 데이터를 보다 편리하게 가져오는 여러가지 방법을 알아보도록 하겠다.

 

SELECT 컬럼 명  FROM 테이블 명

 

   가장 기본이 되는 선택자이다. SELECT 다음에는 컬럼을 선택할 수 있는데, 모든 컬럼을 조회하고 싶다면 아스트릭(*) 기호를 사용하면 된다. 이렇게 조회했을 경우 해당 테이블의 모든 행이 나오게 되며, 특정 컬럼 명을 입력했을 때는 모든 행의 특정 컬럼내용만 출력하게 된다. 여러 개의 컬럼을 선택하고 싶다면 쉼표로 구분하여 나열하면 된다.

 

SELECT 컬럼 명  FROM 테이블 명  WHERE 조건식

 

   모든 행이 아니라 일부 행을 찾고 싶을 때는 WHERE 명령어를 통해 특정 조건을 사용할 수 있다. 이 조건식은 말 그대로 식이기 때문에 찾고자 하는 값이 숫자인 경우, 사칙연산을 포함해 논리 연산자까지 포괄적으로 사용할 수 있다. 문자열의 경우 대입 연산자를 사용하여 해당 문자열이 같다, 같지 않다로만 구분할 수 있다.

   SELECT mem_id, mem_name  FROM member  WHERE height <= 162 ;

   SELECT 뒤에 표시하고 싶은 컬럼 명을 작성하고 FROM절로 어떤 테이블을 사용할 지 명시한다. 이 때 사용하고 있는 데이터베이스가 USE상태가 아니라면 해당 테이블 앞에 데이터베이스까지 명시해주어야 한다. 그런 다음 WHERE절에서 필요한 조건을 입력하는데 위에서는 특정 컬럼의 값이 162보다 작거나 같을 경우만 검색하도록 설정해두었다. 이런 식으로 숫자를 활용하면 다양한 정보를 찾을 수 있는데 AND와 OR를 사용하여 다양한 조건을 붙일 수도 있다.

   하지만 AND와 OR를 사용하다보면 필연적으로 SQL 명령문의 길이가 길어질 수 있는데 이를 보완한 명령어가 존재한다.

   SELECT mem_name, height  FROM member  WHERE height BETWEEN 163 AND 165 ;

   BETWEEN을 사용하면 손쉽게 특정 범위를 지정할 수 있다. AND조건식을 사용하려면 height >= 163 AND height <=165 이런 식으로 같은 컬럼 명을 중복으로 적으면서 길어지게 된다. 위와 같은 방식으로 OR도 다른 함수를 활용하여 해결할 수 있다.

   SELECT mem_name, addr  FROM member  WHERE addr IN( '경기', '전남', '경남' ) ;

   이 조건문도 마찬가지로 OR를 사용하게 될 경우 컬럼 명을 중복해서 작성해야 하기 때문에 내용이 길어진다. 따라서 IN() 함수를 활용하면 위처럼 짧아진 명령문으로 쉽게 데이터 조회가 가능하다. 하지만 숫자와 다르게 문자는 반드시 문자열 전체가 일치해야 해당하는 행을 반환해준다. 그렇다면 일부 문자만 포함되어 있는 행을 검색하는 방법은 없을까?

   SELECT *  FROM member  WHERE mem_name LIKE ' % 또는 언더바 (_) ' ;

   바로 LIKE절을 사용하는 방법이 있다. 여기서 경기, 경남, 경북과 같이 '경'으로 시작하는 데이터를 가진 행을 가져오고 싶다면 '경%' 라고 입력하면 경으로 시작되는 데이터를 가져온다. %는 글자 수 상관없이 무엇이든 허용한다는 의미로, '경기'도 출력되고 '경기도' 도 출력이 될 수 있다. 다만 '경기도'는 제외하고 '경기' 만 출력되게 하기 위해서는 글자수를 제한할 수도 있는데, 그럴 때 사용하는 것이 바로 언더바(_) 이다. 언더바 하나가 한 글자를 의미하며, 허용하고 싶은 만큼 언더바를 작성해주면 된다.

 

SELECT 컬럼 명  FROM 테이블 명 ORDER BY 컬럼 명

 

   ORDER BY는 테이블을 오름차순 또는 내림차순으로 정렬하기 위해 사용되는 명령어다. 어떤 컬럼을 기준으로 정렬을 할 지 선택한 후 정렬방식을 정하면 되는데 기본값은 오름차순(ASC)이며 내림차순을 사용하고 싶을 때는 DESC를 사용하면 된다. 단일 컬럼을 선택하여 정렬을 진행하면 해당 컬럼에 맞게 정렬이 진행되지만, 만약 복수의 컬럼을 선택하게 된다면 첫번째 컬럼을 제외한 두번째 혹은 세번째 컬럼은 후순위로 정렬이 진행된다. 즉, 첫번째 컬럼에서 중복된 값이 있을 경우 두번째 컬럼에서 정한 기준으로 정렬이 되며, 이 두번째 컬럼 또한 중복된 값이 있을 경우 세번째 컬럼에 지정된 순으로 정렬이 된다.

   SELECT mem_name, height  FROM member  ORDER BY hight DESC  LIMIT 3, 2;

   LIMIT은 출력될 데이터의 갯수를 제한하는 명령어다. 하나의 숫자가 온다면 해당 숫자만큼 데이터를 가져온다는 뜻이 되며, 위와 같이 두개의 숫자가 있는 경우 첫번째 숫자는 시작 위치, 두번째 숫자는 가져올 데이터의 수를 나타낸다. 따라서 세번째 데이터부터 두 개의 데이터를 가져온다는 뜻이 된다. LIMIT은 RESULT화면에서 가장 위에 출력되는 값부터 가져오기 때문에 정렬에 따라 가져오는 데이터가 다를 수 있다. 따라서 LIMIT은 모든 테이블의 선택과 정렬이 끝난 이후 옵션으로 지정하는 편이다.

 

SELECT DISTINCT 컬럼 명  FROM 테이블 명

 

   DISTINCT는 중복된 데이터를 없애겠다는 뜻이다. 중복된 데이터를 합치고 싶은 컬럼명 앞에 붙이면 된다.

   컬럼에 받을 수 있는 데이터는 문자도 있지만 숫자도 있다. 숫자는 기본적인 산술과 더불어 범위를 지정한 것 처럼 연산자 사용이 가능한데, 이를 더 쉽게 사용할 수 있는 집계함수라는 것이 존재한다.

 

집계함수

함수명 설명
SUM() 합계를 구함
AVG() 평균을 구함
MIN() / MAX() 최솟값 / 최댓값을 구함
COUNT() / COUNT(DISTINCT) 행의 개수를 반환, DISTINCT를 붙일 경우 중복된 행은 한개로 간주

 

   Java에서 배운것과 비슷하게 함수절에 들어가는 부분에 컬럼을 입력하면 해당 컬럼에 대한 값을 반환해준다. 하지만 해당 컬럼의 모든 값을 연산하게 되면 데이터가 한 줄이 되어버리는 일이 발생할 수 있다. 중복된 값에 따라 필요한 곳만 연산하여 출력하기 위해서는 이를 그룹으로 묶어주는 과정도 필요한데, 이 집계함수를 유용하게 쓰는 곳이 바로 GROUP BY절이다.

 

SELECT 컬럼 명 / 집계함수 등...  FROM 테이블 명  GROUP BY 컬럼 명

 

   GROUP BY를 사용하게 되면 집계함수가 실행되는 범위가 지정된 컬럼 명으로 바뀌게 된다. 만약 쇼핑몰의 주문내역 중, 같은 아이디의 회원이 구매한 내역을 합치고 싶다면 집계함수는 SUM(구매내역)이 될 것이고, 아이디 별로 묶어야 하니까 GROUP BY절 뒤에 올 컬럼명은 회원 아이디가 되는 것이다.

   SELECT mem_id AS '회원 아이디'  SUM( amount ) AS '총 내역'  FROM buy GROUP BY mem_id;

   여기서 AS는 Alias, 즉 별칭을 뜻하며 컬럼명이 너무 길거나 가독성이 떨어질 경우 테이블의 컬럼 제목을 임의로 바꿀 수 있다. AS는 생략 가능하며, 그냥 컬럼 뒤에 공백을 두고 작성해도 된다. 위와 같이 작성하게 되면 회원의 아이디 별로 총 주문 내역이 반영된 데이터 테이블이 완성된다. 이렇듯 SELECT문은 기존에 존재하는 테이블을 선택하여 보여줄 수도 있지만, 임의로 컬럼을 생성하고 가공하여 새로운 데이터를 가진 테이블을 보여줄 수 있다.

   SELECT …  (생략)  … GROUP BY mem_id HAVING SUM( price*amount ) > 1000;

   조건식을 통한 그룹을 진행하려 WHERE절을 쓰면 오류가 난다. 사유는 집계함수를 사용할 수 없기 때문인데, 이럴때 사용할 수 있는 절이 HAVING절이다. HAVING은 WHERE절과 비슷하게 조건을 제한하는 것이지만, 특히 집계함수에 대해 활용하는 것이라 생각하는 편이 좋다. 따라서 HAVING절은 단독으로 쓰일 수는 없으며, 반드시 GROUP BY절 다음으로 사용해야 한다.

 

 

+ Recent posts