'개념정리' 카테고리의 다른 글
이클립스 (0) | 2021.04.13 |
---|---|
POJO (Plain Old Java Object ) (0) | 2021.04.11 |
카멜케이스, 파스칼케이스, 스네이크케이스 (0) | 2021.04.07 |
Get ,Post (0) | 2021.04.07 |
[spring] Rest API (0) | 2021.04.06 |
이클립스 (0) | 2021.04.13 |
---|---|
POJO (Plain Old Java Object ) (0) | 2021.04.11 |
카멜케이스, 파스칼케이스, 스네이크케이스 (0) | 2021.04.07 |
Get ,Post (0) | 2021.04.07 |
[spring] Rest API (0) | 2021.04.06 |
릴레이션 : 행과 열로 구성된 테이블
테이블은 릴레이션의 시각적인 표현 방법
릴레이션은 스키마와 인스턴스로 이루어진다.
스키마 : 관계 데이터베이스의 릴레이션이 어떻게 구성되는지 어떤 정보를 담고 있는지에 대한 기본적인 구조를 정의
테이블에서 스키마는 테이블의 첫 행인 헤더에 나타나며
각 데이터의 특징을 나타내는 속성, 자료 타입 등의 정보를 담고 있다.
인스턴스 : 정의된 스키마에 따라 테이블에 실제로 저장되는 데이터의 집합
릴레이션 스키마는 릴레이션(테이블)에 어떤 정보가 담길지 정의한다.
릴레이션 인스턴스는 릴레이션 스키마에 실제로 저장된 데이터의 집합이다.
릴레이션에서 한행을 투플이라고 한다.
키(KEY)
키라는 용어는 무엇인가를 유일하게 식별한다는 의미가 있다.
데이터베이스에서 키는 릴레이션에서 특정 투플을 식별할 때 사용하는 속성 혹은 속성의 집합이다.
릴레이션(테이블)은 중복된 투플을 허용하지 않기 때문에 각각의 투플에 포함된 속성들 중 어느 하나(혹은 하나 이상)는 값이 달라야 한다.
즉 키가 되는 속성(혹은 속성의 집합)은 반드시 값이 달라서 투플들을 서로 구별할 수 있어야 한다.
그리고 키는 릴레이션 간에 관계를 맺는 데도 사용된다. 예를들어 고객정보, 제품정보, 주문정보의 릴레이션이 있다면 고객이름, 제품이름으로 릴레이션간 관계를 맺을 수 있다.
고객번호 | 이름 | 주민번호 | 주소 | 핸드폰 |
1 | A | 920101-******* | 서울시 | 010-1111-1111 |
2 | B | 930202-******* | 경기도 | 010-2222-2222 |
3 | C | 940303-******* | 세종시 | 010-3333-3333 |
슈퍼키
투플을 유일하게 식별할 수 있는 값이면 모두 슈퍼키가 될 수 있다.
후보키
투플을 유일하게 식별할 수 있는 속성의 최소 집합.
투플을 식별할 수 있는 슈퍼키 중에서도 꼭 필요한, 유일하게 구별할 수 있는 키를 말한다.
기본키 (PK, rimary Key)
여러 후보키 중 하나를 선정하여 대표로 삼는 키를 말한다.
후보키가 하나뿐이라면 그 후보키를 사용하면 되고 여러개면 릴레이션의 특성을 반영하여 하나를 선택하면 된다.
기본키는 릴레이션을 대표하므로 선택하기 전에 여러 사항을 고려해야 한다.
기본키의 제약조건으로는 다음과 같다
- 릴레이션내 투플을 식별할 수 있는 고유한 값을 가져야 한다. - NULL 값은 허용하지 않는다. - 키 값의 변동이 일어나지 않아야 한다. - 최대한 적은 수의 속성을 가진 것이라야 한다. - 향후 키를 사용하는데 있어서 문제 발생 소지가 없어야 한다. |
컬럼 중복제거( DISTINCT, GROUP BY) (0) | 2021.07.15 |
---|---|
오라클 DB정렬 (0) | 2021.06.11 |
11/16 수업내용 (0) | 2020.11.16 |
11/13 수업내용 (3일차 마지막부분, 4일차) (0) | 2020.11.13 |
11/12 수업내용 (3일차) (0) | 2020.11.12 |
단어를 밑줄문자로 구분하는 표기법
파일명 및 DB테이블 컬럼에는 스네이크 케이스 사용
예시: baxkground_color, type_name
POJO (Plain Old Java Object ) (0) | 2021.04.11 |
---|---|
AS - IS / TO - BE 분석 (0) | 2021.04.09 |
Get ,Post (0) | 2021.04.07 |
[spring] Rest API (0) | 2021.04.06 |
[java] 접근 제한자 (0) | 2021.04.04 |
클라이언트가 서버로 요청을 보내느 방법인 HTTP Method에는 크게 2가지 방식이 있는데 GET과 POST이다.
get방식은 주소창에 ?뒤에 파라미터가 붙어서 데이터가 넘어간다.
퍼머링트 (permanent link, permalink) :
어떠한 정보를 식별하는 고유한식별자,식별체계
블로그나 게시판, 포럼 등에 올려진 게시물에 어느 경우에나 연결될 수 있는 절대적인 위치의 불변 주소(URL).
GET방식으 간단한 데이터를 URL에 넣도록 설계된 방식으로 데이터를 보내는 양에 한계가 있다.
HTTP자체는 GET방식의 URL길이에 제한을 두고 있지 않지만
브라우저에서 최대 길이를 제한하고 있기 때문이다.
GET방식은 특별히 전송하는 데이터가 없으므로 body부분은 보통 빈 상태로 전송이 되며
header의 내용중 body의 데이터를 설명하는 Content-type 헤더필드도 들어가지 않는다.
GET방식은 캐싱을 이용해 속도를 높이거나 즐겨찾기를 편리하게 사용하기 위해 사용되는 경우가 많다.
( 캐싱이란 한번 접근 후 또 요청할 시 빠르게 접근하기 위해 레지스터에 데이처를 저장시켜 놓는것 이다. )
데이터를 서버로 제출하여 추가 또는 수정하기 위해서 사용하는 방식이다. post방식은 주소창에 파라미터를 보이지 않고 데이터를 넘긴다.
POST방식은 body에 데이터를 넣어서 전송한다.
따라서 header의 필드 중 body의 데이터를 설명하는 Content-Type이라는 헤더필드가 들어가고 어떤 데이터 타입인지 명시해주어야 한다.
데이터를 body에 포함시키는 이점 때문에 메세지 길이의 제한은 없지만
최대 요청을 받는 시간인 Time out이 존재하므로 클라이언트에서 페이지를 요청하고 기다리는 시간이 존재한다.
get은 가져오는것 post는 수행하는것
get은 데이터를 가져와 보여주는 용도
post는 서버의 값이나 상태를 바꾸기 위해서 사용
(더나아가면 restful? )
AS - IS / TO - BE 분석 (0) | 2021.04.09 |
---|---|
카멜케이스, 파스칼케이스, 스네이크케이스 (0) | 2021.04.07 |
[spring] Rest API (0) | 2021.04.06 |
[java] 접근 제한자 (0) | 2021.04.04 |
관점 지향 프로그래민(Aspect Oriented Programming , AOP) (0) | 2021.04.04 |
모바일 기기는 네트워크 전송량이 유선기기보다 떨어지므로 PC에서 동작하는 것과 달리 화면을 그대로 유지하면서 필요한 데이터만 전송받아 빠르게 결과를 표시한다.
스프링에서도 모바일 기기와 연동하는 경우가 많아지면서 데이터만 전송하는 기능을 지원하게 되었고, 자연히 표준화의 필요성이 생겼다.
그 결과 REST라는 방식이 등장했다.
REST란 Representational State Transfer의 약자로 하나의 URI가 고유한 리소스를 처리하는 공통 방식이다.
REST방식으로 제공되는 API를 REST API (또는 RESTful API) 라고 하며 이는 트위터 같은 Open API에서 많이 사용하고 있다.
스프링 3버전에서는 @ResponseBody 애너테이션을 지원하면서 REST 방식의 데이터 처리를 지원 했습니다.
하지만 스프링 4버전에서는 @RestController 애너테이션을 이용해 REST 방식의 데이터 처리를 지원합니다.
전통적인 Spring MVC의 컨트롤러인 @Controller는 주로 View를 반환하기 위해 사용
@RestController는 Spring MVC Controller에 @ResponseBody가 추가된 것입니다. (Controller+ResponseBody)
그래서 RestController의 주용도는 Json 형태로 객체 데이터를 반환하는 용도로 사용한다.
@RestController가 아닌 @Controller로 선언했을때는 메소드 들은 기본적으로 jsp를 표시한다.
여기에 필요한 메소드에 @ResponsBody를 추가해주면 jsp가 아닌 데이터만을 요청한 곳으로 보내줬었다.
@RestController는 별도의 View를 제공하지 않은 채 데이터를 전달하므로 전달 과정에서 예외가 발생할 수 있다.
예외에 대해 좀더 세밀한 제어가 필요할 경우 ResponseEntity 클래스를 사용하면된다.
서버에 데이터를 조회하는 것 뿐만 아니라 추가, 수정, 삭제 기능도 REST방식으로 요청해야 한다.
이떄 서버에 어떤 행위를 요청할 것인가는 HTTP 메서드를 이용해 처리해야 한다.
카멜케이스, 파스칼케이스, 스네이크케이스 (0) | 2021.04.07 |
---|---|
Get ,Post (0) | 2021.04.07 |
[java] 접근 제한자 (0) | 2021.04.04 |
관점 지향 프로그래민(Aspect Oriented Programming , AOP) (0) | 2021.04.04 |
트랜젝션 (0) | 2021.04.02 |
1. attackyourheart.tistory.com/50
이 블로그 참고해서 프로젝트 export하고 war파일로 만들어서 톰캣 파일안에 넣기
2. 아래의 블로그들 참고해서 방화벽, server.xml, 게이트웨이 주소로 들어가서 포트포워딩 해주기
여기까지 하면 와이파이를 이용해서 핸드폰으로 프로젝트에 접속 가능.
3. 핸드폰 와이파이 말고 lte로 접속하는 방법
프로젝트 경로를 수정할려고 같은게 2개 있어서 에러가 난듯하다.
심각: 경로 [/practiceBoard]의 컨텍스트 내의 서블릿 [appServlet]을(를) 위한 Servlet.service() 호출이, 근본 원인(root cause)과 함께, 예외 [Request processing failed; org.mybatis.spring.MyBatisSystemException: org.apache.ibatis.exceptions.PersistenceException
해결
말 그대로 접근을 제한하기 위헤 사용된다.
여기서 말하는 접근이란 클래스 및 인터페이스 그리고 이들이 가지고 있는 멤버의 접근을 말한다.
대부분 main()메소드를 포함한 실행 클래스 외에는 외부 클래스에서 사용할 목적으로 설계된 라이브러리 클래스이다.
외부 클래스에서 사용할 시 라이브러리 클래스가 무분별하게 변경이 될 수 있다면 안전하지않은 클래스이다.
클래스를 안전하게 보호하기 위해서 생성자를 호출하지 못하게 하거나,
객체의 특징 데이터를 보호하기 위해 해당 필드에 접근하지 못하도록,
특정 메소드를 호출할 수 없도록 접근 제한자를 통해 제한할 수 있다.
클래스, 필드, 메소드에 접근제한자 선언 가능.
어떤 경우에는 클래스와 인터페이스를 다른 패키지에서 사용하지 못하도록 막을 필요가 있다.
그리고 객체 생성을 막기 위해 생성자를 호출하지 못하게 하거나
필드나 메소드를 사용하지 못하도록 막아야 되는 경우도 있는데 이럴때 접군 제한자를 사용한다.
접근제한자는 public, protected, private, default가 있다.
만약 클래스나 변수를 선언할 때 아무것도 쓰지 않으면 default 접근제한을 가진다.
클래스가 default를 가지면 같은 패키지에서는 제약없이 사용가능하지만
다른 패키지에서는 사용할 수 없다.
클래스의 접근제한자
클래스의 접근 제한자는 public과 default가 있다.
public은 항상 모든 곳에서 접근 가능
default는 같은 패키지 안에서만 접근 가능
public 클래스의 이름은 클래스 파일 이름과 동일해야 한다.
즉 파일 하나 당 public 클래스는 한개고 나머지는 Default클래스가 된다.
( public클래스가 하나도 없고 모두가 default인 클래스 파일은 존재할 수 있지만
반재도 public클래스가 여러개인 파일은 존재할 수 없다 )
메소드/변수의 접근 제한자
메소드 및 변수의 접근 제한자는 public, protected, default, private가 있다.
Get ,Post (0) | 2021.04.07 |
---|---|
[spring] Rest API (0) | 2021.04.06 |
관점 지향 프로그래민(Aspect Oriented Programming , AOP) (0) | 2021.04.04 |
트랜젝션 (0) | 2021.04.02 |
예외처리 (try,catch, throw, throws) (0) | 2021.04.02 |