Разработка базы данных «Техническая поддержка IT-помощник»

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

Каждая сущность должна обладать некоторыми свойствами:

· должна иметь уникальное имя, и к одному и тому же имени должна всегда применяться одна и та же интерпретация;

· обладать одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь;

· обладать одним или несколькими атрибутами (первичным ключом), которые однозначно идентифицируют каждый экземпляр сущности, т. е. делают уникальной каждую строку таблицы;

· может обладать любым количеством связей с другими сущностями.

Существует два типа сущностей: сильная(если сущность не зависит от существования другой сущности) и слабая(если ее существование зависит от существования других сущностей).

В таблице 1.1 показаны все существующие сущности базы данных, их описания, псевдонимы и типы.

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

Кардинальность:

1. Связь типа «один-к-одному» означает, что один экземпляр первой сущности связан с одним экземпляром второй сущности. Связь «один-к-одному» чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две.

2. Связь типа «один-ко-многим» означает, что один экземпляр первой сущности связан с несколькими экземплярами второй сущности. Это наиболее часто используемый тип связи.

 

 

 

 

 

Таблица 1.1. Сведения о типах сущностей

№	Имя сущности	Описание	Тип
1	Клиент	Содержит информацию о клиенте	Слабый
2	Мастер	Содержит информацию о сотруднике	Слабый
3	Заявка	Содержит информацию о оставленной заявке	Слабый
4	Вид работ	Информация о видах работ	Сильный
5	Способ оплаты	Описание способа оплаты	Сильный
6	Выполненная работа	Информация о всей сделанной работы у клиента	Слабый
7	Статус	Информация о типе клиента(юрид, физ.)	Сильный
8	Отдел	Информация о филиалах	Сильный
9	Район	Информация о районе города	Сильный
10	Акции	Информация об акциях	Сильный
11	Скидки	Информация о скидках	Сильный
12	Состояние заявки	Информация о текущем состоянии заявок(в работе, выполнена)	Сильный

 

Таблица 1.2. Сведения о типах связей

№	Тип сущности	Тип связи	Тип сущности	Кардинальность
1	Клиент	Оставляет	Заявка	M:N
2	Заявка	Передается	Мастер	M:N
3	Заявка	Относится	Район	M:1
4	Клиент	Живет	Район	M:1
5	Клиент	Имеет	Статус	M:1
6	Мастер	Выполняет	Выполненная работа	M:N
7	Мастер	Относится	Отдел	M:1
8	Заявка	Находится	Состояние заявки	M:N
9	Выполненная работа	Учитывает	Скидки	M:N
10	Выполненная работа	Входит	Акции	M:N
11	Выполненная работа	Обладает	Вид работ	M:N
12	Заявка	Включает	Выполненная работа	M:N
13	Выполненная работа	Оплачивается	Способ оплаты	M:N

3. Связь типа «много-ко-многим» означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Тип связи «много-ко-многим» является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа «один-ко-многим» путем создания промежуточной сущности.

Сведения об имеющихся типах связей для разрабатываемой базы данных представлены в таблице 1.2.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рис. 1.1 ER-модель

 

  1.3 Логическое проектирование базы данных

Цель логического проектирования – развить концептуальное представление БД с учетом принимаемой модели БД (иерархической, сетевой, реляционной и т. д.).

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

Сейчас многие реляционные СУБД позволяют декларативно задавать связи между таблицами при описании БД, а также определять необходимость контроля и способы обеспечения целостности по связям для БД. Решение этих вопросов также следует отнести к даталогическому проектированию. Другие ограничения целостности (кроме ограничения на уникальность и ограничения по связи) в данном разделе рассматриваться не будут.

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

 Атрибут – это свойство сущности в предметной области. Его наименование должно быть уникальным для конкретного типа сущности. В реляционной БД атрибуты хранятся в полях таблиц.

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

На рис. 1.2 представлена логическая схема базы данных.

Таблица 1.3 Атрибуты и домены атрибутов

№	Сущность	Атрибуты сущностей	Домены атрибутов
1	Клиент	ID_Клиента	Счетчик
		Фамилия_Имя_Отчество	Текстовый
		ID_Статус	Числовой
		Адрес_проживания	Текстовый
		ID_Района	Числовой
		Телефон	Текстовый
		E-mail	Текстовый
		Дополнительная_информация	Текстовый
2	Мастер	ID_Мастер	Числовой
		ФИО	Текстовый
		ID_Отдел	Числовой
		Ставка	Числовой
3	Выполненная  работа	ID_Выполненнаяработа	Счетчик
		ID_Мастер	Числовой
		ID_Скидки	Числовой
		ID_Акции	Числовой
		ID Способ оплаты	Числовой
		ID_Вид работ	Числовой

 

 

 

 

 

Таблица 1.3 Продолжение

№	Сущность	Атрибуты сущностей	Домены атрибутов
4	Заявка	ID_Заявки	Числовой
		ID_Клиента	Числовой
		Дата_регистрации	Дата
		ID_Района	Числовой
		ID Мастер	Числовой
		Время_выполнения	Текстовый
		ID_Состояние	Числовой
		Дата_исполнения	Дата
		Общая цена	Денежный
5	Вид работ	ID Вид работ	Счетчик
		Наименование_работ	Текстовый
		Цена	Денежный
		Комментарий	Текстовый
6	Способ оплаты	ID_Способ_оплаты	Числовой
		Название_способа	Текстовый
7	Статус	ID_Статуса	Числовой
		Наименование	Текстовый
8	Отдел	ID_Отдела	Числовой
		Адрес	Текстовый
		Название	Текстовый
9	Акции	ID_Акции	Числовой
		Наименование	Текстовый
		Условия	Текстовый
10	Район	ID_Района	Числовой
		Имя_района	Текстовый
11	Скидки	ID Скидки	Числовой
		Процент скидки	Числовой
12	Состояние заявки	ID_Состояние	Числовой
		Состояние	Текстовый
13	Промежуточная таблица	ID	Числовой
		ID_Выполненнаяработа	Числовой
		ID_Заявки	Числовой

 

 

Рис. 1.2 Логическая схема базы данных

 

 

 

  1.4 Выбор целевой СУБД и среды разработки клиентского приложения

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

 

Microsoft Access 

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

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

• таблицы – главный тип объекта, поскольку все остальные вариации объектов – это производные от таблицы. Основные составляющие таблицы – поля и записи, они определяют свойства элементов таблицы;
• формы – вспомогательные объекты, от использования которых можно отказаться. Они формируются, чтобы создать дополнительные удобства пользователю в плане просмотра, ввода и редактирования данных;
• запросы – результаты обращения пользователя к БД с целью поиска данных, удаления, добавления и обновления записей. Результаты поиска (выборки) подаются в табличном виде;
• отчеты – документы, предназначенные для вывода на печать, сформированные на информации, которая содержится в таблицах и запросах;
• схема – описание архитектуры связей многотабличной базы данных;
• макросы и модули – объекты повышенной сложности, при обыденной работе могут не использоваться.

Access, при работе с базой данных, иначе взаимодействует с жёстким (или гибким) диском, нежели другие программы.

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

Целостность данных в Access обеспечивается также за счёт механизма транзакций.