'DATABASE'에 해당되는 글 43건

  1. 2020.06.05 Define a “Subtype”
  2. 2020.01.23 Can a conceptual data model contain attributes?
  3. 2017.11.19 Oracle sequence구현하기
  4. 2016.02.13 Define a “Thing”
  5. 2014.04.21 Modifying Foreign Key Definitions
  6. 2014.01.09 Data pump로 import 하기
  7. 2013.07.12 [Oracle] 시간간격 구하기
  8. 2013.03.12 Understanding Primary Key(PK) Constraint in Oracle
  9. 2013.02.13 참조 Object조회하기
  10. 2011.12.01 열을 행으로

Define a “Subtype”

DATABASE/Articles 2020. 6. 5. 16:54

항상 그러하듯이 'Subtyping'에 대해 일단 정의부터 내려보자.

 

Subtyping은 엔터티가 독립성을 유지한 상태로 엔터티 內 공통속성을 그룹화화는 과정이다.

위 정의에는 데이터모델링에 대한(특히 엔터티에 대한) 많은 개념이 들어가 있다.

위 정의를 바탕으로 Subtype/Subtyping에 대해 살펴보자.

 

엔터티의 독립성1)을 유지한 상태로 엔터티 내 공통속성을 그룹화하는 과정이라고 했는데,

공통속성 그룹화를 하는 이유는(즉, Subtype을 도출하는 이유는) 아래와 같다.

- 커뮤니케이션을 향상 시킬 수 있다.

- 모델단에서 강제적으로 비즈니스 룰을 적용하여 향후 데이터 정합성을 향상 시킬 수 있다.

 

간혹, 엔터티 통합/분할의 관점에서 Subtype을 얘기하는 경우가 있는데

맞는 얘기이긴 하지만 이게 전부는 아닌데, 아래와 같이 정의하여 Subtype을 결과론적 '행위의 결과'로만 이해(오해)할 수 있게 하는것은 바람직하지 않다고 생각한다.

굳이 이 얘기를 하는 이유는 최근 국내에서 가장 많이 팔린 모델링 책 중 하나에서 아래와 같이 정의했기 때문이다.

엔터티를 통합하거나 분리하는 행위의 결과가 서브타입입니다.

 

3가지 관점에서 Subtype을 정리해 보면...

 

1. Subtype 장단점

- 장점: Subtype을 도출하는 이유와 같다.

  . 커뮤니케이션을 향상 시킬 수 있다.

  . 모델단에서 강제적으로 비즈니스 룰을 적용하여 향후 데이터 정합성을 향상 시킬 수 있다.

- 단점: 무분별하게 Subtype을 도출할 경우

  . 모델을 복잡하게 하고,

  . 그에 따라 이해도가 떨어지고, ex) "왜 Subtype을 도출했지?"라는 불필요한 생각에 따른 에너지 소비 등..

  . 물리 모델 전환 시, 쓸데없는 고민을 하게한다. ex) 하나의 엔터티에 3가지의 경우의 수가 발생한다.

 

2. Subtype 도출시점

위에서 얘기한 두 장점이 필요한 시점이라고 생각한다.(물론 장점은 더 있을 수 있다)

즉, 개념모델링 단계일 수 도 있고, 논리모델링 단계일 수 도 있다.(주로 논리모델링 단계에서 도출된다)

하지만, 물리모델링 단계에서는 원칙적으로 도출할 수 없다. 이유는 Subtype은 RDB(Relational Database)에서 존재하지 않는 개념이기 때문이다.

 

3. Subtype 물리모델 전환 방법(가정: Subtype은 두 개)

방법1) Rolling down

Super type 엔터티를 제거하고, 모든 데이터 element 및 관계들을 Subtype엔터티로 이동 시킨다.(2개 Table)

 

방법2) Rolling up 

Subtype엔터티를 제거하고 모든 데이터 element 및 관계들을 Supertype 엔터티로 이동 시킨다.(1개 Table)

 

방법3) Identity: 

Supertype, Subtype 엔터티들을 모두 유지한다.(3개 Table)

 

 

 

1) 엔터티의 독립성은 너무 중요한 개념이다. 이 주제만으로 정말 많은 얘기를 할 수 있고, 그 만큼 중요하다.

하지만 그 주제에 대해 깊이 들어가지 않겠다. 알고있다는 전제하에 얘기하고자 한다.(궁금하신 분은 구글링하면 엄청 나오니 찾아보시길 바란다)

'DATABASE > Articles' 카테고리의 다른 글

Define a “Subtype”  (0) 2020.06.05
Can a conceptual data model contain attributes?  (0) 2020.01.23
Define a “Thing”  (0) 2016.02.13
Modifying Foreign Key Definitions  (0) 2014.04.21
Trackbacks 0 : Comments 0

Write a comment


Can a conceptual data model contain attributes?

DATABASE/Articles 2020. 1. 23. 18:11

이번에 소개할 내용은 

개념 데이터 모델(CDM, Conceptual Data Model)에 속성(Attribute) 도출을 해야하는가?

이다.

 

사실 필자는 개념 데이터 모델에 속성을 도출하는것을 지양하는 편이다.

