Модераторы: Akina
  

Поиск:

Ответ в темуСоздание новой темы Создание опроса
> Формирование скромной БД, ПРошу оказать посильную помощь  
:(
    Опции темы
Humorist
Дата 15.5.2018, 11:47 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 4
Регистрация: 15.5.2018

Репутация: нет
Всего: нет



Добрый день Уважаемые посетители.
В силу сложившихся обстоятельств в поисках ответов на вопросы вынужден просить посильной помощи у Вас.
Коротко о себе. Мне 30, имею несколько дипломов но ни одного по программированию. Учился в физмате, там же было углубленное (в рамках школьной программы) программирование, но это были все-таки азы, хорошая база, которая позволяла развиться всякому желающему. Мое желание в плоскость программирования не пошло.
Моя ситуация. На работе ввели курсы повышения квалификации (разные) для сотрудников компании. Часть из этих курсов относится к нашему департаменту. На меня скинули следующую задачу. Сформировать реестры слушателей для каждой учебной программы. В чем проблема: - Программ 25, филиалов 52+/- разбросаны по всей стране, от Калининграда до Владивостока. На каждую программу надо набрать 20 слушателей, где-то желающих больше, где-то желающих недостаточно и приходится обзванивать и просить. Программы есть как абсолютно уникальные (то есть составлены под один филиал и весь набор ведется из одного источника, в таком случае проблем никаких нет), а есть программы как котлован, набор слушателей ведется из разных источников, в довесок есть программы одинаковые, но проходящие в разное время, или в разных городах/ВУЗах, то есть степень вариативности тут достаточно высокая. Так как я человек новый, данный процесс был запущен без моего ведома, и я был просто помещен в ситуацию хаоса. Когда ко мне одновременно посыпались заявки на согласование кандидатур из всех филиалов (учитывая, что я новенький ситуация для меня была неприятной) на весь спектр программ (самая первая программа начиналась  30 апр, а последняя заканчивается в декабре) Если бы все это свалилось одномоментно большой бы беды не было, я бы в тишине спокойно бы разгреб списки из 500+ кандидатов. Но все сыпалось хаотично, оформление документов у всех разное, следовательно на обработку уходило много времени. Я уже не говорю о случая когда на местах подчеркнуто наплевательски относились к подаче заявки. И снова уходило время на то, что бы дозвониться, поговорить и уточнить. В компании есть ресурс по автоматизации, как коллеги сказали "неограниченный". Я обрадовался и быстренько накидал письмо со своими пожеланиями в части автоматизации процесса. Но наткнулся на ответ, суть которого свелась к тому, что - я хочу принципиально новый проект, под него надо собрать новую команду, согласовать с местными начальниками и если они сочтут нужным можно будет приступить к реализации. Те же коллеги позднее мне сообщили, что дело это гиблое и потому они три года технологический процесс не меняли. 
Следом в моей памяти всплыл курс информатики в первом институте. Нас там учили пользоваться Access. В то время я не проникся этой программой, но посидев и почитав предположил, что в принципе она может мне помочь. Правда главное мое желание - не принимать заявки от толпы пользователей она решить не может. Но не все коту масленица. Хоть какую-то часть работы на нее взвалить можно. Но я столкнулся с нехваткой знаний и отсутствием опыта в организации БД. Вот потому я решил обратиться на форум. 
Разные самоучители/видеокурсы по Аccess формируют несколько таблиц с данными, потом их связывают. делают надстройки из формы ввода и вывода данных. В целом я понимаю зачем делать несколько разных таблиц вместо одной, так быстрее и проще их просматривать программе. Тут-то у меня и возник первый вопрос. Каким образом мне лучше всего организовать свои таблицы?
у меня есть :
1 ФИО слушателя
2 Филиал (место его работы)
3 Подразделение филиала (далеко не всегда он есть, но можно внести наименование отдела, к примеру)
4 Рабочая почта (ее я решил сделать ключевым полем в таблице, так как почтовый адрес 100% уникальный)
5 Наименование учебной программы
6 Срок проведения программы (он делится на дистанционную часть и очную)
7 Место проведения программы  (ВУЗ, их всего 2, один в Москве, второй в Новосибирске)
8 Логин и пароль для каждого слушателя
9 Внутренний документ (телеграмма) на основании которого слушателей отправляют на обучение (можно привязать к слушателю или филиалу)
На данном этапе прошу подсказать какие таблицы мне необходимо сформировать? Я предполагаю, что надо сделать одну таблицу с наименованием филиалов, что бы из выпадающего списка можно было их выбирать, отдельную таблицу с учебными программами и периодом, и местом их проведения и отдельную таблицу со слушателями. 
В самоучителях строятся аналогичные БД но для примера там есть упрощения, когда все данные идут по порядку и ключевое поле организуется через обычное построчное перечисление, по порядку. Но у меня же все сыпется хаотично. К примеру первым может прийти кандидат на самую дальнюю учебную программу, следом на первую и так далее. 
Если мой вопрос гораздо сложнее и глубже чем мне кажется, ведь сложность БД определяется не только объемом данных в ней хранящихся, прошу подсказать где я могу быстро восполнить пробел в правилах организации БД, который бы смог мне помочь. Так как я описал только часть своей идеи. 
В целом я хочу дойти до следующего состояния - мне присылают таблицу в exel, я оттуда импортирую данные, потом программа мне выдает данные по моему запросу. Основных 2, это - сколько собрано человек на конкретную программу, с конкретным периодом обучения, и сколько человек предоставил филиал (на все программы или на какую-то конкретную программу). Так же мне необходима возможность автоматизированной отправки на электронную почту слушателя его логина и пароля (который я ввожу в самом конце технологической цепочки, процесс рассылки нужен на абсолютли автомат, а по моей команде.), и телеграммы п.8 (тоже делаю самостоятельно)
Так же я понимаю, что все это можно сделать через excel. Запихать все в одну огромную таблицу на 500+ строк, с большим количеством столбцов (штук 15, наверное) и через фильтры получать данные. 
Но это не так круто и красиво как Access. Этот пусть знают все, реализовать могут все. А Access для многих программа неведомая, одновременно красивая и тыры-пыры. В общем мне нужны свистелки/перделки, что бы для обывателя выглядело сложно, круто и вызывало благоговейный страх)
Заранее спасибо. 


