SQL study [21.08.11]

SQL study [21.08.11]

---

DB : Data Base 
   - 대규모의 정보를 사용하고 관리할 수 있도록 체계적으로 관리한 것

   - 필요에 의해 데이터를 일정한 형식으로 저장을 해 놓은 것을 DB라고 한다.

 

DBMS : Data Base Management System
   - 사용자가 정보를 편리하고 효과적으로 검색하고 저장할 수 있는 환경을 제공 해 주고 있다.

   - 정보를 안전하게 저장할 수 있도록 해 주는 시스템

 

모델링 (Modeling)
   - 추상화 : 현실 세계를 일정한 형식에 맞추어 표현한다.
   - 단순화 : 복잡한 현실을 제한된 언어나 표기법을 통해 이해하기 쉽게 만든다.
   - 정확화 : 애매모호함을 배제하고 누구나 이해가 가능하도록 정확하게 현상을 기술한다.

데이터 모델링 (Data Modeling)
   - 업무 정보 구성에 기초가 되는 정보들에 대해 일정한 표기법에 의해 표현한다.

      -> 정보시스템 구축 대상이 되는 업무 내용을 정확하게 분석
   - 분석된 모델을 가지고 DB를 생성하여 개발 및 데이터 관리에 사용하기 위한 것 이다.
   - 데이터 모델링 차제로서 업무의 흐름을 설명하고 분석하는 부분에 의미를 가지고 있다.

   * 데이터 모델링의 유의사항
      1. 중복 : 여러 장소의 DB에 같은 정보를 저장하지 않도록 하여 중복성을 최소화 해야한다.
      2. 비유연성 : 데이터의 정의를 데이터의 사용 프로세스와 분리함으로서 비유연성을 최소화 해야한다.
         -> 데이터 혹은 프로세스의 작은 변화가 애플리케이션과 DB에 중대한 변화를 일으킬 수 있는 가능성을 줄인다.
      3. 비일관성 : 데이터의 중복이 존재하지 않더라도 비일관성은 존재할 수 있다.
         -> 데이터를 모델링 할 때 데이터와 데이터 간의 상호 연관 관계에 대해 명확하게 정의를 해야한다.
         -> 예시로 정보 갱신시 개발자가 서로 연관된 다른 데이터와 모순된다는 고려 없이 데이터를 수정할 경우를 방지.

   * 데이터 모델링의 3단계
      1. 개념적 데이터 모델링 : 추상화 수준이 높고, 업무 중심적이며 포괄적인 수준의 모델링을 진행.

         -> 현실 세계에 존재하는 데이터를 의미 있는 엔티티와 엔티티 내의 공통된 속성과

              엔티티들 사이의 관계를 정의하는 추상화 과정

         -> 현실 세계를 추상화하여 개념적으로 표현함으로써 이해하기 쉽게 할 뿐 아니라 의사소통을 원활하게 해 주는 과정

         -> 정보 모델링 이라고도 한다.
         -> 엔터티와 속성을 도출하며 ERD(Entity-Relation Diagram)를 작성한다.
      2. 논리적 데이터 모델링 : 시스템으로 구축하고자 하는 업무에 대한 속성, 관계 등을 정확하게 표현한다.

         -> 개념적 데이터 모델은 DBMS가 직접 이해할 수 없으므로, 컴퓨터가 이해할 수 있도록 논리적 데이터 모델로 변환해야 한다.

         -> ERD 설계도를 DBMS가 이해할 수 있도록 업그레이드 하는 것 이라고 생각하면 된다. ex) ERD ---> IE(정보 공학 표기법)

         -> 데이터 모델링 이라고도 한다.

         -> 관계 데이터 모델, 계층 데이터 모델, 네트워크 데이터 모델 등이 있다.
         -> 재사용성이 높다.
      3. 물리적 데이터 모델링 : 실제로 db에 이식할 수 있도록 성능, 저장 등 물리적인 성격을 고려하여 설계한다.

DB Schema 구조 3단계

   - 스키마(Schema) : DB의 전체적인 설계. DB가 어떤 구조인지 알려준다.

   1. 외부 스키마 : 각 사용자 단계의 개인적 DB 스키마 이다.

   2. 개념 스키마 : 조직 전체의 통합된 DB 스키마 이다. 설계자의 관점에서 본다.

   3. 내부 스키마 : 물리적으로 데이터가 저장되는 방법을 표현하는 스키마 이다.

 

