Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Нормальные формы
|
|||
|---|---|---|---|
|
#18+
Пример-словарь БД (# - 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 можно ввести поле, не принадлежащее индексируемой таблице. Какая нормальная форма здесь нарушена и в чем состоит нарушение? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2004, 15:20 |
|
||
|
Нормальные формы
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Вот вроде и все. У меня связей index и key с table нет вообще ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2004, 16:16 |
|
||
|
Нормальные формы
|
|||
|---|---|---|---|
|
#18+
т.е. на 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2004, 16:21 |
|
||
|
Нормальные формы
|
|||
|---|---|---|---|
|
#18+
Я думаю что нарушена 4 форма, т.к. любой элемент таблицы должен многозначно зависить(->>) от одного любого элемента, т.е. Если атрибут А->>Б, то А функционально зависит от Б и независит от любого другого элемента. А у тя получается, что IDX_NAME зависит от TAB_NAME и COL_NAME антрибутов, что противоречит 4НФ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2004, 16:26 |
|
||
|
Нормальные формы
|
|||
|---|---|---|---|
|
#18+
блин, что-то я сегодня торможу по вашему вопросу - на мой взгляд никакой - т.е. у вас нигде и не сказано что вводить поле от одной таблице а индекс брать от другой У меня есть идея убить relation между key и index и заменить его check'ом что для key у колонок в него входящих index_id равен и не null ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2004, 16:27 |
|
||
|
Нормальные формы
|
|||
|---|---|---|---|
|
#18+
т.е. мы дублируем информацию об индексе и для keys и для idxs! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2004, 16:31 |
|
||
|
Нормальные формы
|
|||
|---|---|---|---|
|
#18+
так - я еще немного подумал 1. между index и column relation 1..*...1..* 2. не надо удалять релайшн - но вот чек добавить придеться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2004, 16:53 |
|
||
|
Нормальные формы
|
|||
|---|---|---|---|
|
#18+
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) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2004, 17:16 |
|
||
|
Нормальные формы
|
|||
|---|---|---|---|
|
#18+
Возможно, ответ где-то здесь, но пока все равно не ясно. Т.е. нарушение лежит выше 3НФ. А что не ясно??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2004, 17:40 |
|
||
|
Нормальные формы
|
|||
|---|---|---|---|
|
#18+
а по моему нарушение 3NF если в Код: plaintext убрать поле TAB_NAME, то будет все нормально Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2004, 11:13 |
|
||
|
Нормальные формы
|
|||
|---|---|---|---|
|
#18+
>убрать поле 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 (это неправильно)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2004, 14:26 |
|
||
|
Нормальные формы
|
|||
|---|---|---|---|
|
#18+
а по моему нарушение 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 и в нем отстутсвуют многозначные зависимости, не являющиеся функциональными зависимостями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2004, 15:11 |
|
||
|
Нормальные формы
|
|||
|---|---|---|---|
|
#18+
* 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НФ.... З.Ы. И вообще автор не спрашивал, как правильно сделать(я думаю он уже и сам додумался), а спросил четко - "Какая нормальная форма здесь нарушена и в чем состоит нарушение?". Так и отвечайте на вопорс, плз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2004, 15:23 |
|
||
|
Нормальные формы
|
|||
|---|---|---|---|
|
#18+
Нарушение первой нормальной формы, вернее алгоритма приведения к первой нормальной форме Код: plaintext 1. 2. 3. 4. 5. 6. 7. авторАлгоритм нормализации описан Е.Ф.Коддом следующим образом: Начиная с отношения, находящегося на верху дерева (рис. 4.3.), берется его первичный ключ, и каждое непосредственно подчиненное отношение расширяется путем вставки домена или комбинации доменов этого первичного ключа. Первичный Ключ каждого расширенного таким образом отношения состоит из Первичного Ключа, который был у этого отношения до расширения и добавленного Первичного Ключа родительского отношения. После этого из родительского отношения вычеркиваются все непростые домены, удаляется верхний узел дерева, и эта же процедура повторяется для каждого из оставшихся поддеревьев. оригинал статьи лежит в http://www.mstu.edu.ru/education/materials/zelenkov/ch_4_2.html Нарушение - при построении первичного ключа для IDXS. Действительно должно быть #IDX_NAME, #TAB_NAME (вернее даже #TAB_NAME, #IDX_NAME). А уж уникальность имени индекса (если она нужна в глобальном плане, а не в пределах таблицы) - отдельным ограничением. Но автор наверное сам догадался :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2004, 17:42 |
|
||
|
Нормальные формы
|
|||
|---|---|---|---|
|
#18+
Однако просьба меня не пинать, я сам не верю в то, что написал ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2004, 17:53 |
|
||
|
Нормальные формы
|
|||
|---|---|---|---|
|
#18+
Лох Позорный Зачем нужна связь между idxs и tabs??? PS> эх - зря вы на мой вариант забили... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2004, 18:09 |
|
||
|
Нормальные формы
|
|||
|---|---|---|---|
|
#18+
Однако просьба меня не пинать, я сам не верю в то, что написал Вот это ближе к делу... Т.к. первая НФ, гласит что все атрибуты должны быть скалярными. Вы не правы. СТАТЬЯ Для обсуждения первой нормальной формы необходимо дать два определения: Простой атрибут - атрибут, значения которого атомарны (неделимы). Сложный атрибут - получается соединением нескольких атомарных атрибутов, которые могут быть определены на одном или разных доменах. (его также называют вектор или агрегат данных). Теперь можно дать Определение первой нормальной формы: отношение находится в 1NF если значения всех его атрибутов атомарны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2004, 18:22 |
|
||
|
Нормальные формы
|
|||
|---|---|---|---|
|
#18+
PS> эх - зря вы на мой вариант забили... :) Да не забили мы на твой вариант, просто вопрос у автора был другой: Какая нормальная форма здесь нарушена и в чем состоит нарушение? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2004, 18:24 |
|
||
|
Нормальные формы
|
|||
|---|---|---|---|
|
#18+
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НФ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2004, 19:51 |
|
||
|
Нормальные формы
|
|||
|---|---|---|---|
|
#18+
Быть может осознаю, тогда и не буду фигню всякую писать. Как осознаете, так заходите.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2004, 11:43 |
|
||
|
Нормальные формы
|
|||
|---|---|---|---|
|
#18+
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НФ и речи быть не может) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2004, 12:48 |
|
||
|
Нормальные формы
|
|||
|---|---|---|---|
|
#18+
Упс. Откат. Зависимость IDX_NAME -> TAB_NAME будет функциональной только если в IDXS первичный ключ составной (и связь c KEYS по двум полям). Ну так в этом случае все нормально. То, как в условии задачи описано - да, нарушение 4НФ. долго же я пробуксовывал ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2004, 13:02 |
|
||
|
Нормальные формы
|
|||
|---|---|---|---|
|
#18+
УРА, НАКОНЕЦ-ТО, А ТО Я УЖЕ ХОТЕЛ МАТОМ РУГАТЬСЯ.... Просто пример, кот. я привел для определения 4НФ в точности соответсвует пост. задачи. З.Ы. Только не обижайся, я по доброму, сам иногда торможу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2004, 14:06 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=173&tid=1546643]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
36ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
69ms |
get tp. blocked users: |
2ms |
| others: | 12ms |
| total: | 166ms |

| 0 / 0 |
