powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Теоретический вопрос по нормализации
14 сообщений из 39, страница 2 из 2
Теоретический вопрос по нормализации
    #39926061
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ChA
...
Главная проблема заключается в том, что наличие или отсутствие ФЗ формально не выводимо из данных, указанных в таблице, и доказать её можно только наличием примеров, что требует понимания модели данных предметной области.

Имхо, это целиком неверное утверждение.

ФЗ выводятся формально только из состава данных и вообще не предполагают
никакой модели предметной области.

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


Рассуждения о модели предметной области привлекаются тогда, когда
возникает подозрение о том, что представленный в фактических данных мир
по любой причине не полон и допустимо иной состав данных того же рода.
Тогда для анализа ФЗ предлагается иной состав данных,
правдоподобие которого оправдывается "знанием о предметной области",
определяемым тем или иным модельным представлением.

касательно введения суррогатного ключа - конечно ФЗ между суррогатным и естественным ключём просто всегда есть в обе стороны, и иначе быть не может.
Вместе они образуют суперключ.
И это не противоречит 3НФ, но не соответствует НФКБ
...
Рейтинг: 0 / 0
Теоретический вопрос по нормализации
    #39926066
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
boobyФЗ выводятся формально только из состава данных и вообще не предполагают
никакой модели предметной области.

То есть зависимость между плотностью, объёмом и весом не может быть выявлена до наполнения
БД данными. Прелестно...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Теоретический вопрос по нормализации
    #39926068
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov

boobyФЗ выводятся формально только из состава данных и вообще не предполагают
никакой модели предметной области.

То есть зависимость между плотностью, объёмом и весом не может быть выявлена до наполнения
БД данными. Прелестно...

конечно не может.
нет ни "веса", ни "объёма".

Эти слова исследователю функциональных зависимостей в данных не просто не известны,
а за любую догадку сорта - а вдруг в этих клеточках "объем" -
он должен быть подвергнут остракизму и немедленному увольнению.

Исследователь, оправдывающий свое мнение о функциональных зависимостях в данных
своим "модельным знанием" предметной области, не демократии враг,
а способа вести правдоподобное рассуждение.
...
Рейтинг: 0 / 0
Теоретический вопрос по нормализации
    #39926071
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
тот, кто знает про вес и объем - иначе называется
У него и задача другая .
Не "функциональные зависимости в данных" выявлять,
а объяснять пользователю, почему отношение отказывается зафиксировать
свое новое состояние, когда в третье поле 7 вместо 5 записывают.

Путем навязывания пользователю через реализацию своего модельного знания о предметной области.
...
Рейтинг: 0 / 0
Теоретический вопрос по нормализации
    #39926085
Pavel_from_Nsk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
booby,

авторкасательно введения суррогатного ключа - конечно ФЗ между суррогатным и естественным ключём просто всегда есть в обе стороны, и иначе быть не может.
Вместе они образуют суперключ.
И это не противоречит 3НФ, но не соответствует НФКБ

В моем прочтении определения НФБК
https://en.wikipedia.org/wiki/Boyce–Codd_normal_form
авторA relational schema R is in Boyce–Codd normal form if and only if for every one of its dependencies X → Y, at least one of the following conditions hold:

X → Y is a trivial functional dependency (Y ⊆ X),
X is a superkey for schema R.

или
https://ru.wikipedia.org/wiki/Нормальная_форма_Бойса_—_Кодда
авторПеременная отношения находится в BCNF тогда и только тогда, когда каждая её нетривиальная и неприводимая слева функциональная зависимость имеет в качестве своего детерминанта некоторый потенциальный ключ.

ФЗ id->teacher и teacher->id не нарушают НФБК, т.к. и id и teacher являются потенциальными ключами ( и суперключами) и их нахождение слева от стрелки не нарушает НФБК.
...
Рейтинг: 0 / 0
Теоретический вопрос по нормализации
    #39926280