이유는 개념 데이터 모델(이하 CDM)의 정의에서 찾을 수 있는데, 개념 데이터 모델의 정의를 먼저 살펴보도록 하자.

 

개념 데이터 모델(CDM, Conceptual Data Model) : 기호나 텍스트1)로 비즈니스의 개념을 잘 표현한 데이터 모델

즉, CDM으로 비즈니스의 개념을 잘 파악할 수 있어야 하는데, 속성이 도출되어 있을 경우 핵심인 '비즈니스의 개념'보다 해당 속성에 포커싱이 맞추어지는(또는 이슈가 되는) 경우가 생각보다 많이 발생한다는 것이다. 이와 같은 이유로 필자는 가급적 불필요한 논쟁(?)을 피하고자 CDM에서는 속성을 도출하지 않는 편이다. 여기에서 주의할 것은 일반적으로 이렇게 한다는 것이지 반드시 그렇다는 것은 아니다. 프로젝트 초기에 CDM을, 일반적으로 우리가 생각하는 CDM과 LDM2)사이로 정의한다면 CDM에 식별자 또는 후보식별자(Natural key, Business key 등)를 포함한 중요 속성도 함께 도출해야 한다. 이후 계속, 지겹게 얘기하겠지만, 데이터 모델링에 정확한 규칙이나 방법3)은 없다. 다양한 비즈니스 환경에 맞게 유연하게 진행해야한다. 그렇기 때문에 데이터 모델링이 어려운 것이다.  

 

원문

https://stevehoberman.com/can-a-cdm-contain-attributes/

 

1) 여기에서 '기호나 텍스트'는 데이터 모델링 표기법(Notation)을 말한다.

2) LDM(Logical Data Model)

3) 물론 정확한 규칙이나 방법은 없지만, 방법론, 기업 및 집단의 표준화된 규칙이나 방법은 존재한다.

'DATABASE > Articles' 카테고리의 다른 글

Define a “Subtype”  (0) 2020.06.05
Can a conceptual data model contain attributes?  (0) 2020.01.23
Define a “Thing”  (0) 2016.02.13
Modifying Foreign Key Definitions  (0) 2014.04.21
Trackbacks 0 : Comments 0

Write a comment


Oracle sequence구현하기

DATABASE/SQLServer 2017. 11. 19. 17:46

Oracle sequence 구현하기


1. http://roqkffhwk.tistory.com/138


2. Sequence를 테이블로 만들어 관리하기

http://www.databaser.net/moniwiki/wiki.php/MS-SQL%EC%97%90%EC%84%9COracle%EC%9D%98Sequence%EB%94%B0%EB%9D%BC%ED%95%98%EA%B8%B0




Trackbacks 0 : Comments 0

Write a comment


Define a “Thing”

DATABASE/Articles 2016. 2. 13. 18:28

세계적으로 유명한 데이터 모델러 중 한 사람인 스티브 호버만(Steve Hoberman)이라는 사람이 있다.

개인적으로 가장 좋아하는 데이터 모델러이기도 하다. 그의 블로그에는 데이터 모델링의 개념에 대해 여러 사람의 의견을 종합하여 쓴 컬럼을 연재하고 있는데, 그 중 괜찮다고 생각하는 글을 골라 소개하고자 한다.


첫 번째로, 데이터 모델링 관점에서 바라보는 "Thing"에 대해 얘기해보고자 한다.

사실 'Thing'에 대해 얘기하기 이전에 'Thing' 이라는 용어(Term) 자체의 의미를 이해하는 것도 쉬운게 아니다. 국내 유명 서적이나 업체에서 이를 '것'으로 번역 하기도 하는데, 필자는 올바른 번역이 아니라 생각한다. 아래는 Naver사전에서 검색한 Thing에대한 내용이다. 무려 10개 이상의 뜻이 있는데, 좀 길지만 잘 살펴보기 바란다. 생각보다 많은 것을 얻을 수 있다. 기본은 기본에서 시작해야한다.

그리고 중요한 개념이나 아이디어는 의외의 '곳'에서 얻어지곤 한다라는 생각을 새삼느꼈다.

무슨 생각이 드는가? 힌트는 푸른색 글씨를 잘 살펴보면 중요한 개념을 쉽게 이해할 수 있다.




명사

1.OBJECT | [C] (사물을 가리키는) 것[거]

Can you pass me that thing over there?

저기 있는 저거 나한테 좀 건네 주겠니?

She's very fond of sweet things.

그녀는 단것을 아주 좋아한다.

He's just bought one of those exercise things.

그가 얼마 전에 운동 기구인가 뭐 그런 것을 하나 샀다.

Turn that thing off while I'm talking to you!

내가 너한테 이야기 할 때는 그것 좀 꺼!

2.OBJECT | [C] (생명이 없는) 물건, 사물

Don't treat her like thatshe's a personnot a thing!

그녀를 그렇게 대하지 말아요. 그녀는 사람이지 물건이 아니란 말예요!

He's good at making things with his hands.

그는 손으로 물건들을 만드는 것을 잘 한다.

She took no interest in the people and things around her.

그녀는 자기 주변의 사람들과 사물들에 관심을 갖지 않았다.

