오라클 객체란 무엇입니까?

Oracle 개체에는 1. 테이블, 3. 클러스터, 5. 동의어, 7. 트리거,

이 튜토리얼의 운영 환경: Windows 7 시스템, Oracle 11g 버전, Dell G3 컴퓨터.

오라클의 데이터베이스 객체란 무엇입니까?

데이터베이스의 기능은 다양한 데이터베이스 객체를 구성, 관리 및 저장하는 것입니다. 데이터베이스의 개체는 데이터 관리의 기초입니다. 이 문서에서는 이러한 Oracle 데이터베이스 개체를 보다 명확하게 이해할 수 있도록 데이터베이스 개체에 대한 몇 가지 기본 지식을 검토합니다.

1. 테이블:

데이터베이스를 운영할 때 대부분은 테이블 운영을 통해 이루어집니다. 테이블은 데이터베이스를 구성하고 데이터를 관리하기 위한 논리적 개념이자 기본 단위이다.

테이블은 관계형 테이블과 객체 테이블로 나눌 수 있습니다. 관계형 테이블에는 힙 테이블, 인덱스 구성 테이블, 외부 테이블이 포함됩니다. 우리가 일반적으로 사용하는 것은 힙 테이블입니다.

힙 테이블에 해당하는 세그먼트는 힙 구조의 형태로 저장되며, 저장된 데이터는 논리적으로 순서가 없습니다.

테이블과 세그먼트의 관계는 다음과 같습니다.

파티션되지 않은 테이블의 경우 하나의 테이블이 하나의 세그먼트에 해당합니다.

파티션된 테이블의 경우 하나의 파티션이 하나의 세그먼트에 해당합니다.

하위 파티션이 있는 테이블의 경우 하나의 하위 -파티션은 A 세그먼트에 해당합니다.

다른 데이터베이스 개체도 이와 유사합니다

1.1 테이블 파티션
테이블 파티션(파티션)은 사용자의 데이터 상황 및 비즈니스 요구에 따라 하나의 세그먼트에서 여러 세그먼트까지 테이블의 데이터를 저장하는 것입니다. . 사용자 데이터의 관리 및 유지 관리를 용이하게 하고 쿼리 작업 성능을 향상시킵니다. 물론 몇 가지 단점도 있습니다. 부적절하게 사용하면 일부 성능 문제가 발생할 수 있습니다. 파티션 테이블을 적용하려면 더 많은 경험과 더 포괄적인 고려 사항이 필요하며 이는 개발자에게 더 높은 요구 사항을 제시합니다.

파티션 적용 시기:

가장 먼저 고려해야 할 것은 데이터의 양입니다. 파티셔닝은 데이터의 양이 충분히 클 경우에만 필요합니다. 적은 양의 데이터를 전혀 파티셔닝할 필요가 없습니다. Oracle은 테이블이 차지하는 저장 공간이 2GB를 초과하는 경우 테이블 파티셔닝을 고려할 수 있다고 공식적으로 권장합니다. 일반적으로 분할을 피하는 것이 좋으며 분할에는 합당한 이유가 있어야 합니다.
현재 파티션되지 않은 테이블이 사용자의 데이터 관리 및 유지에 영향을 미쳤다면 파티셔닝을 고려할 수 있습니다.
파티셔닝 후 사용자의 쿼리 및 작업 성능이 향상될 수 있는지 여부.
분할 방법에 대해서는 다음 글에서 계속 분석하겠습니다.

2. 인덱스:

인덱스는 테이블 위에 구축된 논리적 개체입니다. 인덱스는 테이블 데이터 액세스 및 쿼리의 효율성을 향상시키고 성능 최적화에 큰 역할을 할 수 있습니다. 인덱스는 하나 이상의 세그먼트와도 연결되며 인덱스의 최종 저장 위치도 세그먼트입니다. 다양한 유형의 인덱스는 B-트리, 비트맵 등과 같은 다양한 저장 논리 구조를 갖습니다.

인덱스는 테이블의 선택 사항이며, 적절한 인덱스를 생성하는 것이 데이터베이스 최적화의 최우선 순위입니다. 그러나 인덱스는 쿼리 효율성을 향상시킬 수 있지만 DML 작업의 효율성을 감소시킬 수도 있습니다. 이 두 가지를 고려해야만 더 나은 성능을 얻을 수 있습니다.

