little_lillyДобрый день.

Я так понимаю она избыточная?


Для избыточности должны быть как минимум две ф-ии зависимомсти:
транзитиваня зависимость.
Какие видны:
третья колонка ф-но не зависит от второй из-за последних двух записей. Будь там две 2-ки или 1-ци, можно было бы надеяться.
четвертая не зависит от второй из-за значения К. По этой же причине и четвертая не завистит от третьей.
Остальные тоже не зависят от второй. От третьей и четвертой тем более.

Есть завимости всех колонок от первой, и есть зависимость второй, третьей и четвертой от последней. И есть зависимость второй от третьей
Поскоку перая не завист от последней и от третьей, то возможны две транзитивные зависмости.
Т.е. в данном состоянии таблы они есть, но нуно быть уверенным, что и в будующем останутся.
Последняя, это какой-то Count.
Т.е. скорей всего эта зависимость нарушится.
Достотачно, например, чтобы появилась, запись в которой вторая AD, а посленей 55.
Остается второй от третьей.
Однако, как Вам сказали нуно знать про зависмости между данными в реале, чтобы быть уверенными, что зависимости сохраняться во всех состояниях таблы в будующем.
Т.е. если счас разбить на две таблы, а потом зависимость нарушится, то таблы будут не адекватны реалу: в них незя буит занести инфу, которая нарушает зависимость.
Чтобы нарушилась зависимость второй от третьей досстаточно появиться записи, хде
в третье 4 а во второй AD.
Ну так примерно, если нигде ниче не упустил.

MasterZiv
vadiminfo пишет:

Я вот вижу чёткую функциональную зависимость третьей колонки от второй.

В предпоследней записи значение второй колнки AD а третьей 2
а впоследне записи соотвественно AD и 1.
Это нарушает зависмость третьей колонки от второй. Имея во второй значение AD незя сказать что в третьей 1 или 2.
Потому зависмости нет все же.
Вот вторая от третьей в приведенном состоянии дает надежду на ФЗ.

Вот в чем ошибся я так в том, что от первого все зависит, потому что отложилось, что это ID. Но от него ничего не зависит: значение то у него одно и то же. Рефлеск Павлова на ID выработался. Он, наоборот, зависит от любой колонки, в данном состоянии таблы. Либо по ошибке он одинаковый. А на самом деле как и положено ID, должен быть уникальным. Потому если вторая зависит от третьей, то первая транзативно зависит от третьей. (Однако, по прежнему третья не зависит от второй, как думает MasterZiv).


Если что-то не должно повторяться, но повторяется по ошибке, то это, скорее, луче считать не избыточностью, а нарушением логических правил (нарушением целостности данных), которым должны соответсвовать данные. Потому шо это хуже избыточности: последняя тока создает проблемы контроля избыточности и риски потери информации, а первая уже искажение информации: объект один, но воспринимается как несколько разных. Это решается с помощью навязывания ОЦ отношения: ключей, обеспечивающих уникальность.

little_lillyА какая нормальная форма соответствует этой табличке?

Чтобы реално говорить об этом нужно знать предметную область, выявить функциональные зависимости (ФЗ). По текущему состоянию данных БД в табличке, если данные адекватны предметной области, можно тока сказать каких ФЗ уже точно нет. Поскоку те ФЗ что есть в данном состоянии БД могут нарушиться при добавлении новых данных.

Но на скока я понял, возможно, данные не правильные: нарушена целостность данных. Вы там собрались шо-то удалять.
Если данные не адекватны, то речь идет о рассуждениях в условиях неопределенности.

Вообще то, Вы пытаетесь решить обратную задачу (ОЗ): идете не от предметной области (ПО) к табличкам, а наоборот. А ОЗ обычно не корректно поставлены. Если данные в табличке не адекватно отображают предметную область, нарушены ОЦ, которые там должны быть, то даже об отсувующих ФЗ судить сложно.

Если данные меняться не будут, и они правильные, то чисто только по этим данным (без знания про их смысл, ПО) моно сказать в какой форме.
Но поскоку их мало и меняться не будут, то практический эффект от нормализации, скорее всего слишком мал, чтобы на это тратить усилия.

Если данные меняться будут и счас они правильные, то ранее я написал каких ФЗ точно нет, а какие могут быть. Но при добалении данных они могут пропасть. Т.е. есть неопределенность.
Просто незя еще тока по этим данным сказать, что она находится в 3 или даже Бойса Кодда. На 4 и 5 анализировать ломно, но ить обчно далее 3 не идут в силу нескольких причин (возможной неполноты, сложности)
Оптимизация выше третье может содержать неопределенность, либо процесс оптимизации завышенную сложность.

Если данные не правильны, то их луче сначала исправить.

Но лучшее из лучшего пойти от ПО к табличкам. А потом уже смотреть на адеватность, оптимальность.