3.POSSESSIONS/EQUIPMENT | [pl.] things (개인 소유의・특정한 용도를 위한) 물건, 소지품, 용품

Shall I help you pack your things?

네 물건들[짐] 싸는 거 도와줄까?

Bring your swimming things with you.

수영에 필요한 용품을 가지고 오너라.

I'll just clear away the breakfast things.

아침 먹은 것[그릇]들만 좀 치울게요.

Put your things on and let's go.

(외투 등 필요한) 옷을 입고 가자.

4.ANYTHING | [sing.] a thing (부정문에서 강조의 의미로 쓰여) 하나[아무것]

haven't got a thing to wear!

난 입을 게[옷이] 하나도 없어요!

There wasn't a thing we could do to help.

우리가 도울 수 있는 게 하나[아무것]도 없었다.

Ignore what he saidit doesn't mean a thing.

그가 한 말은 무시해. 아무 뜻도 없으니까.

5.FACT/EVENT/SITUATION/ACTION | [C] (사실・사건・상황・행동 등을 가리키는) 것, 일; 말; 생각

like campingclimbing and that sort of thing.

나는 캠핑, 등산 그런 것들을 좋아한다.

She said the first thing that came into her head.

그녀는 머리속에 맨 처음 드는 생각을 말했다.

Why did you tell her our secret?' ‘I did no such thing!'

“넌 왜 그녀에게 우리 비밀을 말했니?” “난 그런 짓[말] 안 했어!”

Let's forget the whole thing.

우리 모든 걸 다 잊어버리자.

There are a lot of things she doesn't know about me.

그녀가 나에 대해 모르는 것이 많다.

There's another thing I'd like to ask you.

제가 (당신께) 여쭤 보고 싶은 것이 또 한 가지 있어요.

A terrible thing happened last night.

간밤에 끔찍한 일이 발생했다.

He found the whole thing very boring.

그는 그 모든 것[일]이 아주 지루했다.

I've got loads of things to do today.

난 오늘 할 일이 태산 같다.

The main thing to remember is to switch off the burglar alarm.

기억해야 할 주요한 것이 도난 경보기를 끄는 것이다.

6.FACT/EVENT/SITUATION/ACTION | [pl.] things (어떤 사람에게 영향을 미치는) 상황[사정/형편]

All things consideredshe's done very well.

모든 사정을 고려해 보면 그녀가 아주 잘 했다.

Why do you make things so difficult for yourself?

당신은 왜 상황을 당신 자신에게 그렇게 힘들게 만들어요?

Things haven't gone entirely to plan.

상황이 전적으로 계획대로 되지는 않았다.

HiJaneHow are things?

안녕하세요, 제인! 요즘 (형편이) 어떠세요?

Think things over before you decide.

결정을 하기 전에 상황을 잘 따져 보아라.

As things stand at presenthe seems certain to win.

상황이 현재와 같다면 그가 확실히 우승할 것 같다.

7.WHAT IS NEEDED/RIGHT | [C] [주로 단수로] <필요한 것・사회적으로 마땅한 일>

You need something to cheer you up—I know just the thing!

당신에겐 기분을 북돋워 줄 뭔가가 필요한데, 내가 바로 그것을 알고 있어요!

to say the right/wrong thing

옳은/잘못된[해서는 안 될] 말을 하다

The best thing to do is to apologize.

가장 좋은 것은 사과를 하는 것이다.

8.THINGS OF PARTICULAR TYPE | [pl.] things [뒤에 형용사가 함께 쓰여] (격식) <그 형용사로 묘사될 수 있는 모든 것들>

She loves all things Japanese.

그녀는 일본 것이라면 뭐든 아주 좋아한다.

9.CREATURE | [C] [형용사와 함께 쓰여] 생물

All living things are composed of cells.

모든 생물체는 세포로 구성되어 있다.

10.PERSON/ANIMAL | [C] [형용사와 함께 써서] (비격식) 것(어떤 감정과 함께 사람・동물을 가리킬 때)

You silly thing!

이 멍청한 것!

You must be starvingyou poor things.

배가 아주 고프겠구나, 이 불쌍한 것.

The cat's very illpoor old thing.

고양이가 아주 많이 아파요, 불쌍한 게 나이가 들어서.





위에서 말한 것 처럼 Thing을 '것'으로 번역한 이유는, 가장 많이 쓰이는 표현이 사물을 가리키는

즉, Object의 의미로서 Thing을 '것'으로 표현한 것으로 생각되는데... 5,6번째 뜻에서 'Action'이라는 단어에 주목하길 바란다. 보통 데이터 모델링을 할때 Action은 주로 관계로 표현 한다.. Thing에는 단순히 Object의 의미뿐만 아니라 Action의 의미도 내포하고 있다는 것을 알 수 있다. 이러한 이유로 필자는 Thing을 '것'으로 번역하는것을 옳지 않다고 생각한다. 글쓴이는 국외 IT용어를 무리하게 한글화하는 것은 지양해야한다는 지론을 가지고 있다. 특히 데이터 모델링은 개념에 대한 용어들이 많은데 이를 한글화 할 경우 의미를 너무 축소 또는 변질할 수 있는 가능성이 크기 때문이다. 사설이 길었다. Thing에 대한 개념들은 아래와 같은데 그 정의를 한 번 내려보자.



