Здравствуйте George_Seryakov, Вы писали:
GS>>>Это значит, что где-то есть один счет и другой счет. У них есть кредит с дебетом. И вот в кредите одного и дебите другого (в двух разных местах!) хозоперация и отражается, причем в одной и той же сумме. Про два места ясно? Спорить будешь?
A>>Буду спорить :) Про два места совсем неясно. Если мы можем отразить операцию по дебету одного счета и кредиту другого не только одновременно, но и в одном кортеже, то я не понимаю как это противоречит приведенному определению? Кредит и дебит при этом действительно будут разными местами :) но эти места — два разных атрибута одного кортежа.
GS>А то, что сделана оговорка "в одной и той же сумме" тебя не наводит на мысли? Зачем она нужна если ты свел две записи (смысле бухучета) к одному кортежу (или записи в смысле БД)?
:) Я склонен списать эту оговорку на издержки докомпьютерного учета. У нас же вроде бы разговор идет о проектировании учетной системы, базирующейся на системе управления БД. Предположительно, реляционной. В этом контексте использование такого приема обеспечения "контроля и восстановления целостности" :) как дублирование информации в разных таблицах, мне кажется излишним. Поэтому на эту оговорку, имхо, просто не нужно обращать внимание.
GS>Давай так: вот ссылка на бухгалтерский учебник в которой явно говорится (и показывается на примерах), что двойная запись требует двух записей: http://www.ait.spb.ru/buh_aud/buh004.html. Попробуй найти и представить текст, в котом столь же явно говорилось бы, что для двойной записи хватило бы "отразить операцию по дебету одного счета и кредиту другого не только одновременно, но и в одном кортеже". Найдешь — сравним источники.
Вообще-то на страничке, которую ты привел я нашел аж три способа фиксирования проводок: 1)табличка, отражающая суммы по дебету и кредиту какого-то счета, при этом сумма вносится в дебетовую часть таблички одного счета и в кредитовую — другого (то, о чем ты говоришь, как я понял), 2) запись вида:
Д51
К50 5000р.
— т.е. все-таки объединение в одном кортеже суммы, номера дебетуемого счета и номера кредитуемого счета :) , 3)в конце страницы вообще приведена форма стандартного журнала регистрации хозопераций, довольно точно совпадающая по структуре с таблицей, приведенной мной пару писем назад. При этом я не нашел в тексте указаний на то, что одна из этих форм записи является "более правильной", чем другие. Как мне кажется, напрашивается вывод о том, что главное в принципе двойной записи это все-таки требование того, чтобы деньги не возникали ниоткуда и не исчезали в никуда, чтобы любая операция фиксировалась с участием как минимум двух счетов. Требование же, которое ты выдвигаешь на передний план, о том, что операция обязательно должна физически оформляться в виде двух отдельных записей, мне представляется просто техническим приемом, призванным облегчить ведение учета на бумаге. При переводе учета на машину это требование, имхо, можно опустить.
Здравствуйте alexm1202, Вы писали:
GS>>А то, что сделана оговорка "в одной и той же сумме" тебя не наводит на мысли? Зачем она нужна если ты свел две записи (смысле бухучета) к одному кортежу (или записи в смысле БД)?
A> Я склонен списать эту оговорку на издержки докомпьютерного учета. У нас же вроде бы разговор идет о проектировании учетной системы, базирующейся на системе управления БД.
Первоначальный вопрос был о трудностях реализации в модели данных двойного учета, т.е. о переводе докомпьютерного учета в компьютерный.
A>Требование же, которое ты выдвигаешь на передний план, о том, что операция обязательно должна физически оформляться в виде двух отдельных записей, мне представляется просто техническим приемом, призванным облегчить ведение учета на бумаге.
Именно так. Намеренная денормализация.
A>При переводе учета на машину это требование, имхо, можно опустить.
Здравствуйте alexm1202, Вы писали:
A>...Требование же, которое ты выдвигаешь на передний план, о том, что операция обязательно должна физически оформляться в виде двух отдельных записей, мне представляется просто техническим приемом, призванным облегчить ведение учета на бумаге. При переводе учета на машину это требование, имхо, можно опустить.
Да не требование это... это попытка воспринимать слова формально, т.е. не по смыслу, а по звучанию. С точки зрения алгоритмов учета разделение информации об одной проводке является ошибкой приводящей (рано или поздно) к несоответствию в учете. Математически проводка — это вектор, а весь учет можно представить в виде матрицы. Это и делают большинство бухгалтеров при ручном учете. Посмотри на журнал операций и шахматную ведомость.
PS
Формальное понимание – это непонимание.
PPS
Начал писать завернутый ответ, но получается почти статья. Через некоторое время выдам ее на гора. Заодно объясню как используя обычные реляционные механизмы строить гибкие системы учета. Может найдутся единомышленники...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Будь добр. Сформулируй, что является неправильным в предложенной тебе системе записи проводок в одной таблице. Причем не уходя в сторону. И попробуй привести пример который нельзя учесть в данной схеме. Или который приведет к неправильным результатам.
Напомню еще раз твою фразу которая и породила весь спор:
GS>А надо? Двойная запись вообще-то, если ее пытаться воспроизвести в ERD, создаст нечто вроде денормализации с дополнительным ограничением целостности, то есть, от чего стоит избавляться.
Тебе объяснили, что ты не прав, и что двойная запись прекрасно описывается в терминах и средствами реляционных БД. И что создание нормализации есть вего лишь неправильное проектирование. Мы не претендуем, на то что решение предлагемое нами единственное и наиболее оптимальное, но все же оно удовлетворяет самым строгим требованиям нормализации и при это позволяет эфективно хранить информацию о проводках отвечая всем требовниям двойной записи.
Да! Очень хочется услышать все таки осмысленные аргументы против, т.е. доказательства, а не жанглирования словами.
PS
Такие споры очень полезны, так как позволяют отточить аргуменатацию и сделать более продуманную модель. Так что главное не перейти на личности и не скатиться к демогогии.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте Willi, Вы писали:
W>Влад, а может, посоветушь наиболее толковые книжечки по БД, окромя Дейта, конечно же. А то я одной из частей своего тела чую, что маловато у меня знаний для решения задач подобного рода.
Я бы и рад, но вот толку от моих советов бцдет мало. Я последний раз книжки по БД читал году в 96-м.
Могу дать тлько пару советов:
Если есть пробелы в обшей логике или логике предикатов, то есть смысл найти что-нибудь в этой области. Подойдут даже учебники.
Перед созданием сложных (агрегирующих) запросов нужно сформулировать задачу в виде потабличных "срезов".
Здравствуйте George_Seryakov, Вы писали:
GS>"Каждая хозоперация подлежит отражению в одной и той же сумме одновременно по дебету одного счета и кредиту другого." Твои слова?
GS>Это значит, что где-то есть один счет и другой счет. У них есть кредит с дебетом. И вот в кредите одного и дебите другого (в двух разных местах!) хозоперация и отражается, причем в одной и той же сумме. Про два места ясно? Спорить будешь?
A>> не прав, пожалуйста, поправь меня. В противном случае поясни, что ты имеешь в виду под "намеренной денормализацией"? Я эти слова понимаю как осознанный отход от какой-то из перечисленных НФ, сделанный по каким-то соображениям (производительности, например).
GS>Что в двух местах. Намеренная денормализация, сделанная по соображениям контроля и восстановления целостности.
GS> Т.е. журнал транзакций двойной записью не является.
W>Посо1етуйте, пожалуйста, книги (можно на английском), сайты в нете, вообще любую инфу по проектированию учетных ситем.
Z cjdtneЗдравствуйте Willi, Вы писали:
Я советую посмотреть 1С версии 7.5 и выше — не снаружи — а изнутри, т.е. их конфигуратор и словарь данных. Концепция — железная, как не крути — прийдешь к тому же имхо..
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Господа, мой опыт проектирования небольшой (около 10 систем учета), но мне ВСЕГДА было достаточно данных по движению объекта учета т.е. <откуда поступил> , <куда поступил> , и описание самого <объекта учета>.
а двойная запись необходима лишь при РУЧНОМ методе .
<Обектами учета> -- могут МЦ, дениги,товары, и т.д. (все что учитываем)
<откуда поступил> и <куда поступил> -- могут бать cклады, касса , счета и т.д. (все, относительно чего учитываем)
Я склонен списать эту оговорку на издержки докомпьютерного учета. У нас же вроде бы разговор идет о проектировании учетной системы, базирующейся на системе управления БД. 
Через некоторое время выдам ее на гора. Заодно объясню как используя обычные реляционные механизмы строить гибкие системы учета. Может найдутся единомышленники...
