Нужна ли моя таблица в дополнительной нормализации?

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

Я делаю простую общедоступную таблицу БД кассовой книги, чтобы подсчитать, сколько мы с друзьями заплатили за совместную трапезу. Моя первая таблица была всего одной таблицей, и в ней был столбец «человек» с неатомарными значениями, поэтому я разделил свою таблицу на две таблицы, как указано выше.

Но я не уверен, что это достаточно нормализовано. Есть ли какая-либо функциональная зависимость, которую следует нормализовать, но я не знаю о ее существовании?

(Я собираюсь использовать MySql, но вы можете ответить мне любой СУБД.)


person jungyh0218    schedule 01.03.2015    source источник
comment
Я думаю, что плательщик должен быть внешним ключом для человека. Возможно ли, что человек должен торговать одним и тем же блюдом и контентом в один и тот же день?   -  person Jens    schedule 01.03.2015
comment
Я думаю, что моего объяснения было недостаточно. Отношения, которые я хотел выразить, заключались в следующем: «Джон Доу и Джейн Доу вместе пообедали 2 марта 2015 года, и Джон Доу заплатил за это». Так что таблица с #trade и person может иметь двусмысленность. Я думаю создать новую таблицу с «personal_id» и «name» и использовать «personal_id» в качестве внешних ключей. Но... будет ли это хорошей идеей??   -  person jungyh0218    schedule 01.03.2015
comment
Новая таблица с идентификаторами имен не влияет на нормализацию. Нормализация никогда не включает новые столбцы, только старые столбцы в новых таблицах.   -  person philipxy    schedule 02.03.2015
comment
Пожалуйста, отредактируйте полный оператор отношения приложения (предикат) для каждой таблицы в свой вопрос. Также любое объяснение ограничений и незнакомых понятий.   -  person philipxy    schedule 02.03.2015


Ответы (2)


Нормализация требует знания функциональных зависимостей (FD) и зависимостей соединений (FD). Вы их не дали.

Ваше приложение Мы можем сказать вам FD и JD только в том случае, если мы точно знаем, что такое «отношение, которое я хотел выразить» (т.е. предикат) для каждой таблицы (т.е. до такой степени, что мы могли бы посмотреть на ситуацию и знать для каждой возможной строки, составляет ли она истинное предложение из предиката и, следовательно, принадлежит ли она таблице) и какие именно возможные ситуации могут возникнуть (через «бизнес-правила» о возможных ситуациях приложения, эквивалентные ограничениям на возможные состояния базы данных) .

Ваши "ключи" Вы не давали FD. Вы только что дали один ключ-кандидат (CK) и «уникальный ключ». Но вы не можете определить некоторые или все CK, не зная определенных вещей о FD. Поэтому, когда вы даете CK, это то же самое, что говорить, что есть определенные FD, а не они. Вы должны сказать нам, что вы дали нам, когда вы даете некоторые наборы столбцов, помеченные PK или «уникальный ключ»: является ли «уникальный ключ» CK (содержащим не меньшее уникальное подмножество) или просто суперключом (уникальным)? Вы дали все CK или могут быть другие? Могут ли быть другие суперключи, кроме надмножеств данных? Будет очень полезно, если вы просто сообщите нам, какие именно FD, как вы знаете, держат (через минимальное покрытие), а какие, как вы знаете, не держат.

Догадки
Я понятия не имею, для чего нужен is_calculated.
Может быть, данная пара date и meal содержит ровно один content?

TL;DR Вам действительно нужно проверить каждый возможный набор столбцов, чтобы увидеть, определяет ли он функционально каждый другой столбец. Т.е. появляется ли для каждого состояния базы данных подстрока значений для набора столбцов только с одним значением для столбца. Мы можем только догадываться без четкого понимания ваших предикатов и вашего приложения. Вы можете сократить работу следующим образом: если набор столбцов уникален, то его надмножества определяют все остальные столбцы. Если набор столбцов минимально уникален (является CK), то ни одно из его меньших подмножеств не определяет все остальные столбцы. Вы можете найти контрпримеры к предполагаемым FD, где две строки могут иметь одну и ту же подстроку значений для предполагаемого определителя, но иметь разные значения для предполагаемого детерминированного атрибута. Аксиомы Армстронга порождают все ФП, вытекающие из данных.

JD Нормализация до 4NF и 5NF включает разделение таблицы на несколько таблиц для устранения JD, которые не подразумеваются CK. Предикат таблицы может быть выражен как AND других точно тогда, когда JD соответствует наборам столбцов предикатов. Отношение находится в 5NF, когда каждый конъюнкт в каждом JD перекрывает какой-либо другой по крайней мере на CK. (Алгоритм членства Феджина.)

PS Если вас волнуют ограничения, не потеряли ли вы их, когда перешли от одного стола к двум?

person philipxy    schedule 02.03.2015
comment
Я прочитал ваш ответ несколько раз и начал снова с самого начала. Сначала я определил отношения каждой сущности. И после этого я нарисовал ER-диаграмму на основе этого. Наконец-то я смог сделать таблицы на основе диаграммы. Теперь я думаю, что получил результат, который хотел. :) - person jungyh0218; 03.03.2015

Хм, давайте посмотрим, как мы можем его нормализовать:

  1. В таблице 1 мы можем заменить payer на ссылку внешнего ключа на таблицу2.
  2. удалите дубликаты в таблице 2, сделайте ее первичным ключом (позже вы можете использовать ее для индексации)
person Tarun Gaba    schedule 01.03.2015
comment
Ни одно из этих изменений не имеет ничего общего с нормализацией. Normalizaiton заменяет таблицы их проекциями. (Также в комментарии OP говорится, что плательщики не обязательно являются трейдерами, поэтому FK не существует.) - person philipxy; 02.03.2015