ИВП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[quot booby#22078906]
ChA
...
Имхо, это целиком неверное утверждение.
ФЗ выводятся формально только из состава данных и вообще не предполагают
никакой модели предметной области.
...
Все дано статично и сразу.
На этом выявляется ФЗ. Только на (заданном) составе данных и больше ни на чём.

Ещё одно новое слово в теории БД. Вот именно, что ИМХО .
Это кто же вам даст все статично и сразу ?

Т.е. если смотреть на (заданный) состав данных у ТС, то видно, что каждый Препод ведет ТОЛЬКО одну Дисциплину. Значит имеется ФЗ: Препод->Дисциплина.
Завтра выясняется, что Препод может вести больше одной дисциплины, значит ФЗ отсутствует и надо переделывать структуру БД.
Поэтому должны быть использованы семантические правила, которые появляются после исследования предметной области:
"Каждый Препод может вести только одну (или не только одну) Дисциплину."
Только отсюда и делается вывод о наличии или отсутствии ФЗ. При наличии таких правил никакой состав данных не нужен.
По "снимку" отношения невозможно определить ФЗ. Это сейчас так, а завтра будет иначе!!!
...
Рейтинг: 0 / 0
Теоретический вопрос по нормализации
    #39926386
ИВП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не сразу заметил, что в последнем сообщении приписал цитату не тому автору. Приношу извинения уважаемому ChA.
Вот как должно быть.
booby
...
Имхо, это целиком неверное утверждение.

ФЗ выводятся формально только из состава данных и вообще не предполагают
никакой модели предметной области.
...
Все дано статично и сразу.
На этом выявляется ФЗ. Только на (заданном) составе данных и больше ни на чём.

Ещё одно новое слово в теории БД. Вот именно, что ИМХО.
Это кто же вам даст все статично и сразу?

Т.е. если смотреть на (заданный) состав данных у ТС, то видно, что каждый Препод ведет ТОЛЬКО одну Дисциплину. Значит имеется ФЗ: Препод->Дисциплина.
Завтра выясняется, что Препод может вести больше одной дисциплины, значит ФЗ отсутствует и надо переделывать структуру БД.
Поэтому должны быть использованы семантические правила, которые появляются после исследования предметной области:
"Каждый Препод может вести только одну (или не только одну) Дисциплину."
Только отсюда и можно сделать вывод о наличии или отсутствии ФЗ. При наличии таких правил никакой состав данных не нужен.
По "снимку" отношения невозможно определить ФЗ. Это сейчас так, а завтра будет иначе!!!
...
Рейтинг: 0 / 0
Теоретический вопрос по нормализации
    #39926508
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
booby
ChA
Главная проблема заключается в том, что наличие или отсутствие ФЗ формально не выводимо из данных, указанных в таблице, и доказать её можно только наличием примеров, что требует понимания модели данных предметной области.
Имхо, это целиком неверное утверждение. ФЗ выводятся формально только из состава данных и вообще не предполагают никакой модели предметной области.
Т.е., по любому отношению возможно определить зависимости между атрибутами ? Сиречь, по произвольному набору значений в 2-хмерной матрице со значениями(или даже без оных как частный случай) Вы беретесь восстановить ФЗ между атрибутами ? Ну, например, такой:
ABC1244.23илиABC1244.232123.53Вы уверены в своём утверждении ? А если ФЗ на совсем нетривиальная ?ABC123246Можно ли утверждать, это зависимость, а не случайное совпадение. Какое количество кортежей будет достаточно, что бы можно было бы быть уверенным в том или ином ответе?
booby
"Модель предметной области" - это просто из другого контекста, и такой терминологии не предполагается и не используется для показа фактически существующих в данных ФЗ. ФЗ выявляются и демонстрируются на фактических данных сейчас представляющих весь доступный для анализа мир. Не только "модели предметной области" нет, но и никаких других данных нет. Все дано статично и сразу. На этом выявляется ФЗ. Только на (заданном) составе данных и больше ни на чём.
То, что РМД использует математический аппарат, вовсе не значит, что она занимается абстрактными множествами, этим занимается теория множеств. Ровно так же физика использует математический аппарат, но описывает "реальный мир", или любая другая наука, которая имеет математические основы. Цель РМД в проектировании баз данных, которые описывают множество данных, представимых в виде 2-мерных таблиц. Безусловно, можно построить произвольные абстрактные отношения с абстрактными данными, но в этом случае нельзя быть увереным в наличии или отсутствии в них ФЗ, не говоря уж о практическом смысле таких упражнений. Скорее всего, не составит труда подобрать произвольный кортеж, который внезапно превратит кажущуюся ФЗ в тыкву.
booby
Рассуждения о модели предметной области привлекаются тогда, когда возникает подозрение о том, что представленный в фактических данных мир по любой причине не полон и допустимо иной состав данных того же рода. Тогда для анализа ФЗ предлагается иной состав данных, правдоподобие которого оправдывается "знанием о предметной области", определяемым тем или иным модельным представлением.
Если обратить внимание на примеры, которые приводятся в любом из классических учебниках по проектированию РБД, можно легко заметить, что там всегда оперируют отношениями, завязанными на атрибуты вполне себе "реального мира", а не какими-то абстрактными. И связи между ними понятны и нередко очевидны в рамках предметной области, но не выводимы из произвольного подмножества кортежей, т.е., их как бы не существует, исходя из Вашего утверждения. Я, конечно, могу допустить, что такие примеры приводятся для альтернативно умных, а истинные теоретики проектируют абстрактные БД с абстрактными отношениями, абстрактными атрибутами и абстрактными же ФЗ, выводя их из произвольного набора значений, но мне почему-то кажется, что это слишком абстрактное понимание смысла существования РМД.
booby
касательно введения суррогатного ключа - конечно ФЗ между суррогатным и естественным ключём просто всегда есть в обе стороны, и иначе быть не может. Вместе они образуют суперключ. И это не противоречит 3НФ, но не соответствует НФКБ
И снова не могу с Вами согласиться, суррогатный ключ - абсолютно искусственная конструкция, вводимая в таблицы по определённым соображениям, но ФЗ между ним СК и ЕК не существует, так как соответствие одного другому чисто случайное. Если бы такая ФЗ существовала, то, как ранее справедливо подметил Дмитрий, Вы бы смогли восстановить случайно стёртое значение EK по СК. Лично я не уверен, но если Вам это доступно, то мне, да и не только мне, полагаю, хотелось бы ознакомиться с методикой.
...
Рейтинг: 0 / 0
Теоретический вопрос по нормализации
    #39926524
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ChA,

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

авторВы уверены в своём утверждении ?
Да.

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

авторЦель РМД в проектировании баз данных, которые описывают множество данных, представимых в виде 2-мерных таблиц
а) В РМД нет таблиц . Совсем. Просто даже технического термина такого - таблица - в РМД нет .
б) Даже если бы они там были, то и этом случае, их проектированием РМД не интересуется .

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

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

