ERD2015.05.27 23:50

 

ENTITY란?

1. 우리가 관리하고자 하는 집합

2. 집합(면적) = 가로(속성) * 세로(건수)

3. 독립성을 가진 집합

=> 앞서 정의한 집합과 별도로 정의 되야함.

4. 동질성을 가진 집합

=> 집합의 정의에 따라 동질성이 갖거나 없어 진다.

5. 본질적인 집합

=> 개체 집합, 행위 집합

   

ENTITY의 자격 검증

우리가 관리하고자 하는 이란?

가로축

- 현재 관리되고 있는 항목은?

- 앞으로 관리해야 하지 않는가?

- 구축할 시스템의 목표를 위해서 어떤 관리항목이 필요하는가?

세로축

- 의미상의 주어를 찾아라!

- 개체 구분을 명확히 하라!

- 유형별 개체형태를 도식하라!(Sample 데이터)

- 향후에 발생할 개체형태도 생각해보라!

   

독립성

- 가입자, 납입자는 독립적이지 않아 ENTITY가 아니다

   

동질성

통합이란?

- 어느 것이 가장 최적인지를 판단 해야한다.

동질성 확보의 원칙

- 가능한 공통성 보장 -> 통합

- 의미의 희석 -> 의미가 희석되지 않도록 어떻게 통합해야 하나?

   

KEY ENTITY의 단순화

- 부모들이 분산되어 있으면 자손들은 매우 복잡해 진다.

- 상위 ENTITY는 하위 ENTITY에 지대한 영향을 미친다.(통합)

- 상위로 갈수록 많은 하위에 영향을 미친다.

- 우리는 인수분해, 통분을 해야 한다.(SUBTYPE 지정)

   

하위 ENTITY에서 KEY ENTITY의 도출

- 리버스 모델링시 사용함(현행 시스템이 있을 경우)

- 부모없이 태어난 자손은 없다.

- 의미상의 주어란? ENTITY 탄생에 직접적인 역할을 한 속성들

- 인조키가 아닌 의미상의 주어를 찾아라.

=> 절대 종속인가? 상대 종속인가?(할아버지: 절대 종속, 아버지: 절대 종속)

=> 직접 종속인가? 간접 종속인가?(할아버지: 간접 종속, 아버지: 직접 종속)

의미상의 주어

누가? 데이터 발생 주체
무엇을? 데이터가 발생한 대상

언제? 데이터 발생 시기

어디서? 데이터 발생 장소

 

신고

'ERD' 카테고리의 다른 글

4강. ENTITY 검증 및 단순화  (0) 2015.05.27
3강. ENTITY 분류 및 선정  (0) 2015.05.21
2강. 모델링개요 및 ENTITY 개념 정립  (0) 2015.05.21
1강. 모델링 접근전략  (0) 2015.05.18
Posted by TM ~ing
ERD2015.05.21 01:12

 

ENTITY의 수집

- 가능성이 있으면 도출

- 자격 유무만 판단 하라

- 동의어라도 함부로 버리지 마라

- 개념이 모호한 대상은 인터뷰를 통하여 개념만 파악하라

- 프로세스에 너무 연연하지 마라(중요)

- 예외 경우에 너무 집착하지 마라

- 단어 하나 하나에 집중하여 판단하라

- 핵심적인 특징을 파악해 둬라

- 사용자에 의존 하지 마라

   

수집된 ENTITY의 분류

1. KEY ENTITY

- 대초부터 창조된 실체(주변에 정보가 필요 없음)

- EX) 사원, 부서, 거래처, 자재 등

2. MAIN ENTITY

- 부모로부터 태어난 실체지만 업무의 중심이 되는 실체

- EX) 카드, 공사, 단가, 계약

3. ACTION ENTITY

- 실제 발생하는 업무

- EX) 카드이용, 공사내역, 계약 변경

   

ENTITY의 선정

- 어떤 요소들이 포함되는지를 명확하게 정의

- 명확하지 않으면 추후 많은 혼란 발생

신고

