ch1. Introduction of Database Systems

Sieun·2022년 10월 25일
2

데이터베이스

목록 보기
1/7
post-thumbnail

1. 데이터베이스시스템이란?

🔹데이터베이스: 서로 관계있는 데이터들의 모임

  • 대규모의 정보를 관리하도록 설계됨.
  • 데이터의 관리에는 정보 저장 구조를 정의하는 작업과 저장된 정보를 조작하기 위한 기법을 제공하는 작업 모두가 포함됨.

🔹데이터베이스 관리 시스템(DBMS): 서로 관계있는 데이터들의 모임과 그 데이터에 접근하기 위한 프로그램의 집합

  • 데이터베이스 구조를 관리하며, 데이터로의 접근을 컨트롤하며, 쿼리문을 제공한다.
  • 저장된 정보를 시스템 고장이나 불법적인 액세스 등으로부터 안전하게 보호해야 함.
  • 데이터가 여러 사용자간에 공유될 경우, 이로 인한 예기치 않은 이상 결과를 방지해야 함.

2. 데이터베이스 시스템의 응용

🔹 조직정보
- 판매, 회계, 인적자원, 제조업
🔹 은행 업무 및 재무
- 은행 업무, 신용카드 트랜잭션, 재무
🔹 대학
- 등록, 성적, 학사 관리
🔹 항공
- 예약, 스케줄 편성
🔹 통신
- 통화 내역, 데이터 사용량, 문자
🔹 web-based 서비스
- 온라인 소매: 주문 내역 확인, 사용자 맞춤형 제품 추천
- 온라인 광고
🔹 문서 데이터베이스

데이터 vs 정보

  • 데이터는 정보 구축의 기반이 됨.
  • 데이터는 정보를 생산하기 위해 처리됨.
  • 정보는 데이터의 의미를 밝혀냄.
  • 정보는 지식의 기반이 됨.
  • 좋은, 적시의, 관계있는 정보는 의사 결정에 중요한 역할을 함.
  • 예시
    • 데이터: 가수의 공연 티켓 판매량
    • 정보: 지역과 행사장에 따른 판매 보고서 ➡️ 어떤 행사장이 수익 창출에 유리한지 정보를 얻을 수 있음.

3. 데이터베이스 시스템의 목적

<초기> 컴퓨터에 정보를 저장할 때, 운영 체제 상의 파일 시스템에 저장함.
➡️ 사용자가 정보를 사용하기 위해서는 응용 프로그램들이 필요함.

👎 파일 처리 시스템에 데이터를 저장했을 때의 단점

1. 데이터 의존성 (Data Dependency)

  • 데이터가 수정되면 프로그램을 수정해야 할 수도 있음.
  • 데이터 수정은 많이 발생함.
    ➡️ 파일과 응용 프로그램은 갈 수록 늘어나게 됨.

2. 데이터의 중복과 비일관성 (Data Redundancy and Inconsistency)

  • 각각의 사용자는 서로 다른 데이터 형식 및 프로그래밍 언어를 사용함.
  • 동일한 정보가 여러 파일에 중복 저장될 수 있음.
    ➡️ 저장 공간 낭비 & 데이터 비일관성 초래

    데이터의 비일관성
    동일한 데이터의 여러 사본이 서로 다른 값을 보유하고 있는 상태 (데이터가 수정될 때 발생)

3. 데이터 접근 시의 어려움 (Difficulty in accessing data)

  • 새로운 데이터를 검색할 때마다 새로운 응용 프로그램을 만들어야 한다.

  • 하나의 query = 하나의 프로그램

    	👍 SQL의 경우, 데이터를 변경할 때 소스코드를 변경하지 않아도 됨. 데이터와 독립적임.

데이터의 고립: 데이터가 여러 파일에 흩어져 있고 파일 형식이 다르기 때문에 검색 프로그램을 작성하기 어려움.

4. 무결성 문제 (Integrity problems)

  • 형식의 일관성 제약 조건(consistency contraint)을 만족해야 하는데, 제약조건이 추가될 때마다 모든 프로그램의 소스코드를 변경하는 과정이 복잡함.

