В третьем проектном наборе в таблице, содержащей личную информацию о пациентах, как и в первом, отсутствует искусственный идентификатор пациента, и нет возможности указания нескольких телефонных номеров. Выделение в отдельную таблицу информации о месте работы в третьем наборе позволяет избежать появления ошибок при вводе данных и ведет к уменьшению объема хранимой информации (поле «место работы» содержит только числовой код). В таблице, отображающей процесс приема у терапевта, введен искусственный идентификатор – код, здесь же содержится информация о лекарствах и методах лечения, что в результате может привести к логическому несоответствию между болезнью, лекарством и процедурой (для болезни могут быть указаны лекарства, не относящиеся к этому заболеванию). Из-за этого существует опасность возникновения ошибок. В таблице, содержащей информацию о болезнях, отсутствуют данные о лекарствах и методах лечения, притом, что в первом и втором наборах данные о болезни, методе лечения и лекарствах содержатся в одной таблице.
Вывод
Все три набора получились похожими, но в тоже время каждый набор накладывает свои ограничения на хранение информации и имеет свои достоинства и недостатки.
В первом наборе нет возможности хранения нескольких телефонных номеров для одного пациента.
Во втором проектном наборе отсутствует вышеупомянутый недостаток.
В третьем проектном наборе, как и во втором, было выделено пять таблиц, но их организация заметно отличается от первого и второго наборов. Выделение в отдельную таблицу мест работы, при существенном размере базы данных, ведет к уменьшению объема занимаемого места. Существенный недостаток данной реализации заключается в том, что эта база данных как ни одна из первых двух предрасположена к возникновению ошибок.
Общим недостатком всех трех проектных наборов является то, что информация о специалистах хранится в отдельной таблице, но личных данных о специалистах в базе данных не содержится, т.е. в базу данных нельзя внести информацию о двух терапевтах (двух лорах, психиатрах…).
Из вышесказанного следует, что второй набор, выполненный методом «сущность - связь» является более всего приближенным к реальности, т.к. не обладает недостатками, присущими первому и второму наборам, а также наиболее полно отражает связи между объектами.
Построение запросов.
Запрос 1. а) Для выбранного пациента изменить дату сдачи крови.
PARAMETERS [номер паспорта] Long, [Введите дату] DateTime;
UPDATE patient SET patient.BloodDate = [Введите дату]
WHERE (((patient.PasNum)=[номер паспорта]));
б) Для выбранного пациента изменить дату сдачи флюорографии.
PARAMETERS [номер паспорта] Long, [Введите дату] DateTime;
UPDATE patient SET patient.XRayDate = [Введите дату]
WHERE (((patient.PasNum)=[номер паспорта]));
Запрос 2.
Ввести дату о выздоровлении выбранного пациента
PARAMETERS [код пациента] Short, [код болезни] Short, [дата выздоровления] Text ( 255 );
UPDATE Specialist INNER JOIN (patient INNER JOIN (Illness INNER JOIN Objects ON Illness.illnessID = Objects.ilnessID) ON patient.PatientID = Objects.PatientID) ON Specialist.SpecID = Illness.SpecID SET Objects.OkDate = [дата выздоровления]
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.