Создаваемая структура подчинения

В общем у меня есть довольно специфическое задание. Я хочу сделать планировщик работ, или учёт приказов в общем названий много. Суть такова. Есть администратор (секретарь) бд, который вносит новых пользователей или создаёт структуру отделов. Мне это нужно автоматизировать. Есть способ, сделать структуру состоящую из сущностей директора, зам директора, начальника отдела, работников отдела. С каждым разом все ниже по должности и возможностям как пользователя бд. Директор может добавлять приказы только своим замам, подчиняющимся своим замам и т. д. Для того, чтобы не плодить таблицу приказы, от сущности к сущности, мне нужен один общий ID для всех рабочих. Получается как бы таблица контрагент "пользователи" в которой есть ID пользователя, пароль и логин. У всех сущностей будет уникальный ID пользователя из таблицы пользователей. У сущности зам директора, будет ID директора, для того, чтобы определить какому директору он подчиняется, и все остальные тоже будут ссылаться на своих "начальников", пока не дойдут до простых рабов. Как говорит мне мой преподаватель у такого подхода(я уже пытался такой реализовать, с разделением физических и юридических лиц) есть "недопустимый недостаток", называется необязательность связи. Насколько он не допустим? Неужели это так плохо? Этот подход позволяет мне реализовать подчиненность и одновременно не плодить другие связи и таблицы. Но вот в чем ещё одна проблема, я не планирую иметь другие атрибуты у пользователей. Получается все те сущности дети, которые имеют предка "пользователь" имеют одни и те же атрибуты. Следовательно по логике я могу отказаться от кучи таблиц директора, замы и прочее. Ведь у всех сущностей одни и те же атрибуты, можно обойтись одной таблицей "пользователи" со всеми нужными атрибутами, но тогда я теряю структуру подчиненности. Директор не сможет иметь зам директора, тот не сможет иметь начальников отдела и прочее. Я думаю над тем как реализовать это совсем иначе, и мне так как я совсем не шарю не кажется это бредом. Может это нормальное явление и ему есть название, может я идиот и не знаю причин почему нельзя такое реализовать, или то, что я хочу можно сделать совсем по другому не так и не сяк. В общем вот, что я думаю. Есть таблица пользователи, там есть ID пользователя, естественно он уникален. Есть ФИО, Должность, прочая информация. Могу ли я создать таблицу "подчиненные" в которой будет ID_Пользователя Подчиненного, ID_ПользователяПодчиняющего. Ситуация, когда пользователь подчиняется сам себе недопустима, как и ситуации, когда один и тот же пользователь подчиняется двум разным пользователям. Получается связующая таблица подчиненные, которая одновременно связана двумя связями с одной и той же таблицей пользователей. Из которой она берет ID подчиненных и подчиняющихся. Как я себе представляю, если такие возможно, то я смогу за администратора с нуля создать всю структуру подчиненности, не делая это через отдельные таблицы для каждой должности. Возможно я столько всего написал, что меня не поймут. Я постараюсь завтра прикрепить, er диаграмму или сущность связь первого и второго способа, которые я здесь описал.

0

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

это все делают с помощью CRM
из бесплатного понравилась http://www.triniforce.com

если хочешь сделать свое - нужно уметь программировать, и не просто SQL, а именно взять IDE с формами, написать логику работы, функции и тд и тп

0

Сообщение от qwertehok это все делают с помощью CRM из бесплатного понравилась http://www.triniforce.com если хочешь сделать свое - нужно уметь программировать, и не просто SQL, а именно взять IDE с формами, написать логику работы, функции и тд и тп

Не совсем понял. Писать логику подчинения через код? Я использую c# и windows form, для связи с бд и отображения данных, ввода и т д. Мой вопрос состоял в том, возможно ли вообще создать таблицы так, чтобы я мог за пользователя бд (администратора) создать структуру подчиненности. Написал как я это представляю. Ну или первым способом создать её готовую, используя таблицу контрагента с общими атрибутами для всех. Тут как раз вопрос насколько это хорошая практика, построения бд с использованием таблицы контрагента.

0

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

вот в этой твоей фразе кроется не один десяток вопросов

начнем с того что твои вопросы никаким образом к БД отношения не имеют. ты будешь использовать ее только для хранения.
основная твоя задача реализовать логику работы с помощью языка программирования

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

создание и заполнение таблиц в БД происходит прозрачно для пользователя. Создает директор задачу подчиненному - просто добавляется 1 строка в таблице и все.

0

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

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

Миниатюры

     

0

Сообщение от deadshot2013 но мне вот как раз и нужно понять как будет выглядеть та самая прозрачная часть)

таблица прав
id | Уровень
1 Директор
2 Зам директора
3 Фин директор

таблица сотрудники
id | FIO | отдел | должность | id прав

таблица подчиненности
id строки | id начальника | id подчиненного

таблица приказов
id приказа | id строки | приказ | дата | выполнено

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

Добавлено через 8 минут
тут возможно частично дублируются таблицы "таблица прав" и "таблица подчиненности"
но в таблицу прав можно внести цепочку Директорат-СреднееЗвено-МладшееЗвено
а уже дальше разрулить кто кому подчиняется в директорате и у среднего звена можно в таблице подчиненности

