Нормализация структуры данных в рамках технологий 1С 8.x

02.06.14

Разработка - Инструментарий разработчика

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование		По подписке [?]	Купить один файл
СтруктураКонфигурацииIDEF1c.epf .epf 36,25Kb 71	71	Скачать (1 SM)	Купить за 1 850 руб.

Нормализация БД – просто и доступно.

Вместо предисловия.

Поводом к написанию данной статьи послужил тот факт, что несмотря на то, что мы уже давно живем в 21 веке, тема нормализации отношений БД в публичных источниках до сих пор не раскрыта. Если обратиться к википедии, то становится ясно, что ничего не ясно. Не проясняет ситуацию ни яндекс, ни гугл. Данный вакуум понимания/не понимания был обнаружен случайно. Однажды, в процессе общения на ИС выяснилось, что посоветовать прочесть собеседнику, что-нить адекватное на эту тему не удалось. К тому же выяснилось, что различные источники трактуют нормальные формы по своему. В свое время, в 1998 году мне повезло познакомиться со школой «Третьякова Сергея Робертовича» и его концепцией третьей нормальной формы. С тех пор я искренне считал, что вопрос закрыт.

Нормализация — это процесс организации данных в базе данных, включающий создание таблиц и установление отношений между ними в соответствии с правилами, которые обеспечивают защиту данных и делают базу данных более гибкой, устраняя избыточность и несогласованные зависимости.

Нормализация и проектирование

Проектирование баз данных, как правило, играет одну из ключевых ролей в большинстве проектов. Грамотно спроектированная база позволяет без особых проблем вносить изменения, изменять структуру системы.

Цели нормализации:

Исключение некоторых типов избыточности. Избыточность данных приводит к непродуктивному расходованию свободного места на диске и затрудняет обслуживание баз данных.
Устранение некоторых аномалий обновления. Например, если данные, хранящиеся в нескольких местах, потребуется изменить, в них придется внести одни и те же изменения во всех этих местах. Несогласованность информации в базе данных — это настоящий кошмар, который почти всегда приводит к возникновению ошибок. Если вы забудете хотя бы об одной таблице, которую нужно обновить, то все данные станут не достоверными.
Устранение некоторых аномалий выборки. Например, если данные, хранящиеся в нескольких местах, потребуется выбрать, то выборка одних и тех же данных из разных источников может дать различные результаты.
Упрощение процедуры применения необходимых ограничений целостности. Отношения, определенные с помощью первичных и внешних ключей позволяют организовать СУБД автоматический контроль согласованности данных, в том числе позволяют реализовать каскадное обновление связанных по внешнему ключу полей в соответствующих таблицах. Разработка проекта базы данных, который является достаточно «качественным» представлением реального мира, интуитивно понятен и может служить хорошей основой для последующего расширения;

Нормализация как таковая не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение физического объёма базы данных. Однако качественная модель, разработанная на основе принципов нормализации ведет к уменьшению физического объема базы данных и обеспечивает приемлемый уровень производительности.

Зачем нужны принципы нормализации?

Целостная система принципов нормализации позволяет различным разработчикам получать на выходе идентичные схемы баз данных, при условии, что на вход они получили идентичные задания. То есть реализуется принцип единообразия.
Появляется возможность автоматизировать процесс анализа результата проектирования для выявления рекомендаций, замечаний и грубых ошибок.
В условиях неопределенности нормализация позволяет создавать системы с широкими потенциальными возможностями для последующего развития. В ходе эволюционных модернизаций любая система рискует оказаться в тупике, преодолеть, который можно только революционным путем. Приверженность принципам нормализация позволяет развивать систему без серьезных потрясений и накладных затрат на радикальные изменения структуры.
Нормализованная структура базы данных поддерживает целостность данных на уровне структуры.
Оптимальная структура базы данных обеспечивает максимальную производительность системы, сочетая простоту и функциональность.
Принципы нормализации создают основу для общения между архитекторами системы и разработчиками, разработчиками и заказчиками приложений.
Осознание принципов позволяет выявить скрытые проблемы в уже работающих системах и помогает принять взвешенные решения для устранения недостатков.

Существует несколько правил нормализации баз данных. Каждое правило называется «нормальной формой». Если выполняется первое правило, говорят, что база данных представлена в «первой нормальной форме». Если выполняются два первых правила, считается, что база данных представлена во «второй нормальной форме» Если выполняются три первых правила, считается, что база данных представлена в «третьей нормальной форме». Есть и другие уровни нормализации, однако для большинства приложений достаточно нормализовать базы данных до третьей нормальной формы.

Как таковые первая и вторая нормальные формы не являются целью оптимизации – это промежуточные этапы для приведения схемы базы данных к третьей нормальной форме. В то время как первая и вторая нормальные формы позволяют реализовать схему базы данных различным набором связанных таблиц. Строгая третья нормальная форма предполагает только один вариант решения задачи проектирования схемы базы данных. с заданной функциональностью. Таким образом, различные программисты одну и туже задачу решают одним и тем же способом, что в значительной мере облегчает коммуникации между разработчиками и архитекторами. К тому же, единообразие позволяет проверять качество проектирования схемы баз данных с помощью автоматизированных средств разработки.

В дальнейшем для решения задач производительности или обеспечения простоты может быть проведена денормализация схемы базы данных. Опытный разработчик баз данных такую денормализацию выполняет на лету в своей голове, однако для этого нужен достаточно большой опыт практического применения принципов нормализации в течении нескольких лет. К сожалению, принципы проектирования 1С не соответствуют принципам проектирования по третьей нормальной форме. Для приобретения навыков проектирования можно взять базу данных mySQL и реализовать на её базе несколько web-приложений.

Пример ошибок нормализации

Не будем далеко ходить. Для примера возьмем наш горячо любимый Инфостарт, с которым вечно, что-то не так. Давайте обратим внимание на показатели рейтинга. В один и то же момент времени они показывают разные значение: 179, 183. Как такое может быть? Отчет очень простой - данные об одном и том же атрибуте хранятся в трех различных местах. Можно себе представить, что твориться внутри, если снаружи основной ключевой показатель выглядит таким образом?

С одной стороны понятно стремление Доржи идти вперед. Но с другой - как можно заниматься редизайном без реинжениринга? Может быть сначала стоило провести рефакторинг базы данных, не трогая визуализации? Да, это затратно и с точки зрения пользователей - бессмысленно. Но может быть стоит хотя бы начать? Понятно, что все уже устали и тех. поддержка в том числе. Но без порядка - нет развития, проект все время будет упираться в "неожиданные" трудности. Но это моё личное мнение.

Продолжим...

Первая нормальная форма

Первая нормальная форма относится только к одной таблице.

Таблица находится в первой нормальной форме (сокращённо 1НФ), если все его атрибуты атомарны, то есть если ни один из его атрибутов нельзя разделить на более простые атрибуты.

Первая и главная нормальная форма требует от таблицы (а точнее, от ее проектировщика) следования следующим правилам:

Каждый столбец в строке должен быть атомарным, т.е. столбец может содержать одно и только одно значение для заданной строки.
Каждая строка в таблице обязана содержать одинаковое количество столбцов
Каждый столбец в строке должен быть строго типизирован
Каждая строка должна иметь независимый первичный ключ. Нельзя использовать в роли первичного ключа атрибуты внешнего мира, такие как табельный номер сотрудника, наименование города и т.д. Первичный ключ – это номер цифровой последовательности

Первичный ключ — один или несколько столбцов, уникально идентифицирующих строку в таблице. Значения в столбце, объявленном как первичный ключ, не может дублироваться в нескольких строках. Колонку первичного ключа обозначаем префиксом «PK»

Не стоит использовать для первичного ключа комбинацию столбцов, используйте только генератор последовательностей СУБД – и будет вам Счастье.

Вторая нормальная форма

Вторая нормальная форма относится только к двум таблицам.

Таблицы должна соответствовать первой нормальной форме.
Определите главную таблицу по правилам отношения «один ко многим»,
В зависимой таблице добавьте внешний ключ.

Внешний ключ — один или более столбцов в таблице, значения которых соответствуют значениям некоторых столбцов в другой таблице (как правило, ее первичным ключам). Внешние ключи нужно стараться использовать везде и всегда, когда между двумя таблицами существует взаимосвязь. Технически, современные системы поддерживают автоматический контроль ссылочной целостности при использовании внешних ключей. Колонку внешнего ключа обозначаем префиксом «FK»

Третья нормальная форма

