데이터베이스

---

📝 데이터베이스 : 통합하여 관리되는 구조화된(Structured) 데이터의 집합(SET)

ex) POS기, 휴대폰연락처, 항공사(예약, 스케쥴), 인적자원(직원 관리, 봉급, 세액 공제), 인터넷 뱅킹, 대학교(학점, 분반,등록), 온라인판매(재고, payment, 배송추적), 마케팅(상품, 고객관리)등 매우 ubiquitous !!

0x01. 데이터 추상화(Abstraction)

---

1.1 인스턴스와 스키마

• 프로그래밍 언어의 자료형↔스키마 과 변수↔인스턴스에 상응하는 개념
• 스키마(Schema)
  • 데이터베이스의 논리적/물리적 구조를 의미.
  • 총 3개 View schema, logical schema, physical schema로 분류된다.
  • 처음 한번 구조가 정의되고 나면 거의 변하지 않음
• 인스턴스(Instance)
  • 데이터의 실제
    • 특정 시점에 스키마에 맞는 실제 내용(table)을 의미
  • 실제 내용은 자주 변할 수 있음

1.2 추상화

(1) 추상화 개념

• 어떤 사물에 대한 세부적인 개체(instance)로 부터 중요한 개념을 분리하는 프로세스를 의미하며, 구현상에서만 관련 있는 사항이나 문제 해결에 중요하지 않은 사항을 제거하여 사람들이 문제 핵심 속성에만 집중하여 문제를 해결하게 한다.

  • 전산학 문제 또는 기술(technology)을 서술함에 있어 추상화는 아주 널리 사용되고 있으며, 일상생활에서 일반인도 추상화를 의식적으로 또는 무의식적으로 흔히 접하고 있다.

• 추상화는 추상화 레벨에 따라 사용자에게 보이는 상세한 정도가 달라진다. 추상화는 사물을 보는 높이에 따라 기술(description) 수준에 차이가 나므로, 우리가 추상화를 언급할 때에는 추상화 레벨도 함께 고려하여야 한다. (하나의 시스템은 많은 추상화 계층을 가지고 있다.)

• e.g.

  • 이것은 과연 데스크탑 컴퓨터일까? 일반적인 데스크탑 컴퓨터 형태를 띄고 있지만, 실질적으로 작동되는 컴퓨터라고 할 수가 있을까?? 위 그림은 추상화의 결과물이다. 즉 데스크톱 컴퓨터를 기술(description)할 때 상기 그림과 같이 할 수 있으며, 실은 이 과정에는 많은 추상화를 하고 있다. 마우스에 있는 버튼 등이 세세하게 보이질 않은데 이는 현추상화 단계에서는 마우스 버튼이 중요하지 않다고 생각하기 때문이다.
  • 추상화에서는, 추상화 깊이(단계)에 따라 동일 객체에 대한 추상화 결과는 서로 상이하다. 상기 예제에서도 추상화 깊이에 따라 상이한 결과가 도출될 수 있으며, 만약 좀 더 자세한 추상화에서는 마우스 버턴이 2개 있고 그 가운데 휠 조정 버튼 등이 (또는 키보드 자판 등이) 기술 될 것이다.
  • 그리고, 추상화는 반드시 bottom-top일 필요는 없다. 오히려 구체적인 사항을 숨기고 top-bottom 형식으로 아는 것이 인간에게 더 쉽게 다가올 수 있다.

(2) 데이터베이스에서의 추상화의 레벨(3단계)

1. View Level : 아주 간단한 형태의 정보만을 제공하는 레벨(초보에게 적합)

   • 보안 목적으로도 상세 내용을 숨길 수도 있음

2. Logical Level : 중간정도의 정보를 제공하는 레벨

   • 데이터베이스에 저장되어 있는 데이터와 데이터간의 관계를 논리적 관점에서 추상화.

      		Type professor = record
      				ID : text;
      				name : text;
      				department : text;
      				salary : integer;
      		end;

3. Physical Level : 매우 복잡하고 많은 정보를 제공하는 레벨

   • 실제 데이터 레코드가 어떻게 저장되는지를 기술

     • 데이터 필드 길이, 필드간의 간격길이, 레코드의 전체 길이 등을 포함

   • 

   • [그림 1]. 3단계 스키마 구조

(3) 데이터 독립성(Data Independence)

• 데이터 독립성은 물리적 데이터 독립성과 논리적 데이터 독립성으로 구성됨.
  • 물리적 데이터 독립성 : 논리적 스키마 변화 없이 물리적 스키마를 변화할 수 있는 기능을 의미
  • 논리적 데이터 독립성 : 뷰 스키마 변화 없이 논리적 스키마를 변화할 수 있는 기능을 의미
• View schema는 최종 사용자가 보는 데이터베이스 schema이며 , 사용자는 이를 고려하여 데이터베이스 프로그램 및 응용을 개발하게 된다.
• 데이터베이스 내부 구조 등의 변화로 물리적 스키마 변경이 발생하여도 물리적 데이터 독립성에 의하여 논리적 스키마에 변화 ❌, 또한 논리적 스키마의 변경이 발생하여도 논리적 데이터 독립성에 의하여 뷰 스키마 변화❌. 그러므로 이 경우 기존에 개발된 프로그램이 수정 없이 계속 사용될 수 있음을 의미한다.
• 대부분 DBMS는 약간의 차이가 있으나, 기본적으로 데이터 독립성 지원.
  • But, File System은 데이터 독립성 제공 X