1. Party

'Party'는 비즈니스와 관련있는 사람 또는 조직이고, 비즈니스를 수행하는 구성원이자 주체이다.


예) 

사원, 고객, 담당자, 업체


관계어)

Involved Party, Legal Entity, Business Partner


2. Document

'Document'는 비즈니스적으로 중요한 것이 기록된 물리 또는 전자적 지식/정보 항목이다.

실제로 존재하는 문서일 수도 있고, 가상형태로 존재할 수 도 있다.


예) 

종이/전자 청구서(송장)


관계어)

계약(Contract), 합의(Agreement)


3. Classification

'Classification'이란 비즈니스에 관계된 events/activities/things를 어떤 목적을 위해 공통적인 속성이나 기능 등을 중심으로 분류하여 그룹화 하는 과정(arrangement)이다.


예)

사업부 내의 부서, 연봉 등급 등


4. Association

업무와 관련이 있는 두 개 이상의 'Thing'간의 관계


예) 

전통적인 예로서 교사와 학생을 들 수 있고, 강의실에서 그 둘 간의 관계가 형성된다.


관계어)

Relation


※중요

'Association' 이라는 개념은 신중히 사용해야한다. 매우 모호한 용어이기때문에 Party같이 상위 개념을 연결할 때만 사용하는것이 좋다.


5. Transaction 

- 저장해야한 비즈니스 이벤트(작은 단위의 이벤트라도 그만한 가치가 있다면 저장할 필요가 있다)

- 상황의 변화를 주는 어떤 사건의 발생


예) 거래, 현금이체, 물품, 이미 정의된 상품 또는 서비스의 거래


관계어)

비즈니스 이벤트, 활동(Activity)




원문

http://stevehoberman.com/2014/12/define-a-thing/#comments


'DATABASE > Articles' 카테고리의 다른 글

Define a “Subtype”  (0) 2020.06.05
Can a conceptual data model contain attributes?  (0) 2020.01.23
Define a “Thing”  (0) 2016.02.13
Modifying Foreign Key Definitions  (0) 2014.04.21
Trackbacks 0 : Comments 0

Write a comment


Modifying Foreign Key Definitions

DATABASE/Articles 2014. 4. 21. 16:32

최근 Information Management 스티브 호버만(Steve Hoberman)이 재미있는 글을 하나 올려서 소개합니다.

 

대충 내용은 ERWin등 모델링 툴에서 부모테이블의 Primary key를 자식테이블에서 Foreign Key로 지정했을때, 

부모테이블 컬럼의 definition을 자식테이블에서

  - 그대로 사용하느냐?

  - 마느냐? 

  - 아니면 재정의 하느냐?

에 대해 여러 모델러, 아키텍트들의 의견 입니다.

보통 모델링을 하면서 이 부분은 크게 문제삼지 않거나, 그냥 넘어가는 경우가 많은데...

이 내용으로 3페이지 분량을 다루고 있는게 흥미롭네요^^

 

참고로 저는

  1) 초기에는 부모테이블의 Key definition을 정의하고, 상속받을 경우 자식테이블의 Foreign key definition을 수정하지 않습니다.

    - 이 시기에는 부모테이블의 컬럼의 정의가 변경될 경우가 많기 때문

    - Rolename 지정 컬럼 포함

  2) 관계명을 표기합니다.

  3) 모델검토 완료 후 definition 재정의

    - 단일관계 : 재정의가 필요하다고 판단되는 경우에 한해서만 재정의

    - 다중관계 : 무조건 재정의

와같이 작업을 합니다.

여러분은 어떠하신지요?



When we create a one-to-many relationship between two entities, we copy the primary key from the entity on the one side (the parent entity) over as a foreign key to the entity on the many side (the child entity). We traditionally copy over all of the metadata associated with the primary key such as name, format and definition. The one exception where a foreign key can have a different name than its primary key is when there is more than one relationship from the same entity. To avoid having two or more data elements with the same name in the same entity, we "role name," meaning giving the foreign key a different name than its primary key.

For example, in the data model below, in Employee we have a foreign key back to Employee Type which has the same name as its primary key (Employee Type Code), and we have two foreign keys in Customer that point back to Employee. These two foreign keys are role-named to avoid having Employee ID twice in the Customer entity and to provide additional meaning as to what the foreign key represents. Primary Contact Employee ID points back to the Employee who is the primary contact for this Customer, and Initial Contact Employee ID points back to theEmployee who initially made contact with this Customer. 

In this data model, the definition for Employee Type Code is as follows:

Employee Type Code is a numeric value assigned to each organization-wide understood category for an Employee. These codes have business significance and are for human resources internal use only. Examples:

01 = Full time

02 = Part time

03 = Retired

And the definition for Employee ID is:

Employee ID is the unique, mandatory and stable business key for each Employee. It is assigned by human resources and used throughout the organization. Example: Bob Jones is assigned the Employee ID 123-AB-872123

Definitions also copy over from primary key to foreign key, so the Employee Type Code foreign key in Employeehas the same definition as Employee Type Code in Employee Type, and Primary Contact Employee ID andInitial Contact Employee ID have the same definition as Employee ID in Employee.