авторЕсли бы такая ФЗ существовала, то, как ранее справедливо подметил Дмитрий, Вы бы смогли восстановить случайно стёртое значение EK по СК.
про затертое:

Никаких "стёртых значений" нет.
Само использование термина "стёртое" предполагает некую динамику.
Вот она ещё вчера была, а сегодня нету.
Число два ещё вчера существовало, как математический объект, а сегодня выпало из числового ряда, совсем пропало....
Допускаются пропущенные значения в неключевых атрибутах.
Так хотел Кодд, из практических соображений.
Дейт в этом месте видит теоретическую дырку.
Но это другой вопрос. А суть дела в том, что для целей алгебраических манипуляций,
когда речь идет о комбинировании набора отношений в новый объект
(это то, что в языке SQL обеспечивает Select) отношение всегда статический, целиком
заданный и неизменный в рамках операции объект.

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

Про восстановить:
Реляционную модель данных не интересует ваше умение восстановить "затертое"
значение плотности по сохранившимся значениям объема и массы.
Так же как ей не больно от того, что вы называете такое умение
знанием о функциональных зависимостях реального мира.

То, что она для себя называет функциональными зависимостями, относится только к тому специфическому способу анализа состава данных, который используется ею
в рассуждениях о нормальных формах представления отношений.
Любое утверждение о наличии или отсутствии такой зависимости происходит
по отношению только к составу данных и ни чему больше.
Только предъявив образец отношения с конкретным составом данных можно тыркать в него
пальцем и говорить - вот, видишь зависимость? - Смотри.
В этом смысле почти ничего нельзя восстановить.
И функциональные зависимости в данных не выявляются на пропущенных значениях.