Третья нормальная форма относится ко всем таблицам задачи в комплексе. Анализируемые таблицы не должны содержать избыточную информацию в не ключевых полях. Все таблицы должны быть связаны между совой по принципу «один ко многим»

Таблицы должны соответствовать второй нормальной форме.
В зависимой таблице внешний ключ должен быть not null.
Все поля стремятся быть not null
Избавиться от избыточной информации, содержащейся в не ключевых столбцах. Другими словами не ключевая информация должна храниться только в одной таблице в одном поле

Если содержимое группы полей может относиться более чем к одной записи в таблице, подумайте о том, не поместить ли эти поля в отдельную таблицу.

Связь между таблицами «один к одному»

В связи "один к одному" строке таблицы А может сопоставляться только одна строка таблицы Б и наоборот. Связь "один к одному" создается, если для обоих связанных ключей определены ограничения первичного ключа и уникальности.

Этот тип связи обычно не используется, так как большую часть связанных таким образом данных можно хранить в одной таблице. Связь "один к одному" можно использовать для следующих целей:

Изоляция части таблицы из соображений безопасности.
Хранение кратковременных данных, которые можно легко удалить вместе со всей таблицей.
Хранения данных, которые относятся только к части основной таблицы.

Само по себе использование связи один к одному есть нарушение требований к третьей нормальной форме и может применяться как средство осознанной денормализации для решения задач оптимизации технических проблем.

Связь между таблицами «один ко многим»

Связь "один ко многим" — единственно возможная в рамках требований третьей нормальной формы. В этом типе связей у строки таблицы А может быть несколько совпадающих строк таблицы Б, но каждой строке таблицы Б может соответствовать только одна строка из таблицы А. С логической точки зрения возможны два случая:

Случай первый:

Таблица А – это справочник; Таблица Б – это таблица фактов. Внешний неуникальный ключ из таблицы Б ссылается на первичный ключ таблицы А.

Случай второй:

Таблица А – это главная таблица; Таблица Б – это зависимая таблица. Внешний не уникальный ключ из таблицы Б ссылается на первичный ключ таблицы А.

Однако с физической точки зрения выглядит это одинаково: Несколько строк из таблицы Б ссылаются на одну строку таблицу А. К тому же внешний ключ таблицы Б не может быть null.

Это главное правило определяющее направление внешней связи.

Связь между таблицами «многие ко многим»

В связи "многие ко многим" строке таблицы А может сопоставляться несколько строк таблицы Б, и наоборот. Наличие такой связи в системе таблиц говорит об ошибках проектирования.

Такие связи устраняются либо путем определения третьей таблицы, которая называется таблицей соединения, первичный ключ которой состоит из внешних ключей А и Б, либо пересмотром всех отношений связанных таблиц.

Пример нормализации

Для начала возьмем следующие данные:

ФИО	Табельный номер	Паспортные данные	Город проживания	Дети сотрудника
Иванов Е. Г.	00001	ВМ 045345	Харьков	Иванова Татьяна 13.06.2009 Иванов Михаил 20/03/10
Петрова Елена Николаевна	00002	ТК 45645	Харьков	Наталья Федоровна
Хлебникова Ольга Александровна	00003	567897	Москва

Первая нормальная форма

Для первой нормальной формы таблица примет вид:

Таблица: «Сотрудники»

PK_ИД	Фамилия	Имя	Отчество	Табельный номер	Серия паспорта	Номер паспорта	Город проживания	Дата рождения ребенка	Фамилия ребенка	Имя Ребенка	Отчество Ребенка
1	Иванов	Егор	Григорьевич	00001	ВМ	045345	Харьков	13.06.2009	Иванова	Татьяна
2	Иванов	Егор	Григорьевич	00001	ВМ	045345	Харьков	20.03.2010	Иванов	Михаил
3	Петрова	Елена	Николаевна	00002	ТК	45645	Харьков			Наталья	Федоровна
4	Хлебникова	Ольга	Александровна	00003		567897	Москва

В качестве первичного ключа выбрано поле «Ид», источником для которого является штатный генератор последовательности СУБД.
Колонка ФИО разбита на три атомарных колонки «Фамилия», «Имя», «Отчество». Это позволяет контролировать заполненность полей, убирать пробелы, задавать алгоритм буквицы, формировать сокращения с помощью простых штатных средств SQL.
Табельный номер сотрудника не используется в качестве первичного ключа, так как он относится к атрибуту внешнего мира и может со временем измениться, что может привести к массивным каскадным обновлениям.
Дата рождения ребенка определена типом колонки «дата», что ведет к однозначности интерпретации данных

Вторая нормальная форма

Для второй нормальной формы таблицы примут вид:

Таблица «Сотрудники»

PK_ИД	Фамилия	Имя	Отчество	Табельный номер	Серия паспорта	Номер паспорта	FK_Город проживания	Дата рождения ребенка	Фамилия ребенка	Имя Ребенка	Отчество Ребенка
1	Иванов	Егор	Григорьевич	00001	ВМ	045345	101	13.06.2009	Иванова	Татьяна
2	Иванов	Егор	Григорьевич	00001	ВМ	045345	101	20.03.2010	Иванов	Михаил
3	Петрова	Елена	Николаевна	00002	ТК	45645	101			Наталья	Федоровна
4	Хлебникова	Ольга	Александровна	00003		567897	102

Таблица «Города»

PK_ИД	Город
101	Харьков
102	Москва
103	Житомир

В качестве первичного ключа выбрано поле «Ид», источником для которого является штатный генератор последовательности СУБД.
В таблице «Сотрудники» появился внешний ключ «FK_Город проживания». В данном колонке могут быть использованы только значения из таблицы «Города»: 101,102,103. В данном примере используются только Ид Харькова и Москвы.

Третья нормальная форма

Таблица «Сотрудники» имеет следующие недостатки

PK_ИД	Фамилия	Имя	Отчество	Табельный номер	Серия паспорта	Номер паспорта	FK_Город проживания	Дата рождения ребенка	Фамилия ребенка	Имя Ребенка	Отчество Ребенка
1	Иванов	Егор	Григорьевич	00001	ВМ	045345	101	13.06.2009	Иванова	Татьяна
2	Иванов	Егор	Григорьевич	00001	ВМ	045345	101	20.03.2010	Иванов	Михаил
3	Петрова	Елена	Николаевна	00002	ТК	45645	101			Наталья	Федоровна
4	Хлебникова	Ольга	Александровна	00003		567897	102	null	null	null	null

В строках 1,2 дублируются не ключевые поля
В строке 4 данные о ребенке остаются не заполненными по причине того, что у данного сотрудника нет ни одного ребенка. Отсутствующая серия паспорта в строке 4 говорит о возможной неполноте данных, отсутствие данных о наличие ребенка носит объективный характер.

Таким образом таблицу сотрудники можно разбить на две таблицы «Сотрудники» и «ДетиСотрудников» итого получаем:

Таблица «Города»

PK_ИД	Город
101	Харьков
102	Москва
103	Житомир

Таблица «Сотрудники»

PK_ИД	Фамилия	Имя	Отчество	Табельный номер	Серия паспорта	Номер паспорта	FK_Город проживания
1	Иванов	Егор	Григорьевич	00001	ВМ	045345	101
2	Петрова	Елена	Николаевна	00002	ТК	45645	101
3	Хлебникова	Ольга	Александровна	00003	null	567897	102

Таблица «ДетиСотрудников»

PK_ИД	FK_ИД Сотрудника	Дата рождения ребенка	Фамилия ребенка	Имя Ребенка	Отчество Ребенка
1001	1	13.06.2009	Иванова	Татьяна	null
1002	1	20.03.2010	Иванов	Михаил	null
1003	2	null	null	Наталья	Федоровна

Добавляем Внешний ключ «FK_ИД Сотрудника» типа «один ко многим».
Для сотрудника с табельным номером 00003 строка в таблице «ДетиСотрудников» полностью отсутствует.
Остальные не заполненные поля отражают лишь неполноту данных по ребенку сотрудника. Данное поле можно запретить вводить пустым, и тогда наши таблицы будут соответствовать строгой третьей нормальной форме. А можно «смягчить» данное требование. Оно нам было нужно только во время нормализации структуры базы данных. Ограничение на полному данных можно перенести из задач СУБД в задачи приложения.

Нормализация с точки зрения 1С

