aking: 개발노트

1. code

$.ajax({

type: 'POST',

url: './module/test.jsp',

//data: {idx: 1},

dataType: 'json',

success: function(result) {

if(result != null) {

console.log(", " + result.data[0].list.ORDER_NO + ", " + result.data[1].list.ORDER_NO + ", ");

} else {

alert("값이 없습니다.");

}

},

error: function(request, status, error) {

alert("CODE: " + request.status + "\n" + "MESSAGE: " + request.responseText + "\n" + "ERROR: " + error);

}

});

2. result

, E20160728125922_427989, E20161215175501_641843,

1. code

  List<Object> list = new ArrayList<Object>();

  JSONObject objTickets = new JSONObject();

  JSONArray arrTickets = new JSONArray();

  JSONObject objs = null;

  String sSql = "";

  String data = "";

  sSql = "SELECT OT.SEQ, OT.ORDER_NO, OT.KCODE, OT.BARCODE, OT.NAME, OT.MDN, ES.RNAME, ES.RMDN ";

  sSql += "FROM ORDER_TICKET OT LEFT OUTER JOIN ETC_SEASON ES ON (OT.SEQ=ES.T_SEQ) ";

  sSql += "WHERE 1=1";

  sSql += "    AND OT.NAME='aking'";

  sSql += "    AND OT.MDN='01000000000'";

  sSql += "    AND OT.STATUS=0";

  list = WebUtils.arrayListColumns_tables(sSql);

  int barCnt = list.size();

  if(!list.isEmpty() || barCnt >= 1) {

    for(int i=0; i < barCnt; i++) {

      objs = new JSONObject();

      objs.put("list", list.get(i));

      arrTickets.put(objs);

      objTickets.put("data", arrTickets);

    }

    data = objTickets.toString();

  } else {

    out.println("FAIL");

  }

  out.println(data);

2. json data

• data: 

   

  [

  •  

    {

    • list: 

       

      {

      • RNAME: "aking",
      • RMDN: "01000000000",
      • KCODE: "28747",
      • NAME: "aking",
      • BARCODE: "2195622600",
      • ORDER_NO: "E20160728125922_427989",
      • SEQ: "1484740",
      • MDN: "01000000000"

      }

    },
  •  

    {

    • list: 

       

      {

      • RNAME: null,
      • RMDN: null,
      • KCODE: "38131",
      • NAME: "aking",
      • BARCODE: "726903271604",
      • ORDER_NO: "E20161215175501_641843",
      • SEQ: "1988489",
      • MDN: "01000000000"

      }

    }

  ]

}

2014/05/19 - [Database/Database System] - Chapter 7

2014/04/13 - [Database/Database System] - Chapter 6

2014/04/28 - [Database/Database System] - Chapter 4

2014/04/11 - [Database/Database System] - Chapter 3

2014/04/11 - [Database/Database System] - Chapter 2

2014/04/11 - [Database/Database System] - Chapter 1

8.1 ER-관계 사상을 이용한 관계 데이터베이스 설계

1. ER관계 사상을 이용한 관계 데이터베이스 설계

2. 엔티티 타입은 릴레이션으로 매핑한다. 엔티티 타입의 키 중에서 하나를 릴레이션의 기본키로 지정한다.

3. 약한 엔티티 타입도 릴레이션으로 매핑하되 소유 릴레이션의 키 속성을 포함시킨다. 생성된 릴레이션의 기본키는 소유 릴레이션의 키와 약한 엔티티타입의 부분키를 합쳐서 만든다.

4. 1:1 이진 관계는 관계에 참여하는 두 릴레이션중에서 어느 하나의 외래키 속성으로 매핑한다.

5. 1:N 이진 관계는 N-side 릴레이션의 외래키 속성으로 매핑하며,1-side의 주 키를 참조하도록 한다.

6. N:M 이진관계는 별도의 릴레이션(이를관계릴레이션이라고부름)으로 생성하고, 관계에 참여하는 두 릴레이션의 기본키를 각각 참조하는 외래키로

애트리뷰트를 구성한다. 이때 두 외래키가 관계 릴레이션의 기본키를 형성한다.

7. 다중값 애트리뷰트는 키를 포함하는 릴레이션으로 매핑된다.

