database(23)
-
[Index, 선택성] 데이터베이스가 데이터를 빠르게 검색하는 방법
🙌 인덱스가 없는 것과 인덱스가 있는 것 FTS(Full Table Scan) : 인덱스 없이 모든 테이블을 샅샅이 조회하는 것으로, 그냥 많은 정보를 찾을 때 유리함 Index Scan : 인덱스를 사용하여 범위를 좁혀가는 것으로, 최종 몇 개의 정보를 찾을 때 유리함 🙌 DB에서 실제 데이터를 저장하는 단위를 "page(8kb)"라고 한다. 🙌 Index 구축에는 두가지 방법이 있다. 👍 Clustered Index 각 page의 첫번째 데이터를 인덱스로 하여 Index Root에 모아 놓은 뒤, 정보가 필요하면 해당 page로 바로 이동하여 탐색 어떤 속성이 Clustered Index로 지정되면, 그 속성 기준으로 데이터와 page가 실제로 새로 정렬되어 저장됨(주로 기본키). Index Root..
2020.06.17 -
[View 설계 & Index 구축] 반정규화를 하기 전 고려해야 할 선택지
👊View 설계 - 복잡한 테이블 구조의 단순화 View는 데이터베이스 사용자가 어떤 데이터를 검색했을 때 보여지는 결과화면이다. 예를 들어 네이버는 엄청 많고 복잡한 데이터를 가지고 있지만, 유저가 입력한 검색어나 클릭에 맞는 결과만 나오도록 그 구조를 단순화하여 사용자 관점에서 보여주는 것이 바로 View인 것이다.(또는 Microsoft Access에서의 쿼리라고 생각하면 된다) 👊Index 구축 - 빠른 검색을 위해 목차 만들기 Index는 데이터베이스에서 원하는 데이터를 좀 더 빨리 찾아줄 수 있도록 데이터의 위치정보를 모아놓은 개체다. 책에서의 목차라고 보면 되고, 존재목적 상 항상 정렬된 상태를 유지해야 하며 자주 수정되어서는 안된다. 2020/06/17 - [컴퓨터언어/Database] -..
2020.06.17 -
[반정규화] 논리적 설계에서의 정규화가 오히려 독일 때
현실 속의 추상적 개념을 이해하기 쉽게 도식화한 것이 ER 다이어그램이고, ER 다이어그램의 환상에 효율성을 끼얹은 것이 정규화였다. 2020/06/16 - [컴퓨터언어/Database] - [정규화] 효율적인 데이터베이스 스키마 구축 그런데 간혹 정규화가 오히려 성능을 방해하는 경우가 있다. 정규화란 결국 테이블을 여러 개로 쪼개는 것인데, 실제 데이터베이스를 구현해서 사용할 때 조인 연산이 엄청 무겁다면 무결성을 얻는 대신 성능은 바닥을 기고 통장텅장은 텅텅 비게 될 것이다. 그래서 이런 현상에 미리 대비하고자, 논리적 설계 이후의 물리적 설계 단계에서는 DB에 대한 쿼리 빈도와 그에 따른 트랜잭션(연산)을 예측하고 분석하여, 정규화가 오히려 독이 될 경우에는 반정규화를 하도록 제시한다. 👍 상관모델..
2020.06.17 -
[정규화] 효율적인 데이터베이스 스키마 구축 2
2020/06/16 - [컴퓨터언어/Database] - [정규화] 효율적인 데이터베이스 스키마 구축 [정규화] 효율적인 데이터베이스 스키마 구축 "효율적"인 데이터베이스가 무엇일까? 개념적 설계를 통해 이라는 개체에 필요할 만한 속성을 이것저것 넣었다고 해보자. 학번, 이름, 주민번호, 성별, 주소, 학과, 동아리, 학점, ...... 너무 an-onymous.tistory.com 이전 글에서 정규화는 개념적 설계로 나온 ER 다이어그램을 보편적인 "관계형 테이블"로 대응시킴과 동시에, 효율적인 데이터베이스를 만들기 위한 "논리적 설계" 과정이라고 하였다. 만약 정규화 없이 단순히 개념적 설계만을 가지고 데이터베이스화 한다면 삽입/삭제/갱신 이상이 발생할 것이기 때문이다. 정규화의 목적을 다시 한번 정..
2020.06.17 -
[정규화] 효율적인 데이터베이스 스키마 구축
"효율적"인 데이터베이스가 무엇일까? 개념적 설계를 통해 이라는 개체에 필요할 만한 속성을 이것저것 넣었다고 해보자. 학번, 이름, 주민번호, 성별, 주소, 학과, 동아리, 학점, ...... 너무도 완벽한 것 같다. 마치 나의 릴레이션이라면 학생들의 모든 정보를 다 담고 있는 것 같아 행복하다. 이를 가지고 나 릴레이션과 관계를 가지면 엄청난 빅데이터가 탄생할 것만 같다. 그러나 이 많은 정보를 이라는 단 하나의 릴레이션에 다 담고 있으면, 나중에 부피가 커졌을 때 관계가 복잡해지고 유지보수에 상당한 비용을 지출하게 된다. 만약 정보를 잘못 저장한 곳이 있다면 탐색하고 수정하는 데에도 꽤 많은 비용을 들여야 할 것이다. 그리고 정보가 많은 만큼 데이터베이스의 주 적인 "중복"을 만날 수 있으며, 데이터..
2020.06.16 -
[Key] 키와 무결성 제약조건
Key는 주어진 릴레이션에서 모든 인스턴스 가운데 유일함(Unique)을 보장해주는 하나 이상의 애트리뷰트의 집합이다. Edgar Codd 데이터베이스에서 각 인스턴스를 식별할 때는 중복을 피해야 하는데, 이런 유일함을 보장해주는 것이 Key이다. 중요한 것은 이 Key가 꼭 단 하나의 속성만으로 이루어질 필요는 없다는 것이다.(Key != 속성) 물론 단 하나의 속성만으로 Key를 구성하는 것이 가장 바람직하겠지만, 데이터 저장상태 상 그럴 수 없는 상황에서는 여러 속성을 합쳐서 유일성을 확보할 수 있다면, 그렇게 Key를 구성할 수 있다는 것이다. 이렇게 하나 이상의 속성으로 구성된 Key를 "복합Key"라고 한다. 유일성 : 단 하나의 인스턴스(튜플)를 골라낼 수 있는가의 여부 최소성 : 유일성을 ..
2020.06.16