PM MAIL   Вверх
Akina
Дата 15.5.2018, 13:40 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Советчик
****


Профиль
Группа: Модератор
Сообщений: 20570
Регистрация: 8.4.2004
Где: Зеленоград

Репутация: 30
Всего: 453



Цитата(Humorist @  15.5.2018,  12:47 Найти цитируемый пост)
у меня есть :
1 ФИО слушателя
2 Филиал (место его работы)
3 Подразделение филиала (далеко не всегда он есть, но можно внести наименование отдела, к примеру)
4 Рабочая почта (ее я решил сделать ключевым полем в таблице, так как почтовый адрес 100% уникальный)
5 Наименование учебной программы
6 Срок проведения программы (он делится на дистанционную часть и очную)
7 Место проведения программы  (ВУЗ, их всего 2, один в Москве, второй в Новосибирске)
8 Логин и пароль для каждого слушателя
9 Внутренний документ (телеграмма) на основании которого слушателей отправляют на обучение (можно привязать к слушателю или филиалу)
На данном этапе прошу подсказать какие таблицы мне необходимо сформировать?

У Вас имеются следующие сущности, которые необходимо выделить как самостоятельные (и соответственно для каждой создаётся таблица):
1) Организация (филиал)
2) Слушатель
3) Учебная программа
4) Внутренний документ

Также имеются сущности, которые я не вижу смысла делать самостоятельными:
1) Подразделение. Достаточно его оставить атрибутом сущности Организация - в противном случае придётся организовывать хранение древовидного списка, а для начинающего это сложно.
2) Место проведения программы. Поскольку их всего 2, проще сделать это атрибутом-перечислением.

Выделенные сущности объединяются соотношениями:
1) Организация относится к нескольким слушателям. Слушатель относится к одной Организации. Соотношение один-ко-много.
2) Учебная программа относится к нескольким слушателям. Слушатель относится к нескольким Учебным программам (пусть и не одновременно). Соотношение много-ко-много. Требует создания дополнительной таблицы связей.
3) Внутренний документ относится к одной Организации. Организация относится к нескольким Внутренним документам. Соотношение один-ко-много.
4) Внутренний документ относится к нескольким слушателям. Слушатель относится к нескольким Внутренним документам. Соотношение много-ко-много. Требует создания дополнительной таблицы связей.

Т.е. вроде бы всего потребуется 6 таблиц (4 для сущностей и 2 для связей). 

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

Т.е. на самом деле сущностей не 4, а 5. И то, что написано про соотношения сущности Учебная программа - это на самом деле соотношения сущности Экземпляр учебной программы. После того как мы добавим ещё одну сущность и её связи (одна программа - несколько экземпляров, один экземпляр -  одна программа, один-ко-много), получим итоговую схему из 7 таблиц, 5 для сущностей и 2 для связей.
Цитата(Humorist @  15.5.2018,  12:47 Найти цитируемый пост)
Рабочая почта (ее я решил сделать ключевым полем в таблице, так как почтовый адрес 100% уникальный)