8. n차관계는 관계에 참여하는 n개의 릴레이션의 키들로 구성되는 관계 릴레이션으로 매핑된다. 관계 릴레이션의 애트리뷰트들은 참여 릴레이션의 주 키를 참조하는

외래키들과 관계 속성(들)으로 구성된다.

▼

• 단계 1: 정규 엔티티 타입의 사상

- 엔티티 타입은 릴레이션으로 매핑한다.

- 모든 단순 애트리뷰트를 포함시킨다.

- 엔티티 타입의 키 중에서 하나를 릴레이션의 기본 키로 지정한다.

EMPLOYEE

DEPARTMENT

PROJECT

• 단계 2: 약한 엔티티 타입의 사상

- 약한 엔티티 타입을 릴레이션으로 매핑한다.

- 모든 단순 애트리뷰트를 포함시킨다.

- 소유 릴레이션(owner relation)의 키 속성을 포함시킨다.

- 생성된 릴레이션의 기본 키는 소유 릴레이션의 키와 약한 엔티티 타입의 부분 키를 합쳐서 만든다.

• 단계 3: 이진 1:1 관계 타입의 사상

- 외래키 접근 방식: 한 릴레이션(S)을 선택하여 T의 기본 키를 S에 외래키로 포함, S는 완전참여 릴레이션을 선택하는 것이 좋다.

관계 타입의 모든 단순 애트리뷰트를 S에 포함시킨다. (이 방식이 가장 유용하다, 다음 방식은 참조만 할 것.)

- 합병된 릴레이션 접근 방식: 두 릴레이션을 하나의 릴레이션으로 통합, 두 릴레이션이 모두 완전 참여일 때 좋은 방법

- 교차 참조/관계 릴레이션 접근방식: S와 T를 교차 참조하는 제 3의 릴레이션 R 생성

• 단계 4: 이진 1:N 관계 타입의 사상

- 외래키 접근방식: N측의 릴레이션(S)을 선택하여 1측의 릴레이션 T의 기본키를 S에 외래키로 포함, 관계 타입의 모든 단순 애트리뷰트를 S에 포함시킨다. (권장)

- 교차 참조/관계 릴레이션 접근방식: S와 T를 교차 참조하는 제 3의 릴레이션 R 생성

• 단계 5: 이진 M:N 관계 타입의 사상

- M:N 이진 관계는 별도의 릴레이션(이를 관계 릴레이션이라고 부름)으로 생성하고, 관계에 참여하는 두 릴레이션의 기본 키를 각각 참조하는 외래키로

애트리뷰트를 구성한다. 이 때 두 외래키가 관계 릴레이션의 기본키를 형성한다.

• 단계 6: 다치 애트리뷰트의 사상

- 릴레이션 R의 다치 애트리뷰트는 R의 기본키를 포함하는 새로운 릴레이션으로 매핑된다.

- 새로운 릴레이션의 키는 R의 기본키와 다치 애트리뷰트의 조합이다.

• 단계 7: N차 관계 타입의 사상

- n차 관계는 관계에 참여하는 n개 릴레이션의 키들로 구성되는 관계 릴레이션으로 매핑된다. 관계 릴레이션의 애트리뷰트들은 참여 릴레이션의 기본키를 참조하는

외래키들과 관계 속성(들)으로 구성된다.

ER-관계 사상: COMPANY 데이터베이스를 위한 ER 스키마 다이어그램

ER-관계 사상: 변환 결과 생성된 Relational Schema

8.2 요약

2014/04/13 - [Database/Database System] - Chapter 6

2014/04/28 - [Database/Database System] - Chapter 4

2014/04/11 - [Database/Database System] - Chapter 3

2014/04/11 - [Database/Database System] - Chapter 2

2014/04/11 - [Database/Database System] - Chapter 1

개요

• 개념적 모델링은 데이터베이스 설계에 있어 중요한 단계이다.

• 이 장에서는 개체-관계(Entity-Relationship: ER)모델을 사용한 개념적 모델링 기법을 소개한다.

7.1 데이터베이스 설계를 위한 고수준의 개념적 데이터 모델의 사용

[그림 7.1] 데이터베이스 설계의 주요 단계들을 보여주는 간단한 다이어그램

7.2 간단한 예제 데이터베이스 응용

• COMPANY 데이터베이스의 작은 세계