С точки зрения нормализации в 1С этот процесс выглядит довольно «прозрачно». Программисты интуитивно принимают следующие решения: Таблица «Города» реализуется как справочник «Города», Таблица «Сотрудники» реализуется как справочник «Сотрудники» с реквизитом «Город» типа СправочникСсылка.Города и табличной частью «ДетиСотрудника». В данном случае данный факт можно считать преимуществом 1С, так как процесс разработки скрывает от программиста излишнюю сложность. Если бы не одно большое НО. В табличной части, равно как и в регистре сведений отсутствует первичный ключ. Все бы ничего, но проблемы возникают во время интеграции с реляционными СУБД, в частности при обмене данными с web-сайтом на базе mySQL. Решается проблема с помощью искусственного первичного ключа в табличной части или регистре сведений.

Денормализация с точки зрения 1С

С моей точки зрения большим технологическим прорывом стало появление в 1С регистра накопления. Сама по себе строгая нормальная форма несет в себе порядок в процессе проектирования, но доведенная до абсурда способна тормознуть любой проект своими ограничениями. Во-первых, строгая третья нормальная форма хороша только для статических систем. Для динамических систем, которые меняются во времени, такие ограничения лишают программные комплексы необходимой гибкости. К примеру, в SAP нельзя внести контрагента, пока не заполнишь все обязательные поля, вплоть до телефона директора. Во-вторых, регистр накопления реализует OLAP технологии на уровне платформы, так как регистр накопления имеет измерения, ресурсы и временную ось. Структура регистра накопления позволяет значительно увеличить производительность за счет заранее посчитанных итогов, а штатные средства отчетов позволяют реализовывать принципы drill-down, drill-up в рамках единой среды.

В принципе, регистры накопления и регистры сведений – единственное отличие от третьей нормальной формы.

К сожалению, отсутствие ограничений на уровне платформы дает программисту слишком большую степень свободы и ведет накоплению ошибок проектирования. По этому, на мой взгляд, знать 1С программисту принципы нормализации обязательно. Более того, отсутствие привычки "задумываться о нормализации" во время проектирования приводит к тому, что разработчики умудряются использовать не по назначению справочники, документы и регистры.

Область применения принципов нормализации

В принципе, методика нормализации подходит для объектов справочники и документы. Принципы проектирования регистров выходят за рамки данной статьи. Одно могу сказать точно - наличие в конфигурации свыше 50 регистров накопления свидетельствует об отсутствии концептуальной целостности в частности и об отсутствии модели учета как таковой. К сожалению, а может быть к счастью здесь просто не паханое поле.

Первая нормальная форма, без первичного ключа хорошо подходит для обсуждения и фиксации требований с заказчиков. Обычно заказчик легко идет на обсуждение задач в формате первой нормальной формы, тем более, что экселевская обработка таких данных естественным образом справляется с сортировкой и автофильтрацией.

Третья нормальная форма хороша для общения между архитекторами, консультантами и программистами. По крайней мере, умение читать структуру базы данных и видеть её ограничения позволяет согласовать приемлемое решение с учетом текущего момента.

Чек лист последовательности проектирования базы данных

Для тех, кто ещё только делает первые шаги в проектировании баз данных будет полезна типовая последовательность выполнения работ:

Определить таблицы объектов
Определить атомарные поля
Определить типы полей
Определить первичные ключи
Определить внешние ключи
Определить индексы полей
Определить уникальность полей
Определить признаки полей null/not null
Определить дополнительные ограничений полей
Выполнить нормализацию до 3-й нормальной формы
Выполнить денормализацию с учетом ограничений по производительности

Методология IDEF1Х и программный продукт ERWin

На основании своего опыта могу сказать, что в моем конкретном случае использование AllFusion Data Model Validator (ERwin Examiner) приведет к сокращению трудозатрат приблизительно на 1000 человеко-часов при перепроектировании и настройке баз данных моей фирмы.

Билл Кларк, администратор БД компании FunMail

В свое время компания Computer Associates в рамках серии продуктов ERwin реализовала стандарт IDEF1X.

IDEF1X является методом для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для построения концептуальной схемы структуры данных предприятия, независимой от конечной реализации базы данных и аппаратной платформы.

Сущность предметной области в IDEF1X описывает собой совокупность или набор экземпляров похожих по свойствам, но однозначно отличаемых друг от друга по одному или нескольким признакам. Каждый экземпляр является реализацией сущности. Таким образом, сущность в IDEF1X описывает конкретный набор экземпляров реального мира, в отличие от сущности в IDEF1, которая представляет собой абстрактный набор информационных отображений реального мира.

Поддержка нормализации в ERWin. ERWin не содержит полного алгоритма нормализации и не может проводить нормализацию автоматически, однако его возможности облегчают создание нормализованной модели данных. В первую очередь ERwin Examiner позволяет провести инспекцию структуры базы данных на предмет соответствия её общепринятым нормам проектирования в автоматическом режиме.

AllFusion Data Model Validator 7.1 (ранее: ERwin Examiner 4.1)

Скачать можно здесь

Обработка "СтруктураКонфигурацииIDEF1c.epf"

ERwin examiner позволяет провести анализ модели данных на основе экспертных данных заложенных в программу разработчиками. Не смотря на то, что средства ERwin не могут сказать как нужно делать, они могут сказать как делать не нужно. Использование средств валидации схем баз данных позволяет на собственном опыте решения практических задач впитать лучший опыт разработки.

Методология IDEF1X включает в себя графическое представление отношений между сущностями. Являясь проекцией стандарта IDEF1 на физический уровень баз данных, который позволяет вести как прямую разработку структуры базы данных в терминах конкретной СУБД так и обратный реинжениринг, методология IDEF1X позволяет переносить модели из одной СУБД в другую.

Для целей документирования структуры данных платформы 1С мной была разработана нотация IDEF1c. Простая и очевидная текстовая структура вот уже 5 лет помогает закрывать бреши в технологическом обеспечении платформы 1С. Данный инструмент не претендует на полноту - это скорее попытка начать диалог на эту тему заинтересованных разработчиков.

Операции:

Подсистема - Выбор "подсистемы" для анализа объектов конфигурации. При смене подсистемы, объекты дописываются в конец списка.
Очистить - Очистить список объектов для последующего добавления объектов конфигурации.
Обновить - Добавить в конец списка объекты указанной подсистемы.
Добавить зависимый элемент в общий список - Переместить из нижнего списка зависимых объектов в список объектов конфигурации для дальнейшей печати.
Удалить - Удалить текущий объект из списка.
Печать всего списка - Печать всего списка объектов конфигурации.
Печать выделенного списка - Печать только выбранных элементов из списка объектов
Сохранить - Сохранить список объектов конфигурации в xml-файле, для последующего использования
Открыть - Загрузить спискок объектов конфигурации из xml-файла.

Обработка позволяет не только печать список объектов в формате IDEF1c, но и обмениваться списком в формате xml-файла для облегчения коммуникаций между разработчиками.

Пример, представления объектов конфигурации в формате IDEF1c:

Данная обработка работает в обычной и управляемых формах, версия платформы 8.2.13.219 и выше. Может использоваться как внешняя обработка, что делает её удобным инструментом для исследовальских работ чужих конфигураций.

Нормализация; Нормальные формы; idef1x

+137 –

См. также

SALE! 15%

Infostart Toolkit: Инструменты разработчика 1С 8.3 на управляемых формах

Инструментарий разработчика Роли и права Запросы СКД Программист Платформа 1С v8.3 Управляемые формы Запросы Система компоновки данных Конфигурации 1cv8 Платные (руб)

Набор инструментов программиста и специалиста 1С для всех конфигураций на управляемых формах. В состав входят инструменты: Консоль запросов, Консоль СКД, Консоль кода, Редактор объекта, Анализ прав доступа, Метаданные, Поиск ссылок, Сравнение объектов, Все функции, Подписки на события и др. Редактор запросов и кода с раскраской и контекстной подсказкой. Доработанный конструктор запросов тонкого клиента. Продукт хорошо оптимизирован и обладает самым широким функционалом среди всех инструментов, представленных на рынке.

10000 руб.

02.09.2020 159318 872 399

861

SALE! 15%

Database Compression Tool (DCT) Универсальный инструмент сжатия, свертки и конвертации баз данных 1С

Инструментарий разработчика Чистка данных Свертка базы Инструменты администратора БД Системный администратор Программист Руководитель проекта Платформа 1С v8.3 Конфигурации 1cv8 1С:Управление торговлей 10 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 Россия Платные (руб)

