블로그 이미지
010-9967-0955 보미아빠

카테고리

보미아빠, 석이 (500)
밥벌이 (16)
싸이클 (1)
일상 (1)
Total
Today
Yesterday

달력

« » 2024.3
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31

공지사항

최근에 올라온 글


MAC 주소를 바꾸어야 한다면 다음과 같이 하면 된다.
아래 그림의 값 중에서 앞 6자리는 제조사 정보이고 뒤 6자리는 MAC 주소이다.
해당값을 16진수로 적어 주면 된다.

그리고 해당 네트웍 카드를 사용안함 -> 사용 으로 한번만 클릭해주면 새로운 MAC 주소를 사용하게 된다.
햐~ 좋은거~


Posted by 보미아빠
, |


정규화 법칙은 업데이트 이상과 데이터 비일관성을 막기위해 디자인 되었다. 성능 Tradeoff 에 대해서, 이 가이드는 Non-key 속성은 자주 업데이트 된다고 가정한다. 이런 가정은 데이터 추출에는 비 효율적이다. 왜냐하면, 정규화되지 않은 경우 하나의 레코드에서 추출 될 수 있고, 정규화 폼에서는 아마도 여러 레코드에서 추출해 와야 할 수 있기 때문이다. 실제 성능 요구사항을 고려 할 때 모든 레코드를 완전히 정규화 할 의무는 없다.

 

삽입시 의도하지 않은 값들도 함께 삽입

삭제시 의도하지 않은 값들도 함께 삭제 (값 자체가 없어져 버린다.)

갱신시 전체 갱신되지 않고 일부만 갱신되는 것



1 정규화
1 정규형은 레코드 타입의 모양을 다룬다.
1 정규화는 하나의 레코드는 반드시 같은 필드 숫자로 이루어져야 한다.
1 정규화는 반복되는 필드와 그룹을 없애는 것이다. 정의의 문제지 디자인 가이드라인이 아니다. 관계형 데이터베이스 이론은 레코드들이 가변 필드를 갖는 것을 다루지 않는다.
참고) 하나의 필드에 여러값을 갖는 경우도 1정규화 위반 이라고 하지만, 이것은 데이터베이스 이론의 위반이다. (도메인 원자값)

2 정규화
non-key 필드 팩트가 전체 key 중 일부 key 의 팩터 일 때 발생한다. 이것은 여러 필드의 조합과 같이 key 가 복합키 일때만 일어난다. (부분적 함수 종속 제거)

3 정규화
non-key 필드가 다른 non-key 필드의 팩트일 때 발생한다. (이행적 함수 종속 제거)

BCNF (BoyceCodd Normal Form)
모든 결정자가 후보키 (결정자 이면서 후보키가 아닌것 제거)

 



4 정규화
서로 독립인 다중치 속성일 경우 발생한다. (다치 종속 제거)

 



5 정규화 (PJNF, Project-Join Normal Form)
서로 독립이 아닌 다중치 속성일 경우 발생한다. (조인 종속성 제거)

 

 


6 정규화 (DKNF, Domain-Key Normal Form)
계좌의 Account 가 9로 시작하고, 잔고가 2500불 이상이면 다른 테이블에 들어간다.

 

 


http://blog.naver.com/jinsol1/100024608148


아주 심플하게 정리 했다. 그 이상의 정규형이 있으면 좀 알려주세요~ ^.^ 이것보다 더 쉽게 설명 할 수는 없을듯...
이거 강의하고 조광원 아저씨처럼 쉽게 설명한다는 이야기를 들어 매우 기분이 좋았습니다.





A Simple Guide to Five Normal Forms in Relational Database Theory 에 자세히 설명되어 있으며 매우 쉽게 예제와 함께 설명한다.

위 내용을 다 이해한다면, 3정규화 까지만 해라는 말을 못 할 듯 하다.


이번 정규화 발표가 데이터베이스 디자인시 도움이 되었으면 합니다.
수고하세요~

첨부파일은 원본 입니다.

A Simple Guide to Five Normal Forms in Relational Database .pdf

 

한글자료 
          http://yuhani.springnote.com/pages/917834

어드벤스드 자료로 5정규화와 6정규화의 내용은 다음을 참고한다.

정규화 adx.ppt

 

정규화 adx 한글판.ppt

 









