제2절 엔터티(Entity)

1. Entity 의 개념

• Entity : 실체, 객체

• 옛날 할부지들이 정의한 Entity
  • 변별할수 있는 사물 - Peter Chen (1976) -
  • 데이터베이스 내에서 변별 가능한 객체 - C.J Date (1986) -
  • 정보를 저장할 수 있는 어떤 것 - James Martin (1989) -
  • 정보가 저장될 수 있는 사람, 장소, 물건, 사건 그리고 개념 등 - Thomas Bruce (1992) -

• 위 정의들의 공통점
  • 엔터티는 사람, 장소, 물건, 사건, 개념등의 명사에 해당한다.
  • 엔터티는 엄무상 관리가 필요한 관심사에 해당한다.
  • 엔터티는 저장이 되기 위한 어떤 것이다.

2. Entity 와 Instance 에 대한 내용과 표기법

• Entity(객체), Instance(사례, 경우)
• Entity 는 Instance 의 집합

3. Entity 의 특징

가. 업무에서 필요로 하는 정보

• 반드시 해당 업무에서 필요하고, 관리하고자 하는 정보이어야 한다.

  병원시스템	Entity	인사시스템
  O	환자	X
  X	토익점수	O

나. 식별이 가능해야 함

• 유일한 식별자에 의해 식별이 가능해야 한다.

다. Instance 의 집합

• 영속적으로 존재하는 Instance 의 집합
• 2개 이상의 Instance 의 집합
• 1개의 Instance 로 이루어진 _집합_은 Entity 가 아니다.

라. 업무 프로세스에 의해 이용

• 업무 프로세스가 반드시 그 Entity 를 이용해야 한다.

마. 속성을 포함

• Entity 에는 반드시 속성(Attributes)이 포함되어야 한다.
• 식별자만 존재하고 일반 속성이 전혀 없는 객체는 Entity 가 될 수 없다.
  단, 관계 Entity 의 경우엔 주 식별자 속성만으로도 Entity 로 인정

바. 관계의 존재

• Entity 는 다른 Entity 와 최소 한개 이상의 관계가 존재하여야 한다.
• 데이터모델링에서 관계를 생략하여 표현하는 경우
  • 1) 통계를 위한 데이터 : 통계만을 위한 Read Only Table
  • 2) 코드성 Entity
    • 너무 많은 Entity 들과의 관계로 데이터 모델이 복잡해짐
    • 일반적으로 코드 테이블에 FK 를 설정하지 않는 경우가 대부분이다.
  • 3) 시스템 처리시 내부적으로 필요한 Entity : 로그 테이블

4. Entity 의 분류

가. 유무(有無)형에 따른 분류

나. 발생시점(發生時點)에 따른 분류

다. Entity 분류 방법의 예

5. Entity 의 명명

• 가능하면 현업업무에서 사용하는 용어를 사용
• 가능하면 약어를 사용하지 않는다.
• 가능하면 단수명사를 사용한다.
• 모든 Entity 에서 유일하게 이름이 부여되어야 한다.
• Entity 생성의미대로 이름을 부여한다.

문서정보

• 이 문서는 구루비에서 작성하였습니다.
• 이 문서를 다른 블로그나 홈페이지에 게재하실 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^^
• 출처 : http://wiki.gurubee.net/pages/viewpage.action?pageId=26743402&
• 구루비 지식창고의 모든 문서는 크리에이티브 커먼즈의 저작자표시-비영리-동일조건변경허락(BY-NC-SA) 라이선스에 따라 자유롭게 사용할 수 있습니다.

제1절 데이터 모델의 이해

1. 모델링의 이해

가. 모델링의 정의

• 모델링에 대한 다양한 정의
  • Webster 사전
    • 가설적 일정 양식에 맞춘 표현
    • 어떤 것에 대한 예비표현으로, 그로부터 최종대상이 구축되도록 하는 계획으로서 기여하는 것
  • 복잡한 '현실세계'를 단순화시켜 표현하는 것
  • 모델이란 사물 또는 사건에 관한 양상(Aspect)이나 관점(Perspective)을 연관된 사람이나 그룹을 위하여 명확하게 하는 것이다.
  • 모델이란 현실 세계의 추상화된 반영이다.

