Здравствуйте!
Появилась необходимость создать базу, для себя, по ведению пациентов. Все вроде бы неплохо... И данные разбил на самые мелкие данные и таблицы справочники прикрепил... Но столкнулся с такой проблемой, что не передаются (?) нужные данные из одной таблицы в другую (?) или неправильно связаны (?) таблицы.
Немного логики построения:
Нужно вести учет пациентов, которые приходят на приём. Когда пациент (П) приходит в первый раз, то необходимо внести его личные данные: ФИО, дата рождения, домашний адрес и т.п. Всё это вводится в форме form_Patients и заносятся в таблицу tbl_Patients. Автоматом присваивается личный номер П (через счётчик). Всё работает. Теперь необходимо ввести данные осмотра П (ведь П пришёл для этого))) и переходим в форму form_DescriptionALL. Данные сохраняются в tbl_DescriptionALL. Вот тут мы и подходим к проблеме: Как связать эти две таблицы так, чтобы данные каждого пациента соответствовали именно ему? Я следовал такой логике: В  tbl_Patients у нас каждый П индивидуален по Kod_NumberPatient (счётчик). В tbl_DescriptionALL каждый осмотр индивидуален по Kod_IdMedcart и связь между этими таблицами установлена один-ко-многим по Kod_NumberPatient. Т.е. Одному пациенту из tbl_Patients может соответствовать много записей в tbl_DescriptionALL. НО! Как связать эти данные о осмотре с самим пациентом? По логике есть таблица с данными о пациенте (и каждому присвоен личный номер Kod_NumberPatient) и вот этот номер должен привязываться к каждому осмотру, но не привязывается (((( поле в таблице tbl_DescriptionALL так и остаётся пустым. Как сделать чтобы при переходе из form_Patients в form_DescriptionALL в поле Kod_NumberPatient передавались данные из такого же поля из form_Patients?

Про то, чтобы с помощью поиска вывести эти данные о осмотре я вообще молчу (Это в будущем). Естественно раз нет номера, то и всего остального нет.

Может кто помочь разобраться с этим? Сама база прилагается.

Присоединённый файл ( Кол-во скачиваний: 6 )
 MyPatients7.rar 168,05 Kb

Не вижу анализа предметной области. Выделения сущностей и атрибутов, связей и процессов. Именно из них рождается ER-диаграмма и структура БД. Формы ввода - дело десятое. Вы же построили свою БД на основании неких абстрактных рассуждений, фактически по наитию. Нормализация? нет, не слышали... 

Выбросить и начать заново. Дешевле обойдётся.

Спасибо за ответ.

Слышал и использовал по полной! Там всё Нормализировано! Вы открывали базу? Если Вы увидели что то, что не нормализировано, то подскажите где?

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

Да 16! А как иначе? Программа не позволяет из одного и того же справочника создать связь с несколькими полями в пределах одной таблицы! При попытке создать связь она ругается, знаете ли. Вот так:
Может быть посоветуете как быть в такой ситуации? Я другого метода не нашел. Вернее сама программа его и делает. По факту справочник один. Но в схеме он отображается многократно.


Это сообщение отредактировал(а) matva - 27.10.2017, 14:34

Присоединённый файл ( Кол-во скачиваний: 3 )
 Ошибка2.jpg 128,53 Kb

Вот потому я и говорю, что БД не нормализована. У Вас связь N:N, а Вы её организуете не как положено, а кучей однотипных полей. Так что рекомендация переделать заново, но "по науке" - это единственное, чем могу помочь.

Это как? Видел (знаю) связи 1:М, М:N... а N:N - это один-к-одному?
У меня связь один-ко-многим с сохранением целостности данных и каскадным обновлением данных. Всё как раз по науке. Откройте файл-картинку - там всё видно.

Объясните, пожалуйста, что мне нужно сделать?

P.S. Во всей базе нет ни одной связи один-к-одному.


Это сообщение отредактировал(а) matva - 27.10.2017, 15:39

Уважаемый Akina! Не могли бы Вы хоть намекнуть, где у меня не нормализована БД? 

Это сообщение отредактировал(а) matva - 29.10.2017, 20:49

Присоединённый файл ( Кол-во скачиваний: 3 )
 MyPatients9.rar 182,36 Kb

Показывайте проведённый Вами анализ предметной области. Весь, полностью.

А затем - построенную на его основе ER-диаграмму.

Будем смотреть, правильно ли первое, совпадает ли второе с первым.

Если всё будет в порядке - вот только тогда будем смотреть, насколько структура созданной БД соответствует диаграмме и анализу.

Уважаемый/мая Akina.  
Если Вы не хотите помочь, то так и скажите. Не надо меня отправлять учить программирование и разработку баз данных с самого нуля. Я сам врач-офтальмолог и когда ко мне приходят за помощью, то я её оказываю, а не отправляю человека в библиотеку учить анатомию, пат.анатомию, физиологию, пат.физиологию, офтальмологию, фармакологию и т.д. и т.п. Я собираю анамнез, жалобы, провожу осмотр, если надо то обследование и т.п. ставлю диагноз и назначаю лечение! Но не заставляю пациента учить матчасть! Вы сейчас точно так же поступаете: отправляете учить. Я не требую от Вас переписывать БД, не требую что-либо самому изменять, но уж коль Вы (сами) указывали, что база не нормализована, то я вас попросил просто указать где конкретно. Вы сейчас требуете провести "анализ предметной области. Весь, полностью. А затем - построенную на его основе ER-диаграмму." Но я с этим не сталкивался и не знаю, что это и как его проводить. Нет, ну в википедию то я заглянул... но вникать в такие тонкости у меня, увы, нет времени. Поэтому то я и обратился на форум за помощью, а не за наставлением, что надо выучить разработку и программирование баз данных. 

С Уважением, matva.


Это сообщение отредактировал(а) matva - 30.10.2017, 02:43

Сейчас Вы изображаете врача-офтальмолога, который говорит пациенту следующее:
- У Вас зрение минус три, купите себе трое очков по минус один каждые и наденьте их одновременно, получится суммарно как раз минус три, будете всё прекрасно видеть!

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


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

Akina, Вы так и делаете! Я же подбираю человеку правильные очки и он с моим рецептом делает их и пользуется годами! 



Почему бы Вам, как пациенту, тогда не изучить минимальный базовый курс по медицине и не лечиться самому, а не приходить к врачу?! 


А как правильно? Если программа не позволяет ссылаться на ОДИН справочник? Поля , да однотипные, но цифры должны быть разные! УБрать вообще такой справочник? Делать подстановку непосредственно в поле? В общем и целом переделал я базу и вообще убрал эти связи. Просто сделал выбор этих данных из таблицы и всё. Но это проблемы не решает. В других ячейках сделал связи 1 к 1 без обеспечения целостности данных. ( Насколько я понял из всего прочитанного, то связи 1 к 1 не приветствуются в БД, но выхода нет. Если Вам будет интересно, то результат проделанной работы тут:


Присоединённый файл ( Кол-во скачиваний: 4 )
 MyPatients9.rar 173,69 Kb

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


Об этом я уже говорил. Вы имеете связь много-ко-много, N:N (и тут N - не какое-то определённое число, а эквивалент слов "неизвестно сколько", так что Ваш экзерсис про "N:N - это один-к-одному?" - это опять-таки свидетельство непонимания). 

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

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

Совершенно с Вами согласен.

ох... 
Вроде ж так всё и сделано. Форма Пациент - данные о пациенте. У неё подчинённая форма - данные об осмотрах.

А вот тут непонятно... Зачем такое? Чтобы нельзя было изменить напрямую старые записи? Связующая таблица это будет запрос?

Да какие формы? Вы сперва с таблицами разберитесь! И пока не появится выверенная, полностью соответствующая бизнес-модели, структура, о запросах-формах-отчётах вести речь бессмысленно.


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


Связующая таблица - это таблица.