William Kent, "A Simple Guide to Five Normal Forms in Relational Database Theory", Communications of the ACM 26(2), Feb. 1983, 120-125. Also IBM Technical Report TR03.159, Aug. 1981. Also presented at SHARE 62, March 1984, Anaheim, California. Also in A.R. Hurson, L.L. Miller and S.H. Pakzad, Parallel Architectures for Database Systems, IEEE Computer Society Press, 1989. [12 pp]

A Simple Guide to Five Normal Forms in Relational Database Theory
관계형데이터베이스 이론에서의 5정규화의 간단한 가이드

1 소개 **************
관계형 데이터베이스 이론에서 정규화란 레코드 디자인에 대한 가이드라인이다. 본 가이드라인은 1정규화 부터 5정규화 까지를 다룬다. 용어는 관계이론의 이해 없이 볼 수 있는 것들이다. 이 디자인 가이드라인들은 관계형 데이터베이스를 사용하지 않더라도 충분히 의미 있는 것이다. 일반화를 강조하기 위해, 관계형 모델의 컨셉의 참조 없이 가이드라인을 제시한다. 더불어 좀 더 이해하기 쉽게 하기 위해서이다. 이 프리젠테이션은 레코드 디자인의 의도된 제약을 직관적으로 전달한다. 약식(비공식적)이지만 몇몇 기술적 세부사항은 부정확 할 수 있다. 이 주제를 포괄적으로 다루는 것은 Date [4] 에서 다룬다.

정규화 법칙은 업데이트 이상과 데이터 비일관성을 막기위해 디자인 되었다. 성능 Tradeoff 에 대해서, 이 가이드는 Non-key 속성은 자주 업데이트 된다는 가정한다. 이런 가정은 데이터 추출에는 비 효율적이다. 왜냐하면, 정규화되지 않은 경우 하나의 레코드에서 추출 될 수 있고, 정규화 폼에서는 아마도 여러 레코드에서 추출해 와야 할 수 있기 때문이다. 실제 성능 요구사항을 고려 할 때 모든 레코드를 완전히 정규화 할 의무는 없다.

2. Frist Normal Form **************
E.F. Codd, "A Relational Model of Data for Large Shared Data Banks", Comm. ACM 13 (6), June 1970, pp. 377-387.
The original paper introducing the relational data model.

1 정규형은 레코드 타입의 모양을 다룬다.
1 정규화는 하나의 레코드는 반드시 같은 필드 숫자로 이루어져야 한다.
1 정규화는 반복되는 필드와 그룹을 없애는 것이다. 정의의 문제지 디자인 가이드라인 이 아니다. 관계형 데이터베이스 이론은 레코드들이 가변 필드를 갖는 것을 다루지 않는다.

1정규화 위반사례 1 (데이터베이스 이론의 정의 위반)
아이디, 취미1, 취미2, 취미3
민석, 싸이클, 영화감상, SQL Server
만철, 오락실게임, SQL Server Bulk Operation,null
산아, SQL Server, null, null

1정규화 위반사례 2 (반복 그룹 - 업데이트 어떻게 할꺼야?)
아이디, 취미
민석, 싸이클
민석, 영화감상
민석, SQL Server
만철, 오락실 게임
만철, SQL Server Bulk Operation
산아, SQL Server
참고) 하나의 필드에 여러값을 갖는 경우도 1정규화 위반 이라고 하지만, 이것은 데이터베이스 이론의 위반이다.

3. SECOND AND THIRD NORMAL FORMS **************
E.F. Codd, "Normalized Data Base Structure: A Brief Tutorial", ACM SIGFIDET Workshop on Data Description, Access, and Control, Nov. 11-12, 1971, San Diego, California, E.F. Codd and A.L. Dean (eds.).
An early tutorial on the relational model and normalization.

E.F. Codd, "Further Normalization of the Data Base Relational Model", R. Rustin (ed.), Data Base Systems (Courant Computer Science Symposia 6), Prentice-Hall, 1972. Also IBM Research Report RJ909.

W. Kent, "A Primer of Normal Forms", IBM Technical Report TR02.600, Dec. 1973.
An early, formal tutorial on first, second, and third normal forms.

2 정규화와 3정규화는 관계에서 non-key 와 key 필드를 다룬다.
2 정규화와 3정규화 에서는 하나의 non-key 필드는 key 에 대해서 반드시 하나의 팩트를 제공해야 한다. 복합키의 경우도 전체 키에 하나의 팩터를 제공해야 한다. 그리고, 이 레코드들은 1 정규화를 준수해야 한다.