ERD (Entity RelationShip Diagram)

   - 1976년 피터첸에 의해 만들어진 표기법이다.

   - 일반적으로 ERD를 작성하는 순서 : 엔터티 도출 -> 엔터티 배치 -> 관계 설정 -> 관계명 기술

 

엔티티 (Entity)

   - DB에 자료로 표현하려는 것

   - 사람이 생각하는 개념이나 정보단위 같은 현실 세계의 대상체

   - 유형, 무형의 정보

   - 서로 연관된 몇 개의 속성으로 구성

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

   - 다른 엔터티와 관계를 가져야 한다. 단, 공통코드 / 통계성 엔터티의 경우엔 관계를 생략 가능하다.

   - Table과 거의 같은 개념.

   ex) 부서 엔티티 사원 엔티티

   * 강한 엔티티 타입 (Strong Entity Type)

      -> 엔티티 타입 내에서 자신의 키를 사용하여 고유하게 엔티티들을 식별할 수 있는 엔티티 타입

      -> 독립 엔티티, 부모 엔티티, 정규 엔티티 타입 이라고도 한다.

      -> 독자적으로 존재

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

      -> 키를 형성하기에 충분한 속성들을 갖지 못한 것

      -> 자기 자신의 속성만으로는 키를 명세할 수 없는 엔티티

      -> 종속 엔티티, 자식 엔티티 라고도 함

      -> 소유 엔티티 타입 (식별 엔티티 타입 : Identifying Entity Type) 이 있어야 존재한다.

 

ISA 관계

   - 상위 엔티티와 하위 엔티티 간의 관계

 

키 (Key)

   - 각 엔티티 인스턴스를 유일하게 식별하는 데 사용

   - ERD 상에서 Key에 해당되는 속성에 밑줄을 치는 거 같다.

 

속성 (Attribute)

   - 데이터의 가장 작은 논리적 단위 

   - 하나의 엔티티는 한 개 이상의 속성으로 구성

   - 각 속성은 엔티티의 특성, 상태들을 기술

   - Table 의 Column 과 같은 개념.

   ex) 부서 엔티티의 속성 : 부서 번호 / 부서명 / 위치

          사원 엔티티의 속성 : 사원 번호 / 이름 / 주소 / 소속 부서

 

   * 단순 속성 (Simple Attribute) : 더 이상 작은 구성원소로 분해할 수 없는 속성

   * 복합 속성 (Composite Attribute) : 몇 개의 기본적인 단순 속성으로 분해할 수 있는 속성

   * 단일 값 속성 (Single valued Attribute) : 각 엔티티에 대해서 하나의 값만 갖는 것

      -> ex) 설병, 주민등록번호

   * 다중 값 속성 (Multi valued Attribute) : 한 엔티티에 대해서 여러 개의 값을 갖는 것

      -> ex) 취미, 성격

 

   * 유도 속성/파생 속성 (Derived Attribute) : 속성의 값이 다른 속성이나 엔티티가 가지고 있는 값으로부터 유도되어 결정되는 경우

   * 저장 속성 (Sorted Attribute) : 유도 속성을 생성하는데 사용된 속성

      -> ex) 생년월일 : 저장속성 / 나이 : 유도속성

   * 널 속성 (Null Attribute) : NULL value 를 갖는 속성 

 

관계 (Relation)

   - 엔티티와 엔티티 혹은 엔티티와 속성 간의 연관성

     이러한 연관성을 논리적으로 표현한 것 이다.

   - 이후 Table 로 발전할 수 있거나, Column 으로 발전할 수 있다.

   - RDBMS : 이러한 관계가 반드시 있어야 RDBMS 라고 할 수 있다.

   - 카디날리티 (Cardinality : 관계의 대응 엔티티 수)

      -> 하나의 관계에 실제로 참여할 수 있는 인스턴스의 수를 의미한다.

      -> ex) 1 : 1 , 1 : N , N : M

---

오늘의 한 마디 : 항상 시작은 낯설고 힘든 것 같다. 그래도 결국 이겨낼 수 있는 문제임이 틀림없다.