나. 모델링의 특징

• 모델링의 재정의 : 현실세계를 추상화, 단순화, 명확화하기 위해 일정한 표기법에 의해 표현하는 기법
• 정보시스템 구축에서의 모델링 활용
  • 계획/분석/설계 단계 : 업무를 분석하고 설계하는데 이용
  • 구축/운영 단계 : 변경과 관리의 목적으로 이용

다. 모델링의 세 가지 관점

2. 데이터 모델의 기본개념의 이해

가. 데이터 모델링의 정의

• 모델링에 대한 다양한 정의
  • 정보시스템을 구축하기 위해, 해당 업무에 어떤 데이터가 존재하는지 또는 업무가 필요로 하는 정보는 무엇인지를 분석하는 방법
  • 기업 업무에 대한 종합적인 이해를 바탕으로 데이터에 본재하는 업무 규칙(Business Rule)에 대하여 참(True) 또는 거짓(False)을 판별할 수 있는 사실(사실명제)을 데이터에 접근하는 방법(How), 사람(Who), 전산화는 별개(독립적인)의 관점에서 이를 명확하게 표현하는 추상화 기법

• 실무적 관점(정보시스템 구축)에서의 데이터 모델링을 하는 주요 이유
  • 정보시스템 구축 대상이 되는 업무 내용을 정확하게 분석하는 것
  • 분석된 모델을 가지고 실제 데이터베이스를 생성하여 개발 및 데이터관리에 사용하기 위한 것
  • 단지 데이터베이스 구축만이 목적이 아니라 데이터 모델링 자체로서 업무를 설명하고 분석하는 부분에도 중요한 의미를 가지고 있음.

• 데이터 모델링이란
  • 정보시스템을 구축하기 위한 데이터 관점의 업무분석 기법
  • 현실세계의 데이터(Whet)에 대해 약속된 표기법에 의해 표현하는 과정
  • 데이터베이스를 구축하기 위한 분석/설계의 과정

나. 데이터 모델이 제공하는 기능

• 업무를 분석하는 관점에서 데이터 모델이 제공하는 기능
  • 시스템을 현재 또는 원하는 모습으로 가시화하도록 도와준다.
  • 시스템의 구조와 행동을 명세화 할 수 있게 한다.
  • 시스템을 구축하는 구조화된 틀을 제공한다.
  • 시스템을 구축하는 과정에서 결정한 것을 문서화한다.
  • 다양한 영역에 집중하기 위해 다른 영역의 세부사항은 숨기는 다양한 관점을 제공한다.
  • 특정 목표에 따라 구체화된 상세 수준의 표현방법을 제공한다.

3. 데이터 모델링의 중요성 및 유의점

가. 파급효과(Leverage)

• 시스템 구축이 완성되가는 시점에서의 데이터 모델 변경은 엄청난 파급효과를 발생시킨다.
• 데이터 구조변경에 따른 표준영향분석, 응용영향분석등 많은 영향 분석이 일어난다.
• 변경해야할 데이터 형태에 따른 영향도는 차이가 있겠지만, 
  구조 변경으로 인한 일련의 변경작업은 전체 시스템 구축 프로젝트에서 큰 위험요소이다.
• 따라서, 데이터 설계는 그만큼 중요하다.

나. 복잡한 정보 요구사항의 간결한 표현(Conciseness)

• 데이터 모델은 구축할 시스템의 정보 요구사항과 한계를 가장 명확하고 간결하게 표현할 수 있는 도구이다.

다. 데이터 품질(Data Quality)

• 데이터는 중요한 자산이며, 기간이 오래될수록 활용가치는 더 커진다.
• 그러나, 데이터의 정확성이 떨어진다면? 데이터의 활용가치는 떨어지게 된다.
• 따라서 데이터 모델링을 할때는 다음을 유의하여 데이터 품질을 높여야 한다.
  • 중복(Duplication) : 동일 자료의 중복
  • 비유연성(Inflexibility) : 잘못된 데이터 모델은 사소한 업무변화에 대응하지 못하고 유지보수에 어려움이 따른다.
  • 비일관성(Inconsistency) : 데이터의 모순, 데이터간 상호 연관관계에 대한 정확한 정의로 이러한 위험을 예방