1. 회사는 여러 부서들로 구성된다. 각 부서마다 고유한 이름, 고유한 번호, 부서를 관리하는 특정 사원이 있다. 사원이 부서를 관리하기 시작한 날짜도 유지한다. 한 부서는 여러 위치에 있을 수 있다.

2. 한 부서는 여러 프로젝트들을 관리한다. 각 프로젝트는 고유한 이름, 고유한 번호, 한 개의 위치를 가진다.

3. 각 사원에 대해서 이름, 사회보장번호, 주소, 급여, 성별, 생년월일을 저장한다. 한 사원은 한 부서에 속하지만, 여러 프로젝트들에 관여할 수 있다.

한 사원이 관여하는 프로젝트들을 그 사원이 소속된 부서가 관리하는 프로젝트가 아니어도 무방하다. 반드시 한 부서의 각 사원이 프로젝트를 위해 일하는 주당 근무 시간을 기록한다. 또한 각 사원의 직속 상사도 유지한다.

4. 보험 목적을 위해서 각 사원의 부양 가족들을 기록한다. 각 부양 가족에 대해서 이름, 성별, 생년월일, 사원과의 관계를 기록한다.

개념적 설계의 결과

[그림 7.2] COMPANY 데이터베이스를 위한 ER 스키마 다이어그램. 표기법은 이 장에서 점진적으로 소개됨

7.3 엔티티 타입, 엔티티집합, 애트리뷰트, 키

• ER 모델은 데이터를 엔티티(개체), 관계, 애트리뷰트(속성) 로 모델링 한다.

• 엔티티와 애트리뷰트

- 엔티티: 실세계에서 독립적으로 존재하는 실체

- 애트리뷰트: 엔티티를 기술하는 속성

[그림 7.3] 두 개의 엔티티(사원 과 회사 )와 애트리뷰트

• 애트리뷰트 유형
  

- 복합 애트리뷰트

- 단순 애트리뷰트

- 단일 값 애트리뷰트

- 다치 애트리뷰트

- 저장된 애트리뷰트

- 유도된 애트리뷰트

[그림 7.4] 복합 애트리뷰트의 계층 구조

• 널 값

- 두가지로 사용됨; '적용할 수 없음'이라는 의미와 '알려지지 않음'의 의미

• 복합(composite) 애트리뷰트

[그림 7.5] 복잡한 애트리뷰트 Address-Phone

• 엔티티 타입: 엔티티 집합

[그림 7.6] 두 엔티티 타입 EMPLOYEE, COMPANY와 각 타입에 속하는 일부 엔티티들

[그림 7.7] Registration과 Vehicle_id라는 두 개의 키 애트리뷰트를 갖는 CAR 엔티티 타입, (a) ER 다이어그램 표기법 (b) 세 개의 엔티티를 갖는 엔티티집합

• 키 애트리뷰트
  

- 각 엔티티마다 서로 다른 값을 가지는 애트리뷰트

- 그림 3.2에서

ㆍCOMPANY 엔티티 타입에서 키 애트리뷰트는 Name

ㆍPERSON 엔티티 타입의 키 애트리뷰트는 SocialSecurityNumber

- 복합키

ㆍ두 개 이상의 애트리뷰트들이 모여서 하나의 키 애트리뷰트 역할을 하는 키

• 값 집합(도메인)

- 각 엔티티에서 애트리뷰트가 가질 수 있는 값들의 집합

ㆍEMPLOYEE의 Age 애트리뷰트의 값 집합은? (16부터 70사이의 정수 집합)

[그림 7.8] COMPANY 데이터베이스를 위한 엔티티 타입들의 초기 설계. 몇몇 애트리뷰트들은 관계로 수정될 것임

COMPANY 데이터베이스에 대한 초기 개념적 설계

1. 엔티티 타입 DEPARTMENT는 Name, Number, Locations, Manager, Manager_start_date 애트리뷰트를 가진다. Locations는 유일한 다치 애트리뷰트이다.

Name과 Number는 각 부서마다 고유하기 때문에 각각 키 애트리뷰트로 지정할 수 있다.

2. 엔티티 타입 PROJECT는 Name, Number, Location, Controlling_department 애트리뷰트들을 가진다. Name과 Number가 각각 키 애트리뷰트이다.

