Методические рекомендации по базам данных
Оценка 4.7

Методические рекомендации по базам данных

Оценка 4.7
Раздаточные материалы
doc
информатика
Взрослым
22.03.2019
Методические рекомендации по базам данных
Данное методические пособие содержит в себе рекомендации по созданию базы данных в среде разработки ACCESS. Описаны действия при создании базы данных, связыванию таблиц, созданию экранных форм и запросов по критериям, формированию отчетов. Также описаны действия работы с интерфейсом и панелями инструментов.
Методичка_Aceess.doc
РАЗРАБОТКА БАЗЫ ДАННЫХ ДЛЯ АВТОМАТИЗИРОВАННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ «УЧЕТ ОКАЗАНИЯ УСЛУГ В ХИМЧИСТКЕ» Введение При   сильной   занятости   современного   человека   несомненным   спросом   пользуются организации, работающие в сфере услуг. Химчистка является примером такой организации. Конечно,   трудно   представить   себе   жизнь   без   функциональной   стиральной   машины,   но   в некоторых случаях справиться с чисткой вещей невозможно без помощи квалифицированных специалистов. Работникам химчистки приходится выполнять множество повторяющихся действий по оформлению   документов   при   работе   с   клиентами:   оформление   заказа   на   услуги,   расчет стоимости услуг, оформление оплаты заказов, предоставление информации об услугах и ценах на них. А поскольку подобная работа выполняется вручную, то имеет смысл выполнить их автоматизацию. Тогда сотрудники смогут без особых усилий работать с заказами, печатать квитанции,   составлять   отчетные   документы   и   т.д.   Основная   работа   будет   выполняться программой,   которая   к   тому   же   позволит   оперативно   обрабатывать   информацию. Преимуществом программы перед ручной работой является удобное представление данных, автоматическое заполнение некоторых данных, богатые возможности по обработке данных. К тому же автоматизация сервисных служб, в данном случае химчистки, повышает уровень и качество сервиса.  Подводя   итог,   можно   сказать,   что   автоматизация   работы   химчистки   в   части   учета оказания услуг является необходимым и перспективным процессом. Чтобы   разработать   полноценную   информационную   систему   следует   создать соответствующую базу данных. Структура базы данных напрямую будет зависеть от задач, которые   должна   будет   выполнять   информационная   система,   и   от   среды   разработки   этой системы. Вероятно, было бы предпочтительней разработать базу данных, не зависящую от конкретной   СУБД,   но   все­таки   среда   разработки   накладывает   свой   отпечаток,   заставляя разрабатывать   наиболее   оптимальную   и   удобную   с   точки   зрения   реализации   модель   базы данных. В дальнейшем будут указаны конкретные примеры такой зависимости. 1 1. Описание бизнес­процесса и задачи Пусть   в   некоторой   химчистке   бизнес­процесс   протекает   следующим   образом.   В химчистку обращается  клиент, желающий  отдать  вещи на обработку. При этом он может ознакомиться с прайс­листом предоставляемых видов чистки на разные категории изделий. Если клиент собирается заказать обработку вещей, то в базу данных заносится контактная информация о клиенте. Затем сотрудник оценивает перечень необходимых видов обработки для каждой вещи и приступает к оформлению заказа. В заказе указывается перечень изделий на обработку, вид обработки каждого изделия, количество   изделий   каждого   вида,   автоматически   рассчитывается   общая   длительность выполнения заказа, дата выполнения заказа, стоимость заказа, скидка клиента. Если клиент заказывает доставку обработанных изделий, то дополнительно фиксируется адрес доставки и происходит   пересчет   стоимости   услуг.   Доставка   возможна   только   в   пределах   города расположения самой химчистки и предоставляется только в том случае, если сумма заказа составляет не менее, например, 1000 руб. Пусть   требуется   разработать   информационную   систему   для   автоматизации   работы химчистки в части учета заказов. Средством разработки информационной системы выбрана среда программирования MS Vsual FoxPro 9.0 Согласно краткому описанию бизнес­процесса химчистки будущая информационная система должна обладать следующими функциями:  регистрация клиентов химчистки;  ведение каталога услуг по чистке изделий;  оформление заказов на чистку изделий;  расчет стоимости чистки изделий;  формирование квитанций к заказам;  начисление скидки;  формирование отчетов по выручке;  определение готовых и неготовых заказов;  определение выданных заказов;  определение заказов на доставку. 2 В   дальнейшем   при   разработке   базы   данных   будут   учитываться   требования   к перечисленным функциям системы, а также используемая среда разработки. Одним из отправных пунктов в разработке базы данных для будущей информационной системы может стать проектирование главного документа системы [2]. Очевидно, что таковым станет диалоговое  окно (форма), при  помощи которого и будет выполняться  оформление заказа   на   чистку   изделий.   Составляющие   этого   окна   определяются   в   соответствии   с предполагаемыми функциями будущей разработки. На рис. 1 приведен пример такого окна. Рисунок 1 – Примерный вид диалоговой формы оформления заказов 3 2. Определение сущностей и взаимосвязей между ними Анализ   бизнес–процесса   позволяет   подойти   к   построению   информационной   модели химчистки. Перечень информации, которая будет храниться в базе данных, понятен из главной формы системы (рис. 1). На первом этапе уже возможно определить некоторое начальное количество   сущностей,   которые   будут   содержать   эту   информацию   в   качестве   своих атрибутов.   Сущности   и   связи   между   ними   изображается   в   виде   диаграммы,   которая представлена на рис. 2. Рисунок 2 – Диаграмма «сущность ­ связь» В данной диаграмме используются следующие связи:  между сущностями «Изделие» и «Заказ» установлена связь «многие­ко­ многим», поскольку один вид изделия может быть указан в нескольких заказах, а в одном заказе может быть указано несколько видов изделий;  между   сущностями   «Клиент»   и   «Заказ»   установлена   связь   «один­ко­ многим»,   поскольку   один   клиент   может   быть   указан   в   нескольких заказах, но в одном заказе может быть указан только один клиент;  между   сущностями   «Вид_обработки»   и   «Заказ»   установлена   связь «многие­ко­многим», поскольку один вид обработки может быть указан в нескольких заказах для нескольких изделий, а в одном заказе для одного изделия может быть указано несколько видов обработки. При   определении   типов   связей   между   сущностями   следует   обратить   внимание   на сущность «Вид_обработки». Конечно, по смыслу хочется установить связь этой сущности и сущности «Изделие», но, во­первых, разные изделия могут подвергаться одинаковым видам обработки, и тогда возникает необходимость несколько раз вносить в базу данных один и тот же вид, а это влечет избыточность данных и увеличение используемой памяти; во­вторых, установление   связи   между   сущностями   «Вид_обработки»   и   «Заказ»   позволит   облегчить 4 реализацию в системе MS Visual FoxPro 9.0. Итак, на основе диаграммы взаимосвязей между сущностями (рис. 2) будет разработана модель   базы   данных,   доведенная   до   третьей   нормальной   формы.   Понятие   нормализации применимо только к реляционным базам данных, поэтому следует преобразовать исходную модель, так как в реляционной базе данных не должны присутствовать связи «многие­ко­ многим». Для этого следует добавить еще одну сущность, получив эквивалентный вариант диаграммы,   представленный   на   рис.   3.   Стоит   обратить   внимание,   что   в   диаграмме присутствовало две связи «многие­ко­многим», но сущность будет добавлена только одна, т.к. обе связи используют одну сущность «Заказ» (это один из плюсов использования связи Заказ­ Вид_обработки вместо Изделие­Вид_обработки). Рисунок 3 –  Эквивалентный вариант диаграммы «сущность­связь» 5 3. Задание первичных ключей, определение атрибутов сущностей Для каждой сущности определяются атрибуты, которые будут храниться в базе данных. Результат представлен в таблице 1. Таблица 1 Атрибуты и первичные ключи сущностей информационной модели Сущность Первичный ключ Атрибуты Заказ код_заказа Состав_заказа Клиент Изделие код_клиента код_изделия, код_категории Вид_обработки код_вида код_заказа код_клиента дата_составления общ_длительность дата_исполнения сумма_заказа скидка сумма_со_скидкой готовность выдача код_заказа код_изделия код_вида кол­во сумма_за_позицию код_клиента ФИО_клиента тел_клиента адрес_клиента код_изделия наименование цена длительность код_категории категория код_вида вид_обработки коэффициент_обр Следует   обратить   внимание   на   то,   что   в   сущности   «Вид_обработки»   присутствует атрибут «коэффициент_обр». Какого его назначение? Дело в том, что цена обработки одного и   того   же   изделия   может   быть   разной   в   зависимости   от   того,   какой   вид   чистки   к   нему применяется (деликатная стирка, выведение пятен, обычная стирка и т.д.). Естественно, нецелесообразно хранить в базе данных полный перечень цен на каждый вид обработки каждого изделия,  поэтому можно по каждому изделию  хранить некоторую базовую цену, которая будет меняться в зависимости от вида обработки путем ее умножения на   коэффициент   обработки.   Вообще   говоря,   такой   прием   помножающих   коэффициентов 6 эффективен во многих подобных случаях. 4. Приведение модели базы данных к первой нормальной форме Отношение   находится   в   первой   нормальной   форме,   если   для   каждой   сущности выполняются условия:  должны отсутствовать повторяющиеся записи;  должны отсутствовать повторяющиеся атрибуты;  каждый атрибут должен быть неделим. Согласно требованиям первой нормальной формы необходимо преобразовать атрибуты «ФИО_клиента» и «адрес_клиента» в сущности «Клиент» так, чтобы получить неделимые атрибуты. Результат преобразования представлен в таблице 2. Таблица 2 Атрибуты и первичные ключи сущностей в первой нормальной форме Сущность Первичный ключ Атрибуты Заказ код_заказа Состав_заказа Изделие код_изделия, код_категории Клиент код_клиента код_заказа код_клиента дата_составления общ_длительность дата_исполнения сумма_заказа скидка сумма_со_скидкой готовность выдача код_заказа код_изделия код_вида кол­во сумма_за_позицию код_изделия наименование цена длительность код_категории кол­во_в_категории категория код_клиента фам_клиента имя_клиента отч_клиента тел_клиента улица_клиента дом_клиента корпус_клиента 7 Вид обработки код_вида кварт_клиента код_вида вид_обработки коэффициент_обр Диаграмма взаимосвязей между атрибутами сущностей в первой нормальной форме представлена на рис. 4. Рисунок 4 – Диаграмма взаимосвязей между атрибутами сущностей в первой нормальной форме 5. Приведение модели базы данных ко второй нормальной форме Отношение   находится   во   второй   нормальной   форме,   если   оно   удовлетворяет следующим требованиям:  выполняются условия первой нормальной формы;  первичный ключ однозначно определяет запись;  все поля записи функционально полно зависят от первичного ключа. В сущности «Изделие» атрибуты «категория», «кол­во_в_категории» зависят только от 8 части   «код_категории»   составного   первичного   ключа.   Поэтому   отношение   «Изделие»   не находится   во   второй   нормальной   форме   и   его   следует   преобразовать,   выделив   из   него отдельную сущность «Категория». Результат преобразования представлен в таблице 3. 9 Атрибуты и первичные ключи сущностей во второй нормальной форме Сущность Первичный ключ Атрибуты Таблица 3 Заказ код_заказа Состав_заказа Изделие код_изделия Клиент код_клиента Вид обработки код_вида Категория код_категории код_заказа код_клиента дата_составления общ_длительность дата_исполнения сумма_заказа скидка сумма_со_скидкой готовность выдача код_заказа код_изделия код_вида кол­во сумма_за_позицию код_изделия наименование цена длительность код_категории код_клиента фам_клиента имя_клиента отч_клиента тел_клиента улица_клиента дом_клиента корпус_клиента кварт_клиента код_вида вид_обработки коэффициент_обр код_категории категория кол­во_в_категории 10 Диаграмма взаимосвязей между атрибутами сущностей во второй нормальной форме представлена на рис. 5. Рисунок 5 – Диаграмма взаимосвязей между атрибутами сущностей во второй нормальной форме 6. Приведение модели базы данных к третьей нормальной форме Условия третьей нормальной формы:  должны выполняться условия второй нормальной формы;  внутри   каждой   сущности   должны   отсутствовать   транзитивные зависимости. В сущности «Состав_заказа» атрибут «сумма_за_позицию» зависит от атрибута «кол­ во» этой  же  сущности.  Поэтому  данный   атрибут следует  удалить   из  сущности,  создав  на соответствующей форме поле, вычисляемое по формуле: Сумма_за_позицию =цена*коэффициент_обр*кол­во, (1) где: «коэффициент_обр» – поле из сущности «Вид обработки», «цена» – поле из сущности «Изделие». 11 В   сущности   «Заказ»   атрибут   «дата_исполнения»   зависит   от   атрибута «дата_составления»   этой   же   сущности.   Поэтому   данный   атрибут   следует   удалить   из сущности, создав на соответствующей форме поле, вычисляемое по формуле: Дата_исполнения =дата_составления+общ_длительность, (2) где: «общ_длительность» – поле из сущности «Заказ». В сущности «Заказ» атрибут «сумма_со_скидкой» зависит от атрибута «сумма_заказа» этой   же   сущности.   Поэтому   данный   атрибут   следует   удалить   из   сущности,   создав   на соответствующей форме поле, вычисляемое по формуле: скидка = F(сумма_заказа), (3) где: F – правило расчета скидки, оно не описывается в явном виде, поскольку может быть любым и не является принципиально важным в контексте данной статьи. В сущности «Заказ» атрибут «скидка» зависит от атрибута «сумма_заказа» этой же сущности.   Поэтому   удалим   данный   атрибут   следует   удалить   из   сущности,   создав   на соответствующей форме поле, вычисляемое по формуле: Сумма_со_скидкой =сумма_заказа – скидка, где: «скидка» – поле из сущности «Заказ». Результат преобразований приведен в таблице 4. (4) Таблица 4 Атрибуты и первичные ключи сущностей в третьей нормальной форме Сущность Первичный ключ Атрибуты Заказ код_заказа Состав_заказа Изделие код_изделия код_заказа код_клиента дата_составления общ_длительность сумма_заказа готовность выдача код_заказа код_изделия код_вида кол­во код_изделия наименование цена длительность 12 Вид обработки код_вида Клиент код_клиента Категория код_категории код_категории код_вида вид_обработки коэффициент_обр код_клиента фам_клиента имя_клиента отч_клиента тел_клиента улица_клиента дом_клиента корпус_клиента кварт_клиента код_категории категория кол­во_в_категории Диаграмма взаимосвязей между атрибутами сущностей в третьей нормальной форме представлена на рис. 5. Рисунок 5 – Диаграмма взаимосвязей между атрибутами сущностей в третьей нормальной форме 13 7. Физическое описание модели базы данных Для   реализации   автоматизированной   системы   учета   оказания   услуг   в   химчистке следует   разработать   базу   данных,   состоящую   из   6   таблиц.   Структура   каждой   таблицы приведена ниже. Таблица 5 – Таблица «Изделие» (izdelie.dbf) Имя поля kod_izd kod_kat cena dlit naim Тип поля Integer(AutoInc) Integer Numeric Numeric Character Размер поля 4 4 10(2) 4(1) 30 Содержание код_изделия код_категории  цена_за_обработку длительность_обработки наименование Таблица 6 – Таблица «Вид обработки» (vid_obrabot.dbf) Имя поля kod_vid vid koeffic Тип поля Integer(AutoInc) Character Numeric Размер поля 4 30 4(2) Содержание код_вида вид_обработки коэффициент_обработк и Таблица 7 – Таблица «Cостав_заказа» (sostav.dbf) Имя поля kod_zakaz kod_izd kod_vid kol Тип поля Integer Integer Integer Integer Размер поля 4 4 4 4 Содержание код_заказа код_изделия код_вида_обработки количество_изделий Таблица 8 – Таблица «Заказ» (zakaz.dbf) Имя поля кod_zakaz kod_kl data_sost o_dlit summa gotov vadacha Тип поля Integer(AutoInc) Integer Date Integer Numeric Logical Logical Размер поля 4 4 8 4 10(2) 1 1 Содержание код_заказа код_клиента дата_составления общая_длительность сумма_заказа готовность выдача 14 Таблица 9 – Таблица «Клиент» (klient.dbf) Имя поля kod_kl fam_kl im_kl ot_kl tel_kl ul_kl d_kl k_kl kv_kl Тип поля Integer(AutoInc) Character Character Character Character Character Character Character Character Размер поля 4 25 25 25 13 25 3 3 3 Содержание код_клиента фам_клиента имя_клиента отч_клиента тел_клиента улица_клиента дом_клиента корпус_клиента кварт_клиента Таблица 10 – Таблица «Категория» (kategor.dbf) Имя поля kod_kat kategor kol_iz Тип поля Integer(AutoInc) Character Integer Размер поля 4 50 4 Содержание код_категории категория кол­во_в_категории 15

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

Методические рекомендации по базам данных

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