0x02 데이터 모델

2.1 데이터 모델 definition

💡 DB만들 때 맨첫번째 단계

• 실제 데이터는 하드디스크같은데에 산재해 있는데, 인간이 이 데이터를 식별하는 건 불가능하므로 그것들을 추상화할 필요가 있다.

📝 데이터 모델 : 데이터(Data), 데이터 관계성(Data relationships), 데이터 의미(Data semantics), 데이터 제약 조건(Data constraints) 등을 기술하는 명세(specification) 또는 개념적인 도구(conceptual tool)이다.

• 이 데이터 모델은 데이터를 개념적으로 추상화하는 도구이며, 우리는 데이터 모델링을 통하여 데이터를 기술하거나 조작할 수 있다.

2.2 데이터 모델의 종류

• 관계형 데이터 모델(Relational data model)
• 객체지향 데이터 모델(Object-oriented data model)
• 객체관계형 데이터 모델(Object-relational data model)
• 개체-관계 데이터 모델(Entity-Relationship data model← for DB 설계에서 가장 처음으로 하는 데이터 모델링)
  • 이것을 참조로 해서 Relational, Object 등의 데이터 모델링을 한다.
• XML 데이터 모델(XML data model ← for semi-structured data like web)
• 네트워크 데이터 모델(Network data model)
• 계층형 데이터 모델(Hierarchical data model)
  • 네트워크 데이터 모델과 계층형 데이터 모델은 현대사회에서 더이상 사용 X
  • 이를 지원하는 구식 시스템을 legacy system이라고 함.

상용 DBMS는 위 데이터 모델 중 하나를 지원하며, 예를 들어 RDBMS는 관계형 데이터 모델을 지원하는 DBMS이다. 데이터 모델은 사용자가 DB를 보는 관점을 나타내기 때문에, 데이터 모델이 다른 DBMS는 동일 데이터를 저장/관리하더라도 완전히 다른 데이터베이스 시스템으로 보인다.

(1) 관계형 데이터 모델(Relational Data model)

• 위 그림은 관계형 데이터 모델의 기본 요소인 관계(relation)의 예를 보이고 있다.

  • 학생 relation을 나타내고 있다.

• 관계형 데이터 모델은 80년대 이후 가장 많이 사용되는 데이터 모델이다.

• 관계를 테이블 형식으로 표현한다.

(2) 객체-관계형 데이터 모델(Object-Relational Data model)

• 현 시대에 많이 사용하는 데이터 모델.

• 관계형 데이터 모델(그대로 보존) + 객체지향 요소(쬐끔) :

  • 즉 관계형 데이터 모델의 확장판이라 볼 수 있다

• 이미지, 동영상, 지리 등 복잡한 타입의 데이터를 가질 수 있다.(= 모델링 파워가 크다)

(3) XML(Extensible Markup LanDguage) 데이터 모델

• 웹에 사용되는 데이터 모델 기술로, W3C에서 정의.
• 요즘에는 문서 교환을 위한 표준 기술로 널리 사용됨.
  • 태그를 사용하여 데이터 교환.
    • 태그는 HTML에서 아이디어를 따온것임(비롯된 것임)
    • 따라서 중첩태그도 사용가능
    • 그리고 오히려 HTML보다 사용하기 더 쉬움

0x03 DBMS 설계(스키마)

💡 DB만들 때 2번째 단계

• DBMS라는 프로그램을 Java 코드로 어떻게 구현하고 이런 것이 아니라, 데이터베이스내에서 데이터 구조를 설계하는 작업으로, 사용자 요구사항을 분석하여 요구사항을 충족하는 좋은 스키마(설계한 결과물)를 생성하는 작업
• 2가지 type이 존재 :
  • 논리적 설계(Logical schema) : view schema, logical schema 생성
  • 물리적 설계(Physical schema) : Physical schema 생성
• DB schema를 어떻게 만드느냐에 따라 DBS의 성능이 달라질 수가 있다.
  • 따라서, DB schema를 잘 설계 해야한다.

Database Schema = Data Model + Data + Meta Data

3.1 E-R Model(Entity-Relationship Model)

(1) 개체관계 모델 개념

• 설계를 해서 Schema를 만들려고 할 때 위에서 봤던 모델을 사용한다.

• DB 설계방식 중 가장 많이 쓰는 방식은 E-R 데이터 모델이다.

• 개체와 관계 형식으로 실세계를 바라본다.

  • 이 결과물을 개체-관계 다이어그램으로 표현한다.
    • 매우 직관적임
  • 이 다이어그램으로 RDBS로 디자인할 건가, ODBS로 디자인할건가를 결정.

이러한 결과물인 schema가 Bad or Good인지 어떻게 확인 ???

• 정규화 이론
  • 설계된 스키마가 좋은지 나쁜지 판단 가능
  • 스키마를 잘 설계할 수 있는 방법을 제공(추후 배움)

(2) 개체관계 모델 예제

• 개체
  • Student
    • Student 속성: sID(학번), name(이름), totalCredit(총수강학점)
  • Course
    • Course 속성: cID(과목번호), title(과목명), deptName(개설학과명)
• 관계성
  • Takes: Student entity와 Course entity간에는 "학생이 과목을 수강하다"는 의미의 Takes관계성이 존재한다.
    • Takes 관계성은 year 속성을 가지는데, 의미는 수강년도이다.

ER 다이어그램은 데이터베이스가 관리하고자 하는 데이터에 대한 명세이다.