5. 원자성 문제 (Atomicity of updates)

  • 시스템 고장으로 일부만 업데이트되어 일관성이 위배될 수 있음.
  • 데이터베이스의 일관성을 지키기 위해서는 일련의 과정 전체가 수행되든지 아니면 어느 것도 수행되지 않아야 함. 즉, ✨원자성이 보장되어야 함.

6. 동시 액세스 문제 (Concurrent access by multiple users)

  • 여러 사용자가 데이터를 동시에 갱신할 수 있도록 해야 함.
    ➡️ 이때, 동시 접근이 제대로 감독되지 않으면 데이터의 비일관성을 야기할 수 있음.

7. 보안 문제 (Security problems)

  • 사용자에게 전체 데이터가 아닌 일부 데이터에 대한 접근 권한만 부여하는 것이 어려움.

✨데이터베이스 시스템은 위 7가지 문제에 대한 솔루션을 모두 제공함.

🔷 데이터베이스 시스템의 단점

  1. 의존성 문제 (Reliability Issue)
  • 병목현상이 발생할 수 있음.
  • 취약함.
  1. 비용 문제 (Expensive)
  • 부가적인 자원이 필요함. DBSM, DB 관리자, 서버 등
  1. 속도 문제 (Slow)
  • 모든 트랜잭션이 DBMS 소프트웨어를 거쳐야 하기 때문에 처리 속도가 느려질 수 있음.
  • 사용자는 데이터 구조 조작 권한이 없음.
    file system vs db system

4. 데이터의 관점

4-1. 데이터의 추상화

시스템이 원활하게 사용되려면, 데이터 검색이 효율적으로 이루어져야 함. 이러한 목적을 이루기 위해 DB 내의 데이터를 효율적으로 표현하기 위한 여러가지 복잡한 데이터 구조가 제안됨.
복잡한 구조를 감추어 사용자의 이해와 편의를 돕기 위해 여러 단계의 추상화 과정을 거침.
🔹물리적 단계(Physical level)추상회의 최하위 단계
ㅤ- 데이터가 실제로 어떻게 저장되는지 기술함.
ㅤ- 하드웨어의 관점에서 데이터 구조를 기술함.
ㅤ- 사람이 아니라 운영체제가 관리하는 부분임.
🔹논리적 단계(Logical level) 그 다음 상위 단계
ㅤ- DB에 어떤 데이터가 저장되어 있는지와 데이터 사이에는 어떤 관계가 있는지 기술함.
ㅤ- 사람의 관점에서 데이터 구조를 기술함.
ㅤ- 논리적 단계에서 사용되는 도구로는 table, tree ,graph, class 등이 있음.
ㅤ- 데이터베이스 모델은 논리적 단계에서 사용된 도구를 기반으로 결정됨.
ㅤ- DB 프로그램은 논리적 단계를 사용함.
ㅤ- 데이터베이스 관리자(database administrator: DBA)가 이 단계에서 작업함.
ㅤ물리적 데이터 독립성: 논리적 단계의 사용자는 물리적 단계의 복잡한 구조에 대해 알 필요가 없다
🔹뷰 단계(View level) 추상화의 최 상위 단계
ㅤ- 사용자들이 시스템을 간단하게 사용할 수 있도록 데이터의 일부만 기술하고 모두 숨김.
ㅤ- 논리적 단계의 부분집합임.
ㅤ- 한 사용자/앱 당 하나의 뷰❔
ㅤ- 하나의 데이터베이스에 대해서 수많은 뷰가 존재할 수 있음.ㅤ
ㅤ- 보안 목적으로도 뷰를 사용해서 정보를 숨기기도 함.

데이터 추상화의 세 가지 단계

4-2. 인스턴스와 스키마

🔹인스턴스(instance): 어느 특정한 순간에 DB에 저장되어 있는 정보의 모임 변수 선언(형 정의)
🔹스키마(schema): DB의 전체적인 설계 변수에 저장된 값