3. 엔티티 타입 EMPLOYEE는 Name, Ssn, Sex, Address, Salary, Birth_date, Department, Supervisor 애트리뷰트들을 가진다. 사용자가 사원 Name의 각 구성요소
(Fname, Minit, Lname)와 Address의 각 구성요소를 참조할 것인지의 여부를 알기 위해서 사용자와 다시 협의해야 한다.

4. 엔티티 타입 DEPENDENT는 Employee, Dependent_name, Sex, Birth_date, Relationship(사원과의 관계) 애트리뷰트들을 가진다.

7.4 관계, 관계 타입, 역할, 구조적 제약조건

• 관계 타입과 관계 인스턴스

- 관계 타입(관계 집합) R은 엔티티 간의 연관들의 집합이다. 그림 7.9에서 WORKS_FOR

- [그림7.9] 관계 WORKS_FOR에서 관계 인스턴스: 7개 (R1 ~ R7)

[그림 7.9] EMPLOYEE와 DEPARTMENT 간의 WORKS_FOR 관계 타입을 나타내는 WORKS_FOR 관계집합 내의 일부 인스턴스

• 관계 타입의 차수(degree): 관계에 참여하고 있는 엔티티 타입의 수
  

- 이진(binary) 차수: [그림 7.9]의 WORKS_FOR 관계

- 3진(ternary) 차수: [그림 7.10] 3진 관계 SUPPLY

[그림 7.10] SUPPLY 3진 관계집합 내의 일부 관계 인스턴스

• 애트리뷰트로서의 관계: 관계는 참여 엔티티 타입의 속성으로 볼 수도 있음

ㆍ예: (EMPLOYEE의 DEPARTMENT 또는 DEPARTMENT의 EMPLOYEE)

• 역할과 순환적(recursive) 관계

- [그림 7.11] EMPLOYEE에서의 순환적 관계 SUPERVISION은 상사(1)와 부하(2)의 두 역할로 구분할 수 있음.

[그림 7.11] 상사 역할(1)의 EMPLOYEE와 부하 역할(2)의 EMPLOYEE 간의 순환적 관계 SUPERVISION

• 관계 타입에서 제약조건

- 카디날리티 비율: 관계 인스턴스에 참여하는 엔티티의 개수의 비율(이진 관계 타입에 대한 카디날리티 비율은 1:1, 1:N, N:M)

- 참여 제약조건: 한 엔티티의 존재가 관계 타입을 통해 연관되어 있는 다른 엔티티에 의존하는지의 여부(부분참여와 전부참여)

- MANAGER 관계: EMPLOYEE는 부분 참여하고, DEPARTMENT는 전부 참여한다.

[그림 7.12] 1:1 관계 MENAGES

• 관계 타입의 애트리뷰트

- 1:1, 1:N 관계 타입의 애트리뷰트

ㆍMANAGES의 Start_date [그림 7.12], WORKS_FOR의 Start_date [그림 7.9]

- M:N 관계 타입

ㆍWORKS_ON의 Hours [그림 7.13]

- [그림 7.13] M:N 관계 WORKS_ON

[그림 7.13] M:N 관계 WORKS_ON

7.5 약한 엔티티 타입(Weak Entity Type)

• 자신의 키 애트리뷰트가 없는 엔티티 타입

- 예: DEPENDENT 엔티티 타입

• 식별(소유) 엔티티 타입과 식별 관계

- EMPLOYEE와 DEPENDENT에서 EMPLOYEE가 식별 엔티티 타입이며, 두 엔티티 타입 사이의 관계를 식별 관계라고 부른다.

• 부분 키

- 동일한 소유 엔티티와 연관된 약한 엔티티 집합 내의 서브 집합(예를 들어 소유 엔티티 EMPLOYEE e1의 DEPENDENTS SET) 내에서 서로를 구분할 수 있는 애트리뷰트들의 집합(예를들어, Dependent.name)

• 약한 엔티티는 소유 엔티티 타입의 복합 속성으로 표현될 수도 있으나 다음의 경우에는 별도의 엔티티 타입으로 표현하는 것이 바람직하다.

1. 엔티티가 많은 애트리뷰트들을 가지고,

2. 식별 관계 타입 외에 다른 관계 타입들에 독립적으로 참여하는 경우

7.6 COMPANY DB에 대한 ER 설계의 개선