인덱스 데이터베이스 최적화 솔루션은 대부분 인덱스 오류 방지, 인덱스 사용 순서 최적화 등을 위한 것입니다. B* 트리 인덱스, 비트맵 인덱스 등의 인덱스에 대해서는 후속 기사에서 자세히 설명합니다.

3. 클러스터:

클러스터는 하나 이상의 테이블의 데이터를 포함하는 데이터베이스 개체입니다. 이러한 열은 모두 클러스터 목록이라고 합니다.

클러스터를 생성하려면 해당 권한이 필요하며 개발에서는 거의 사용되지 않습니다. 클러스터는 인덱스 클러스터와 해시 클러스터로 나눌 수 있는데, 차이점은 데이터 검색 시 전자는 클러스터 키 열의 인덱스를 사용하고, 후자는 클러스터 키 열의 해시 값을 사용한다는 점입니다. 사용할 유형은 사용 시나리오에 따라 다릅니다.

4. 뷰(View) 및 구체화된 뷰(Materialized View):

View는 주로 비즈니스 로직을 단순화하고 개발 및 유지 관리를 용이하게 하는 데 사용되는 가상 정의 논리 개체입니다. 데이터는 뷰에 해당하는 다른 개체를 기반으로 합니다.

View는 추가, 삭제, 수정 및 확인과 같은 일부 작업을 제공할 수 있으며 동시에 어느 정도 보안이 유지되고 일부 열을 차단할 수 있으며 사용이 더 유연합니다. 하지만 성능에는 어느 정도 영향이 있을 것입니다.

구체화된 뷰는 뷰에 비해 실제로 데이터를 저장할 수 있고 테이블과 같은 관련 세그먼트에 대응할 수 있습니다.

구체화된 뷰는 요약, 계산 및 기타 작업에 사용될 수 있습니다. 동시에 특정 조건에서는 추가, 삭제, 수정, 검색도 가능하며 색인도 구축할 수 있습니다.

5. 동의어:

동의어 역시 가상 논리 객체이며 어떠한 데이터도 저장하지 않습니다. 기본적으로 이는 다른 데이터 개체의 별칭입니다. 동시에 보안 관리의 일환으로 동의어 권한을 다른 사용자에게 할당할 수 있습니다.

6. 시퀀스:

시퀀스는 어떠한 데이터도 저장하지 않으며, 사용자는 시퀀스를 통해 일련의 정렬된 값을 얻을 수 있습니다.

시퀀스를 정의할 때 시퀀스 이름, 오름차순 및 내림차순, 단계 크기 등을 정의할 수 있습니다. 로드 동시성이 높으면 시퀀스의 증가가 전체 성능에 영향을 미칩니다.

7. 프로시저 및 기능:

프로시저와 함수는 가상 논리 객체이며 데이터를 저장하지 않습니다. 주요 기능은 데이터베이스 인코딩 호출을 사용하여 일련의 작업을 수행하는 것입니다.

프로시저와 함수는 일련의 SQL 또는 기타 PL 문으로 구성된 데이터베이스의 개체입니다. 특정 문제를 해결하기 위해 작성된 단위입니다.

차이점은 함수에 반환값이 있다는 점인데, 이를 제외하고는 프로시저와 함수의 다른 부분은 동일합니다.

8. 트리거:

트리거는 데이터베이스의 논리적 개체이기도 하며 데이터를 저장하지 않습니다. 주로 데이터베이스 코딩을 통해 이벤트가 자동으로 트리거될 때 일련의 명령이 실행됩니다.

실행 프로세스는 이벤트가 관련 조건을 트리거하면 실행됩니다.

9. 제약 조건:

제약 조건은 데이터베이스의 논리적 개체입니다. 해당 기능은 특정 규칙이나 표준을 준수하도록 일부 내부 또는 자동 논리를 통해 데이터를 확인하고 제한하는 것입니다. 이를 통해 데이터의 정규화 및 표준화가 가능해집니다.

공통 제약 조건에는 다음이 포함됩니다

• 기본 키 제약 조건

• 고유 제약 조건

• null이 아닌 제약 조건

• 외부 키 제약 조건

• 사용자 지정 제약 조건(제약 조건 확인)

추천 튜토리얼: "오라클 튜토리얼"

위 내용은 오라클 객체란 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!