2024년 데이터베이스 과목 중‘건국대학교 컴퓨터공학부’ 김욱희 교수님 수업을 바탕으로 정리된 내용입니다.
1차시
- DB
- 구조를 가진 데이터의 모음집
- 하드디스크 혹은 SSD에 보통 저장된 데이터의 집합
- Real Data → relations
- So we need to use, learn about DBMS
- Reason for using a DBMS rather than a file system
2차시
- 실제 데이터들은 데이터 간에 상관(연관)관계가 존재.
- 이거를 어떻게 정의할 거냐?
만약 파일 시스템으로만 기능하게끔 한다면..
- Data redundancy and inconsistency
- 하나의 정보를 복사했을 때, 만약 기존 정보를 수정한다면 복사된 데이터들을 관리하기 힘들어짐(일관성이 깨짐 → data inconsistency)
- Difficulty in accessing data
- Need to write a new program
- Data isolation
- Data can be scattered in the multiple files and the files may have different formats
- 파일들이 여러 곳에 분산되어 있다면 관리하기 힘들어짐.
- Integrity problems
- Example: Salaries should not be below zero.
- 우리가 성적가지고 db를 만들어야 한다고 하면, 성적은 마이너스일 수가 없음, 파일 시스템으로 다룬다면 일일이 코드를 짜야됨.(오류 방지)
- Atomicity problems
- 잘 된다, 안된다라고만 결정나야 하는데..
- A가 500$을 가지고, B가 100$를 가지고 있을 때, 200$을 A가 B에게 보낸다고 할 때, inconsistent 한 상태가 발생할 수 있음(즉, Atomicity를 보장하지 못함)
- Concurrent-access anomalies
- 동시에 balance가 왔을 때, file system은 concurrent-access한 상황 발생시 예상 결과와 다른 결과가 다를 수 있음.
- Security problems
- Not every user of db system should be able to access all the data
Data models
- Definition
- data model is a collection of conceptual tools for [Data, Data relationships, Data semantics, Consistency constraints]
- Why use models?
- can be useful when we want to examine or manage parts of the real world
- high cost → using models
- e.g : Airplane simulator, Nuclear power plant simulator, Map.. etc
- can be useful when we want to examine or manage parts of the real world
- Data model Types
- Relational Model (Enitity-Relationship data model)그 Entity들 간의 상관관계가 존재할 수도 아닐 수도 있고, 존재한다면 이를 표현할 수 있는 다이얼로그 표기법이 존재
- → Entity: 객체를 표현할 수 있는 녀석들
-
Object-based data models -
Semi-structured data model (XML)
- Data abstraction
- A major purpose of a database system is to provide users with an abstract view of the data
- 데이터 추상화 → 디테일한 부분은 굳이 유저에게 알려줄 필요가 없음
- Database system hides certain details of how the data is stroed and maintained
- 대부분 잘 모르는 사람들이 query문 가지고서 저장하기 위해 사용
- 안에서 일어나는 일들을 최대한 가릴 필요가 있음
- 하지만 안에서는 어떻게 더 효율적으로 빠르게 찾을 수 있는 지를… 다뤄야 함 → 복잡한 자료구조 등 여러가지 노력들이 존재
- A major purpose of a database system is to provide users with an abstract view of the data
[레벨 별 구분]
- Physical level
- How data is actually stored
- e.g: Index structures(B+-tree, Hash table, etc.), Slotted page
- 즉, 실제 데이터가 저장되어 있는데, 사람이 읽으라고 해놓은 형태가 아님. 하드웨어 친화적인 구조. 주로, 메모리, 하드디스크 구조에 맞게 최적화되어 있는 경우도 있고, 데이터를 좀 더 빠르게 찾기 위해 Index 자료구조에 맡게 되어 있는 경우도 있음.
- Logical level
- 사람이 읽을 수 있음. 누군가에게 특화되어 있는 레벨은 아님. 누구나 볼 수 있고, 이해할 수 있는 레벨
Type instructor = record
ID: char(5);
name: char (20);
dept_name : char(20);
salary: numeric(8,2);
end;- View level
- 유저마다 정해진 형태가 다름. 유저가 원하는 정보인데, 그 중에서도 유저한테 허락되어 있는 정보들만 보여주는 레벨.
- 같은 데이터베이스를 기반으로 하더라도 생긴 모양이 다 다르다.
- High details of logical level and provide a security mechanism
- Schema
- Similar to types and variables in programming languages → 데이터베이스를 표현하고 싶을 때(e.g: 클래스)
- Logical Schema - the overall logical structure of the database → 논리 플로우, 위의 instructor에서의 ID, … salary를 의미.
- Physical schema - the overall physical structure of the database → 실제 데이터베이스가 저장장치에 어떻게 저장되어있는 지를 표현한 것
- Instance - the actual content of the database at a particular time
- Analogous to the value of a variable
- 결국에 이런 데이터베이스가 있을 때 특정 시점의 실제 데이터를 의미
Physical data independence
- Physical Data Independence - the ability to modify the physical schema without changing the logical schema
- Applications depend on the logical schema
- In general, the interfaces between the various levels and components should be well defined so that changes in some parts do not seriously influence others.
- 사실 데이터베이스 시스템을 쓰는 어플, 유저는 내부적으로 이가 어떻게 동작하는 지 관심이 없음… 그저 쿼리를 날릴 뿐..
- 그렇기 때문에 physical schema를 몰라도 됨. 계층 간의 상호작용이 있을 때, 각각의 component들은 디자인이 잘 되어 있어서 영향을 받으면 안됨.
Introduction to Relational Model
- relation(==table)
- attribute(or columns)
- tuples(or rows)
- Attribute Types
- The set of allowed values for each attribute is called the domain (Di) of the attribute
- Attribute values are (normally) required to be atomic; that is, indivisible
- The specail value null is a member of every domain
- 각각 값을 가지고 있는데, 허용된 값들을 우리가 정의할 수 있음. 이를 Domain이라고 한다.
- 보통은 값을 절대 나눌 수 없어야 함 → Atomic 해야 한다.
- special value 중에 null value는 모든 attribute의 기본 값으로 설정할 수 있다.
- Relation Schema and Instance
- A1, A2, … , An are attributes
- R = (A1, A2, …, An) is a relation schema
- E.g : instructor = (ID, name, dept_name, salary)
- A relation instance ‘r’ defined over schema ‘R’ is denoted by ‘r(R)’
- schema R에서의 특정 시점의 인스턴스 r은 r(R)로 정의.
- The current values at relation are specified by a table
- An element t of relation r is called a tuple and is represented by a row in a table
- table의 한줄 = ‘t’
- Database
- A database consists of multiple relations
- Bad design: univ(instructor -ID, name, … , salary) results in
- repetition of information (e.g., two students have the same instructor)
- the need for null values (e.g., represent a student with no advisor)
- Keys
- Let K ⊂ R
- K is a superkey of R if values for K are sufficient to identify a unique tuple in relation R
- e.g.; {ID} and {ID, name} are both superkeys of instructor
- SuperKey K is a candidate key if K is minimal
- e.g.; {ID} is a candidate key for Instructor
- SuperKey 중 최소화된 것.
- One of the candidate keys is selected to be the primary key
- Foreign key constraint: Value in one relation must appear in another relation
참고
건국대학교 데이터베이스 강의자료(김욱희 교수님)
Slides from Authors of textbook (db-book.com)
• Silberschatz, Korth. Sudarshan, 2019
Slides from Professor Beomseok Nam (SKKU)
반응형