• [그림 7.8]에서 관계를 나타내는 애트리뷰트들을 관계 타입으로 변환하여 발전시킨다.
• 생성되는 관계 타입들

1. MANAGES: EMPLOYEE와 DEPARTMENT 사이의 1:1관계 타입

2. WORKS_FOR: DEPARTMENT와 EMPLOYEE 사이의 1:N 관계 타입

3. CONTROLS: DEPARTMENT와 PROJECT 사이의 1:N 관계 타입

4. SUPERVISION: EMPLOYEE(상사역할)와 EMPLOYEE(사원역할) 사이의 1:N 관계 타입

5. WORKS_ON: EMPLOYEE와 PROJECT 사이의 M:N 관계 타입

6. DEPENDENT_OF: EMPLOYEE와 DEPENDENT 사이의 1:N 관계 타입

7.7 ER 다이어그램, 이름 지정에 관한 규칙, 설계에 관한 사항

[그림 7.14] ER 다이어그램의 표기법 요약

• 스키마에 사용된 각 구조물에 대해 가능한 한 그 의미를 전달할 수 있는 이름 선택
• 복수보다 단수 이름 선택
• 일반적으로 자연어로 기술된 요구 사항에서 명사는 엔티티 타입 이름, 동사는 관계 타입 이름으로 해석하는 것이 도움이 된다.
• ER 다이어그램은 왼쪽에서 오른쪽, 위에서 아래로 읽기 쉽게 작성한다.
• 스키마 설계는 반복해서 개선하는 작업이 필요하다 - 한번에 완성하기는 쉽지 않다.
• 다음 TP에서는 ER 다이어그램의 또 다른 표기법 소개

[그림 7.15] 구조적 제약조건들을 (min, max) 형식으로 명시한 COMPANY 스키마의 ER 다이어그램과 역할 이름 다이어그램

7.8 3차 이상의 관계 타입

• 관계 타입의 차수: 참여하는 엔티티 타입의 수

- 이진 관계, 3진 관계 등

• 3진 관계 예제: 부품공급(SUPPLY)

[그림 7.16] 삼진 관계 타입, (a) SUPPLY 관계, (b) SUPPLY와 같지 않은 세 개의 이진 관계, (c) 약한 엔티티 타입으로 표현된 SUPPLY

(a): (s1, p1, j1) 관계 표현

(b): (s1, p1) (p1, j1) (j1 p1) 관계가 있어도 (s1, p1, j1) 관계를 표현하지 못할 수도 있다.

• 3진 관계 예제: 부품공급(SUPPLY) (계속)

• 3진 관계 예제: 강좌개설 (OFFERS)

ER Model

- 가장 대중적으로 사용되는 고수준 개념 데이터 모델

ER Diagrams

- ER모델을 그림 형식으로 표현하는 표기법

논리적 모델의 하나의 instance

- 계층형/망형 -> 관계형모델 -> 객체지향 -> 객체관계형

논리적 모델

개발자가 대상을 논리적으로 식별하고 조작하는 수단을 제공

고수준(~보다 높은)은 논리설계를 뜻 함.

개발자와 사용자간에 커뮤니티케이션을 돕기 위해 만드는 설계를 개념적 설계라한다.

개념적 설계까지는 DBMS로부터 독립적이다.

논리적 설계부터는 DBMS에 의존한다.

n-ary 관계성은 n개의 binary 관계로 환원되어야 한다.

1. 사용자를 추가하기 위해서는 반드시 루트(root) 계정이 있어야한다. 그러므로 최고 관리자인 root로 MySQL에 접속한다.

2. 사용자 계정을 생성해준다.

위 그림은 root와 같은 모든 권한을 가지는 계정으로 'aking' 이라는 사용자를 '1q2w3e' 라는 비밀번호를 갖도록 하여 추가한 것으로

로컬호스트에서 접속을 할 경우에만 사용된다.

3. 스키마 생성

'Company' 라는 이름의 스키마를 생성한다.

4. 생성한 스키마 확인방법

Database 리스트에 company가 있는것을 확인할 수가 있다.

5. 생성한 company 스키마에 접속

6. 스키마 삭제하기

* MySQL에 변경사항이 있을 경우 적용을 해줘야 한다. flush privileges; 는 그 역할을 해준다.