Инструмент представляет собой обработку для проведения свёртки или обрезки баз данных. Работает на ЛЮБЫХ конфигурациях (УТ, БП, ERP и т.д.). Поддерживаются управляемые и обычные формы. Может выполнять свертку сразу нескольких баз данных и выполнять их автоматически без непосредственного участия пользователя.

~~8400~~ 7140 руб.

20.08.2024 7738 55 22

OneDebugger - инструмент для отладки кода в 1С без использования конфигуратора

Инструментарий разработчика Программист Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

Инструмент для написания и отладки кода в режиме «1С:Предприятие». Представляет собой консоль кода с возможностью пошаговой отладки, просмотра значений переменных любых типов, использования процедур и функций, просмотра стека вызовов, вычисления произвольных выражений на встроенном языке в контексте точки останова, синтаксического контроля и остановки по ошибке. В консоли используется удобный редактор кода с подсветкой, контекстной подсказкой, возможностью вызова конструкторов запроса и форматной строки.

9360 руб.

17.05.2024 23401 68 45

117

SALE! 15%

Infostart DataFormWizard: Управление данными и формами в 1С 8.3

Инструменты администратора БД Инструментарий разработчика Роли и права Программист Платформа 1С v8.3 Конфигурации 1cv8 Россия Платные (руб)

Расширение позволяет без изменения кода конфигурации выполнять проверки при вводе данных, скрывать от пользователя недоступные ему данные, выполнять код в обработчиках. Не изменяет данные конфигурации, легко устанавливается практически на любую конфигурацию на управляемых формах.

~~10000~~ 8500 руб.

10.11.2023 10401 36 20

SALE! 15%

Infostart PrintWizard - создание и редактирование печатных форм в 1С 8.3

Пакетная печать Печатные формы Инструментарий разработчика Программист Платформа 1С v8.3 Запросы 1С:Зарплата и кадры бюджетного учреждения 1С:Конвертация данных 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 Платные (руб)

Инструмент, позволяющий абсолютно по-новому взглянуть на процесс разработки печатных форм. Благодаря конструктору можно значительно снизить затраты времени на разработку печатных форм, повысить качество и "прозрачность" разработки, а также навести порядок в многообразии корпоративных печатных форм.

~~22200~~ 19980 руб.

06.10.2023 15379 35 7

SALE! 35%

PowerTools: Инструменты администратора 1С 8.3

Инструментарий разработчика Инструменты администратора БД Системный администратор Программист Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Россия Платные (руб)

Универсальный инструмент программиста для администрирования конфигураций. Сборник наиболее часто используемых обработок под единым интерфейсом.

~~4800~~ 3120 руб.

14.01.2013 187959 1138 0

912

SALE! 15%

Бустер Конвертации данных 3 (Infostart Toolkit)

Инструментарий разработчика Программист 8.3.14 1С:Конвертация данных Россия Платные (руб)

Расширение для конфигурации “Конвертация данных 3”. Добавляет подсветку синтаксиса, детальную контекстную подсказку, глобальный поиск по коду.

~~15000~~ 12750 руб.

07.10.2021 17295 6 32

Менеджер конфигураций 1С

Инструментарий разработчика Программист Платные (руб)

Менеджер конфигураций 1С — альтернативный стартер информационных баз 1С:Предприятие.

1800 руб.

21.02.2023 7688 8 35

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. fishca 1259 09.04.14 12:30 Сейчас в теме

Не будем далеко ходить. Для примера возьмем наш горячо любимый Инфостарт, с которым вечно, что-то не так. Давайте обратим внимание на показатели рейтинга. В один и то же момент времени они показывают разные значение: 187,179, 183. Как такое может быть? Отчет очень простой - данные об одном и том же атрибуте хранятся в трех различных местах. Можно себе представить, что твориться внутри, если снаружи основной ключевой показатель выглядит таким образом?

Про инфостарт ты загнул, звездочки и рейтинг никак не связаны друг с другом. Звездочки показывают количество твоих голосов отданных за публикации. А рейтинг рассчитывается сложным образом в зависимости от вида публикации. Это совершенно разные показатели. И прежде чем публиковать такую "туфту" для начала бы надо было проконсультироваться с Доржи или разобраться самому.

2. Diversus 2329 09.04.14 13:04 Сейчас в теме

(1) Раньше были несоответствия с рейтингами, подтверждаю. Сейчас пофиксили вроде бы.

4. Evgen.Ponomarenko 568 09.04.14 15:03 Сейчас в теме

(2) Diversus,
Не... не пофиксили ))) После публикации данной статьи рейтинги из обоих источников синхронизировались... похоже на то, что рейтинги пересчитывают после публикации новой статьи. Это моя личная версия. Со временем показатели снова начнут "разбегаться" пока не будет опубликована новая статья.

5. fishca 1259 09.04.14 16:14 Сейчас в теме

(4) еще раз повторюсь это разные показатели
звездочки - это сколько раз ты проголосовал за публикации
рейтинг - это сколько раз за тебя проголосовали

разница на лице, не вижу предмета для обсуждения.

6. Evgen.Ponomarenko 568 09.04.14 16:48 Сейчас в теме

(5) fishca,
о звездочках речь уже не идет... (это была моя опечатка... ну глюканул яяяя)
речь идет о том, что один тот же рейтинг в различных источниках показывает разные значения...

хех... вообще речь в статье шла о сооооовсем другом ))) о системном подходе, системах моделирования аналогичным ErWin стандарте проектирования IDEF1х и обработке СтруктураКонфигурацииIDEF1c.epf, которая позволяет печать структуру конфигурации.

3. Evgen.Ponomarenko 568 09.04.14 13:05 Сейчас в теме

(1) fishca,
Может и перегнул... но на то были причины
1) Мои обращения в тех. поддержу
Тикет #5263 Очень странно обновляется статья после редактирования
Тикет #5262 Ошибка рейтинга
Остались без реакции.

Я и не собирался публиковать этот обзац... но реально ДОСТАЛО! Давно не публиковался...но столько ГЛЮКОВ уже реально вывело из себя...

Скажем так, повод был выбран специально, чтобы обратить внимание Дорджи на ситуацию.

2)

А рейтинг рассчитывается сложным образом в зависимости от вида публикации.

Я не исключаю сложность, но в данном случае, я просто наблюдаю глючность... время от времени эти показатели, показывают одно и то же значение... потом разбегаются... потом снова показывают одно и то же. Замечено, что полный пересчет происходит после добавления новой статьи. Тогда показатели начинают совпадать. Не знаю... это мои личные наблюдения.
Мне в общем-то все равно, какой у меня рейтинг +/- 10 единиц не имеют значения. Мне важен сам принцип надежной разработки приложений.

3) Вот скажите, вы можете описать каким образом расчитываются эти показатели?
И привести алгоритм по которому можно оценить достоверность ваших доводов?

7. marsohod 123 10.04.14 02:46 Сейчас в теме

Статья великолепная. Хотя и отличается от классики (Дейт, например).
Но мне показался спорным один момент:
"Первичный ключ не должен относиться к внешнему миру".
Если для табельного номера это абсолютно верно, то например для ИНН, мне кажется, уже неверно. Или, скажем, для отпечатка пальца :) Такие уникальные характеристики из внешнего мира могут и, наверное, должны использоваться как первичный ключ. Это дополнительная гарантия верности данных, ускорение их обработки и уменьшение накладных расходов на хранение.

Ответить

8. zqzq 25 10.04.14 10:16 Сейчас в теме

(7) marsohod, использовать ли естественный (Natural) или искусственный (суррогатный, Surrogate) первичный ключ -- тут мнения расходятся. 1С выбрали искусственный первичный ключ (UUID) для объектных таблиц (справочники, документы), и естественный составной для регистров, таб.частей(?). (Преимущество UUID перед автоинкрементным очевидно для каждого, кто обменами данных занимался.) Из вашего же примера - ИНН может быть одинаковым для нескольких (подразделений) организаций - у них КПП разное, ИНН и КПП могут менятся со временем в связи с изменением законодательства или ещё чего. Так что искусственный ПК более универсален.

Ответить

10. Evgen.Ponomarenko 568 10.04.14 11:27 Сейчас в теме

(8) zqzq,
100-пудово ))) UUID - это большой шаг вперед, но если бы 1С внедрило его в табличные части и регистры сведений не было бы повода писать такие статьи.

11. Yashazz 4790 10.04.14 17:30 Сейчас в теме

