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

Даталогическим или логическим проектированием называют проектирование логической структуры базы данных в среде конкретной СУБД. В качестве модели данных выступает реляционная база данных.

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

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

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

1) Пользователь – Код_пользователя (ключевое), Имя, Фамилия, Отчество, Логин, Пароль, Код_прав, Телефон, Почта, Адрес (таблица 1).

Сущность	Идентификатор таблицы	Атрибут	Идентификатор поля	Тип поля	Ограничения/ шаблон
Пользователь		Код_пользователя (первичный ключ)
Имя
Фамилия
Отчество
Логин
Пароль
Код_прав
Телефон
Почта
Адрес

 

 

2) Права пользователя – Код_прав (ключевое), Название_права (таблица 2).

Сущность	Идентификатор таблицы	Атрибут	Идентификатор поля	Тип поля	Ограничения/ шаблон
Права пользователя		Код_прав (первичный ключ)
Название_права

 

3) Услуги – Код_услуги (ключевое), Название_услуги, Описание, Цена, Ожидаемая_продолжительность (таблица 3).

Сущность	Идентификатор таблицы	Атрибут	Идентификатор поля	Тип поля	Ограничения/ шаблон
Услуги		Код_услуги (первичный ключ)
Название_услуги
Описание
Цена
Ожидаемая_продолжительность

 

4) Календарь – Дата (ключевое), Время, Код_сотрудника, Код_кабинета, Код_услуги, Описание, Код_статуса_мероприятия (таблица 4).

Сущность	Идентификатор таблицы	Атрибут	Идентификатор поля	Тип поля	Ограничения/ шаблон
Календарь		Дата (первичный ключ)
Время
Код_сотрудника
Код_кабинета
Код_услуги
Описание
Код_статуса_ мероприятия

 

5) Статус мероприятия – Код_статуса (ключевое), Название_статуса (таблица 5).

Сущность	Идентификатор таблицы	Атрибут	Идентификатор поля	Тип поля	Ограничения/ шаблон
Статус мероприятяи		Код_статуса (первичный ключ)
Название_статуса

 

6) Клиент – Код_клиента (ключевое), Код_пользователя, Номер_полиса (таблица 6).

Сущность	Идентификатор таблицы	Атрибут	Идентификатор поля	Тип поля	Ограничения/ шаблон
Клиент		Код_клиента (первичный ключ)
Код_пользователя
Номер_полиса

 

7) Сотрудник – Код_сотрудника (ключевое), Код_пользователя, Должность (таблица 7).

Сущность	Идентификатор таблицы	Атрибут	Идентификатор поля	Тип поля	Ограничения/ шаблон
Сотрудник		Код_сотрудника (первичный ключ)
Код_пользователя
Должность

 

8) Кабинет – Код_кабинета (ключевое), Номер_кабинета (таблица 8).

Сущность	Идентификатор таблицы	Атрибут	Идентификатор поля	Тип поля	Ограничения/ шаблон
Кабинет		Код_кабинета (первичный ключ)
Номер_кабинета

 

9) Кабинеты сотрудников – Код_кабинета_сотрудника (ключевое), Код_кабинета, Код_сотрудника (таблица9).

Сущность	Идентификатор таблицы	Атрибут	Идентификатор поля	Тип поля	Ограничения/ шаблон
Кабинеты сотрудников		Код_кабинета_ Сотрудника (первичный ключ)
Код_кабинета
Код_сотрудника

 

10) Расписание сотрудников – Код_расписания (ключевое), Код_сотрудника, Время_начала_смены, Время_конца_смены (таблица 10).

Сущность	Идентификатор таблицы	Атрибут	Идентификатор поля	Тип поля	Ограничения/ шаблон
Расписание сотрудников		Код_расписания (первичный ключ)
Код_сотрудника
Время_начала_смены
Время_конца_смены

 

Стратегия резервного копирования и восстановления

Компонент резервного копирования и восстановления SQL Server обеспечивает необходимую защиту важных данных, которые хранятся в базах данных SQL Server. Чтобы минимизировать риск необратимой потери данных, необходимо регулярно создавать резервные копии баз данных, в которых будут сохраняться производимые изменения данных. Хорошо продуманная стратегия резервного копирования и восстановления защищает базы от потери данных при повреждениях, происходящих из-за различных сбоев.

Операции резервного копирования и восстановления SQL Server выполняются в контексте модели восстановления базы данных. Модели восстановления предназначены для управления обслуживанием журналов транзакций. Модель восстановления — это свойство базы данных, которое управляет процессом регистрации транзакций, определяет, требуется ли для журнала транзакций резервное копирование, а также определяет, какие типы операций восстановления доступны. Есть три модели восстановления: простая модель восстановления, модель полного восстановления и модель восстановления с неполным протоколированием. Обычно в базе данных используется модель полного восстановления или простая модель восстановления. База данных в любой момент может быть переключена на другую модель восстановления.

В SQLServer существует три модели восстановления:

1) простая;

2) полная;

3) с неполным протоколированием.

Описание простой модели восстановления:

- Нет резервных копий журналов.

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

Описание полной модели восстановления:

- необходимы резервные копии журналов;

- потеря результатов работы из-за повреждения файлов данных исключена;

- возможно восстановление до произвольного момента времени (например до ошибки приложения или пользователя).

Описание модели восстановления с неполным протоколированием:

- необходимы резервные копии журналов;

- дополнение к полной модели полного восстановления, позволяющее выполнять высокопроизводительные операции массового копирования;

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

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

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

Для проектируемой базы данных будем использовать простую модель восстановления. Данная модель будет включать только полные резервные копии. Копию будем создавать на дисковом устройстве. Создание полной резервной копии проектируемой базы данных через запрос будет выглядеть так:

USE master;

GO

BACKUP DATABASE stomatologia

TO DISK='C: \ stomatologia \ stomatologia.bak';

Конструкция BACKUP DATABASE означает, что мы производим полное резервное копирование базы данных.

Далее задаём модель восстановления (простую модель восстановления), с помощью конструкции ALTER DATABASE:

USE master;

GO

ALTER DATABASE stomatologia

SET RECOVERY SIMPLE;

GO

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

 

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

⇐ Предыдущая12345Следующая ⇒

Поделиться: