Проектирование информационной системы учета продаж Компания "Max-Service"

3. Даталогическое моделирование

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

 

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

В соответствии с построенной инфологической моделью предметной области, были выделены следующие сущности (объекты):

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

2. Фирма – данный объект содержит  основные сведения о фирмах-производителях мобильных телефонов.

3. Телефоны_товар – является  подчинённым по отношению к  объекту Модель_телефона и содержит  сведения об отдельных экземплярах  этого объекта, включая IMEI, состояние  телефона, статус (новый или б/у).

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

5. Телефоны_клиентов. В общем случае  каждый клиент может иметь  несколько телефонов, которые он мог приобрести как непосредственно в магазине «Vid Service», так и у других продавцов. При этом телефоны клиента могут находиться в разном состоянии – быть исправными или неисправными и т. д.

6. Заявки_клиентов. Клиент, обратившийся  в магазин «Vid Service», может заказать модель, которая как присутствует, так и отсутствует на складе. В последнем случае срок выполнения заказа может увеличиться до трёх-четырёх недель, и каждую такую заявку необходимо отслеживать.

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

8. Ремонтные_работы. В общем случае ремонт может оказаться сложным, требующим, например, программирования, замены корпусных деталей и т.п. Изо всего этого складывается конечная стоимость произведённых работ.

9. Запчасти_ремонт. Если в ходе проведения ремонта  потребовалась замена запчастей, это обязательно учитывается в конечной стоимости ремонта. При этом нужные запчасти могут как иметься в наличии на складе, так и отсутствовать.

10. Виды_ремонтных_работ.  На каждый вид работы существует  прейскурант, в котором заложена  базовая цена ремонта.

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

12. Запчасти –  данный объект содержит сведения  об имеющихся на складе запчастях,  включая информацию о взаимозаменяемости  запчастей разных моделей телефонов от одного производителя.

13. Сотрудники. Необходим  для того, чтобы учесть вклад  каждого сотрудника в общую  работу магазина «Vid Service».

14. Статус_клиента  – подстановочный объект, необходимый  для идентификации клиента в  плане возможности получения им скидки и т.п.

15. Тех_состояние  – оценка технического состояния  телефона (исправен-неисправен, пригоден  для ремонта, подлежит разбору  на запчасти и т.п.).

3.2. Физическая модель данных

 

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

В бланках описания таблиц в столбце Индекс используются следующие обозначения:

• PRI – первичный индекс, соответствующий ключевому полю таблицы. В каждой таблице только один первичный индекс;
• FOR – внешний индекс, создаваемый для поля, участвующего в связи с другой таблицей;
• REG – регулярный индекс, создаваемый для полей, часто участвующих в запросах к базе данных, для ускорения процесса поиска и обработки информации.

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

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

Таким образом, была составлена даталогическая модель, реализованная в СУБД MS Access, представленная на рис. 5.

Рис. 5. Схема данных, реализованная в СУБД Access.

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

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

В СУБД Access данные хранятся в таблицах. Каждая таблица состоит из схемы таблицы (названия полей, типы данных, размеры, ограничения, индексы) и собственно записей, содержащих информацию.

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

В бланках описания таблиц в столбце  Индекс используются следующие обозначения:

PRI – первичный индекс, соответствующий ключевому полю таблицы. В каждой таблице только один первичный индекс;

FOR – внешний индекс, создаваемый  для поля, участвующего в связи  с другой таблицей;

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

Таблица 1.

Описание таблицы «Телефоны_клиентов»

Имя объекта:   Телефоны_клиентов
Краткое описание: В таблицу заносятся  сведения о телефонах.
Связанные объекты:	Модель_телефона	Связь:	М:1
	Статус_клиента		М:1
	Тех_состояние		М:1
	Клиенты		М:1
Имя	Тип	Размер	Индекс
IMEI	Текстовый	50
модель	Длинное целое	4	FOR
дата_начала	Дата/время	8
дата_окончания	Дата/время	8
код_статуса	Длинное целое	4	FOR
код_состояния	Длинное целое	4	FOR
код_клиента	Длинное целое	4	FOR
аппарат	Логический	1
аккумулятор	Логический	1
задняя_крышка	Логический	1
зарядное_устройство	Логический	1
гарнитура	Логический	1
гарант_талон_№	Текстовый	50
дата_выдачи	Дата/время	8
код_телефона	Длинное целое	4	PRI

 

Полное описание всех объектов приведено  в приложении Б.

 

4. Разработка программного обеспечения

4.1. Структура программных средств

 

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

Рис. 12 - Общая структура программных средств

На рисунке сплошными линиями  показаны структурные связи, штриховыми – вызов одних элементов приложения из других.

