우리학교의 데이터베이스 수업은 크게 2가지로 나뉘는데 ... 비밀인데 ...
정연돈 교수님의 데이터베이스와 정순영 교수님의 데이터베이스가 있다.
우리는 두 수업을 연두부와 순두부라고 부른다 ...
나는 지난 학기 알고리즘 강의를 통해 정순영 교수님의 팬이 되었으므로, '순두부'를 듣기로 결정했다 ... 수강신청 1순위로 잡았다 ㅠㅠ
맨날 프론트엔드 한다면서 데이터에 대해 1도 몰랐던 나를 반성하며 ... 이번 학기는 정말 열심히 들어야지
*** 지금부터 정리하는 내용은 모두 Avil Silberschatz, Henry F.Kroth, S.Sudarshan의 "Database System Concepts 7th edition"이라는 교재와, 고려대학교 정순영 교수님의 2023년 1학기 "데이터베이스" 강의를 기반으로 하고 있다. 모든 강의자료 캡쳐본은 정순영 교수님께서 권한을 갖고 있다. ***
1) 전체적인 구조에 대하여
ㅠㅠ
Applications:
데이터베이스를 이용하는 프로그램
DBMS:
Databse와 App 사이에 존재하는 것으로, 효과적으로 사용할 수 있도록 지원하는 시스템 소프트웨어
(시나공 정처리기능사 교재에 따르면,
DBMS란 사용자와 데이터베이스 사이에서 / 사용자의 요구에 따라 / 정보를 생성해주고 / 데이터베이스를 관리해주는 소프트웨어라고 한다 )
➡️ 추가적으로, DBMS는 기존의 파일 시스템이 갖는 데이터 종속성과 중복성의 문제를 해결하기 위해 제안된 시스템으로 / 모든 응용 프로그램들이 데이터베이스를 공용할 수 있도록 관리해준다 (교수님께서 뒤의 예시에서 이해가 쏙쏙 되게 설명해주셨다)
2) Database란?
[ 정의 ]
어떤 조직이 활용하는 application시스템 (ex.고려대 포털)이 있을 때 / 그러한 시스템에서 사용되는 /
{persistent / interrelated / integrated}한 데이터의 집합
Database is a collection of persistent, interrelated, and integrated data that is used by the application systems of some given enterprise(ex.bank)
🔎 Application Systems 예시
- 새로운 학생 / 교수 / 강의를 추가하는 것
- 학생들을 특정 강의에 등록시키는 것
- 학생들에게 성적을 부여하고 / 평균학점을 계산하고 / 성적증명서를 생성해내는 것
- ...
✅ Persistent?
사실 DBMS가 알아서 해주는 부분.
Ex) 우리가 기본적인 프로그래밍 과제를 할 때 입력을 받고 특정 절차를 거쳐서 적절한 값을 출력하는 것을 만들었을 때,
프로그램이 다 종료된 이후 입력값과 출력값을 언제든 볼 수 있을까?
No! 어딘가에 저장하지 않았기 때문 = 이는 persistent하지 않으므로 이러한 값들을 우리는 Database라고 부르지 않는다.
✅ interrelated?
서로 연결되어 있다는 특성으로 이해했다 ..
Ex) '데이터베이스'라는 강의를 통해서
(정순영 교수님 - 문지후 학생), (정순영 교수님 - 김나영 학생) 등의 관계가 만들어지는 것
✅ integrated?
데이터를 통합해서 관리할 수 있다는 특성으로 이해했다
Ex) '나(문지후)'에 대해서 정보대학(단과대학)이 요구하는 정보와 / 학생처에서 요구하는 정보와 / 교무처 학사팀에서 요구하는 정보는 각각 다를 것이다. 이 세 곳에 모두 '나의 집주소'가 들어가 있다고 할 때, 만약 내가 이사를 가서 주소가 변경된다면?
➡️ 각각의 부서에 접근하여 따로 업데이트하면, 또다른 곳에서는 제대로 주소가 변경되지 않을 수 있다 (=일관성이 떨어짐)
➡️ 이러한 문제를 방지하기 위해서 데이터는 '통합된' 상태로 관리되어야 한다고 설명해주셨다
3) Using file systems to store data (예전엔 파일 시스템을 썼는데 ... 뭐가 문제였냐면 ...)
[ 가정하는 상황 ]
위와 같은 상황이 있다고 해보자. 예를 들어, 어떤 직원의 '주소'가 바뀐다면 인사부에서는 제대로 반영되었는데, 총무부나 후생복지부에서는 제대로 업데이트가 안될 수도 있다.
데이터를 저장할 때 file system의 결점을 다음과 같이 정리할 수 있다.
✅ 데이터의 redundancy & inconsistency
데이터가 중복될 수 있다는 것인데, 이러한 문제때문에 database design을 잘 고려해야 한다
(DBMS가 자동으로 해주는 것이 아니므로)
✅ Difficuty in accessing data
데이터에 접근하기 어렵다는 것인데, 다음의 예시를 생각해볼 수 있다.
Ex) 파일 시스템을 이용한 어플리케이션을 만들어서, 학생 전체보기를 화면에 띄워준다고 했을 때
➡️ 제주도 출신의 학생들만 보고싶다면? / 컴퓨터학과 학생들만 보고싶다면?
자동으로 특정 조건에 맞는 데이터에만 접근하기가 어려울 것 - 하나하나 찾아야할 수 있다
(이는 DBMS를 활용할 경우 간편하게 해결됨)
✅ Data isolation
데이터를 연결해서 갖고 오기 어렵고, 각각 고립되어 있다는 의미다. 다음 예시를 살펴보자.
Ex) 위의 사진 속에서, 인사부/총무부/후생복지부에서 사용하는 데이터포맷이 다 달랐다. 만약에 내가 특정 직원의 '이름 - 부서 - 호봉 - 서클'이라는 새로운 조합으로 조회하고 싶다면?
➡️ 파일 시스템에서는 매우 어려울 것이다 (데이터를 원하는 대로 도출하는 것이 어렵다는 의미다)
✅ Integrity problems - 책 보충 p6
데이터베이스에 저장되는 데이터들은 일관적인 제약조건을 만족해야한다. 이러한 조건을 어디서든 일관성 있게 유지시키는 것이 어렵다는 의미다.
Ex) 여러 부서에서 '계좌'에 대한 정보를 저장하고 있다고 생각해보자. 꺼낼 수 있는 잔액은 0보다 낮으면 안된다. 그런데 이에 대한 제약 조건이 바뀐다면? 여러 파일 시스템에서 저장하고 있을 때, 업데이트된 조건을 통합적으로 적용하기가 어려울 것이다.
(The data values stored in the database must satisfy certain types of consistency constraints)
✅ Atomicity of updates
- 추후 다룸!
✅ Concurrent access by multiple users - 책 보충 p7
- 한꺼번에 접근하여, 작동 상태를 공유할 수 없을 때 inconsistent한 상태로 업데이트 될 수 있다는 의미다. 책에 좋은 예시가 있었다.
Ex) 8000원이 있는 어떤 계좌에 대해, 점원A가 2000원을 빼고 / 점원B가 3000원을 빼서 계산하는 작업을 하고 있다고 할 때,
절묘한 타이밍으로 동시에 접근하여 처리한다고 하면 - 정상적으로 8000 - 2000 - 3000 = 3000원이어야 할 계좌의 최신 상태가
마지막으로 작업한 8000-2000=6000원이나 8000-3000=5000원으로 덮어씌어질 수 있다.
✅ Secuirty problems
- 사용자마다 볼 수 있는 데이터가 제한되어야 하는데, 파일 시스템은 이러한 제약을 실현하기 어렵게 만든다.
Ex) 학교의 데이터베이스를 관리할 때, 재정을 담당하는 부서에서는 학생들의 등록금 등에만 접근하면 되는데, 학업과 관련된 데이터에 접근할 수 있는 secuirty문제가 발생할 수 있음
(Not every user of the database system should be able to access all the data ... But since application programs are added to the file-processing system in an ad hoc manner_임시방편, enforcing such security constraints is difficult)
✅ Data Dependence Problem
- 추후 다룸!
4) Data Dependece Problem (가장 중요한 데이터 의존성 문제 ⭐️)
[ 좋은 예시 ]
Program A에서는 10자 / 15자 / 8자를 구분하여 ➡️ 학번 / 학생명 / 학과로 저장하고 있다그런데, new Program B를 보면 10자 / 15자 / 8자 / 7자로 구분하여 ➡️ 학번 / 학생명 / 학과 / 주소로 저장하려고 하는데,
두 번째 ex.txt를 new Program을 활용하여 데이터를 가져오면, 데이터가 깨져서 보일 수 있다.
왜냐하면! 단순히 문자열을 개수만큼 가져오므로 학생명에 'Park, MinjiComp' 학과에 'uterSeo' 이런식으로 다음 속성의 값이 짤려서 들어올 수 있기 때문이다.
5) Solution (데이터 의존성을 해결하려면? ⭐️)
[ 좋은 예시 ]
위의 그림처럼, 데이터를 '통합'하여 관리하면 된다.
➡️ 데이터가 한 가지만 있다는 것이 아니라, 여러 부서에서 다양하게 활용되는 데이터들을 하나의 '집합'으로 묶었다는 의미이고, 이렇게 유사한 형태로 [교수데이터], [학생데이터] 등 통합된 데이터가 여러 개 존재할 수 있다.
위의 그림에서 만약 특정 사용자가 '인사부'에 와서 주소변경을 알리고 수정하면?
아래에 있는 통합된 데이터에 반영되므로, 해당 데이터(주소값)를 필요로 하는 모든 곳에서 업데이트된 상태의 데이터를 정상적으로 조회할 수 있다(=의존성 문제 발생X)
6) View of Data
[ Data abstraction의 3가지 레벨 ]
1️⃣ Physcial level
: describes how data are actually stored
(데이터가 실제 물리적으로 저장된 레벨)
2️⃣ Logical level
: describes what data stored in database, and what relationships among the data
(DBMS가 바라보며 관리하는 레벨)
3️⃣ View level
: describes only part of the entire database
: can also hide information (such as an employee's salary) for security purposes
(각 부서에서 데이터를 '활용하는 쪽'이 바라보는 레벨)
7) Instances and Schemas
[ Schema란? ]
: the logical structure of the database (프로그래밍 언어에서 '자료형'과 유사)
physical schema = ?이해못했 .. 아래에 책 보충
logical schema = DBMS관점에서 사용되는 것으로, 앞으로의 강의는 주로 이 스키마를 다룰 것임
Database systems have several schemas, partitioned according to the levels of abstraction.
The physical schema describes the database design at the physical level,
while the logical schema describes the database design at the logical level.
[ Instance란? ]
: the actual content of the database at a particular point in time (프로그래밍 언어에서 '변수'와 유사)
[ 스키마와 인스턴스 관계? ]
: 위의 그림과 같은 관계로 이해하면 된다. 스키마와 인스턴스 정보는 주로 '따로 구분되어' 저장되어 있으며
스키마는 인스턴스가 생성되는 바탕이 되는 '틀'같은 것으로 이해하기.
[ 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
📚Data abstraction에 대한 책 내용.. p9📚
Logical Level:
it describes what data are stored in the database, and what relationships exist among those data.
The logical level thus describes the entire database in terms of a small number of relatively simple structures.
Although implementation of the simple structures at the logical level may involve complex physical-level structures, the user of the logical level does not need to be aware of this complexity. This is referred to as physical data independence. Database administrators, who must decide what information to keep in the database, use the logical level of abstraction.
➡️ 데이터 추상화 단계 중, user들은 logical level에서는 실존하는 여러 물리적인 복잡한 데이터 구조를 몰라도 상관없다는 의미인 것 같다. 그렇다면 '논리적 스키마를 바꾸지 않고, 물리적 스키마를 수정할 수 있는 능력?'이라는 건 어떤 말일까. 여전히 강의자료에 있는 표현은 이해가 안된다 ㅠㅠ

망했다 ...
- using file systems to store data부분에서 몇 개 요소들 의미를 제대로 모른다 ✅
- 데이터 의존성 program 2개 나온 예시를 제대로 설명한 건지 모르겠다
- physical schema 정확한 의미 모르겠고 ✅
- physical data independence 의미 모르겠다 ✅ = 알아냈다! 논리적 단계의 사용자는 복잡한 물리적 단계의 구조를 알 필요가 없음을 의미한다.
얼른 교재를 찾아야겠구낭
'CS전공강의 > 데이터베이스' 카테고리의 다른 글
데이터베이스 Chapter2: Intro to Relational Model (3회차) (0) | 2023.04.11 |
---|---|
데이터베이스 Chapter15: Query Processing (N회차) (0) | 2023.04.06 |
데이터베이스 Chapter1: Introduction (2회차) (0) | 2023.04.05 |