BCNF로 정상화하려고 시도합니다.

BCNF인지 여부는 확실하지 않지만 선생님은 인스트루먼트이 BCNF에 있다고 말했습니다. 선생님은 옳고 그른 것을 내 마음을 어지럽히고 나를 확신시키지 않습니다. 그는 내가 이미 생각한 것들을 계속해서 말하고 있으며, 그가 말하는 것을 얻지도 못한다.BCNF로 정상화하려고 시도합니다.

INSTRUMENT (InstrumentID, InstrumentType, 조정, 출연자,의 Adr, 전화, 가용성) 참고 (TitleNr,Tune, 작곡가, 복사, 제목, 출연자)

그래서이 정규화? BCNF에 :

악기 (InstrumentID, InstrumentType, 조정, 가용성, PerformerID *)
참고 (TitleNr, Title, 조정, 작곡가, 복사, PerformerID *)
PERFORMER (PerformerID, 이름,의 Adr, 전화 번호)

Tune은 INSTRUMENT와 NOTES에 있습니다. 둘 다있을 수 있습니까?

출처

2010-08-03 jdnhldn

"조정"이란 무엇입니까? –

아래의 답에 약간의 답을 달았습니다. "가용성"은 연주자가 아니라 악기와 관련이 있다고 생각합니까? 또는, 그 문제에 대해, 곡 "튜닝"이 "오케스트라 악보"와 같은 것을 의미한다면? –

각 일반 양식에는 앞에 오는 일반 양식이 필요합니다.

1 NF - 귀하의 표에는 원자 값 즉 세트가 없습니다.

2 NF - 키가 아닌 속성을 사용하려면 키의 모든 부분을 결정해야합니다.

3 NF - 키가 아닌 속성은 키를 결정할 필요가 있지만 아무것도 필요하지 않습니다.

3.5 NF - 키가 아닌 속성이 키 속성을 결정할 수있는 경우 고유 한 튜플을 만들어야합니다.

내 첫 번째 관심사는 TitleNr의 약자입니다. 고유 ID이면 키가 아닌 속성은 Title을 결정할 필요가 없기 때문에 2 NF가 아 U니다.

제 2의 관심사는 Tune이 포함되어 있으면 InstrumentID가 적절한 후보 키가 아니라는 것입니다. Instrument.Tune이 해당 악기로 어떤 곡을 연주했는지 나타내는 경우 하나의 악기에서 여러 개의 Tunes를 재생할 수 있습니다. 이러한 속성을 다른 테이블로 분할하는 것이 더 좋을 것입니다. 그렇지 않으면 다른 비 핵심 속성이 2 NF가되지 않게합니다.

단순히 악기의 키에 포함되지 않은 PerformerID로 이미 사용 가능한 곡을 나타낼 수 있습니다. 그렇다면 그것은 3 NF가 아닙니다.

출처

2010-08-03 16:11:46

* "각 일반 양식은 그 앞에 오는 일반 서식이 필요합니다."* 일반적으로 사실이지만 BCNF에는 해당되지 않습니다. BCNF의 현재 정의는 예를 들어 a) 그것이 3NF에 있고 b) (무엇이든) ... BCNF가 BCNF에 있다고 말하지 않습니다. 대신 BCNF는 사소한 종속성과 수퍼 키로 정의됩니다 ] (http://en.wikipedia.org/wiki/Boyce%E2%80%93Codd_normal_form). –

정규화는 개별 테이블에 적용됩니다. 기능 의존성을 기반으로합니다.

기능 종속성은 열 이름이 아니라 데이터에 의해 결정됩니다. 강사가 데이터를 제공하지 않았습니다. 열 이름만으로 함수 종속성을 결정하려고하면 열 이름이 잘 지정 되더라도 위험한 비즈니스입니다. 열의 이름이 잘 지정되지 않았습니다.

상상력이 풍부한 데이터베이스 설계자는 BCNF를 보여주는 첫 번째 "Instruments"테이블에 대한 술어와 샘플 데이터를 제공 할 수 있습니다.

어쩌면 강사가이 내용을 이해하지 못할 수도 있습니다.처음이 아니겠습니까?

출처

2011-01-14 21:17:40

'기능 의존성은 데이터로 결정됩니다'. 나는 조금 뒤로 물러서 고 싶다. 기능 종속성은 일반적으로 비즈니스 규칙을 나타냅니다. 테이블 인스턴스의 데이터를 기반으로 FD를 고안하는 것은 열 이름을 추측하는 것만큼이나 위험합니다. – beldaz

비즈니스 규칙은 "가용성"이 계측기 또는 수행자와 관련이 있는지 여부를 판별 할 수 없습니다. 비즈니스 규칙은 종종 데이터 오해를 나타냅니다. (많은 예제에서 "database-normalization"태그가 붙은 질문을 읽어보십시오.) 그래서 함수 종속성은 컬럼 이름이 아닌 데이터에 의존합니다. 더 구체적으로 말하면 데이터 *가 무엇을 의미하는지에 달려 있습니다. 크리스 데이트 (Chris Date)는 데이터베이스 시스템 소개 (Introduction to Database Systems *)에 대해 약간 썼습니다. –

아, 그게 무슨 뜻입니까? 내가 동의하고, 내 "비즈니스 규칙"(그리고 그렇습니다, 그들은 틀릴 수도 있지만, 나는 _right_ 비즈니스 규칙을 의미했습니다)에 대한 나의 암시였습니다. 요점은 모든 데이터 집합이 완전히 정확하다고 가정했습니다. 일부 후보 FD를 제외하고 몇 가지 후보 FD를 제안하는 데 도움이 될 수 있습니다. – beldaz

BCNF가 아닌 2NF입니다.

INSTRUMENT (InstrumentID, InstrumentType, 조정, 출연자,의 Adr, 전화 번호, 가용성) 당신은 정말 내가 말하고 싶지만 기능 종속성을 알고 있지만 추측을 복용 할 필요가

adr 및 phone 악기가 아닌 연주자의 속성입니다. 속성이 키를 설명하지 않으면 (전체적으로) BCNF가 아 U니다.

각 출연자는 최대 하나의 전화 번호와 주소를 가지고 있다고 가정합니다. 이다

Performer -> phone, adr

이 같은 연예인과 관련된 여러 악기가있을 수 있지만, 각각의 경우에 자신의 휴대 전화 및 주소 (따라서 중복 기록) 같은 것이다 : 그렇다면, 당신은 기능 종속성을 가질 것이다. 악기 관계에 대한 열쇠는 InstrumentId이라고 생각합니다. 따라서 대부분의 연주자가 각 악기와 연결되어 있다는 FD가 있습니다.

InstrumentId -> Performer

경우되고, phone 및 adr이 InstrumentId에 직접 의존하지 않는 속성 그건

하지만 간접적를 통해 Performer. 따라서이 관계 내에서 FD Performer -> phone, adr은 전이 종속성입니다. 정의에 의한 전이 종속성을 포함하는 관계는 2NF (두 번째 정규형)보다 높을 수 없습니다. 그래서 3NF 나 BCNF에는 없습니다.

2NF는 부분 종속성을 허용하지 않습니다. 좋은 소식은 키가 하나의 속성 일 뿐이므로 여기서 부분적인 의존성에 대해 걱정할 필요가 없다는 것입니다. 하나의 속성의 일부만 가질 수는 없습니다.

출처

2013-09-13 06:07:59 beldaz

BCNF로 정상화하려고 시도합니다.

답변

관련 문제