이제부터 단지 하나의 값만을 가지는 팩트를 다룰 것이다. 팩트는 부서와 사원과 같이, one-to-many 관계를 가질것이다. 또는, 사원과 배우자와 같이 one-to-one 관계이다. "X 는 Y 의 팩터이다." 라는 것은 X 와 Y 에 대해 one-to-one 이나 one-to-many 관계이다.
Y 는 하나 이상의 컬럼을 가지고, X 는 그렇지 않을 것이다. 수량은 파트와 창고 조합의 팩트이다.

3.1 Second Normal Form
2 정규화 위반은 non-key 필트 팩트가 전체 key 중 일부 key 의 팩터일때 발생한다. 이것은 여러 필드의 조합과 같이 key 가 복합키 일때만 일어난다. 아래와 같은 인벤토리 레코드를 생각해 보자.

---------------------------------------------------
| PART | WAREHOUSE | QUANTITY | WAREHOUSE-ADDRESS |
====================-------------------------------

key 는 part 와 warehouse 두개의 조합으로 이루어져 있다. 하지만 warehouse-address 는 warehose 하나에만 속하는 팩터이다. 이러한 디자인의 기본적인 문제는 다음과 같다.

* warehose 에 있는 part별 warehouse address 는 모든 행에서 반복된다.
* 만약 warehose-address가 갱신되면,그 warehouse 에 있는 모든 part 의 warehouse-address 가 업데이트 되어야 한다.
* 중복으로 들어가 있기 때문에 데이터 일관성을 잃을 수 도 있다. 같은 warehose 에 다른 warehouse-address 가 보여질 수 있다.
* 만약 어떤 시간에서 warehose 에 part 가 없으면, warehouse-address 를 유지 할 수 없다.

2 정규화의 문제에서 안전하기 위해서는 위 예제의 레코드는 두개의 레코드로 분리 되어야 한다.

-------------------------------  ---------------------------------
| PART | WAREHOUSE | QUANTITY |  | WAREHOUSE | WAREHOUSE-ADDRESS |
====================-----------  =============--------------------

데이터 디자인이 이런 방법으로 변화되면 정규화 되지 않은 레코드들은 정규화된 레코드로 된다. 이러한 프로세스를 정규화라 한다. 정규화(normalization)의 용어는 때때로 특정 정규 폼에 상대적으로 사용된다. 그래서, 하나의 레코드셋이 2 정규화에 대해서는 정규 폼을 지키고 3 정규형에 대해서는 아닐 수 있다.

중복과 비일관성을 최소화 함으로 정규화된 디자인은 데이터 완전성을 향상시킨다. 하지만 특정 검색 어플리케이션의 성능 비용이 더 야기되기도 한다. 어떤 어플리케이션이 warehose 에 있는 part 의 warehouse-address 를 보려고 할 때, 비 정규화된 폼에서는 하나의 레코드만 보면되나, 정규화된 디자인에서는 그 어플리케이션은 2개의 레코드 타입을 조사한 후 적절한 패어로 연결해야 한다.

3.2 Third Normal Form
3 정규화 위반은 non-key 필드가 다른 non-key 필드의 팩트일 때 발생한다.

------------------------------------
| EMPLOYEE | DEPARTMENT | LOCATION |
============------------------------

employee 필드는 키 필드이다. 만약 각 department 가 한 곳에 있다면, location 필드는 department 의 팩트이다. 더해서 employee 도 팩트가 된다. 이러한 디자인의 문제는 아래와 같이 2 정규화 위반과 같다.

* department 에 할당된 모든 employee 에 department의 location 이 중복되어 나타난다.
* 만약 department 의 location 이 변경되면, 이러한 모든 레코드가 업데이트 되어야 한다.
* 중복 때문에 데이터는 일관정을 잃을 수 있고, 같은 department 에 대해 다른 location 을 보일 수 있다.
* 만약 department 에 employee 가 없으면, department 의 location 정보를 보존 할 수 없다.

요약하면, 모든 필드는 키의 부분이나 하나의 팩트를 전달 할때 전체키에 연관되어야 한다. 다른건 없다. 이렇때 레코드는 2,3 정규화의 폼이다.