'ERD' 카테고리의 다른 글

4강. ENTITY 검증 및 단순화  (0) 2015.05.27
3강. ENTITY 분류 및 선정  (0) 2015.05.21
2강. 모델링개요 및 ENTITY 개념 정립  (0) 2015.05.21
1강. 모델링 접근전략  (0) 2015.05.18
Posted by TM ~ing
ERD2015.05.21 01:12

 

기본개념 모델링: 골조 공사

상세개념 모델링: 바닥, 전기, 수도 공사 등

   

모델링을 업무를 정의해 놓은 것이다.

   

SYSTEM 개발 과정

1. 데이터 모델링(전략수립, 분석)

  • 업무조사, 업무파악
  • 과정의 툴이다. 즉, 모르는 상태에서 알아가면서 한다.

2. 데이터베이스 설계(설계)

  • DB로 내리는 과정
  • 전체 과정 중에 10% 이상이면 안됨

3. 데이터베이스 생성(개발)

   

데이터모델링이란?

- 관리하고자 하는 유용한 정보와 그 관계를 정의하고 형상화 하는 것(구체적, 상세적)

   

데이터베이스 설계

- ERD에 반영된 정보의 요구사항을 관계형 데이터베이스 설계로 바꾸는 작업

   

데이터베이스 Build

- 작성된 데이터베이스 DESIGN을 이용하여 물리적인 관계형 데이터베이스 테이블을 생성시키는 작업

   

SYSTEM 개발 절차

- 데이터모델링 -> 기능모델링

   

논리적 모델링

- 전략수립 및 분석 단계에서 실시(과정의 툴이다)

- ERD로 구현 하는 것

ENTITY:관리할 대상이 되는 것

RELATIONSHIP:ENTITY 간의 대응관계

ATTRIBUTE:관리할 정보의 구체적 항목

- ERD를 의사소통의 보조자료로 써야 한다.

   

ENTITYES(실체)

- 우리가 관리하고자 하는…

EX) ERP 패키지의 주어는 "모든 회사가 쓰고자 하는?" 이다.

- 객관적인 집합이어야 함

- 집합에 대한 명확한 재정의 필요

- 가로(속성)와 세로(ROW)가 있어야 한다(면적)

신고

'ERD' 카테고리의 다른 글

4강. ENTITY 검증 및 단순화  (0) 2015.05.27
3강. ENTITY 분류 및 선정  (0) 2015.05.21
2강. 모델링개요 및 ENTITY 개념 정립  (0) 2015.05.21
1강. 모델링 접근전략  (0) 2015.05.18
Posted by TM ~ing
MS SQL2015.05.19 13:39

 

[궁금증]

SQL Server의 메모리 설정 값 변경 시 현재 Allocate하고 있는 memory의 반환을 즉시 할 것인가?

아니면 Service 재시작을 통하여 적용될 것인가?

   

[환경]

SQL Server 2014 Ent x64

Min Memory: 1024 MB

Max Memory: 1024 MB

   

변경 Min Memory: 512 MB

변경 Max Memory: 512 MB

   

[Test]

   

1. Memory 축소

   

   

약 5~7초 후 변화

   

2. Memory 증가

   

   

약 5~7초 후 변화

   

[결론]

메모리 축소의 경우 바로 적용이 되어, 사용 가능한 메모리로 반환을 즉시 적용한다. 하지만 메모리 증가의 경우는 Target Server Memory로 즉시 적용되지만, SQL Server 사용에 따라 점점 증가하게 된다.

둘 다 Service 재시작은 필요 없다.

   

[참고]

https://technet.microsoft.com/en-us/library/ms178067(v=sql.105).aspx

신고

'MS SQL' 카테고리의 다른 글

[MSSQL] Memory 적용 시점  (1) 2015.05.19
SQL Server 서버명 변경  (0) 2014.10.15
[MSSQL] SP_RENAME  (0) 2014.07.29
SSIS Access denied 조치 방법  (0) 2014.07.11
CSV 파일 MSSQL에 Import 방법  (0) 2014.07.09
MSSQL Replication(복제) 구성  (0) 2014.06.30
Posted by TM ~ing
Linux2015.05.19 00:02

