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