Курсовая 5 класс. Мой курсовой БД. 1 Анализ предметной области. 5 Постановка задачи 11
 Скачать 2.77 Mb.
|
2.2.1. Идентификация сущностей и связей. ER-диаграмма логического уровня.Erwin имеет два уровня представления модели – логический и физический. Логический уровень – это абстрактный взгляд на данные. Объекты модели, представляемые на нем, называются сущностями и атрибутами. Логическая модель данных является универсальной, т.к. не зависит от конкретной СУБД. Для отображения информационной модели рассматриваемого процесса на логической модели используются следующие сущности: - «Персонал_Поликлиники» – для фиксации информации о сотрудниках поликлиники, содержит личные данные, специализацию; - «Расписание_приёма_врачей_поликлиники» – для хранения информации о времени и месте приёма врачей поликлиники; - «История_болезни_пациента» – запись информации о пациентах поликлиники - «Сведения_о_заболевании» – заболевания пациентов; - «Сведения_об_анализах» хранит информацию об анализах, которые сдавали пациенты; - «Свединия_о_льготах» – информация ольготах, положенных пациентам; - «Сведения_о_санаторном_лечении» – информация о санаториях и лечившихся в них пациентах; - «Сведения_о_препаратах_аптеки» хранит информацию о препаратах, содержащихся в аптеке; - «Сведения_о_привозе_препаратов»- информация о количестве, времени привоза; - «Сведения_о_поставщиках_препаратов» . Для однозначного определения записей в каждом из отношений выделен первичный ключ (простой или составной). Внешние ключи для отношений БД: в отношениях «Расписание_приёма_врачей_поликлиники» и «Персонал_Поликлиники» - это ключ «Специализация»; в отношениях «История_болезни_пациента» и «Сведения_об_анализах» - это ключ «Номер_Пациента» в отношениях «История_болезни_пациента» и «Сведения_о_заболевании» - это ключ «Номер_Пациента» На логическом уровне проектирования в моделируемой базе данных присутствуют следующие типы связей между описанными сущностями: неиденцифицирующие связи; иденцифицирующие связи; связи многие-ко-многим Связь между сущностями «Расписание_приёма_врачей_поликлиники» и «Персонал_Поликлиники» идентифицирующая, не разрешающая присутствие нулей. Тип связи 1 к одному, т.к. в поликлинике каждому времениприёма соответствует 1 врач. и 1 ко многимттствие нулейтрудники библиотеки Связь между сущностями «История_болезни_пациента» и «Сведения_об_анализах» неидентифицирующая, не разрешающая присутствие нулей, т.к. каждый номер закреплён за отдельным пациентом. Тип связи 1 ко многим, т.к. пациент может иметь много анализов. Связь между сущностями «История_болезни_пациента» и «Сведения_о_заболевании» неидентифицирующая, не разрешающая присутствие нулей, т.к. каждый номер закреплён за отдельным пациентом. Тип связи 1 ко многим, т.к. пациент может перенести не одну болезнь. Связь между сущностями «История_болезни_пациента» и «Сведения_о_льготах» неидентифицирующая, не разрешающая присутствие нулей, т.к. каждый номер закреплён за отдельным пациентом. Тип связи 1 к одному, т.к. пациент может иметь только 1 тип льгот. Связь между сущностями «История_болезни_пациента» и «Сведения_о_санаторном_лечении» идентифицирующая, не разрешающая присутствие нулей, т.к. каждый номер закреплён за отдельным пациентом. Тип связи 1 ко многим, т.к. пациент может неоднократно лечится в разных санаториях. Связь между сущностями «Сведения_о_заболевании» и «Сведения_о_препаратах_аптеки» неидентифицирующая. Тип связи 1 к одному, т.к. содержит информацию о препарате, выписанном во времязаболевания пациента. Связь между сущностями «Сведения_о_препаратах_аптеки» и «Сведения_о_привозе_препаратов » идентифицирующая, т.к. для получения информации о препарате необходима информация, о его привозе в аптеку. Тип связи 1 к одному т.к. одному тиду препарата аптеки соответствуют одни сведения о привозе. Связь между сущностями «Сведения_о_препаратах_аптеки» и «Сведения_о_постащиках_препаратов» многие ко многим, т.к. у одного препарата может быть не один поставщик. ER-диаграмма логического уровня представлена в приложении2 (рисунок 10).  Рисунок 10 – ER-диаграмма логического уровня 2.2.2. ER-диаграмма физического уровня. Ограничения доменов. Ограничения ссылочной целостности. Переопределение триггеров. Индексирование отношений Физическая модель данных зависит от конкретной СУБД. В ней содержится информация обо всех объектах БД. Одной и той же логической модели может соответствовать несколько разных физических. В физической модели важно описать всю информацию о конкретных физических объектах – таблицах, колонках, индексах, процедурах. Проверим, удовлетворяют ли все имеющиеся отношения соответствующим наборам ограничений. Первая нормальная форма требует, чтобы значения всех атрибутов отношения были атомарными. При рассмотрении информационной модели было отмечено, что значения атрибутов всех отношений логически разделить на элементы нельзя и, следовательно, они удовлетворяют условию первой нормальной формы. Пример, рассмотрим таблицу «Расписание_приёма_врачей_поликлиники». Ключевой аттрубут в ней – «Специализация» не может быть разделен на элементы. Не ключевые аттрубуты – «Табельный_номер», «Время_приёма», «Кабинет» также являются атомарными. Вторая нормальная форма требует, чтобы отношение находилось в первой нормальной форме, и каждый не ключевой атрибут функционально полно зависел от первичного ключа. И это требование также выполняется в рассматриваемой модели. Пример, рассмотрим таблицу «Сведения_о_препаратах_аптеки». Ключевой аттрубут в ней – «Выписанные_препараты». Не ключевые аттрубуты – «Тип_продажи», «Цена», «Имеется_в_наличии», «Количество» зависят функционально полно только от первичного ключа. Для нормализации схем отношений к третьей нормальной форме необходимо чтобы каждый детерминант (любой атрибут, от которого функционально полно зависит некоторый другой атрибут) является возможным ключом. В рассматриваемой модели это условие соблюдается. Пример, рассмотрим таблицу «Выписанные_препараты». Как было отмечено выше, все неключевые атрибуты функционально полно зависят от первичного ключа, т.е. первичный ключ является детерминантом. Реализация ссылочной целостности: При изменении информации о каком-либо отделе из таблицы «Поставщик» в таблицах «Сведения_о_препаратах_аптеки», «Сведения_о_привозе_препаратов» и информация будет автоматически меняться (каскадное обновление); При изменении информации о каком-либо сотруднике из таблицы «Расписание_приёма_врачей_поликлиники» в таблице «Персонал_Поликлиники» информация будет автоматически изменяться (каскадное обновление); В таблице «История_болезни_пациента» разрешено изменение записей (каскадное обновление), удаление данных из этой таблицы запрещается специальным триггером (запрет удаления), т.к. эта таблица содержит информацию обо всех пациентах поликлиники; В таблице «Свединия_о_льготах» разрешено изменение записей (каскадное обновление), удаление данных из этой таблицы запрещается (запрет удаления), т.к информация обо всех льготах должна храниться постоянно. Типы данных 1. Рассмотрим таблицу «Расписание_приёма_врачей_поликлиники». Ключевое поле этой таблицы Специализация содержит специализацию врача. Следовательно, тип данных поля Специализация должен быть строковым с длиной не менее 15 символов. Выбираем тип varchar(20). 2. В таблице «История_болезни_пациента» имеется поле «Дата_рождения». Это поле содержит число, месяц, год даты, рождения пациента книга. Тип данных для неё – datetime. 3. Рассмотрим таблицу «Персонал_Поликлиники». Ключевое поле этой таблицы (табельный номер) представляет собой номер, который присваивают каждому сотруднику при принятии на работу. Он представляет собой набор цифр (например, 2431). Следовательно, тип данных поля табельный номер должен быть числовым целым. Выбираем тип int. ER-диаграмма физического уровня показана в приложении 3 (рисунок 11).  Рисунок 11 – ER-диаграмма физического уровня |