Ну тогда строго говоря (следуя букве определения) можно сказать что это денормализация, но на практике обычно под этим подразумевают что есть какое выразимое в нормальной форме представление.
Допустим у нас есть камера и софт, который может пересчитывать количество товара на складе раз в миллисекунду автоматически. Например мы решаем этот пересчет не представлять в виде инвентаризационной описи, а при выявлении расхождения оператор может нажать кнопку и сформировать эту опись. Тогда у нас не будет обязательного ограничения что в базу нельзя занести состояние "сумма по документам <> остаткам на складе". Если у нас считает человек, то мы вполне можем выбрать что нельзя никак изменить остатки на складе кроме как зафиксировав это документом и у нас ограничение будет.
И то, что если ограничение есть в предметной области, то к понятию "нормализация" оно не относится.
Почему? В определении "нормализации" нет ничего про то откуда взялось ограничение?
Двойна́я за́пись — способ ведения бухгалтерского учёта, при котором каждое изменение состояния средств организации отражается по крайней мере на двух бухгалтерских счетах, обеспечивая общий баланс.
Тут в определении про транзакции "изменения состояния" а не про остатки.
Можно как хранить остатки так и расcчитывать. Принято комбинировать, в особенности, если нужна историчность но можно было бы и не хранить.
В инфологической модели есть понятие вычислимого атрибута
Если мы хотим это моделировать, значит надо чтобы в модели были такие же сущности и взаимоотношения между ними.
А если не хотим (например, у нас нет камеры которая показывает состояния всех складских ячеек) то можем это не моделировать. У нас может строго соблюдаться, что общее количество по документам равно складским остаткам.
Интересно, как вы это делаете и сколько времени уходит.
У меня обычно несколько итераций содержит взаимосвязанные рефакторинги и добавления фич (переименовал метод, сделал новый класс, выделил в базовом классе метод так что это задело новый класс для фичи и так далее). Мне отделение рефакторинга от нового кода представляется сложным.
В предметной области, как мне кажется, наоборот возможно несовпадение реального количества и количества по документам. Это совпадение желательно, но возможно что оно и не соблюдается (и этот факт фиксируюется инветаризационной описью). Так что это наше решение разрешать ли хранение расхождения или нет.
Предположим у нас бумажный учет, и на складе разбилась люстра. От момента события до момента учета события может быть какой-то промежуток и может наблюдаться различие. Документы показывают одно а в реальности другое.
PS. И в определениях нормализации вообще не сказано, что откуда пришло, так что это не важно в данном контексте
Думаю, продукт коллектива из журналистов и переводчиков производит несколько искаженное впечатление относительно целей создания фичи.
В исходнике что цель выяснить насколько люди знают и юзают фичи софта, чтобы предложить им тренинг (если мало кто употребляют @ надо рассказать об этой фиче):
Productivity Score identifies areas where you can offer people training to learn how to use the tools to their fullest capacity. For example, the new teamwork category (available today) provides a score based on the percentage of people who engage in teamwork within shared workspaces like SharePoint, Microsoft Teams, and group mailboxes in Exchange.
…
We get it, and we are committed to privacy as a fundamental element of Productivity Score. Let me be clear: Productivity Score is not a work monitoring tool. Productivity Score is about discovering new ways of working, providing your people with great collaboration and technology experiences. It focuses on actionable insights about the ways in which people and teams are using the tools so you can make improvements or provide training to further your digital transformation.
Ок, переформулирую. "Мы не считаем, что в реальности абстракция "Товары" и абcтракция "Документы" это одно и то же.
Что такое "абстракция в реальности"? Абстракция есть в голове у кого-то (в какой-то модели).
В бухгалтерии есть еще понятие "двойная запись", там тоже одна величина должна соответствовать другой. Моделирование ее в базе вы тоже считаете денормализацией?
Прочтите определение понятия "денормализация" и примените каждый признак, пожалуйста, его к вашему примеру. Для удобства я их пронумерую циферками.
Денормализация (англ. denormalization) — (1) намеренное(2)приведение структуры базы данных в состояние, (3)не соответствующее критериям нормализации, обычно проводимое с целью ускорения операций чтения из базы за счет добавления избыточных данных.
Я видел как структуры данных, в которых форма соблюдена (Проводка это, счет дебета, счет кредита, сумма) как и структуры данных в которых таковая есть.
"номер транзакции, счет, дебет/кредит, сумма". Во втором случае требовался дополнительный шаг по валидации того, что транзакция сбалансирована, но зато получение остатков было проще писать, например.
Приведите мне пожалуйста определение нормальной формы, в котором есть слова "избыточные данные" и "самостоятельная сущность".
Соответствие документов и товаров идет из предметной области, а не является результатом такого проектирования БД.
Является. Можно спроектировать БД так, чтобы сознательно нарушать это соответствие. Например, у нас eventual consistency или просто мы так решили потомучто. Мы можем игнорировать это соотвествие в каких-то целях. Мы решаем какое подмножество правил модели предметной области реализовывать в нашем БД.
Ну я обычно смотрю в словарь, если не знаю значения слов.
Денормализация (англ. denormalization) — намеренное приведение структуры базы данных в состояние, не соответствующее критериям нормализации, обычно проводимое с целью ускорения операций чтения из базы за счет добавления избыточных данных.
А где тут технические детали, я вижу только логические детали разного уровня абстракции. Тут нет ничего про процессоры, винты, которыми прикручивают SSD и так далее.
Вопрос в том, как вы будете это моделировать.
Так НФ это и есть про модели. Какие ограничения вы хотите ввести в вашей модели реальности.
В реальности нет никаких товаров и документов, есть только (грубо говоря) атомы. Документы, товары, остатки на складе это абстракция.
hpmor
Хорошо. Выкинем этот мусор девятнадцатого века.
Реальность — это не атомы, не множество маленьких бильярдных шаров, летающих вокруг. Маленькие шарики — это просто ещё одна ложь. Представление об атомах как о маленьких точках — лишь ещё одна общепринятая галлюцинация, за которую цепляются люди, потому что они не хотят сталкиваться с нечеловечески чуждой формой скрывающейся за ней реальности. Неудивительно, что его попытки трансфигурации, основанные на таком представлении, не работали. Если он хочет власти, он должен отбросить человеческую природу и заставить мысли соответствовать математическим формулировкам квантовой механики.
Нет никаких частиц, есть лишь облака амплитуд в пространстве состояний множества частиц. И то, что его мозг наивно считает ластиком, не более чем гигантский множитель волновой функции, который тоже можно разложить на множители. Сказать, что он самостоятельно существует, всё равно, что сказать — внутри числа «шесть» существует независимый множитель «три». И если палочка Гарри способна изменять множители в волновых функциях, которые можно хотя бы приблизительно на множители разложить, значит, чёрт побери, она может изменить немного меньший множитель, который мозг Гарри видит как участок ластика…
Из той абстракции, которая существует в голове у специалиста, мы выделяем подмножество, которое нам удобно реализовать в виде программы. В этом подмножестве мы вводим свои правила. Мы можем учитывать товары как нам удобно. Можем один единичный товар записывать записью, если нас это интересует. Можем учитывать партиями, если нам не нужен единичный товар. Можем учитывать просто общее количество без учета партий.
Поверх этого мы вводим свои правила целостности и, наконец, решаем как компьютер будет считать нашу модель.
Если мы решаем, с учетом всего перечисленного, что БД не должна позволять вводить остатки, которых нет ни в каком документе, то у нас есть ограничение. Если мы считаем, что можно вводить данные непосредственно в таблицу остатков и расхождение это нормально, то у нас нет ограничения.
Дальше мы применяем определения из книжек нашим табличкам и можем узнать, находятся они в какой-то НФ или нет.
Дальше мы можем узнать, какие последствия этого нас ожидают и принять решение о том, надо ли нам нормализовывать|денормализовывать или нет.
Не важно является ли это dоmain или еще каким-то ограничением. Если оно должно соблюдаться, значит это не соответствует этой НФ.
Например, если в таблицу остатков можно ввести от балды данные, и это нормально в рамках принятых вами в процессе дизайна решений, то нарушение НФ нет, так как в базе допустимо расхождение.
Если нельзя (например, если МОЛ могут ввести в нее данные только посредством документа "инвентаризационная опись") то тогда есть нарушение этой НФ.
Логически ведь ничем не отличается, мы только агрегацию убрали.
Что такое "логически не отличается"? И куда убрали агрегацию? Количество товара осталось зависимым документов, просто присутствие записи это 1 а отсутствие это 0.
Для того, чтобы ответить на вопрос "является ли 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.
Следовательно схема БД не соответствует ДКНФ.
Хотелось бы, чтоб прежде чем беспокоить окружающих подобными вопросами их авторы предпринимали хотя бы небольшие самостоятельные усилия по поиску информации.
Определения можно так же прочитать в книге "Введения в системы баз данных" К. Дж. Дейт.
Ну тогда строго говоря (следуя букве определения) можно сказать что это денормализация, но на практике обычно под этим подразумевают что есть какое выразимое в нормальной форме представление.
Допустим у нас есть камера и софт, который может пересчитывать количество товара на складе раз в миллисекунду автоматически. Например мы решаем этот пересчет не представлять в виде инвентаризационной описи, а при выявлении расхождения оператор может нажать кнопку и сформировать эту опись. Тогда у нас не будет обязательного ограничения что в базу нельзя занести состояние "сумма по документам <> остаткам на складе". Если у нас считает человек, то мы вполне можем выбрать что нельзя никак изменить остатки на складе кроме как зафиксировав это документом и у нас ограничение будет.
Почему? В определении "нормализации" нет ничего про то откуда взялось ограничение?
Вы говорите про двойную запись:
Тут в определении про транзакции "изменения состояния" а не про остатки.
Можно как хранить остатки так и расcчитывать. Принято комбинировать, в особенности, если нужна историчность но можно было бы и не хранить.
В инфологической модели есть понятие вычислимого атрибута
А если не хотим (например, у нас нет камеры которая показывает состояния всех складских ячеек) то можем это не моделировать. У нас может строго соблюдаться, что общее количество по документам равно складским остаткам.
И что?
Интересно, как вы это делаете и сколько времени уходит.
У меня обычно несколько итераций содержит взаимосвязанные рефакторинги и добавления фич (переименовал метод, сделал новый класс, выделил в базовом классе метод так что это задело новый класс для фичи и так далее). Мне отделение рефакторинга от нового кода представляется сложным.
В предметной области, как мне кажется, наоборот возможно несовпадение реального количества и количества по документам. Это совпадение желательно, но возможно что оно и не соблюдается (и этот факт фиксируюется инветаризационной описью). Так что это наше решение разрешать ли хранение расхождения или нет.
Предположим у нас бумажный учет, и на складе разбилась люстра. От момента события до момента учета события может быть какой-то промежуток и может наблюдаться различие. Документы показывают одно а в реальности другое.
PS. И в определениях нормализации вообще не сказано, что откуда пришло, так что это не важно в данном контексте
Думаю, продукт коллектива из журналистов и переводчиков производит несколько искаженное впечатление относительно целей создания фичи.
В исходнике что цель выяснить насколько люди знают и юзают фичи софта, чтобы предложить им тренинг (если мало кто употребляют @ надо рассказать об этой фиче):
Итак, самостоятельная сущность это синоним избыточные данные. Отлично. Будем дальше так использовать.
Если мы его решили не делать, то да, а если мы его решили делать, то становится. Это мы ж в процессе проектирования решили его моделировать да?
Что такое "абстракция в реальности"? Абстракция есть в голове у кого-то (в какой-то модели).
Прочтите определение понятия "денормализация" и примените каждый признак, пожалуйста, его к вашему примеру. Для удобства я их пронумерую циферками.
Денормализация (англ. denormalization) —
(1) намеренное (2)приведение структуры базы данных в состояние, (3)не соответствующее критериям нормализации, обычно проводимое с целью ускорения операций чтения из базы за счет добавления избыточных данных.
Я видел как структуры данных, в которых форма соблюдена (Проводка это, счет дебета, счет кредита, сумма) как и структуры данных в которых таковая есть.
"номер транзакции, счет, дебет/кредит, сумма". Во втором случае требовался дополнительный шаг по валидации того, что транзакция сбалансирована, но зато получение остатков было проще писать, например.
Приведите мне пожалуйста определение нормальной формы, в котором есть слова "избыточные данные" и "самостоятельная сущность".
Является. Можно спроектировать БД так, чтобы сознательно нарушать это соответствие. Например, у нас eventual consistency или просто мы так решили потомучто. Мы можем игнорировать это соотвествие в каких-то целях. Мы решаем какое подмножество правил модели предметной области реализовывать в нашем БД.
Ну я обычно смотрю в словарь, если не знаю значения слов.
Денормализация (англ. denormalization) — намеренное приведение структуры базы данных в состояние, не соответствующее критериям нормализации, обычно проводимое с целью ускорения операций чтения из базы за счет добавления избыточных данных.
А где тут технические детали, я вижу только логические детали разного уровня абстракции. Тут нет ничего про процессоры, винты, которыми прикручивают SSD и так далее.
Так НФ это и есть про модели. Какие ограничения вы хотите ввести в вашей модели реальности.
В реальности нет никаких товаров и документов, есть только (грубо говоря) атомы. Документы, товары, остатки на складе это абстракция.
Хорошо. Выкинем этот мусор девятнадцатого века.
Реальность — это не атомы, не множество маленьких бильярдных шаров, летающих вокруг. Маленькие шарики — это просто ещё одна ложь. Представление об атомах как о маленьких точках — лишь ещё одна общепринятая галлюцинация, за которую цепляются люди, потому что они не хотят сталкиваться с нечеловечески чуждой формой скрывающейся за ней реальности. Неудивительно, что его попытки трансфигурации, основанные на таком представлении, не работали. Если он хочет власти, он должен отбросить человеческую природу и заставить мысли соответствовать математическим формулировкам квантовой механики.
Нет никаких частиц, есть лишь облака амплитуд в пространстве состояний множества частиц. И то, что его мозг наивно считает ластиком, не более чем гигантский множитель волновой функции, который тоже можно разложить на множители. Сказать, что он самостоятельно существует, всё равно, что сказать — внутри числа «шесть» существует независимый множитель «три». И если палочка Гарри способна изменять множители в волновых функциях, которые можно хотя бы приблизительно на множители разложить, значит, чёрт побери, она может изменить немного меньший множитель, который мозг Гарри видит как участок ластика…
Из той абстракции, которая существует в голове у специалиста, мы выделяем подмножество, которое нам удобно реализовать в виде программы. В этом подмножестве мы вводим свои правила. Мы можем учитывать товары как нам удобно. Можем один единичный товар записывать записью, если нас это интересует. Можем учитывать партиями, если нам не нужен единичный товар. Можем учитывать просто общее количество без учета партий.
Поверх этого мы вводим свои правила целостности и, наконец, решаем как компьютер будет считать нашу модель.
Если мы решаем, с учетом всего перечисленного, что БД не должна позволять вводить остатки, которых нет ни в каком документе, то у нас есть ограничение. Если мы считаем, что можно вводить данные непосредственно в таблицу остатков и расхождение это нормально, то у нас нет ограничения.
Дальше мы применяем определения из книжек нашим табличкам и можем узнать, находятся они в какой-то НФ или нет.
Дальше мы можем узнать, какие последствия этого нас ожидают и принять решение о том, надо ли нам нормализовывать|денормализовывать или нет.
Не важно является ли это dоmain или еще каким-то ограничением. Если оно должно соблюдаться, значит это не соответствует этой НФ.
Например, если в таблицу остатков можно ввести от балды данные, и это нормально в рамках принятых вами в процессе дизайна решений, то нарушение НФ нет, так как в базе допустимо расхождение.
Если нельзя (например, если МОЛ могут ввести в нее данные только посредством документа "инвентаризационная опись") то тогда есть нарушение этой НФ.
Для этого надо определить что значит "являться денормализацией другой"
Что такое "логически не отличается"? И куда убрали агрегацию? Количество товара осталось зависимым документов, просто присутствие записи это 1 а отсутствие это 0.
Я подробнее написал в этом комментарии
Для того, чтобы ответить на вопрос "является ли X Y" надо:
Если не знаем что такое "ограничение" ищем определение для этого.
Теперь задаем вопрос, есть ли у нас ограничения кроме доменных и ключевых? Да, для того, чтобы корректно обновить таблицу current_stocks сумма там должна соответствовать таблице documents.
Следовательно схема БД не соответствует ДКНФ.
Хотелось бы, чтоб прежде чем беспокоить окружающих подобными вопросами их авторы предпринимали хотя бы небольшие самостоятельные усилия по поиску информации.
Определения можно так же прочитать в книге "Введения в системы баз данных" К. Дж. Дейт.
Я думаю, есть нарушение ДКНФ -> она не нормализована
Имхо знающий мотивированный джун, даже без коммерческого опыта который имеет представление об институтской теории весьма ценен.
Не интересующийся специальностью джун который погулял пары по алгоритмам и проектированию БД нафиг не нужен