Задача для Мастеров реляционных баз данных.

← →
Soft (2003-09-13 17:20) [0]

Здесь описана 5 нормальная форма реляционной зависимости:
http://www.vsma.ac.ru/~pharm/library/books/db/ch_4_2.html#4_2_7

До сих пор мы предполагали, что единственной операцией, необходимой для устранения избыточности в отношении, была декомпозиция его на две проекции. Однако, существуют отношения, для которых нельзя выполнить декомпозицию без потерь на две проекции, но которые можно подвергнуть декомпозиции без потерь на три (или более) проекций. Этот факт получил название зависимости по соединению, а такие отношения называют 3-декомпозируемые отношения (ясно, что любое отношение можно назвать "n-декомпозируемым", где n >= 2).

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

Отношение находится в 5НФ тогда и только тогда, когда любая зависимость по соединению в нем определяется только его возможными ключами.

Другими словами, каждая проекция такого отношения содержит не менее одного возможного ключа и не менее одного неключевого атрибута.

Считается, что это только теоретическая форма зависимости, реально не применяющаяся. Можете привести пример базы, в корой зависимости отображаются в классе 5НФ?

← →
pasha_golub (2003-09-13 20:16) [1]

Это далеко не тоеоретическая форма. Просто до нее редко доходит. Пример http://www.partmotor.com/psites/delphikmb/Temporary_Pages/_normalization.htm

Последний абзац посмотри. Более того теоретически рассматривабтся 6НФ и 7НФ, правда кроме упоминания о них, более полной инфы я нигде не нашел

← →
[NIKEL] (2003-09-13 22:52) [2]

все формы выше третьей ненужны, это очень спорный вопрос на самом деле... после участия в некоторых проектах, я полностью откозался от "NOT NULL" и вторичных ключей и вообще исключаю всяких жестких ссылок...

... если бы все юзеры знали б SQL ...

← →
Zacho (2003-09-13 23:13) [3]

>
> [NIKEL] © (13.09.03 22:52) [2]
> после участия в некоторых проектах, я полностью
> откозался от "NOT NULL" и вторичных ключей

А мой опыт говорит об обратном - лучше все поля делать NOT NULL, проблем в дальнейшем гораздо меньше будет.
И что такое в твоем понимании "вторичные ключи" ? У меня есть только два предположения - либо это потенциальные ключи (обычно на них накладывается constraint unique), либо внешние ключи (foreign keys). Опять же, исходя из собственного (и не только) опыта (не говоря уже о теории) могу утверждать, что отказ от них принесет множество проблем.

← →
Zacho (2003-09-14 00:08) [4]

> [NIKEL] © (13.09.03 22:52) [2]
>я полностью
> откозался от "NOT NULL"

Тут подумалось: а ведь эта фраза означает, что ты и от первичных ключей отказался. Тогда могу тебя поздравить: ты вступил на непаханное поле подводных граблей :))

← →
[NIKEL] (2003-09-14 01:02) [5]

А мой опыт говорит об обратном - лучше все поля делать NOT NULL, проблем в дальнейшем гораздо меньше будет.

например?
И что такое в твоем понимании "вторичные ключи" ?
конечно же foreign keys
могу утверждать, что отказ от них принесет множество проблем
каких проблем?

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

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

В книжных моделях здорово описываются и смотрятся БД, все там класно, все между собой здорово стыкуется, все связно и однозначно, черезвычайно стройно... но на практике многое не катит, и тут нет дела до опыта проектировщика. Просто всегда надо думать о будущем, многое будет изменяться в БД, что-то надо будет добавить, что-то убрать... и тут очень важно, что бы все компоненты БД были как можно меньше связаны между собой, как можно меньше "NOT NULL", "foreign keys" и PK

... если бы все юзеры знали SQL ...

← →
Zacho (2003-09-14 01:36) [6]

> [NIKEL] © (14.09.03 01:02) [5]
> например?

Извени, но набивать как минимум килобайт текста - ломы. У нас уже 5-й час утра, спать хочется :)

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

А я на самом деле просто прикалывался. И сильно удивлен, что случайно попал в цель :)

> Но, как ни странно ты прав, я откозался от примари кей,
> и довольно давно... вместо него я использую unique

СУБД какая ? Вообще-то unique constraint обычно то же самое, что и потенциальный ключ. Надеюсь, объяснять, что такое потенциальные ключи и первичный ключ не надо ? Без обид, просто думаю что ты и сам это знаешь.

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