The Challenge

Should we at times modify the foreign key definitions so they are more relevant to the relationship they represent? After all, if I just see the Employee ID definition in Primary Contact Employee ID, it is not very descriptive.

What guidelines would you apply in deciding whether a foreign key should have a different definition than its primary key?


전문은 아래와 같고, 회원가입을 하셔야 보실 수 있습니다.

http://www.information-management.com/news/modifying-foreign-key-definitions-10025585-1.html





'DATABASE > Articles' 카테고리의 다른 글

Define a “Subtype”  (0) 2020.06.05
Can a conceptual data model contain attributes?  (0) 2020.01.23
Define a “Thing”  (0) 2016.02.13
Modifying Foreign Key Definitions  (0) 2014.04.21
Trackbacks 0 : Comments 0

Write a comment


Data pump로 import 하기

DATABASE/Oracle 2014. 1. 9. 16:05

Data pump로 import 하기


-- 1. User생성

create user B2EN identified by 비번;


-- 2. 디렉토리 생성

-- User와 동일한 디렉토리 생성 후 덤프파일 복사

D:\B2EN


-- 3. Oracle 디렉토리 설정

디렉토리 생성 후 2번 디렉토리와 Mapping




-- 4. 생성한 User에 권한 부어

grant read,write on directory B2EN to B2EN;


grant dba to B2EN;


-- 5. 명령창에서 실행

impdp B2EN/비번 dumpfile="expdp.B2EN.20131210.dmp" directory=B2EN logfile=a.log



'DATABASE > Oracle' 카테고리의 다른 글

Data pump로 import 하기  (0) 2014.01.09
[Oracle] 시간간격 구하기  (0) 2013.07.12
Understanding Primary Key(PK) Constraint in Oracle  (0) 2013.03.12
참조 Object조회하기  (0) 2013.02.13
열을 행으로  (0) 2011.12.01
[Oracle]Oracle DBA Scripts  (0) 2011.06.19
Trackbacks 0 : Comments 0

Write a comment


[Oracle] 시간간격 구하기

DATABASE/Oracle 2013. 7. 12. 21:31
1. 일반적인 경우(초)
SELECT 
ROUND (
    MOD
    (
        (
        TO_DATE('20120623152300', 'YYYYMMDDHH24MISS') - 
        TO_DATE('20120623152100', 'YYYYMMDDHH24MISS')
        ), 60
    ) * 24 * 60 * 60 
) SEC
FROM DUAL;
SEC    
------ 
   120

2. NUMTODSINTERVAL() 함수 사용
SELECT 
  TO_NUMBER (SUBSTR (DIFF, 2, 9)) DAY
, TO_NUMBER (SUBSTR (DIFF, 12, 2)) HOUR
, TO_NUMBER (SUBSTR (DIFF, 15, 2)) MINUTE
, TO_NUMBER (SUBSTR (DIFF, 18, 2)) SECOND
FROM    (
        SELECT NUMTODSINTERVAL (    TO_DATE (TIME2, 'YYYYMMDDHH24MISS')
                                  - TO_DATE (TIME1, 'YYYYMMDDHH24MISS'), 'DAY') DIFF
        FROM    (
                SELECT '20111125203138' TIME1, '20111203123557' TIME2
                FROM DUAL)
                );

DAY    HOUR     MINUTE       SECOND       

------ -------- ------------ ------------ 

     7       16            4           19

'DATABASE > Oracle' 카테고리의 다른 글

Data pump로 import 하기  (0) 2014.01.09
[Oracle] 시간간격 구하기  (0) 2013.07.12
Understanding Primary Key(PK) Constraint in Oracle  (0) 2013.03.12
참조 Object조회하기  (0) 2013.02.13
열을 행으로  (0) 2011.12.01
[Oracle]Oracle DBA Scripts  (0) 2011.06.19
Trackbacks 0 : Comments 0

Write a comment


Understanding Primary Key(PK) Constraint in Oracle

DATABASE/Oracle 2013. 3. 12. 08:26

primary-key
The Primary Key(PK) constraint is the most basic concept of any RDBMS (I am particularly interested in Oracle). Yet, I have noticed people getting confused when it comes to the practical usage and asking questions like:

- I have disabled PK and now oracle is doing full table scan.
- How PK constraints and indexes are related/different?
- How Oracle is using a non-unique index to enforce PK constraints?

Although these questions seem simple to the experienced users yet these can act as food for thought for the new developers. I have tried to consolidate few aspects about PK constraint which I found particularly confusing / worth knowing.

1. Primary key(PK) constraint and unique index are different.
PK constraint is a rule that prohibits multiple rows from having the same value in the same column or combination of columns and prohibits values from being null.
Index is a database object which is used for fast retrieval of data. It is created using DDL commands: “CREATE INDEX” or as part of a “CREATE TABLE” with PK/UK constraint or an “ALTER TABLE” command to add these constraints.

2. An enabled PK constraint is always associated with an index.
The associated index can be unique or non-unique (discussed later). The corresponding index can be find by querying:

SELECT constraint_name, constraint_type, index_name
  FROM user_constraints
 WHERE table_name = '<TABLE_NAME>';