Видимо, речь об адресе электронной почты? потому как почтовый-то один для всех сотрудников организации, а домашний вряд ли будет фигурировать в БД... так вот - не делайте этого! Есть несколько резонов против, и в Вашем случае ни одного за, и самый серьёзный против - это дама, которая вышла замуж, после чего у неё сменились и фамилия, и соответственно e-mail. 
В каждой таблице сущностей (и Слушателей в том числе) создаёте поле типа Счётчик с автозаполнением, именно его делаете ключевым, именно его используете для организации связей. А на поле электронной почты, если очень хочется, можете наложить требование уникальности (но и этого не советую - вполне может вдруг оказаться, что некоторые сотрудники идентифицируются по e-mail подразделения).


--------------------
 О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума.

PM MAIL WWW ICQ Jabber   Вверх
Humorist
Дата 15.5.2018, 14:23 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 4
Регистрация: 15.5.2018

Репутация: нет
Всего: нет



Большое спасибо, попробую переварить и на неделе начну приступать.
За подсказку с таблицами отдельное спасибо, я все никак не мог уловить каким образом мне группировать данные. Буду осваиваться и по мере поступления вопросов задавать их.
Еще раз большое спасибо 
PM MAIL   Вверх
Humorist
Дата 15.5.2018, 16:07 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 4
Регистрация: 15.5.2018

Репутация: нет
Всего: нет



Цитата(Akina @  15.5.2018,  13:40 Найти цитируемый пост)
Есть несколько резонов против, и в Вашем случае ни одного за

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

Это сообщение отредактировал(а) Humorist - 15.5.2018, 16:08
PM MAIL   Вверх
Akina
Дата 15.5.2018, 19:09 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Советчик
****


Профиль
Группа: Модератор
Сообщений: 20570
Регистрация: 8.4.2004
Где: Зеленоград

Репутация: 30
Всего: 453



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


--------------------
 О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума.

PM MAIL WWW ICQ Jabber   Вверх
Humorist
Дата 16.5.2018, 18:13 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 4
Регистрация: 15.5.2018

Репутация: нет
Всего: нет



Добрый день. 
В процессе формирования таблицы со списком учебных программ у меня возникла проблема.
Учебная программа состоит из 2 частей. Дистанционная и Очная. Все 4 даты мне нужны в таблице, но помимо этого мне необходимо иметь еще 2 ячейки в которых указывается начало и конец программы. Итого получается 6 дат на одну программу. 2 из которых повторяются. 
и у меня возник вопрос, на который ответ я не нашел. Есть ли в access функция аналогичная "=" в excel? Что бы мне не приходилось каждый раз вводить 6 дат, а достаточно было ввести 4,а две другие просто автоматом заполнялись? Все это в рамках одной таблицы. 
Заранее спасибо 
PM MAIL   Вверх
Akina
Дата 17.5.2018, 07:54 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Советчик
****


Профиль
Группа: Модератор
Сообщений: 20570
Регистрация: 8.4.2004
Где: Зеленоград

Репутация: 30
Всего: 453



Цитата(Humorist @  16.5.2018,  19:13 Найти цитируемый пост)
Учебная программа состоит из 2 частей. Дистанционная и Очная.

В данном случае сущностью, помещаемой в таблицу Учебных программ, является каждая отдельная часть, т.е. всё написанное ранее для Учебной программы становится описанием для Часть учебной программы (или, скажем, Этап - не суть). Т.е. описанная программа в таблице состоит из 2 записей. Для учёта подобных объединений потребуется дополнительная таблица Учебных программ и таблица связей, которая устанавливает соответствие между Учебной программой и Частью учебной программы. Для тех программ, которые не имеют этапов, там будет одна запись, для разбитых на этапы - несколько записей.

Цитата(Humorist @  16.5.2018,  19:13 Найти цитируемый пост)
Итого получается 6 дат на одну программу. 2 из которых повторяются. 

Если данные ГАРАНТИРОВАННО повторяются (точнее, есть данные, которые могут быть однозначно вычислены из других данных) - значит, в одном из двух мест они размещены не по делу, и соотв. поля должны быть удалены, а когда потребуются - их получают в запросе на основе других данных. В каком именно месте оставить и в каком удалить - зависит от сущности и логики процесса (там, где эти данные являются следствием - удалить).


--------------------
 О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума.

PM MAIL WWW ICQ Jabber   Вверх
  
Ответ в темуСоздание новой темы Создание опроса
Правила форума "MS Access"
Akina
  • Действия модераторов можно обсудить здесь
  • С просьбами о написании курсовой, реферата и т.п. обращаться сюда
  • Вопросы по реализации алгоритмов рассматриваются здесь
  • Используйте теги [code=vb][/code] и [code=sql][/code] для подсветки кода. Используйтe чекбокс "транслит" (возле кнопок кодов) если у Вас нет русских шрифтов.

Запрещается!

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

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


Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, Akina.

 
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | MS Access | Следующая тема »


 




[ Время генерации скрипта: 0.1335 ]   [ Использовано запросов: 21 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.