DBMS에는 추상화의 단계에 따라 여러 개의 스키마가 존재함.
🔹물리적 스키마(physical schema): 물리적 단계에서 DB 설계
🔹논리적 스키마(logical schema): 논리적 단계에서 DB 설계
🔹서브 스키마(subschema): 뷰 단계의 스키마 여러 개가 존재할 수 있으며 각각 서로 다른 뷰를 기술함.

  • 응용 프로그램에 가장 큰 영향을 미치는 것은 논리적 스키마임.
    ☝️대부분의 응용 프로그램들이 논리적 스키마를 기반으로 작성되기 때문임.
  • 물리적 스키마는 논리적 스키마 아래에 감추어져 있으나 상위 프로그램에 영향을 주지 않고서도 쉽게 변경할 수 있음.
    ➡️ 물리적 데이터 독립성(physical data independence): 응용 프로그램이 물리적 스키마에 의존하지 않아서 물리적 스키마가 변경되어도 논리적 스키마(또는 응용 프로그램)을 고칠 필요가 없음.

4-3. 데이터 모델

🔹데이터 모델: 데이터, 데이터 사이의 관계, 데이터의 의미, 일관성 제약조건 등을 기술하기 위한 개념적 표현들의 집합으로, DB 구조의 기반이 됨.

🔹 데이터 모델의 4가지 분류
ㅤ1. 관계형 모델(Relational Model) - 테이블

  • 데이터와 데이터 사이의 관계를 나타내기 위해 테이블을 사용함.

  • 각 테이블은 여러 개의 열(column)과 행(row)으로 구성됨.

  • 테이블은 릴레이션(Relation)이라고도 부름.

  • 레코드 기반 모델의 한 예시임.
    ➡️ 각 테이블은 특정한 형(type)의 레코드를 포함하기 때문임.

  • 가장 널리 쓰이고 있는 데이터 모델임.

  • 장점

    • 구조적 독립성
    • 향상된 개념적 단순성
    • 더 쉬운 DB 디자인, 구현, 관리, 사용
    • SQL로 쿼리문을 작성할 수 있음.

  • 단점

    • 잠재적인 하드웨어와 시스템 소프트웨어 오버헤드
    • "islands of information" 문제
      A data island is a subset of entities that are connected to each other via relationships, but that are independent of other entities within the same data store.
  1. 개체-관계 모델(Entity-Relationship Model)
  • E-R 모델은 기본적인 객체들의 집합인 개체(entity)들과 개체들 간의 관계(relationship)를 사용함.
  • 개체: 실세계에 존재하는 '어떤 것' 또는 '객체'이며 다른 객체들과 구별됨.
  1. 객체-기반 데이터 모델(Object-Based Data Model)
  • 객체 지향 데이터 모델과 관계형 데이터 모델의 특성을 결합한 모델
  • E-R 모델에 캡슐화, 메소드(함수), 객체 아이덴티티의 개념을 더해 E-R 모델을 확장한 것처럼 보임.
  1. 반구조형 데이터 모델(Semistructured Data Model)
  • 같은 형식을 갖고 있으나 다소 다른 속성들을 가진 데이터 항목들을 기술하기 위한 비정형 데이터 모델
  • 다른 모델들이 특정 형식의 데이터 항목에 대해서는 동일한 속성만을 갖도록 허용한다는 점에서 대조를 이룸.
  • XML(extensible markup language, 확장성 마크업 언어)가 반구조형 데이터를 나타내는 데 널리 쓰임.

+) NoSQL/Hadoop/MapReduce

