slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
데이터베이스 개요 PowerPoint Presentation
Download Presentation
데이터베이스 개요

Loading in 2 Seconds...

  share
play fullscreen
1 / 75
Download Presentation

데이터베이스 개요 - PowerPoint PPT Presentation

jalen
133 Views
Download Presentation

데이터베이스 개요

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. The database system is one of the most complex systems that human ever built. 데이터베이스 개요 2005.3.17. Byung-Hyun Ha pepper@netopia.snu.ac.kr

  2. What a Database Is and Is Not • 아래의 어떤 것도 데이터베이스라고 할 수 있으며, 따라서 데이터베이스는 매우 일반적으로 사용되는 개념이다. • 치의학과 수업용 게시판의 치의학 강의자료 모음 • 엑셀로 작성한 치의학 수강생 리스트 • 아래아 한글로 작성한 주소록 • 통계분석을 위해 작성한 실험데이터 파일 • 차트에 기록된 환자 기본 정보와 상태 데이터 • 항공회사에서 좌석예약을 위해 수집하고, 유지하며, 사용하는 데이터 • SIS 수강신청 하위시스템에서 학생들이 입력한 수강신청 데이터 집합 • Etc.

  3. 학번 … 98406-050 98406-100 99406-060 95406-080 99406-077 … … 이름 … 한만칠 강철환 나기무 이악연 빈유경 … … 평점 … 3.78 4.09 3.87 1.99 3.54 … … 학과 … 산업공학과 대수학과 경영학과 광산학과 기악과 … … 지도교수 … 김영팔 박대수 이주식 최금광 노래만 … … Database • Table example

  4. 데이터베이스 용도 • 서울대학교 도서관 • Amazon • 신림동사무소 호적과 • 현대자동차 설계실 • 기상청 • 대우중공업 자재과 • 전화국 • ………… • 국민은행 • American Express • 편의점 • 삼성전자 인사관리부 • 서울대학교 학적과 • 대한항공 예약 서비스부 • 증권거래소 • 서울대학교병원

  5. 데이터베이스 정의 • 데이터베이스: 여러 응용 시스템들이 공용할 수 있도록 통합, 저장된 운영 데이터의 집합 • 통합된 데이터: 중복의 원칙적 배제(minimal redundancy) • 저장된 데이터: 컴퓨터를 중심으로 데이터를 저장 관리 • 운영 데이터: 조직의 목적에 부합하는 데이터 • 데이터베이스관리시스템(DBMS: DataBase Management System): • 응용 프로그램과 데이터베이스의 중재자로서 모든 응용 프로그램들이 DB를 공용할 수 있게끔 관리해 주는 소프트웨어 시스템 • A software package to facilitate creation, querying, updating and maintenance of a database

  6. Problems with traditional files • Data Redundancy - data held in more than one place, can lead to inconsistencies in data. • Data Dependence - programs specifically related to storage of data.

  7. DBMS CICS Employee Table Ledger Table Sales Table . . . Database File Processing vs. Database Systems Payroll Application Payroll Application Market Analysis Application Accounting Application . . . (COBOL) (COBOL/SQL) (C/SQL) (SQL) Payroll File

  8. 90년대 60년대 70년대 80년대 APPL D B M S UIMS UIMS APPL D B M S W F M S A P P L D B M S APPL OS OS OS OS EDPS ED&PMS 정보시스템 발전의 역사 Application과 Data가 결합된 형태 유지관리 곤란 및 응용범위 제한 Data를 Application 에서 분리 Data 변경에 따른 Application 적응성 향상 Business Processes 분리 유연성과 유지보수성 획기적 증대

  9. 데이터 파일 메타 데이터 (Meta data) 데이터베이스 일반 사용자 응용 프로그래머 데이터베이스 관리자 Query(질의) 응용 프로그램 데이터베이스관리시스템 (DBMS)

  10. Database and People • 최종사용자 • Predetermined queries and updates • Ad hoc queries (SQL) • 응용시스템 프로그래머 • SQL, embedded SQL, DBMS - specific 4GLs • 데이터베이스 요구사항 분석가/설계자 • Semantic schema design (ER diagrams) • Conceptual/external schema design (normalization, integrity constraints, views) • Physical database design (indexing) • Database administrator (DBA)

  11. 데이터베이스 특성 • 실시간 접근성: 처리에 대한 요구를 즉시 해결해야 한다. • 계속적인 변화: 삽입, 삭제, 갱신으로 항상 변하고, 그 변화 속에서 현재의 정확한 데이터를 유지해야 한다. • 동시 공용: 여러 사용자가 동시에 각자가 원하는 데이터에 접근(access)하여 이용할 수 있어야 한다. • 내용에 의한 참조: 레코드의 주소나 위치에 의해서가 아니라 사용자가 요구하는 데이터의 내용, 즉 데이터가 가지고 있는 값에 따라 참조(reference)될 수 있어야 한다.

  12. 데이터베이스 이점 • 데이터 중복의 최소화 (Redundancy) • 데이터 공용 (Share) • 데이터의 일관성 유지 (Consistency) • 데이터의 무결성 유지 (Integrity) • 데이터의 보안 보장 (Security) • 표준화 (Standard) • 전체 관점에서 데이터 관리 및 데이터 요구 조정 (Total management)

  13. 데이터베이스 단점 • 운영비 증대 • 자료 처리의 복잡화 • 복잡한 예비(backup)와 회복(recovery) • 시스템 취약성의 문제

  14. 데이터베이스 용도 실시간 접근성, 계속적 변화, 동시 공용, 내용에 의한 참조 • 국민은행 • American Express • 편의점 • 삼성전자 인사관리부 • 서울대학교 학적과 • 대한항공 예약 서비스부 • 증권거래소 • 서울대학교병원 • 서울대학교 도서관 • Amazon • 신림동사무소 호적과 • 현대자동차 설계실 • 기상청 • 대우중공업 자재과 • 전화국 • ………… 중복 최소화, 공용, 일관성, 무결성, 보안, 표준화, 통합

  15. Use a DBMS when this is important Do not use a DBMS when • H/W, S/W, 그리고 교육에 대한 초기 투자 부담 • DBMS가 제공하는 일반적 특성이 불필요할 때 • 보안, 동시성, 복구에 필요한 overhead가 지나치게 높을 때 • 데이터와 응용 시스템이 단순하고 안정적일 때 • 실시간 서비스에 대한 요구를 만족할 수 없을 때 • 다수 사용자를 지원할 필요가 없을 때 • 데이터의 영구적 저장 • 데이터의 중앙 집중 통제 • 데이터 중복(redundancy)의 통제 • 데이터 일관성(consistency)과 무결성(integrity) 통제 • 다수 사용자 지원 • 데이터 공유 • 데이터의 문서화 • 데이터 독립성(independence) • 데이터 접근(access) 및 보안 (security) 또는 권한 통제 • 데이터 백업 및 복구(recovery)

  16. 데이터베이스 종류 • 계층형 데이터베이스 (Hierarchical database) • 망형 데이터베이스 (Network database) • 관계형 데이터베이스 (RDB: Relational DataBase) • 객체지향 데이터베이스 (OODB: Object-Oriented DataBase)

  17. 계층형 데이터베이스 • 계층형 데이터베이스 (Hierarchical database) • 1960년대 개발 • Database의 논리적 구조를 트리(tree) 형태로 표현 (A child has only one parent) • parent-child relationship: one record type is the root, all other record types are a child of one parent record type only • 논리적 독립성 결여 • Database 구조에 변화가 생기면 응용 프로그램을 다시 개발 flight-sched flight# flight-inst dept-airp arriv-airp date airport-code airport-code customer customer# customer name

  18. F1 F2 R1 R2 R3 R4 R5 R6 C1 C4 망형 데이터베이스 • 망형 데이터베이스 (Network database) • 1970년대 개발 • 데이터간의 관계를 연결(네트워크) 구조로 표현 (A child can have more than one parent )

  19. flight-schedule relation name attribute names flight#: integer airline: char(20) weekday: char(2) price: dec(6,2) domain names 관계형 데이터베이스 - I • 관계형 데이터베이스 (RDB: Relational DataBase) • 1970년대 말 탄생 • Oracle에 의해 처음 상용화 (most recent and popular) • Oracle, DB2 (IBM), Informix, Sybase, Ingres • Borland’s Paradox; dBASE IV; Microsft’s Access; FoxPro; IBM’s OS/2 Database Manager; RBASE 5000; WATCOM SQL, SQL Server • Powerful set-oriented query languages • Capabilities of insert, delete, and update • Relational Algebra: procedural; describes how to compute a query; operators like JOIN, SELECT, PROJECT • Relational Calculus: declarative; describes the desired result, e.g. SQL.

  20. flight-schedule customer flight# customer# customer name p p reservation flight# date customer# 관계형 데이터베이스 - II • Integrity Constraints • Keys • Primary Keys • Entity Integrity • Referential Integrity

  21. reservation customer flight# date customer# customer# customer-name _c _c .P .P LEO 관계형 데이터베이스 - III • tuple calculus example (SQL) select flight#, date from reservation R, customer C where R.customer#=C.customer# and customer-name=‘LEO’;

  22. 객체지향 데이터베이스 • 객체지향 데이터베이스 (OODB: Object-Oriented DataBase) • Based on the object-oriented paradigm, e.g., Simula, Smalltalk, C++, Java. • 현재 계속 그리고 활발히 연구가 진행 중인 분야 • 데이터 스키마(schema)를 클래스(class)로 정의 • Object-oriented model has object-oriented repository model; adds persistence and database capabilities • ObjectStore, Objectivity, GemStone, Ontos, Orion-2, Statice, Versant, O2 • Object-relational model has relational repository model; adds object-oriented features • Starburst, POSTGRES, Oracle V. 8.0

  23. Prerelational vs. Relational billion $ • Prerelational market revenue shrinking about 9%/year. Currently 1.8 billion/year • Relational market revenue growing about 30%/year. Currently 11.5 billion/year • Object-Oriented market revenue about 150 million/year

  24. Revenues for the entire database market: $13.5 billion Database Vendors Source: IDC, 2003

  25. DBMS 필수기능 • 정의 기능 • 응용 프로그램이 요구하는 데이터 구조 지원 • 데이터베이스를 물리적 저장장치에 저장하는데 필요한 명세 • 데이터의 논리적 구조와 물리적 구조 사이의 변환 • 조작 기능 • 데이터의 검색, 삽입, 삭제, 갱신을 지원하는 기능 • 제어 기능 • 무결성 유지, 보안과 권한, 병행제어

  26. Data Organization - key terms • Entity - person, place, or thing that we wish to collect information on (e.g. students). • Attribute - a characteristic of an entity (e.g. student name, student address). Is equivalent to a Field in the data hierarchy. • Key Field- a special field that uniquely identifies a single record (e.g. student number).Can be a collection of fields.

  27. DML database system database system DDL schema database data ANSI/SPARC 3-Level DB Architecture - separating concerns • A database is divided into schema and data • The schema describes the intension (types) • The data describes the extension (data) • Why? Effective! Efficient!

  28. 데이터베이스 스키마 • 스키마(schema) • 데이터베이스의 논리적 정의 • 데이터 구조와 제약 조건에 대한 명세를 기술한 것 • 데이터 객체(object) 또는 • 개체(entity)와 개체의 속성(attribute) • 개체간의 관계(relationship)에 대한 정의 • 관계에 대한 제약 조건(constraint)

  29. 데이터베이스 스키마 • 외부 스키마 (External schema) • 개별 사용자 입장 • 개개 사용자나 응용 프로그래머가 접근하는 데이터베이스의 정의로 전체의 일부분이므로 ‘서브스키마’ • 개념 스키마 (Conceptual schema) • 전체 시스템 입장 • 모든 사용자나 응용 시스템이 접근하는 데이터를 종합한 구조로 개념 스키마에서 외부 스키마 생성, ‘스키마’ • 내부 스키마 (Internal schema) • 저장 장치 입장 • 개념 스키마의 물리적 저장 구조에 대한 정의

  30. External level View 1 View 2 View N Conceptual level Internal level 데이터베이스 스키마 Appl. 1 Appl. 2 Appl. N . . . . . . external/conceptual mapping Conceptual Schema: a collection of relation schemas (def. of base relations) conceptual/internal mapping index Base relation

  31. ANSI/SPARC 3-Level DB Architecture external schema1 external schema2 external schema3 conceptual schema • external schema: • use of data • conceptual schema: • meaning of data • internal schema: • storage of data internal schema database

  32. 외부 스키마 1(학적과) ST SN INT NAME CHAR(10) GRADE INT DEPT CHAR(5) 외부 스키마2 (학생과) STUDENT SNO PIC 9(4) SNAME PIC X(10) YEAR PIC 9(2) ADDR PIC X(44) 개념 스키마 STUDENT SNUMBER INTEGER NAME CHAR(10) YEAR SMALLINT GRADE SMALLINT DEPT CHAR(5) ADDRESS CHAR(44) 내부 스키마 STORED-STUDENT LENGTH=71 Prefix BYTE(4) OFFSET=0 SNO BYTE(4) OFFSET=4 ……

  33. Conceptual Schema • Describes all conceptually relevant, general, time-invariant structural aspects of the universe of discourse. • Excludes aspects of data representation and physical organization, and access. CUSTOMER NAME ADDR SEX AGE • An object-oriented conceptual schema would also describe all process aspects.

  34. External Schema • Describes parts of the information in the conceptual schema in a form convenient to a particular user group’s view • Is derived from the conceptual schema MALE-TEEN-CUSTOMER NAME ADDR TEEN-CUSTOMER(X, Y) = CUSTOMER(X, Y, S, A) WHERE SEX=M AND 12<A<20; CUSTOMER NAME ADDR SEX AGE

  35. Internal Schema • Describes how the information described in the conceptual schema is physically represented to provide the overallbest performance CUSTOMER NAME ADDR SEX AGE CUSTOMER NAME ADDR SEX AGE B+-tree on AGE index on NAME NAME PTR

  36. Physical Data Independence external schema1 external schema2 external schema3 conceptual schema internal schema Physical data independence is a measure of how much the internal schema can change without affecting the application programs database

  37. Logical Data Independence external schema1 external schema2 external schema3 conceptual schema internal schema Logical data independence is a measure of how much the conceptual schema can change without affecting the application programs database

  38. System metadata: Where data came from How data were changed How data are stored How data are mapped Who owns data Who can access data Data usage history Data usage statistics Business metadata: What data are available Where data are located What the data mean How to access the data Predefined reports Predefined queries How current the data are Metadata - What is it? Metadata - Why is it important? • System metadata are critical in a DBMS • Business metadata are critical in a data warehouse

  39. 데이터 언어 • 데이터 정의어(DDL: Data Definition Language) • DB 구조를 정의하거나 그 정의를 수정할 목적으로 사용하는 언어 • 데이터 사전, 시스템 카탈로그에 저장하여 놓고 필요한 경우에 시스템에 활용 • 데이터 조작어(DML: Data Manipulation Language) • DB의 정보에 접근(access)하기 위한 목적으로 사용하는 언어 • 절차적 DML (한번에 하나의 레코드)와 비절차적 DML (set 단위의 레코드) • SQL (Structured Query Language): Most common DML • 데이터 제어어 (DCL: Data Control Language) • 보안, 무결성, 회복, 병행 제어

  40. Query language DML 응용 프로그래머 (Application programmer) DB 설계자 DML DDL DDL DDL, DCL 데이터 언어와 사용자 일반 사용자 (End user) 응용 프로그래머 (Application programmer) DB 설계자 DB 관리자 (DBA)

  41. 데이터베이스와 관련된 사람들 • 시스템 분석가 • 데이터베이스 설계자 • 응용시스템 개발자 • DBA (Database Administrators) • 최종사용자

  42. 시스템 분석가 • 다음을 이해하기 위해 개별 데이터베이스 사용자 그룹과 communication • information needs • processing needs • 개별 데이터베이스 사용자 그룹의 information 및 processing 요구사항에 대한 specification 개발 • 데이터베이스 사용자 그룹의 information 및 processing 요구사항 specification을 통합 • Specification을 문서화

  43. 데이터베이스 설계자 • 시스템 분석가의 information에 대한 specification 을 표현하기에 적절한 구조를 선정 • 데이터의 무결성과 일관성을 보장하기 위해 정규화(normalization)된 방식으로 정보를 저장하기에 적절한 구조를 선정 • 효율적인 시스템을 위한 적절한 구조 선정 • 데이터베이스 설계 결과를 문서화

  44. 응용시스템 개발자 • 데이터베이스 설계 결과를 구현 • 프로그램 specifications를 만족하는 응용 프로그램을 구현 • 데이터베이스 구현과 응용 프로그램을 테스트하고 debug • 데이터베이스 구현과 응용 프로그램에 대한 문서화

  45. DBA - I • 데이터베이스 구조 관리 • 데이터베이스 및 응용 시스템 개발에 참여 • 요구사항 분석 지원 • 데이터베이스 설계 및 데이터베이스 테이블 생성에 참여 • 데이터 무결성과 품질을 보장하기 위한 절차 개발 • 데이터베이스 구조 변경을 편리하게 함 • 조직 전체의 입장에서 해결책 강구 • 모든 사용자에 대한 영향도 평가 • Configuration control (형상 관리) 제공 • 변화가 일어난 후 문제점에 대한 대비책 준비 • 지속적 문서 유지 관리

  46. DBA - II • 데이터 관련 활동 관리 • 데이터 관리 표준과 일치하는 데이터베이스 표준 결정 • 데이터 사전 (data dictionary) 작성 및 유지 • 데이터 제공자 결정 • 데이터 접근 및 수정 권한을 개발하기 위해 데이터 제공자와 협력 • 백업 및 복구 절차를 개발하고, 문서화 하며, 담당자 교육 • 데이터 관련 활동의 표준을 문서화 하여 알리고 유지 보수

  47. DBA - III • DBMS 관리 • 데이터베이스 응용시스템의 performance에 대한 보고서 작성 • 사용자의 performance에 대한 불만 조사 • 데이터베이스 구조나 응용시스템 설계의 변화 필요성 평가 • 데이터베이스 구조 변경 • 새로운 DBMS 기능을 평가하고 구현 • 데이터베이스 튜닝 • 데이터베이스의 데이터 사전 결정 • 데이터 이름, 형식, 관계 • 데이터와 응용 프로그램 간의 cross-references • Meta data 관리

  48. 최종 사용자 • 단순 사용자: 일상적으로 데이터베이스를 query하고 업데이트하는 최종 사용자. 표준 queries 및 updates를 지원하는 canned transactions 사용. • 중급 사용자: 보통 간헐적으로 데이터베이스를 사용하나 매번 다른 정보를 필요로 하는 최종 사용자. 세련된 query languages와 browsers를 구사하고 사용 • 고급 사용자: 매번 복잡한 요구사항과 다른 정보를 필요로 하는 최종 사용자. DBMS의 능력에 대해 정통한 사용자.

  49. 데이터 모델

  50. 모델을 사용하는 이유 • 모델은 실세계의 일부분을 검사하거나 관리하는 데 유용 • 모델 사용이 실세계를 직접 사용하거나 시험하는 것보다 비용 효과적 • 예: • 비행기 조종 시뮬레이터 • 원자력 발전소 시뮬레이터 • 홍수경보시스템 • 한국경제지표 계산 모델 • Surgical Simulator • 지도 • etc. 지도는 현실에 대한 모델