Инфологическая модель базы данных

Введение

Цель курсового проектирования – применение на практике знаний, полученных в процессе изучения курса " Базы данных" и получение практических навыков проектирования и реализации баз данных, для последующего создания информационных систем.

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

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

 

Проектирование базы данных

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

Проектируемая база данных создается для клиники, предоставляющей медицинские услуги в области стоматологии. Данная база данных должна позволять регистратору стоматологической клиники записывать клиентов на прием к врачам, предоставлять им график работы отдельного специалиста и цену оказываемой услуги. База предназначена для регистратора клиники, что улучшит и упростит управление записей на прием, уменьшит очереди и упростит рутинные функции регистратора клиники.

В разрабатываемой базе данных будет храниться информация о пользователях, клиентах, сотрудниках и предоставляемых ими услугах, а также расписание записей к специалистам.

База данных предназначена для выполнения следующих функций:

- хранение информации о сотрудниках, клиентах, услугах, расписании работы сотрудников и графике приема пациентов;

- поиск данных о клиентах клиники;

- поиск клиентов, которые записались на прием или уже посетили специалиста;

- предоставление отчёта о выполненных и запланированных услугах.

Основные задачи:

• проведение мероприятий по профилактике заболеваний челюстно-лицевой области среди населения и в организованных коллективах

• проведение и организация мероприятий, направленных на раннее выявление больных с заболеваниями челюстно-лицевой области и своевременное их ле­чение

• оказание квалифицированной амбулаторной стоматологической помощи на­селению

Клиника предоставляет следующие услуги:
- Анестезия ( Цена – 300 р.);
- Оказание неотложной помощи ( Цена – 830 р.);
- Отбеливание ( Цена – 24.000 р.);
- Лечение кариеса на временном зубе ( Цена – 1.100 р.);
- Исправление прикуса с помощью пластин ( Цена – 4.800 р.);

- Постановка пломбы на временный зуб ( Цена – 250 р.);

- Постановка пломбы на постоянный зуб (Цена – 1250 р.);

- Серебрение (Цена – 400 р.);
- Консультация зубного врача с составлением плана лечения ( Цена – 600р.);

- Осмотр первичный ( Цена – 200 р.);

- Снимок рентгеновский ( Цена – 200 р.).

 

Инфологическая модель базы данных

На этапе инфологического проектирования базы данных строится инфологическая модель предметной области, которая должна отражать семантику (смысл взаимосвязи объектов) предметной области. Инфологическая модель строится не для отдельного объекта, а отображает классы объектов и связи между ними. Диаграмма, отражающая связи объектов предметной области, называется диаграммой ER-типа (Entity – сущность, Relationship – связь).

Объекты предметной области:

- пользователь;

- права пользователя;

- услуги;

- календарь;

- статус мероприятия;

- клиент;

- сотрудник;

- кабинеты сотрудников;

- расписание сотрудников.

 

Основные атрибуты объектов:

 

1. Пользователь – код пользователя, имя, фамилия, отчество, логин, пароль, код прав, телефон, почта, адрес.

2. Права пользователя – код прав, название права (администратор, пользователь, сотрудник).

3. Услуги – код услуги, название услуги, описание, цена, ожидаемая продолжительность.

4. Календарь – дата, время, код сотрудника, код кабинета, код услуги, описание, код статуса мероприятия.

5. Статус мероприятия – код статуса, название статуса (запланировано, завершено, отменено).

6. Клиент – код клиента, код пользователя, номер полиса.

7. Сотрудник – код сотрудника, код пользователя, должность.

8. Кабинет – код кабинета, номер кабинета.

9. Кабинеты сотрудников – код кабинета сотрудника, код кабинета, код сотрудника.

10. Расписание сотрудников – код расписания, код сотрудника, время начала смены, время конца смены.

 

Выделим основные сущности:

- сущность «Пользователь»;

- сущность «Права пользователя»;

- сущность «Услуги»;

- сущность «Календарь»;

- сущность «Статус мероприятия»;

- сущность «Клиент»;

- сущность «Сотрудник»;

- сущность «Кабинет»;

- сущность «Кабинеты сотрудников»;

- сущность «Расписание сотрудников».

Сущность «Сотрудник» содержит информацию о сотрудниках. Отдельный экземпляр этой сущности содержит информацию о расписании сотрудников, предоставляемых ими услугах.