🔹 오래된 모델
1. 계층형 데이터 모델(hierarchical data model)

  • Top-down 트리로 표현됨.
    • 각 부모는 여러 자식을 가질 수 있음.
    • 각 자식은 오직 한 부모만 가질 수 있음.
  • 장점
    • 개념적 단순성
    • 보안성 및 무결성
    • 효율성
    • 데이터 독립성
  • 단점
    • 구현하기 복잡함.
    • query문이 부족함. ❔
    • 관리하기 어렵고 기준이 부족함.
  1. 네트워크형 데이터 모델(network data model)
  • 각 레코드는 여러 부모를 가질 수 있음.
    • set으로 구성됨
    • 각 set은 owner 레코드와 member 레코드를 갖고 있음.
    • Member는 여러 owner를 가질 수 있음.
  • 장점
    • 개념적 단순성
    • 더 많은 데이터형을 다룰 수 있음.
    • 데이터 접근이 유연함.
    • DB 무결성
    • 데이터 독립성
    • 기준 적합성
  • 단점
    • 시스템이 복잡함.
    • 구조적 독립성이 부족함.
🔹 계층형/네트워크형 모델
- 장점: 데이터 표현에 있어 관계형 모델보다 더 효율적이며 매우 복잡한 데이터도 표현할 수 있음.
- 단점: 효율적인 DB 언어는 아님.

⭐ 데이터베이스 모델은 논리적 단계에서 사용된 도구를 기반으로 결정됨.

  • 관계형 모델: 테이블
  • 계층형 모델: 트리
  • 네트워크형 모델: 그래프
  • 객체 지향 모델: 클래스(object)

❔Object Oriented-Based-Relational Model이 모두 같은 것인가?

🔹 객체 관계(지향) 데이터 모델 (Object Relational(Oriented) Data Models)

  • 원자 값 (더 쪼갤 수 X)

  • 주로 숫자와 문자 데이터

  • 복잡한 데이터를 표현하기 위해 사용함.

  • 객체 지향 개념및 추가된 데이터 형을 다루기 위한 개념을 포함하여 관계형 데이터 모델을 확장함.

  • 튜플의 속성이 복잡한 타입을 가질 수 있게 함. ex) 중첩관계와 같은 비원자적인 값

  • 존재하는 관계형 언어와 양립할 수 있음.

  • 장점: 매우 복잡한 데이터도 표현할 수 있음.

  • 단점: 효율적인 DB 언어는 아님.

💭 NoSQL/Hadoop/MapReduce란?

5. 데이터베이스 언어

5-1. DDL

- DDL(Data Definition Language, 데이터 정의 언어): 데이터베이스 스키마를 기술

  • DDL 컴파일러는 Data dictionary에 저장된 테이블들을 생성함.
  • 데이터 사전(Data Dictionary)는 metadata를 포함한다. metadata: 데이터를 위한 데이터
  • 데이터 저장 및 정의 언어(Data storage and definition language)로 저장 구조와 액세스 방법이 정의됨. ➡️ DB 스키마 구현 상의 세부 사항을 정의
  • 무결성 제약조건을 이행함.
    • 도메인 제약조건(Domain Constraints): 값의 도메인은 모든 속성들과 연관되어 있어야 함.
    • 참조 무결성(Referential Integrity): 주어진 속성들의 집합에 대한 릴레이션의 한 값이 다른 릴레이션에 대한 속성 집합의 값으로 반드시 나타나야 함.
    • 주장(Assertions): DB가 항상 만족시켜야 하는 조건
    • 권한(Authorization): DB의 다양한 데이터들에 대해서 사용자마다 접근을 다르게 하고 싶을 때 주는 차별 읽기 권한, 삽입 권한, 갱신 권한, 삭제 권한

5-2. DML

- DML(Data Manipulaiton Language, 데이터 조작 언어): 사용자가 적절한 데이터 모델로 구성된 데이터를 접근하거나 조작할 수 있도록 하는 언어

  • 접근 형태: 검색(SELECT), 삽입(INSERT), 삭제(DELETE), 수정(UPDATE)
  • 두 가지 형태의 DML
    • 절차식(procedural) DML: 어떤 데이터가 필요하며 그 데이터를 어떻게 구할지 지정할 것을 요구함. ex) 대부분의 언어
    • 선언적/비절차식(declartive/nonprocedural) DML: 필요한 데이터를 어떻게 구할지 명시할 필요 없이, 어떠한 데이터가 필요한지 지정할 것만을 요구함. ex) SQL
  • 질의(query): 정보의 검색을 요청하는 문장
  • 질의어(query language): DML에서 정보 검색을 담당하는 부분