Про случайность:
Вы про что вообще говорите?
Что вчера ещё функциональная зависимость была, а завтра "затрётcя" или исчезнет?
"Введено" оно было, или "выведено", искусственно или случайно, или даже "восстановить".
Это даже не про дядьку в Киеве.
Зависимость либо есть, и является собственным свойством отношения, либо зависимости нет.
Между двумя потенциальными ключами зависимость всегда есть.
То, что выбран в качестве первичного суррогатный - именно это и есть чистая случайность ,
если и предопределённая, то целиком соображениями к реляционной модели данных отношения не имеющими.
Это всё.

-------------------------------------------
2 Pavel_from_Nsk
наверно вы правы.
я имел в виду то, что в НФБК стремятся к кратчайшей форме первичного ключа,
что в моём сознании ассоциируется с исключением избыточности.
Здесь, вероятно, перестарался.
...
Рейтинг: 0 / 0
Теоретический вопрос по нормализации
    #39926677
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
booby
ChA,Вам, видимо, я что-то должен ответить, на основании использования вашей цитаты в своем тексте.
Я предположил, что Вы хотите продолжить обсуждение темы, когда Вы процитировали меня в своём тексте. Мы ведь в месте обмена мнениями ? Или я был неправ ? Но, в принципе, вы не должны мне отвечать, я вовсе не настаивал.
booby
авторВы уверены в своём утверждении ?
Да.Уверенность - вещь хорошая, но лучше бы аргументы.
booby
автор Какое количество кортежей будет достаточно, что бы можно было бы быть уверенным в том или ином ответе?
Такое, какое представляет весь мир конкретного отношения.Узнаю всё больше нового. Что такое "мир конкретного отношения" ? Где можно ознакомиться с этим термином ? Он упомянут в теории РМД ?
booby
авторЦель РМД в проектировании баз данных, которые описывают множество данных, представимых в виде 2-мерных таблиц
а) В РМД нет таблиц . Совсем. Просто даже технического термина такого - таблица - в РМД нет .
б) Даже если бы они там были, то и этом случае, их проектированием РМД не интересуется .Даже Википедия об этом не догадывается, вероятно она тоже сугубо для альтернативно одарённых. Раскроете, в чём был смысл создания и существования РМД ?
booby
автор... там всегда оперируют отношениями, завязанными на атрибуты вполне себе "реального мира", а не какими-то абстрактными. И связи между ними понятны и нередко очевидны в рамках предметной области, но не выводимы из произвольного подмножества кортежей, т.е., их как бы не существует, исходя из Вашего утверждения.
По дизайну сами отношения и их атрибуты именованы. Любое манипулирование информацией происходит с использованием имен отношений и их атрибутов. Это всё. Остальное эмоции.Внезапно. По какому-такому дизайну ? Ещё один новый термин. Дизайну чего ? И откуда взялись эти самые имена для отношений и атрибутов ? Не из предметной области ? Или они ничего не значат, а представляют собой случайный набор символов, так же как и данные ?
booby
Вы вводите ранее неиспользованный термин - связи. Что же. Связей в упомянутом вами смысле в реляционной модели нет. О связях, как объекте "иного мира", говорится следующее: вся информация о моделируемых объектах "реального мира" представлена в виде реляционных отношений, включая информацию об их логических связях. С этого момента термин связь , как самостоятельный термин, далее нигде не используется.
Тут стоило бы упрекнуть в недостатке внимания, если вернётесь к исходной фразе, то можете обнаружить, что речь идёт о связях между атрибутами, сиречь, ФЗ. Вероятно фраза оказалась слишком сложной и вы обнаружили в ней то, чего там не было. И не улавливаю связи в определениях "иной мир", "реальный мир" в применении к абстрактному характеру РМД, который Вы декларируете.
booby
авторЕсли бы такая ФЗ существовала, то, как ранее справедливо подметил Дмитрий, Вы бы смогли восстановить случайно стёртое значение EK по СК.
про затертое:
Никаких "стёртых значений" нет. Само использование термина "стёртое" предполагает некую динамику. Вот она ещё вчера была, а сегодня нету. Число два ещё вчера существовало, как математический объект, а сегодня выпало из числового ряда, совсем пропало.... Допускаются пропущенные значения в неключевых атрибутах. Так хотел Кодд, из практических соображений. Дейт в этом месте видит теоретическую дырку. Но это другой вопрос. А суть дела в том, что для целей алгебраических манипуляций, когда речь идет о комбинировании набора отношений в новый объект (это то, что в языке SQL обеспечивает Select) отношение всегда статический, целиком заданный и неизменный в рамках операции объект.
"удалённый", "вставленный", тем более, "затёртый" - здесь это не по месту и вне контекста использованная терминология. И, отношение ни теоретически, ни практически не может содержать кортеж с "затёртым" ключевым атрибутом.
Не совсем улавливаю, зачем это всё написано, но допускаю что я опять ввёл Вас в заблуждение слишком сложными фразами. Попробую чуть иначе: ФЗ между атрибутами подразумевает, что в случае отсутствия значения в зависимом атрибуте(ах) его(их) можно восстановить, зная эту самую ФЗ. Таким образом, он(и) оказывается излишним в этом отношении. Учитывая, что СК не даёт возможности вос(создать) ЕК(обратное тоже верно), можно сделать вывод, что между ними нет ФЗ. Кроме того, если бы они были связаны ФЗ, то получается, что ведение СК приводит к понижению нормализации, что, вобщем-то, неверно.
booby
Про восстановить:
Реляционную модель данных не интересует ваше умение восстановить "затертое" значение плотности по сохранившимся значениям объема и массы. Так же как ей не больно от того, что вы называете такое умение знанием о функциональных зависимостях реального мира. То, что она для себя называет функциональными зависимостями, относится только к тому специфическому способу анализа состава данных, который используется ею в рассуждениях о нормальных формах представления отношений. Любое утверждение о наличии или отсутствии такой зависимости происходит по отношению только к составу данных и ни чему больше. Только предъявив образец отношения с конкретным составом данных можно тыркать в него пальцем и говорить - вот, видишь зависимость? - Смотри.
В этом смысле почти ничего нельзя восстановить. И функциональные зависимости в данных не выявляются на пропущенных значениях.
Взгляд интересный, с интересом бы понаблюдал, как проектировщики БД по значениям ищут функциональные зависимости по произвольным данным, не обращая внимания на их природу. Хотя при чём здесь проектировщики БД, РМД, как вы мне сообщили, существует сама по себе, кто же тогда "тыркает" пальцами и во что ? В отношения ? А что такое отношения, чтобы в них "тыркать" ? Да и ФЗ, по которой "почти" ничего нельзя восстановить удивляет, какая же тогда она ФЗ ?
booby
Про случайность:
Вы про что вообще говорите? Что вчера ещё функциональная зависимость была, а завтра "затрётcя" или исчезнет? "Введено" оно было, или "выведено", искусственно или случайно, или даже "восстановить". Это даже не про дядьку в Киеве. Зависимость либо есть, и является собственным свойством отношения, либо зависимости нет. Между двумя потенциальными ключами зависимость всегда есть. То, что выбран в качестве первичного суррогатный - именно это и есть чистая случайность , если и предопределённая, то целиком соображениями к реляционной модели данных отношения не имеющими.
Это, конечно, очень ярко, эмоционально, особенно про дядьку в Киеве, но не очень убедительно. У вас получается какая-то странная ФЗ между потенциальными ключами. Или это всё таки эта зависимость не ФЗ ? Хотелось бы, конечно, как-то поконкретнее, без риторики.
Например, зачем вводить СК, если есть ЕК ? Почему именно выбирают в качестве PK ? Полагаю, что Вы в курсе, что при генерации СК используются не только последовательности, но и чисто случайные значения ?
booby
Это всё.
Будет очень жаль. Я бы с большим интересом узнал от Вас ещё что-нибудь новое про РМД.
...
Рейтинг: 0 / 0
Теоретический вопрос по нормализации
    #39927022
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Pavel_from_Nsk
Уважаемые форумчане,