1

Сообщение от qwertehok таблица прав id | Уровень 1 Директор 2 Зам директора 3 Фин директор таблица сотрудники id | FIO | отдел | должность | id прав таблица подчиненности id строки | id начальника | id подчиненного таблица приказов id приказа | id строки | приказ | дата | выполнено ну на первый взгляд всего 4 таблицы (может будут еще какие справочники) по таблицам вопросы есть? Добавлено через 8 минут тут возможно частично дублируются таблицы "таблица прав" и "таблица подчиненности" но в таблицу прав можно внести цепочку Директорат-СреднееЗвено-МладшееЗвено а уже дальше разрулить кто кому подчиняется в директорате и у среднего звена можно в таблице подчиненности

Вооот. По сути все что мне нужно было это подтвердить мою догадку по таблице подчиненности. А зачем в таблице подчиненности id строки? Просто, чтобы была? Или это как то влияет на уникальность. Я не совсем еще понимаю, как избавиться от того, чтобы при добавлении подчиненных нельзя было добавить подчиненного, который уже кому-то подчиняется или подчинить самого себя. Ну я могу это сделать через код клиента. Делать запрос, подчиняется ли и отображать только тех сотрудников, where id != id_текущего пользователя. Единственное, что в голову приходит. Я хотел еще оправлять приказ на ID_USER получателя, а от того ID_User отправителя. Как лучше, так как вы написали c ID строки? Или мои бредни?)

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

0

Сообщение от deadshot2013 А зачем в таблице подчиненности id строки? Просто, чтобы была? Или это как то влияет на уникальность.

да, для однозначного определения строки

Сообщение от deadshot2013 Я не совсем еще понимаю, как избавиться от того, чтобы при добавлении подчиненных нельзя было добавить подчиненного, который уже кому-то подчиняется или подчинить самого себя.

проверкой на форме

Сообщение от deadshot2013 Я хотел еще оправлять приказ на ID_USER получателя, а от того ID_User отправителя. Как лучше, так как вы написали c ID строки? Или мои бредни?)

этого я не понял

Сообщение от deadshot2013 Я не собираюсь использовать отдельную таблицу для прав, в общем-то они не нужны, как мне кажется.

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


а как быть если нужна сквозная заявка от одного отдела к другому?
а как быть если одна заявка тянет за собой несколько других?

0

Сообщение от qwertehok этого я не понял

Я имею в виду, что приказы отправляются по тому же ID_User, в отправителе так же указывается ID_User.

Сообщение от qwertehok человек может уйти в отпуск и что бы не терялась нить подчиненности ... а как быть если нужна сквозная заявка от одного отдела к другому? а как быть если одна заявка тянет за собой несколько других?

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

Добавлено через 10 минут

Сообщение от qwertehok а как быть если нужна сквозная заявка от одного отдела к другому?

Вообще я не думал над этим, типа равные отделы дают друг другу заявки? Они же не могут друг другу приказывать. Не знаю. Это именно работа, а не просто просьба.

Сообщение от qwertehok а как быть если одна заявка тянет за собой несколько других?

Вы имеете в виду, что зам. директора дал начальнику отдела приказ, а тот отправил выполнять приказ нескольких других работников? Я не знаю, как такое связать, поэтому начальник просто будет создавать заявку для рабочих(несколько рабочих могут быть на одной заявке) на основе той которая поступила ему. Я обычный студент СПО, а не senior гугла. Мне бы хотя бы такой функционал)

0

Сообщение от deadshot2013 Я имею в виду, что приказы отправляются по тому же ID_User, в отправителе так же указывается ID_User.

все равно не понял. приказы никуда не отправляются. есть инициатор, есть исполнитель. все

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

тут не нужны таблицы, тут нужна иерархия - нужно TreeView.
Пользователь (root) должен видеть свои задания (child) и своих подчиненных (отдельные подветки) и их задания, дату выдачи, статус их выполнения.

или можно сделать вот так как на картинке, а меню вызывать правой кнопкой

Миниатюры

 

1

Сообщение от qwertehok все равно не понял. приказы никуда не отправляются. есть инициатор, есть исполнитель. все

Со стороны пользователя, они отправляются. ID_Инициатор, ID_Исполнитель это в таблице, в вашем варианте они отправляются по ID строки таблицы подчиненности. Я же имел в виду использование того же самого ID_User.

Сообщение от qwertehok тут не нужны таблицы, тут нужна иерархия - нужно TreeView.

А если вдруг администратор бд создаст там по 20 начальников отделов?) Заходит Директор к заму в TreeView и ему как в реестре виндовс сыпятся на голову начальники. Мне кажется простая таблица лучше подходит, но это все вопросы интерфейса а не бд. С вашей помощью я определился с таблицами, спасибо.

0

Сообщение от deadshot2013 А если вдруг администратор бд создаст там по 20 начальников отделов?)

и что?

Сообщение от deadshot2013 Заходит Директор к заму в TreeView и ему как в реестре виндовс сыпятся на голову начальники

