{"componentChunkName":"component---src-templates-blog-post-js","path":"/Database/2020-04-11-데이터베이스-키/","result":{"data":{"site":{"siteMetadata":{"title":"Hun's Footsteps 🥷","author":"전여훈","siteUrl":"https://jeonyeohun.netlify.app","comment":{"disqusShortName":"","utterances":"jeonyeohun/jeonyeohun.github.io"},"sponsor":{"buyMeACoffeeId":"jeonyeohun"}}},"markdownRemark":{"id":"e32c697c-8741-5db2-8601-2566c447b435","excerpt":"Revisit Keys  Key 의 종류와 개념이 헷갈려서 한번 다시 정리해보자. Super Key Super Key 는 테이블 내의 특정한 tuple을 식별할 수 있게하는 attribute 들의 집합을 의미한다. 집합이기 때문에 atrribute 는 하나만 있을 수도 있고, 다수 존재할 수도 있다. Super Key 는 항상 유일성(uniquness) 를 만족해야 하는데, 위에서 설명한 것 처럼 이 key를 통해서 유일한 tuple을 식별할 수 있음을 의미한다. student_id student…","html":"<h1 id=\"revisit-keys\" style=\"position:relative;\"><a href=\"#revisit-keys\" aria-label=\"revisit keys permalink\" class=\"anchor before\"><svg aria-hidden=\"true\" focusable=\"false\" height=\"16\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"><path fill-rule=\"evenodd\" d=\"M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z\"></path></svg></a>Revisit Keys</h1>\n<p><img src=\"..assets/post_images/keys.png\"></p>\n<p>Key 의 종류와 개념이 헷갈려서 한번 다시 정리해보자.</p>\n<h2 id=\"super-key\" style=\"position:relative;\"><a href=\"#super-key\" aria-label=\"super key permalink\" class=\"anchor before\"><svg aria-hidden=\"true\" focusable=\"false\" height=\"16\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"><path fill-rule=\"evenodd\" d=\"M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z\"></path></svg></a>Super Key</h2>\n<p>Super Key 는 테이블 내의 특정한 tuple을 식별할 수 있게하는 attribute 들의 집합을 의미한다. 집합이기 때문에 atrribute 는 하나만 있을 수도 있고, 다수 존재할 수도 있다.</p>\n<p>Super Key 는 항상 <strong>유일성(uniquness)</strong> 를 만족해야 하는데, 위에서 설명한 것 처럼 이 key를 통해서 유일한 tuple을 식별할 수 있음을 의미한다.</p>\n<table>\n<thead>\n<tr>\n<th>student_id</th>\n<th>student_name</th>\n<th>age</th>\n<th>sex</th>\n</tr>\n</thead>\n<tbody>\n</tbody>\n</table>\n<p>위와 같은 테이블의 attribute 가 있다고 할 때, student<em>id 하나만으로 어떤 tuple을 특정할 수 있다. 그렇다면 student</em>id를 포항하는 다른 집합들은 어떨까?</p>\n<ol>\n<li>student_id</li>\n<li>{ student<em>id, student</em>name }</li>\n<li>{ student<em>id, student</em>name, age }</li>\n<li>{ student<em>id, student</em>name, age, sex }</li>\n</ol>\n<p>위 attribute 들의 조합들은 모두 uniqueness 를 충족시키기 때문에, Super Key 가 될 수 있다.</p>\n<h2 id=\"candidate-key\" style=\"position:relative;\"><a href=\"#candidate-key\" aria-label=\"candidate key permalink\" class=\"anchor before\"><svg aria-hidden=\"true\" focusable=\"false\" height=\"16\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"><path fill-rule=\"evenodd\" d=\"M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z\"></path></svg></a>Candidate Key</h2>\n<p>그런데, Super Key 는 너무나 광범위해서 어쩌면 비효율적일 수도 있다. student_id 로만 어떤 tuple을 특정할 수 있다면, 다른 attribute 들을 확인하는 것은 의미가 없는 작업이기 때문이다.</p>\n<p>Candidate Key 는 테이블을 구성하는 attribute들의 집합 중, tuple 을 특정하게하는 key를 말하는데, Super Key 와 다른 점은 Candidate Key는 언제나 <strong>유일성(Uniqeuness)과 최소성(Minimality)</strong> 를 만족해야한다.</p>\n<table>\n<thead>\n<tr>\n<th>student_id</th>\n<th>student_name</th>\n<th>age</th>\n<th>sex</th>\n</tr>\n</thead>\n<tbody>\n</tbody>\n</table>\n<p>최소성은 tuple을 식별하기 위해서 집합내에 있는 attribute가 꼭 존재해야함을 의미한다. 따라서 위 테이블에서 Candidate Key가 될 수 있는 Super Key는 student_id 뿐이다.</p>\n<table>\n<thead>\n<tr>\n<th>user_id</th>\n<th>username</th>\n<th>email_address</th>\n<th>SSN</th>\n</tr>\n</thead>\n<tbody>\n</tbody>\n</table>\n<p>위와 같은 경우에서는 tuple을 특정할 수 있는 Super Key 중 최소성을 만족하는 집합은 user<em>id, email</em>address, SSN 총 세 개의 다른 집합이 존재하기 때문에, 한 테이블에 Candidate Key 가 3개가 될 수 있다.</p>\n<h2 id=\"primary-key\" style=\"position:relative;\"><a href=\"#primary-key\" aria-label=\"primary key permalink\" class=\"anchor before\"><svg aria-hidden=\"true\" focusable=\"false\" height=\"16\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"><path fill-rule=\"evenodd\" d=\"M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z\"></path></svg></a>Primary Key</h2>\n<p>Primary Key 는 Candidate Key 들 중에서 해당 테이블에서 tuple을 식별하는 기준으로 삼는 Candidate Key 하나를 의미한다. Primary Key 는 tuple을 식별하는 기준으로 사용되기 때문에, NULL 값을 절대로 허용하지 않는다. 왜냐하면, 만약에 여러 tuple의 Primary Key attribute 가 NULL을 가지고 있다면, tuple을 식별할 수 없게 되기 때문이다.</p>\n<h2 id=\"alternate-key\" style=\"position:relative;\"><a href=\"#alternate-key\" aria-label=\"alternate key permalink\" class=\"anchor before\"><svg aria-hidden=\"true\" focusable=\"false\" height=\"16\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"><path fill-rule=\"evenodd\" d=\"M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z\"></path></svg></a>Alternate Key</h2>\n<p>Alternate Key 는 만약 한 테이블에 Candidate Key 가 여러개 있을 때, Primary Key 로 선택되지 않고 남은 Candidate Key 들을 의미한다.</p>\n<h2 id=\"foreign-key\" style=\"position:relative;\"><a href=\"#foreign-key\" aria-label=\"foreign key permalink\" class=\"anchor before\"><svg aria-hidden=\"true\" focusable=\"false\" height=\"16\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"><path fill-rule=\"evenodd\" d=\"M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z\"></path></svg></a>Foreign Key</h2>\n<p>위 키들은 모두 단일한 테이블 안에서 사용되는 Key 들이었다. 그리고 Foreign Key는 특빌히 다른 테이블과 연계되어 관계를 맺는데 사용되는 Key이다. Foreign Key 는 다른 테이블에 존재하는 Primary Key를 참조하게 되는데, Primary Key 와 Foreign Key 의 이름은 달라도 되지만 Domain 은 동일하게 가져야 한다.</p>\n<p><img src=\"..assets/post_images/FK.png\"></p>\n<p>위 예시에서는 Student_id 를 Primary Key로 가진 테이블이 Professor 를 Pirmary Key로 가진 테이블을 Foreign Key 를 통해서 참조한다.</p>\n<p><img src=\"..assets/post_images/inrelationFK.png\"></p>\n<p>위와 같이 테이블 스스로의 Primary Key를 참조 할 수도 있다. 위의 경우에서는 어떤 교수의 지도교수를 나타내기 위해서 advisor<em>id 가 professor</em>id 를 참조하고 있다. 모든 지도교수는 한명의 교수이기 때문에 지도교수의 id 를 Foreign Key로 만드는 것은 타당해보인다.</p>\n<h2 id=\"integrity-constraint\" style=\"position:relative;\"><a href=\"#integrity-constraint\" aria-label=\"integrity constraint permalink\" class=\"anchor before\"><svg aria-hidden=\"true\" focusable=\"false\" height=\"16\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"><path fill-rule=\"evenodd\" d=\"M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z\"></path></svg></a>Integrity Constraint</h2>\n<p>무결성 제약조건이라고도 불리는 Integrity Constraint 는 데이터베이스가 꼭 가져야할 규칙이라고 볼 수 있다. 무결설 제약 조건은 크게 두가지로 나뉜다.</p>\n<h3 id=\"entity-integrity-constraint-primary-key-constraint\" style=\"position:relative;\"><a href=\"#entity-integrity-constraint-primary-key-constraint\" aria-label=\"entity integrity constraint primary key constraint permalink\" class=\"anchor before\"><svg aria-hidden=\"true\" focusable=\"false\" height=\"16\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"><path fill-rule=\"evenodd\" d=\"M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z\"></path></svg></a>Entity Integrity Constraint (Primary Key Constraint)</h3>\n<p>개체 무결성 제약조건이라고도 한다. 앞서 언급했던 것 처점 Primary Key 는 절대로 중복된 값을 가질 수 없고, 이 때문에 Primary Key가 null 값을 가지는 것을 허용하지 않는 다는 것이다.</p>\n<h3 id=\"referential-integrity-constraint-foreign-key-constraint\" style=\"position:relative;\"><a href=\"#referential-integrity-constraint-foreign-key-constraint\" aria-label=\"referential integrity constraint foreign key constraint permalink\" class=\"anchor before\"><svg aria-hidden=\"true\" focusable=\"false\" height=\"16\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"><path fill-rule=\"evenodd\" d=\"M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z\"></path></svg></a>Referential Integrity Constraint (Foreign Key Constraint)</h3>\n<p>참조 무결성 제약조건이라고도 한다. 테이블 간의 참조 관계에 대한 내용으로, 참조 관계에 있는 tuple들이 일관성있는 값을 가지게 하는 것이다. 이를 위해서, 참조 무결성 제약조건은 다음 두 조건 중 하나가 만족되어야 한다.</p>\n<ol>\n<li>Foreign Key 의 값은 참조되는 테이블의 특정 tuple의 Primary Key로 존재한다. 즉 Foreign Key 는 Primary Key로부터 참조가 가능한 값만 가져야 한다.</li>\n<li>1번의 조건이 성립되지 않아 참조할 값이 존재하지 않는다면, Foreign Key 는 NULL 값을 가진다.</li>\n</ol>","frontmatter":{"title":"[데이터베이스] 키(Key)","date":"April 11, 2020"}}},"pageContext":{"slug":"/Database/2020-04-11-데이터베이스-키/","previous":{"fields":{"slug":"/Database/2020-04-10-데이터베이스-정규화/"},"frontmatter":{"title":"[데이터베이스] 정규화(Normalization) - 1NF,2NF, 3NF, BCNF","category":"Database","draft":false}},"next":{"fields":{"slug":"/Database/2020-04-13-데이터베이스-조인연산/"},"frontmatter":{"title":"[데이터베이스] 조인연산(Join Operations in SQL)","category":"Database","draft":false}}}},"staticQueryHashes":["2486386679","3128451518"]}