Так как услуги предоставляются клиентам, вводится сущность «Клиент». Каждый экземпляр этой сущности содержит информацию о клиентах стоматологической клиники.

Каждый специалист клиники работает в своем кабинете, поэтому для хранения информации об этом используется сущность «Кабинеты сотрудников.

В сущности «Расписание сотрудников» хранится информация о графике работы сотрудников клиник, а сущность «Календарь» содержит график записи о пациентах, которые записаны на прием к специалистам на определенные виды услуг.

Далее определяем уникальные ключи экземпляров каждой сущности:

- сущность «Пользователь» – Код пользователя;

- сущность «Права пользователя» – Код прав;

- сущность «Услуги» – Код услуги;

- сущность «Календарь» – Дата;

- сущность «Статус мероприятия» – Код статуса мероприятия;

- сущность «Клиент» – Код клиента;

- сущность «Сотрудник» – Код сотрудника;

- сущность «Кабинет» – Код кабинета;

- сущность «Кабинеты сотрудников» – Код кабинета сотрудников;

- сущность «Расписание сотрудников» – Код расписания.

Далее представлена ER – диаграмма.

 

Рисунок 1 – ER - диаграмма

Реализация базы данных

Создание структуры базы данных

Структура базы данных следующая:

· База данных состоит из одной или нескольких таблиц.

· Каждая таблица имеет одно или несколько полей.

· В каждой таблице имеется одна или несколько записей.

На данном этапе были разработаны сама база данных, три таблицы и индексы.

База данных и таблицы

В этом разделе описаны:

§ алгоритм создания базы данных

§ алгоритмы создания всех таблиц базы данных с указанием полей, назначенных для них ограничений, обозначением первичных и внешних ключей отношений.

Для начала была создана база данных в два этапа:

1) организация самой базы данных (Файл с расширением *.mdf);

2) организация принадлежащего ей журнала транзакций (Файл с расширением *.ldf).

Создание базы данных осуществляется командой CREATE DATABASE:

CREATE DATABASE stomatologia

ON PRIMARY (NAME= stomatologia, FILENAME=" C: \ stomatologia \ stomatologia.mdf",

SIZE=50MB, MAXSIZE=250MB, FILEGROWTH=25)

LOG ON

(NAME= stomatologia Log, FILENAME=" C: \ stomatologia \ stomatologia Log.ldf",

SIZE=10MB, MAXSIZE=100MB, FILEGROWTH=5)

Отсюда следует, что именем базы данных будет являться «stomatologia». ON – определяет список файлов на диске для размещения информации, хранящейся в базе данных. PRIMARY – определяет первичный файл. LOGON – определяет список файлов на диске для размещения журнала транзакций. В параметрах NAME указывается логическое имя файла, в FILENAME – физическое имя файла, в SIZE – размер файла, в MAXSIZE – максимальный размер файла, в FILEGROWTH – величина прироста.

Далее были созданы следующие таблицы базы данных.

1) Таблица «contactKlienta»:

use stomatologia;

CREATE TABLE [dbo].[contactKlienta](

[id] [int] IDENTITY(1, 1) NOT NULL,

[klientId] [int] NOT NULL,

[contactTypeId] [int] NOT NULL,

[znachenie] [varchar](250) NOT NULL)

После добавления записей получили таблицу, представленную на рисунке 2.2.1.1.

Рисунок 2.2.1.1 – Таблица «contactKlienta»

2) Таблица «contactSotrudnika»:

use stomatologia;

CREATE TABLE [dbo].[contactSotrudnika](

[id] [int] IDENTITY(1, 1) NOT NULL,

[contactTypeId] [int] NOT NULL,

[znachenie] [varchar](250) NOT NULL,

[sotrudnikId] [int] NOT NULL)

После добавления записей получили таблицу, представленную на рисунке 2.2.1.2.

Рисунок 2.2.1.2 – Таблица «contactSotrudnika»

 

3) Таблица «contactType»:

use stomatologia;

CREATE TABLE [dbo].[contactType](

[id] [int] IDENTITY(1, 1) NOT NULL,

[contactType] [varchar](250) NOT NULL)

После добавления записей получили таблицу, представленную на рисунке 2.2.1.3.

Рисунок 2.2.1.3 – таблица «contactType»

4) Таблица «dniNedeli»:

