Все что угодно на каком-то уровне абстракции одного рода, а на каком-то другого
Таблица "current_stocks" — Элементы модели соответствуют сущностям предметной области без дублирования, их количество, приходящееся на одну сущность, не избыточно.
Для целей моделирования — избыточно. Реляционная модель будет совершенно так же отвечать на вопросы об объекте моделирования без возможности хранить остатки отдельно.
Может все-таки у определений есть некая сфера применения
Да, это называется контекст. Если вы вдруг захотите внезапно обсуждать психическую нормальность реляционной модели вам придется это слово явно предварять словом "психическая" или вас перестанут понимать.
Если вы хотите ввести нормальность еще в каком-то смысле, то надо бы это явно описать и желательно подумать в чем его ценность.
Например, если вы придумываете отдельное слово для зеленоглазого блондина в черных ботинках, то, пока таковые не обладают какими-то особыми свойствами (например мода такая) особой пользы в нем не будет.
В традиционной нормализованности есть полезные свойства, ненормализован, значит избыточные элементы, значит возможны аномалии обновления.
Какая польза от вашей нормализованности. И определите ее, кстати.
Если под остатками на складе вы понимаете остатки на реальном складе, то это ваше решение что вы будете соблюдать правило что они равны сумме складских движений по документам — особенность проектирования.
Когда вы делаете деревянную модель самолета для продувке в аэротрубе это ваше решение вырезать в нем окошки и расставлять сиденья.
И если вы принимаете решение вырезать и расставлять, то это проектирование несмотря на то, что в реальном самолете такие сиденья есть. И это проектирование может быть избыточно, если продувать в аэротрубе — единственная цель и может быть не избыточно, если вы хотите не только продувать, но и, например, демонстрировать заказчикам.
как это называть
Просто читаете определение и применяете. Если вы хотите ввести еще какую-то денормализованность кроме той которая уже есть в определениях, то придумайте новое слово для нее. Чтобы понимать друг друга.
Смотрите, вы либо считаете, что эти значения были зависимы или независимы. Если вы считаете, что в вашей модели невозможна ситуация расхождения значит у вас есть избыточность которая может привести к аномалиям, если возможна, значит избыточности нет.
Не важно поменяете ли вы в будущем это или нет.
Модель это предмет, который может с какой-то точностью ответить на вопросы о другом предмете.
Например деревянная модель самолета отвечает на вопросы об аэродинамике в аэротрубе. Она не имитирует удобство посадки пассажиров.
Так и тут. Вы принимаете решение какая у вас модель и какие условия вас интересует. Если вам удобнее знать об остатках на складе только из документов, то модель с хранением остатков избыточна => возможны аномалии обновления.
Если вы говорите, что готовы учитывать какие-то другие остатки не следующие из документов, то тогда она не избыточна вот и все.
Эти все термины нужны не для того, чтобы что-то было хорошим или плохим а чтобы пользоваться свойствами определений.
в ней появилась характеристика статьи "количество комментариев за все время".
А раньше ее не было? Можно еще сделать модель, где это общее количество хранимых комментариев, но при этом часть комментариев хранится за пределами РБД в бекапах на ленточках.
как выглядят нормализованные остатки, что бы это ни значило?
В случае, если вы принимаете решение, что остатки можно вычислить через документы, то они выглядят примерно так:
select sum(quantity) from document_line group by product;
Тогда мне кажется надо разделять денормализацию модели и денормализацию, существующую в предметной области.
А что такое "денормализация, существующая в предметной области"? Денормализация это процесс когда из реляционной модели, удовлетворяющей НФ сознательно делают реляционную модель недовлетворяющую НФ.
Если в рамках предметной области у вас есть величины, которые связаны между собой условием и одна из них может быть вычислена на основании другой, то можно ее моделировать не базовым отношением, в производным — вычисленным на основании базового.
для первого у нас не может измениться требование в предметной области для "comments_cnt" что оно может быть не равно "COUNT(comments.id)",
Почему? Я решаю не хранить старые комменты, чтобы сохранить место на диске, а хранить только 10 последних + их количество чтобы сравнивать посты по количеству реакций. Никакого закона природы тут нет.
Поэтому все равно неправильно называть "current_stocks" денормализованными остатками, если нормализованных остатков у нас нет.
Есть — в рамках текущей версии модели наши остатки избыточны. То, что можно сделать другую модель не значит что сейчас они не избыточны. В определениях НФ ничего не сказано про перспективы изменения модели. Только про текущее состояние.
А должно равняться сумме Б" это такое же требование бизнес-логики, как и "заказ может редактировать только менеджер заказа".
А то, что "A" это поле в отношении а не вычислимый атрибут или поле View это требование бизнес логики?
Вы решите, должна база допускать хранение ситауции, когда сумма документов не равна складским остаткам или не должна и тогда у вас это будет одно и то же или не будет. Вот и все. Это и называется ограничение.
Явно написано, что он относится к разработке проекта.
Ну и что? Мой дедушка относится ко мне, но он не я.
"Каждый обычный тип сущности отображается на базовую переменную отношения."
А что такое "обычный тип"? У меня другое издание, а удобочитаймого онлайна я не нашел.
Если X является отображением Y то нельзя сказать что это одно и то же. Ваша фотография является отображением вас, например, но она не вы.
Возможно у Дейта свое определение сущности, но обычно сущность на инфомодели и она обладает другими свойствами, чем отношение (например, наследованием, вычислимыми атрибутами и так далее)
Он употребил термин "денормализованные остатки", я сказал, что в данном конетксте это нельзя считать денормализацией модели, так как эта таблица моделирует сущность реального мира.
Теперь пройдитесь по определению ДКНФ и найдите там "сущность реального мира".
Там есть отношения и ограничения. Откуда они взялись — пофиг. Есть ограничения невыразимые через домены и ключи, то форма не соблюдается.
Завтра вы снимете ограничение — форма будет соблюдаться.
Так за вами и так следят. Логи пишутся и так далее. Что меняет то, что есть способ удобно посмотреть статистику используемых фич рабочего софта по подразделению?
Потому что в определении нормализации оно подразумевается
А я считаю что не подразумевается.
денормализованной, то есть менее качественной.
Становится. В определениях ничего нет про сущности. Там только про отношения, зависимости и ограничения.
Если у вас ограничение, которое вы не выразили через домены и ключи, то надо предпринимать дополнительные усилия чтобы их соблюдать.
Это не значит что она только менее качественная, по другим критериям она более качественная.
Мне кажется вы как-то эмоционально подходите к вопросу. Типа все номализованное "хорошее", все денормализованное "плохое" поэтому вы стараетесь вашу схему назвать нормализованной.
А это не так. Оно как и почти все обладает как достоинствами так и недостаткаими.
Вы пытаетесь прочитать определения между строк, а там все явно написано.
Ну тогда строго говоря (следуя букве определения) можно сказать что это денормализация, но на практике обычно под этим подразумевают что есть какое выразимое в нормальной форме представление.
Допустим у нас есть камера и софт, который может пересчитывать количество товара на складе раз в миллисекунду автоматически. Например мы решаем этот пересчет не представлять в виде инвентаризационной описи, а при выявлении расхождения оператор может нажать кнопку и сформировать эту опись. Тогда у нас не будет обязательного ограничения что в базу нельзя занести состояние "сумма по документам <> остаткам на складе". Если у нас считает человек, то мы вполне можем выбрать что нельзя никак изменить остатки на складе кроме как зафиксировав это документом и у нас ограничение будет.
И то, что если ограничение есть в предметной области, то к понятию "нормализация" оно не относится.
Почему? В определении "нормализации" нет ничего про то откуда взялось ограничение?
Двойна́я за́пись — способ ведения бухгалтерского учёта, при котором каждое изменение состояния средств организации отражается по крайней мере на двух бухгалтерских счетах, обеспечивая общий баланс.
Тут в определении про транзакции "изменения состояния" а не про остатки.
Можно как хранить остатки так и расcчитывать. Принято комбинировать, в особенности, если нужна историчность но можно было бы и не хранить.
В инфологической модели есть понятие вычислимого атрибута
Если мы хотим это моделировать, значит надо чтобы в модели были такие же сущности и взаимоотношения между ними.
А если не хотим (например, у нас нет камеры которая показывает состояния всех складских ячеек) то можем это не моделировать. У нас может строго соблюдаться, что общее количество по документам равно складским остаткам.
Все что угодно на каком-то уровне абстракции одного рода, а на каком-то другого
Для целей моделирования — избыточно. Реляционная модель будет совершенно так же отвечать на вопросы об объекте моделирования без возможности хранить остатки отдельно.
Да, это называется контекст. Если вы вдруг захотите внезапно обсуждать психическую нормальность реляционной модели вам придется это слово явно предварять словом "психическая" или вас перестанут понимать.
Если вы хотите ввести нормальность еще в каком-то смысле, то надо бы это явно описать и желательно подумать в чем его ценность.
Например, если вы придумываете отдельное слово для зеленоглазого блондина в черных ботинках, то, пока таковые не обладают какими-то особыми свойствами (например мода такая) особой пользы в нем не будет.
В традиционной нормализованности есть полезные свойства, ненормализован, значит избыточные элементы, значит возможны аномалии обновления.
Какая польза от вашей нормализованности. И определите ее, кстати.
Если под остатками на складе вы понимаете остатки на реальном складе, то это ваше решение что вы будете соблюдать правило что они равны сумме складских движений по документам — особенность проектирования.
Когда вы делаете деревянную модель самолета для продувке в аэротрубе это ваше решение вырезать в нем окошки и расставлять сиденья.
И если вы принимаете решение вырезать и расставлять, то это проектирование несмотря на то, что в реальном самолете такие сиденья есть. И это проектирование может быть избыточно, если продувать в аэротрубе — единственная цель и может быть не избыточно, если вы хотите не только продувать, но и, например, демонстрировать заказчикам.
Просто читаете определение и применяете. Если вы хотите ввести еще какую-то денормализованность кроме той которая уже есть в определениях, то придумайте новое слово для нее. Чтобы понимать друг друга.
Только надо подумать чем оно будет полезно.
Если этот if определяет ограничение
Смотрите, вы либо считаете, что эти значения были зависимы или независимы. Если вы считаете, что в вашей модели невозможна ситуация расхождения значит у вас есть избыточность которая может привести к аномалиям, если возможна, значит избыточности нет.
Не важно поменяете ли вы в будущем это или нет.
Модель это предмет, который может с какой-то точностью ответить на вопросы о другом предмете.
Например деревянная модель самолета отвечает на вопросы об аэродинамике в аэротрубе. Она не имитирует удобство посадки пассажиров.
Так и тут. Вы принимаете решение какая у вас модель и какие условия вас интересует. Если вам удобнее знать об остатках на складе только из документов, то модель с хранением остатков избыточна => возможны аномалии обновления.
Если вы говорите, что готовы учитывать какие-то другие остатки не следующие из документов, то тогда она не избыточна вот и все.
Эти все термины нужны не для того, чтобы что-то было хорошим или плохим а чтобы пользоваться свойствами определений.
Да, а для предметной области это не так. Соответственно общий счетчик в БД может как быть избыточным так и нет.
Мне не очень понятно, зачем нормализацию тут применять к производным отношениям (у Дейта тоже написано, что она в основном к базовым применяется).
А раньше ее не было? Можно еще сделать модель, где это общее количество хранимых комментариев, но при этом часть комментариев хранится за пределами РБД в бекапах на ленточках.
В случае, если вы принимаете решение, что остатки можно вычислить через документы, то они выглядят примерно так:
А что такое "денормализация, существующая в предметной области"? Денормализация это процесс когда из реляционной модели, удовлетворяющей НФ сознательно делают реляционную модель недовлетворяющую НФ.
Если в рамках предметной области у вас есть величины, которые связаны между собой условием и одна из них может быть вычислена на основании другой, то можно ее моделировать не базовым отношением, в производным — вычисленным на основании базового.
Почему? Я решаю не хранить старые комменты, чтобы сохранить место на диске, а хранить только 10 последних + их количество чтобы сравнивать посты по количеству реакций. Никакого закона природы тут нет.
Есть — в рамках текущей версии модели наши остатки избыточны. То, что можно сделать другую модель не значит что сейчас они не избыточны. В определениях НФ ничего не сказано про перспективы изменения модели. Только про текущее состояние.
Это смотря какие документы рассматривать. Некоторые — про право собственности.
А вы прочитайте первоисточник. Там вообще не про покарать.
А то, что "A" это поле в отношении а не вычислимый атрибут или поле View это требование бизнес логики?
Вы решите, должна база допускать хранение ситауции, когда сумма документов не равна складским остаткам или не должна и тогда у вас это будет одно и то же или не будет. Вот и все. Это и называется ограничение.
Значит у вас свое собственное определение НФ.
Потому, что я считаю что не соблюдается именно она.
Откуда вы это узнали?
Ну и что? Мой дедушка относится ко мне, но он не я.
А что такое "обычный тип"? У меня другое издание, а удобочитаймого онлайна я не нашел.
Если X является отображением Y то нельзя сказать что это одно и то же. Ваша фотография является отображением вас, например, но она не вы.
Возможно у Дейта свое определение сущности, но обычно сущность на инфомодели и она обладает другими свойствами, чем отношение (например, наследованием, вычислимыми атрибутами и так далее)
Теперь пройдитесь по определению ДКНФ и найдите там "сущность реального мира".
Там есть отношения и ограничения. Откуда они взялись — пофиг. Есть ограничения невыразимые через домены и ключи, то форма не соблюдается.
Завтра вы снимете ограничение — форма будет соблюдаться.
И что? Модель может стать как соответствущей НФ так и не соответсвующей.
Так за вами и так следят. Логи пишутся и так далее. Что меняет то, что есть способ удобно посмотреть статистику используемых фич рабочего софта по подразделению?
А я считаю что не подразумевается.
Становится. В определениях ничего нет про сущности. Там только про отношения, зависимости и ограничения.
Если у вас ограничение, которое вы не выразили через домены и ключи, то надо предпринимать дополнительные усилия чтобы их соблюдать.
Это не значит что она только менее качественная, по другим критериям она более качественная.
Мне кажется вы как-то эмоционально подходите к вопросу. Типа все номализованное "хорошее", все денормализованное "плохое" поэтому вы стараетесь вашу схему назвать нормализованной.
А это не так. Оно как и почти все обладает как достоинствами так и недостаткаими.
Вы пытаетесь прочитать определения между строк, а там все явно написано.
Ну тогда строго говоря (следуя букве определения) можно сказать что это денормализация, но на практике обычно под этим подразумевают что есть какое выразимое в нормальной форме представление.
Допустим у нас есть камера и софт, который может пересчитывать количество товара на складе раз в миллисекунду автоматически. Например мы решаем этот пересчет не представлять в виде инвентаризационной описи, а при выявлении расхождения оператор может нажать кнопку и сформировать эту опись. Тогда у нас не будет обязательного ограничения что в базу нельзя занести состояние "сумма по документам <> остаткам на складе". Если у нас считает человек, то мы вполне можем выбрать что нельзя никак изменить остатки на складе кроме как зафиксировав это документом и у нас ограничение будет.
Почему? В определении "нормализации" нет ничего про то откуда взялось ограничение?
Вы говорите про двойную запись:
Тут в определении про транзакции "изменения состояния" а не про остатки.
Можно как хранить остатки так и расcчитывать. Принято комбинировать, в особенности, если нужна историчность но можно было бы и не хранить.
В инфологической модели есть понятие вычислимого атрибута
А если не хотим (например, у нас нет камеры которая показывает состояния всех складских ячеек) то можем это не моделировать. У нас может строго соблюдаться, что общее количество по документам равно складским остаткам.
И что?