(10) Глубоко внутри, может, у них и есть свои UUIDы. Хоть на уровне СУБД. Ведь и "УникальныйИдентификатор" далеко не сразу вытащили хотя бы в частичную доступность. Авось, однажды и мы до них из встроенного языка да из запросов дотянемся...
Статья хорошая, умная, только ненужная 95% одинэсников. Ибо есть программисты, архитекторы, разработчики, а есть 1С-ники... Которые не то что нормализацией заниматься не будут, а даже про индексы впервые слышат и хардкодят любую конкретику в исходниках и даже в свойствах сущностей. Увы.

12. Evgen.Ponomarenko 568 10.04.14 18:19 Сейчас в теме

(11) Yashazz,
Полностью согласен... Статья для архитекторов. Кодеры, скорее всего, столкнуться с траблами во время интеграции с другими системами. НО Я не мог её не опубликовать, я не мог идти дальше... было ощущение внутренней пустоты. Есть принцип концептуальной целостности, он предполагал именно такую последовательность изложений статей. У меня в черновиках лежат еще 6... теперь можно с чистой совестью продолжить. Честно говоря мне очень радует, что на ИС есть люди которые не только 1С-ят )))

17. zqzq 25 11.04.14 10:38 Сейчас в теме

(10) в том-то и дело, что, например, для независимого непериодического регистра сведений UUID - что для собаки пятая нога. Статья по теме не из мира 1С http://weblogs.sqlteam.com/jeffs/archive/2007/08/23/composite_primary_keys.aspx

19. Evgen.Ponomarenko 568 11.04.14 11:12 Сейчас в теме

(17) zqzq,
Согласен, что в 95% случаях - это пятая нога, но вот здесь бы она мне пригодилась

http://infostart.ru/public/201607/ Универсальный обмен между похожими конфигурациями

Ее отсутствие привело к тому, что я на тестирование механизма обмена регистров сведений потратил столько же
времени, как на тестирование всех других объектов 1С вместе взятых. Имхо - композитный ключ очень капризная штука )))

В свое время я участвовал в разработке генератора кода PL/SQL под ORACLE. Принцип был следующий: Сначала схема БД разрабатывалась
в ERwine, потом генерировался ею код DDL SQL. А наш генератор формировал код PL/SQL из DDL SQL,
что позволило сократить время разработки на треть. Дополнительно генерировались DDL SQL для исторических,
теневых таблиц вместе с кодом PL/SQL. Это стало возможно благодаря отказу композитных ключей. В дальнейшем я не раз сталкивался с побочными проблемами их использования, в том числе с проблемами производительности и синхронизации данных.

Так, что я их не использую принципиально, НОоооо ключ уникальности по копмозитному ключу - это святое дело.
В один 1С все в точности наоборот - в регистре сведений данные могут схлопнуться и бесследно исчезнуть в неизвестном направлении.

Я согласен, статья на об 1С... но кто сказал, что мы не можем творить историю?

9. Evgen.Ponomarenko 568 10.04.14 11:24 Сейчас в теме

(7) marsohod,
Очень меткий комментарий! Сразу видно, что человек в теме.

Цитата - Хотя и отличается от классики (Дейт, например).

О да! Если говорить о классиках, то стоит упомянуть Кодда, Дейта, Брукса.
Если работы Теслы позволили совершить так называемый второй этап промышленной революции,
то эти люди заложили фундамент для третей.
Поверьте, если бы мое виденье не отличалось в данном случае от представлений Дейта,
я бы не тратил свое личное время. Дейт был математиком и способ подачи материала соответствует.
Я бы сказал, что мое виденье более популярное и расширяет его работы в сторону "упрощения".
Меня познакомили с этой практикой ещё 20 лет назад. Она основана на принципах Дейта,
но уже включает в себя опыт практиков. Просто для оптимизации структуры выбраны более простые
и надежные целевые функции.

Но мне показался спорным один момент:
"Первичный ключ не должен относиться к внешнему миру".

В самую точку! До 98 года я даже об этом не задумывался ))) Зато сталкивался с проблемой, что рано или поздно
при изменении ТЗ программу нужно переписывать заново. Скажем так, на тот момент времени я гордился, что мои программы выдерживали в среднем до 5-ти серьезных смены ТЗ. И в основном это касалось не верно выбранного первичного ключа.

К сожалению, зачастую нам приходится автоматизировать "неопределенности" которые могут казаться на первый взгляд полностью "детерминированными". Но Мир и наши Представления о нем могут меняться...

Так, что для создания информационных систем которые могут эволюционировать без серьезных потрясений, стоит всегда использовать внутренний идентификатор. Причем, если система изначально построена на таких ключах, производительность только выигрывает. Плохо, когда часть ключей "естественные" а часть "суррогатные".

По поводу объема хранимых данных - тут не стоит заморачиваться... сейчас технический прогресс успевает за потребностями.А вот если искажать структуру данных для решения чисто технологических задач, то мы рискуем создать программу-однодневку.

А в остальном, огромное спасибо за коммент, он позволил глубже раскрыть тему! )

13. awk 744 10.04.14 22:13 Сейчас в теме

(0) Класс. Мало стоящего на инфостарте стало публиковаться последнее время... Еще бы перечислить минусы нормализации...

14. Evgen.Ponomarenko 568 10.04.14 23:00 Сейчас в теме

(13) awk,

Еще бы перечислить минусы нормализации...

Мне трудно говорить о минусах нормализации...
это скорее процесс эволюции перехода от хаоса к нормализации, от нормализации к денормализации.

Я бы говорил о плюсах денормализации, как осознанных шагов после нормализации.

И все же, если говорить об ограничениях, то:
1.Нормальные формы больше подходят к статике, чем к динамике.
2.Нормальные формы имеют большее количество таблиц, что создает иллюзию сложности.
3.Чрезмерное увлечение ограничениями NOT NULL ухудшает юзабельность приложения.
4.Принцип "одна сущность - одна основная таблица" ограничивает универсальность решения.

Ну, а в остальном... главное - это обойтись без фанатизма.
Нормальные формы - это всего лишь еще одна полезная модель.

15. Famza 85 11.04.14 10:15 Сейчас в теме

Автору спасибо за статью.

...тема нормализации отношений БД в публичных источниках до сих пор не раскрыта.

Когда читал про нормализацию в книге Пола Нильсена "Microsoft SQL Server 2005. Библия пользователя" то все было понятно, но как только закончилась глава - так и забылось. Считаю из-за отсутствия практики, а в 1С грамотный программист на автомате будет правильно разрабатывать схему. Но это не значит, имхо, что программист 1С не обязан помнить об этом. Особенно когда основной стала клиент-серверная версия программ 1С.

16. Evgen.Ponomarenko 568 11.04.14 10:32 Сейчас в теме

(15) Famza,
Если говорить о Микрософте, то популярно нормальные формы они объясняют здесь:

http://support.microsoft.com/kb/283878/ru

Но человек устроен так, что познание происходит через практику...
Я то же с трудом вспоминал, когда-то давным давно усвоенные принципы.
Но это как на велосипеде: нужно один раз научиться ездить - тогда не забудешь )))

18. alex_sayan 51 11.04.14 11:02 Сейчас в теме

Насколько мне известно, нормализация используется только в стенах образовательных учреждений... В промышленных БД сплошь и рядом денормализация. У фирмы 1С даже есть рекомендация по самодостаточности регистров.

20. Evgen.Ponomarenko 568 11.04.14 11:19 Сейчас в теме

(18) puzakov,

Насколько мне известно, нормализация используется только в стенах образовательных учреждений...

Это базовый курс

В промышленных БД сплошь и рядом денормализация.

Это для продвинутых

У фирмы 1С даже есть рекомендация по самодостаточности регистров.

Не верьте ))) у меня 80% рекомендаций 1С вызывают сомнения, а учебные курсы от 1С вызывают фатальный когнитивный диссонанс.
Хотя... регистры 1С действительно самодостаточны... а регистры накопления - это технологический прорыв ))))

Просто нужно слушать свой разум ))))

21. Азбука Морзе 106 11.04.14 15:05 Сейчас в теме

Третья нормальная форма? Как же, помню: курсовая, третий курс. То же мне откровение.

22. Evgen.Ponomarenko 568 11.04.14 20:54 Сейчас в теме

(21) Азбука Морзе,
))) Небось лабы препод проверял или все таки пользовались ERwin Examiner? ;)

В принципе статья получилась многоцелевая. К ней идет обработка, которая помогает документировать структуры 1С. Простая вещь, но очень полезная...

23. ManyakRus 489 11.04.14 22:43 Сейчас в теме

Написано всё правильно :)
Знать Правила нормализации это самое важное для любого программиста !