use stomatologia;

CREATE TABLE [dbo].[dniNedeli](

[id] [int] IDENTITY(1, 1) NOT NULL,

[day] [varchar](50) NOT NULL)

После добавления записей получили таблицу, представленную на рисунке 2.2.1.4.

Рисунок 2.2.1.4 – таблица «dniNedeli»

5) Таблица «dniRabotiSotrudnikov»:

use stomatologia;

CREATE TABLE [dbo].[dniRabotiSotrudnikov](

[id] [int] IDENTITY(1, 1) NOT NULL,

[sotrudnikId] [int] NOT NULL,

[dayId] [int] NOT NULL,

[timeStart] [time](7) NOT NULL CONSTRAINT [DF_dniRabotiSotrudnikov_timeStart] DEFAULT ('9: 00'),

[timeEnd] [time](7) NOT NULL CONSTRAINT [DF_dniRabotiSotrudnikov_timeEnd] DEFAULT ('17: 00'))

После добавления записей получили таблицу, представленную на рисунке 2.2.1.4.

Рисунок 2.2.1.4 – таблица «dniRabotiSotrudnikov»

6) Таблица «dolznost»:

use stomatologia;

CREATE TABLE [dbo].[dolznost](

[id] [int] IDENTITY(1, 1) NOT NULL,

[dolznost] [varchar](250) NOT NULL)

После добавления записей получили таблицу, представленную на рисунке 2.2.1.4.

Рисунок 2.2.1.4 – таблица «dolznost»

7) Таблица «kabinet»:

use stomatologia;

CREATE TABLE [dbo].[kabinet](

[id] [int] IDENTITY(1, 1) NOT NULL,

[kabinet] [varchar](250) NOT NULL)

После добавления записей получили таблицу, представленную на рисунке 2.2.1.4.

Рисунок 2.2.1.4 – таблица «kabinet»

8) Таблица «klient»:

use stomatologia;

CREATE TABLE [dbo].[klient](

[id] [int] IDENTITY(1, 1) NOT NULL,

[fam] [varchar](250) NOT NULL,

[name] [varchar](250) NULL,

[otch] [varchar](250) NULL,

[userId] [int] NULL,

[adres] [varchar](250) NULL,

[polis] [varchar](50) NULL)

После добавления записей получили таблицу, представленную на рисунке 2.2.1.4.

Рисунок 2.2.1.4 – таблица «klient»

9) Таблица «sotrudnik»:

use stomatologia;

CREATE TABLE [dbo].[sotrudnik](

[id] [int] IDENTITY(1, 1) NOT NULL,

[fam] [varchar](250) NOT NULL,

[name] [varchar](250) NULL,

[otch] [varchar](250) NULL,

[dolznostId] [int] NOT NULL,

[userID] [int] NULL)

После добавления записей получили таблицу, представленную на рисунке 2.2.1.4.

Рисунок 2.2.1.4 – таблица «sotrudnik»

10) Таблица «user»:

use stomatologia;

CREATE TABLE [dbo].[user](

[id] [int] IDENTITY(1, 1) NOT NULL,

[login] [varchar](250) NOT NULL,

[pas] [varchar](250) NOT NULL)

После добавления записей получили таблицу, представленную на рисунке 2.2.1.4.

Рисунок 2.2.1.4 – таблица «user»

11) Таблица «usluga»:

use stomatologia;

CREATE TABLE [dbo].[usluga](

[id] [int] IDENTITY(1, 1) NOT NULL,

[usluga] [varchar](250) NOT NULL,

[price] [float] NOT NULL)

После добавления записей получили таблицу, представленную на рисунке 2.2.1.4.

Рисунок 2.2.1.4 – таблица «usluga»

12) Таблица «zakazanieUslugiDetali»:

use stomatologia;

CREATE TABLE [dbo].[zakazanieUslugiDetali](

[id] [int] IDENTITY(1, 1) NOT NULL,

[uslugaId] [int] NOT NULL,

[kolvoUslug] [int] NOT NULL,

[zakazinieUslugiObshieId] [int] NOT NULL)

После добавления записей получили таблицу, представленную на рисунке 2.2.1.4.

Рисунок 2.2.1.4 – таблица «zakazanieUslugiDetali»

13) Таблица «zakazinieUslugiObshie»:

use stomatologia;