4. 데이터 모델링의 3단계 진행

가. 개념적 데이터 모델링(Conceptual Data Modeling)

나. 논리적 데이터 모델링(Logical Data Modeling)

다. 물리적 데이터 모델링(Physical Data Modeling)

5. 프로젝트 생명주기(Life Cycle)에서 데이터 모델링

6. 데이터 모델링에서 데이터독립성의 이해

가. 데이터독립성의 필요성

• 데이터 독립성 필요
  • 유지보수 비용 증가
  • 데이터 중복성 증가
  • 데이터 복잡도 증가
  • 요구사항 대응 저하

나. 데이터베이스 3단계 구조

다. 데이터독립성 요소

라. 두 영역의 데이터독립성

마. 사상(Mapping)

7. 데이터 모델링의 중요한 세 가지 개념

가. 데이터 모델링의 세 가지 요소

• 업무가 관여하는 어떤 것(Things)
• 어떤 것이 가지는 성격(Attributes)
• 업무가 관여하는 어떤것 간의 관계(Relationships)

나. 단수와 집합(복수)의 명령

8. 데이터 모델링의 이해관계자

가. 이해관계자의 데이터 모델링 중요성 인식

나. 데이터 모델링의 이해관계자

9. 데이터 모델링의 표기법인 ERD의 이해

가. 데이터 모델 표기법

나. ERD(Entity Relationship Diagram) 표기법을 이용하여 모델링하는 방법

1) ERD 작업순서

• 1. 엔터티를 그린다.
• 2. 엔터티를 적절하게 배치한다.
• 3. 엔터티간 관계를 설정한다.
• 4. 관계명을 기술한다.
• 5. 관계의 참여도를 기술한다.
• 6. 관계의 필수여부를 기술한다.

2) 엔터티 배치

• 좌에서 우로, 위에서 아래로
• 가장 중요한 고객과 주문을 좌측 상단에 배치
• 주문에 따른 출고 및 재고 를 주문의 아래에 차례로 배치
• 업무 흐름의 중심이 되는 엔터티(주문, 출고, 주문목록, 출고목록)를 중앙에 배치
• 중심 엔터티와 관계있는 엔터티(창고, 고객, 사원, 재고)를 주위에 배치

3) ERD 관계의 연결

• 서로 관련있는 엔터티간의 관계를 설정
• 초기에는 모두 PK 로 속성이 상속되는 식별자 관계를 설정
• 중복관계, Cycle 관계 등을 유의

4) ERD 관계명의 표시

• 관계이름은 현재형을 사용
• 지나치게 포괄적인 용어(예, 이다, 가진다 등)은 사용하지 않도록
• 실무에서는 생략해도 무방 - 관계명이 없어도 ERD의 흐름을 알 수 있다.

5) ERD 관계 관계차수와 선택성 표시

관계	선택성	IE 표기법	Barker 표기법
1 : 1	필수
1 : 1	선택
1 : n	필수
1 : n	선택

10. 좋은 데이터 모델의 요소

가. 완전성(Completeness)

• 업무에서 필요로 하는 모든 데이터가 모델에 정의되어 있어야 한다.

나. 중복배제(Non-Redundancy)

• 하나의 데이터베이스에 동일한 사실은 반드시 한번만 기록되어야 한다.
• 중복시 문제점
  • 저장공간의 낭비
  • 일관성 유지를 위한 추가 비용 발생

다. 업무규칙(Business Rules)

• 업무규칙(Business Rules)을 데이터 모델링에 표현하고, 모든 사용자가 공유한다.
• 모든 사용자(개발자, 관리자)가 해당 규칙에 대해 동일하게 판단하고 데이터를 조작할 수 있게 된다.
• 업무규칙이 명확하게 표현되지 않았다면
  • 각각의 사용자가 같은 업무를 다르게 판단 할 수 있다.

라. 데이터 재사용(Data Reusability)

