Отношение между фармацевтом и пациентом в доступе 2016 - PullRequest
0 голосов
/ 28 декабря 2018

Я создаю аптечную базу данных в Access 2016. Это мой школьный проект и первый проект базы данных.

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

Теперь проблема в том, что мы знаем, что отношение «Адрес» и «Пациент» взаимно однозначно, так как я могу выполнить эту задачу?

Другая проблема заключается в том, что у меня уже есть адрес, город и национальность, связанные с Pharmacist_ID.Могу ли я связать эти таблицы с Patient_ID?

Я сбит с толку, потому что тип данных Pharmacist_ID равен Auto-Number.Patient_ID у первого Пациента будет 1, а затем у Pharmacist_ID у первого Фармацевта также будет 1, так что же произойдет?

Опять же, я нахожусь на MS-Access 2016. ЭтоИзображение RelationShip и вы можете увидеть детали моих таблиц

С уважением,

Арслан Ифтихар

enter image description here

Это для Томаса Дж. Проверьте это, Томас, как вы думаете, я поступаю правильно или неправильно

Ответы [ 2 ]

0 голосов
/ 02 января 2019

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


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

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

В нормальном мире:

  • у фармацевта может быть много пациентов
  • у пациента может быть много фармацевтов

Не так ли?

Таким образом, у вас отношения м-м-м.Как вы решаете это?С промежуточной таблицей, в которой хранятся отношения между пациентами и фармацевтами.

Единственное исключение из этого: если вы создаете свое программное обеспечение только для одного фармацевта, тогда ваш подход «один к одному» будет работать, но я не будупосмотрите любую причину иметь таблицу Фамарциста:)


Теперь проблема в том, что мы знаем, что отношение Адреса и Пациента однозначно, так как я могу выполнить эту задачу?

Вы действительно уверены в этом?Что происходит в таких случаях:

  • Пациенты, принадлежащие к одной семье (проживающие в одном доме).
  • Пациенты, для которых адрес выставления счета не совпадает с домашним адресом.
  • Пациенты, которые также являются фармацевтами.
  • Пациенты, владеющие несколькими домами.

Это очень распространенные случаи.Если вы пойдете 1-1, вы получите много двойников в вашей адресной таблице.

РЕАЛЬНАЯ причина, по которой мы почти всегда помещаем адреса в отдельную таблицу, заключается в том, что адреса редко встречаются в информационных системах.Если бы это было один к одному, не было бы реальной причины хранить их в дополнительных таблицах.


Я запутался, потому что типом данных Pharmacist_ID является Auto-Number.Patient_ID первого пациента будет 1, а затем Pharmacist_ID первого фармацевта также будет 1, так что же произойдет?

И это хороший вопрос, который должен был привести вас к ошибке проектирования выше,У вас не должно быть 1-1 между адресом и чем-то еще (Пациент или Фармацевт).

В таблицах «Пациент И Фармацевт» у вас должен быть AddressID, ссылающийся на идентификатор в таблице адресов.Если вы хотите дать возможность фарамацистам хранить:

  • Домашний адрес
  • Платежный адрес
  • Адрес для отдыха
  • Какой бы дополнительный адрес

Вам необходимо:

  • Создать поле AddressID в вашем пациенте (и, в конечном итоге, в таблице фармацевта) для каждого из типов адресов.
  • Если у вас действительно много типов для ваших адресов, лучше создать промежуточную таблицу, обрабатывающую m-to-m между адресом и пациентом / фармацевтом, по крайней мере, с колонкой Type в ней.

Редактировать.Реакции на вашу новую модель.

Полагаю, смысл вашей таблицы CITY в том, чтобы иметь большой список городов?Что вы можете использовать для comboboxes например?Если вы пойдете по этому пути, вы можете сделать то же самое для стран или штатов / регионов.Это нормально, НО: city_id (и, в конечном итоге, State_ID и Country_ID) должны быть частью таблицы ADDRESS.Не имеет смысла иметь адрес только с улицей, номером дома и почтовым ящиком.Это неполно, адрес также должен содержать почтовый индекс, город и страну для заполнения.

0 голосов
/ 02 января 2019

Я внесу следующие изменения в таблицу адресов:

  1. Я предпочту создать одну общую таблицу для адреса, которая также имеет City и Nationality (для простоты, иначесвяжите их, как показано на рисунке 2 ниже)
  2. добавлено поле PID как число, где вы можете сохранить идентификатор фармацевта или пациента
  3. добавлено поле Ptype как число, где необходимо сохранить значение 1, когда аптекарь и 2когда пациент, поэтому мы можем легко дифференцировать с помощью этого поля.

Изображение 1 enter image description here

Изображение 2

Image 2

...