Изучаю теорию, помогите, пожалуйста, выйти из логического тупика.

Ниже пример, в котором я не могу разобраться самостоятельно.
Пусть есть таблица с данными о преподавателях и дисциплинах, которые они ведут. Преподаватель может вести одну дисциплину, но одну дисциплину могут вести разные преподаватели. Таблица имеет структуру:

Teacher Subject
---------------------
Иванов Англ. яз
Петров Англ. яз.
Сидоров Информатика

Между полями есть ФЗ: Teacher -> Subject.
Судя по определению, таблица находится в 3 НФ.

Если же я добавляю еще одно поле с идентификатором записи (id) и делаю его первичным ключом:

Id Teacher Subject
---------------------
1. Иванов Англ. яз
2. Петров Англ. яз.
3. Сидоров Информатика ,

То получается, что у меня появляется ФЗ Id->Teacher ( по Id можно однозначно установить Teacher) и прежняя, между теперь неключевыми атрибутами Teacher -> Subject.
Следовательно, есть транзитивная зависимость Id->Subject и таблица перестает удовлетворять даже требованию к 3 НФ.
Хотя интуитивно понятно, что таблица находится и в 3 НФ и в НФБК.

Подскажите, пожалуйста, где ошибка в логике.

Спасибо.

1. Если у вас есть ФЗ: Teacher -> Subject, то Teacher - ключ: от него зависят все остальные (Subject,). Если добавить ID, то верно не только Id->Teacher, но и Teacher->Id. Соотвественно, нет транзитивной зависимости Id->Subject, так как для этого необходимо, чтобы не было ФЗ:Teacher->Id. Стало быть отношение в 3НФ.