• 통합성
  • 과거 시스템은 각각의 업무 영역별 데이터 별도 관리
  • 전사적 관점에서 공통데이터를 도출하고 이를 전 영역에서 사용하기 적절한 형태로 설계하여야 한다.
  • 이러한 통합 데이터 모델이어야 데이터 재사용성을 향상시킬 수 있다.

• 독립성
  • 과거 시스템은 데이터 모델이 별도로 없이 어플리케이션의 부속품 정도로 여겨졌다.
  • 이경우 데이터는 각각의 업무 프로세스에 종속적일수밖에 없고
  • 중복데이터 발생, 일관성 저하, 재사용성이 떨어지게 된다.
  • 따라서 데이터가 어플리케이션에 독립적으로 설계되어야만 데이터 재사용성을 향상시킬 수 있다.

• 확장성, 유연성
  • 정보시스템은 비즈니스 변화에 대해 최적의 적응을 요구한다.
  • 비즈니스 변화에 유연하게 대처하고 확장이 용이한 데이터 설계가 필요하다
  • 확장성, 유연성이 떨어질 경우 작은 업무 변경에도 시스템 기반이 흔들리게 된다.

• 합리적 균형이 있으면서도 단순하게 분류하는 것
  • 예를 들면, 동일한 계약 업무를 수행하기 위한 테이블이 A보험사는 10개, B보험사는 100개라면?
  • A사의 데이터 모델은 단순하지만 새로운 업무환경 변화에 대해서 확장성을 가지고 있다.
  • B사는 업무환경 변화(신규상품출현 등)에 적응하지 못하고 데이터 모델의 한계로 테이블 갯수를 늘려왔다.
  • 간결한 모델의 전제조건은 통합.

마. 의사소통(Communication)

• 데이터 모델은 대상 업무를 데이터 관점에서 분석하고 설계하여 나오는 최종 산출물이다.
• 분석과정에서 도출되는 수많은 업무 규칙들은 최대한 자세하게 표현되어야 한다.
• 모든 관련자들이 데이터 모델을 통해 의사소통을 할 수 있도록 자세하게 기술해야 한다.

바. 통합성(Integration)

• "라. 데이터 재사용" 부분 참조.

문서정보

• 이 문서는 구루비에서 작성하였습니다.
• 이 문서를 다른 블로그나 홈페이지에 게재하실 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^^
• 출처 : http://wiki.gurubee.net/pages/viewpage.action?pageId=26743267&
• 구루비 지식창고의 모든 문서는 크리에이티브 커먼즈의 저작자표시-비영리-동일조건변경허락(BY-NC-SA) 라이선스에 따라 자유롭게 사용할 수 있습니다.

다음 문제를 풀어보세요.

하위 쿼리를 시작하는 비교 연산자는 ALL 또는 ANY 키워드에 의해 수정될 수 있습니다. SOME은 ANY의 ISO 표준 동의어입니다.

수정된 비교 연산자로 시작하는 하위 쿼리는 0개 이상의 값 목록을 반환하고 GROUP BY나 HAVING 절을 포함할 수 있습니다. 이러한 하위 쿼리는 EXISTS를 사용하여 다시 작성할 수 있습니다.

> 비교 연산자를 예로 들면 >ALL은 모든 값보다 크다는 것을 의미합니다. 즉, 최대값보다 크다는 것을 나타냅니다. 예를 들어 >ALL (1, 2, 3)은 3보다 크다는 것을 의미합니다. >ANY는 적어도 하나의 값보다 큼 즉, 최소값보다 크다는 것을 의미합니다. 따라서 >ANY (1, 2, 3)은 1보다 큼을 의미합니다.

>ALL이 있는 하위 쿼리의 행이 외부 쿼리에 지정된 조건을 만족시키려면 하위 쿼리를 시작하는 열의 값이 하위 쿼리에서 반환되는 값 목록의 모든 값보다 커야 합니다.

마찬가지로 >ANY가 있는 행이 외부 쿼리에 지정된 조건을 만족시키려면 하위 쿼리를 시작하는 열의 값이 하위 쿼리에서 반환되는 값 목록에서 하나 이상의 값보다 커야 합니다.