명령어

사용법

설명

ls

ls

현재 디렉토리의 파일 목록

  

ls /usr/bin

/usr/bin 디렉토리의 파일 목록

  

ls -a

현재 디렉토리의 목록(숨김파일 포함)

  

ls -l

현재 디렉토리의 목록을 자세히 보여줌

  

ls *.txt

현재 디렉토리의 확장자가 txt인 목록을 보여줌

  

ls -l /usr/bin/a*

/usr/bin/ 디렉토리에 있는 목록 중 앞글자가 'a'인 것의 목록을 자세히 보여줌

  

  

  

cd

cd

현재 사용자의 홈 디렉토리로 이동함

  

cd ~root

root 사용자의 홈 디렉토리로 이동함

  

cd ..

바로 상위 디렉토리로 이동

  

cd /usr/bin

/usr/bin 디렉토리로 이동함(절대 경로)

  

cd ../usr/bin

상대 경로로 이동함

  

  

  

pwd

pwd

현재 작업중인 디렉토리의 경로 출력

  

  

  

rm

rm abc.txt

abc.txt 파일 삭제

  

rm -i abc.txt

삭제 시 확인을 물어봄

  

rm -r abc

디렉토리 삭제

  

rm -rf abc

abc 디렉토리와 그 하부를 강제로 전부 삭제

  

  

  

cp

cp abc.txt cba.txt

abc.txt 파일을 cba.txt 파일로 복사

  

cp -r abc cba

디렉토리 복사

  

  

  

touch

touch abc.txt

파일이 없을 경우엔 abc.txt라는 빈 파일을 생성하고, abc.txt가 있을 경우에는 파일의 수정 시간을 현재 시각으로 변경함

  

  

  

mv

mv aaa bbb ccc ddd

aaa, bbb, ccc 파일을 dd디렉토리로 이동

  

mv abc.txt www.txt

이름 변경

  

  

  

mkdir

mkdir abc

현재 디렉토리 아래에 abc라는 디렉토리 생성

  

mkdir -p def/fgh

현재 디렉토리 아래에 def 디렉토리 생성하고, 그 안에 fgh 디렉토리 생성

  

  

  

rmdir

rmdir abc

파일이 없는 디렉토리를 삭제한다. 파일이 있는 디렉토리는 rm -r을 사용해야 한다.

  

  

  

cat

cat install.log

텍스트로 작성된 파일을 화면에 출력한다.

  

  

  

head, tail

head install.log

  

텍스트로 작성된 파일의 앞 10행 출력

  

tail install.log

텍스트로 작성된 파일의 뒤 10행 출력

  

  

  

more, less

more install.log

텍스트로 작성된 파일을 화면에 페이지 단위로 출력한다.

  

more +100 install.log

100행부터 출력해 줌

  

  

  

file

file install.log

어떤 종류의 파일인지를 표시해 준다.

  

  

  

clear

clear

명령창을 깨끗하게 지워준다.

 

신고

'Linux' 카테고리의 다른 글

리눅스(Linux) 기본 명령어  (0) 2015.05.19
Posted by TM ~ing
ERD2015.05.18 23:58

 

프로젝트 성공 3요소

1. 단순 명료한 시스템 설계

2. 생산성을 향상 시키며 핵심 문제를 해결할 수 있는 리더

3. 개발자 인식 전환(집합적인 사고 방식)

   

정보시스템의 전반적인 특징

  • 다양한 H/W
  • 다양한 DB
  • 분리된 Data Model
  • Process 중심
  • 데이터 중복 및 일관성 문제
  • 완벽하지 않은 이력관리

       

잘못된 유형

1. 형제형: 모델링은 1촌 관계만 표현 해야 한다.

2. 족보형: 부계 중심의 형태

3. 네트워크형

   

데이터 모델링 실태

- 책상에 앉아 그리는 풍경화(모델링을 그리면서 실무자와 같이 그려야 함)

