* 데이터베이스(DB)를 사용하는 이유
• 모든(대규모) 웹사이트를 보면 DB가 있음
• Examples:
– UPS / FedEx tracking
– Amazon’s/eBay’s websites
– Wal-Mart’s inventory system
– Dell’s ordering system
– Google’s search engine
* 데이터관리 시나리오 예시
• 시나리오
– You run a movie rental startup.
– Your customers rent DVD copies of movies.
– Several copies of each movie.
• 요구사항
– Which DVD disks have a customer rented?
– Are any disks overdue?
– When will a disk become available?
<Solution: A “File-based” System>
• (Create an) Edit rented.txt file and list.txt file
• 장점?
– 텍스트 편집기는 사용하기가 쉬움
– 데이터를 삽입하고 삭제하기가 쉬움 (really?)
<문제점 1: 질의(Query)방법?>
• Query 1: ‘Young-Woo Kwon’은 어떤 영화를 대여하였는가?
– Search for ‘Young-Woo Kwon’
– Read a movie rent by ‘Kwon’
– Repeat it until there is no movie rent by ‘Kwon’
• Query 2: 대여기간을 넘긴 영화가 있는가?
– Query 1을 반복하고, 날짜를 읽어 대여기간을 확인함
– 너무 복잡함!!!
<문제점 2: 무결성(Integrity)>
•데이터 무결성, 일관성의 어려움
– 직원이 값과 필드의 이름을 잘못 입력하였다면?
• Customer: Young-KooKwon, Rent: 중경삼림, Due: May 20, 2024
– 잘못된 값을 넣거나, 동일한 값이지만 다르게 표현한다면?
•Customer: Young-Woo Kwon, Rent: Chungking Express, Due: May 20, 2024
– 필드에 들어가야할 항목을 빼거나, 다른 순서로 넣는다면?
•Due: May 20, 2024, Rented: 중경삼림
<문제점 3: 갱신(Update)>
• 모든 레코드에 새로운 필드를 추가/삭제/변경의 어려움
– 대여점 위치를 추가하고 싶다면?
• Customer: Young-Woo Kwon, Rent: 중경삼림, Due: Sep. 5, 2020, Store: Bukgu
• Modify the customer field to the first and last name fields
– First: Young-Woo, Last: Kwon, Rented: 중경삼림, Due: Sep. 5, 2020, Store: Bukgu
– 새로운 정보를 저장하고 싶다면?
• 예: 고객 정보를 저장하고 싶어 customer.txt 파일을 생성하고, 고객별로 전화번호를 저장함
• customer: Young-Woo Kwon, Phone: 7566
<문제점 4: 복수의 사용자>
•두 명 이상의 직원이 rent.txt 파일을 동시에 수정하는 경우.
1) Alice starts to edit rent.txt, reads it into memory.
2) Bob starts to edit rent.txt.
3) Alice adds a record.
4) Alice saves rent.txt to disk.
5) Bob saves rent.txt to disk.
<문제점 5: 실행 실패 / 장애>
• 데이터를 업데이트하는 도중에 시스템 장애가 발생하는 경우
– 대여점에 영화 DVD를 반납하였음
– 직원이 rent.txt 파일에 반납 사실을 기록하는 도중 시스템이 꺼져버리고, 직원은 자리를 떠났음
– 직원이 돌아왔을 때 rent.txt 파일에 반납 정보가 기록되지 않았음
<문제점 6: 흩어진 데이터>
• 요구사항: 새로운 영화가 출시되었을 때 알림을 받기 원함
• 해결 방안
– customer.txt 파일에 고객 정보 (전화 / 이메일)를 기록함
– list.txt 파일에 새로운 영화가 기록되면 customer.txt 파일에서 고객 정보(다수)를 읽어 메일을 보냄
– 알림을 받기 원하는 고객들을 메일링 리스트로 만들어 저장함
• 문제점
– 텍스트 편집기를 사용하여 두개의 파일에서 정보를 추출하여 합칠 수 있는 방법은 무엇인가? 엑셀?
– customer.txt에 Young-Woo Kwon이 여러 명이 있다면?
<문제점 7: 보안>
• 고객은 대여 회수를 알기 원함
– rent.txt 파일에 접근할 수 있도록 하면서, 다른 항목에 대해서 수정이나 열람을 막을 수 있는 방법이 있는가?
• 나이에 따라 대여를 제한하고 싶은 경우
– 새로운 필드를 customer.txt, list.txt에 만들어서 고객 정보를 확인하고 대여함
<문제점 8: 효율성>
• 고객 수가 급증함
– rent.txt file gets huge (gigabytes, terabytes, or more of data).
– Slow to open and edit
– Slow to query for customer information
[텍스트 편집기 사용의 문제점 총정리]
1. 질의방법이 없다.
2. 데이터 무결성, 일관성이 어렵다.
3. 갱신하기 어렵다.
4. 복수의 사용자를 감당하기 힘들다.
5. 실행 실패 및 장애가 발생할 가능성 높다.
6. 흩어진 데이터 찾기 힘들다.
7. 보안이 취약하다.
8. 효율성이 떨어진다.
* 주요 용어 정리
• 데이터: 기록될 수 있는 사실이나 정보
• 데이터베이스: 데이터의 집합
• 데이터베이스 관리 시스템(DBMS): 데이터베이스를 생성하고 관리할 수 있는 소프트웨어 시스템
* 데이터베이스의 종류 및 기본 개념
• 전통적인 데이터베이스
– 숫자와 텍스트 정보를 저장하는 데이터베이스
• 최근의 데이터베이스
– 멀티 미디어 데이터베이스
– 지리 정보 시스템 (GIS)
– Biological and Genome Databases
– 데이터 웨어하우스
– 데이터 레이크 등
– 모바일 데이터베이스
• 데이터베이스는 다음을 통해 외부와 상호작용
- 쿼리 (Query): 데이터 추출을 위한 명령
- 트랜잭션 (Transaction): 데이터 삽입 / 삭제 / 읽기 등의 작업 등을 원자성 (atomicity)을 보장하며 수행
- 데이터를 인가되지 않은 접근으로 부터 보호하며 쿼리 및 트랜잭션을 처리함
* 최근의 데이터베이스 개발 (1)
• 최근 IT 기술의 급격한 발전으로 인하여 다양한 데이터베이스 시스템이 등장하고 있음
– 소셜 미디어는(e.g., Facebook, Twitter, LinkedIn ...) non-traditional data(e.g. posts, tweets, images, and video clips) 데이터를 저장함
• 빅데이터로 인하여 다양한 형태의 데이터 종류를 저장할 필요가 있어 NoSQL (Not-only SQL) 시스템(Hive, Pig, Hbase, etc.)의개발이 늘고 있음
– Google, Amazon, Yahoo, eBay 등과 같은 기존의 웹 기반 서비스도 검색 결과 저장을 위하여 NoSQL 데이터베이스를 사용함
• 검색의 편리성, 정확성을 위하여 웹 페이지 정보를 읽어 자신들의 클라우드 서비스를 활용함
– Google Cloud, Amazon AWS, MSAzure
* 최근의 데이터베이스 개발 (2)
• NoSQL은 데이터의 특징과 기능이 변경되는 경우에 사용하기 위한 용어임
– SQL은 고정된 데이터를 저장하기 위하여 사용되지만 NoSQL 은 그렇지 않음
• 특징
– 고성능 쓰기 작업, 확장성: Ex) mongoDB, elasticsearch, Cassandra
– 데이터 저장을 위하여 스키마가 필요없음 (스키마 = table)
– 느슨한 형태의 무결성 / 일관성 정책을 사용함
– 최신 언어(Python, Scala, Go, ...)에서 많이 사용됨
– 분산 컴퓨팅 환경에 적합함
* 최근의 데이터베이스 개발 (3)
• MongoDB
* 최근의 데이터베이스 개발 (4)
• Hadoop
– 빅데이터를 위하여 Map Reduce Programming Model을 구현한 데이터 저장 / 처리 시스템
– Map Reduce Example:
* 데이터베이스의 주요 특징
- 데이터 추상화
- 데이터 모델을 통하여 저장된 데이터에 대한 자세한 사항을 숨기고, 사용자에게는 개념적인 형태로 보여줌
- 프로그램은 저장된 데이터에 대하여 직접 접근하는 것이 아니라 데이터 모델을 참조하여 데이터에 접근함
- 데이터에 대한 다양한 뷰(view) 제공
- 개별 사용자는 데이터베이스에 대한 서로 다른 뷰를 통해 데이터에 접근함
- 사용자는 자신이 관심있는 데이터만 볼 수 있음
- 데이터 공유와 다수 사용자를 위한 트랜잭션 처리
- 동시에 다수의 사용자가 데이터에 접근하고, 업데이트하는 것을 허용함
- DBMS는 동시성 처리를 통해 각 트랜잭션이 정상적으로 실행되거나 취소될 수 있도록 함
* 데이터베이스 사용의 장점
- 중복 제어
- 무단 접근 제한
- 프로그램 객체의 영구적인 저장
- 효율적인 질의 처리를 위한 저장 구조 제공
- 질의(queries) 최적화
- 백업 및 복구 서비스 제공
- 다양한 사용자 인터페이스 제공
- 복잡한 데이터 관계 표현
- 무결성 제약 조건 적용
* DBMS를 쓰지 말아야할 때
• DBMS 사용 비용:
– 높은 초기 투자 비용 및 추가 하드웨어 필요성 발생 가능
– 일반성, 보안, 동시성 제어, 복구 및 무결성 기능 제공에 대한 오버헤드 (사업을 운영하는 지속적인 비용)
• DBMS가 불필요한 경우:
– 데이터베이스 및 응용 프로그램이 단순하고, 잘 정의되어 있으며, 변경될 가능성이 없는 경우
– 다중 사용자의 데이터 접근이 필요하지 않은 경우
• DBMS가 불가능할 수 있는 경우:
– 범용 DBMS가 사용 가능한 저장 공간에 맞지 않는 임베디드 시스템의 경우
* 빅데이터의발전
• Internet/Online Data
– Clicks
– Searches
– Server requests
– Web logs
– Cell phone logs
– GPS locations
– User generated contents
– Entertainment
• Healthcare and Scientific Computations
– Genomics, medical images, health care data, billing data
• Graph data
– Telecommunications network
– Social networks
– Computer networks
• IoT
– Sensors
• Financial data
* 데이터 웨어하우스를 이용한 데이터 처리
• Data analysis의 특징
– 데이터는 추가되거나 읽혀지기만 한다.
– 데이터는 절대로 업데이트되거나 삭제되지 않는다.
– 엄격한 데이터 모델 및 스키마가 있으며 특정 분석 기법에 맞춰서 데이터가 저장되어 있다.
문제점:
• 빅데이터 분석에서는 사전에 정의된 데이터 모델이나 스키마를 적용할 수 없을 수 있다.
• 분석 기법이 사전에 정의되지 않는다.
* 데이터 레이크를 이용한 데이터 분석
• 데이터 저장소 관점
– 데이터는 추가되거나 읽혀지기만 한다.
– 데이터는 절대로 업데이트되거나 삭제되지 않는다.
– 데이터는 변경없이 원시 형식으로 저장된다.
– 메타데이터를 사용하여 데이터의 버전을 관리한다.
• 데이터 거버넌스(주권) 관점
– 적절한 메타데이터가 필수적이며, 데이터 관리 주체를 명확히 명시해야 Data Swamp를 피할 수 있음
* Data Swamps
• 원시 데이터
• 찾거나 사용할 수 없는 형태로 저장된 데이터
• 민감한 데이터에 대하여 보호되지 않음
*파일 시스템과 DBMS의 비교
* 데이터베이스 시스템의 구성
• 데이터베이스 언어
• 데이터베이스 사용자
• 데이터 모델
• 데이터베이스의 개념적 구조
* 데이터베이스 언어
• SQL(Structured query language)
– 데이터 정의어(DDL, Data Definition Language) /CREATE, ALTER, DROP 등
– 데이터 조작어(DML, Data Manipulation Language) / SELECT, INSERT, DELETE, UPDATE 등
– 데이터 제어어(DCL, Data Control Language) / GRANT, REVOKE 등
* 데이터베이스사용자
• 일반 사용자
– 은행의 창구 혹은 관공서의 민원 접수처 등에서 데이터를 다루는 업무를 하는 사람
– 프로그래머가 개발한 프로그램을 이용하여 데이터베이스에 접근한 일반인
• 응용 프로그래머
– 일반 사용자가 사용할 수 있도록 프로그램을 만드는 사람
– 자바, C, JSP 등의 프로그래밍 언어와 SQL을 사용하여 일반 사용자를 위한 사용자 인터페이스와 데이터를 관리하는 응용 로직을 개발
• SQL 사용자
– SQL을 사용하여 업무를 처리하는 IT 부서의 담당자
– 응용 프로그램으로 구현되어 있지 않은 업무를 SQL을 사용하여 처리
• 데이터베이스 관리자 (DBA, Database Administrator)
– 데이터베이스 운영 조직의 데이터베이스 시스템을 총괄하는 사람
– 데이터 설계, 구현, 유지 보수의 전 과정을 담당
– 데이터베이스 사용자 통제, 보안, 성능 모니터링, 데이터 전체 파악 및 관리, 데이터 이동 및 복사 등 제반 업무를 함
* DBMS의 기능
* 데이터모델
• 계층 데이터 모델 (hierarchical data model)
• 네트워크 데이터 모델 (network data model)
• 객체 데이터 모델 (object data model)
• 관계 데이터 모델 (relational data model) -> 제일 많이 쓰임
• 객체-관계 데이터 모델 (object-relational data model)-> 관계 데이터 모델과 객체 데이터 모델의 장점을 결합한 모델
데이터 모델 -> 데이터베이스 시스템에서 데이터를 저장하는 이론적인 방법
* 데이터 모델 사용
1) 포인터 사용: 계층 데이터 모델, 네트워크 데이터 모델
2) 속성 값 사용: 관계 데이터 모델
3) 객체식별자 사용: 객체 데이터 모델
* 데이터 모델과 각 모델에서 관계의 표현 방법
* 데이터 모델의 발전 역사
* 3단계 데이터베이스 구조(ANSI)
<스키마 구조>
(!스키마 = Table 무방!)
• 외부 스키마
– 일반 사용자나 응용 프로그래머가 접근하는 계층으로 전체 데이터베이스 중에서 하나의 논리적인 부분임
– 여러 개의 외부 스키마(external schema)가 있을 수 있음
– 서브 스키마 (sub schema)라고도 하며, 뷰(view)의 개념임
– (예) 대학 데이터베이스 → 학생처의 학생 정보, 교무처 수강 정보, 취업처 취업 정보 등
* ER Diagram --> Entity Relation
• 개념적 모델링: 복잡한 현실 세계를 단순화하고 데이터베이스의 논리적 구조를 시각적으로 표현하는 도구
• 주요 구성 요소:
– 개체 (Entity): 데이터베이스에 표현될 대상(예: 학생, 강좌, 교수)
– 속성 (Attribute): 개체의 특징 (예: 학번, 이름, 학과)
– 관계 (Relationship): 개체 간의 연관성 (예: 수강, 지도)
• 데이터베이스 설계의 첫 걸음: ER 다이어그램을 통해 데이터베이스 구조를 명확히하고 효율적인 설계 가능
<ER Diagram의 활용>
• 논리적 모델링: 개념적 ER 다이어그램을 구체화하여 실제 데이터베이스 구현에 필요한 세부 정보 추가
– 기본 키 (Primary Key): 개체를 고유하게 식별하는 속성
– 외래 키 (Foreign Key): 관계를 나타내는 속성
• 소통 및 협업 도구
– 개발자, 데이터베이스 관리자, 사용자 간의 효과적인 의사소통 수단
• 데이터베이스 관리 시스템 (DBMS) 생성
– ER 다이어그램을 기반으로 데이터베이스 스키마 자동 생성 가능
• 데이터 무결성 유지
– 데이터베이스 제약 조건 설정을 통해 데이터 정확성 및 일관성 보장
'KNU Freshman > 컴퓨터학개론' 카테고리의 다른 글
| (15) 인공지능 (0) | 2024.06.09 |
|---|---|
| (14) 소프트웨어공학 (0) | 2024.06.09 |
| (12) 분산시스템 / 클라우드 (0) | 2024.06.03 |
| (11) 네트워크 (1) | 2024.06.03 |
| (10) 통신의 발전 과정 (0) | 2024.05.20 |