мелкие замечания:
1) "не должны содержать избыточную информацию..." - это в 1ом правиле, а не в 3ем
2) "Первичный ключ.." - это 2ое правильно, а не 1ое
3) "В зависимой таблице добавьте внешний ключ.." - это 3ее правило, а не 2ое
4) "..по принципу «один ко многим»" - это больше относится к 4ому правилу: запрещается связь многие ко многим

5) UUID в 1с не первичный ключ т.к. не может обеспечивать полную функциональную зависимость, в т.ч. нельзя использовать в запросах и др.
Код справочника тоже не первичный ключ т.к. может повторяться почему-то в 1С 8.2.
В регистрах составной ключ тоже не подходит т.к. нарушает второе правильно нормализации о том что запрещается иметь незаполненные значения в составном первичном ключе.
В 1С нет первичного ключа совсем нигде :(

24. Evgen.Ponomarenko 568 11.04.14 23:41 Сейчас в теме

(23) ManyakRus,
Ваша наблюдательность делает Вам честь )))

1) "не должны содержать избыточную информацию..." - это в 1ом правиле, а не в 3ем

я скорее всего имел ввиду, что это справедливо и для 1-й и для 3-й форм, причем для всех связанных таблиц одновременно.

2) "Первичный ключ.." - это 2ое правильно, а не 1ое
3) "В зависимой таблице добавьте внешний ключ.." - это 3ее правило, а не 2ое
4) "..по принципу «один ко многим»" - это больше относится к 4ому правилу: запрещается связь многие ко многим

В классике так и есть ))) я намеренно поменял местами операции, так как они отражают последовательность практических действий. В принципе, в целях нормализации смысл имеет только третья нормальная форма, сами по себе промежуточные 1-я и 2-я пользы приносят мало. А учитывая, что 3-я форма включает в себя 2-ю и 1-ю, суть от перестановки не меняется.

26. ManyakRus 489 14.04.14 13:52 Сейчас в теме

(24)
.."суть от перестановки не меняется"

Как раз суть и меняется. Без правильной нумерации невозможно будет кратко сказать что именно неправильно типа "нарушение первого правила нормализации" а придётся долго объяснять что это такое тем кто не знает и не хочет ничего знать.

27. Evgen.Ponomarenko 568 14.04.14 14:34 Сейчас в теме

(26) ManyakRus,
))) та как скажите...

что это такое тем кто не знает и не хочет ничего знать.

Статья не для тех кто не хочет знать, а для тех кто набил шишки )))
Насильно учить - зря тратить время.
Подсознательные фильтры восприятия делают свое дело.

Если не дошло - значит субъект еще не созрел ;)

Время все расставит все по своим местам. Может лет через 5 вспомнит ваши или мои слова...
и подумает!!! Таки да!!!
Или еще лучше - решит, что это он сам все придумал ))))))

25. Evgen.Ponomarenko 568 12.04.14 00:15 Сейчас в теме

(23) ManyakRus,

5) UUID в 1с не первичный ключ т.к. не может обеспечивать полную функциональную зависимость, в т.ч. нельзя использовать в запросах и др.

Немного не понял...
предлагаю обратиться к http://ru.wikipedia.org/wiki/GUID

Если wiki©:«GUID» называют некоторые реализации стандарта, имеющего название Universally Unique Identifier (UUID).

Тогда ССЫЛКИ в 1С могут играть/играют роль первичных ключей и могут использоваться/используются в запросах...

65. MariusUrsus 22.03.18 23:14 Сейчас в теме

(23)

UUID не является первичным ключом только лишь с точки зрения СУБД, однако с точки зрения метаданных 1С это первичный ключ. Правда называется он Ссылка (поле _idrref). А Ссылка на уровне СУБД и есть UUID, который в пользовательском представлении оборачивается Представлением (поле _description) ссылки (ранее только Кодом/Наименованием и т.д., с недавнего времени представление можно определять в модуле менеджера).

28. wolfsoft 2421 16.04.14 08:52 Сейчас в теме

Не знаю, как в "педии", а в ВУЗ-ах на профильных специальностях ещё в первой половине 90-х за нормализацию "ответку держали" :)

29. Evgen.Ponomarenko 568 16.04.14 10:20 Сейчас в теме

(28) wolfsoft,
На самом деле качество "ответки" очень зависит от преподавательского состава конкретного вуза.
К тому же не каждый выпускник профильного факультета работает программистом, и не каждый программист
имеет профильную специальность.

А по поводу "педии" - я с вами согласен на все 100%
Это так... чисто для "навигации", не более того.

30. idhas 11 16.04.14 15:19 Сейчас в теме

В принципе, когда с sql/delphi переходил на 1с, то меня тоже мучил этот вопрос. Сейчас делаю так: если в 1с надо контролировать уникальность ключа на уровне платформы, то я использую регистры сведений (непериодический, независимый), где измерения (обязательно notnull) - части ключа (на сколько помню, PK может быть составным), а реквизиты- данные. И тогда при попытке записи одинакового набора измерений система выдаст ошибку. Ничего более подходящего я не нашел :)

31. Evgen.Ponomarenko 568 16.04.14 16:04 Сейчас в теме

(30) idhas,
Как вариант... Правда, если форма получает сообщение об ошибке от платформы, её не по-детски клинит )))
Я обычно проверяю в событии формы ПередЗаписью. Так помягче получается: и сообщение можно внятное выдать и курсор в поле перекинуть легче.

32. wunderland 202 17.04.14 13:01 Сейчас в теме

Отличная статья. Сейчас осознал что еще с института НФ въелись в сознание как татуировка в кожу (преподам отдельное спасибо). Но как любую татуху нужно подновлять, так что автору респект.
Вот только не нужно забывать, что есть программисты 1С, которые кроме 1С больше нигде не программировали... Для них здесь будет не все понятно.

33. Evgen.Ponomarenko 568 17.04.14 13:32 Сейчас в теме

(32) wunderland,
В 10-ку!!! Я надеюсь, что узким 1С специалистам будет хороший повод задуматься на тему расширения своего кругозора )))

34. FractonKireyev 21.04.14 13:05 Сейчас в теме

Я отношусь к тем, кто "денормализацию выполняет на лету в своей голове" (цитата из статьи).
Наверно поэтому заметил несоответствие в данной статье.

В описании третьей нормальной формы автор пишет:

3. Все поля стремятся быть not null

В описании связи один к одному:

3. Хранения данных, которые относятся только к части основной таблицы.

Эти два утверждения противоречат:

использование связи один к одному есть нарушение требований к третьей нормальной форме

(из описания связи один к одному). Я считаю, что никакого нарушения требований к третьей нормальной форме здесь нет.

Несколько абсурдный (с точки зрения реальных потребностей), но тем не менее вполне адекватный пример:
Допустим, нам для каких-то целей надо хранить информацию о документе заключения действующего в настоящий момент брака (дата, город, номер, наличие и параметры брачного договора, ...). Поскольку многоженство у нас запрещено, то супруг(а) может быть только в единственном числе, либо не быть вообще. Следовательно, такой документ либо есть, либо его нет.
Если хранить информацию о документе в основной таблице - то это будет нарушением

3. Все поля стремятся быть not null

(для тех, у кого документа заключения брака нет - все поля описания будут null).
Здесь хорошо поможет

3. Хранения данных, которые относятся только к части основной таблицы.

- для сотрудника, у которого такой документ есть, в таблице описания документов будет одна (!) запись соответствия записи в таблице сотрудников (связь 1:1). А для сотрудника, у которого нет документа о заключения брака - такой записи в таблице описания документа не будет.

Таких примеров можно привести достаточно много: информация об удалении аппендицита (остальные не интересуют); дачный участок в кооперативе "АБВГД"; информация о выходе на пенсию (дата, последнее место работы, сумма, причина, ...); личный рекорд в покорении горных вершин до поступления на работу; ...

Просьба к автору прокомментировать данный пост.

35. Evgen.Ponomarenko 568 21.04.14 18:23 Сейчас в теме

(34) FractonKireyev,
Честно, говоря в целом - вы абсолютно правы. Однако я не могу понять, каким образом вам удалось вырвать из контекста мои фразы и скомпилировать такой логичный вывод. По поводу вашего примера, хочу сказать, что он действительно не очень подходящий, хотя и интересный. Во-первых в течении некоторого времени сотрудник мог иметь несколько браков. Во-вторых, в реальной жизни действительно могут быть двоеженцы нарушающие законы, а отразить факт предметной области, при такой реализации схемы БД, у вас вряд ли получится. На самом деле, я больше говорил о тенденциях, чем о жестких правилах. Ибо тогда статья разрослась бы до невиданных размеров.