- 범인은 앞에서 연설하고, 수사관은 평가(우리는 수사관이 되어야 함)

- 작가는 자신의 작품세계를 표현, 사진사는 있는 그대로를 찍음

   

삼격형의 원리(수평적 사고)

- 각 삼각형마다 100점을 맞으라

- 삼각형의 크기는 항상 동일

- 수평적으로 잘라라(사고의 Buffer 만큼)

- 각 삼각형마다 잘못이 있으면 삼각형의 크기가 커짐

   

데이터 모델링 왜 중요하고 어려운가?

- 데이터 모델 = Application로 접근 해야 한다. 프로그램에서 해결하겠다는 생각은 버려라. 데이터를 깨끗하게 하라.

- 모델링을 전사적으로 해야 한다.

- 명확하고 구체적이고 효율적인 집합을 강조

- 무한한 사용자 요구를 만족해야 한다.

- 대용량 데이터를 관리

신고

'ERD' 카테고리의 다른 글

4강. ENTITY 검증 및 단순화  (0) 2015.05.27
3강. ENTITY 분류 및 선정  (0) 2015.05.21
2강. 모델링개요 및 ENTITY 개념 정립  (0) 2015.05.21
1강. 모델링 접근전략  (0) 2015.05.18
Posted by TM ~ing
MySQL2015.05.15 00:31

 

3. 테이블 컬럼

MySQL의 실행 계획은 단위 SELECT 쿼리 기준이 아니라 테이블 기준으로 표시된다.

테이블 컬럼에 "<>"로 둘러싸인 이름이 명시되는 경우 해당 테이블은 임시 테이블을 의미한다.

   

EXPLAIN

SELECT *

FROM

(SELECT de.emp_no FROM dept_emp de) tb,

employees e

WHERE e.emp_no = tb.emp_no;

   

   

4. type 컬럼

각 테이블 접근 방식으로 해석하면 된다.

   

system

레코드가 1건만 존재하는 테이블 또는 한 건도 존재하지 않는 테이블을 참조하는 형태의 접근 방법(MyISAM, MEMORY 테이블에만 해당)

   

const

쿼리가 프라이머리 키나 유니크 키 칼럼을 이용하는 WHERE 조건 절을 가지고 있으며, 반드시 1건을 반환하는 쿼리 방식

   

EXPLAIN

SELECT * FROM employees WHERE emp_no = 10001;

   

   

eq_ref

조인에서 처음 읽은 테이블의 칼럼 값을 그 다음에 읽어야 할 테이블의 프라이머리 키나 유니크 키 칼럼의 검색 조건에 사용할 때를 eq_ref라고 한다.

   

EXPLAIN

SELECT * FROM dept_emp de, employees e

WHERE e.emp_no =de.emp_no AND de.dept_no = 'd005';

   

   

ref

인덱스의 종류와 관계없이 동등 조건으로 검색할 때는 ref 접근 방법이 사용된다.

   

EXPLAIN

SELECT * FROM dept_emp WHERE dept_no='d005';

   

   

ref_or_null

ref 접근 방식과 같은데, NULL 비교가 추가된 형태다.

   

uinique_subquery

WHERE 조건 절에서 사용될 수 있는 IN (서브쿼리) 형태의 쿼리를 위한 접근 방식으로 중복되지 않은 유니크한 값만 반환할 때 이 접근 방법을 사용 한다.

   

EXPLAIN

SELECT * FROM departments WHERE dept_no IN (SELECT dept_no FROM dept_emp WHERE emp_no=10001);

   

   

index_subquery

IN(서브쿼리)에서 서브쿼리가 중복된 값을 반환할 수는 있지만 중복된 값을 인덱스를 이용해 제거할 수 있을 때 index_subquery 접근 방식이 사용된다.

   

EXPLAIN

SELECT * FROM departments WHERE dept_no IN (

SELECT dept_no FROM dept_emp WHERE dept_no BETWEEN 'd001' AND 'd003');

   

-> 버전이 달라서 실행 계획이 표현이 조금 다름.

   

range

인덱스 레인지 스캔 형태의 접근 방법

   

EXPLAIN

SELECT dept_no FROM dept_emp WHERE dept_no BETWEEN 'd001' AND 'd003';

   

   

index_merge

2개의 이상의 인덱스를 이용해 각각의 검색 결과를 만들어 낸 후 그 결과를 병합하는 처리 방식

   

EXPLAIN

SELECT * FROM employees

WHERE emp_no BETWEEN 10001 AND 11000

OR first_name='Smith';

   

   

index

접근 방식은 인덱스를 처음부터 끝까지 읽는 인덱스 풀 스캔을 의미한다.

   

EXPLAIN

SELECT * FROM departments ORDER BY dept_name DESC LIMIT 10;

   

   

ALL

풀 테이블 스캔을 의미하는 접근 방식

   

5. key_len

인덱스의 각 레코드에서 몇 바이트까지 사용했는지 알려주는 값

   

EXPLAIN

SELECT * FROM dept_emp WHERE dept_no='d005';

   

   

   

   

char

3바이트

integer

4바이트

date

3바이트

   

6. ref

참조 조건으로 어떤 값이 제공됐는지 보여 준다.

const: 상수값

테이블명.칼럼명: 칼럼값

EXPLAIN

SELECT *

FROM employees e, dept_emp de

WHERE e.emp_no = de.emp_no;

   

   

func: 콜레이션 변환, 연산을 거친 값

EXPLAIN

SELECT *

FROM employees e, dept_emp de

WHERE e.emp_no =(de.emp_no-1);

   

   

7. rows

실행 계획의 효율성 판단을 위해 예측했던 레코드 건수를 보여 준다. 예상 값이라 정확하지 않다

   

EXPLAIN

SELECT * FROM dept_emp WHERE from_date >= '1985-01-01';

   

   

EXPLAIN

SELECT * FROM dept_emp WHERE from_date >= '2002-07-01';

   

   

EXPLAIN

SELECT * FROM dept_emp WHERE from_date >= '1985-01-01' LIMIT 10;

   

;

   

>

신고

'MySQL' 카테고리의 다른 글

[Mysql] 변수  (0) 2016.05.19
[Mysql] 제어문  (0) 2016.05.19
[Mysql] 스토어드 함수  (0) 2016.05.17
[Mysql] 스토어드 프로시저  (0) 2016.05.17
[Mysql] 실행계획2  (1) 2015.05.15
[Mysql] 실행계획  (0) 2015.05.11
Posted by TM ~ing
MySQL2015.05.11 19:30

 

1. id 컬럼

- 단위 SELECT 쿼리별 부여되는 식별자 값이다.

- 두개의 테이블을 조인하는 쿼리에서는 같은 id가 부여된다.

EXPLAIN

SELECT e.emp_no, e.first_name, s.from_date, s.salary

FROM employees e, salaries s

WHERE e.emp_no = s.emp_no

LIMIT 10;

   

   

- 쿼리 문장이 3개의 SELECT로 구성돼 있으면 실행 계획의 각 레코드는 각기 다른 id를 부여받는다.

EXPLAIN

SELECT

((SELECT COUNT(*) FROM employees) + (SELECT COUNT(*) FROM departments) ) AS total_count;

   

   

2. select_type 컬럼

어떤 타입의 쿼리인지 표시되는 칼럼

   

SIMPLE

UNION이나 서브 쿼리를 사용하지 않는 단순한 SELECT의 경우

   

PRIMARY

UNION이나 서브 쿼리가 포함된 SELECT 쿼리의 실행 계획에서 가장 바깥쪽에 있는 단위 쿼리

   

UNION

UNION으로 결합하는 단위 SELECT 쿼리 가운데 첫 번째를 제외한 두 번째 이후 단위 SELECT의 select_type

EXPLAIN

SELECT * FROM (

(SELECT emp_no FROM employees e1 LIMIT 10)

UNION ALL

(SELECT emp_no FROM employees e2 LIMIT 10)

UNION ALL

(SELECT emp_no FROM employees e3 LIMIT 10)

) tb;

   

   

