관계형 모델
Relational model관계형 모델(RM)은 1차 술어 로직과 일치하는 구조와 언어를 사용하여 데이터를 관리하는 접근방식으로 1969년 영국의 컴퓨터 과학자인 Edgar F에 의해 처음 기술되었습니다. Codd [1][2]- 모든 데이터가 튜플 단위로 표현되며, 관계별로 그룹화됩니다.릴레이셔널 모델의 관점에서 정리된 데이터베이스는 릴레이셔널 데이터베이스이다.
관계형 모델의 목적은 데이터와 쿼리를 지정하기 위한 선언적 방법을 제공하는 것입니다.사용자는 데이터베이스에 포함된 정보와 원하는 정보를 직접 기술하고 데이터베이스 관리 시스템소프트웨어가 데이터 저장용 데이터 구조 기술 및 응답용 검색 절차를 처리하도록 합니다.g 쿼리
대부분의 관계형 데이터베이스는 SQL 데이터 정의 및 쿼리 언어를 사용합니다.이러한 시스템은 관계형 모델에 대한 엔지니어링적 근사치로 간주할 수 있는 것을 구현합니다.SQL 데이터베이스 스키마의 테이블은 술어 변수에 대응합니다.테이블의 내용은 관계에 대응합니다.키 제약 조건, 기타 제약 조건 및 SQL 쿼리는 술어에 대응합니다.그러나 SQL 데이터베이스는 많은 세부사항에서 관계형 모델에서 벗어났고 Codd는 원래 원칙을 [3]훼손하는 편차에 대해 격렬하게 반대했습니다.
개요
관계형 모델의 중심 아이디어는 데이터베이스를 유한한 술어 변수 집합으로 기술하고 가능한 값과 값의 조합에 대한 제약을 기술하는 것입니다.데이터베이스의 내용은 데이터베이스의 유한(논리적인) 모델, 즉 술어 변수마다 하나씩 모든 술어가 충족되도록 일련의 관계입니다.데이터베이스로부터의 정보 요구(데이터베이스 쿼리)도 술어입니다.
대체 수단
다른 모델에는 계층 모델 및 네트워크 모델이 있습니다.이러한 오래된 아키텍처를 사용하는 일부 시스템은 데이터 볼륨 요구가 높은 데이터 센터 또는 기존 시스템이 복잡하고 추상적이어서 관계형 모델을 사용하는 시스템으로 이행하는 것이 비용 부담이 큰 데이터 센터에서 여전히 사용되고 있습니다.또한 주목할 만한 것은 새로운 객체 지향 데이터베이스입니다.
실행
Codd에 의해 원래 정의되고 Date, Darwen 및 기타에 의해 설명되는 관계형 데이터베이스 모델을 실제로 구현하기 위해 여러 번 시도했지만 지금까지 어떤 시도도 성공하지 못했습니다.2015년 10월[update] 현재 Rel은 이를 위한 최근 시도 중 하나입니다.
관계형 모델은 공식적인 수학적 용어로 기술된 최초의 데이터베이스 모델이었다.계층형 및 네트워크 데이터베이스는 관계형 데이터베이스 이전에 존재했지만, 그 사양은 비교적 비공식적이었다.후 관계 모델 정의되었다, 많은 시도와 대조의 다른 모델들을 비교하여, 이것은 이전 모델들의 더 엄격한 명세서의 출현으로 기여하지만 데이터를 조작 인터페이스 및 네트워크 계층적 데이터베이스에 대한 절차적 성격 형식화에 대한 범위 이내로 제한했다.[표창 필요한]
관계형 모달리티 프로토콜을 사용하는 구조 데이터베이스 분석에서는 새로운 입력의 통합으로 계층적 아키텍처 지정을 유지하기 위해 데이터 시퀀스 차분을 사용하는 경우가 많다.이러한 시스템은 클라우드 데이터베이스 [citation needed]인프라의 기반을 구성하는 대체 릴레이 알고리즘과 기능적으로 유사합니다.
역사
관계형 모델은 Edgar F에 의해 개발되었다. Codd는 일반적인 데이터 모델로, Chris Date와 Hugh Darwen에 의해 추진되었습니다.1995년 The Third Manifesto, Date 및 Darwen은 관계형 모델이 특정 "원하는" 객체 지향 기능을 어떻게 수용할 수 있는지를 증명하려고 합니다.
내선번호
1970년 모델을 발표한 지 몇 년 후, Codd는 누락된 정보에 대처하기 위해 3가지 값 논리(True, False, Missing/NULL) 버전을 제안했습니다.또한 The Relational Model for Database Management Version 2(1990)에서는 4가지 값 논리(True, False, Missing, Missing, 그러나 적용 가능하지는 않음)를 한 걸음 더 나아갔습니다.n.[4] 이들은 구현된 적이 없습니다.아마도 본질적으로 복잡하기 때문일 것입니다.SQL의 NULL 구조는 3개의 값을 가진 논리 시스템의 일부로 의도되었지만 표준 및 [5]구현에서의 논리적 오류로 인해 그에 미치지 못했습니다.
토픽
관계 모델 뒤에 있는 기본적인 가정은 모든 데이터가 수학적 n-ary 관계, 즉 n-ary 관계가 n 도메인의 데카르트 곱의 하위 집합으로 표현된다는 것이다.수학적 모델에서, 그러한 데이터에 대한 추론은 두 개의 값 술어 논리로 이루어지며, 이는 각 명제에 대해 참 또는 거짓의 두 가지 가능한 평가가 있음을 의미한다(그리고 특히 알 수 없거나 적용되지 않는 것과 같은 세 번째 값은 종종 NULL의 개념과 관련이 있다).데이터는 관계 미적분 또는 관계 대수에 의해 연산되며, 이들은 표현력에서 동등하다.
데이터의 관계형 모델을 통해 데이터베이스 설계자는 일관성 있고 논리적인 정보 표현을 작성할 수 있습니다.데이터베이스 설계에 선언된 제약조건을 포함시킴으로써 일관성이 확보됩니다.이 제약조건은 일반적으로 논리 스키마라고 불립니다.이 이론에는 데이터베이스 정규화 프로세스가 포함되어 있어 논리적으로 동등한 일련의 대안에서 특정 바람직한 특성을 가진 설계를 선택할 수 있습니다.액세스 계획 및 기타 구현 및 운영 세부 사항은 DBMS 엔진에 의해 처리되며 논리 모델에 반영되지 않습니다.이는 성능 튜닝이 논리 모델을 변경해야 하는 SQL DBMS의 일반적인 관행과 대조됩니다.
기본적인 관계형 빌딩 블록은 도메인 또는 데이터 유형이며, 오늘날에는 일반적으로 type으로 축약됩니다.태플은 어트리뷰트 값의 순서가 매겨져 있지 않은 세트입니다.속성은 속성 이름과 유형 이름의 순서가 매겨지지 않은 쌍입니다.Attribute 값은 Atribute 유형의 특정 유효한 값입니다.이는 스칼라 값 또는 더 복잡한 유형 중 하나입니다.
관계는 제목과 본문으로 구성됩니다.머리글은 속성 세트입니다.(n-ary 관계의) 본체는 n-tuples 집합입니다.관계 표제는 각 튜플의 표제이기도 합니다.
관계는 n개의 튜플 세트로 정의됩니다.수학 및 관계형 데이터베이스 모델에서 집합은 중복되지 않은 고유한 항목의 순서 없는 집합이지만 일부 DBMS는 데이터에 순서를 부여합니다.수학에서, 튜플은 순서가 있고 복사를 허용한다.E. F. Codd는 원래 이 수학적 [2]정의를 사용하여 튜플을 정의했습니다.나중에 E. F. Codd의 위대한 통찰력 중 하나는 순서를 정하는 대신 속성 이름을 사용하는 것이 관계를 기반으로[citation needed] 하는 컴퓨터 언어에서 더 편리할 것이라는 것이었습니다.이 통찰력은 오늘날에도 여전히 사용되고 있다.개념은 바뀌었지만 태플이라는 이름은 바뀌지 않았다.이 구별 특성의 즉각적이고 중요한 결과는 관계 모형에서 데카르트 곱이 가환적이 된다는 것이다.
테이블은 관계를 시각적으로 표현한 것으로, 태플은 행의 개념과 유사합니다.
relvar는 특정 관계 유형의 이름 있는 변수이며, 이 변수에는 항상 해당 유형의 관계가 할당됩니다. 단, 관계에는 0의 튜플이 포함될 수 있습니다.
관계 모델의 기본 원칙은 정보 원칙입니다. 모든 정보는 관계에서 데이터 값으로 표시됩니다.이 원칙에 따라 관계형 데이터베이스는 일련의 관계형 데이터베이스이며 모든 질의 결과는 관계형 데이터베이스로 제시됩니다.
관계형 데이터베이스의 일관성은 관계형 데이터베이스를 사용하는 응용 프로그램에 내장된 규칙이 아니라 논리 스키마의 일부로 선언되고 모든 응용 프로그램에 대해 DBMS에 의해 강제되는 제약에 의해 적용됩니다.일반적으로 제약조건은 관계 비교 연산자를 사용하여 표현되며, 그 중 하나의 "하위"(),)만 이론적으로 충분하다[citation needed].실제로는 몇 가지 유용한 단축키를 사용할 수 있을 것으로 예상되며, 그 중 가장 중요한 것은 후보 키(진짜, 슈퍼 키)와 외부 키 제약입니다.
해석
데이터의 관계 모델을 완전히 이해하려면 관계의 의도된 해석을 이해하는 것이 필수적이다.
관계의 본체를 확장이라고 부르기도 합니다.이는 술어의 각 자유 변수를 이름(무엇을 지정하는 용어)으로 대체함으로써 형성될 수 있는 진정한 명제의 집합인 일부 술어의 확장의 표현으로 해석되어야 하기 때문이다.
술어의 자유 변수와 관계 헤더의 속성 이름 사이에는 일대일 대응 관계가 있습니다.관계체의 각 태플은 각 자유변수를 치환함으로써 술어를 인스턴스화하는 속성값을 제공한다.그 결과는 관계기관에서 태플의 출현으로 인해 사실로 간주되는 명제이다.반대로, 표제가 관계의 표제와 일치하지만 본문에 나타나지 않는 모든 태플은 거짓으로 간주됩니다.이 가정은 폐쇄적 세계 가정으로 알려져 있다: 이것은 종종 실제 데이터베이스에서 위반된다. 여기서 태플이 없다는 것은 해당 명제의 진실이 알려지지 않았다는 것을 의미할 수 있다.예를 들어, 언어 능력 표에 태플('John', '스페인어')이 없다고 해서 반드시 John이 스페인어를 하지 않는다는 증거로 받아들일 수는 없다.
이러한 아이디어에 대한 공식적인 설명은 아래의 집합 이론 공식 섹션을 참조하십시오.
데이터베이스에 대한 응용 프로그램
일반적인 관계형 데이터베이스에서 사용되는 데이터 유형은 정수 집합, 문자열 집합, 날짜 집합 또는 true 및 false 두 개의 부울 값 등이 될 수 있습니다.이러한 유형에 대응하는 타입명은 문자열 "int", "char", "date", "boolean" 등이 될 수 있습니다.그러나 관계 이론이 지원되는 유형을 지시하는 것은 아니라는 것을 이해하는 것이 중요합니다. 사실, 오늘날에는 시스템에 의해 제공되는 내장형 외에 사용자 정의 유형에 대해서도 제공이 가능할 것으로 예상됩니다.
Attribute는 이론에서 일반적으로 컬럼이라고 불리는 것을 가리키는 용어입니다.마찬가지로 이론적인 용어 관계 대신 테이블이 일반적으로 사용됩니다(SQL에서는 이 용어가 관계와 동의어가 아닙니다).테이블 데이터 구조는 열 정의 목록으로 지정되며, 각 열 정의에는 고유한 열 이름과 해당 열에 허용되는 값의 유형이 지정됩니다.속성 값은 "John Doe" 또는 "35"와 같은 특정 열 및 행의 항목입니다.
태플은 기본적으로 행의 열 값이 정렬되는 SQL DBMS를 제외하고 행과 동일합니다(튜플은 순서가 매겨지지 않습니다.대신 각 속성 값은 속성 이름만으로 식별되며 태플 내의 순서 위치에 의해 식별되지 않습니다).속성 이름은 "name" 또는 "age"일 수 있습니다.
관계는 테이블 구조 정의(열 정의 세트)와 해당 구조에 나타나는 데이터입니다.구조 정의는 제목이며, 여기에 나타나는 데이터는 본문, 행 집합입니다.데이터베이스 relvar(관계 변수)는 일반적으로 기본 테이블로 알려져 있습니다.임의의 시점에서 할당된 값의 제목은 테이블 선언에서 지정되어 있으며, 그 본문은 일부 업데이트 연산자(일반적으로 INSERT, UPDATE 또는 DELETE)를 호출하여 가장 최근에 할당된 값입니다.일부 쿼리의 평가 결과 테이블의 제목과 본문은 해당 쿼리의 식에서 사용되는 연산자의 정의에 따라 결정됩니다(SQL에서 머리글은 항상 위에서 설명한 열 정의 집합은 아닙니다. 왜냐하면 컬럼에 이름이 없고 두 개 이상의 컬럼이 t를 가질 수 있기 때문입니다.그는 이름이 같다.또한 SQL에서는 동일한 행이 동일한 본문에 여러 번 표시될 수 있기 때문에 본문이 항상 행 집합인 것은 아닙니다.)
SQL 및 관계형 모델
SQL은 처음에는 관계형 데이터베이스의 표준언어로 사용되었지만 여러 부분에서 관계형 모델에서 벗어납니다.현재 ISO SQL 표준에서는 관계형 모델을 언급하거나 관계형 용어 또는 개념을 사용하지 않습니다.그러나 특정 SQL 기능을 사용하지 않는 경우 SQL을 사용하여 관계형 모델에 적합한 데이터베이스를 생성할 수 있습니다.
SQL에서는 관계형 모델에서 다음과 같은 차이가[by whom?] 발견되었습니다.SQL 표준 전체를 구현하는 데이터베이스 서버는 거의 없으며 특히 이러한 편차를 허용하지 않습니다.예를 들어 NULL은 어디에나 있는 반면 테이블이나 익명 열 내에서 중복된 열 이름을 허용하는 것은 드문 일입니다.
- 행의 중복
- SQL 테이블에 동일한 행이 여러 번 표시될 수 있습니다.같은 태플은 관계에 두 번 이상 표시될 수 없습니다.
- 익명 열
- SQL 테이블의 열에 이름을 지정할 수 있으므로 식에서 참조할 수 없습니다.관계형 모델에서는 모든 속성에 이름을 붙이고 참조할 수 있어야 합니다.
- 중복된 열 이름
- 동일한 SQL 테이블의 두 개 이상의 열이 동일한 이름을 가질 수 있으므로 명백한 모호성 때문에 참조할 수 없습니다.관계형 모델에서는 모든 속성을 참조할 수 있어야 합니다.
- 열 순서 유의성
- SQL 테이블의 열 순서가 정의되고 중요하며, 그 결과 SQL의 데카르트 곱 구현과 결합 구현이 모두 가환적이지 않습니다.관계 모형은 관계의 속성 순서에 유의성이 없어야 합니다.
- CHECK OPTION이 없는 보기
- CHECK OPTION을 사용하지 않고 정의된 보기에 대한 업데이트를 수락할 수 있지만 결과적으로 데이터베이스에 대한 업데이트가 대상에 대해 표현된 영향을 미칠 필요는 없습니다.예를 들어 INSERT 호출은 허용되지만 삽입된 행이 보기에 모두 표시되지 않거나 UPDATE 호출로 인해 행이 보기에서 사라질 수 있습니다.관계형 모델에서는 뷰가 기본 relvar인 경우와 동일한 효과를 얻으려면 뷰에 대한 업데이트가 필요합니다.
- 열 없는 테이블을 인식할 수 없습니다.
- SQL에서는 모든 테이블이 적어도1개의 컬럼을 가져야 하지만 2개의 degree 0(가진수 1과 0)의 관계가 있어 빈 변수를 포함하지 않는 술어의 확장자를 나타내는 데 필요합니다.
- 특수한 순서
- 이 특수 마크는 SQL에서 값이 표시될 수 있는 모든 위치, 특히 일부 행의 열 값 대신 표시될 수 있습니다.관계형 모델로부터의 편차는 SQL에서의 이 애드혹 개념의 구현에 3개의 값 로직이 포함되어 있기 때문에 발생합니다.이 논리에서는 NULL과 NULL의 비교는 true가 아니라 알 수 없는 제3의 true 값이 됩니다.또한 NULL과 다른 것을 비교해도 true가 되지 않습니다.d false이지만 알 수 없는 결과가 됩니다.NULL이 값이 아닌 마크로 기술되는 것은 이 동작 때문입니다.관계모델은 사실이 아닌 것은 모두 거짓이고 거짓이 아닌 것은 모두 참이라는 제외 중간 법칙에 의존합니다.또한 관계체 내의 모든 태플이 그 관계의 모든 속성에 대해 값을 가질 필요가 있습니다.이 특별한 편차는 E.F. Codd 자신이 결국 특별한 마크와 4개의 값 논리의 사용을 지지했기 때문에 일부에 의해 논란이 되고 있지만, 이것은 값 대신 특별한 마크를 사용하고 싶어하는 두 가지 뚜렷한 이유가 있다는 그의 관찰에 기초하고 있었고, 이는 이러한 로직의 사용에 반대하여 더 많은 d를 발견하도록 이끌었다.적어도 19개의 명확한 이유와 21개의 값 [citation needed]논리를 필요로 하는 것이 지적되었다.SQL 자체는 "값 알 수 없음"을 나타내는 것 이외의 목적으로 NULL을 사용합니다.예를 들어 빈 세트의 합계는 0을 의미하는 NULL이고 빈 세트의 평균은 정의되지 않은 NULL이며 LEFT JOIN의 결과로 나타나는 NULL은 "오른쪽 피연산자에 일치하는 행이 없기 때문에 값이 없음"을 의미할 수 있습니다.일반적으로 높은 수준의 데이터베이스 정규화를 고려하거나 유사한 NULL의 필요성을 피하기 위해 테이블을 설계하는 방법이 있지만 많은 경우 이러한 방법은 실용적이지 않습니다.그것은 뜨거운 논쟁이 될 수 있다.
릴레이셔널 오퍼레이션
사용자(또는 프로그램)는 특수 언어(일반적으로 SQL 방언)로 작성된 쿼리를 관계형 데이터베이스에 전송하여 데이터를 요청합니다.SQL은 원래 최종 사용자를 위한 것이었지만 SQL 쿼리가 보다 쉬운 사용자 인터페이스를 제공하는 소프트웨어에 삽입되는 경우가 훨씬 많습니다.Wikipedia와 같은 많은 웹 사이트는 페이지를 생성할 때 SQL 쿼리를 수행합니다.
쿼리에 응답하여 데이터베이스는 응답을 포함하는 행 목록인 결과 집합을 반환합니다.가장 간단한 쿼리는 테이블에서 모든 행을 반환하는 것이지만 원하는 답변만 반환하도록 행을 필터링하는 경우가 많습니다.
대부분의 경우 조인(join)을 통해 여러 테이블의 데이터가 하나로 결합됩니다.개념적으로 이것은 행의 가능한 모든 조합(데카르트 곱)을 취하여 답을 제외한 모든 것을 걸러냄으로써 이루어집니다.실제로 관계형 데이터베이스 관리 시스템은 다양한 기술을 사용하여 쿼리를 재작성(최적화)하여 보다 빠르게 수행합니다.
가입 이외에도 많은 관계형 연산이 있습니다.여기에는 프로젝트(열 일부를 제거하는 프로세스), 제한(행 일부를 제거하는 프로세스), 결합(동일한 구조를 가진 두 테이블을 결합하는 방법), 차이(한 테이블에서 찾을 수 없는 행을 나열함), 교차(두 테이블에서 모두 찾을 수 있음), 제품(상기)이 포함됩니다.한 테이블의 각 행과 다른 테이블의 각 행을 결합하는 oeb).그 외의 소스에 따라서는, 그 외의 연산자가 다수 존재합니다.이 연산자의 대부분은 상기의 관점에서 정의할 수 있습니다.여기에는 세미 조인, 외부 결합 및 외부 결합과 같은 외부 연산자 및 다양한 형태의 분할이 포함됩니다.다음으로 열의 이름을 변경하는 연산자와 요약 연산자 또는 집계 연산자가 있습니다.관계 값을 속성(상대값 속성)으로 허용하면 그룹 및 그룹 해제 연산자와 같은 연산자가 있습니다.SQL의 SELECT 문은 group 연산자와 ungroup 연산자를 제외한 모든 항목을 처리합니다.
관계형 데이터베이스의 유연성을 통해 프로그래머는 데이터베이스 설계자가 예상하지 못한 쿼리를 작성할 수 있습니다.그 결과, 관계형 데이터베이스는 원래 설계자가 예측하지 못한 방식으로 여러 애플리케이션에 의해 사용될 수 있으며, 이는 장기간(아마 수십 년) 사용될 수 있는 데이터베이스에 특히 중요하다.이로 인해 관계형 데이터베이스의 아이디어와 구현이 기업들에게 매우 인기를 끌고 있습니다.
데이터베이스 정규화
관계는 취약한 변칙의 유형에 따라 분류됩니다.첫 번째 정규 형식의 데이터베이스는 모든 유형의 이상 징후에 취약하지만 도메인/키 정규 형식의 데이터베이스에는 수정 이상이 없습니다.일반 형식은 본질적으로 계층적입니다.즉, 가장 낮은 수준이 첫 번째 정규 형식이며, 데이터베이스는 낮은 정규 [6]형식의 모든 요건을 먼저 충족시키지 않으면 상위 수준의 정규 형식 요건을 충족할 수 없습니다.
예
데이터베이스
일부 관계 변수(관계 변수)와 그 속성의 이상적인 매우 간단한 예:
- 고객(고객 ID, 세금 ID, 이름, 주소, 시/도, 우편, 전화, 이메일, 성별)
- 주문(주문 번호, 고객 ID, 청구서 번호, 발행일, 약속일, 조건, 상태)
- 주문 라인(주문 번호, 주문 라인 번호, 제품 코드, Qty)
- 청구서(송장 번호, 고객 ID, 주문 번호, 날짜, 상태)
- 청구서 라인(송장 번호, 청구서 라인 번호, 제품 코드, QTY 발송)
- 제품(제품 코드, 제품 설명)
이 설계에는 6개의 릴바가 있습니다.고객, 주문, 주문 라인, 청구서, 청구서 라인 및 제품.굵은 글씨로 밑줄이 그어진 속성은 후보 키입니다.굵은 글씨로 밑줄 친 속성은 외부 키입니다.
보통 후보 키는 프라이머리 키라고 불리도록 선택되며 다른 후보 키보다 우선하여 사용됩니다.이 키들은 대체 키라고 불립니다.
후보 키는 태플이 복제되지 않도록 강제하는 고유 식별자입니다.이 경우 세트의 기본 정의를 위반하여 관계가 다른 것, 즉 가방으로 바뀝니다.외부 키와 슈퍼 키(후보 키 포함)는 모두 복합적으로 구성할 수 있습니다.즉, 여러 개의 속성으로 구성할 수 있습니다.다음은 고객님의 relvar의 관계를 표 형식으로 나타낸 것입니다.관계는 relvar에 기인하는 값으로 생각할 수 있습니다.
고객 관계
고객 아이디 | 세금 아이디 | 이름. | 주소. | [더 많은 필드...] |
---|---|---|---|---|
1234567890 | 555-5512222 | 라메시 | 서던 애비뉴 323번지 | … |
2223344556 | 555-5523232 | 아담 | 메인 스트리트 1200 | … |
3334445563 | 555-5533323 | 슈웨타 | 라니잔시도 871번지 | … |
4232342432 | 555-5325523 | 사르파라즈 | 123 마울라나 아자드 사라니 | … |
ID가 1234567890인 신규 고객을 삽입하려고 하면 고객 ID가 프라이머리 키이고 고객 ID가 이미 1234567890이기 때문에 relvar 설계에 위배됩니다.DBMS는 무결성 제약 조건 위반으로 인해 데이터베이스가 일관되지 않게 되는 이와 같은 트랜잭션을 거부해야 합니다.
외부 키는 속성 세트의 값이 다른 관계의 후보 키에서 추출되도록 강제하는 무결성 제약 조건입니다.예를 들어 Order 관계에서 Customer ID 속성은 외부 키입니다.조인이란 한 번에 여러 관계에서 정보를 가져오는 작업입니다.위의 예에서 제공하는 릴레이에 참여함으로써 모든 고객, 주문 및 송장에 대한 데이터베이스를 조회할 수 있습니다.특정 고객에 대해서만 튜플을 원하는 경우 제한 조건을 사용하여 이를 지정합니다.
고객 1234567890의 모든 주문을 가져오려면 데이터베이스에 문의하여 고객 ID 1234567890의 Order 테이블 내의 모든 행을 반환하고 Order 테이블을 Order No.에 따라 Order Line 테이블에 참여시킬 수 있습니다.
위의 데이터베이스 설계에 결함이 있습니다.Invoice relvar에는 Order No 속성이 포함되어 있습니다.따라서 Invoice relvar의 각 튜플에는 주문번호가 1개씩 할당됩니다.이는 각 청구서에 정확히 1개의 주문이 있음을 의미합니다.그러나 실제로는 많은 주문에 대해 청구서를 작성할 수 있으며, 특정 주문에 대해서도 청구서를 작성할 수 없습니다.또한 Order relvar에는 Invoice No 속성이 포함되어 있으며, 이는 각 주문에 대응하는 Invoice가 있음을 의미합니다.그러나 다시 말하지만 이것은 현실에서 항상 진실인 것은 아니다.주문은 여러 개의 송장을 통해 결제되는 경우도 있고, 송장 없이 결제되는 경우도 있습니다.즉, 주문당 송장 수가 많고 청구서당 주문이 많을 수 있습니다.이는 주문과 송장 간의 다대다 관계(비특정 관계라고도 함)입니다.데이터베이스에 이 관계를 나타내려면 주문과 송장 간의 대응 관계를 지정하는 역할을 하는 새로운 relvar를 도입해야 합니다.
Order Invoice (Order No, Invoice No)
이제 Order relvar는 Invoice 테이블과 Invoice relvar와 마찬가지로1 대 다의 관계가 있습니다.특정 주문에 대한 모든 청구서를 가져오려면 모든 주문에 대해 문의할 수 있습니다.이 경우 Order 관계의 Order No는 Order Invoice의 Order No와 같고, Order Invoice의 Invoice No는 Invoice의 Invoice No와 같습니다.
집합 이론 공식
관계 모델의 기본 개념은 관계 이름과 속성 이름입니다."Person" 및 "name"과 같은 문자열로 나타내며 보통 r { r, 및 a,를 사용하여 범위를 지정합니다.또 다른 기본 개념은 숫자나 문자열과 같은 값을 포함하는 원자 값 집합입니다.
첫 번째 정의는 테이블 내의 행 또는 레코드의 개념을 공식화하는 태플의 개념에 관한 것입니다.
- 튜플
- 태플은 속성 이름에서 원자값까지의 부분 함수입니다.
- 헤더
- 헤더는 속성 이름의 유한 세트입니다.
- 투영
- 유한한 속성 A A에 대한 t}의 은t [ {( ,v) :( , ) 、 } \ { ( , v ) t 、 { ( a , v ) : ( a )\ { , )\ ,} }}입니다.
다음 정의는 관계형 모델에서 정의된 대로 표의 내용을 공식화하는 관계를 정의합니다.
- 관계.
- 관계는 헤더인 H H와본문인 B B의 튜플(H, B입니다 . 튜플은 모두 H(\ H를 가집니다.
이러한 관계는 보통 1차 논리에서는 술어의 확장이라고 불리는 것과 밀접하게 일치합니다.단, 여기서 속성명으로 술어의 위치를 식별합니다.일반적으로 관계 모델에서 데이터베이스 스키마는 일련의 관계 이름, 이러한 이름과 관련된 헤더 및 데이터베이스 스키마의 모든 인스턴스에 대해 유지해야 하는 제약 조건으로 구성됩니다.
- 관계 우주
- H H의 관계 세계 Udisplaystyle는 H({ H와의 관계 집합입니다.
- 관계 스키마
- 관계 스키마는 H(\ H와 헤더(\ H와의 모든 R(\ R에 대해 정의된 C C로 구성됩니다.관계는 스키마 C를 만족합니다.S H(\ H 및 C C를 충족합니다.
주요 제약사항 및 기능 의존관계
관계 제약의 가장 단순하고 중요한 유형 중 하나는 키 제약입니다.특정 관계 스키마의 모든 인스턴스에서 특정 속성의 값으로 튜플을 식별할 수 있음을 알 수 있습니다.
슈퍼키는 연결된 열의 값이 모든 행에서 고유한 열 머리글 집합입니다.형식:
- 슈퍼키는 속성 이름의 유한 집합으로 작성됩니다.
- K K는 다음과 같은 경우( B {{와 관련된다
- H ( \ K \ H)및
- 1 [ ] = [ t2 [ K ]({ K ]= } [ 와 같은 두 개의 구별되는 , 2B ( \ \ B)는 존재하지 않습니다.
- 슈퍼키가 모든 에서 U Udisplaystyle U\displaystyle U\로 유지되면 U Udisplaystyle U\로 유지된다.
- 정리:K( K가 U)에서 K(디스플레이 스타일 K)와 K K\오른쪽 H가 되는 에만 H H보다 U U가 관계 (relationation worldyle U)에 유지된다.
- 후보 키
후보 키는 다른 슈퍼키를 형성하기 위해 더 세분화할 수 없는 슈퍼키입니다.
함수 의존성은 튜플의 값이 해당 튜플의 다른 값에서 파생될 수 있는 속성입니다.
- 함수 종속성(FD 줄임말)은 X Y, Y 유한 속성 이름 집합에 X X로 표기됩니다.
- 기능적 X {\ X Y는 다음과 같은 경우 ( {\ (과와) 관계가 있습니다.
- (\ X H 및
- {\forall} t , 、 t 、 1 [ X = [ X、 [ Y = [ ] \ t { 1 [ X ] ={ 2 [ X X ] ] 、 [ X ] ] 、 t _ t _ t _ t _ t _ t _ t _ t _ t _ t _ t _ t _ t _ t _ 、 t _ right ]
- 기능적 X X Y는 UU의 모든 관계에서 유지되는 경우 세계 U 스타일 U에 있습니다.
- 사소한 기능 의존성
- H(\ H에 모든 관계에서 H H)에 대한 기능 의존성은 헤더 H(\displaystyle H에서 사소한 것입니다.
- 정리: X X Y는 Y(\ X\인 에만 HH라는 아래에서는 사소한 것입니다.
- 클로즈
- 암스트롱의 공리:S + 로 표기된 H {\displaystyle H 아래의 (\ S 세트의 닫힘은 다음과 같이S(\ S의 최소 슈퍼셋입니다.
- X H X S+ \ Y \ X \ H ~ \ \ Y \ S { + } (비활성)
- S +→ S + X S + (\ 화살표 S Y\right ZS^{+}~\right S
- + Z⇒ ( X) Z ) ( ) ) S + ( \ style X \ \ in S^ { + } \ Z \ ~ \ rightarrow ~ (X \Z ) \ )
- 정리:H(\H +(\X Y S의 하위 집합만 포함하는 (\ H와 FD S S\ S가 주어진 암스트롱의 공리는 정확하고 합니다.displaystyle S의 FD가 고정되는 HH.
- 완료
- X+ {\ X로 표기된의 유한 세트 아래에 있는 유한 X(\X의 완성은 다음과 X(\ X의 최소 슈퍼셋입니다.
- 속성 세트의 완료는 특정 종속성이 FD 세트의 폐쇄에 있는 경우 계산에 사용할 수 있습니다.
- 정리: X + \ X \ Y + { + } X+ \ Y + \ X { + 。
- 환원 불가능한 커버
- FD S S의 축소 불가능한 커버는 다음과 같은 FD T(\ T입니다 .
- S+ + \ S^ { + } = { + } = U^ { + } 의 UT { U T}
- TY \ X \ Y \ in T ~ \ Y}는 싱글톤 세트입니다.
- T Z X Z Y S + (\X\ Y T Z X Y S
기능 의존 관계에서 후보 키를 도출하는 알고리즘
함수 종속성에서 후보 키를 파생하는 알고리즘이 입력됨: 헤더 H 출력의 하위 집합만 포함하는 FD 집합: S의 모든 FD가 C : = // // 포함할 수 있는 후보 키 Q : = { H } // 를 찾은 H 위의 모든 관계 우주에서의 후보 키 집합 CDidate 키 Q가<>∅ QQ에서 K몇가지 요소:)Q–{K}최소:)각 X->에 대해서 사실 했을 까요?YS에 K':)(K– Y)∪ X//을 얻다. 새로운 superkey 만약 K'⊂ K그 최소한의:= 거짓 Q:)Q∪{K'}끝 끝나면을 위해 최소한의 이유가 있지 않은 부분 집합의 K에 나와 있는 C를 모든 supersets의 K.시작 C : = C ∪ { K }은(는) 다음과 같이 종료됩니다.
「 」를 참조해 주세요.
레퍼런스
- ^ 를 클릭합니다Codd, E.F (1969), Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks, Research Report, IBM.
- ^ a b Codd, E.F (1970). "A Relational Model of Data for Large Shared Data Banks". Communications of the ACM. Classics. 13 (6): 377–87. doi:10.1145/362384.362685. S2CID 207549016. Archived from the original on 2007-06-12.
- ^ 를 클릭합니다Codd, E. F (1990), The Relational Model for Database Management, Addison-Wesley, pp. 371–388, ISBN 978-0-201-14192-4.
- ^ Date, Christopher J. (2006). "18. Why Three- and Four-Valued Logic Don't Work". Date on Database: Writings 2000–2006. Apress. pp. 329–41. ISBN 978-1-59059-746-0.
- ^ Date, Christopher J. (2004). An Introduction to Database Systems (8 ed.). Addison Wesley. pp. 592–97. ISBN 978-0-321-19784-9.
- ^ David M. Kroenke, 데이터베이스 처리: Frentice-Hall, Inc., 130~144페이지, 기초, 설계 및 구현(1997년)
추가 정보
- Date, Christopher J.; Darwen, Hugh (2000). Foundation for future database systems: the third manifesto; a detailed study of the impact of type theory on the relational model of data, including a comprehensive model of type inheritance (2 ed.). Reading, MA: Addison-Wesley. ISBN 978-0-201-70928-5.
- ——— (2007). An Introduction to Database Systems (8 ed.). Boston: Pearson Education. ISBN 978-0-321-19784-9.
외부 링크

- Childs (1968), Feasibility of a set-theoretic data structure: a general structure based on a reconstituted definition of relation (research), Handle, hdl:2027.42/4164 1970년 Codd의 논문에 인용되었습니다.
- 를 클릭합니다Darwen, Hugh, The Third Manifesto (TTM).
- Curlie의 관계형 데이터베이스
- 를 클릭합니다"Relational Model", C2.
- 를 클릭합니다Binary relations and tuples compared with respect to the semantic web (World Wide Web log), Sun.