powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Нормальные формы
24 сообщений из 24, страница 1 из 1
Нормальные формы
    #32392471
*
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
*
Гость
Пример-словарь БД (# - PK, несущественные атрибуты не указаны):

TABS(#TAB_NAME) -- таблицы
COLS(#TAB_NAME, #COL_NAME) -- поля
IDXS(#IDX_NAME, TAB_NAME) -- индексы
KEYS(IDX_NAME, TAB_NAME, COL_NAME) -- поля индексов

Имеются ссылки KEYS на IDXS (IDX_NAME) и COLS (TAB_NAME, COL_NAME).
Конструкция содержить дефект - в KEYS можно ввести поле, не принадлежащее индексируемой таблице.

Какая нормальная форма здесь нарушена и в чем состоит нарушение?
...
Рейтинг: 0 / 0
Нормальные формы
    #32392560
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
table (table_id,...)
column(column_id,...)

key(key_id,...)
index (index_id,...)

связи
 table  1 .. 1   ---- column 1..*
 
 column  1 ..*  ---- index 1..1
 
 column  1 ..*  ---- key 1..1
 
 key  1 .. 1   ---- index 1..1
 



Вот вроде и все. У меня связей index и key с table нет вообще
...
Рейтинг: 0 / 0
Нормальные формы
    #32392568
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
т.е. на SQL это будет

Код: plaintext
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.
create table  "table"  (
    "table"               int                  not null,
   constraint PK_TABLE primary key  ( "table" )
)
go

create table  "column"  (
   column_id            int                  not null,
   index_id             int                  not null,
    "table"               int                  not null,
   key_id               int                  not null,
   constraint PK_COLUMN primary key  (column_id)
)
go

create table  "index"  (
   index_id             int                  not null,
   constraint PK_INDEX primary key  (index_id)
)
go

create table  "key"  (
   key_id               int                  not null,
   index_id             int                  not null,
   constraint PK_KEY primary key  (key_id)
)
go
...
Рейтинг: 0 / 0
Нормальные формы
    #32392581
bas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я думаю что нарушена 4 форма, т.к. любой элемент таблицы должен многозначно зависить(->>) от одного любого элемента, т.е. Если атрибут
А->>Б, то А функционально зависит от Б и независит от любого другого элемента.

А у тя получается, что IDX_NAME зависит от TAB_NAME и COL_NAME антрибутов, что противоречит 4НФ.
...
Рейтинг: 0 / 0
Нормальные формы
    #32392583
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
блин, что-то я сегодня торможу

по вашему вопросу - на мой взгляд никакой - т.е. у вас нигде и не сказано что вводить поле от одной таблице а индекс брать от другой

У меня есть идея убить relation между key и index и заменить его check'ом что
для key у колонок в него входящих index_id равен и не null
...
Рейтинг: 0 / 0
Нормальные формы
    #32392589
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
т.е. мы дублируем информацию об индексе и для keys и для idxs!
...
Рейтинг: 0 / 0
Нормальные формы
    #32392616
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
так - я еще немного подумал

1. между index и column relation 1..*...1..*

2. не надо удалять релайшн - но вот чек добавить придеться
...
Рейтинг: 0 / 0
Нормальные формы
    #32392644
*
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
*
Гость
bas>получается, что IDX_NAME зависит от TAB_NAME и COL_NAME антрибутов, что противоречит 4НФ.

Возможно, ответ где-то здесь, но пока все равно не ясно. Т.е. нарушение лежит выше 3НФ.

Одно уточнение. Дефект, о котором я говорил, устранится, если сделать избыточный PK в IDXS (#TAB_NAME, #IDX_NAME) и изменить ссылку ссылку KEYS на IDXS (TAB_NAME, IDX_NAME), ссылка на COLS остается неизменной (TAB_NAME, COL_NAME).

И, если я неаккуратно выразился, подразумевалось наличие связей между IDXS и TABS (TAB_NAME) и между COLS и TABS (TAB_NAME). О PK KEYS я сознательно умолчал, он может быть например (IDX_NAME, COL_NAME)
...
Рейтинг: 0 / 0
Нормальные формы
    #32392689
bas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Возможно, ответ где-то здесь, но пока все равно не ясно. Т.е. нарушение лежит выше 3НФ.

А что не ясно???
...
Рейтинг: 0 / 0
Нормальные формы
    #32393314
Читатель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а по моему нарушение 3NF

если в
Код: plaintext
KEYS(IDX_NAME, TAB_NAME, COL_NAME) -- поля индексов 

убрать поле TAB_NAME, то будет все нормально
Код: plaintext
KEYS(IDX_NAME, COL_NAME) -- поля индексов 
...
Рейтинг: 0 / 0
Нормальные формы
    #32393768
*
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
*
Гость
>убрать поле TAB_NAME, то будет все нормально

Думаю, что это неправильно. Если сделать так, то можно будет ввести в индекс поле, которого нет в таблице (ссылку на COLS придется ведь убрать)

bas>А у тя получается, что IDX_NAME зависит от TAB_NAME и COL_NAME антрибутов, что противоречит 4НФ.

Можно ли сказать обратное: IDX_NAME определяет список полей (т.е. список пар (TAB_NAME, COL_NAME)) и, кроме того, определяет список таблиц (TAB_NAME). Т.е. (TAB_NAME, COL_NAME) многозначно зависит от IDX_NAME (и это правильно) и TAB_NAME многозначно зависит от IDX_NAME (это неправильно)?
...
Рейтинг: 0 / 0
Нормальные формы
    #32393885
bas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а по моему нарушение 3NF

если в
KEYS(IDX_NAME, TAB_NAME, COL_NAME) -- поля индексов



убрать поле TAB_NAME, то будет все нормально
KEYS(IDX_NAME, COL_NAME) -- поля индексов



Это и есть как раз 4 НФ, т.к. в 3НФ идет речь о не ключевых полях, а в 4НФ про любое сочеиание полей....

Вот определения

3НФ
Перед обсуждением третьей нормальной формы необходимо ввести понятие транзитивной функциональной зависимости.
Определение:

Пусть X, Y, Z - три атрибута некоторого отношения. При этом X --> Y и Y --> Z, но обратное
соответствие отсутствует, т.е. Z -/-> Y и Y -/-> X. Тогда Z транзитивно зависит от X.

Пусть имеется отношение ХРАНЕНИЕ (ФИРМА, СКЛАД, ОБЪЕМ), которое содержит информацию о фирмах, получающих товары со складов, и объемах этих складов. Ключевой атрибут - "фирма". Если каждая фирма может получать товар только с одного склада, то в данном отношении имеются следующие функциональные зависимости:

фирма -> склад
склад -> объем
При этом возникают аномалии:
если в данный момент ни одна фирма не получает товар со склада, то в базу данных нельзя ввести данные о его объеме (т.к. не определен ключевой атрибут)
если объем склада изменяется, необходим просмотр всего отношения и изменение кортежей для всех фирм, связанных с данным складом.
Для устранения этих аномалий необходимо декомпозировать исходное отношение на два:
ХРАНЕНИЕ (ФИРМА, СКЛАД)
ОБЪЕМ_СКЛАДА (СКЛАД, ОБЪЕМ)
Определение третьей нормальной формы:
Отношение находится в 3НФ, если оно находится во 2НФ и каждый неключевой атрибут нетранзитивно зависит от первичного ключа.

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

В качестве примера рассмотрим отношение ПРЕПОДАВАТЕЛЬ (ИМЯ, КУРС, УЧЕБНОЕ_ПОСОБИЕ), хранящее сведения о курсах, читаемых преодавателем, и написанных им учебниках. Пусть профессор N читает курсы "Теория упругости" и "Теория колебаний" и имеет соответствующие учебные пособия, а профессор K читает курс "Теория удара" и является автором учебников "Теория удара" и "Теоретическая механика". Тогда наше отношение будет иметь вид:

----------------------------------------------------
| ИМЯ | КУРС | УЧЕБНОЕ_ПОСОБИЕ |
----------------------------------------------------
| N | Теория упругости | Теория упругости |
| N | Теория колебаний | Теория упругости |
| N | Теория упругости | Теория колебаний |
| N | Теория колебаний | Теория колебаний |
| K | Теория удара | Теория удара |
| K | Теория удара | Теоретическая механика |
----------------------------------------------------
добавляем:
----------------------------------------------------
| K | Теория упругости | Теория удара |
| K | Теория упругости | Теоретическая механика |
----------------------------------------------------
Это отношение имеет значительную избыточность и его использование приводит к возникновению аномалии обновления. Например, добавление информации о том, что профессор K будет также читать лекции по курсу "Теория упругости" приводит к необходимости добавить два кортежа (по одному для каждого написанного им учебника) вместо одного. Тем не менее, отношение ПРЕПОДАВАТЕЛЬ находится в NFBC (ключевой атрибут - ИМЯ).
Заметим, что указанные аномалии исчезают при замене отношения ПРЕПОДАВАТЕЛЬ его проекциями:

--------------------------- -------------------------------
| ИМЯ | КУРС | | ИМЯ | УЧЕБНОЕ_ПОСОБИЕ |
--------------------------- -------------------------------
| N | Теория упругости | | N |Теория упругости |
| N | Теория колебаний | | N |Теория колебаний |
| K | Теория удара | | K |Теоретическая механика |
| K | Теория упругости | | K |Теория удара |
--------------------------- -------------------------------
Аномалия обновления возникает в данном случае потому, что в отношении ПРЕПОДАВАТЕЛЬ имеются:
зависимость множества значений атрибута КУРС от множества значений атрибута ИМЯ
зависимость множества значений атрибута УЧЕБНОЕ_ПОСОБИЕ от множества значений атрибута ИМЯ.
Такие зависимости и называются многозначными и обозначаются как

ИМЯ ->> КУРС ИМЯ ->> УЧЕБНОЕ_ПОСОБИЕ
Нетрудно показать, что многозначные зависимости всегда образуют связанные пары, поэтому их часто обозначают
ИМЯ ->> КУРС | УЧЕБНОЕ_ПОСОБИЕ
Очевидно, что каждая функциональная зависимость является многозначной, но не каждая многозначная зависимость является функциональной.
Определение четвертой нормальной формы:

Отношение находится в 4NF если оно находится в BCNF и в нем отстутсвуют многозначные зависимости, не являющиеся функциональными зависимостями.
...
Рейтинг: 0 / 0
Нормальные формы
    #32393921
bas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
*
bas>А у тя получается, что IDX_NAME зависит от TAB_NAME и COL_NAME антрибутов, что противоречит 4НФ.

Можно ли сказать обратное: IDX_NAME определяет список полей (т.е. список пар (TAB_NAME, COL_NAME)) и, кроме того, определяет список таблиц (TAB_NAME). Т.е. (TAB_NAME, COL_NAME) многозначно зависит от IDX_NAME (и это правильно) и TAB_NAME многозначно зависит от IDX_NAME (это неправильно)?


*, да я что-то перемудрил... Но все ровно я прав на счет 4 НФ, Это видно из моего пред. постинга(просто в разных книгах немного по разному написану, но смысл особенно не оличается). В общем из пред. постинга получается, что IDX_NAME ->> TAB_NAME|COL_NAME, А ИМЕННО ЭТО ПРОТИВОРЕЧИТ 4НФ....

Так, что не 3НФ, а 4НФ....

З.Ы. И вообще автор не спрашивал, как правильно сделать(я думаю он уже и сам додумался), а спросил четко - "Какая нормальная форма здесь нарушена и в чем состоит нарушение?". Так и отвечайте на вопорс, плз.
...
Рейтинг: 0 / 0
Нормальные формы
    #32394170
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Нарушение первой нормальной формы, вернее алгоритма приведения к первой нормальной форме

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
                       Table
                         |
            + ------------+---------------+
 
            |                            |
          Index                       Column
            |                            |
            +---------->Keys<------------+


авторАлгоритм нормализации описан Е.Ф.Коддом следующим образом:
Начиная с отношения, находящегося на верху дерева (рис. 4.3.), берется его первичный ключ, и каждое непосредственно подчиненное отношение расширяется путем вставки домена или комбинации доменов этого первичного ключа.

Первичный Ключ каждого расширенного таким образом отношения состоит из Первичного Ключа, который был у этого отношения до расширения и добавленного Первичного Ключа родительского отношения.

После этого из родительского отношения вычеркиваются все непростые домены, удаляется верхний узел дерева, и эта же процедура повторяется для каждого из оставшихся поддеревьев.


оригинал статьи лежит в http://www.mstu.edu.ru/education/materials/zelenkov/ch_4_2.html

Нарушение - при построении первичного ключа для IDXS. Действительно должно быть #IDX_NAME, #TAB_NAME (вернее даже #TAB_NAME, #IDX_NAME). А уж уникальность имени индекса (если она нужна в глобальном плане, а не в пределах таблицы) - отдельным ограничением.
Но автор наверное сам догадался :)
...
Рейтинг: 0 / 0
Нормальные формы
    #32394177
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Однако просьба меня не пинать, я сам не верю в то, что написал
...
Рейтинг: 0 / 0
Нормальные формы
    #32394193
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Лох Позорный

Зачем нужна связь между idxs и tabs???

PS>
эх - зря вы на мой вариант забили... :)
...
Рейтинг: 0 / 0
Нормальные формы
    #32394207
bas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Однако просьба меня не пинать, я сам не верю в то, что написал


Вот это ближе к делу... Т.к. первая НФ, гласит что все атрибуты должны быть скалярными. Вы не правы.

СТАТЬЯ
Для обсуждения первой нормальной формы необходимо дать два определения:
Простой атрибут - атрибут, значения которого атомарны (неделимы).

Сложный атрибут - получается соединением нескольких атомарных атрибутов, которые могут быть определены на одном или разных доменах. (его также называют вектор или агрегат данных).

Теперь можно дать



Определение первой нормальной формы:

отношение находится в 1NF если значения всех его атрибутов атомарны.
...
Рейтинг: 0 / 0
Нормальные формы
    #32394209
bas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PS>
эх - зря вы на мой вариант забили... :)


Да не забили мы на твой вариант, просто вопрос у автора был другой: Какая нормальная форма здесь нарушена и в чем состоит нарушение?
...
Рейтинг: 0 / 0
Нормальные формы
    #32394265
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 funikovyuri
Зачем нужна связь между idxs и tabs???
Учимся читать внимательно
автор вопроса писалИ, если я неаккуратно выразился, подразумевалось наличие связей между IDXS и TABS (TAB_NAME) и между COLS и TABS (TAB_NAME)

2 bas
Можно обойтись без лишних цитат, все равно одну статью используем :)

Я не спорю, что вроде как аттрибуты все атомарные, и, стало быть, 1НФ имеет место быть. Это с одной стороны.
С другой стороны я пока торможу и не осознаю нарушений 4НФ или 5НФ. Быть может осознаю, тогда и не буду фигню всякую писать.
С третьей стороны я вижу расходения между результатами приведения к 1НФ "по Кодду" и "по Звездочке"
С четвертой стороны при нормализации "по Кодду" дефектов нет, а при нормализации по "Звездочке" есть.

Собирая воедино 2, 3 и 4 - я начинаю сомневаться в том, что верно 1.
Вот сижу и гадаю - толи я 1НФ понимаю неправильно , толи безудержно торможу и до сих пор не вижу нарушений 4НФ.
Пойду еще раз читать определения 4НФ и 5НФ
...
Рейтинг: 0 / 0
Нормальные формы
    #32395082
bas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Быть может осознаю, тогда и не буду фигню всякую писать.


Как осознаете, так заходите....
...
Рейтинг: 0 / 0
Нормальные формы
    #32395208
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
basIDX_NAME ->> TAB_NAME|COL_NAME, А ИМЕННО ЭТО ПРОТИВОРЕЧИТ 4НФ....
статьяОтношение находится в 4NF если оно находится в BCNF и в нем отстутсвуют многозначные зависимости, не являющиеся функциональными зависимостями
Однако зависимость IDX_NAME -> TAB_NAME самая что ни на есть функциональная

И давайте все таки определимся с первичными ключами в таблице KEYS. Если, как предложил Звездочка, " О PK KEYS я сознательно умолчал, он может быть например (IDX_NAME, COL_NAME) ", то имеем зависимость ключевого поля (COL_NAME) от неключевого аттрибута (TABLE_NAME) и как минимум нарушение условия для нормальной формы Бойса-Кодда (а стало быть ни о какой 4НФ и речи быть не может)
...
Рейтинг: 0 / 0
Нормальные формы
    #32395233
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Упс. Откат. Зависимость IDX_NAME -> TAB_NAME будет функциональной только если в IDXS первичный ключ составной (и связь c KEYS по двум полям). Ну так в этом случае все нормально.
То, как в условии задачи описано - да, нарушение 4НФ.
долго же я пробуксовывал
...
Рейтинг: 0 / 0
Нормальные формы
    #32395364
bas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
УРА, НАКОНЕЦ-ТО, А ТО Я УЖЕ ХОТЕЛ МАТОМ РУГАТЬСЯ....
Просто пример, кот. я привел для определения 4НФ в точности соответсвует пост. задачи.

З.Ы. Только не обижайся, я по доброму, сам иногда торможу
...
Рейтинг: 0 / 0
Нормальные формы
    #32395404
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да просто у меня в голове сидела "правильная" схема (с составным ключом и прочее), и я постоянно на нее переключался
...
Рейтинг: 0 / 0
24 сообщений из 24, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Нормальные формы
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]