Also, if we have an enabled PK constraint, the corresponding column(s) will be “NOT NULL“. Now if you drop/disable the PK constriant, the column(s) will be changed to the state in which they were before adding the PK constraint.

-- Creating a table with two columns. One as NULL and other as NOT NULL
CREATE TABLE tbl_test ( col_1 NUMBER,
                                  col_2 NUMBER NOT NULL);
 
-- Querying to check the the column nullable status
SELECT table_name, column_name, nullable
  FROM user_tab_cols
 WHERE table_name = 'TBL_TEST';
  
-- TABLE_NAME | COLUMN_NAME | NULLABLE
-- TBL_TEST   | COL_1       | Y
-- TBL_TEST   | COL_2       | N
 
-- Adding the the PK constraint
ALTER TABLE tbl_test ADD CONSTRAINT tbl_test_pk PRIMARY KEY(col_1);
 
-- Querying to check the user constraints.
--Two entries, one for NOT NULL constraint and one for PK constraint
SELECT a.table_name, b.column_name, a.constraint_name,
           a.constraint_type, a.index_name
  FROM user_constraints a, user_cons_columns b
 WHERE a.table_name      = 'TBL_TEST'
   AND a.constraint_name = b.constraint_name;
  
-- TABLE_NAME | COLUMN_NAME | CONSTRAINT_NAME | CONSTRAINT_TYPE | INDEX_NAME
-- TBL_TEST   | COL_2       | SYS_C001231845  | C               |
-- TBL_TEST   | COL_1       | TBL_TEST_PK     | P               | TBL_TEST_PK
 
-- Rechecking the column nullable status. Both the columns are now NOT NULL
SELECT table_name, column_name, nullable
  FROM user_tab_cols
 WHERE table_name = 'TBL_TEST';
  
-- TABLE_NAME | COLUMN_NAME | NULLABLE
-- TBL_TEST   | COL_1       | N
-- TBL_TEST   | COL_2       | N
 
-- Disabling the PK constraint
ALTER TABLE tbl_test DISABLE PRIMARY KEY;
-- OR
-- ALTER TABLE tbl_test DISABLE CONSTRAINT tbl_test_pk;
 
-- The column status is changed back as it was before adding the PK.
SELECT table_name, column_name, nullable
  FROM user_tab_cols
 WHERE table_name = 'TBL_TEST';
  
-- TABLE_NAME | COLUMN_NAME | NULLABLE
-- TBL_TEST   | COL_1       | Y
-- TBL_TEST   | COL_2       | N

3. If the PK constraint is disabled, there will be no index associated with it.
The “index_name” in the above query would be blank. But the constraint name would still be there. So, PK constraint exists (with status as disabled) but there is no associated index.

DROP TABLE tbl_test;
 
CREATE TABLE tbl_test (col_1 NUMBER);
 
CREATE INDEX idx_col_1 ON tbl_test (col_1);
 
ALTER TABLE tbl_test ADD CONSTRAINT tbl_test_pk PRIMARY KEY(col_1);
 
SELECT constraint_name, constraint_type, index_name
  FROM user_constraints
 WHERE table_name = 'TBL_TEST';
 
-- CONSTRAINT_NAME | CONSTRAINT_TYPE | INDEX_NAME
-- TBL_TEST_PK     | P               | IDX_COL_1
 
ALTER TABLE tbl_test DISABLE PRIMARY KEY;
-- OR
-- ALTER TABLE tbl_test DISABLE CONSTRAINT tbl_test_pk;
 
-- Once the PK is disabled, the association with the index is gone
SELECT constraint_name, constraint_type, index_name, status
  FROM user_constraints 
 WHERE table_name = 'TBL_TEST';
 
CONSTRAINT_NAME | CONSTRAINT_TYPE | INDEX_NAME | STATUS
TBL_TEST_PK     | P               |            | DISABLED

4. Once PK constraint is disabled, the index left on that column can be dropped.
If the index was created by oracle with the creation of PK constraint, it will be dropped automatically. If some existing index was associated with the PK constraint, it will not be dropped by oracle(refer point 6 for details). But its now possible to drop that index manually.

-- With the primary key disabled, the index can now be dropped
DROP INDEX idx_col_1;
 
SELECT table_name, index_name
  FROM user_indexes
 WHERE table_name = 'TBL_TEST';
  
-- no rows returned.

5. Enabling of the PK constraint requires association with index.
If we now try to enable the PK constraint again, it will pick up the first index it found on that column and will get associated with it. In case there is no index to get associated, oracle will create a new index with the name same as that of PK constraint.

ALTER TABLE tbl_test ENABLE PRIMARY KEY;
-- OR
-- ALTER TABLE  tbl_test ENABLE CONSTRAINT tbl_test_pk;
 
-- Oracle has created a new index with name "TBL_TEST_PK"
SELECT constraint_name, constraint_type, index_name
  FROM user_constraints
 WHERE table_name = 'TBL_TEST';
  
-- A new index "TBL_TEST_PK" is created and associated with the PK constraint
-- CONSTRAINT_NAME | CONSTRAINT_TYPE | INDEX_NAME
-- TBL_TEST_PK     | P               | TBL_TEST_PK
 