и что?
дерево оно на то и придумано - для отображения иерархии

отобразить 20 строк, никто их не будет на всю форму же растягивать.

Сообщение от deadshot2013 Мне кажется простая таблица лучше подходит

таблица для вывода однотипной структурированной по колонкам информации.

Сообщение от deadshot2013 Со стороны пользователя, они отправляются.

Сообщение от deadshot2013 в вашем варианте они отправляются по ID строки таблицы подчиненности

Сообщение от deadshot2013 Я же имел в виду использование того же самого ID_User

извини, но я ничего не понял

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

ЗЫ вы проходили нормализацию таблиц?

0

Сообщение от qwertehok таблица для вывода однотипной структурированной по колонкам информации.

ну так пользователь видит подчиненных, как строку в таблице, что не так?) Он видит не только одну фамилию или id а также остальные данные, и да они однотипны, поэтому я не понимаю зачем здесь TreeView.

Сообщение от qwertehok извини, но я ничего не понял может ты разделишь хранение данных, отображение и логику и начнешь объяснять поэтапно? у тебя большая каша в мыслях, структурируй их

Просто я объяснял это в контексте предыдущих цитат и сообщений. Пользователь видит

Сообщение от qwertehok приказы никуда не отправляются.

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

Сообщение от qwertehok таблица подчиненности id строки | id начальника | id подчиненного таблица приказов id приказа | id строки | приказ | дата | выполнено

Сообщение от qwertehok ЗЫ вы проходили нормализацию таблиц?

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

0

Сообщение от deadshot2013 Он видит не только одну фамилию или id а также остальные данные, и да они однотипны

таблица хороша для вывода логов, каких то отчетов

Сообщение от deadshot2013 ну так пользователь видит подчиненных, как строку в таблице, что не так?

нет, не нужно выводить сразу все что ты знаешь по проекту в одну строку на 10 мониторов вправо.
вот тут посмотри ВНИЗУ 2 картинки.
Справа таблица. Все залито и ничего не понятно.
Слева расширенное TreeView. Вот так должен выглядеть список.

тут важно показать пользователю ВАЖНУЮ информацию удобным способом.

Сообщение от deadshot2013 это как отправление приказа. Приказ, это таблица.

Приказ это не таблица, Таблицей может быть СписокПриказов
но у меня и так выделена в отдельную таблицу, добавь нужные поля и все

Сообщение от deadshot2013 Все что я знаю о нормализации, это то что не нужно плодить таблиц

это так

Сообщение от deadshot2013 оставлять в таблицах пустые поля

это не так

Сообщение от deadshot2013 по возможности избегать связи 1 к 1

это тоже не так

Сообщение от deadshot2013 СПО не дало мне ничего, все что я знаю это опыт от лабораторных работ и практических

Тогда ты не построишь правильно систему и не напишешь хорошее ПО

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

0

Сообщение от qwertehok нет, не нужно выводить сразу все что ты знаешь по проекту в одну строку на 10 мониторов вправо. вот тут посмотри ВНИЗУ 2 картинки. Справа таблица. Все залито и ничего не понятно. Слева расширенное TreeView. Вот так должен выглядеть список. тут важно показать пользователю ВАЖНУЮ информацию удобным способом.

я нашел пример TreeListView. Список раскрывается по ФИО, а справа будут какие нибудь поля, которые я захочу отображать как информацию о подчиненном? Вы так предлагаете?

Миниатюры

 

0

Сообщение от qwertehok Приказ это не таблица, Таблицей может быть СписокПриказов но у меня и так выделена в отдельную таблицу, добавь нужные поля и все

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

Сообщение от qwertehok оставлять в таблицах пустые поля

я имел в виду не оставлять) Но это тоже вряд ли нормализация.

Сообщение от qwertehok Тогда ты не построишь правильно систему и не напишешь хорошее ПО рекомендую прежде чем строить систему составить на нее ТЗ. полноценное взрослое ТЗ. потом выложить его здесь и исправлять по мере надобности.

Кому интересно мое ТЗ, особенно когда я в душе не чаю как его писать.

0

Сообщение от deadshot2013 Кому интересно мое ТЗ, особенно когда я в душе не чаю как его писать.

твое ТЗ интересно в первую очередь тебе самому
попробуй скачать готовое и сделать под себя, это намного упростит работу

1

Сообщение от qwertehok твое ТЗ интересно в первую очередь тебе самому попробуй скачать готовое и сделать под себя, это намного упростит работу

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

0

я бы предложил такое

слева TreeView
ФИО
-задача1
-задача2
-ПОДЧИНЕННЫЙ1
---задача1
---задача2
---задача3
-ПОДЧИНЕННЫЙ2
---задача1
---задача2
-ПОДЧИНЕННЫЙ3
---задача1
---задача2

Справа у тебя TabControl c 3 вкладками
при клике на человека открывается 1ая вкладка с информацией о сотруднике
при клике на задачу открывается информация о задаче на 2й вкладке
при клике правой кнопкой на сотруднике появляется меню (добавить задачу, удалить задачу, уволить)
все действия совершаются на 3 вкладке

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

0