SQL은 사용자 입력을 받거나 출력을 보여주거나 통신하는 기능은 없음. ➡️ 이러한 기능들은 데이터 접근을 허용하는 SQL 쿼리를 포함하는 C, C++, Java 등과 같은 host language로 작성되어야 함. ➡️ 응용 프로그램이 이러한 DB와의 상호작용을 가능하게 하는 프로그램임.

6. 데이터베이스 설계

6-1. 설계 단계

DB 설계 초기 단계는 장래 이용자들이 필요로 하는 데이터를 충분히 규정하는 것임. 이를 수행하기 위해 DB 설계자는 전문가들 및 사용자들과 활발히 상호작용 해야 함.
➡️ 결과물: 사용자의 요구 명세서(specification of user requirements)
다음으로 설계자는 데이터 모델을 설계하고, 선택한 데이터 모델의 개념을 적용함으로써 사용자의 요구들을 DB의 개념적인 스키마로 바꿈. 개념적 설계 단계에서 개발된 스키마는 기업의 상세한 overview를 제공함. 설계자는 스키마를 재검토한 뒤 중복되는 사항들(redundant features)을 제거함.
관계형 모델에서의 개념적 설계 단계는 DB에서 우리가 어떤 속성을 포착하고 이를 어떻게 그룹화 할것인지 결정함.

  • Business decision(기업적인 결정): 어떤 속성을 DB에 저장해야 하지?
  • Computer Science decision(전산학적 결정): 어떤 관계 스키마를 가지고 어떻게 속성을 관계 스키마에 분산해야 하지?
    완전히 개발된 개념적 스키마는 기능적인 요구사항들을 보여줌. 기능적 요구사항 명세서(specification of functional requirement)에 사용자들은 데이터에 적용될 연산(또는 트랜잭션)들의 종류를 기술함. 데이터 검색, 추출, 삭제 등
    추상 데이터 모델로부터 DB 구현으로 이동하는 과정은 마지가 두 가지 디자인 단계에서 이루어짐. ➡️ 논리 설계 단계에서 설계자는 상위의 개념적 스키마를, 사용할 DB의 구현 데이터 모델에 대응시킴. 설계자는 결과로 나온 시스템 특유의 DB 스키마를 DB의 물리적 속성들이 구체화되는 물리 설계 단계에 이용함.

6-2. 개체-관계 모델(E-R 모델)

  • DB 디자인 tool
  • E-R 모델은 기본적인 객체를 나타내는 개체(entity)들과 개체들 간의 관계(relationship)를 이용함.
    • 개체: 실세계에 존재하는 어떤 것 혹은 객체로, 다른 것들과 구별되며 속성의 집합으로 기술됨.
    • 관계: 여러 개체들 간의 연관성.
  • E-R 모델로 디자인 된 DB는 주로 관계형 모델(table)로 변환됨.
    ☝🏻 E-R 모델이 관계형 모델에만 적용되는 것은 아님. 어떤 모델이든 적용 가능함.
    ☝🏻 E-R 모델과 DB 모델은 서로 독립적임.
  • DB의 전체 논리적 구조는 E-R diagram으로 시각적으로 도식할 수 있음. 다이어그램을 나타내는 방법은 UML(통일된 모델링 언어)를 이용하는 것임.
    UML 기반 E-R 다이어그램 예시
- 개체 집합: 윗 부분에 개체 집합의 이름을 갑고 그 아래에 속성들의 목록을 갖는 사각형 박스로 표현됨.
- 관계 집합: 연관된 개체 집합들을 연결한 마름모로 표현함. 관계의 이름을 마름모 안에 작성함.
  • Database Architecture에 영향을 주는 컴퓨터 시스템 동작 환경
    • Centralized(one server)
    • Client-server
    • Parallel(multi-processor)
    • Distributed(분산)
profile
Sieun
AI/ML 공부중👩🏻‍💻
다음 포스트

ch2. Relational Database

0개의 댓글