SELECT table_name, index_name
  FROM user_indexes
 WHERE table_name = 'TBL_TEST';
  
-- TABLE_NAME | INDEX_NAME
-- TBL_TEST   | TBL_TEST_PK

6. Use “USING INDEX” clause to associated a particular index with the PK.
If there are more than one indexes on the column on which you want to add PK constraint, we can selectively choose the index to be assoicated with the PK using “USING INDEX“. This clause can be used while:
a) Adding the PK constraint for the first time (using “ALTER TABLE” command).

DROP TABLE tbl_test;
 
CREATE TABLE tbl_test ( col_1 NUMBER,
                        col_2 NUMBER,
                        col_3 NUMBER);
 
CREATE INDEX idx_col_1_2 ON tbl_test(col_1, col_2);
 
CREATE INDEX idx_col_1_3 ON tbl_test(col_1, col_3);
 
CREATE UNIQUE INDEX idx_col_1 ON tbl_test(col_1);
 
-- Forcing oracle to use the unique index "IDX_COL_1"
ALTER TABLE tbl_test ADD CONSTRAINT tbl_test_pk PRIMARY KEY(col_1)
USING INDEX idx_col_1;
 
SELECT constraint_name, constraint_type, index_name
  FROM user_constraints
 WHERE table_name = 'TBL_TEST';
  
-- CONSTRAINT_NAME | CONSTRAINT_TYPE | INDEX_NAME
-- TBL_TEST_PK     | P               | IDX_COL_1

b) Enabling the PK constraint.

DROP TABLE tbl_test;
 
CREATE TABLE tbl_test ( col_1 NUMBER, col_2 NUMBER,
                        col_3 NUMBER);
 
CREATE INDEX idx_col_1_2 ON tbl_test(col_1, col_2);
 
CREATE INDEX idx_col_1_3 ON tbl_test(col_1, col_3);
 
CREATE UNIQUE INDEX idx_col_1 ON tbl_test(col_1);
 
ALTER TABLE tbl_test ADD CONSTRAINT tbl_test_pk PRIMARY KEY(col_1);
 
SELECT table_name, index_name, uniqueness
  FROM user_indexes
 WHERE table_name = 'TBL_TEST';
  
-- TABLE_NAME | INDEX_NAME  | UNIQUENESS
-- TBL_TEST   | IDX_COL_1_2 | NONUNIQUE
-- TBL_TEST   | IDX_COL_1_3 | NONUNIQUE
-- TBL_TEST   | IDX_COL_1   | UNIQUE
 
-- Although an unique index exists, oracle has picked up the first index
SELECT constraint_name, constraint_type, index_name
  FROM user_constraints
 WHERE table_name = 'TBL_TEST';
  
-- CONSTRAINT_NAME | CONSTRAINT_TYPE | INDEX_NAME
-- TBL_TEST_PK     | P               | IDX_COL_1_2
 
ALTER TABLE tbl_test DISABLE PRIMARY KEY;
 
-- Forcing oracle to use the unique index
ALTER TABLE  tbl_test ENABLE CONSTRAINT TBL_TEST_PK USING INDEX IDX_COL_1;
 
SELECT constraint_name, constraint_type, index_name
  FROM user_constraints
 WHERE table_name = 'TBL_TEST';
  
-- CONSTRAINT_NAME | CONSTRAINT_TYPE | INDEX_NAME
-- TBL_TEST_PK     | P               | IDX_COL_1

Manully associating PK constraint with already existing unique/non-unique index has the following advantages:
a) The index remains available and valid when the constraint is disabled.
b) Enabling the PK constraint doesn’t require rebuilding the unique/non-unique index associated with the constraint.
c) The redundant indexes can be eliminated. PK constraint can be associated with a composite index too if the column is included as the prefix of the composite index. So, in the example above, it iss possible to remove the unique index (if not required) and the composite index can be used for PK enforcement.

7. The index associated with the PK constraint needn’t be unique.
A non-unique index can also be be associated with the PK constraints. Now the question is how oracle allows PK constraint to be enforced using a non-unique index. Here is the explanation (as per best of my knowledge, might not be correct):

As described above, PK constraint is a rule to prohibit duplicate/null records for the PK column. Suppose, we already have 1 Million records in the table and inserting a new entry. So, to enforce the PK constraint, Oracle has to search through the already present records and this is where the index comes handy. If you have an index on that column, the search will be quite fast. The unique index will be the best but a non-unique index will also be a better option as compared to a full table scan. So, the basic purpose of associating index with PK constraints is to efficiently enforce the underlying rule. So, using index for PK constraint enforcement is a part of Oracle architecture (I assume its the same for all other RDBMS).

DROP TABLE tbl_test;
 
CREATE TABLE tbl_test ( col_1 NUMBER, col_2 NUMBER,
                        col_3 NUMBER);
 
CREATE INDEX idx_col_1_2 ON tbl_test(col_1, col_2);
 
-- Associating composite index with the PK constraint
ALTER TABLE tbl_test ADD CONSTRAINT tbl_test_pk PRIMARY KEY(col_1)
USING INDEX idx_col_1_2;
 
SELECT constraint_name, constraint_type, index_name
  FROM user_constraints
 WHERE table_name = 'TBL_TEST';
  