CREATE TABLE [dbo].[zakazinieUslugiObshie](

[id] [int] IDENTITY(1, 1) NOT NULL,

[klientId] [int] NOT NULL,

[sotrudnikId] [int] NULL,

[date] [date] NOT NULL)

После добавления записей получили таблицу, представленную на рисунке 2.2.1.4.

Рисунок 2.2.1.4 – таблица «zakazinieUslugiObshie»

14) Таблица «zurnal»:

use stomatologia;

CREATE TABLE [dbo].[zurnal](

[id] [int] IDENTITY(1, 1) NOT NULL,

[date] [date] NOT NULL,

[time] [time](7) NOT NULL,

[sotrudnikId] [int] NOT NULL,

[klientId] [int] NOT NULL,

[opisanie] [text] NULL,

[kabinetId] [int] NULL)

После добавления записей получили таблицу, представленную на рисунке 2.2.1.4.

Рисунок 2.2.1.4 – таблица «zurnal»

Далее установим ключевые поля:

1)

Индексы

Индексы - это наборы уникальных значений для некоторой таблицы с соответствующими ссылками на данные.

Создание индексов поможет существенно повысить производительность выполнения операций поиска и выборки данных.

Некоторые индексы создаются автоматически, при задании первичного ключа. Например:

1) PK_contactKlienta – для таблицы «contactKlienta»;

2) PK_contactSotrudnika – для таблицы «contactSotrudnika»;

3) PK_contactType – для таблицы «contactType»;

4) PK_dniNedeli – для таблицы «dniNedeli»;

5) PK_dniRabotiSotrudnikov – для таблицы «dniRabotiSotrudnikov»;

6) PK_dolznost – для таблицы «dolznost»;

7) PK_kabinet – для таблицы «kabinet»;

8) PK_klient – для таблицы «klient»;

9) PK_sotrudnik – для таблицы «sotrudnik»;

10) PK_user – для таблицы «user»;

11) PK_usluga – для таблицы «usluga»;

12) PK_zakazanieUslugiDetalno – для таблицы «zakazanieUslugiDetali»;

13) PK_zakazinieUslugiList – для таблицы «zakazinieUslugiObshie»;

14) PK_zurnal – для таблицы «zurnal».

Представленные ключи относятся к кластеризованным и являются уникальными.

Для таблицы «contactKlienta» по столбцу «Фамилия» создадим два некластеризованных индекса. В отличие от кластеризованных индексов, они не перестраивают физическую структуру таблицы, а лишь организуют ссылки на соответствующие строки. Элементы представленных индексов будут располагаться по возрастанию. Индексы создаются вручную при помощи запроса.

Создание индекса index_reg для таблицы Клиенты:

CREATE UNIQUE NONCLUSTERED INDEX index_reg

ON Клиенты(Фамилия asc)

Представленные индексы являются уникальными.

Создание представлений

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

Одним из главных достоинств представлений является то, что они сильно упрощают взаимодействие с данными в базе данных. Допустим, необходимо каждый раз делать сложную по своей структуре выборку, и запрос на данную выборку может быть очень сложный. И если бы не было представлений, то приходилось бы каждый раз запускать этот запрос, или даже его модифицировать, например, для вставки условий. А так как есть такие объекты как представления, то этого делать не придется. Достаточно создать одно представление, и потом уже к нему можно обращаться с помощью уже простых запросов, которые также можно делать сложными, если это необходимо. Например, представления также можно объединять с другими таблицами или другими представлениями.

В данном разделе приводятся текст запроса, SQL-сценарии для создания представлений и результаты их работы в форме таблицы (или рисунка).

Многотабличный запрос

Данный запрос должен выполнять выборку информации из нескольких таблиц.

Для базы данных «Стоматология» был создан многотабличный запрос, который осуществляет выборку всех клиентов из таблицы «Клиенты», которые посещали определенного специалиста, и время посещения. Выборка данных осуществляется также из таблицы «Журнал», так как она является связующей между таблицами «Клиенты» и «Сотрудники». Данный запрос был записан в представление «Пациенты сотрудника».

Текст запроса выглядит следующим образом:

CREATE VIEW [Пациенты сотрудника]

AS

SELECT dbo.klient.fam AS [Фамилия клиента], dbo.zurnal.date AS [Дата], dbo.zurnal.time AS [Время]

