Transcript 데이터베이스 개요
The database system is one of the most complex systems that human ever built. 데이터베이스 개요 2005.3.17. Byung-Hyun Ha [email protected] What a Database Is and Is Not • 아래의 어떤 것도 데이터베이스라고 할 수 있으며, 따라서 데이터베이스는 매우 일반적으로 사용되는 개념이다. - 치의학과 수업용 게시판의 치의학 강의자료 모음 - 엑셀로 작성한 치의학 수강생 리스트 - 아래아 한글로 작성한 주소록 - 통계분석을 위해 작성한 실험데이터 파일 - 차트에 기록된 환자 기본 정보와 상태 데이터 - 항공회사에서 좌석예약을 위해 수집하고, 유지하며, 사용하는 데이터 - SIS 수강신청 하위시스템에서 학생들이 입력한 수강신청 데이터 집합 - Etc. Database • Table example 학번 이름 평점 학과 지도교수 … … … … … 98406-050 한만칠 3.78 산업공학과 김영팔 98406-100 강철환 4.09 대수학과 박대수 99406-060 나기무 3.87 경영학과 이주식 95406-080 이악연 1.99 광산학과 최금광 99406-077 빈유경 3.54 기악과 노래만 … … … … … … … … … … 데이터베이스 용도 • • • • • • • • 국민은행 American Express 편의점 삼성전자 인사관리부 서울대학교 학적과 대한항공 예약 서비스부 증권거래소 서울대학교병원 • • • • • • • • 서울대학교 도서관 Amazon 신림동사무소 호적과 현대자동차 설계실 기상청 대우중공업 자재과 전화국 ………… 데이터베이스 정의 • 데이터베이스: 여러 응용 시스템들이 공용할 수 있도록 통합, 저 장된 운영 데이터의 집합 – 통합된 데이터: 중복의 원칙적 배제(minimal redundancy) – 저장된 데이터: 컴퓨터를 중심으로 데이터를 저장 관리 – 운영 데이터: 조직의 목적에 부합하는 데이터 • 데이터베이스관리시스템(DBMS: DataBase Management System): – 응용 프로그램과 데이터베이스의 중재자로서 모든 응용 프로그램들 이 DB를 공용할 수 있게끔 관리해 주는 소프트웨어 시스템 – A software package to facilitate creation, querying, updating and maintenance of a database 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. File Processing vs. Database Systems Payroll Application (COBOL) Payroll Market Analysis Accounting Application Application Application . . . (COBOL/SQL) (C/SQL) (SQL) CICS Payroll File DBMS Employee Table Ledger Table ... Database Sales Table 정보시스템 발전의 역사 60년대 90년대 70년대 80년대 APPL D B APPL M S UIMS D B APPL M S UIMS W A D F P B M P M S L S OS OS OS OS Application과 Data 가 결합된 형태 Data를 Application 에서 분리 Business Processes 분리 유지관리 곤란 및 응용범위 제한 Data 변경에 따른 Application 적응성 향상 유연성과 유지보수 성 획기적 증대 EDPS ED&PMS 데이터베이스 일반 사용자 응용 프로그래머 데이터베이스 관리자 Query(질의) 응용 프로그램 데이터베이스관리시스템 (DBMS) 데이터 파일 메타 데이터 (Meta data) 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) 데이터베이스 특성 1) 실시간 접근성: 처리에 대한 요구를 즉시 해결해야 한 다. 2) 계속적인 변화: 삽입, 삭제, 갱신으로 항상 변하고, 그 변화 속에서 현재의 정확한 데이터를 유지해야 한다. 3) 동시 공용: 여러 사용자가 동시에 각자가 원하는 데이 터에 접근(access)하여 이용할 수 있어야 한다. 4) 내용에 의한 참조: 레코드의 주소나 위치에 의해서가 아니라 사용자가 요구하는 데이터의 내용, 즉 데이터가 가지고 있는 값에 따라 참조(reference)될 수 있어야 한 다. 데이터베이스 이점 • • • • • • • 데이터 중복의 최소화 (Redundancy) 데이터 공용 (Share) 데이터의 일관성 유지 (Consistency) 데이터의 무결성 유지 (Integrity) 데이터의 보안 보장 (Security) 표준화 (Standard) 전체 관점에서 데이터 관리 및 데이터 요구 조 정 (Total management) 데이터베이스 단점 • • • • 운영비 증대 자료 처리의 복잡화 복잡한 예비(backup)와 회복(recovery) 시스템 취약성의 문제 데이터베이스 용도 실시간 접근성, 계속적 변화, 동시 공용, 내용에 의한 참조 • • • • • • • • 국민은행 American Express 편의점 삼성전자 인사관리부 서울대학교 학적과 대한항공 예약 서비스부 증권거래소 서울대학교병원 • • • • • • • • 서울대학교 도서관 Amazon 신림동사무소 호적과 현대자동차 설계실 기상청 대우중공업 자재과 전화국 ………… 중복 최소화, 공용, 일관성, 무결성, 보안, 표준화, 통합 Use a DBMS when this is important • 데이터의 영구적 저장 • 데이터의 중앙 집중 통제 • 데이터 중복(redundancy)의 통제 • 데이터 일관성(consistency)과 무결성(integrity) 통제 • 다수 사용자 지원 • 데이터 공유 • 데이터의 문서화 • 데이터 독립성(independence) • 데이터 접근(access) 및 보안 (security) 또는 권한 통제 • 데이터 백업 및 복구(recovery) Do not use a DBMS when • H/W, S/W, 그리고 교육에 대한 초기 투자 부담 • DBMS가 제공하는 일반적 특성이 불필요할 때 • 보안, 동시성, 복구에 필요한 overhead가 지나치게 높을 때 • 데이터와 응용 시스템이 단순하고 안정적일 때 • 실시간 서비스에 대한 요구를 만족할 수 없을 때 • 다수 사용자를 지원할 필요가 없을 때 데이터베이스 종류 • 계층형 데이터베이스 (Hierarchical database) • 망형 데이터베이스 (Network database) • 관계형 데이터베이스 (RDB: Relational DataBase) • 객체지향 데이터베이스 (OODB: Object-Oriented DataBase) 계층형 데이터베이스 1) 계층형 데이터베이스 (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 customer airport-code airport-code customer# customer name 망형 데이터베이스 • 망형 데이터베이스 (Network database) – 1970년대 개발 – 데이터간의 관계를 연결(네트워크) 구조로 표현 (A child can have more than one parent ) F1 R1 F2 R2 C1 R3 R4 R5 C4 R6 관계형 데이터베이스 - I 3) 관계형 데이터베이스 (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. relation name flight-schedule attribute names domain names flight#: integer airline: weekday: price: char(20) char(2) dec(6,2) 관계형 데이터베이스 - II • Integrity Constraints – Keys – Primary Keys – Entity Integrity – Referential Integrity flight-schedule customer flight# p customer# p reservation flight# date customer# customer name 관계형 데이터베이스 - III • tuple calculus example (SQL) select flight#, date from reservation R, customer C where R.customer#=C.customer# and customer-name=‘LEO’; reservation flight# date .P .P customer# _c customer customer# customernameLEO _c 객체지향 데이터베이스 • 객체지향 데이터베이스 (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 objectoriented features – Starburst, POSTGRES, Oracle V. 8.0 Prerelational vs. Relational 14 prerelational relational 12 billion $ 10 8 6 4 2 0 1994 1995 1996 1997 1998 1999 • 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 Database Vendors • Revenues for the entire database market: $13.5 billion Others Sybase Oracle Microsoft SQL Server IBM DB2 Source: IDC, 2003 DBMS 필수기능 • 정의 기능 – 응용 프로그램이 요구하는 데이터 구조 지원 – 데이터베이스를 물리적 저장장치에 저장하는데 필요한 명세 – 데이터의 논리적 구조와 물리적 구조 사이의 변환 • 조작 기능 – 데이터의 검색, 삽입, 삭제, 갱신을 지원하는 기능 • 제어 기능 – 무결성 유지, 보안과 권한, 병행제어 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. ANSI/SPARC 3-Level DB Architecture separating concerns DML database system database database system DDL schema data • • • • A database is divided into schema and data The schema describes the intension (types) The data describes the extension (data) Why? Effective! Efficient! 데이터베이스 스키마 • 스키마(schema) – 데이터베이스의 논리적 정의 – 데이터 구조와 제약 조건에 대한 명세를 기술한 것 – 데이터 객체(object) 또는 • 개체(entity)와 개체의 속성(attribute) • 개체간의 관계(relationship)에 대한 정의 • 관계에 대한 제약 조건(constraint) 데이터베이스 스키마 1) 외부 스키마 (External schema) – 개별 사용자 입장 – 개개 사용자나 응용 프로그래머가 접근하는 데이터베이스의 정의로 전체의 일부분이므로 ‘서브스키마’ 2) 개념 스키마 (Conceptual schema) – 전체 시스템 입장 – 모든 사용자나 응용 시스템이 접근하는 데이터를 종합한 구조로 개 념 스키마에서 외부 스키마 생성, ‘스키마’ 3) 내부 스키마 (Internal schema) – 저장 장치 입장 – 개념 스키마의 물리적 저장 구조에 대한 정의 데이터베이스 스키마 Appl. 1 Appl. 2 ... Appl. N View 1 View 2 ... View N External level external/conceptual mapping Conceptual Schema: a collection of relation schemas (def. of base relations) Conceptual level conceptual/internal mapping index Base relation Internal level ANSI/SPARC 3-Level DB Architecture external schema1 external schema2 conceptual schema external schema3 • external schema: use of data internal schema • conceptual schema: meaning of data • internal schema: storage of data database 외부 스키마 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 Prefix BYTE(4) SNO BYTE(4) …… LENGTH=71 OFFSET=0 OFFSET=4 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. 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) CUSTOMER NAME WHERE SEX=M AND 12<A<20; ADDR SEX AGE Internal Schema • Describes how the information described in the conceptual schema is physically represented to provide the overall best performance CUSTOMER NAME ADDR SEX AGE ADDR SEX AGE index on NAME NAME CUSTOMER NAME B+-tree on AGE PTR Physical Data Independence external schema1 external schema2 external schema3 conceptual schema internal schema database Physical data independence is a measure of how much the internal schema can change without affecting the application programs Logical Data Independence external schema1 external schema2 external schema3 conceptual schema internal schema database Logical data independence is a measure of how much the conceptual schema can change without affecting the application programs Metadata - What is it? • System metadata: • Business metadata: – Where data came from – What data are available – How data were changed – Where data are located – How data are stored – What the data mean – How data are mapped – How to access the data – Who owns data – Predefined reports – Who can access data – Predefined queries – Data usage history – How current the data are – Data usage statistics Metadata - Why is it important? • • System metadata are critical in a DBMS Business metadata are critical in a data warehouse 데이터 언어 1) 데이터 정의어(DDL: Data Definition Language) – DB 구조를 정의하거나 그 정의를 수정할 목적으로 사용하는 언어 – 데이터 사전, 시스템 카탈로그에 저장하여 놓고 필요한 경우에 시스 템에 활용 2) 데이터 조작어(DML: Data Manipulation Language) – DB의 정보에 접근(access)하기 위한 목적으로 사용하는 언어 – 절차적 DML (한번에 하나의 레코드)와 비절차적 DML (set 단위의 레코드) – SQL (Structured Query Language): Most common DML 3) 데이터 제어어 (DCL: Data Control Language) – 보안, 무결성, 회복, 병행 제어 데이터 언어와 사용자 일반 사용자 (End user) Query language 응용 프로그래머 (Application programmer) DML DB 설계자 DDL DB 관리자 (DBA) DDL, DCL 데이터베이스와 관련된 사람들 • • • • • 시스템 분석가 데이터베이스 설계자 응용시스템 개발자 DBA (Database Administrators) 최종사용자 시스템 분석가 • 다음을 이해하기 위해 개별 데이터베이스 사용자 그룹 과 communication – information needs – processing needs • 개별 데이터베이스 사용자 그룹의 information 및 processing 요구사항에 대한 specification 개발 • 데이터베이스 사용자 그룹의 information 및 processing 요구사항 specification을 통합 • Specification을 문서화 데이터베이스 설계자 • 시스템 분석가의 information에 대한 specification 을 표 현하기에 적절한 구조를 선정 • 데이터의 무결성과 일관성을 보장하기 위해 정규화 (normalization)된 방식으로 정보를 저장하기에 적절한 구조를 선정 • 효율적인 시스템을 위한 적절한 구조 선정 • 데이터베이스 설계 결과를 문서화 응용시스템 개발자 • 데이터베이스 설계 결과를 구현 • 프로그램 specifications를 만족하는 응용 프로그램을 구 현 • 데이터베이스 구현과 응용 프로그램을 테스트하고 debug • 데이터베이스 구현과 응용 프로그램에 대한 문서화 DBA - I • 데이터베이스 구조 관리 – 데이터베이스 및 응용 시스템 개발에 참여 – 요구사항 분석 지원 – 데이터베이스 설계 및 데이터베이스 테이블 생성에 참여 – 데이터 무결성과 품질을 보장하기 위한 절차 개발 – 데이터베이스 구조 변경을 편리하게 함 – 조직 전체의 입장에서 해결책 강구 – 모든 사용자에 대한 영향도 평가 – Configuration control (형상 관리) 제공 – 변화가 일어난 후 문제점에 대한 대비책 준비 – 지속적 문서 유지 관리 DBA - II • 데이터 관련 활동 관리 – 데이터 관리 표준과 일치하는 데이터베이스 표준 결정 – 데이터 사전 (data dictionary) 작성 및 유지 – 데이터 제공자 결정 – 데이터 접근 및 수정 권한을 개발하기 위해 데이터 제공자와 협력 – 백업 및 복구 절차를 개발하고, 문서화 하며, 담당자 교육 – 데이터 관련 활동의 표준을 문서화 하여 알리고 유지 보수 DBA - III • DBMS 관리 – 데이터베이스 응용시스템의 performance에 대한 보고서 작성 – 사용자의 performance에 대한 불만 조사 – 데이터베이스 구조나 응용시스템 설계의 변화 필요성 평가 – 데이터베이스 구조 변경 – 새로운 DBMS 기능을 평가하고 구현 – 데이터베이스 튜닝 • 데이터베이스의 데이터 사전 결정 – 데이터 이름, 형식, 관계 – 데이터와 응용 프로그램 간의 cross-references – Meta data 관리 최종 사용자 • 단순 사용자: 일상적으로 데이터베이스를 query하고 업데이트하는 최종 사용자. 표준 queries 및 updates를 지원하는 canned transactions 사용. • 중급 사용자: 보통 간헐적으로 데이터베이스를 사용하 나 매번 다른 정보를 필요로 하는 최종 사용자. 세련된 query languages와 browsers를 구사하고 사용 • 고급 사용자: 매번 복잡한 요구사항과 다른 정보를 필 요로 하는 최종 사용자. DBMS의 능력에 대해 정통한 사용자. 데이터 모델 모델을 사용하는 이유 • 모델은 실세계의 일부분을 검사하거나 관리하는 데 유용 • 모델 사용이 실세계를 직접 사용하거나 시험하는 것보다 비용 효 과적 • 예: – 비행기 조종 시뮬레이터 – 원자력 발전소 시뮬레이터 – 홍수경보시스템 – 한국경제지표 계산 모델 – Surgical Simulator – 지도 – etc. 지도는 현실에 대한 모델 지도제작자에게 할 말 있음 • 지도제작자에게 주문하면서: “고속도로는 붉은 색으로 표시하고, 강을 경계로 한 도계는 강 중앙을 따라 경계를 표시해 주시고, XXX 산의 경우 등고선이 분명히 보이도록 만들어 주시오.” • 모델은 커뮤니케이션의 한 가지 수단 • 모델 사용자는 일반적으로 모델에 대해 일정 수준의 지식이 있어 야 함. • 모델은 특정의 선택된 관점들을 강조해서 표현함. • 모델은 어떤 언어 (language)를 이용하여 기술함. • 모델은 에러가 있을 수 있음. 데이터베이스는 현실에 대한 모델 DML DATABASE SYSTEM REALITY • structures • processes • • • • • DDL DATABASE 데이터베이스는 현실세계의 구조에 대한 하나의 모델 데이터베이스의 사용은 현실세계에서 일어나는 프로세스를 반영함. 데이터베이스 시스템은 데이터베이스의 정의와 사용을 지원하는 소프트웨어 시스템 DDL: Data Definition Language DML: Data Manipulation Language 데이터 모델링 DATABASE SYSTEM REALITY • structures MODEL • processes Data modeling 모델은 현실세계의 구조에 대한 인식을 표현 데이터 모델링 과정은 이 인식에 대한 오류를 수정하는 과정 데이터 모델링 과정에서 관점을 선정하고, 추상화 하는 일을 함. 프로세스 모델링 REALITY Process modeling DATABASE SYSTEM • structures MODEL • processes 모델의 사용은 현실세계의 프로세스를 반영함. 프로세스는 embedded database queries와 updates를 포함한 프로그램으로 표현됨 프로세스는 실행 시에 ad-hoc database queries와 updates로 표현되기도 함. DML PROG DML 데이터베이스 설계 • 데이터베이스 설계의 목적은 아래와 같은 데이터베이스를 만드는 것 – 현실 세계의 구조에 대한 모델 – 현실 세계의 프로세스를 모델링하는 질의(queries)와 갱신 (updates)을 지원 – 효율적 작동 관계형 데이터베이스 • 모든 데이터들을 테이블과 같은 형태로 나타내어 저장하는 데이 터베이스 • 일상 생활에서 데이터를 정리하여 표현할 때 흔히 표와 같은 방법 을 사용하게 되는데, 관계형 데이터베이스는 이 ‘표’의 개념을 사 용해서 데이터를 구성하는 방법을 사용 관계형 데이터베이스 – 테이블의 정의 열(속성, Attribute) 행(Tuple) 학번 이름 평점 학과 지도교수 … … … … … 98406-050 한만칠 3.78 산업공학과 김영팔 98406-100 강철환 4.09 대수학과 박대수 99406-060 장옹조 3.87 경영학과 이주식 95406-080 이악연 1.99 광산학과 최금광 99406-077 빈유경 3.54 기악과 노래만 … … … … … … … … … … 관계형 데이터베이스 – 속성(Attribute) • 관계형 데이터베이스에서 각각의 열을 말함. • 실제 값은 그 속성에 따라 다른 형태를 가지고 있음. • 테이블의 각 열에 올 수 있는 값의 범위와 종류가 정해져 있음. • Table의 한 행은 각 항목의 가능한 값의 조합들 중 하나가 됨. • 이렇게 행의 각 항목이 가능한 값들로 이루어져 있는 행(tuple)들 의 집합을 관계(relation = table)라고 함. 관계형 데이터베이스 – View • A view is a relation derived from one or more base relations or other views • Honor Students 학번 이름 평점 학과 지도교수 98406-050 한만칠 3.78 산업공학과 김영팔 98406-100 강철환 4.09 수학과 박대수 99406-060 장옹조 3.87 경영학과 이주식 99406-077 빈유경 3.54 기악과 노래만 관계형 데이터베이스 – 데이터베이스 스키마 • 각 항목을 정의하여 만든 테이블의 틀 • Ex) 학생 = (이름, 학번, 학과, 출생년도) • 전체 데이터베이스에서 각각의 table을 정의하면 하나의 데이터 베이스에 대한 틀이 만들어 지는데 이것을 데이터베이스 스키마 라고 함. 관계형 데이터베이스 – 테이블 키 속성 • 키(key): Tuple을 유일하게 식별할 수 있는 attribute의 집합 ex) 학생 테이블의 <학번> • 슈퍼키(super key) : 유일성만 가지고 최소성은 없는 attribute의 집합 ex) 학생 테이블의 <학번, 이름> • 기본키(primary key): 후보키가 둘 이상인 경우 그 중 하나를 선택하여 기본키로 지정. 기본키는 널(NULL)이 될 수 없으며, 중복될 수도 없음. • 외래키(foreign key): 두 테이블 간의 relationship을 정의하는 것으로, Relation R1에 속한 한 attribute의 집합 FK가 어떤 relation R2의 기본 키가 될 때, 이 FK를 R1의 외래키라고 한다. – 즉, 한 테이블에서 primary key로 정의된 attribute가 다른 테이블에서 사 용될 때 이 attribute는 두 번째 테이블에서 foreign key가 될 수 있다. ex) 교수(교수번호, 교수이름, 학과번호, 직급) 학과(학과번호, 학과이름, 학과장 교수번호, 학생수) 데이터 모델 1) 데이터 모델은 속성들로 기술된 개체 타입과 이 개체 타입들간의 관계를 이용하여 현실세계를 표현 2) 데이터 모델은 아래를 표시하는 기호로 구성 – 데이터 구조 – 무결성 제약 (integrity constraints) – 운영 (operation) • 데이터 모델 종류 – 관계 데이터 모델, 네트워크 데이터 모델, 계층 데이터 모델 • Entity-Relationship (E-R) Diagram (개체-관계 모델) – 데이터베이스 설계에 매우 성공적으로 사용되어온 도구 데이터 모델 - 데이터 구조 entity type composite attribute relationship type attribute subset relationship type Multi-valued attribute d disjoint x exclusion Derived attribute p partition 데이터 모델 - 데이터 구조 학생 학번 교수 교수번호 이름 이름 출생년도 학생개체 학과 교수개체 학과이름 강좌 강좌번호 강좌명 소속대학 인정학점 시간 학과개체 강좌개체 강의실 E-R Diagram – 관계(relationship)1 • 데이터베이스를 구축하려고 하는 데이터들은 서로 관련되어 있음. • 서로 관련이 있는 대상을 개체(Entity)라고 할 때, 개체들간에 관 계(relationship)를 정의할 필요가 있음. • 이를 E-R Diagram으로 표현할 때는 다음과 같이 마름모를 사용 하여 관계되는 개체들을 서로 연결함. 개체 1 관계 E-R 모델에서 관계의 정의 개체 2 학과이름 학번 소속대학 이름 전공한다 학생 학과 출생년도 속한다 지도한다 수강한다 강좌번호 강좌명 강의한다 교수 강좌 인정학점 교수번호 이름 시간 강의실 E-R Diagram – 관계 (relationship) 2 • 여러 형태의 관계 – N:1 – M:N • 관계의 속성 개체의 경우와 마찬가지로 개체들간의 관계에 대해서도 특성을 부여할 수 있는데, 이를 관계에 대한 속성이라 함. 데이터 모델 – 무결성 제약 • 무결성 (integrity) 제약은 데이터 구조만으로는 설명될 수 없는 규칙을 기술하는 것으로, 모델이 현실세계를 잘 반영하고 있는가를 설명한다. • Entity integrity: 한 테이블 내에 중복된 데이터를 허용하지 않는 것과 주키가 null이 될 수 없음. – FLIGHT-SCH의 FLIGHT#는 현실세계에 존재하는 개체를 모델링한 것이므로 중복될 수 없고, 또 null이 될 수도 없다. • Referential integrity: 테이블 간의 일관성(consistency)을 설명하는 것으로, 모델 내부에 상충(conflicts)이 없어야 함. – 모든 FLIGHT-SCH 개체는 반드시 하나의 DEPT-AIRPORT 개체와 관계를 가진다. 즉, DEPTAIRPORT의 FLIGHT#는 반드시 FLIGHT-SCH에 있어야 한다. 존재하지 않는 FLIGHT-SCH 개 체가 DEPT-AIRPORT 개체를 갖는다는 것은 있을 수 없기 때문이다. • Semantic integrity: Attribute의 값은 설정된 domain 제약과 범위를 준수하는 형태이어 야 함. FLIGHT-SCH FLIGHT# DEPT-AIRPORT AIRLINE WEEKDAY PRICE FLIGHT# AIRPORT-CODE 101 delta mo 156 101 atl 545 american we 110 912 cph 912 scandinavian fr 450 545 lax 242 usair mo 231 242 bos ER Model - Example visa required domestic flight dept time street airport name airport code airport addr airport city dept airport 1 1 arriv time zip arriv airport international flight n p n flight schedule 1 weekdays instance of customer# date n customer name customer n reservation n seat# flight instance flight# ER Model – Example 2 개체간의 관계를 표시해보자. 학과이름 학번 이름 전공한다 학생 출생년도 소속대학 학과 속한다 지도한다 수강한다 강좌번호 강좌명 강의한다 교수 강좌 인정학점 교수번호 이름 시간 강의실 User Info. Requirements: Example • The company is organized into departments. Each dept. has a name, number, and an employee who manages the dept. We keep track of the start date of the dept. manager. A dept. may have several locations. • Each dept. controls a number of projects. Each project has a name, number, and is located at a single location. • We store each employee’s ssn, address, salary, sex, and birth date. Each employee works for one dept., but may work on several projects. We keep track of the number of hours per week that an employee currently works on each project. We also keep track of the direct supervisor of each employee. • Each employee may have a number of dependents. For each dependent, we keep their name, sex, birth date, and relationship to the employee. Entity-Relationship Diagram The company is organized into departments. Each dept. has a name, number, and an employee who manages the dept. We keep track of the start date of the dept. manager. A dept. may have several locations. name number locations department startdate 1 manage 1 employee Conceptual Database Schema: Example • employee (ssn, fname, minit, lname, bdate, address, sex, salary, superssn, dno) • department (dnumber, dname, mgrssn, mgrstdate) • dept_loc (dnumber, dloc) • project (pnumber, pname, ploc, dno) • works_on (essn, pno, hours) • dependent (essn, dependent_name, sex, bdate) – primary key – foreign key 데이터 모델 - 운영 Operations는 데이터 변경과 추출을 지원하는 것을 말하는 것으로 아래와 같은 query languages를 사용 • • insert FLIGHT-SCHEDULE(97, delta, tu, 258); atl); select FLIGHT#, WEEKDAY from FLIGHT-SCHEDULE where AIRLINE=‘delta’; insert DEPT-AIRPORT(97, FLIGHT-SCHEDULE DEPT-AIRPORT PRICE FLIGHT# AIRPORT-CODE FLIGHT# AIRLINE WEEKDAY 101 delta mo 156 101 atl 545 american we 110 912 cph 912 scandinavian fr 450 545 lax 242 usair mo 231 242 bos 97 delta tu 258 97 atl 강의계획, OK? 13,14 File Organization Indexing 1,2 Introductory 5,6 Relational Model, Algebra, Calculus 10,11 Dependencies, Normalization 8,9 SQL, DB Programming 15,16 Query Processing, DB Tuning 17,18,19 Transactions, Concurrency, Recovery 3,4 ER Model, EER Model 7 ER, EERTo-relational 20 Object-Oriented Concepts 12 DB Design, UML 23 Security 27,28 Data Mining, Warehousing 25 Distributed, Client Server 24 Active, Tempered, Deductive 22 Object Relational 26 XML 21 ODMG, ODL, OQL