다음은 ANY로 수정된 비교 연산자로 시작하는 하위 쿼리를 보여 주는 예입니다. 이 쿼리에서는 가격이 제품 하위 범주의 최대 가격보다 크거나 동일한 제품을 찾습니다.

USE AdventureWorks2008R2;
GO
SELECT Name
FROM Production.Product
WHERE ListPrice >= ANY
    (SELECT MAX (ListPrice)
     FROM Production.Product
     GROUP BY ProductSubcategoryID) ;

각각의 Product 하위 범주마다 내부 쿼리는 최대 가격을 찾습니다. 외부 쿼리는 이러한 값 모두를 찾고 Product 하위 범주의 최대 가격보다 크거나 동일한 개별 제품의 가격을 확인합니다. ANY를 ALL로 변경하면 가격이 내부 쿼리에서 반환된 모든 가격보다 크거나 동일한 제품만 반환됩니다.

하위 쿼리에서 반환된 값이 없으면 전체 쿼리에도 반환 값이 없습니다.

=ANY 연산자는 IN과 동일합니다. 예를 들어 IN 또는 =ANY를 사용하여 Adventure Works Cycles에서 만드는 모든 바퀴 제품의 이름을 찾을 수 있습니다.

--Using =ANY
USE AdventureWorks2008R2;
GO
SELECT Name
FROM Production.Product
WHERE ProductSubcategoryID =ANY
    (SELECT ProductSubcategoryID
     FROM Production.ProductSubcategory
     WHERE Name = 'Wheels') ;

--Using IN
USE AdventureWorks2008R2;
GO
SELECT Name
FROM Production.Product
WHERE ProductSubcategoryID IN
    (SELECT ProductSubcategoryID
     FROM Production.ProductSubcategory
     WHERE Name = 'Wheels') ;

각 쿼리의 결과 집합은 다음과 같습니다.

Name
--------------------------------------------------
LL Mountain Front Wheel
ML Mountain Front Wheel
HL Mountain Front Wheel
LL Road Front Wheel
ML Road Front Wheel
HL Road Front Wheel
Touring Front Wheel
LL Mountain Rear Wheel
ML Mountain Rear Wheel
HL Mountain Rear Wheel
LL Road Rear Wheel
ML Road Rear Wheel
HL Road Rear Wheel
Touring Rear Wheel

(14 row(s) affected)

그러나 < >ANY 연산자는 NOT IN과는 다릅니다. < >ANY는 not = a, or not = b, or not = c를 의미하지만 NOT IN은 not = a, and not = b, and not = c를 의미합니다. <>ALL은 NOT IN과 동일한 의미입니다.

예를 들어 다음 쿼리는 영업 직원이 담당하지 않는 지역에 있는 고객을 찾습니다.

Use AdventureWorks2008R2;
GO
SELECT CustomerID
FROM Sales.Customer
WHERE TerritoryID <> ANY
    (SELECT TerritoryID
     FROM Sales.SalesPerson) ;

고객에게 할당된 모든 지역을 영업 직원이 담당하기 때문에 결과에는 영업 지역이 NULL인 고객을 제외한 모든 고객이 포함됩니다. 내부 쿼리가 영업 직원의 담당 영업 지역을 모두 찾은 후 외부 쿼리가 각 지역마다 해당 지역에 없는 고객을 찾습니다.

이와 같은 이유로 이 쿼리에서 NOT IN을 사용하면 결과에 아무 고객도 포함되지 않습니다.

NOT IN에 해당하는 < >ALL 연산자를 사용해도 동일한 결과를 얻을 수 있습니다.

◎ 연재기사 ◎ 