Может быть, реляционная теория - это не догма, в реальной жизни всякое быват. Но мой опыт говорит об обратном.

> . Просто всегда надо думать о будущем, многое будет изменяться
> в БД, что-то надо будет добавить, что-то убрать... и тут
> очень важно, что бы все компоненты БД были как можно меньше
> связаны между собой, как можно меньше "NOT NULL", "foreign
> keys" и PK

Не согласен. Категорически. Исходя, опять же, из собственного опыта.

> ... если бы все юзеры знали SQL ...

То для разработчиков/DBA и т.п. жизнь стала бы кошмаром. :) Или =8-()

← →
[NIKEL] (2003-09-14 02:18) [7]

Вообще-то unique constraint обычно то же самое, что и потенциальный ключ да нет, не то же самое.
переиндексировать PK ты не сможешь...
и я не вижу прямой\косвенной связи потенциального ключа и unique constraint, я не обижаюсь :)

То для разработчиков/DBA и т.п. жизнь стала бы кошмаром. :) Или =8-()

нет, тогда бы (на примере InterBase) я всем раздал isql, и вот в этом случае я бы "реально" использовал бы роли,views,FK,NOT NULL и прочее... и пускай тока попробуют сделать что-то не так.

← →
Zacho (2003-09-14 02:29) [8]

> [NIKEL] © (14.09.03 02:18) [7]
> ключ да нет, не то же самое.
> переиндексировать PK ты не сможешь...
> и я не вижу прямой\косвенной связи потенциального ключа
> и unique constraint, я не обижаюсь :)

А для меня - тоже самое (хотя это и спорно, согласен). И переиндексировать смогу, только зачем ? Мне кажется, что именно в этом вопросе мы просто друг друга не понимаем, и говорим о разных вещах.

> нет, тогда бы (на примере InterBase) я всем раздал isql,
> и вот в этом случае я бы "реально" использовал бы роли,views,FK,NOT
> NULL и прочее... и пускай тока попробуют сделать что-то
> не так.

А я и так все это реально использую (кроме ролей, у меня другая модель user security), и не у одного из моих юзеров нет isql :)

← →
[NIKEL] (2003-09-14 03:20) [9]

И переиндексировать смогу, только зачем ?
и как ты сможешь переиндексировать PK? просвети пожалуйста...

← →
Zacho (2003-09-14 03:49) [10]

> [NIKEL] © (14.09.03 03:20) [9]

Так же, как любой индекс. Но только нафига его переиндексировать ??? За 5 лет работы с IB такое мне понадобилось только 1 раз - после падения сервера, и восстановления базы из запоротого бэкапа.

← →
Zacho (2003-09-14 04:15) [11]

2 [NIKEL] ©
Вот ты меня просвети: нафига вообще нужно что-то там переиндексировать, и какое отношение переиндексация имеет к нормализации ?
Ты случаем не с Парадоксом работаешь, где разрушение индексов - привычное явление ?

← →
Petr V. Abramov (2003-09-14 15:17) [12]

Все FK и not null - дополнительный уровень защиты ДАННЫХ от кривого кода приложения. И при чем тут "что-то может поменяться" - непонятно, ведь все constraint`ы прозрачны для приложения, их можно в любой момент ( по-хорошему, совпадающий с моментом перестройки структуры) включить/выключить удалить/добавить.
Другой вопрос, что многие СУБД поддерживают их проверку только в момент вставки/изменения/удаления записи, а не commit`а, что не всегда удобно, может быть, именно поэтому некоторые любители крайностей от них отказываются вообще.

← →
MsGuns (2003-09-14 21:17) [13]

>Petr V. Abramov © (14.09.03 15:17) [12]
Все FK и not null - дополнительный уровень защиты ДАННЫХ от кривого кода приложения

Это очень жесткие рамки БД. Ради надежности и скорости (второе сомнительно) приносится в жертву гибкость и масштабируемость базы. Путь, ИМХО, в тупик. Применим для маломерных замкнутых систем, но не для "живых" развивающихся моделей.

← →
Petr V. Abramov (2003-09-14 21:28) [14]