FROM dbo.klient INNER JOIN dbo.zurnal ON dbo.klient.id = dbo.zurnal.klientId INNER JOIN

dbo.sotrudnik ON dbo.sotrudnik.id = dbo.zurnal.sotrudnikId

WHERE dbo.zurnal.sotrudnikId = '8'

Результат запроса показан на рисунке 2.3.2.1.

Рисунок 2.3.2.1 – Представление «Пациенты сотрудника»

Итоговый запрос

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

 

Рисунок 2.3.4.1 – Представление «Итог».

Примеры запросов на модификацию данных

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

Запросы на модификацию данных представляют собой достаточно мощное средство, так как позволяют оперировать не только отдельными строками, но и набором строк. С помощью запросов модификации данных пользователь может добавить, удалить или обновить блоки данных. Существует три вида запросов модификации данных:

· INSERT INTO – запрос добавления;

· DELETE – запрос удаления;

· UPDATE – запрос обновления.

 

Простые запросы

В данном разделе приводятся тексты простых однотабличных запросов, используемых для выполнения операций вставки, обновления и удаления данных: INSERT, DELETE и UPDATE.

Операция вставки INSERT

INSERT – оператор языка SQL, который позволяет добавить строки в таблицу, заполняя их значениями. Значения можно вставлять перечислением с помощью слова values и перечислив их в круглых скобках через запятую или оператором SELECT.

Был создан запрос, осуществляющий вставку записи в таблицу «Услуги».

Текст запросы выглядит следующим образом:

INSERT INTO [dbo].[usluga] ([usluga], [price])

VALUES

('Удаление зуба', '500')

Из запроса видно, что была вставлена запись со следующими полями: Код_услуги – 18, Услуга – Удаление зуба, Цена - 500.

Операция удаления DELETE

DELETE – в языках, подобных SQL, DML-операция удаления записей из таблицы. Критерий отбора записей для удаления определяется выражением where. В случае, если критерий отбора не определён, выполняется удаление всех записей.

Был создан запрос, который удаляет услуги из таблицы «Услуги», имеющих название «Удаление услуги».

Текст запроса выглядит следующим образом:

DELETE FROM dbo.usluga

WHERE usluga=Удаление зуба

Описание триггеров

В этом разделе приводится описание триггеров, использующихся в проекте.

Триггеры – особый инструмент SQL-сервера, используемый для поддержания целостности данных в базе данных. Триггеры можно рассматривать как своего рода фильтры, вступающие в действие после выполнения всех операций в соответствии с ограничениями, стандартными значениями и так далее.

Существует три типа триггеров:

1) INSERT TRIGGER – запускаются при попытке вставки данных с помощью команды INSERT.

2) UPDATE TRIGGER – запускаются при попытке изменения данных с помощью команды UPDATE.

3) DELETE TRIGGER – запускаются при попытке удаления данных с помощью команды DELETE.

Для проектируемой базы данных было разработано четыре триггера, два из которых на удаление (DELETE), один на вставку (INSERT) и один на обновление (UPDATE).

Для данной базы данных было создано три триггера: на удаление, обновление и вставку, которые представлены ниже:

Заключение

 

Введение

Цель курсового проектирования – применение на практике знаний, полученных в процессе изучения курса " Базы данных" и получение практических навыков проектирования и реализации баз данных, для последующего создания информационных систем.

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

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

 

Проектирование базы данных

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

Проектируемая база данных создается для клиники, предоставляющей медицинские услуги в области стоматологии. Данная база данных должна позволять регистратору стоматологической клиники записывать клиентов на прием к врачам, предоставлять им график работы отдельного специалиста и цену оказываемой услуги. База предназначена для регистратора клиники, что улучшит и упростит управление записей на прием, уменьшит очереди и упростит рутинные функции регистратора клиники.

В разрабатываемой базе данных будет храниться информация о пользователях, клиентах, сотрудниках и предоставляемых ими услугах, а также расписание записей к специалистам.

База данных предназначена для выполнения следующих функций:

- хранение информации о сотрудниках, клиентах, услугах, расписании работы сотрудников и графике приема пациентов;

- поиск данных о клиентах клиники;

- поиск клиентов, которые записались на прием или уже посетили специалиста;

- предоставление отчёта о выполненных и запланированных услугах.

Основные задачи:

• проведение мероприятий по профилактике заболеваний челюстно-лицевой области среди населения и в организованных коллективах