▷ 물탱크 구조로 알아본 오라클의 블록 옵션 ‘PCTFREE와 PCTUSED’ 
▷ 이산가족 찾기 생방송을 통해 배우는 DB 원리 
▷ 개발자에게 맞는 DB 공부방법 찾기: 물리적 분류와 논리적 분류 그리고 인덱스 
▷ 데이터베이스 인덱스의 오해와 진실 
▷ 쉬운 것이 올바른 것이다. ‘인덱스 끝장리뷰’ (상)
▷ 쉬운 것이 올바른 것이다. ‘인덱스 끝장리뷰’ (하)
▷ 누구도 알려주지 않았던 ‘오라클 인덱스 생성도’의 비밀
▷ 누구도 알려주지 않았던 ‘오라클 쿼리 작성의 비법’
▷ 퀴리 최적화 및 튜닝을 위한 오라클 공정쿼리 작성법
▷ 만능 쿼리와 한 방 쿼리
▷ 오라클 옵티마이저 ‘CBO와 RBO’ 이해하기
▷ 재미있는 DB 이야기 ‘60갑자와 쿼리’
▷ 그림으로 배우는 ‘오라클 조인의 방식’ 이야기
▷ 반드시 알아야 하는 오라클 힌트절 7가지
▷ 오라클 플랜을 보는 법
▷ 개발자들의 영원한 숙제 ‘NULL 이야기’ 
▷ 알면 유용한 오라클 기능 ‘GATHER_PLAN_STATISTICS’
▷ 알면 유용한 오라클 기능들 
▷ 오라클 DICTIONARY를 활용한 DB툴 프로그램 ‘FreeSQL’ 
▷ 이제는 말할 수 있다: 주식 자동매매 프로그램(상) 
▷ 이제는 말할 수 있다: 주식 자동매매 프로그램(하) 
▷ 개발자들이 자주 접하는 오라클 에러 메세지 
▷ 재미있는 DB 이야기 ‘사라진 날짜를 찾아라’
▷ 오라클 랜덤 함수와 사용자 정의 함수
▷ 그림으로 배우는 ‘공정쿼리와 인덱스 생성도’
▷ 이병국의 개발자를 위한 DB 이야기: 디폴트 세팅의 함정과 오라클 파라미터
▷ 재미있는 DB 이야기 ‘놀라운 마방진의 세계’
▷ 오라클 운반 최소 단위 BLOCK
▷ 이병국의 개발자를 위한 DB 이야기: 이세돌과 알파고의 세기의 대결
▷ 이병국의 개발자를 위한 DB 이야기(30회) : DB 엔지니어의 가볍게 읽는 세상 이야기
▷ 이병국의 개발자를 위한 DB 이야기: 튜닝(31회) : 개발자를 위한 DB 튜닝 실전(1편)
▷ 이병국의 개발자를 위한 DB 이야기: 튜닝(32회) : 개발자를 위한 튜닝 실전(2편)
▷ 이병국의 개발자를 위한 DB 이야기: 튜닝(33회) : 개발자를 위한 튜닝 실전(3편)
▷ 이병국의 개발자를 위한 DB 이야기: 튜닝(34회) : 개발자를 위한 DB 튜닝 실전(4편)
▷ 이병국의 개발자를 위한 DB 이야기: 튜닝(35회) : 개발자를 위한 튜닝 실전(5편)
▷ 이병국의 개발자를 위한 DB 이야기: 페이징 처리에 대한 이해 (36회)
▷ 보기 좋은 떡이 먹기도 좋다 - 좋은 쿼리 좋은 성능
▷ 테이블의 수직분할과 수평분할에 대한 이해

기출문제는 한국데이터진흥원에서 공식 문제집을 발간한 "SQL 자격검정 실전문제" 을 온라인몰에서 판매하고 있습니다. 가격은 대략 17,000원 정도입니다.

교재는 한국데이터진흥원에서 발간한 "SQL 전문가 가이드" 을 온라인몰에서 판매하고 있습니다. 가격은 대략 45,000원 정도입니다. 교재는 구입하지 않고 웹페이지에서도 볼수 있습니다. "http://www.gurubee.net/bookcafe/sqlp_1st" 입니다.

1. 데이터 전문가 지식포탈(http://www.dbguide.net)에 접속

2. 우측 상단 메뉴에서 "데이터자격시험 > 국가공인 SQL전문가" 클릭

"자격소개", "시험주요내용", "출제문항및배점", "응시자격및합격기준"을 볼수 있습니다.

"시험일정" 도 잘 찾아보면 있으니, 참고하시면 됩니다.