> MSGuns [13]
Ну и как же это гибкость и масштабируемость связана с not null и отсутствием FK или PK или UK??? :))
То есть самые гибкое и масштабируемое приложение по идее должно использовать формат dbaseN, который все эту ерунду не поддерживает? :))
А вот скорость даже снижается, на проверку constraint`ов время тратится, только это окупается тем, что вероятность "развала" базы снижается и ошибки проявляются не через год, когда что-то "не бьется". ( Ситуацию с использованием Pidarox не берем :)

← →
[NIKEL] (2003-09-15 05:23) [15]

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

большинство ошибок надо предусмотреть на этапе проектирования

← →
Sergey13 (2003-09-15 09:11) [16]

2Petr V. Abramov © (14.09.03 21:28) [14]
> Ну и как же это гибкость и масштабируемость связана с not null и отсутствием FK или PK или UK??? :))
Да очень просто. Когда есть маленькая база на 1-2 клиентов, легко можно уследить за "виртуальными констрентами" из этих клиентов. В крайнем случае обновить целостность (переиндексация например). С ростом числа клиентов и связей в базе уследить за всем этим хозяйством становится практически невозможно. А причин для нарушения целостности (даже при "правильном" софте) дофига. Самое банальное - отключение питания при незаконченой транзакции.

> То есть самые гибкое и масштабируемое приложение по идее должно использовать формат dbaseN, который все эту ерунду не поддерживает? :))
Смешно. 8-) Но это формат файлов а не СУБД в чистом виде.

> А вот скорость даже снижается, на проверку constraint`ов время тратится, только это окупается тем, что вероятность "развала" базы снижается и ошибки проявляются не через год, когда что-то "не бьется".
От "развала" на 100% конечно никто не застрахован. Но при наличии нормальных констрейнтов ты можешь сасм себе сказать - я все сделал, что бы этого не произошло.

2[NIKEL] © (15.09.03 05:23) [15]
>после участия в некоторых проектах, я полностью откозался от "NOT NULL" и вторичных ключей и вообще исключаю всяких жестких ссылок...
Поподробнее, плиз. Что за проекты? И в чем причины отказа?

>большинство ошибок надо предусмотреть на этапе проектирования
Ты меня извини, но ты их делаешь, причем очень серьезные, да еще хвастаешься этим.

← →
Danilka (2003-09-15 10:14) [17]

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

Но, кроме этих "злых гениев", аналогичная проблема может возникнуть и среди разработчиков, когда несколько десятков человек работают над одной БД, причем еще и находятся в разных зданиях, если все правильно не описывать, не создавать все связи, опять можно налететь на проблемы.
Даже больше, желательно правильно описывать каждую сущьность, каждый констрейн, чтобы по-имени можно было определить связь иначе пойди-ка разберись в базе, в которой больше тысячи констрейнов SYS_XXXXXХХХХ, сгенерированых автоматом из ервина..

Вобщем, все эти fk, констрейны нот-нуллы, люди не с дуру придумали, не для того чтобы надувать щеки и ходить с важным видом, типа: "какие мы крутые, форегин-кей изобрели", а для РЕАЛЬНОГО уменьшения своего личного гемороя, и то, что кому-то это еще не пригодилось, это его личные проблемы.

← →
Romkin (2003-09-15 10:23) [18]

2[NIKEL] >большинство ошибок надо предусмотреть на этапе проектирования

Конгениально! :)))

← →
Danilka (2003-09-15 10:30) [19]

[NIKEL] © (13.09.03 22:52)
>... если бы все юзеры знали б SQL ...

если-бы все юзеры знали-бы sql это была-бы жопа. они лезли-бы в базу из своих екселей, творили-бы там безобразия, а потом наезжали-бы на разработчиков.
видел, всякие случаи, как, например, паренек, постоянно в update ... set упорно забывал писать секцию where..., блин, я боюсь представить весь ужас ситуации, когда юзеры будут знать sql...

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

← →
pasha_golub (2003-09-15 12:25) [20]

← →
[NIKEL] (2003-09-15 13:33) [21]

если-бы все юзеры знали-бы sql это была-бы жопа.
и в правду была бы, если не раздать права и не понасоздавать views

← →
Danilka (2003-09-15 13:35) [22]

← →
Johnny Smith (2003-09-15 14:50) [23]

2Romkin © (15.09.03 10:23) [18]
2[NIKEL] >большинство ошибок надо предусмотреть на этапе проектирования
Конгениально! :)))
Ага!
Предусмотреть их и допустить!
:)))))))

← →
[NIKEL] (2003-09-16 05:28) [24]

Ага!
Предусмотреть их и допустить!
:)))))))

ну это уже не смешно :)
если ошибки пред!усматриваются(:)) то они, соответственно, не допускаются !

Задача для Мастеров реляционных баз данных. Найти похожие ветки