-- CONSTRAINT_NAME | CONSTRAINT_TYPE | INDEX_NAME
-- TBL_TEST_PK     | P               | IDX_COL_1_2
 
 SELECT table_name, index_name, uniqueness
  FROM user_indexes
 WHERE table_name = 'TBL_TEST';
  
-- TABLE_NAME | INDEX_NAME  | UNIQUENESS
-- TBL_TEST   | IDX_COL_1_2 | NONUNIQUE

8. Merits of allowing non-unique index for enforcing PK constraints:
a) The non-unique indexes facilitates the use of “INITIALLY DEFERRED” clause with the constraint until the transaction has been committed if the PK constraint has been defined as “DEFERRABLE” at the time of creating. The “DEFERRABLE” PK constraint can’t be associated with a unique index.

DROP TABLE tbl_test;
 
CREATE TABLE tbl_test ( col_1 NUMBER,
                        col_2 NUMBER);
                         
ALTER TABLE tbl_test ADD CONSTRAINT tbl_test_pk PRIMARY KEY(col_1) 
INITIALLY DEFERRED DEFERRABLE;
 
-- The resulting index created by oracle is non-unique
SELECT table_name, index_name, uniqueness
  FROM user_indexes
 WHERE table_name = 'TBL_TEST';
 
-- TABLE_NAME | INDEX_NAME  | UNIQUENESS
-- TBL_TEST   | TBL_TEST_PK | NONUNIQUE
 
-- Allowing duplicate records inspite of the presence of PK consraint
INSERT INTO tbl_test VALUES (1,2);
INSERT INTO tbl_test VALUES (1,2);
INSERT INTO tbl_test VALUES (1,2);
 
-- Constraint checked at the time of transaction commit
COMMIT;
-- ORA-02091: transaction rolled back
-- ORA-00001: unique constraint (GC_ADMIN.TBL_TEST_PK) violated

b) The “NOVALIDATE” option can be used to exclude the enforcement of constraint on the already existing data.

DROP TABLE tbl_test purge;
 
CREATE TABLE tbl_test ( col_1 NUMBER);
 
INSERT INTO tbl_test VALUES (1);
INSERT INTO tbl_test VALUES (1);
INSERT INTO tbl_test VALUES (1);
 
ALTER TABLE tbl_test add constraint idx_col_1 PRIMARY KEY (col_1) NOVALIDATE;
-- ORA-02437: cannot validate (GC_ADMIN.IDX_COL_1) - primary key violated
 
ALTER TABLE tbl_test add constraint idx_col_1 PRIMARY KEY (col_1) DISABLE;
 
ALTER TABLE tbl_test ENABLE NOVALIDATE PRIMARY KEY;
-- ORA-02437: cannot validate (GC_ADMIN.IDX_COL_1) - primary key violated
 
-- This is because oracle tries to create unique index for the PK constraints.
-- The statement fails while checking the uniqueness for creating the unique index.
-- To fix this, create a non-unique index first. Then oracle will associate
-- the primary key constraint with this non-unique index.
CREATE INDEX idx_col_1 ON tbl_test(col_1);
 
ALTER TABLE tbl_test ENABLE NOVALIDATE PRIMARY KEY;

9. Bitmap index can’t be associated with a PK constraint.

DROP TABLE tbl_test;
 
CREATE TABLE tbl_test ( col_1 NUMBER,
                        col_2 NUMBER,
                        col_3 NUMBER);
 
CREATE BITMAP INDEX idx_col_1 ON tbl_test (col_1);
 
ALTER TABLE tbl_test ADD CONSTRAINT tbl_test_pk PRIMARY KEY(col_1) USING INDEX idx_col_1;
-- ORA-14196: Specified index cannot be used to enforce the constraint.

10. Dropping the PK may or may not drop the associated index.
If you drop a PK constraint, the associated index may or may not be dropped depending on the association of PK constraint and index. Two scenario arises:
a) The PK constraint is associated with an already present index (either by using “USING INDEX” clause or by default association if not specifically specified). In that case, the index will not be dropped with the dropping of PK constraint.

DROP TABLE tbl_test;
 
CREATE TABLE tbl_test ( col_1 NUMBER);
 
CREATE INDEX idx_col_1 ON tbl_test (col_1);
 
ALTER TABLE tbl_test ADD CONSTRAINT tbl_test_pk PRIMARY KEY(col_1)
USING INDEX idx_col_1;
 
ALTER TABLE tbl_test DROP PRIMARY KEY;
 
-- Primary Key dropped
SELECT constraint_name, constraint_type, index_name
  FROM user_constraints
 WHERE table_name = 'TBL_TEST';
  
-- no rows selected.
-- The index is still present
 SELECT table_name, index_name, uniqueness
  FROM user_indexes
 WHERE table_name = 'TBL_TEST';
  
-- TABLE_NAME | INDEX_NAME | UNIQUENESS
-- TBL_TEST   | IDX_COL_1  | NONUNIQUE

b) If the PK constraint is created while there is no index on PK column, oracle will create a new unique index with the same name as PK constraint. By default, this index will be dropped with the dropping of PK constraint. You can keep this index intact by using the “KEEP INDEX” clause.