Comments 134
Есть же ТостерQ&A. Почему бы не опубликовать этот вопрос на нем?
Там народу мало, тут важна статистика. Это же не вопрос, а опрос, ответ на вопрос я и сам знаю.
Слушайте, ребята, я серьезно не понимаю, почему надо постить опрос на Тостере, на котором нет функционала опросов, и на котором основной формат вопросов это "Как сделать X в Y?". Функционал опросов есть на Хабре, поэтому я сделал его на Хабре, расставил только нужные разделы, написал в заголовке первым словом, что это опрос, и написал вопрос опроса до ката, то есть сделал все, чтобы те, кому это не интересно, не тратили время.
Опрос не поможет дать ответ на неправильный вопрос.
А опрос и не для получения ответа делается, а чтобы узнать мнение.
Если вам кажется, что вопрос неправильный, и поэтому вы не можете сказать свое мнение по этому вопросу, тогда опишите в чем неправильность и как должно быть правильно.
Я не считаю правильным отвечать вам по теме вопроса, так как вы опубликовали его как статью, не имеющую самостоятельной ценности.
На мой взгляд вы с кем-то поспорили, но у вас не хватило знаний, чтобы обосновать свою позицию (и даже на сам вопрос тоже не очень хватило). Поэтому вы потом будете использовать это как аргумент в споре то, что будет более удобным: самый аргументированный комментарий, либо самый массовый ответ в опросе. Мотивация "опросить мнение остальных" выглядит как отмазка за эту манипуляцию.
К тому же непонятно зачем вообще задавать такой вопрос. Ну допустим там денормализация. Что это изменило?
так как вы опубликовали его как статью, не имеющую самостоятельной ценности
С каких пор у опроса должна быть самостоятельная ценность? Ценность опроса в результатах опроса. А на Хабре еще и в комментариях. Правилами вроде не запрещено публиковать опросы на технические темы.
но у вас не хватило знаний, чтобы обосновать свою позицию
Обоснование моей позиции находится в статье, если вы не заметили. Как и обоснование противоположной стороны.
Поэтому вы потом будете использовать это как аргумент в споре то, что будет более удобным: самый аргументированный комментарий
Ага, например свой, которых я уже тут много написал.
Мотивация "опросить мнение остальных" выглядит как отмазка за эту манипуляцию.
С учетом вышесказанного, вы видите то, что хотите видеть, игнорируя все, что этому не соответствует. Ок, дело ваше.
К тому же непонятно зачем вообще задавать такой вопрос. Ну допустим там денормализация. Что это изменило?
Так можно сказать про любые вопросы.
Узнать аргументы каждой из сторон. Узнать соотношение мнений. Текущие результаты показывают, что это не такой однозначный вопрос. Да, при случае можно давать ссылку "вот тут люди это обсуждали".
Вы со всеми подряд спорите?
Ну, на самом деле не совсем. Мне вот в итоге нравится то, что получилось, потому что комментарии интереснее поста. Но сам пост изначально предполагает, что мы можем и должны додумывать за вас многие вещи, типа зависимостей атрибутов друг от друга, которые нужны для правильного ответа на опрос. Т.е. оформлен не очень хорошо, и вопрос предварительно не был достаточно проработан.
Я намеренно написал общими словами, поэтому и сделал один из ответов в опросе "зависит от ситуации". Никто же нам не подсказывает при проектировании системы по бизнес-требованиям. Мне не кажется, что это зависит от ситуации, моделируемая взаимосвязь между сущностями присутствует независимо от модели.
потому что комментарии интереснее поста
Я на это и рассчитывал)
Ну это получилось, мне кажется. Но проработка с вашей стороны все равно выглядит недостаточной. Ну вот смотрите: 5НФ, цитирую:
Очень редко отношение, находящееся в 4НФ, не соответствует 5НФ. Это те ситуации, в которых реальные правила, ограничивающие допустимые комбинации атрибутов, никак не выражены в структуре отношения (см. пример ниже). В таком случае, если отношение не приведено к 5НФ, бремя обеспечения логической целостности данных отчасти перекладывается на приложение, отвечающее за добавление, удаление и изменения данных. В этом случае существует риск возникновения ошибок. Пятая нормальная форма исключает возникновение таких аномалий.
Это же практически про ваш случай. Ну как бы ожидается, что перед созданием такого опроса вы прочитаете хотя бы определения нормальных форм, не так ли?
Да, есть риск возникновения расхождений между агрегатами, рассчитаными по документам, и агрегатами, хрянащимися в отдельной таблице. В этом смысла таблице для аргегатов не нормализована, так как она создает такой риск. Но риск этот потенциальный! Во-первых, можно сделать эту таблицу скажем материализованным view, там где это позволяет СУБД, и тогда расхождений не будет (это гипотеза, и будет ли это хорошо со всех других точек зрения — вопрос отдельный). Ну и есть другие варианты, которые тут уже рассматривали, например такой, что расхождения допускаются вашей бизнес моделью.
Ну т.е. я согласен с мнением выше, что попытка заменить самостоятельную проработку вот этой всей теории опросом — она получилась не очень. Отсюда вероятно и минусы. Большую часть выводов вы могли бы сами сделать, просто перечитав определения.
бремя обеспечения логической целостности данных отчасти перекладывается на приложение, отвечающее за добавление, удаление и изменения данных
Но дело в том, что даже без приложения, без компьютерного учета, у нас все равно должна обеспечиваться логическая целостность между цифрами на бумаге и количеством реальных товаров на складе. У нас даже может быть специальная бумажка "текущие остатки", где они подсчитываются вручную. В этом случае она тоже моделирует сущность реального мира. То, что она должна совпадать с другой сущностью, это особенность предметной области, а не особенность модели. Завтра это требование может поменяться, поменяется и модель. А в случае столбца "comments_cnt" в таблице "articles" в предметной области не может поменяться требование, что оно может не соответствовать количеству комментов в таблице "comments", потому что там эти понятия не разделяются, там есть просто "количество комментариев к статье". В этом я вижу отличие этих ситуаций.
Ну как бы ожидается, что перед созданием такого опроса вы прочитаете хотя бы определения нормальных форм, не так ли?
Я читал определение нормальных форм и определение денормализации. Дело как раз в том, что я не согласен, что описанная ситуация соответствует критериям, заданным в этих определениях.
Завтра это требование может поменяться, поменяется и модель.
И что? Модель может стать как соответствущей НФ так и не соответсвующей.
Я дальше написал. Это не про соответствие модели НФ, а про наличие требования в предметной области, с этим утверждением связаны оба примера. То, что во втором случае у нас есть денормализация, но в предметной области нет соответствующего требования. Такие случаи и подразумевают, когда говорят "денормализация".
Ну, давайте конкретно? Критерии нормальности — это в основном избыточность. Избыточность либо есть, либо нет. В данном случае избыточность — это хранение агрегатов, которые можно вычислить. Бремя обеспечения целостности агрегатов ложится на приложение (если вы считаете что-то руками — никакой разницы не вижу). Одна сущность должна совпадать с другой.
Разве нет? Вполне себе типичный случай для нормализации и денормализации. Но опять же — формы не 3НФ, а более высокие.
Чем это не соответствует?
Тем, что эта избыточность присутствует в модели. Если мы хотим сделать правильную модель, мы обязаны ее моделировать. И это не денормализация модели. Избыточность в определении нормальных форм это избыточность модели для описания предметной области. То есть некоторые части модели не требуются для описания, но они есть. А в данном примере такой избыточности нет, обе таблицы моделируют разные сущности из предметной области. Правило "А должно равняться сумме Б" это такое же требование бизнес-логики, как и "заказ может редактировать только менеджер заказа".
А в примере с "comments_cnt" и это поле и количество строк в таблице "comments" обозначают одно понятие предметной области "количество комментариев в статье". Тут избыточность описания есть.
Тут надо аккуратно :) У слова модель очень много смыслов.
Вы про тут (мета)модель, которая у вас лежит над базой данных?
Если в ней агрегаты это отдельная сущность, и их можно вводить произвольно — то у вас нет такого ограничения, что А должно равняться сумме Б. И тогда, вероятно, нет никакой денормализации.
Мне кажется нужно исходить из того, нормализация это лишь инструмент. Она призвана решать некоторые типы возможных проблем. Если проблем нет — она не нужна. При этом, денормализация — это такой же инструмент, который тоже решает проблемы другого сорта (например, производительности соединений). И ее применяют, если есть эти самые другие проблемы.
Заметьте, что ваша проблема — она лишь потенциальная. Возможно, что ваша архитектура каким-то волшебным образом гарантирует, что таких случаев, когда агрегаты не обновились, их не будет никогда. Это значит, что нормализация не нужна, и ваши таблицы в такой нормальной форме, которая вас устраивает.
По-моему, именно такой подход самый логичный. Нужна ли вам дальнейшая нормализация этих вот таблиц? Если нет — они достаточно нормализованы, и их можно оставить в покое, пусть они хоть в 1НФ при этом. Нужна ли вам денормализация? Если проблем производительности нет — то видимо тоже не нужна. Может ли быть так, что у вас проблемы обоих видов? На мой взгляд — да, можно себе и такое представить.
А должно равняться сумме Б" это такое же требование бизнес-логики, как и "заказ может редактировать только менеджер заказа".
А то, что "A" это поле в отношении а не вычислимый атрибут или поле View это требование бизнес логики?
Вы решите, должна база допускать хранение ситауции, когда сумма документов не равна складским остаткам или не должна и тогда у вас это будет одно и то же или не будет. Вот и все. Это и называется ограничение.
> Там народу мало
Заблудился охотник в лесу, патроны закончились, еда тоже:
— Лю-у-уди-и-и! Ау-у-у! Есть кто-нибудь?!
Медведь выходит на поляну:
— Ну я есть. Легче стало?
Насколько я понял, мнение второй стороны заключается в том, что информация в "current_stocks" это агрегация данных из другой таблицы, это похоже например на столбец "comments_cnt" в таблице "articles", что вроде как считается денормализацией.
CREATE TABLE можно посмотреть здесь.
Ближайший по структуре аналог документов это заказы и товары в них.
Берете определение нормальной формы, и смотрите, в какой из нормальных форм находятся ваши отношения. И что-то мне подсказывает, что они у вас все плюс-минус в 3НФ (но я особо не вникал, если честно, да и не видно этого из приведенной схемы). Глядя на ваш DDL, мы можем только догадываться, что у вас там от чего зависит, возможно мы и правильно догадаемся — но лучше было бы это рассказать явно с самого начала.
То есть, если подойти чисто формально, то чтобы показать, что тут имела место денормализация, нужно показать два отношения, одно скажем в 3НФ, и потом другое в 2НФ, после денормализации. Тут у вас в тексте такого нет.
Ну и еще — если вы хотите сказать, что в какой-то из таблиц хранятся агрегаты, расчитаные на другой таблице — так это вообще не про нормализацию, как вот тут уже было сказано. Потому что нормальные формы — они про то, как атрибуты таблицы зависят от ее ключа и друг от друга, а не про то, как они вычисляются (в форме скажем sum(что-то) from другая-таблица).
Так что да, я бы тоже сказал, что это что-то вроде снапшота (ну или materialised view, скажем).
DDL не мой, я его просто анализировал. Автор кода asmm, он может подробнее пояснить, что от чего зависит.
Рассказал я вроде и так явно в тексте статьи, все основные столбцы описаны, более подробно только схему показать.
Два отношения в данном случае это история изменений и результат изменений, хоть история изменений и связана с некоторой бизнес-сущностью. Я тоже не считаю, что тут есть понижение нормальной формы.
Для того, чтобы ответить на вопрос "является ли X Y" надо:
- Найти определение, что такое X (в данном случае структура БД приведена в статье)
- Найти определение, что такое Y (в данном случае "денормализованный" — возможно подвергнувшийся денормализации)
- Попробовать применить Y к X чтобы, узнать подходит ли определение к ситуации. В данном случае, мы узнаем, что денормализация — уход от НФ для каких, то целей. Это нас отсылает к списку НФ, перебираем НФ по списку доходим до ДКНФ — на русском статья куцая так что переходим в английский раздел. И там читаем:
Domain-key normal form (DK/NF) is a normal form used in database normalization which requires that the database contains no constraints other than domain constraints and key constraints.
Если не знаем что такое "ограничение" ищем определение для этого.
Теперь задаем вопрос, есть ли у нас ограничения кроме доменных и ключевых? Да, для того, чтобы корректно обновить таблицу current_stocks сумма там должна соответствовать таблице documents.
Следовательно схема БД не соответствует ДКНФ.
Хотелось бы, чтоб прежде чем беспокоить окружающих подобными вопросами их авторы предпринимали хотя бы небольшие самостоятельные усилия по поиску информации.
Определения можно так же прочитать в книге "Введения в системы баз данных" К. Дж. Дейт.
есть ли у нас ограничения кроме доменных и ключевых? Да, для того, чтобы корректно обновить таблицу current_stocks сумма там должна соответствовать таблице documents.
Это вообще-то domain-ограничение. Даже материально ответственные лица назначаются для его соблюдения.
Не важно является ли это dоmain или еще каким-то ограничением. Если оно должно соблюдаться, значит это не соответствует этой НФ.
Например, если в таблицу остатков можно ввести от балды данные, и это нормально в рамках принятых вами в процессе дизайна решений, то нарушение НФ нет, так как в базе допустимо расхождение.
Если нельзя (например, если МОЛ могут ввести в нее данные только посредством документа "инвентаризационная опись") то тогда есть нарушение этой НФ.
То есть по вашему мнению введение таблицы с логами изменения некоторой сущности это денормализация этой сущности. Ок.
Ну я обычно смотрю в словарь, если не знаю значения слов.
Денормализация (англ. denormalization) — намеренное приведение структуры базы данных в состояние, не соответствующее критериям нормализации, обычно проводимое с целью ускорения операций чтения из базы за счет добавления избыточных данных.
Ага, неоднозначность вопроса в том, является ли таблица "current_stocks" избыточными данными, или это самостоятельная сущность. Соответствие документов и товаров идет из предметной области, а не является результатом такого проектирования БД.
Приведите мне пожалуйста определение нормальной формы, в котором есть слова "избыточные данные" и "самостоятельная сущность".
Соответствие документов и товаров идет из предметной области, а не является результатом такого проектирования БД.
Является. Можно спроектировать БД так, чтобы сознательно нарушать это соответствие. Например, у нас eventual consistency или просто мы так решили потомучто. Мы можем игнорировать это соотвествие в каких-то целях. Мы решаем какое подмножество правил модели предметной области реализовывать в нашем БД.
Приведите мне пожалуйста определение нормальной формы, в котором есть слова "избыточные данные" и "самостоятельная сущность".
Денормализация (англ. denormalization) — намеренное приведение структуры базы данных в состояние, не соответствующее критериям нормализации, обычно проводимое с целью ускорения операций чтения из базы за счет добавления избыточных данных.
Слов "самостоятельная сущность" там действительно нет, можно считать это выражение синонимом "неизбыточные данные".
Является. Можно спроектировать БД так, чтобы сознательно нарушать это соответствие.
Разговор о случае, когда ограничение смоделировано, а не когда от него отказались.
Слова "а не является результатом такого проектирования БД" означает, что источником этого ограничения на данные является процесс проектирования БД, а в предметной области его нет. Если оно есть, неважно, что мы решили его не делать, источником ограничения процесс проектирования БД не становится.
Слов "самостоятельная сущность" там действительно нет, можно считать это выражение синонимом "неизбыточные данные".
Итак, самостоятельная сущность это синоним избыточные данные. Отлично. Будем дальше так использовать.
Если оно есть, неважно, что мы решили его не делать, источником ограничения процесс проектирования БД не становится.
Если мы его решили не делать, то да, а если мы его решили делать, то становится. Это мы ж в процессе проектирования решили его моделировать да?
Это мы ж в процессе проектирования решили его моделировать да?
Да. А источником является предметная область. В отличие от более традиционных денормализаций типа столбца "comments_cnt" в таблице "articles". Ограничение, что оно должно совпадать с количеством комментариев появляется в процессе проектирования схемы БД, а в предметной области оно не требуется. Для описания этого собственно и придумали термин "денормализация".
А источником является предметная область.
В предметной области, как мне кажется, наоборот возможно несовпадение реального количества и количества по документам. Это совпадение желательно, но возможно что оно и не соблюдается (и этот факт фиксируюется инветаризационной описью). Так что это наше решение разрешать ли хранение расхождения или нет.
Предположим у нас бумажный учет, и на складе разбилась люстра. От момента события до момента учета события может быть какой-то промежуток и может наблюдаться различие. Документы показывают одно а в реальности другое.
PS. И в определениях нормализации вообще не сказано, что откуда пришло, так что это не важно в данном контексте
Это совпадение желательно, но возможно что оно и не соблюдается
Документы показывают одно а в реальности другое.
Ну да, я о том и говорю. Если мы хотим это моделировать, значит надо чтобы в модели были такие же сущности и взаимоотношения между ними. Если это разные сущности, то и в модели они разные.
И в определениях нормализации вообще не сказано, что откуда пришло, так что это не важно в данном контексте
Да, потому что они относятся к процессу моделирования предметной области в базе данных. По умолчанию подразумевается, что нормальность это следствие проектирования модели. Решили спроектировать так, это одна нормальная форма, решили по-другому, другая. Предметная область при этом одна и та же.
Если мы хотим это моделировать, значит надо чтобы в модели были такие же сущности и взаимоотношения между ними.
А если не хотим (например, у нас нет камеры которая показывает состояния всех складских ячеек) то можем это не моделировать. У нас может строго соблюдаться, что общее количество по документам равно складским остаткам.
Предметная область при этом одна и та же
И что?
А если не хотим (например, у нас нет камеры которая показывает состояния всех складских ячеек)
При чем тут камера-то?) В учете на бумаге тоже камер нет, только это все равно разные сущности.
И что?
И то, что если ограничение есть в предметной области, то к понятию "нормализация" оно не относится. Мы моделируем это ограничение, а уже эта модель имеет какую-то нормальную форму.
При чем тут камера-то?)
Допустим у нас есть камера и софт, который может пересчитывать количество товара на складе раз в миллисекунду автоматически. Например мы решаем этот пересчет не представлять в виде инвентаризационной описи, а при выявлении расхождения оператор может нажать кнопку и сформировать эту опись. Тогда у нас не будет обязательного ограничения что в базу нельзя занести состояние "сумма по документам <> остаткам на складе". Если у нас считает человек, то мы вполне можем выбрать что нельзя никак изменить остатки на складе кроме как зафиксировав это документом и у нас ограничение будет.
И то, что если ограничение есть в предметной области, то к понятию "нормализация" оно не относится.
Почему? В определении "нормализации" нет ничего про то откуда взялось ограничение?
и у нас ограничение будет.
Ну ок, будет, они все равно от этого не считаются одной и той же сущностью если учет ведется без компьютеров. Я же после этого вопроса специально пояснения дал, чтобы было понятно, что он риторический, и ответ на него одинаковый независимо от способа учета.
Почему? В определении "нормализации" нет ничего про то откуда взялось ограничение
Я уже писал про это. Потому что в определении нормализации оно подразумевается, это понятие само по себе относится к структуре модели предметной области. Зачем бы его стали в определении каждой нормальной формы писать.
"Нормализация предназначена для приведения структуры БД к виду, обеспечивающему минимальную логическую избыточность.
Как отмечает К. Дейт, общее назначение процесса нормализации заключается в следующем:
…
разработка проекта базы данных, который является достаточно «качественным» представлением реального мира, интуитивно понятен и может служить хорошей основой для последующего расширения"
Это как раз то, о чем я ниже писал, про соответствие поведения модели и реальности при изменениях требований. Если у нас в реальном мире имеются какие-то зависимости между сущностями, модель от этого не становится денормализованной, то есть менее качественной. В общем, я к тому, что надо либо не называть это денормализацией, либо пояснять, что это не денормализация самой модели.
Потому что в определении нормализации оно подразумевается
А я считаю что не подразумевается.
денормализованной, то есть менее качественной.
Становится. В определениях ничего нет про сущности. Там только про отношения, зависимости и ограничения.
Если у вас ограничение, которое вы не выразили через домены и ключи, то надо предпринимать дополнительные усилия чтобы их соблюдать.
Это не значит что она только менее качественная, по другим критериям она более качественная.
Мне кажется вы как-то эмоционально подходите к вопросу. Типа все номализованное "хорошее", все денормализованное "плохое" поэтому вы стараетесь вашу схему назвать нормализованной.
А это не так. Оно как и почти все обладает как достоинствами так и недостаткаими.
Вы пытаетесь прочитать определения между строк, а там все явно написано.
А я считаю что не подразумевается.
Вы пытаетесь прочитать определения между строк, а там все явно написано.
Я же привел цитату "общее назначение процесса нормализации заключается в следующем:… разработка проекта базы данных, который является достаточно «качественным» представлением реального мира". Явно написано, что он относится к разработке проекта.
определениях ничего нет про сущности. Там только про отношения, зависимости и ограничения.
В контексте обсуждения отношения и сущности это синоннимы.
"Введение в проектирование баз данных. К. Дж. Дейт. 8-е издание"
"ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ С ПОМОЩЬЮ МЕТОДА ER-МОДЕЛИРОВАНИЯ"
"Каждый обычный тип сущности отображается на базовую переменную отношения."
Мне кажется вы как-то эмоционально подходите к вопросу. Типа все номализованное "хорошее", все денормализованное "плохое" поэтому вы стараетесь вашу схему назвать нормализованной.
Я уже говорил, что дело не в том, плохо это или хорошо, а в том, как это называть.
И это не моя схема, а схема другого человека, которую я анализировал. Он употребил термин "денормализованные остатки", я сказал, что в данном конетксте это нельзя считать денормализацией модели, так как эта таблица моделирует сущность реального мира.
Явно написано, что он относится к разработке проекта.
Ну и что? Мой дедушка относится ко мне, но он не я.
"Каждый обычный тип сущности отображается на базовую переменную отношения."
А что такое "обычный тип"? У меня другое издание, а удобочитаймого онлайна я не нашел.
Если X является отображением Y то нельзя сказать что это одно и то же. Ваша фотография является отображением вас, например, но она не вы.
Возможно у Дейта свое определение сущности, но обычно сущность на инфомодели и она обладает другими свойствами, чем отношение (например, наследованием, вычислимыми атрибутами и так далее)
Он употребил термин "денормализованные остатки", я сказал, что в данном конетксте это нельзя считать денормализацией модели, так как эта таблица моделирует сущность реального мира.
Теперь пройдитесь по определению ДКНФ и найдите там "сущность реального мира".
Там есть отношения и ограничения. Откуда они взялись — пофиг. Есть ограничения невыразимые через домены и ключи, то форма не соблюдается.
Завтра вы снимете ограничение — форма будет соблюдаться.
Ну и что?
То, что это подтверждает мое утверждение "Потому что в определении нормализации оно подразумевается". Я не говорил, что вы это ваш дедушка, а разработка проекта это денормализация.
А что такое "обычный тип"?
Это которые стандартные самостоятельные сущности, типа Employee. Можно поискать по "введение в системы баз данных pdf".
Если X является отображением Y то нельзя сказать что это одно и то же.
Я не сказал, что это одно и тоже, я сказал, что это синонимы. Сущность реального мира моделируется отношением.
Откуда они взялись — пофиг.
А я не считаю, что моделирование зависимостей в предметной области означает денормализацию. Денормализованность это свойство модели предметной области.
Теперь пройдитесь по определению ДКНФ и найдите там "сущность реального мира".
"Переменная отношения находится в ДКНФ тогда и только тогда, когда каждое наложенное на неё ограничение является логическим следствием ограничений доменов и ограничений ключей, наложенных на данную переменную отношения."
"Каждый обычный тип сущности отображается на базовую переменную отношения."
Нашел.
Почему вообще ДКНФ, а не 6 нормальная форма, или любая другая? 6-я как раз для temporal data была введена.
Таблица с логами — это не денормализация, тк нет дублирования данных (предыдущие состояния сущности — это не те же данные, что текущее состояние).
Наверное я соглашусь что это денормализация…
У меня у самого склад documenttitles documentcontents(document_id foreign) и incomactives, что содержит ссылку на contents_id и quantity(текущий остаток партии по id documentscontents, когда достигает 0 убирается из таблицы)… и хотя это денормализация без этой таблицы никак нельзя.(я ещё добавил document_id чтобы видеть документ источник прихода… ибо documentscontents растет очень быстро и соединение с ней ради получения атрибутов documenttitles ресурсоемко.
Дело даже не в ресурсоемкости. С расчетом текущих остатков по SELECT будет очень сложно отслеживать и обрабатывать факты краж например и другие причины изменений количества, не связанные с документами о приходах-расходах. Пришла машина, по документам в системе 10 единиц товаров, а надо отгрузить 8, и система провела документ, поехали отгружать, а на складе 7.
С SELECT нужен специальный тип документа, у которого могут быть другие поля, которые в других документах не нужны, надо откатить все утвержденные документы, занести в систему новый о недостаче, утвердить его с помощью ответственного. А за это время система приняла документы еще на 3 единицы, за которыми тоже приехали машины.
С отдельной таблицей можно просто скорректировать информацию и продолжить обрабатывать заказы, новых некорректных заказов не будет. Документ о недостаче конечно тоже нужен, но он заносится в специальную таблицу со своими полями и обрабатывается параллельно основному процессу.
Из того, что вы написали в этом комментарии я бы сделал вывод, что это две разные сущности. Т.е. как я понимаю, остатки на складе могут отличаться от данных в документе.
В посте было неочевидно.
Так в том и смысл, что это неочевидно. Никто же нам не подсказывает, когда мы систему проектируем, мы сами должны предусмотреть, что могут быть кражи, и реализовать обработку. По-хорошему остатки не должны отличаться от данных в документах, в этом и смысл понятия "учет". Моя точка зрения в том, что это в любом случае разные сущности.
Моделировать надо максимально близко к реальности. Мы же не считаем в реальности, что документы и товары на складе это одно и то же, вот и в модели они должны быть разные.
В каком-то случае на каждую единицу товара может клеиться инвентарный номер, например если это имущество организации. Документы на приход и расход тут тоже есть. Одна строка в базе "стул, 2 штуки" превращается в две с разными идентификаторами "стул, номер такой-то". Здесь уже нельзя рассчитать состояние по документам.
Недостача, избыток, пкресоптица вводятся отдельными документвми при выявлении.
Да, на любое изменение количества на складе должен быть документ с причиной, но и при учете на бумаге без компьютеров это тоже так, но мы не считаем, что в реальности товары и документы это одно и то же.
В реальности нет никаких товаров и документов, есть только (грубо говоря) атомы. Документы, товары, остатки на складе это абстракция.
Хорошо. Выкинем этот мусор девятнадцатого века.
Реальность — это не атомы, не множество маленьких бильярдных шаров, летающих вокруг. Маленькие шарики — это просто ещё одна ложь. Представление об атомах как о маленьких точках — лишь ещё одна общепринятая галлюцинация, за которую цепляются люди, потому что они не хотят сталкиваться с нечеловечески чуждой формой скрывающейся за ней реальности. Неудивительно, что его попытки трансфигурации, основанные на таком представлении, не работали. Если он хочет власти, он должен отбросить человеческую природу и заставить мысли соответствовать математическим формулировкам квантовой механики.
Нет никаких частиц, есть лишь облака амплитуд в пространстве состояний множества частиц. И то, что его мозг наивно считает ластиком, не более чем гигантский множитель волновой функции, который тоже можно разложить на множители. Сказать, что он самостоятельно существует, всё равно, что сказать — внутри числа «шесть» существует независимый множитель «три». И если палочка Гарри способна изменять множители в волновых функциях, которые можно хотя бы приблизительно на множители разложить, значит, чёрт побери, она может изменить немного меньший множитель, который мозг Гарри видит как участок ластика…
Из той абстракции, которая существует в голове у специалиста, мы выделяем подмножество, которое нам удобно реализовать в виде программы. В этом подмножестве мы вводим свои правила. Мы можем учитывать товары как нам удобно. Можем один единичный товар записывать записью, если нас это интересует. Можем учитывать партиями, если нам не нужен единичный товар. Можем учитывать просто общее количество без учета партий.
Поверх этого мы вводим свои правила целостности и, наконец, решаем как компьютер будет считать нашу модель.
Если мы решаем, с учетом всего перечисленного, что БД не должна позволять вводить остатки, которых нет ни в каком документе, то у нас есть ограничение. Если мы считаем, что можно вводить данные непосредственно в таблицу остатков и расхождение это нормально, то у нас нет ограничения.
Дальше мы применяем определения из книжек нашим табличкам и можем узнать, находятся они в какой-то НФ или нет.
Дальше мы можем узнать, какие последствия этого нас ожидают и принять решение о том, надо ли нам нормализовывать|денормализовывать или нет.
В реальности нет никаких товаров и документов, есть только (грубо говоря) атомы. Документы, товары, остатки на складе это абстракция.
Ок, переформулирую. "Мы не считаем, что в реальности абстракция "Товары" и абcтракция "Документы" это одно и то же"
Если мы решаем, с учетом всего перечисленного, что БД не должна позволять вводить остатки, которых нет ни в каком документе, то у нас есть ограничение.
Это ограничение идет из предметной области. Данные в бумажных документах должны соответствовать количеству физических товаров. А дальше да, мы можем моделировать это ограничение как угодно. Но считать ли его денормализацией. Определения из книжек относятся к отношениям между моделями, соданным при моделировании, модели могут моделировать одну и ту же предметную область, но находиться в разных нормальных формах. А вот если ограничение из предметной области идет, тут непонятно.
В бухгалтерии есть еще понятие "двойная запись", там тоже одна величина должна соответствовать другой. Моделирование ее в базе вы тоже считаете денормализацией?
Ок, переформулирую. "Мы не считаем, что в реальности абстракция "Товары" и абcтракция "Документы" это одно и то же.
Что такое "абстракция в реальности"? Абстракция есть в голове у кого-то (в какой-то модели).
В бухгалтерии есть еще понятие "двойная запись", там тоже одна величина должна соответствовать другой. Моделирование ее в базе вы тоже считаете денормализацией?
Прочтите определение понятия "денормализация" и примените каждый признак, пожалуйста, его к вашему примеру. Для удобства я их пронумерую циферками.
Денормализация (англ. denormalization) —
(1) намеренное (2)приведение структуры базы данных в состояние, (3)не соответствующее критериям нормализации, обычно проводимое с целью ускорения операций чтения из базы за счет добавления избыточных данных.
Я видел как структуры данных, в которых форма соблюдена (Проводка это, счет дебета, счет кредита, сумма) как и структуры данных в которых таковая есть.
"номер транзакции, счет, дебет/кредит, сумма". Во втором случае требовался дополнительный шаг по валидации того, что транзакция сбалансирована, но зато получение остатков было проще писать, например.
Что такое "абстракция в реальности"? Абстракция есть в голове у кого-то (в какой-то модели)
Да. Любые абстракции есть у кого-то в голове. Только для этих абстракций придумали термины "реальность", "предметная область" и "модель". А еще есть "уровни абстракций".
Я не писал "абстракция в реальности", я писал "в реальности мы считаем, что X". В X содержится слово "абстракция" и означает она ровно то, для чего придумали этот термин.
Мы выделяем из наблюдений за реальностью абстракцию "сущность X" и абстракцию "сущность Y", и не считаем их одной и той же сущностью.
Я видел как структуры данных, в которых форма соблюдена (Проводка это, счет дебета, счет кредита, сумма)
Так я говорю про баланс на самих счетах, а не про сумму в проводке. Они же должны совпадать, и это ограничение идет из предметной области.
Вы говорите про двойную запись:
Двойна́я за́пись — способ ведения бухгалтерского учёта, при котором каждое изменение состояния средств организации отражается по крайней мере на двух бухгалтерских счетах, обеспечивая общий баланс.
Тут в определении про транзакции "изменения состояния" а не про остатки.
Можно как хранить остатки так и расcчитывать. Принято комбинировать, в особенности, если нужна историчность но можно было бы и не хранить.
В инфологической модели есть понятие вычислимого атрибута
А дальше написано:
Каждый учётный счёт (регистр) состоит из двух частей: де́бета (левая сторона) счёта и кре́дита (правая сторона). Основным принципом учёта при этом является выполнение в любой момент времени равенства (уравнения баланса):
Активы = Пассивы
Про моделирование этого равенства я и говорил.
Так согласованность должна быть внутри данных системы. Понятно, что система !== реальный мир, и между ними происходят рассогласования. Но их нужно выявлять (инвентаризация) и устранять (списывать, приходовать, перемещать и тд)
Зависит от логики. В общем случае нет, но если обеспечено равенство на уровне базы, то денормализация
Я думаю, есть нарушение ДКНФ -> она не нормализована
Можете подробнее рассказать, в чем нарушение?
Ну в 3НФ (насколько я помню)должны быть исключены транзитивные зависмости.
При изменении контекста документа Вы всегда должны каким то способом (или кодом или тригером) изменить таблицу остатков. транзитивно на ту же величину изменения quantity.(количества)
Отлично, теперь представим, что на каждую единицу поступившего товара надо клеить инвентарный номер. В таблице остатков исчезает столбец "количество", и появляется столбец "инвентарный номер". В этом случае мы тоже должны транзитивно изменять таблицу остатков по тем же условиям, только вместо "UPDATE cnt = cnt +N" будет N операторов INSERT. Вы считаете, что это тоже денормализация? Логически ведь ничем не отличается, мы только агрегацию убрали.
Боюсь что Вы путаете теплое с мягким… У меня так же в одном из отраслевых решений склада реализовано инвернартный номер… и для него отдельная таблица… а также на неё ссылается на documentscontents и на остатки. Подчеркну… от того что это денормализация… это ни есть плохо… без этой таблицы горячих остатков вообще в складе не обойтись.
Так может если не обойтись, то это и не денормализация, а самостоятельная сущность, такая же, как и другие сущности, у которых мы храним состояние? Никто не говорит, что это плохо, вопрос в том, так ли это.
Ну у меня реализован такой же склад… с подобной архитектурой… и я считаю что таблица горячих остатков всё же денормализация… из-за присутствия транзитивной зависимости… Про количество я уже писал, Но так же… если у Вас поменялась цена… ВЫ транзитивно меняете её в таблице остатков… изменился сам товар в таблице контекста(у меня это goods_id) меняем без рассуждений и в остатках… поменялся инвернарный номер(у меня seria_id) транзитивно меняем и там… та таблица транзитивно зависмая от контекста(По-простому Вы всегда их должны синхронизировать)… и согласно определению 3НФ -Это ни есть 3НФ
если у Вас поменялась цена… ВЫ транзитивно меняете её в таблице остатков
изменился сам товар в таблице контекста(у меня это goods_id) меняем без рассуждений и в остатках
В такой формулировке это денормализация, да. Денормализованные данные это столбец "цена". Я говорил о случае, когда "current_stocks" это основной источник данных о состоянии склада. В моем примере там хранится только количество и тип товара, без цены.
Логически ведь ничем не отличается, мы только агрегацию убрали.
Что такое "логически не отличается"? И куда убрали агрегацию? Количество товара осталось зависимым документов, просто присутствие записи это 1 а отсутствие это 0.
"Логически" означает без учета технических деталей. Можно заменить на "принципиально", если вас это смущает.
"Убрали агрегацию" означает, что мы 2 записи "товар X" не схлопываем в одну "товар X, 2 штуки". Подсчет количества это агрегация данных.
просто присутствие записи это 1 а отсутствие это 0
Ага, значит у нас в любой базе во всех таблицах агрегация) Ок.
Количество товара осталось зависимым документов
Количество товара не зависит от документов, товар могут просто украсть без всяких документов. Вопрос в том, как вы будете это моделировать.
А где тут технические детали, я вижу только логические детали разного уровня абстракции. Тут нет ничего про процессоры, винты, которыми прикручивают SSD и так далее.
Вопрос в том, как вы будете это моделировать.
Так НФ это и есть про модели. Какие ограничения вы хотите ввести в вашей модели реальности.
Количество товара осталось зависимым от документов
Или наоборот, документы должны соответствовать текущему количеству товаров на складе. Если выявляется недостача, что мы должны сделать — занести в систему документ о недостаче.
Я подробнее написал в этом комментарии
> Денормализация или нет
Решается голосованием. Докатились.
Это далеко от полной нормализации, по прикладному использованию похоже на кэш.
Устранение избыточности производится, как правило, за счёт декомпозиции отношений таким образом, чтобы в каждом отношении хранились только первичные факты (то есть факты, не выводимые из других хранимых фактов).
В Вашей базе данных, как утверждает Ваш товарищ, и с чем согласны Вы (хотя и делаете другой вывод из ситуации, но согласны с фактом) "данные в «current_stocks» можно рассчитать по документам за все время существования системы, поэтому это денормализация.".
Таким образом у Вас есть факты «выводимые из других хранимых фактов». Всё. Присутствует денормализация.
Другой вопрос в том, что у Вас денормализация звучит в контексте как ругательство. Но это не так. Денормализация это нормально, это хорошо, это не стыдно, это правильно при праавильном применении:) Кэширование, логирование, бакапирование и т.д. — это всё денормализации.
В Вашей ситуации главное не нарушать консистентность БД и сам факт того, что ее необходимо соблюдать, уже свидетельствует о денормализации, т.к. процесс нормализации в глобальном смысле направлен на то, что бы консистентность в принципе не могла быть нарушена.
Я не говорил, что это ругательство, я говорил, что это разные модели, поэтому это не денормализация.
сам факт того, что ее необходимо соблюдать, уже свидетельствует о денормализации, т.к. процесс нормализации в глобальном смысле направлен на то, что бы консистентность в принципе не могла быть нарушена
Так а что если этот процесс существует в предметной области? Понятие денормализации относится к процессу моделирования предметной области, одна и та же предметная область может быть описана моделями с разной нормальной формой. А тут в самой предметной области есть требование "Состояние сущности А и результат расчетов по сущностям B должны совпадать". Тут даже по формулировке видно, что это разные сущности.
Если данные принципиально находятся в разных областях (например продакшен база и отдельный сервер с бинари логами с самого начала) и Вы хотите рассматривать их отдельно, то при отдельном рассмотрении у Вас будет две нормализованные сущности (логи и продакшен), но их объединенное множество будет денормализованным.
Поэтому если Вы рассматриваете базу данных в целом, в которой есть записи о текущем складе и обо всех движениях, то это однозначно денормализованная база. В то же время по отдельности все движения и по отдельности текущий склад — несомненно нормализованные базы, если рассматривать их по отдельности.
Бухгалтерская двойная запись, кстати, отличный пример денормализованной базы, где денормализация не просто оправдана, а решает конкретную задачу, не решаемую более хорошим способом.
Вы обсуждаете общее множество данных, где одно подмножество логически высчитывается из другого. Это по определению денормализованное множество.
Нуу в общем случае логическое высчитывание может выглядеть как "начальное состояние + набор изменений". Поэтому я и воспринимаю "набор изменений" как отдельную сущность.
Опять же, если мы решили клеить на каждый входящий товар инвентарный номер, то принципиально ничего не поменялось, какие были сущности, такие и остались, ограничение что данные в документах должны соответствовать текущим остаткам тоже осталось, но вычислить по документам его уже нельзя. Он по факту и так клеится если в "current_stocks" есть автоинкрементный ключ, только на группу товаров.
В целом в ваших словах есть резон, но мне кажется надо все равно разделять денормализацию, которая есть в предметной области, и денормализацию модели этой предметной области. Сама модель может быть не денормализована. В данном случае все 3 таблицы моделируют соответствующие сущности предметной области. И если в предметной области появится правило, что данные по остаткам могут расходиться с документами в пределах какого-то времени, например пока не будет проведена полная инвентаризация, то нам в модели надо будет просто убрать соответствующее ограничение. Имеется соответствие поведения модели и моделируемых сущностей, это признак правильной модели.
Как тут уже подмечено, чтобы говорить о денормализации, надо сначала сказать, относительно какой НФ. Таки какую НФ денормализует таблица current_stocks?
Касательно сути вопроса.
Первое. Емнип, ни ода из НФ не говорит о вычислимости данных одной сущности из данных других сущностей. Т.о. current_stocks — отдельная сущность. Правила её наполнения находятся вне рамок НФ.
Второе. Тут уже был комментарий, что на складах (если уж речь про них), всегда есть расхождения. Потому таблиц учёта всегда больше одной. И ни одна их сама по себе не хранит информацию о точном состоянии склада.
Из моей практики. Для учёта ТМЦ были такие таблицы:
— актуальные остатки (товар-количество-место),
— перемещения ТМЦ внутри склада (дата-товар-количество-откуда-куда, все движения начинаются с погрузочной зоны, а заканчиваться могут и в «мусорка»),
— входящие/исходящие накладные (дата-товар-количество),
— данные инвентаризации (опять товар-количество-место).
Если при инвентаризации что-то не сходилось — делались коррекции и в актуальных остатках и документах движения.
И всё было по 3НФ.
чтобы говорить о денормализации, надо сначала сказать, относительно какой НФ
Я намеренно дал общее описание, из него можно выделить все основные поля, так же как при анализе бизнес-требований. Мне кажется, что если описанная взаимосвязь между сущностями есть, то ответ на вопрос "денормализация ли это" не зависит от того, как мы будем это моделировать, так как независимо от модели эта взаимосвязь никуда не девается. Схему с CREATE TABLE приводил в этом комментарии.
автор пытается смешать структуру БД и способ её эксплуатации
Я не смешиваю, я описал некоторую уже существующую систему и задал вопрос, по которому с ее автором у нас возникли разногласия.
Я намеренно дал общее описаниеНи в вашем общем описании, ни в схеме таблиц нет ничего про денормализицию.
описал некоторую уже существующую системуПредложенная схема БД выглядит вполне нормальной.
Ещё раз — в описаниях НФ нет ничего про вычисление атрибутов одной сущности из данных другой.
Если уж совсем грубо — если значение атрибутов сущности (кроме ключей) более нигде в БД не встречается — эта сущность соответствует как минимум 3-й НФ.
P.S. В данном случае эта избыточность вполне оправдана
>Нормальная форма — свойство отношения в реляционной модели данных, характеризующее его с точки зрения избыточности, потенциально приводящей к логически ошибочным результатам выборки или изменения данных.
Так что идеологически вопрос вида «А какие виды избыточности нормализация устраняет» (а денормализация соответственно сохраняет) — он вполне валидный.
Денормализация — это, грубо говоря, когда мы храним одни и те же данные в нескольких местах. Ее, по возможности, нужно избегать, чтобы не получить рассогласования данных.
"Остатки на складах" — это самостоятельная сущность предметной области, но это не значит, что она не может быть вычислимой (как сумма всех приходов и расходов).
Вопрос в том, должны ли в вашей системе остатки на складах быть согласованы с приходными и расходными документами. Если должны — это денормализация, если нет — то это не денормализация.
Должны, только на мой взгляд неправильно считать эту модель денормализованной. В самой модели избыточности нет, избыточность есть в предметной области. Все 3 таблицы моделируют соответствующие сущности.
Я думаю, что дело не в том, соответствуют (моделируют) ли таблицы соответствующие объекты предметной области, а в том, дублируются ли данные в таблицах.
Например, если каждый документ меняет остатки, и любое изменение остатков должно соответствовать документу — то данные денормализованные. То есть по сути можно заменить таблицу остатков вьюшкой — и программа этого не заметит.
Еще вопрос: есть ли в приложении пересчет остатков, и задействует ли он какие-либо сущности, кроме документов?
а в том, дублируются ли данные в таблицах
Но это дублирование не следствие проектирования, а особенность предметной области. А понятие нормальности относится к результату проектирования модели.
есть ли в приложении пересчет остатков, и задействует ли он какие-либо сущности
Приложение не мое, поэтому я не в курсе.
Да, кстати. В списке типов документов есть тип "План производства". Не совсем уверен, что это значит, но видимо какие-то фиктивные товары, которых по факту нет на складе. То есть рассчитать все равно можно если эти документы исключить из расчета, но становится более явным, что документы это другая сущность.
Но это дублирование не следствие проектирования, а особенность предметной области. А понятие нормальности относится к результату проектирования модели.
То есть в приложении есть функционал редактирования остатков независимо от документов?
Нету. В предметной области же есть требование, что так нельзя.
Тогда это денормализация, неважно, есть ли требование в предметной области, или нет. Это же по сути те же данные, размещенные в другом месте. То, что вы их вводите как сущность, ничего не меняет.
Тогда мне кажется надо разделять денормализацию модели и денормализацию, существующую в предметной области. Во втором случае убрать избыточность мы можем только убрав одну сущность, то есть сделав модель менее точной, со всеми вытекающими последствиями при изменении требований. Расчет модели на лету это примерно то же самое что расчет структуры класса при анализе ассемблерного кода. Вроде как мы можем отнести какие-то переменные и функции к одному классу, но в коде это не выражено.
Просто явно есть логическое различие между "comments_cnt" и "current_stocks". Для первого у нас не может измениться требование в предметной области для "comments_cnt" что оно может быть не равно "COUNT(comments.id)", обе эти величины моделируют одно и то же. Раз различие есть, надо его как-то выражать в терминах.
Поэтому все равно неправильно называть "current_stocks" денормализованными остатками, если нормализованных остатков у нас нет. Думаю, записи в "document_items" не могут считаться нормализованными остатками (материалов), так как там для одного материала есть несколько записей.
Тогда мне кажется надо разделять денормализацию модели и денормализацию, существующую в предметной области.
А что такое "денормализация, существующая в предметной области"? Денормализация это процесс когда из реляционной модели, удовлетворяющей НФ сознательно делают реляционную модель недовлетворяющую НФ.
Если в рамках предметной области у вас есть величины, которые связаны между собой условием и одна из них может быть вычислена на основании другой, то можно ее моделировать не базовым отношением, в производным — вычисленным на основании базового.
для первого у нас не может измениться требование в предметной области для "comments_cnt" что оно может быть не равно "COUNT(comments.id)",
Почему? Я решаю не хранить старые комменты, чтобы сохранить место на диске, а хранить только 10 последних + их количество чтобы сравнивать посты по количеству реакций. Никакого закона природы тут нет.
Поэтому все равно неправильно называть "current_stocks" денормализованными остатками, если нормализованных остатков у нас нет.
Есть — в рамках текущей версии модели наши остатки избыточны. То, что можно сделать другую модель не значит что сейчас они не избыточны. В определениях НФ ничего не сказано про перспективы изменения модели. Только про текущее состояние.
А что такое "денормализация, существующая в предметной области"?
Избыточность, существующая в предметной области. Денормализация там не совсем корректно использовано, да. Или можно на денормализованность заменить.
Почему? Я решаю не хранить старые комменты, чтобы сохранить место на диске, а хранить только 10 последних + их количество
Вот в этот момент у вас и поменялась предметная область, решением "храним у статьи количество комментариев" в ней появилась характеристика статьи "количество комментариев за все время". Теперь да, в предметной области это разные сущности, так как сами комментарии хранятся не за все время.
В определениях НФ ничего не сказано про перспективы изменения модели.
Я это говорил не про определение нормальности, а про сущности, существующие в предметной области, которые мы хотим смоделировать. Нормальные формы появляются позже, в процессе моделирования.
если нормализованных остатков у нас нет
Есть — в рамках текущей версии модели наши остатки избыточны.
Ок, как выглядят нормализованные остатки, что бы это ни значило?
Такое выражение подразумевает что они где-то хранятся в нормализованном виде.
в ней появилась характеристика статьи "количество комментариев за все время".
А раньше ее не было? Можно еще сделать модель, где это общее количество хранимых комментариев, но при этом часть комментариев хранится за пределами РБД в бекапах на ленточках.
как выглядят нормализованные остатки, что бы это ни значило?
В случае, если вы принимаете решение, что остатки можно вычислить через документы, то они выглядят примерно так:
select sum(quantity) from document_line group by product;при этом часть комментариев хранится за пределами РБД
Так был же разговор, что определение нормальности применяется только к данным в БД.
они выглядят примерно так
Денормализация же относится в первую очередь к схеме, к набору столбцов. А тут схема этого результата такая же, как и в current_stocks.
при этом часть комментариев хранится за пределами РБД
Так был же разговор, что определение нормальности применяется только к данным в БД.
Да, а для предметной области это не так. Соответственно общий счетчик в БД может как быть избыточным так и нет.
Денормализация же относится в первую очередь к схеме, к набору столбцов.
Мне не очень понятно, зачем нормализацию тут применять к производным отношениям (у Дейта тоже написано, что она в основном к базовым применяется).
Ну вот я считаю остатки базовой сущностью, так как она присутствует в предметной области. Неважно, что она имеет взаимосвязь с другой сущностью, это просто правило бизнес-логики. Такое же, как и что менеджер заказа может быть только из региона заказа и не в отпуске. Тут тоже есть зависимости, которые не выражены в базе через таблицы и поля, а выражены только кодом. Так можно любую модель считать денормализованной, если в бизнес-логике есть хотя бы один if.
Это разные модели, "current_stocks" моделирует состояние склада, "document_positions" строки текста в документах.
Пришла мысль, что строки текста в документах сами моделируют физические материалы в грузовике. И с большой вероятностью на каждом складе без компьютерного учета есть бумага, которая моделирует физические материалы на складе. Таблицы в базе это просто замена моделей на бумаге.
По результатам обсуждения я пришел к выводу, что был не прав. С математической точки зрения и в соответствии с определениями в этом примере есть денормализованность.
Но я считаю, что определения сами применимы только в контексте составления модели, так как теория баз данных это теория моделирования.
Также я думаю, в теории есть упущение в том, что теория моделирования не различает ситуации с "articles.comments_cnt" и "current_stocks", так как в плане моделирования между ними есть логическая разница. Правильнее было бы считать, что в примере с "current_stocks" модель не денормализована.
Всем спасибо за обсуждение.
Смотрите, вы либо считаете, что эти значения были зависимы или независимы. Если вы считаете, что в вашей модели невозможна ситуация расхождения значит у вас есть избыточность которая может привести к аномалиям, если возможна, значит избыточности нет.
Не важно поменяете ли вы в будущем это или нет.
Модель это предмет, который может с какой-то точностью ответить на вопросы о другом предмете.
Например деревянная модель самолета отвечает на вопросы об аэродинамике в аэротрубе. Она не имитирует удобство посадки пассажиров.
Так и тут. Вы принимаете решение какая у вас модель и какие условия вас интересует. Если вам удобнее знать об остатках на складе только из документов, то модель с хранением остатков избыточна => возможны аномалии обновления.
Если вы говорите, что готовы учитывать какие-то другие остатки не следующие из документов, то тогда она не избыточна вот и все.
Эти все термины нужны не для того, чтобы что-то было хорошим или плохим а чтобы пользоваться свойствами определений.
Не важно поменяете ли вы в будущем это или нет.
Мой критерий не в том, поменяем мы это в будущем или нет, а в том, что это разные сущности, а зависимость между ними это правило бизнес-логики, а не следствие проектирования модели.
Эти все термины нужны не для того, чтобы что-то было хорошим или плохим
И про это я тоже уже говорил. Дело не в том, как к этому относиться, а в том, как это называть.
Если под остатками на складе вы понимаете остатки на реальном складе, то это ваше решение что вы будете соблюдать правило что они равны сумме складских движений по документам — особенность проектирования.
Когда вы делаете деревянную модель самолета для продувке в аэротрубе это ваше решение вырезать в нем окошки и расставлять сиденья.
И если вы принимаете решение вырезать и расставлять, то это проектирование несмотря на то, что в реальном самолете такие сиденья есть. И это проектирование может быть избыточно, если продувать в аэротрубе — единственная цель и может быть не избыточно, если вы хотите не только продувать, но и, например, демонстрировать заказчикам.
как это называть
Просто читаете определение и применяете. Если вы хотите ввести еще какую-то денормализованность кроме той которая уже есть в определениях, то придумайте новое слово для нее. Чтобы понимать друг друга.
Только надо подумать чем оно будет полезно.
И это проектирование может быть избыточно, если продувать в аэротрубе — единственная цель
В этом примере избыточность другого рода.
Модель самолета с сиденьями — Элементы модели соответствуют сущностям предметной области без дублирования, избыточно их количество для целей моделирования.
Поле "articles.comments_cnt" — Элементы модели соответствуют сущностям предметной области с дублированием, избыточно их количество, приходящееся на одну сущность.
Таблица "current_stocks" — Элементы модели соответствуют сущностям предметной области без дублирования, их количество, приходящееся на одну сущность, не избыточно.
Просто читаете определение и применяете.
Нормальный (Толковый словарь Ожегова)
Соответствующий норме, обычный.
Психически здоровый.
Может все-таки у определений есть некая сфера применения, за пределами которой они неакутальны?
Я считаю, что определения нормальных форм должны применяться только как характеристика избыточности модели, когда разные части модели моделируют одну и ту же характеристику или сущность.
В этом примере избыточность другого рода.
Все что угодно на каком-то уровне абстракции одного рода, а на каком-то другого
Таблица "current_stocks" — Элементы модели соответствуют сущностям предметной области без дублирования, их количество, приходящееся на одну сущность, не избыточно.
Для целей моделирования — избыточно. Реляционная модель будет совершенно так же отвечать на вопросы об объекте моделирования без возможности хранить остатки отдельно.
Может все-таки у определений есть некая сфера применения
Да, это называется контекст. Если вы вдруг захотите внезапно обсуждать психическую нормальность реляционной модели вам придется это слово явно предварять словом "психическая" или вас перестанут понимать.
Если вы хотите ввести нормальность еще в каком-то смысле, то надо бы это явно описать и желательно подумать в чем его ценность.
Например, если вы придумываете отдельное слово для зеленоглазого блондина в черных ботинках, то, пока таковые не обладают какими-то особыми свойствами (например мода такая) особой пользы в нем не будет.
В традиционной нормализованности есть полезные свойства, ненормализован, значит избыточные элементы, значит возможны аномалии обновления.
Какая польза от вашей нормализованности. И определите ее, кстати.
В этом примере избыточность другого рода.
Все что угодно на каком-то уровне абстракции одного рода, а на каком-то другого
Давайте не будем словами играть.
В этом примере избыточность другого рода на том же уровне абстракции.
Для целей моделирования — избыточно.
Если бы оно было избыточно, нам не надо было бы ни считать сумму по документам, ни хранить их отдельно. Так же как в примере с самолетом сиденья не нужны ни в каком виде.
Да, это называется контекст.
Давайте уже перестанем словами играть. Я вам во всей этой части обсуждений объясняю, что контекст применения определения нормальности — процесс моделирования. Я даже выше писал именно с этим словом "Но я считаю, что определения сами применимы только в контексте составления модели, так как теория баз данных это теория моделирования.".
Какая польза от вашей нормализованности.
Тут писал:
"И если в предметной области появится правило, что данные по остаткам могут расходиться с документами в пределах какого-то времени, например пока не будет проведена полная инвентаризация, то нам в модели надо будет просто убрать соответствующее ограничение. Имеется соответствие поведения модели и моделируемых сущностей, это признак правильной модели."
Упрощение изменений бизнес-логики, упрощение понимания модели программистом.
Когда элементы модели не соответствуют сущностям предметной области, возможны аномалии изменения модели — например появляются сущности и данные, которые ничего не моделируют, наподобие поля "Поставщик" или "Клиент" для документов о краже материалов. А уж сколько аномалий обновления могут вызвать такие фиктивные поля из-за того что бизнес-логика на них полагается, думаю вы и сами знаете.
И определите ее, кстати.
Стоп-стоп. Я говорил только о том, что (должно быть) неправильно говорить, что в описанной ситуации в модели есть денормализованность. Я не вводил никаких новых терминов. Критерий я повторил уже много раз — элементы модели моделируют сущности предметной области без избыточности.
В этом примере избыточность другого рода на том же уровне абстракции.
Я про уровень абстракции на котором вы сравниваете две избыточности.
Если бы оно было избыточно, нам не надо было бы ни считать сумму по документам, ни хранить их отдельно. ]
НФ они про хранение а не про расчет. Хранение суммы с точки зрения декларированных ограничений избыточно. Оно нужно либо для быстродействия либо для того, чтобы, в дальнейшем проще мигрировать на другую схему без этого ограничения.
Так же как в примере с самолетом сиденья не нужны ни в каком виде.
Допустим мы хотим использовать ту же модель для демонстрации заказчикам или как игрушку. Фактически как вы проектируете навырост для модели когда возможен непосредственный ввод остатков.
данные по остаткам могут расходиться с документами в пределах какого-то времени, например пока не будет проведена полная инвентаризация,
Тогда встанет вопрос, надо ли допускать ввод непосредственно остатков в таблицу, или это должно быть что-то под номером, возможно кем-то утвержденное с какими-то статусами и так далее. Т.е. документ.
Кстати, я встречал системы, где водился дополнительный уровень "складские движения" которые были просто записью инкремента остатка на складе со ссылкой на источник.
наподобие поля "Поставщик" или "Клиент" для документов о краже материалов.
Оно всегда так будет в какой-то степени, потому, что обычно базы денормализованы. Это нормально. То, что у части документов будут заполнены какие-то поля а какие-то нет может быть на инфологической модели и в виде бизнес правил.
Вообще уровень абстракции реляционной модели он более низкий по сравнению с инфологической моделью и описывает в основном логику хранения.
Он не обязан 1:1 соответствовать бизнес сущностям.
Я говорил только о том, что (должно быть) неправильно говорить, что в описанной ситуации в модели есть денормализованность.
Если вы считаете что это та же денормализованность, про которую говорили Кодд и Дейт, то просто возьмем их определения. Если вы считаете, что это не та же денормализованность, то доопределите. У вас получается что вы сначала вводите ограничение в скопе моделирования, а потом сами же расширяете скоп чтобы от него отказаться.
Допустим мы хотим использовать ту же модель для демонстрации заказчикам или как игрушку.
Противоречит утверждению "Для целей моделирования — избыточно". Цель это то чего мы хотим.
Хранение суммы с точки зрения декларированных ограничений избыточно.
Мы не храним сумму, мы храним остатки на складе. То что они должны быть равны сумме по документам это требование предметной области.
Если бы у нас не было в предметной области понятия "остатки на складе", а было только "документы", тогда да, два элемента модели для моделирования суммы по документам это избыточность.
Тогда встанет вопрос… Т.е. документ.
На это я тоже давал ответ.
"Документ о недостаче конечно тоже нужен, но он заносится в специальную таблицу со своими полями и обрабатывается параллельно основному процессу."
И в предыдущем комментарии тоже специально написал "для документов о краже материалов", чтобы было понятно, что я учитываю эти документы.
Если бы оно было избыточно, нам не надо было бы ни считать сумму по документам, ни хранить их отдельно.
НФ они про хранение а не про расчет. Хранение суммы с точки зрения декларированных ограничений избыточно.
Вы слова ингорируете чтобы потроллить?
А избыточно оно почему? Какой критерий, не тот ли, что их можно рассчитать?
Безотносительно этого, этот ответ был про необходимость моделирования этой сущности, а не про нормальную форму получившейся модели.
Он не обязан 1:1 соответствовать бизнес сущностям.
Я не говорил, что он обязан. Я сказал, что та часть, которая соответствует, в примере с current_stocks соответствует без избыточности, а в примере с comments_cnt с избыточностью.
то просто возьмем их определения
И про это я тоже писал. Я считаю, что "брать" их в данном случае неправильно, так как они относятся к другому контексту. Так же как и определение нормальности из словаря. Если вы считате, что брать их можно, тогда надо приводить аргументы почему можно и почему вы считаете мои аргументы неверными, а не повторять одно и то же.
Если вы считаете, что это не та же денормализованность, то доопределите.
Я не считаю, что это денормализованность. И всё. Здесь нечего доопределять. Я же писал, что не вводил новых сущностей. Для зависимостей между сущностями уже есть термин — правило бизнес-логики.
Мне неинтерсно постоянно указывать на логические ошибки в ваших словах и повторять одно и тоже, извините. Я уже согласился, что с формальной точки зрения был не прав.
Противоречит утверждению "Для целей моделирования — избыточно". Цель это то чего мы хотим.
Не противоречит. То, чего мы хотим изменилось. Так же как и в остатках "И если в предметной области появится правило, ...." — есть гипотетическая возможность изменения того, что мы моделируем.
Если бы у нас не было в предметной области понятия "остатки на складе", а было только "документы", тогда да, два элемента модели для моделирования суммы по документам это избыточность.
Тут от меня ускользает мысль. Если какие-то числа по тем ограничениям, о которых мы условились могут быть вычислены из других чисел, то их хранение избыточно. Потому, что их можно вычислить. Избыточно, это то, что можно не хранить и получить тот же результат. Если условия изменятся, мы можем хранить как-то по-другому. Например, вес и масса отличаются по определению и в каких-то случаях это может стать важным. Но пока мы условились работать на Земле хранение веса и массы избыточно.
Я считаю, что "брать" их в данном случае неправильно, так как они относятся к другому контексту.
Давайте тогда определим контекст явно, чтобы понимать друг друга. Желательно тогда дать определение денормализованности явно в этом другом контексте.
Я не считаю, что это денормализованность. И всё. Здесь нечего доопределять.
О! С этого и надо было начинать :D
— Когда я беру слово, оно означает то, что я хочу, не больше и не
меньше, — сказал Шалтай презрительно.
— Вопрос в том, подчинится ли оно вам, — сказала Алиса.
— Вопрос в том, кто из нас здесь хозяин, — сказал Шалтай-Болтай. — Вот в чем вопрос!
О! С этого и надо было начинать :D
Когда я беру слово
Ок, специально для вас расшифрую. Вам видимо очень нравится играть словами, подменять понятия и приписывать собеседнику то, чего он не говорил. Наверно вам кажется, что вы так выглядите умнее и побеждаете в споре, это единственная логичная причина, которую я могу предположить.
— Если вы считаете, что это не та же денормализованность, то доопределите.
— Я не считаю, что это денормализованность. Аргументы для этого я приводил. Это всё, о чем я хочу сказать, не более того. Я не ввожу ничего, что надо доопределять.
Если бы вы не вырвали процитированную фразу из контекста, в котором следующим предложением идет "Я писал, что не вводил новых сущностей", вы бы сами это поняли.
Я просто вас совершенно не понимаю.
Вот тут вы пишете:
Я считаю, что "брать" их в данном случае неправильно, так как они относятся к другому контексту.
Т.е. существующие определения вас не устраивают в применении к какому то контексту, правильно?
Значит:
- Либо есть какие-то более правильные определения на которые вы можете сослаться.
- Либо у вас есть свое определение (может быть неосознанное).
- Либо вас будет трудно понимать.
Нет? Судя по вашему общению здесь получается третий пункт. Причем вы ссылаетесь на какие-то факты, как будто у нас есть еще какое-то определение денормализованности которым они противоречат.
Т.е. существующие определения вас не устраивают в применении к какому то контексту, правильно?
Не устраивают в том же смысле, в котором не устраивает определение нормальности из словаря Ожегова.
Значит:
1. Либо есть какие-то более правильные определения на которые вы можете сослаться...
Нет, не значит. Еще 4-й вариант есть — я не вводил новых понятий, которым нужны определения.
Определения, на которые я ссылаюсь, я уже раз 20 повторил — сущность, модель, бизнес-логика. Если модель моделирует сущности предметной области без избыточности, значит неправильно говорить, что в модели есть избыточность. И, соответственно, применять термины, основанные на избыточности модели. Если в модели нет избыточности, это не значит, что в ней есть что-то другое, для чего нужно определение.
Определения, на которые я ссылаюсь, я уже раз 20 повторил — сущность, модель, бизнес-логика.
Как ссылаясь только на эти понятия ответить на вопрос является ли х денормализацией y не используя определения слова "денормализация"?
Вот у вас есть треугольник и квадрат. Я хочу узнать квыклоупен ли треугольник квадрату или нет. Определение, что такое "квыклоупен" я вам не дам (существущие меня не устраивают, а своего я не буду описывать так как новые понятия я не вводил).
Нет, не значит. Еще 4-й вариант есть — я не вводил новых понятий, которым нужны определения.
Если вас не устраивает существующее определение, значит вы вводите какой-то другой способ соотносить объекты cо словом. Не является ли это введением нового понятия?
Если модель моделирует сущности предметной области без избыточности, значит неправильно говорить, что в модели есть избыточность.
Для этого надо понять что такое избыточность. В данном случае избыточностью я называю то, что можно не делать и получить тот же самый результат. Например можно не хранить складские остатки а вычислять их по документам. Значит избыточность есть. По крайней мере, пока есть ограничение. Нет?
Определение, что такое "квыклоупен" я вам не дам
Вам не надоело еще играть словами? Давайте я и в таких терминах напишу. Я не вводил никакого понятия "квыклоупен" или чего-то подобного.
Как ссылаясь только на эти понятия ответить на вопрос является ли х денормализацией y не используя определения слова "денормализация"?
Ответ на этот вопрос я уже писал неоднократно — x не является денормализацией y, если x и y моделируют разные сущности в предметной области без избыточности. Почему вдруг не надо его использовать, если о нем идет разговор, и оно подразумевается по контексту? Давайте я еще раз переведу: "Определения, на которые я ссылаюсь [при определении того, применять термин денормализация или нет], я уже раз 20 повторил — сущность, модель, бизнес-логика".
Взаимооотношение между x и y называется "правило бизнес-логики".
Если вас не устраивает существующее определение, значит вы вводите какой-то другой способ соотносить объекты cо словом. Не является ли это введением нового понятия?
Нет. Способ я уже написал — контекст применения. Денормализация применяется в контексте моделирования предметной области, а не в контексте самой предметной области.
"Правило бизнес-логики" это видимо и есть то "новое" понятие, которое вы ищете. Только оно не новое. Поэтому я ничего нового не вводил.
Для этого надо понять что такое избыточность.
Я про это тоже уже писал. Избыточность определяется по количеству элементов модели, приходящееся на одну сущность предметной области или ее характеристику.
Если их больше одного, модель избыточна. Если меньше, модель недостаточна.
Значит избыточность есть. По крайней мере, пока есть ограничение. Нет?
Не бывает просто избыточности, бывает избыточность чего-то.
Это не избыточность модели предметной области. Это в самой предметной области есть такое правило, что сумма по документам должна быть равна количеству товаров на складе. Вот если бы в предметной области не было понятия "количество товаров на складе", тогда сумма по документам, хранящаяся отдельно от документов, была бы избыточностью модели.
На всякий случай еще раз поясню — слова типа "должен" и "является" следует читать как "я считаю, что будет правильнее, если будет так", а не как "я считаю, что так и есть".
Хотите убедить(ся) в денормализации — напишите, относительно какой НФ эта модель денормализирована.
Вы же рассуждаете о бизнес-функциональной модели, в которую может быть заложено ограничение (constraint). Отдельный вопрос, как и будет ли реализовано это ограничение на уровне БД. При чём тут сама модель предметной области?
Опрос. Денормализация или нет?