Однако, если абстрагироваться от примера - вы, еще раз хочу подчеркнуть, вы абсолютно правы. Мало того, такая схема решения очень часто встречается, когда нужно раскрыть некоторые подробности по контрагенту. Мне кажется, у вас в голове находится непротиворечивая модель, которая позволяет вам принимать рациональные решения. Она может немного в деталях отличаться от моей, но в целом, такая же. Я мог неудачно выразиться, либо моя модель наложилась на вашу не очень удачным способом. Но в любом случае, цель моей статьи была достигнута. Во первых, мне удалось выговориться, во вторых, найти единомышлеников, в третьих обозначить тему для классических 1с-ков.

Просьба к автору прокомментировать данный пост.

Мне его трудно комментировать. Порой истину передать словами нет возможности, но на истину можно намекнуть. Мне кажется, что наши модели очень похожи, и мне не особо хочется углубляться в детали, чтобы разобраться в отличиях. Однако, если вам оооочень хочется, я могу вам составить компанию. Но тогда мне нужны более детальное описание корректного примера с вашим вариантом решения.
Ибо я не могу поставить себя на ваше место и пытаться анализировать самого себя. Поймите меня правильно.

36. qwinter 683 27.04.14 11:39 Сейчас в теме

Вообще странно, что не описана нормализация в рамках регистров накопления. Ведь по сути именно в них "типичный" 1С-ник и решает задачи нормализации. Ведь в зависимости от построения РН, он в рамках непосредственно СУБД может быть и 2, и 3 нормальной форме.

37. Evgen.Ponomarenko 568 27.04.14 12:35 Сейчас в теме

(36) qwinter,
))) Если, говорить о регистрах накопления, то я бы сказал, что это тема касается денормализации в классическом её понимании. Регистры накопления в большей степени соответствуют технологии OLAP, а там действуют свои принципы. В данном случае, я решил вынести обсуждение этой темы за рамки этой статьи. Кроме этого, структура регистров накопления должна отражать учетную модель предприятия. А модель предприятия как объект управления в 1С отсутствует как понятие, как в прочем и в подавляющем числе современных ERP-систем. Так, что перед тем, как пытаться раскрыть эту тему, стоит опубликовать еще как минимум три статьи.
А в целом, ваш вопрос вполне логичный. Я долго ждал: "Кто же его задаст?"

38. veretennikoff 34 13.05.14 14:35 Сейчас в теме

Данная обработка работает в обычной и управляемых формах, версия платформы 8.2.13.219 и выше

на УФ не запускается !!
получить форму на сервере...

39. Evgen.Ponomarenko 568 13.05.14 14:47 Сейчас в теме

(38) veretennikoff,
а подробнее можете описать ситуацию... чего пишет?

40. veretennikoff 34 14.05.14 16:46 Сейчас в теме

(39) ну я вам указал уже на ошибку "функция ПолучитьФорму() у вас написана на сервере"
ФормаУФ, строка 112

41. Evgen.Ponomarenko 568 14.05.14 17:50 Сейчас в теме

(40) veretennikoff,
Упс... режим запуска следует выбрать "толстый клиент", я понимаю, что это не фонтан, но пока так.

42. Evgen.Ponomarenko 568 15.05.14 09:49 Сейчас в теме

(40) veretennikoff,
Обработку поправил - теперь работает и в режиме "тонкого клиента" управляемой формы.

43. necropunk 9 15.05.14 12:34 Сейчас в теме

Интересно, а для целей разработки и автоматизации конфигурацию 1С:Система Разработки Прикладных Решений не пробовали использовать? Просто когда-то в ней проектировал, интересно ваше мнение.

44. Evgen.Ponomarenko 568 15.05.14 14:34 Сейчас в теме

(43) necropunk,
Если вы имеете в виду "Система проектирования прикладных решений" СППР,
то на мой взгляд - это правильное направление движения, но не актуальное.
К тому же 1С:СППР получился громоздким, как с точки зрения конфигурации, так и методики.

Мне больше нравится 3D подход - см. Эрика Эванса «Предметно-ориентированное проектирование (DDD)».
(англ. Domain-driven design)

1С:СППР предполагает конструирование с помощью кирпичиков согласно заранее согласованного проекта.
3D подход предполагает использование готовых унифицированных независимых блоков(шаблонов)

В своих разработках я уже более 5 лет использую "виртуальную машину", которая решает следующие задачи:
Позволяет формировать формы ввода/вывода на лету. Осуществляет мониторинг ВСЕХ действий пользователей и программистов.
Осуществляет взаимодействие между постановщиком/разработчиком/пользователем/администратором проекта в одном флаконе с привязкой к конкретным объектам конфигурации, с возможностью создавать на основе "заявки пользователя" контрольные примеры и FAQ.
"Виртуальная машина" позволяет вести документацию в автоматическом режиме. Согласованное техническое задание ложится в базу и полностью определяет поведение системы. Таким образом реализуется подход "что заказал - то и получил".
К слову сказать 3-е поколение виртуальной машины предполагало 80 тыс кода,а 4-е поколение по прогнозам должно уложиться в 20 тыс.
То есть, наблюдается упрощение внутренней структуры без потери функциональности.

На фоне выше сказаного, 1С:СППР воспринимается мной как доисторическим монстром.

45. awk 744 16.05.14 00:35 Сейчас в теме

(44) 1С:СППР - без автогенерации конфигурации - мартышкин труд.

46. Evgen.Ponomarenko 568 16.05.14 01:07 Сейчас в теме

(45) awk,
Что ты имеешь ввиду?

47. necropunk 9 16.05.14 15:04 Сейчас в теме

(46) думаю, имеется в виду, что при окончании проектировании на уровне метаданных - система должна сама собирать эти метаданные в цельную конфигурацию, с чем я, в общем-то согласен.

48. Evgen.Ponomarenko 568 16.05.14 15:17 Сейчас в теме

(47) necropunk,
Если в этом контексте, то я тоже спорить не буду. Правда возникают вопросы чисто практического значения:
1) В этом случае проект конфигурации на СППР должен проектировать с нуля, либо полностью определять отдельную подсистему либо СППР должна поддерживать функцию реверсинжениринга. В противном случае не получится собрать работоспособную конфигурацию и придется снова вышивать ручками.

2) Я имел в виду другое, в случае с виртуальной машиной, проект является исполняемой структурой. Для актуализации изменений достаточно выйти/войти в прикладной объект.

51. awk 744 17.05.14 00:55 Сейчас в теме

(46) Я работал с этой системой и заметил у нее два ключевых недостатка:
1. Это отсутствие возможности вести несколько проектов.
2. Это отсутствие генерации конфигураций на основе проделанного описания. То есть сначала один вбивает все в СППР, а потом другой тратя то же время вбивает в конфигуратор. То есть все то же самое первый мог сделать в любой другой системе.

52. Evgen.Ponomarenko 568 17.05.14 15:03 Сейчас в теме

(51) awk,
Спасибо за информацию! Честно говоря, особо надежд по поводу СППР не питал, но...

1. Это отсутствие возможности вести несколько проектов.

Как же ж так??? (риторически пожимая плечами...) это ж самое вкусное!

2. Это отсутствие генерации конфигураций на основе проделанного описания.

Ну и на кой... она такая сдалась? (еще больше округляя глаза)

Нет... теперь точно на досуге поковыряю СППР, что-то ж в ней полезное должно быть?!

53. awk 744 17.05.14 17:33 Сейчас в теме

(52) У нее есть только одно полезное качество - это первый шаг. Если будет последним то...

49. necropunk 9 16.05.14 19:01 Сейчас в теме

Реверсинженеринг она поддерживает (ну, там допилить правда немного приходится), а вот собирать она уже не умеет. Ну, не умела, по крайней мере.
Виртуальная машина - хорошо, конечно. У нас примерно так же организовано, но не опишешь в двух словах. Попытался, но понял что пустое все и стер :)
В общем, да, СППР - попытка хорошая, но до ума не доведенная, а лучшие решения - собственноручно выстраданные :)))

50. Evgen.Ponomarenko 568 16.05.14 21:36 Сейчас в теме

(49) necropunk,
та...да.

54. webester 26 30.05.14 16:32 Сейчас в теме

Не согласен со следующими моментами:

