스니스니 닷넷

Chap 1. Database and Database Users

1.1 Introduction
▪ Database : a collection of related data
▪ Data : kwon facts (that can be recorded and have implicit meaning)
▪ Database의 implicit properties
① Miniworld 또는 UoD 를 반영.
② A logically coherent collection of data with some inherent meaning.
③ A specific purpose를 위해 설계, 구현됨.
▪ DBMS
: A collection of programs that enables users to create and maintain a DB.
(Defining, constructing, manipulating, sharing)
▪ Database system
: DBMS + Application Program + Stored DB + Stored DB Definition(Meta-Data)

1.2 An Example
▪ DB manipulation : querying & updating

1.3 Characteristics of the Database Approach
: 각 application마다 각각 따로 file을 만들어 관리해야 했던 file processing에 비해, 하나의 data repository만 유지하는 DB system approach가 훨씬 효율적이다.
① Self-Describing Nature of a Database System
DB system = DB 그 자체 + DB 구조와 제약에 대한 complete 정의나 설명.
catalog : meta-data (각 파일의 구조, 데이터 형, 제약 조건 등의 DB 정의)가 저장되어있다.
특정 DB에 있는 파일 구조를 알려면 catalog만 참조하면 되므로, DBMS software는 general-purpose로 만들 수 있다.
② Insulation between programs and data, and data abstraction
program-data independence : DBMS catalog에 저장된 data file의 구조와 access programs는 별개이다. => 데이터 구조 변경 =/=> 프로그램 변경
program-operation independence : 사용자는 operation이 어떻게 구현되었나 몰라도 사용 가능.
data abstraction : 위의 두 개를 가능하게 하는 것. Conceptual representation만 제공. (data model)
=> 사용자에게는 conceptual representation만 제공하고, DBMS가 필요하면 자세한 사항은 catalog에서 꺼내어 보고 file access.
③ Support of multiple views of the data
④ Sharing of data and multiuser transaction processing

1.4 Actors on the Scene
① Database Administrators
② Database Designers : 데이터 정의 및 저장 구조 설계
③ End Users
casual end user : DB 사용 빈도수 적지만 다양하고 복잡한 정보를 원함
naïve, parametric user : 정형화된 질의/갱신 작업 반복 (canned transactions)
sophisticated end user : 데이터의 복잡한 작업 수행
stand-alone user : 개인 데이터 베이스 사용자
④ System Analysts and Application Programmers (Software Engineers)

1.5 Workers behind the Scene
① DBMS system designers and implementers
② Tool developers
③ Operators and maintenance personnel

1.6 Advantages of Using the DBMS Approach
① Controlling Redundancy
▪ File processing : 모든 사용자 그룹은 각자 파일을 보관하고 있어서 같은 정보라도 여러 파일에 중복하여 보관됨.
=> redundancy 문제 발생. (duplication of effort, 저장공간 낭비, inconsistent)
▪ DB approach : redundancy 해결. (때로는 controlled redundancy 필요.)
② Restricting Unauthorized Access : security 보장.
③ Providing Persistent Storage for Program Objects
④ Providing Storage Structures for Efficient Query Processing
⑤ Providing Backup and Recovery : H/W, S/W 고장시에도 DBMS가 데이터 유지
⑥ Providing Multiple User Interfaces : 다양한 사용자 유형 및 숙련도 지원
⑦ Representing Complex Relationships among Data
⑧ Enforcing Integrity Constraints : semantics of DB (무결성 보장)
⑨ Permitting Inferencing and Actions Using Rules
⑩ Additional Implications of Using the Approach
▪ Potential for Enforcing Standards
▪ Reduced Application Development Time
▪ Flexibility
▪ Availability of Up-to-Date Information : concurrency control
▪ Economies of Scale : 중복투자, 데이터 관리 인력 감소

1.7 A Brief History of Database Applications

1.8 When Not to Use a DBMS
simple, well defined, not expected to change, real-time, no multiple user access

Chap 2. Database System Concepts and Architecture
2.1 Data Models, Schemas, and Instances
▪ data model : a collection of concepts that can be used to describe the structure of a database
▪ Categories of Data Models
① High-level (or conceptual) data model
DB 사용자가 이해하는 데이터베이스의 구조
entity, attribute, relationship으로 miniworld 표현
② Low-level (or physical) data model
데이터가 어떻게 컴퓨터에 저장되는지를 자세하게 설명하는 개념 제공
③ Representational (or implementation) data model
DBMS에서 사용하는 모델로, 위 두 데이터 모델의 중간 모델.
▪ Database Schemas (meta-data)
DB 설명. 대부분의 데이터 모델은 schema diagram을 가지고 있음.
▪ Instances : 저장된 데이터
▪ Database State : 특정 시점에서의 instances의 집합.