Кнопочная форма содержит объединяющие последовательности команд и запросов для выполнения задач приложения.

Таблицы – это место хранения взаимосвязанных данных в реляционных  СУБД. Экраны – специфическое представление  таблиц, когда показаны не все записи или поля таблицы, а только те, которые нужны в данный момент для решения конкретной задачи. Полное описание таблиц приведено в приложении А.

В категории Отчеты представлены выходные отчеты, формируемые системой.

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

Инструкции на выборку данных

SELECT [ALL | DISTINCT |DISTINCTROW | TOP ]

{ * | таблица.* | [таблица.]поле_1 [AS псевдоним_1] [, [таблица.]поле_2 [AS псевдоним_2] [, ...]]}

FROM выражение [, ...] [IN внешняяБазаДанных]

[WHERE условие отбора ]

[GROUP BY условие группировки ] (до 10 полей)

[HAVING условие отбора сгруппированных  полей ]

[ORDER BY поле 1[ASC|DEC], … ] (сортировка)

[WITH OWNERACCESS OPTION] (пользователю предоставляются  права владельца)

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

DISTINCT	Исключает записи, которые содержат повторяющиеся значения в выбранных  полях. Чтобы запись была включена в  результат выполнения запроса, значения в каждом поле, включенном в инструкцию SELECT, должны быть уникальными.
DISTINCTROW	Опускает данные, основанные на целиком  повторяющихся записях, а не отдельных  повторяющихся полях.
TOP n [PERCENT]	Возвращает определенное число  записей, находящихся в начале или в конце диапазона, описанного с помощью предложения ORDER BY.

 

В предложении WHERE может размещаться  вложенный запрос:

WHERE поле1, поле2, … IN (запрос).

Также, в этом предложении могут  быть размещены кванторы существования (EXIST, NOT EXIST). Они всегда размещаются перед вложенным запросом.

В предложении FROM могут быть представлены результаты выполнения операций над  другими таблицами:

FROM таблица_1 [INNER | RIGHT | LEFT JOIN таблица_2 ON таблица_1.поле_1 оператор таблица_2.поле_2]

В качестве оператора — любой  оператор сравнения.

Операция INNER JOIN объединяет записи из двух таблиц, если связующие поля этих таблиц содержат одинаковые значения.

Инструкции, которые изменяют данные:

Инструкция SELECT...INTO — создаёт новую таблицу. SELECT поле_1[, поле_2[, ...]] INTO новая Таблица [IN внешняяБазаДанных] FROM источник;

Инструкция DELETE создает запрос на удаление записей, предназначенный  для удаления записей из одной  или нескольких таблиц, перечисленных  в предложении FROM, которые удовлетворяют предложению WHERE. DELETE [таблица.*] FROM таблица  WHERE условиеОтбора;

Инструкция INSERT INTO добавляет запись или записи в таблицу. INSERT INTO назначение [(поле_1[, поле_2[, ...]])] [IN внешняяБазаДанных]  
SELECT [источник.]поле_1[, поле_2[, ...]     FROM выражение;

Инструкция UPDATE создает запрос на обновление, который изменяет значения полей указанной таблицы на основе заданного условия отбора. UPDATE таблица      SET имя поля = новое Значение     WHERE условие Отбора.

Инструкции, изменяющие структуру данных

Инструкция CREATE TABLE используется для  описания новой таблицы, ее полей  и индексов. Если для поля добавлено  ограничение NOT NULL, то при добавлении новых записей это поле должно содержать допустимые данные.

CREATE [TEMPORARY] TABLE таблица (поле_1 тип [(размер)] [NOT NULL] [WITH COMPRESSION | WITH COMP] [индекс_1] [, поле_2 тип [(размер)] [NOT NULL] [индекс_2] [, ...]] [, CONSTRAINT составнойИндекс [, ...]])

Создаваемая временная (TEMPORARY) таблица  будет доступна только в том сеансе, где эта таблица была создана. По завершении данного сеанса она автоматически удаляется. Временные таблицы могут быть доступны для нескольких пользователей. Использование атрибута WITH COMPRESSION допускается только для типов данных CHARACTER и MEMO (он же TEXT) и их синонимов (переход к формату Юникод).

Модификация существующей таблицы, добавление или удаление поля или индекса, изменение  типа и размера полей.

ALTER TABLE таблица {ADD {COLUMN тип поля[(размер)] [NOT NULL]

[CONSTRAINT индекс] |     ALTER COLUMN тип поля[(размер)] | CONSTRAINT составнойИндекс} |     DROP {COLUMN поле I

CONSTRAINT имяИндекса} }