И действительно, при нкрушении 3НФ, с помощью декомпозиции должен быть выигрышь: должны быть состояния при котором во второй таблице записей будет меньше чем в первой. Но так как Teacher - ключ, т.е. уникален.

2. Если нет ФЗ: Teacher -> Subject (один препад ведет несколько предметов), то и говорить не о чем. Отношение 3НФ.
...
Рейтинг: 0 / 0
Теоретический вопрос по нормализации
    #39927025
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
опечатка. Всесто: Но так как Teacher - ключ, т.е. уникален.
Следует читать:
Но так как Teacher - ключ, т.е. уникален, поэтому запечий всегда будет столько, сколько значений Teacher. Выигрыша от декомпозиции нет.
...
Рейтинг: 0 / 0
Теоретический вопрос по нормализации
    #39927030
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблица удовлетворяет условиям НФБК (левая сторона любой нетривиальной и неприводимой ФЗ является потенциальным ключом). А т.к. любая НФБК является 3НФ, то все ОК.
...
Рейтинг: 0 / 0
Теоретический вопрос по нормализации
    #39927053
Pavel_from_Nsk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
vadiminfo,

автор1. Если у вас есть ФЗ: Teacher -> Subject, то Teacher - ключ: от него зависят все остальные (Subject,). Если добавить ID, то верно не только Id->Teacher, но и Teacher->Id. Соотвественно, нет транзитивной зависимости Id->Subject, так как для этого необходимо, чтобы не было ФЗ:Teacher->Id. Стало быть отношение в 3НФ.

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

fkthat,
авторТаблица удовлетворяет условиям НФБК (левая сторона любой нетривиальной и неприводимой ФЗ является потенциальным ключом). А т.к. любая НФБК является 3НФ, то все ОК.

Спасибо.
...
Рейтинг: 0 / 0
14 сообщений из 39, страница 2 из 2
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Теоретический вопрос по нормализации
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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