Материал есть, причем достаточно фундаментальный и подробный, при желании можно почитать ответы гугла, на тему "Принципы построения реляционных баз данных", "основы реляционных баз данных" и тд, "там можно вводить разные слова" (с)кто из толпы.

Все бы ничего, но проблемы возникают во время интеграции с реляционными СУБД, в частности при обмене данными с web-сайтом на базе mySQL

Значит у вас ошибки в проектировании. Если вы пытаетесь обменяться движениями регистра накопления(или любого другого) с вебсайтом. У регистров единственная цель: ускорить и упростить формирование отчетов. Разумеется использование регистров увеличивает время записи документов. И тут чем быстрее тем лучше, поэтому в топку все лишние сущности, так же они не нужны при получении остатков\оборотов, отсутствие идентификатора здесь плюс а не минус. При использовании не по назначению, получаем вышеообозначенные траблы.

55. Evgen.Ponomarenko 568 03.06.14 18:00 Сейчас в теме

(54) webester,
Хороший ресурс... качественный, в теории. Но вся проблема заключается в том,
что именно поиск корректных практических примеров реализации третьей нормальной формы оказался безрезультатным.

http://www.askit.ru/custom/db_basics/m4/04_05_3rd_form.htm
В данном конкретном случае в вашем источнике налицо вопиющие нарушения принципов 3НФ:
1) в результате нормализации были появиться как минимум пять таблиц, а не две:

2) За связь по полю "Наим." просто бил бы кривым ручкам.
3) А где первичные и вторичные ключи?

Вообще-то за такие примеры нужно лишать лицензии.
К теоретической части вопросов нет, очень хорошо проработана.
Вывод: Примеры писал либо аспирант, либо преподаватель-теоретик.
Это хорошо видно по его любимой фразе: "Переводя на человеческий язык:" и следующими за ней рекомендациями.

А вообще спасибо за пост - он еще раз подтверждает актуальность темы с одной стороны и тезис "век живи - век учись!" с другой стороны. На самом деле учебники содержат море ошибочных посылов - нужно быть всегда на чеку.

56. mixsture 17.10.14 14:13 Сейчас в теме

Про регистры сведений: я подозреваю, что при их создании в 1с немного свалили в кучу необходимость уникальности записей по измерениям (просто уникальный ключ) и первичный ключ (который для производительного решения должен быть минимальным, но чтобы его хватало). Так и вышло, что решили все сделать первичным ключом.

Добавлю, что в реальных системах много ненормализованных данных - и это почти всегда погоня за производительностью. База в 3х нормальных формах предполагает, что при запросе данных из нее - все они будут в реальном времени получены и скомпонованы, а эта операция может быть неимоверно долгой, поэтому расчет некоторых промежуточных итогов переносят на другой момент времени (на запись). Система быстрее выбирает данные, но медленнее пишет.

На уровне БД: все дополнительные индексы, кроме первичного - есть создание отдельной таблицы для быстрого поиска и поэтому потеря НФ (дублирование данных).
Любые кэширования данных есть потеря НФ (дублирование данных).
На уровне 1с:
Кроме "странных" ключей регистров сведений и таблиц итогов регистра накопления - есть еще вынос тяжелых данных в отдельные справочники или РС (например, присоединенные файлы в варианте, когда связь один-к-одному) - тоже потеря НФ (сущность расползлась на 2 таблицы).
Еще у меня припоминается реквизит СуммаДокумента - который рассчитывается на основании табличной части. (тоже по сути хранение заранее посчитанных итогов).

59. caponid 24.10.14 11:31 Сейчас в теме

(56) mixsture,

Еще у меня припоминается реквизит СуммаДокумента - который рассчитывается на основании табличной части. (тоже по сути хранение заранее посчитанных итогов).

Это некорректное сравнение - сумма это одна из основных сущностей документа и может не равнятся (если принята другая бизнес логика) посчитанным итогам ТЧ документа.

И является правильным применением "денормализации"

60. mixsture 31.10.14 16:31 Сейчас в теме

(59) caponid, соглашусь, что сумма документа может не равнятся итогам по ТЧ. Но она все равно вычисляется на основе итогов по ТЧ и другим реквизитам, а значит хранить ее отдельно - это "задваивание информации" => транзитивная зависимость (реквизит зависит от другого реквизита, а должен зависеть только от ключа) => потеря 3 НФ. Разве не так?

61. ManyakRus 489 31.10.14 22:13 Сейчас в теме

(59) caponid,
1ая НФ запрещает не только дублирование информации, но и детерминированные значения, когда одно вычисляется из другого,
поэтому СуммаДокумента нарушает 1НФ

57. Puk2 190 20.10.14 10:16 Сейчас в теме

За обработку спасибо и "плюс"! Как раз понадобилась для нестандартной задачи, ~~напугать~~ показать людям, что номенклатура и её настройка для производства это не "два пальца...". А то руководство считает, что оно "разбирается" в ИТ и даже когда-то сисадминило/программировало, поэтому номенклатура в ERP это несложно...

62. Evgen.Ponomarenko 568 09.11.14 19:04 Сейчас в теме

Удивительно наблюдать как статья уже живет своей жизнью, обрастая своими идеями, которые и в голову не приходили. Одно это уже стоило того, чтобы дать ей жизнь.

(57) Puk2,

За обработку спасибо и "плюс"! Как раз понадобилась для нестандартной задачи

А еще с её помощью удобно общаться с подчиненными, и также печатать обои на стену, когда схемы объектов уже заняли всю рабочую поверхность стола. (К стати такие обои оказывают потрясающее впечатление как на начальство, так и на пользователей)

(56) mixsture,(59) caponid, (61) ManyakRus,

СуммаДокумента

Зачет! Спасибо всем за диалог.
На самом деле если бы 1С поддерживала конструкцию "CRЕATE VIEW", то нормальность 1С бы значительно повысилась. Не смотря на шаги в верном направлении http://v8.1c.ru/o7/201401query/index.htm я бы на месте 1С уже давно встроил "тексты запросов" как объект конфигурации.

58. МихаилМ 20.10.14 11:33 Сейчас в теме

непонятно , для кого написана статья . Нормализация входит в курс основы работы с бд
уже лет 20. этот курс читается для всех ит специальностей.
а программистам "от сохи" нормализация вряд ли не нужна.

63. slazzy 42 23.01.15 12:42 Сейчас в теме

(58) МихаилМ, ну например для меня :) или для половины всех существующих 1Сников, тк в основном все мы не имеем ИТ образования. И лично меня тема правильной разработки и проектирования интересует довольно сильно :)

(62) За статью спасибо, интересно для начала, но явно недостаточно. Для таких как я, без образования, но с желанием, она указывает верный путь дальнейшего обучения. Вроде бы как раз после первого прочтения этой статьи я полез в книги и видеокурсы, зарегистрировался на sql-ex и стал потихоньку догонять вумных программистов. После второго прочтения - сегодня, в целом стало ещё понятнее.

64. Evgen.Ponomarenko 568 24.01.15 17:22 Сейчас в теме

(63) slazzy,

После второго прочтения - сегодня, в целом стало ещё понятнее.

Всему свое время )) Тем более, что утро вечера мудренее... При том, что обучение процесс последовательный, а целостно-концептуальное озарение/осознание ближе к параллельным процессам.
Рад, что нашему полку - прибыло ;)

66. NAlex 6 23.02.21 21:19 Сейчас в теме

Интересный взгляд на нормализацию.
Где-то в начале миллениума в МГУ на факультете ВМК слушал полуторогодовой курс Основый теории СУБД у Кузнецова Сергея Дмитриевича
Из этого курса я вынес следующее:
1. Нормализация - это требования к таблице в единственном числе. Т.е. когда говорят о соответствии какой-то нормальной форме, то речь идет о таблице (отношении - в терминах теории СУБД), а не о связах этих отношений. Говорят - таблица не приведена к 3НФ.
2. Первая НФ - это атомарность полей отношения, которые назвают доменами, если к ограничению значения в поле в виде типа добравляют ограничение этого типа. Например, тип Число плюс доп. ограничение числа неотрицательные.
3. Вторая НФ - это выполнение требований первой НФ плюс зависимость полей отношения от первичного ключа (ПК). Т.е. данные всех полей одной таблицы должны зависить от ПК. Причем, объяснялось это как раз для случаев, когда превичные ключи составлялись из наборов полей таблицы.
4. Третья НФ - это выполнение требований второй НФ плюс отсутствие транзитивной зависимости от ПК. Т.е. данные в поля А зависят от ПК, а данные в поле В зависят от поля А, но не зависят от ПК.