• проведение и организация мероприятий, направленных на раннее выявление больных с заболеваниями челюстно-лицевой области и своевременное их ле­чение

• оказание квалифицированной амбулаторной стоматологической помощи на­селению

Клиника предоставляет следующие услуги:
- Анестезия ( Цена – 300 р.);
- Оказание неотложной помощи ( Цена – 830 р.);
- Отбеливание ( Цена – 24.000 р.);
- Лечение кариеса на временном зубе ( Цена – 1.100 р.);
- Исправление прикуса с помощью пластин ( Цена – 4.800 р.);

- Постановка пломбы на временный зуб ( Цена – 250 р.);

- Постановка пломбы на постоянный зуб (Цена – 1250 р.);

- Серебрение (Цена – 400 р.);
- Консультация зубного врача с составлением плана лечения ( Цена – 600р.);

- Осмотр первичный ( Цена – 200 р.);

- Снимок рентгеновский ( Цена – 200 р.).

 

Инфологическая модель базы данных

На этапе инфологического проектирования базы данных строится инфологическая модель предметной области, которая должна отражать семантику (смысл взаимосвязи объектов) предметной области. Инфологическая модель строится не для отдельного объекта, а отображает классы объектов и связи между ними. Диаграмма, отражающая связи объектов предметной области, называется диаграммой ER-типа (Entity – сущность, Relationship – связь).

Объекты предметной области:

- пользователь;

- права пользователя;

- услуги;

- календарь;

- статус мероприятия;

- клиент;

- сотрудник;

- кабинеты сотрудников;

- расписание сотрудников.

 

Основные атрибуты объектов:

 

1. Пользователь – код пользователя, имя, фамилия, отчество, логин, пароль, код прав, телефон, почта, адрес.

2. Права пользователя – код прав, название права (администратор, пользователь, сотрудник).

3. Услуги – код услуги, название услуги, описание, цена, ожидаемая продолжительность.

4. Календарь – дата, время, код сотрудника, код кабинета, код услуги, описание, код статуса мероприятия.

5. Статус мероприятия – код статуса, название статуса (запланировано, завершено, отменено).

6. Клиент – код клиента, код пользователя, номер полиса.

7. Сотрудник – код сотрудника, код пользователя, должность.

8. Кабинет – код кабинета, номер кабинета.

9. Кабинеты сотрудников – код кабинета сотрудника, код кабинета, код сотрудника.

10. Расписание сотрудников – код расписания, код сотрудника, время начала смены, время конца смены.

 

Выделим основные сущности:

- сущность «Пользователь»;

- сущность «Права пользователя»;

- сущность «Услуги»;

- сущность «Календарь»;

- сущность «Статус мероприятия»;

- сущность «Клиент»;

- сущность «Сотрудник»;

- сущность «Кабинет»;

- сущность «Кабинеты сотрудников»;

- сущность «Расписание сотрудников».

Сущность «Сотрудник» содержит информацию о сотрудниках. Отдельный экземпляр этой сущности содержит информацию о расписании сотрудников, предоставляемых ими услугах.

Так как услуги предоставляются клиентам, вводится сущность «Клиент». Каждый экземпляр этой сущности содержит информацию о клиентах стоматологической клиники.

Каждый специалист клиники работает в своем кабинете, поэтому для хранения информации об этом используется сущность «Кабинеты сотрудников.

В сущности «Расписание сотрудников» хранится информация о графике работы сотрудников клиник, а сущность «Календарь» содержит график записи о пациентах, которые записаны на прием к специалистам на определенные виды услуг.

Далее определяем уникальные ключи экземпляров каждой сущности:

- сущность «Пользователь» – Код пользователя;

- сущность «Права пользователя» – Код прав;

- сущность «Услуги» – Код услуги;

- сущность «Календарь» – Дата;

- сущность «Статус мероприятия» – Код статуса мероприятия;

- сущность «Клиент» – Код клиента;

- сущность «Сотрудник» – Код сотрудника;

- сущность «Кабинет» – Код кабинета;

- сущность «Кабинеты сотрудников» – Код кабинета сотрудников;

- сущность «Расписание сотрудников» – Код расписания.

Далее представлена ER – диаграмма.

 

Рисунок 1 – ER - диаграмма

12345Следующая ⇒

Поделиться: