데이터베이스 관계

안녕하세요, 똑똑한개발자에서 백엔드 개발을 하고 있는 권창식입니다. 벌써 3번째 데이터베이스 이야기입니다. 오늘은 데이터베이스 관계의 개념에 대해 소개해드리고 자 합니다. 관계의 정의 관계는 개체와 개체 사이의 논리적인 연결을 의미합니다. 관계에는 개체 간의 관계와 속성 간의 관계가 있습니다. 관계의 형태 1:1(One To One) : 개체 집합 A의 각 원소가 개체 집합 B의 원소 한 개와 대응하는 관계입니다. 1:N(One To Many) : 개체 집합 A의 각 원소는 개체 집합 B의 원소 여러 개와 대응하고 있지만, 개체 집합 B의 각 원소는 개체 집합 A의 원소 한 개와 대응하는 관계입니다. N:M(Many To Many) : 개체 집합 A의 각 원소는 개체 집합 B의 원소 여러 개와 대응하고, 개체 집합 B의 각 원소도 개체 집합 A의 원소 여러 개와 대응하는 관계입니다. 관계의 종류 종속관계 : 두 개체 사이의 주, 종 관계를 표현한 것으로 식별 관계와 비식별 관계가 있습니다. 중복 관계 : 두 개체 사이에 2번 이상의 종속 관계가 발생하는 관계입니다. 재귀 관계 : 개체가 자기 자신과 관계를 갖는 것으로, 순환 관계라고도 합니다. 배타 관계 : 개체의 속성이나 구분자를 기준으로 개체의 특성을 분할하는 관계로, 배타 AND 관계와 OR 관계로 구분합니다. 배타 AND 관게는 하위 개체들 중 속성이나 구분자 조건에 따라 하나의 개체만을 선택할 수 있고, 배타 OR 관계는 하나 이상의 개체를 선택할 수 있습니다. 관계형 데이터베이스의 개요 1970년 IBM에 근무하던 코드(E. F. Codd)에 의해 처음 제안되었습니다. 관계형 데이터베이스를 구성하는 개체나 관계를 모두 Relation이라는 표(Table)로 포현합니다. Relation은 개체를 표현하는 개체 Relation, 관계를 나타내는 관계 Relation으로 구분할 수 있습니다. 장점 : 간결하고 보기 편리하며, 다른 데이터베이스로의 변환이 용이합니다. 단점 : 성능이 다소 떨어집니다. 관계형 데이터베이스의 Relation 구조 Relation은 데이터들을 표(Table)의 형태로 표현한 것으로 구조를 나타내는 Relation 스키마와 실제 값들인 Relation 인스턴스로 구성됩니다. 튜플(Tuple) 튜플은 Relation을 구성하는 각각의 행을 말합니다. 튜플은 속성의 모임으로 구성됩니다. 파일 구조에서 레코드와 같은 의미입니다. 튜플의 수를 카디널리티(Cardinality) 또는 기수, 대응수라고 합니다. 속성(Attribute) 속성은 데이터베이스를 구성하는 가장 작은 논리적 단위입니다. 파일 구조상의 데이터 항목 또는 데이터 필드에 해당됩니다. 속성은 개체의 특성을 기술합니다. 속성의 수를 디그리(Degree) 또는 차수라고 합니다. 도메인(Domain) 도메인은 하나의 속성이 취할 수 있는 같은 타입의 원자값들의 집합입니다. 도메인은 실제 속성 값이 나타날 때 그 값의 합법 여부를 시스템이 검사하는데에도 이용됩니다. Relation의 특징 한 Relation에는 똑같은 튜플이 포함될 수 없으므로 Relation에 포함된 튜플들은 모두 상이합니다. 한 Relation에 포함된 튜플 사이에는 순서가 없습니다. 튜플들의 삽입, 삭제 등의 작업으로 인해 Relation은 시간에 따라 변합니다. Relation 스키마를 구성하는 속성들 간의 순서는 중요하지 않습니다. 속성의 유일한 식별을 위해 속성의 명칭은 유일해야 하지만, 속성을 구성하는 값은 동일한 값이 있을 수 있습니다. Relation을 구성하는 튜플을 유일하게 식별하기 위해 속성들의 부분집합을 키(Key)로 설정합니다. 속성의 값은 논리적으로 더 이상 쪼갤수 없는 원자값만을 저장합니다. NoSQL 비관계형 타입의 데이터를 저장할때 주로 사용되는 데이터베이스 시스템입니다. 관계형 데이터베이스와 다르게 비관계형 이기 때문에 데이터들을 저장하기 전에 정의 할 필요가 없습니다. MongoDB, Redis, Cassandra 등이 가장 대표적인 NoSQL 데이터 베이스입니다. SQL(RDBMS) VS NoSQL SQL 장점 관계형 데이터베이스는 데이터를 더 효율적으로 그리고 체계적으로 저장할 수 있고 관리 할 수 있습니다. 미리 저장하는 데이터들의 구조(테이블 스키마)를 정의 함으로 데이터의 완전성이 보장됩니다. 트랜잭션(transaction) 단점 테이블을 미리 정의해야 함으로 테이블 구조 변화 등에 덜 유연합니다. 테이블 구조가 미리 정의 되어 있다보니 단순히 서버를 늘리는것 만으로 확장 하기가 쉽지 않고 서버의 성능 자체도 높여야 합니다. 정형화 된 데이터들 그리고 데이터의 완전성이 중요한 데이터들을 저장하는데 유리합니다. NoSQL 장점 데이터 구조를 미리 정의하지 않아도 됨으로 저장하는 데이터의 구조 변화에 유연합니다. 확장하기가 비교적 쉽습니다.. 그냥 서버 수를 늘리면 됩니다.(scale out) 확장 하기가 쉽고 데이터의 구조도 유연하다 보니 방대한 양의 데이터를 저장하는데 유리합니다. 단점 데이터의 완전성이 덜 보장됩니다. 트랜잭션이 안되거나 비교적 불안정합니다.