Ключ-кандидат на понимание 2-й нормальной формы

Чтобы понять, что такое вторая нормальная форма, я читал некоторые статьи, и есть некоторые вещи, которые я не понимаю.

В статье здесь в таблице customer написано, что он не во 2NF, потому что there are several attributes which don’t completely rely on the entire Customer table primary key. Здесь первичный ключ, я думаю, означает {customerId,EmployeeId}

введите здесь описание изображения

Если мы выберем {customerId,employeeId} в качестве ключа-кандидата, то верно, что Customername,customerCity,PostalCode только частично зависит от ключа-кандидата и, следовательно, не во 2NF. Но если мы считаем, что потенциальным ключом является только идентификатор клиента, тогда все столбцы в таблице клиентов полностью зависят от идентификатора клиента, верно? (Поскольку идентификатор сотрудника зависит от идентификатора клиента). ключ-кандидат, мы можем иметь {CustomerId,EmployeeId} в качестве ключа-кандидата, потому что ключ-кандидат не может содержать другой ключ-кандидат как его часть.

Поэтому, если мы возьмем только идентификатор клиента в качестве ключа-кандидата, не является ли эта таблица формой 2NF?
но затем в статье говорится, что таблица a в форме 2NF должна служить одной цели, а здесь эта таблица клиентов служит двум целям.< br> To indicate which customers are called upon by each employee To identify customers and their locations.
Тогда я чувствую, что эта таблица не находится во 2NF.
Итак, какой ключ-кандидат в этой таблице?

Мой второй вопрос содержится в этой статье.

введите здесь описание изображения

эти таблицы находятся в 3NF. В таблице TABLE_BOOK ключевым ключом-кандидатом является bookId, верно? Мы не можем выбрать {bookId,genereId} в качестве ключа-кандидата, верно? Если выбрано, это не будет во 2NF, поскольку цена не зависит от жанраId.

Может кто-нибудь, пожалуйста, помогите мне лучше понять эту теорию нормализации


database database-normalization normalization candidate-key
person sam_rox    schedule 07.12.2014    source источник
comment
FD определяют CK. Вы не можете выбирать CK. CK — это наборы столбцов, которые определяют все остальные столбцы. Вы выбираете критерий размещения строк в таблице. Тогда, учитывая все ситуации, которые могут возникнуть, каждое подмножество столбцов (нетривиально) определяет 0 или более столбцов, т.е. есть или нет FD из набора в столбец.   -  person philipxy    schedule 15.12.2014
comment
Эти статьи некомпетентны. Каким учебником вы пользуетесь?   -  person philipxy    schedule 16.12.2014

Ответы (1)


arrow_upward
4
arrow_downward

Оба ваших вопроса демонстрируют ограничения подобных упражнений. Вы не сможете создать эффективную структуру базы данных или применить принципы нормализации, если не знаете или не можете заранее определить соответствующие бизнес-правила. В реальной ситуации проектирования базы данных вы можете определить бизнес-правила, опросив экспертов в предметной области и изучив существующие системы и процессы. В наброске примера на веб-сайте все, что вам нужно, — это несколько строк образцов данных и некоторые, возможно, неоднозначные имена для атрибутов и таблиц. Решения, полученные таким образом, обязательно гипотетичны, часто неточны и субъективны.

В первом случае вы правы в том, что если бы CustomerID был единственным ключом-кандидатом в таблице Customer, тогда он удовлетворял бы 2NF. Однако в этом случае для каждого CustomerID может быть только один EmployeeID, другими словами: CustomerID->EmployeeID. Я полагаю, что смысл этого примера в том, что более одного сотрудника могут продавать одному и тому же клиенту, и поэтому одного CustomerID будет недостаточно в качестве ключа-кандидата, если EmployeeID будет включен в ту же таблицу. Это не то, что показано в примере данных, но подразумевается тем фактом, что {CustomerID, EmployeeID} указан как ключ этой таблицы, а не только CustomerID.

Второй пример очень похож на первый. Выбор BookID в качестве ключа означает, что каждая книга, идентифицируемая BookID, может иметь только один GenreID и одну связанную с ней цену: BookID->GenreID, BookID->Price. Если вы определили {BookID, GenreID} в качестве ключа, то зависимости BookID->GenreID, BookID->Price больше не будут применяться, поскольку таблица допускает несколько жанров и несколько цен на книгу. Это было бы нарушением 2NF в отношении зависимости BookID->Price.

person nvogel    schedule 13.12.2014