Разработать структуру БД , согласно приведенной диаграмме: прикреплен рисунок 1.
Описание сущностей:
Подразделения – представляет собой иерархическую структуру с неограниченным уровнем вложенности.
Сотрудники - сведения о физических лицах.
Должности – справочник должностей.
Штатные единицы – связующая таблица сотрудников подразделений и должностей.
Germ529"Подразделения – представляет собой иерархическую структуру с неограниченным уровнем вложенности." - как понять? такое еще не делал
Так на вашей схеме это уже Вами (?) отрисовано.
У каждой записи в соответствующей таблице есть ID и ссылка на родительскую запись, что в итоге порождает дерево с неограниченным ветвлением (в вашей терминологии структура с неограниченным уровнем вложенности).
Т.е. будут записи вида
IDParentID 102131425464
Что порождает дерево с главным узлом "1", двумя узлами "второго уровня" "2"/"3", узлом третьего уровня "4" с родителем "2" и двумя узлами четвертого уровня "5"/"6" и родителем 4. И количество уровней ничем не ограничены.
В таблице Сотрудники должна быть ссылка на Должность, а не наоборот. Таблица Сотрудники должна хранить историю перемещения Сотрудника с должности на должность или между подразделениями. Обычно в ней есть еще поля ДатаС ДатаПо.
Кот МатроскинП-ЛВ таблице Сотрудники должна быть ссылка на Должность, а не наоборот.
Философский вопрос. Если сотрудник может совмещать несколько должностей...
Судя по связи 1-1 между штаткой и сотрудником - совмещение не предусмотрено.
Не понятна задача ТС - на "диаграмме" приведена требуемая структура в первом приближении (без учета ряда существенных фактов типа дат, хранения истории и т.п.).
Если задача ТСа написать скрипты для создания этих таблиц/либо "наваять" таблички в акцессе - то это не та ветка форума.
Если же задача ТСа как раз расширить сущности, предусмотрев возможные кейсы - то мягко сказать задача бесконечна...
да, спасибо ребята за поддержку, добавил такой код.
Код который описан ниже, не совсем то что я хотел.
Как создать one to many relationship?
ALTER TABLE shtat ADD
--CONSTRAINT YourUniqueName --for adding your own name to unique constraint
UNIQUE(dolzhnost)
ALTER TABLE shtat
ADD
--constraint yourUniqueName --uncomment for adding your own name to FK constraint
FOREIGN KEY (dolzhnost) REFERENCES dolzhnost(id);
Да подключись Аксесом к базе (проект ADP) конструируй да рисуй что тебе нужно, есть куча и других инструментов - зачем всем мозг выносить... можно вообще макет отладить в том же акцесе от и до, а потом сделать экспорт в MS SQL.... а вообще схема изначально, мягко говоря - неудачный эскиз:
1. Обычно должности не сами по себе, а привязаны к подразделению (это штатка) в вашем случае если должность свободна, то хрен поймешь в каком подразделении вакансия...
2. + все те замечания что выше (даты С, По, приказ)
По поводу по последнего вопроса (one to many): Как может быть many между двумя первичными уникальными ключами ??? Many может быть только между первичным (уникальным) и вторичным (которых дохрена одинаковых - допускаются совпадения)... Учиться... Учиться... Учиться.... Шапками забросать не получится...
Вот такой вариант (как точка опоры) более гибкий (готов выслушать критику...)
1. Просто Штатка - это отчет по Podrazdelenie и Doljnost.
2. Список сотрудников - это отчет по Podrazdelenie и Sotrudnik.
3. Один сотрудник может быть назначен хоть на 100 должностей (Совмещение).
4. Сотрудник одного подразделения может занимать должность другого подразделения (местная командировка).
5. Вакансии - это отчет по Podrazdelenie и Doljnost где у Doljnost нет подчинения в Shtat или нет в Shtat действующего приказа (data_s - data_po)
6. Сотрудники за штатом - это отчет по Podrazdelenie и Sotrudnik где у Sotrudnik нет подчинения в Shtat или нет в Shtat действующего приказа (data_s - data_po)
....
....
vmag,
схема в топике 1 мне понятна, а от 01:23 --нет
зачем вы подразделение во все таблицы затолкали
директор
--гл.инженер
----некие службы
--зам по экономике
----некие службы
--зам по производству
----под-зам по пр-1
-------цеха пр1
---------цех 1
-----------уч1
-----------уч2
-----------уч3
...........................
............................
----под-зам по пр-2
-------цеха пр2
............................
----под-зам по пр-3
-------цеха пр3
...........................
.
Моя схема это
vmagВот такой вариант (как точка опоры)
+ У ТС ни слова про службы...
ПЕНСИОНЕРКАи мне кажется, что работник может занимать несколько ячеек в штатном расписании(внутреннем или внешнем)
vmag3. Один сотрудник может быть назначен хоть на 100 должностей (Совмещение).
4. Сотрудник одного подразделения может занимать должность другого подразделения (местная командировка).
Germ529"Создать триггер контролирующий отсутствие циклов в иерархии подразделений" - как понять эту задачу?
Кстати о птичках.... у вас (при чем не важно по какому пути вы пошли: по своему или по моему) нет иерархии подразделений, у вас тупо есть одна таблица Подразделения и всё.... Если вы хотите иерархию и бешенных циклов в иерархии, с которыми вам нужно будет бороться, то добавьте в Таблицу Подразделения еще одно поле типа "Код_Иерархии" и тогда:
1/Управление/0 - ноль, значит никому не подчиняется...
2/Первый отдел/1 - один, значит подчиняется Управлению....
3/Второй Отдел/1 - один, значит тоже подчиняется Управлению....
4/Автотранспортная Служба/2 - два, значит подчиняется Первому отделу...
то есть нужно создать такой триггер который будет контролировать повтор значении, например в "Код_Иерархии" если цикл повторяется (значения) то нужно его контролировать верно?
тогда parent мне зачем? запутался
Germ529то есть нужно создать такой триггер который будет контролировать повтор значении
Я же говорю... идите обратно с этим на на форум "Microsoft SQL Server"... иерархия у вас уже в кармане...
лично я в триггерах не бум-бум, а так как стараюсь придерживаться правила: "Дурак не тот, который чего-то не знает, а тот кто рассуждает о том, чего не знает", то помочь вам больше ни чем не могу...
- У вас начнется резкий прогресс, как только вы отойдете от подхода 1С к вычислению значения 2+2 =...
- И нужно как то понимать где речь идет о курсовой работе с тремя таблицами и реальной предметной области....
vmagКот МатроскинСотрудник занимает должности в подразделении 2 и подразделении 3 -что будет в ID_podr таблицы "сотрудник"?
ID_podr основного подразделения по ветке Подразделение - Сотрудник
WTF "основное подразделение" в случае, когда человек занимает должности в нескольких подразделениях?
Кот МатроскинWTF "основное подразделение" в случае, когда человек занимает должности в нескольких подразделениях?
Это всегда...
- если должность только в одном подразделении, то это основное подразделение и оно же единственное
vmag2. Список сотрудников - это отчет по Podrazdelenie и Sotrudnik.
- В этом списке Сотрудник представлен в своем основном подразделении...
Уточняю - таблицы Shtat и Doljnost не участвуют в определении основного подразделения Сотрудника...
- Если сделать запрос по Sotrudnik - Shtat - Doljnost, то можно найти Сотрудников у которых id_podr не совпадает с id_podr в таблице Doljnost (это и есть не основные подразделения Сотрудника, в которых он что то совмещает)...
- Мало того,- если у двух разных сотрудников одинаковые другие id_podr в Doljnost (по цепочке Sotrudnik - Shtat - Doljnost), то это значит, что они могут оба совмещать одну и ту же другую должность в определенных пропорциях (например пилить чужую ставку пополам)
vmagУточняю - таблицы Shtat и Doljnost не участвуют в определении основного подразделения Сотрудника...
Отойдите от запросов, посмотрите с точки зрения модели.
Вот у нас Иван Иванович возглавляет службу безопасности и является одновременно членом совета директоров, итого он занимает должности в "СБ" и "директорате". Что в записи Sotrudnik по нему будет в ID_Podr? И почему?
Как Вы планируете поддерживать смысловую целостность этого поля - т.е. что будет, если на этапе ввода таблицы Sotrudnik оператор внесет ему в ID_podr "Бухгалтерия" - эта ошибка не будет отловлена системой никогда?
Кот МатроскинВот у нас Иван Иванович возглавляет службу безопасности и является одновременно членом совета директоров, итого он занимает должности в "СБ" и "директорате". Что в записи Sotrudnik по нему будет в ID_Podr? И почему?
С точки зрения модели - хоть один человек на свете да должен принять решение: какое из указанных подразделений для Ивана Ивановича будет основным - код этого подразделения и нужно поставить в ID_Podr у Sotrudnik
Кот МатроскинКак Вы планируете поддерживать смысловую целостность этого поля - т.е. что будет, если на этапе ввода таблицы Sotrudnik оператор внесет ему в ID_podr "Бухгалтерия" - эта ошибка не будет отловлена системой никогда?
Основа это связка Podrazdelenie - Sotrudnik и на ней базируется всё (в этом смысле):
- Списки сотрудников подразделения для начальников подразделений (Сразу вопрос у Главбуха:
почему у меня числится уборщица ?)
- Общий Список телефонов организации.
- Любой другой список на связке Podrazdelenie - Sotrudnik
.... системой не знаю (когда в 1С вносите уборщицу в бухгалтерию - она ведь не пищит и комп не выключает?) а вот глазами сразу при просмотре первого же кривого списка...
При желании можно в любом списке выдать рядом с основным подразделением все совмещения сотрудника или только совмещения сотрудника:
- Если мы идем по схеме от Сотрудника к Подразделению по часовой стрелке (один шаг) то это Основные подразделения...
- Если мы идем по схеме от Сотрудника к Подразделению против часовой стрелки (Сотрудник -> Штат -> Должность -> Подразделение) то получаем совмещения...
Я согласен, что гибкость этого фрагмента из 4-х таблиц (замкнутого круга) немного шокирует своими возможностями и по этому требует более полной и точной конкретизации функционала и ограничений в реализации интерфейса, но это (с моей точки зрения) интереснее и предпочтительнее, чем сидеть со связанными руками над ограниченной схемой базы данных...
vmagКот МатроскинВот у нас Иван Иванович возглавляет службу безопасности и является одновременно членом совета директоров, итого он занимает должности в "СБ" и "директорате". Что в записи Sotrudnik по нему будет в ID_Podr? И почему?
С точки зрения модели - хоть один человек на свете да должен принять решение: какое из указанных подразделений для Ивана Ивановича будет основным - код этого подразделения и нужно поставить в ID_Podr у Sotrudnik
Ну то есть вводится некая непонятная сущность "основное подразделение", никакого алгоритма ее заполнения не предлагается, отдается на откуп оператору Машеньке "решай как хочешь".
vmagКот МатроскинКак Вы планируете поддерживать смысловую целостность этого поля - т.е. что будет, если на этапе ввода таблицы Sotrudnik оператор внесет ему в ID_podr "Бухгалтерия" - эта ошибка не будет отловлена системой никогда?
Основа это связка Podrazdelenie - Sotrudnik и на ней базируется всё (в этом смысле):
- Списки сотрудников подразделения для начальников подразделений (Сразу вопрос у Главбуха:
почему у меня числится уборщица ?)
Список будет кривым, поскольку совместители в него сразу не попадают (Иван Иванович будет только в одном подразделении).
Бронируем отель для членов директората, забронировали 6 мест - приехало 8 директоров, потому что у двоих стояли другие "основные подразделения"(tm). Толково :)
vmag.... системой не знаю (когда в 1С вносите уборщицу в бухгалтерию - она ведь не пищит и комп не выключает?) а вот глазами сразу при просмотре первого же кривого списка...
Зачисление уборщицы на должность бухгалтера - это не противоречие с точки зрения системы, это возможно .
Выставление сотруднику "основного подразделения", в котором он не занимает должностей - это противоречие.
В общем-то, основное отличие хорошей схемы данных от плохой - это невозможность внести противоречивые и глючные данные.
vmagЯ согласен, что гибкость этого фрагмента из 4-х таблиц (замкнутого круга) немного шокирует своими возможностями и по этому требует более полной и точной конкретизации функционала и ограничений в реализации интерфейса, но это (с моей точки зрения) интереснее и предпочтительнее, чем сидеть со связанными руками над ограниченной схемой базы данных...
Максимальная "гибкость" - у экселя. Это не значит что эксель это идеал проектирования БД.
Что Вы выигрываете этой гибкостью? Какой запрос нельзя сделать без ID_podr в таблице сотрудников?
Кот МатроскинНу то есть вводится некая непонятная сущность "основное подразделение", никакого алгоритма ее заполнения не предлагается, отдается на откуп оператору Машеньке "решай как хочешь".
Мы с вами в разных плоскостях... можно даже сказать в параллельных и не пересекающихся... вы в каком-то искусственном интеллекте... а я в простой БД из 4-х таблиц по курсовой работе...
Кот МатроскинСписок будет кривым, поскольку совместители в него сразу не попадают (Иван Иванович будет только в одном подразделении).
Возьмите на работу Машеньку по умнее, которая поставит галочку "Выдать список вместе с совместителями"
vmagПри желании можно в любом списке выдать рядом с основным подразделением все совмещения сотрудника или только совмещения сотрудника:
- Если мы идем по схеме от Сотрудника к Подразделению по часовой стрелке (один шаг) то это Основные подразделения...
- Если мы идем по схеме от Сотрудника к Подразделению против часовой стрелки (Сотрудник -> Штат -> Должность -> Подразделение) то получаем совмещения...
Кот МатроскинВыставление сотруднику "основного подразделения", в котором он не занимает должностей - это противоречие.
Вы в армии не служили... когда занимаешь реальную должность в другом отделе, а мозг тебе выносит начальник основного отдела, в котором ты даже не числишься... плюс это противоречие (с вашей точки зрения) легко решается в интерфейсе (даже не объясняю как - ибо это очевидно)
Кот МатроскинМаксимальная "гибкость" - у экселя. Это не значит что эксель это идеал проектирования БД.
Что Вы выигрываете этой гибкостью? Какой запрос нельзя сделать без ID_podr в таблице сотрудников?
Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
