데이터베이스

데이터베이스(Database)는 여러 사람들이 공유하고 사용할 목적으로 통합 관리되며 중복을 최소화한 정보의 집합이다.

1 파일 시스템과의 차이점[편집]

파일시스템이나 데이터베이스나, 자료를 영구적으로 저장하기 위해 존재한다는 점에서 그 목적은 같다. 그러나 데이터베이스가 갖는 파일시스템과의 가장 큰 차이점은 다음과 같다.

  1. 데이터 의존성
    파일의 구조와 접근 방법을 변경할 경우 응용 프로그램은 또한 같이 수정되어야 한다. 그러나 데이터베이스는 응용시스템에 대해서 독립성을 갖는다.
  2. 데이터 무결성
    데이터베이스는 데이터의 정확성, 일관성, 유효성, 신뢰성을 위해서 무효한 갱신에 의해 데이터가 변조되는 것을 방지한다.

2 종류[편집]

2.1 관계 지향적 데이터베이스(RDBMS)[편집]

1970년 IBM 연구소의 테드 코드(Ted Codd)가 처음으로 제시한 개념으로, 현재 상용 데이터베이스의 거의 대부분을 차지하는 방식이다. 관계지향적 모델에서 데이터베이스는 개체(Entity)와 그 개체간의 관계(Relation)를 나타내는 테이블의 모임으로 정의된다. 이 테이블을 구성하는 요소는 행(Tuple, Record), 열(Attribute, Field)이다. 관계지향적 모델의 이론적 토대는 집합론논리학에 있으므로 관계지향적 데이터베이스에 대한 심도있는 이해를 위해서는 이 분야의 수학에 대한 공부가 반드시 선행되어야 한다.

이론적으로 관계지향적 데이터베이스에 대한 질의는 관계 대수관계 해석으로 표현될 수 있다. 이 두 표현 방식의 표현 가능 범위는 동일하다. 그러나 관계 대수의 경우, '질의를 통해 가져오고자 하는 정보를 어떻게 가져올 것인가'에 초점을 맞추고 있고 관계 해석의 경우 '질의를 통해 가져오고자 하는 것이 무엇인가'에 초점을 두고 있다. 그러나 이 두 방식은 모두 고도로 수학적이고 추상적인 방법으로, 실제 응용 컴퓨터 과학에 적용하기에는 많은 무리가 따랐다. 연구자들은 직관적으로 이해하고 사용할 수 있는 질의 형식을 개발할 필요성을 느꼈고, 마침내 1974년 IBM 연구소는 자신들이 제시한 관계지향적 데이터베이스에 사용될 질의 형식을 발표하는데 그것이 SQL(원래 약어는 SEQUEL로, Structured English QUEry Language의 약자였으나 이후 SQL로 굳어지게 되었다)이다. 어찌된 일인지 당시 IBM은 다른 원천기술에 대해서는 모두 특허를 걸어놓았으나 SQL에 대해서는 별다른 권리를 주장하지 않았는데, 덕분에 모든 RDBMS는 이 SQL의 기본적인 틀을 공짜로 사용할 수 있다. 오라클Java에 대한 권리를 주장하여 마이크로소프트 측에서 결국 C 샵이라는 언어를 새로 개발하게 된 것을 생각해보면, IBM은 떼돈을 벌 수 있는 좋은 기회를 놓친 대신 RDBMS 발전에 큰 기여를 한 셈이다.

2.2 객체 지향적 데이터베이스(ODBMS)[편집]

객체지향의 개념을 DBMS에도 적용한 것으로 현실세계의 대상을 자연스럽게 객체와 1:1로 매핑시킬 수 있고, OOP의 장점인 유연성의 측면에서 호평받을 것이라고 예상하였으나... 이미 RDBMS에 익숙해져있던 많은 DBA들의 반발을 불러왔다. 여태까지 편리하게 사용할 수 있었던 테이블 기반의 DB 설계가 무용지물이 될 뿐 아니라, 편리하고 직관적이었던 SQL 역시 포기해야 했기 때문이다. ODBMS 회사들은 사용자들의 요구를 받아들이며 자사 제품을 개선하려 노력하였으나, 기존의 시장 점유율이 높은 Oracle을 비롯한 여러 RDBMS 회사들에서 객체 개념을 RDBMS에 추가로 얹은 ORDBMS 를 차기작으로 제시하면서 많은 ODBMS 회사들은 그 자체로는 별다른 반향을 일으키지 못하고 시대의 뒤편으로 사라지게 되었다. OODB의 성장과 몰락에 관한 이야기

2.3 NoSQL[편집]

NoSQL은 Not only SQL 의 약자로, 이는 SQL을 배제한다는 의미가 아니라 SQL 외의 다른 방식으로도 질의가 수행 가능함을 의미한다.

2.3.1 컬럼[편집]

이 문단은 비어 있습니다. 내용을 추가해 주세요.

2.3.2 도큐먼트[편집]

이 문단은 비어 있습니다. 내용을 추가해 주세요.

2.3.3 키값[편집]

이 문단은 비어 있습니다. 내용을 추가해 주세요.

2.3.4 그래프[편집]

이 문단은 비어 있습니다. 내용을 추가해 주세요.

3 특징[편집]

이 문단에서는 가장 보편적으로 널리 쓰이는 DBMS인 관계지향적 데이터베이스 모델을 중심으로 서술하도록 한다.

3.1 설계 순서[편집]

관계 지향적 데이터베이스의 설계 순서는 일반적으로 다음과 같다.

  1. 요구사항 도출: 문자 그대로 설계를 위한 요구사항을 명세서로 도출하는 과정
  2. 개념적 설계: 데이터베이스의 구조를 Entity와 Relationship으로 정의하고 개념 스키마를 정의하는 과정
  3. 논리적 설계: 테이블 구조, 속성, 타입 및 트랜잭션에 대한 설계
  4. 물리적 설계: DBMS의 종류나 방식을 고려하여 성능을 최적화하는 방향으로 구현하도록 설계하는 과정

일반적으로 데이터베이스의 설계에서 가장 흔하게 다루어지는 것은 개념적/논리적 설계이다. 물리적 설계 단계의 경우 최적화 단계에서 고려된다.

3.1.1 ER Model[편집]

데이터베이스를 구성하는 요소를 E(Entity)와 R(Relationship)으로 정의한 모델이다. 각각의 엔티티와 관계가 하나의 논리적 테이블로 대응될 수 있다.

3.1.1.1 엔티티[편집]

현실 세계에서 다른 모든 것들과 구분되는 유형, 무형의 것을 의미한다. 객체 지향 프로그래밍의 객체에 비교할 수 있는 개념이라고 할 수 있다.

3.1.1.2 관계[편집]

엔티티 사이의 참조, 종속과 같은 관계를 의미한다. 관계는 그 과정에서 기존의 엔티티에는 존재하지 않았던 새로운 속성을 가지는 것이 가능하다.

3.1.1.3 ER 다이어그램[편집]

이 문단은 비어 있습니다. 내용을 추가해 주세요.

3.2 무결성[편집]

이 문단은 비어 있습니다. 내용을 추가해 주세요.

3.3 정규화[편집]

이 문단은 비어 있습니다. 내용을 추가해 주세요.

3.4 SQL[편집]

SQL은 RDBMS에서 질의를 수행할 때 사용하는 언어이다.

3.5 트랜잭션[편집]

이 문단은 비어 있습니다. 내용을 추가해 주세요.

3.6 PL/SQL[편집]

이 문단은 비어 있습니다. 내용을 추가해 주세요.

3.7 DB 최적화[편집]

이 문단은 비어 있습니다. 내용을 추가해 주세요.

3.8 각주