DEPENDENT UNION

DEPENDENT UNION은 UNION이나 UNION ALL로 결합된 단위 쿼리가 외부의 영향에 의해 영향을 받는 것을 의미함

*select type에 DEPENDENT가 나오는 쿼리는 비효율적인 경우가 많음

EXPLAIN

SELECT

e.first_name,

(SELECT CONCAT('Salary Change count : ', COUNT(*)) AS message

FROM salaries s WHERE s.emp_no = e.emp_no

UNION

SELECT CONCAT('Department Change count : ' , COUNT(*)) AS message

FROM dept_emp de WHERE de.emp_no = e.emp_no

) AS message

FROM employees e

WHERE e.emp_no=10001;

   

   

UNION RESULT

UNION 결과를 담아두는 테이블을 의미함

EXPLAIN

SELECT emp_no FROM salaries WHERE salary > 100000

UNION ALL

SELECT emp_no FROM dept_emp WHERE from_date > '2001-01-01';

   

   

SUBQUERY

FROM 절 이외에서 사용되는 서브 쿼리

EXPLAIN

SELECT e.first_name,

(SELECT COUNT(*) FROM dept_emp de, dept_manager dm WHERE dm.dept_no=de.dept_no) AS cnt

FROM employees e

WHERE e.emp_no = 10001;

   

   

DEPENDENT SUBQUERY

서브 쿼리가 바깥쪽(Outer) SELECT 쿼리에서 정의된 컬럼을 사용하는 경우

EXPLAIN

SELECT e.first_name,

(SELECT COUNT(*)

FROM dept_emp de, dept_manager dm

WHERE dm.dept_no = de.dept_no AND de.emp_no = e.emp_no) as cnt

FROM employees e

WHERE e.emp_no = 10001;

   

   

DERIVED

서브 쿼리가 FROM 절에 사용된 경우 항상 DERIVED인 실행 계획을 만든다.

MySQL은 FROM 절에 사용된 서브 쿼리를 제대로 최적화하지 못할 때가 대부분이다.

EXPLAIN

SELECT *

FROM (SELECT de.emp_no FROM dept_emp de) tb,

employees e

WHERE e.emp_no=tb.emp_no;

   

--변경후

EXPLAIN

SELECT *

FROM dept_emp de, employees e

where de.emp_no=e.emp_no;

   

   

UNCACHEABLE SUBQUERY

조건이 똑같은 서브 쿼리가 실행될 때는 다시 실행하지 않고 이전의 실행 결과를 그대로 사용할 수 있게 서브 쿼리의 결과를 내부적인 캐시 공간에 담아둔다. 하지만 아래의 요소로 인하여, 해당 캐시를 사용하지 못할 수 있는데 이런 서브 쿼리는 UNCACHEABLE SUBQUERY라 한다.

   

- 사용자 변수가 서브 쿼리에 사용된 경우

- NOT-DETERMINISTIC 속성의 스토어드 루틴이 서브 쿼리 내에 사용된 경우

- UUID()나 RAND()와 같이 결과값이 호출활 때마다 달라지는 함수가 서브 쿼리에 사용된 경우

   

EXPLAIN

SELECT *

FROM employees e

WHERE e.emp_no = ( SELECT @status FROM dept_emp de WHERE de.dept_no ='d005');

   

   

UNCACHEABLE UNION

위의 UNCACHEABLE SUBQUERY가 UNION일 경우 발생하는 실행 계획이다.

신고

'MySQL' 카테고리의 다른 글

[Mysql] 변수  (0) 2016.05.19
[Mysql] 제어문  (0) 2016.05.19
[Mysql] 스토어드 함수  (0) 2016.05.17
[Mysql] 스토어드 프로시저  (0) 2016.05.17
[Mysql] 실행계획2  (1) 2015.05.15
[Mysql] 실행계획  (0) 2015.05.11
Posted by TM ~ing

티스토리 툴바