Здравствуйте форумчане!
Задумался о построении БД в своем отделе.
В отделе 7 человек, из этих 7-и сотрудников знания эксель только у двоих отличные.
По этой причине ни о каком уходе из файлов эксель в другие СУБД не может быть и речи.
Из 7-и человек работать в этом смогут только двое да и не работать учиться)))
Остальные сотрудники кроме пользовательского экселя ничему не обучаемые.
Это я к тому что прежде чем предлагать всякие MySQL, PostgreSQL и Power BI вы представляли реалии кто будет с этим работать.
Естественно, делать так чтобы в отделе работало только два человека в мои планы не входит.
По этой причине необходимо создать БД отдела максимально дружественную к пользователям Excel.
Уход в Access тоже не подойдет по тем же соображениям и плюс много сложной отчетности, которая должна быть построена на БД.
Осложняющим фактором является то, что нет устроявшейся формы отчетности, приходится то так сделать, то эдак.
По этой причине строить отчетность в Access нет никакого желания.
Имея такие вводные пришла идея выкручиваться следующим образом.
1. В отдельных xlsx файлах вести файлы-справочники. Один файл - один справочник. Например, в одном файле перечень договоров по подрядчикам, во втором файле реквизиты субподрядчиков, в третьем файле данные о ходе сдачи документации заказчику, в четвертом файле единичные расценки по видам работ, в пятом классификатор, присваеваемый виду работ и т.д.
В общем будет как-бы множество столбцов, но не в одной раздутой книге Эксель, а в некоем множестве книг. Эдакий конструктор, из которого 2-е сотрудников будут строить сложную отчетность по общему идентификатору (разную, в т.ч. по новым формам)
2. Всей файлы-справочники (вместо того чтобы использовать ВПР) связать через Access, но при этом не загружать их в сам Access, а только создать связанные таблицы.
4. На основании запросов power query к Access 2-е сотрудников смогут строить сложную отчетность для отдела (отчетность будет опят же строится в файлах эксель). При этом файлы отчетности будут не такие тормознутые как было ранее (не будет множества ВПР-формул), а самое главное в них легче наводить порядок если изменилось что-то в справочнике (не придется переделывать все отчеты). Кроме того наводить порядок смогут низкоквалифицированные сотрудники отдела - они смогут разобраться в файле-справочнике.
При такой схеме сотрудники, которые кроме экселя ничего не хотят знать, не останутся без дела - им я смогу вовлечь в наполнение файлов-справочников. Они смогут их подкорректировать при необходимости, так как это же знакомый им эксель!
В общем получается схема:
База эксель - Access для построения связей между справочниками в Excel - Запрос power query к Access - отчетность в Excel
Отдельно хочу пояснить почему не рассматриваю power pivot .
Строить модель данных в power pivot не подходит так как 1. Мне не нужна сводная таблица в отчетности. А выводить данных из pivota во что-либо другое, отличающееся от сводной таблицы, как я понял, не выйдет.
2. Проблематично подключиться через power query к модели данных power pivot. Получается система нипель туда закачать данные не вопрос, а обратно танцы с бубном.
Что посоветуете мне? Правильная ли моя идея идти к решению проблемы БД через Access?
Может есть какой-то другой подходящий инструментарий.
Задумался о построении БД в своем отделе.
В отделе 7 человек, из этих 7-и сотрудников знания эксель только у двоих отличные.
По этой причине ни о каком уходе из файлов эксель в другие СУБД не может быть и речи.
Из 7-и человек работать в этом смогут только двое да и не работать учиться)))
Остальные сотрудники кроме пользовательского экселя ничему не обучаемые.
Это я к тому что прежде чем предлагать всякие MySQL, PostgreSQL и Power BI вы представляли реалии кто будет с этим работать.
Естественно, делать так чтобы в отделе работало только два человека в мои планы не входит.
По этой причине необходимо создать БД отдела максимально дружественную к пользователям Excel.
Уход в Access тоже не подойдет по тем же соображениям и плюс много сложной отчетности, которая должна быть построена на БД.
Осложняющим фактором является то, что нет устроявшейся формы отчетности, приходится то так сделать, то эдак.
По этой причине строить отчетность в Access нет никакого желания.
Имея такие вводные пришла идея выкручиваться следующим образом.
1. В отдельных xlsx файлах вести файлы-справочники. Один файл - один справочник. Например, в одном файле перечень договоров по подрядчикам, во втором файле реквизиты субподрядчиков, в третьем файле данные о ходе сдачи документации заказчику, в четвертом файле единичные расценки по видам работ, в пятом классификатор, присваеваемый виду работ и т.д.
В общем будет как-бы множество столбцов, но не в одной раздутой книге Эксель, а в некоем множестве книг. Эдакий конструктор, из которого 2-е сотрудников будут строить сложную отчетность по общему идентификатору (разную, в т.ч. по новым формам)
2. Всей файлы-справочники (вместо того чтобы использовать ВПР) связать через Access, но при этом не загружать их в сам Access, а только создать связанные таблицы.
4. На основании запросов power query к Access 2-е сотрудников смогут строить сложную отчетность для отдела (отчетность будет опят же строится в файлах эксель). При этом файлы отчетности будут не такие тормознутые как было ранее (не будет множества ВПР-формул), а самое главное в них легче наводить порядок если изменилось что-то в справочнике (не придется переделывать все отчеты). Кроме того наводить порядок смогут низкоквалифицированные сотрудники отдела - они смогут разобраться в файле-справочнике.
При такой схеме сотрудники, которые кроме экселя ничего не хотят знать, не останутся без дела - им я смогу вовлечь в наполнение файлов-справочников. Они смогут их подкорректировать при необходимости, так как это же знакомый им эксель!
В общем получается схема:
База эксель - Access для построения связей между справочниками в Excel - Запрос power query к Access - отчетность в Excel
Отдельно хочу пояснить почему не рассматриваю power pivot .
Строить модель данных в power pivot не подходит так как 1. Мне не нужна сводная таблица в отчетности. А выводить данных из pivota во что-либо другое, отличающееся от сводной таблицы, как я понял, не выйдет.
2. Проблематично подключиться через power query к модели данных power pivot. Получается система нипель туда закачать данные не вопрос, а обратно танцы с бубном.
Что посоветуете мне? Правильная ли моя идея идти к решению проблемы БД через Access?
Может есть какой-то другой подходящий инструментарий.