데이터베이스는 정보를 저장하고 관리하기 위한 소프트웨어 시스템
-> 일반적으로 제품 정보, 고객 정보, 주문 정보들을 저장 및 관리하기 위해 사용
-> 일반적으로 정보를 쉽게 검색할 수 있도록 설계되어 있으며, 정보의 정확성과 신뢰성을 보장하기 위해 정규화된 규칙을 적용
이러한 주소록 데이터를 PC로 관리하는 가장 간단한 방법은 콤마(.)를 사용한 텍스트 파일(csv 파일)이나 Excel과 같은 스프레드 시트에 보관하는 것
-> 이러한 방법들은 단순하지만 DB에 필요한 최소한의 기능만을 갖춤
검색을 통해 원하는 데이터를 찾아오는 것이 DB에 요구되는 가장 중요한 기능
ex) 주소에 서울이라는 단어가 포함된 인물 검색, 이벤트 메세지를 보내기 위해 특정 주소에 거주하는 사람 특정
DB는 새로운 데이터를 등록하고, 기존데이터를 수정하며, 불필요한 데이터를 제거하는 것(갱신) 또한 가능해야 함
DB를 조작할시에는 데이터를 어떤 포맷(형식)으로 다룰지
, 검색이나 갱신을 어떻게 효율적으로 할지
중요
검색이나 갱신에서 중요한 문제 : 성능
-> 어느 정도의 빠르기로 처리 가능한가?
-> 상용으로 사용하는 DB에는 몇백만 명이나 되는 사용자가 등록되어 있음
-> 이러한 데이터를 읽어 들이고, 검색 요건에 해당하는 데이터만을 추리는 작업은 최신 장비여도 시간이 오래 걸림(영원한 숙제)
개인이 관리하는 주소록이라면 이를 검색하거나 갱신 하는 것은 자기 자신 뿐
-> 비즈니스나 공공목적으로 이용되는 DB에는 불특정다수의 사용자가 동시에 접근하는 경우가 많음
즉 DB는 동시에 복수의 사용자로부터 검색이나 갱신 처리를 받음
-> 이때 무결성을 어느 정도로 보장하는지가 중요
ex)PC의 주소록 파일을 아버지 와 아들이 공유
아버지가 파일을 열어 박민수의 주소를 변경할때 아들도 동시에 파일을 열어 박민수의 주소를 갱신하려 함(아들이 잘못된 주소로 갱신하려 함)
이러한 경우를 해결하기 위해
1의 행위 제한이 가장 심하고 3이 가장 느슨
-> 1의 경우엔 아버지가 보고 있을 때 주소록에 아무것도 할 수 없지만, 3의 경우 아버지가 주소록을 갱신하고 있다는 것조차 의식하지 않고 주소록 갱신 가능
3이 아들 입장에선 자유도가 높아 바람직하지만, 아버지 입장에서 3은 위험하고 의도하지 않은 상황
-> 이 처럼 어느 사용자에게는 괜찮은 갱신제어가 다른 사용자에게는 불편한 상황을 트레이드오프 관계
라고 함
-> 이렇게 복수 사용자의 갱신을 조절하기 위한 기능 (동시성 제어 or 베타 제어)
3의 경우를 보통 dirty write
라 함
-> DB 무결성 관점에서 기피
좀처럼 부서지기 어렵고 부셔졌다 하더라도 복원할 수 있다라는 것
데이터 소실 예시
-> 어떠한 원인으로 소실되고 복원 또한 되지 않는 경우
-> 금융 기관의 거래 이력, 기업의 고객 정보 사라짐(매우 큰 사회적 문제)
이러한 데이터 소실 문제 대책
1. 데이터 다중화
: 데이터를 한곳이 아니라 복수의 장소에 분산해서 유지하는 것으로, 데이터가 완전하게 소실되는 것을 막는법
2. 백업
: 데이터가 소실되었을 때 데이터를 복원하는 방법으로 사후대책 느낌
데이터베이스에 보존된 데이터를 어떻게 숨길지
데이터베이스는 사용자로부터 가능한 보이지 않게 설계되고 있음
-> 웹 브라우저는 클라이언트에서 동작, DB는 서버에서 동작
데이터베이스에 들어 있는 데이터는 기밀성이 지극히 높아서 공개할 수 없는 내용이 상당수 포함
-> 결제 시 계좌번호, 신용카드 번호, 비밀번호
-> 이러한 정보가 보존된 장소가 DB
개발자 입장에서는 되도록 사용자가 데이터베이스에 접근할 수 없도록 이용제한을 걸고 싶음
-> 하지만 보안의 강도와 편리함+간편함과의 트레이드오프 관계에 있어서 그 균형을 잡는 것이 설계에서 매우 어려움
데이터를 게층 구조로 관리(트리형태, ex : 회사 조직도)
ex) 회사 보고 체계
2차원 표 형식으로 데이터를 관리하는 데이터베이스(주류)
행과 열로 이루어진 각각의 테이블의 고유값(Primary Key)을 참조
하여 서로 종속되는 관계(=연결하는것)를 표현하는 데이터 베이스 구조를 관계형 데이터베이스
각각 객체와 XML 형식으로 데이터를 관리하는 데이터 베이스
관계형 데이텁이스를 대체하길 기대했지만, 아직 활용성 낮음
Not noly SQL -> SQL(관계형 데이터베이스를 만들기 위한 언어)
NoSQL 기반의 DB들은 관계형 DB에 있는 기능 일부를 버려서 성능을 높임
-> 대량의 데이터를 고속으로 처리해야 하는 웹 서비스와 잘 맞음