2.2 Three-Schema Architecture and Data Independence
2.2.1 The Three-Schema Architecture
▪ Internal schema : DB의 물리적 저장 구조 기술 ( physical data model 이용)
▪ Conceptual schema: DB구조 기술 ( conceptual, implementation data model이용)
▪ External schema : 사용자의 필요에 따라 DB 일부분 기술

2.2.2 Data Independence
① Logical data independence : external schemas나 응용 프로그램을 바꾸지 않고 conceptual schema 변경 가능.
② Physical data independence : conceptual schemas 바꾸지 않고 internal schema 변경 가능.

2.3 Database Languages and Interfaces
▪ Schema 정의 언어 : DDL(data), SDL(storage), VDL(view)
▪ 검색, 삽입, 삭제, 갱신 언어 : DML(data manipulation), SQL(structured query)
high-level DML : 내가 원하는 것을 표현한다.
low-level DML : 어떻게 가져올 지에 대해서도 표현한다.
▪ Host language : C, COBOL등 응용 프로그램이 사용하는 언어.
▪ DBMS Interfaces
: User-friendly, natural language, for parametric users, for DBA.

2.4 The Database System Environment
2.4.1 DBMS Component Modules
▪ Stored data manager : 디스크에 저장된 DBMS 정보에 대한 접근 제어
▪ DDL compiler : schema definition 처리, catalog에 저장.
▪ Runtime database processor : runtime에 DB에 접근하는 것을 다룸.
▪ Query compiler : interactive하게 들어오는 high-level query들을 다룸.
▪ Pre-compiler : host programming language로 적힌 응용 프로그램에서 DML 명령들을 뽑아낸다.

2.4.2 Database System Utilities
: loading, backup, file reorganization, performance monitoring
2.4.3 Tools, Application Environments, and Communications Facilities

2.5 Centralized and Client/Server Architectures for DBMSS

2.6 Classification of Database Management Systems
▪ Data model -> relational, network, hierarchical, object-oriented 등.
▪ Number of users -> single-user, multi-user systems
▪ Number of sites -> centralized, distributed DBMS
▪ 목적 -> general, special-purpose DBMS

[요구사항]
때는 바야흐로 22세기. 21세기에 유행하던 얼짱 신드롬이 사회 전반적으로 확산되고, 짱이 연예인의 유일한 등용문이 되면서, 이를 효과적으로 대처하기 위해 "짱 키우기 신개념 프로젝트"를 추진하기에 이르렀다. 당시 연예인 협회 회장이 된 데이터베이스 롸목 반장은, "짱 키우기 신개념 프로젝트"를 위해 얼짱 이회에 각종 짱들을 육성하고 이들을 관리하기 위하여 데이터베이스 시스템을 구축하기로 하였다. 각종 사이트를 통하여 다수의 추천을 받은 짱들은 주민등록번호와 이름을 기본적으로 등록하고, 각자의 재능에 따라 얼짱, 몸매짱, 노래짱이 될 수 있으며, 워낙 능력이 뛰어나 재능을 크게 인정 받은 짱들은 몇몇 분야(얼굴 또는 몸매 또는 노래)를 아우르는 짱이 될 수도 있다. 짱으로 인정을 받으면, 얼짱인 경우 코높이와 눈크기, 얼굴 비율을 등록해야 하고, 몸매짱인 경우는 키와 몸무게를, 노래짱인 경우는 성량과 음역대를 등록해야 한다.
모든 짱들은 자신을 좋아하는 팬들로 구성된 팬클럽을 여러 개 가질 숙 있으며, 한 짱에 소속된 팬클럽들은 그 팬클럽 이름으로 구별이 가능하고, 팬클럽 관리 차원에서 매년 팬클럽이 결성된 날 팬 캠프를 하기 위하여 비상 연락처로 팬클럽의 회장 이름과 연락처를 관리한다.
짱들은 등록된 연예기획사와 오디션을 통해서만 연예인으로 데뷔할 수 있으며, 오디션의 관리를 위하여 시행된 날짜와 응시 분야, 평가 점수를 기록하도록 한다. 한 명의 짱은 같은 날 같은 분야에 대해서 여러 연예기획사의 오디션을 볼 수도 있다. 오디션의 평가점수에 의해 등록된 연예기획사들로부터 지목된 짱들은 연예인으로써 하나의 등록된 연예기획사와 계약을 통해 연예인이 되는데, 이 때는 계약금과 계약 기간을 명시하도록 한다. 연예인이 되면, 코디와 매니저 및 연락처를 추가로 관리한다. 10명 이상의 연예인을 관리하는 연예기획사가 각 시/도별로 사업자 등록이 가능하며 등록 시에는 등록번호가 주어지고, 회사 주소와 대표이름을 관리하도록 한다.