3.3 Functional Dependencies
데이터베이스 이론에서, 2,3 정규화 폼은 함수 종속으로 정의된다. 우리의 싱글 밸류 팩트에 일치한다. 어떤 필드 Y 는 X 필드(들)에 "함수 종속" 이며 만약 두개의 레코드가 있을 때 같은 X 가 다른 Y 값을 가지면 이것은 종속이 아니다. 다르게 말하면, 주어진 X 값은 항상 같은 Y 값을 가진다. X 가 key 이면, 모든 필드들은 정의에 의해 X 에 종속된다. 그렇기 때문에 같은 X 값에 대해 2개의 레코드를 가질 수 없다.

여기 함수 종속과 우리가 보여준 단일값 팩트는 기술적으로 약간 틀린점이 있다. 함수 종속은 유니크 와 단일 식별자에서만 존재한다. 예를 들자면 어떤 사람의 주소가 단일값 팩트 일때를 가정해 보자. 그 사람은 하나의 주소만 가지고 있다. 만약 우리가 사람에 대해 unique 식별자를 제공하지 못하면, 함수 종속되지 못한다.

(동명 2인)
------------------------------------------
|   PERSON   |       ADDRESS                 |
-------------+--------------------------------
| John Smith | 123 Main St., New York        |
| John Smith | 321 Center St., San Francisco |
----------------------------------------------

사람이 단일 주소를 가지지만, 주어진 이름이 여러 다른 주소를 나타낼 수 있다. 그렇기 때문에 우리의 단일값 팩트는 함수 종속에 해당하지 않는다.

마찬가지로, address는 함수 종속성을 만족하기 위해 동일한 철자를 써야 한다. 다음과 같은 경우는 같은 사람이 두개의 다른 주소를 가지는 것 처럼 보인다. 다시 말해 함수 종속성을 불가능 하게 한다.

(같은 사람이며, 주소를 다르게 표시함)
---------------------------------------
|   PERSON   |       ADDRESS          |
-------------+-------------------------
| John Smith | 123 Main St., New York |
| John Smith | 123 Main Street, NYC   |
---------------------------------------

유니크하지 않거나 비 단일 식별자를 사용하면 보호하지 못한다. 이런 예제는 종종 데이터 관리 문제를 유발 시킨다.  지적 하고자 하는것은, 기능적 종속과 다양한 정규화들은 유니크나 단일 식별자가 있을때만 정의된다. 그래서, 디자인 가이드라인은 정규화 공식 정의에 적용된 것 보다 좀 더 암시적이다.

예를 들어, 디자이너는 다음 예제에서 어떤 non-key 필드가 단일값 팩터 임을 안다. 이 디자인은 위에서 언급한 모든 업데이트 이상에 해당된다.   

----------------------------------------------------------
| EMPLOYEE  |  FATHER    |  FATHER'S-ADDRESS             |
|============------------+-------------------------------|
| Art Smith | John Smith | 123 Main St., New York        |
| Bob Smith | John Smith | 123 Main Street, NYC          |
| Cal Smith | John Smith | 321 Center St., San Francisco |
----------------------------------------------------------

하지만, 공식 용어에서, father's-address 와 father 사이에는 함수 종속이 없다. 그러므로, 3정규화 위반이 아니다.


1nf 하나의 컬럼에 한개의 값만 있을것

2nf 키 컬럼에 종속되는 컬럼은 테이블 분리 

3nf 키가 아닌 컬럼에 종속되는 컬럼은 테이블 분리

bcnf 일반컬럼이 복합키 컬럼 일부에 종속되는 경우 테이블 분리

4nf 복합키가 다른 주제영역을 다루고 있을경우 1:n 으로 분리한다. 

5nf 4nf 에서 주제 영역간 n:m 관계가 있을때 각각을 1:n 으로 분리해 join 종속성을 제거한다. 

1~3까지만 실무에 쓰임 

Posted by 보미아빠
, |

요즘 넘 운동을 안해서 함 달렸다. 오랜만에~~~~슉 슉~ 왜 저렇게 수줍어 하지...ㅡ.ㅡ 이상하네....
여자 사람이 밤 라이딩 나와서 그런가......ㅋㅋㅋㅋㅋ

Posted by 보미아빠
, |

최근에 달린 댓글

최근에 받은 트랙백

글 보관함