1. 요구사항에서, entity, attribute, relationship을 분석해 보자.
짱 : 주민등록 번호, 이름
얼짱 : 코높이, 눈크기, 얼굴 비율
몸짱 : 키, 몸무게
노래짱 : 성량, 음역대
팬클럽 : 팬클럽 이름, (회장의 이름, 회장의 연락처)
연예기획사
등록 (연예인 10명 이상): 등록번호, 회사 주소, 대표이름.
=> 각 시/도 별로 등록이 가능하고 등록할 때 마다 등록번호가 주어지므로, multivalued attribute.
미등록 : x
오디션 : 시행된 날짜, 응시 분야, 평가 점수
=> 오디션은 연예기획사에서 주최하므로, 연예기획사를 owner entity로 하는 weak entity가 되어야 한다.
연예인 : 코디, 매니저, 연락처
=> 짱이 등록된 연예기획사와의 계약으로 연예인이 되므로,
짱을 owner entity로 하고, 계약을 owner relationship으로 하는 weak entity가 된다.

2. 애매하여 가정이 필요한 부분이 있는가?
(1) 연예기획사에 대하여.
10명 이상의 연예인이 있어야 등록이 가능하고, 짱들은 등록된 연예기획사의 오디션만 볼 수 있고, 오디션에 합격하면 계약하여 연예인이 될 수 있다. 이 등록된 연예기획사는 짱이 연예인이 되기 위한 유일한 등용문이기 전부터 연예인을 관리하여 등록된 기획사이며, 새로 생기는 기획사는 기존의 연예인을 10명 이상 다른 연예기획사로부터 스카웃 해와야 한다.
연예기획사는 기본적으로 회사 이름을 가지며, 같은 이름의 연예기획사가 두 개 이상 있을 수 없다.
(2) 오디션
오디션은 등록된 연예기획사만 주최할 수 있으며, 미등록 기획사는 주최할 수 없다. 왜냐하면, 짱들은 등록된 연예기획사에서만 오디션을 볼 수 있기 때문이다.
(3) 짱과 팬클럽
팬클럽을 가지지 않는 짱이 있을 수도 있다.

3. relationship을 뽑아내보자.
4. 모두 생략하고 걍 그려봤다.

1. 연예기획사 등록된 연예기획사와 미등록된 연예기획사로 나누는데,
미등록 연예기획사는 다른 기획사에 있는 연예인을 10명 이상 스카우트 해야만 등록이 가능하고,
등록 되기 전에는 DB에서 다루지 않는다.
2. 등록시의 문제로, 연예 기획사는 모두 다른 이름을 가지며, 이름과 대표이사 이름으로 관리한다.
3. 연예기획사는 시/도 별로 등록을 한 지사를 한 개 이상 가지고 있다.
각 지사는 회사 주소와 등록 번호로 관리되는데, 등록 번호로 지사를 identify할 수 있다.
4. 팬클럽을 가지지 않는 짱이 있을 수도 있다. 팬클럽은 한 짱에게 속하여 이름으로 구분된다.
5. 짱이더라도 오디션을 보지 않을 수도 있고, 등록된 연예기획사도 오디션을 주최하지 않을 수 있다.
6. 연예인은 오직 한 연예 기획사와만 계약을 할 수 있고, 짱은 꼭 얼짱, 몸짱, 노래짱 중에 하나 이상이다.
7. 오디션은 등록된 연예 기획사의 지사 아무 곳에서나 볼 수 있고,
그 기획사와의 계약은 모든 해당 회사의 모든 지사에서 유효하다.

<조교가 올려준 정답>