ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 08.11.2023
Просмотров: 25
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Федеральное агентство по образованию
Государственное образовательное учреждение
высшего профессионального образования
«УДМУРТСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»
Факультет информационных технологий и вычислительной техники
ОТЧЁТ
по преддипломной практике
Работу выполнил:
студент М.В. Пашин
ФИТиВТ, гр.ВЗ-351400-34 (к)
Проверил:
старший преподаватель кафедры ТОИ
Д.А.Дунаев
Ижевск 2013
СОДЕРЖАНИЕ
ВВЕДЕНИЕ 3
I. ПОСТАНОВКА ЗАДАЧИ 5
1.1. Краткая характеристика предметной области -
1.2. Разработка структуры БД 6
1.3. Инфологическое проектирование 7
1.4. Структура и создание таблиц 8
1.5. Реляционная схема базы данных 10
II. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ 13
2.1. Описание бизнес-процесса -
2.2. Моделирование БД 15
2.3. Заполнение базы данных 16
2.4. Запросы 22
2.5. Отчёты -
ЗАКЛЮЧЕНИЕ 24
ЛИТЕРАТУРА
ПРИЛОЖЕНИЯ
ВВЕДЕНИЕ
Жизнь современного предприятия немыслима без эффективного системного анализа и обработки его информационного потенциала. Важной категорией являются системы обработки информации, от которых во многом зависит эффективность работы любого предприятия или учреждения. Такая система должна:
-
обеспечивать получение общих и/или детализированных отчетов по итогам работы; -
позволять легко определять тенденции изменения важнейших показателей; -
обеспечивать получение информации, критической по времени, без существенных задержек; -
выполнять точный и полный анализ данных.
Среди наиболее ярких представителей систем управления базами данных можно отметить: LotusApproach, MicrosoftAccess, BorlanddBase,BorlandParadox, MicrosoftVisualFoxPro, MicrosoftVisualBasic, а также баз данных MicrosoftSQLServer и Oracle, используемые в приложениях, построенных по технологии «клиент-сервер».
Фактически, у любой современной СУБД существует аналог, выпускаемый другой компанией, имеющий аналогичную область применения и возможности, любое приложение способно работать со многими форматами представления данных, осуществлять экспорт и импорт данных благодаря наличию большого числа конвертеров. Общепринятыми, также, являются технологи, позволяющие использовать возможности других приложений, например, текстовых процессоров, пакетов построения графиков и т.п., и встроенные версии языков высокого уровня (чаще – диалекты SQL и/или VBA) и средства визуального программирования интерфейсов разрабатываемых приложений.
Поэтому уже не имеет существенного значения, на каком языке и на основе какого пакета написано конкретное приложение, и какой формат данных в нем используется.
Более того, стандартом «де-факто» стала «быстрая разработка приложений» или RAD (от английского RapidApplicationDevelopment), основанная на широко декларируемом в литературе «открытом подходе», то есть необходимости и возможности использования различных прикладных программ и технологий для разработки более гибких и мощных систем обработки данных.
Поэтому в одном ряду с «классическими» СУБД упоминаются языки программирования VisualBasic 4.0 и VisualC++, которые позволяют быстро создавать необходимые компоненты приложений, критичные по скорости работы, которые иногда трудно разработать средствами «классических» СУБД. Современный подход к управлению базами данных подразумевает также широкое использование технологии «клиент-сервер».
Таким образом, на сегодняшний день разработчик не связан рамками какого-либо конкретного пакета, а в зависимости от поставленной задачи может использовать самые разные приложения. Поэтому, более важным представляется общее направление развития СУБД и других средств разработки приложений в настоящее время.
I. ПОСТАНОВКА ЗАДАЧИ
1.1. КРАТКАЯ ХАРАКТЕРИСТИКА ПРЕДМЕТНОЙ ОБЛАСТИ
Целью данного проекта является разработка информационной системы салона корпусной мебели. Данная система представляет собой базу данных, содержащую информацию о следующем:
-
ассортимент продукции магазина; -
предприятия-поставщики; -
персонал; -
график поставок; -
клиентура; -
заказы клиентов.
Представленная база данных решает следующие задачи: учёт товара, выдача данных о поставщиках и поставляемых ими товарах (фирма-поставщик, его реквизиты, наименование товаров, описание, цены), вычисление суммы оплаты. В режиме формы вычисляет стоимость товара с наценкой магазина в 50%. Реализует запросы упорядочения по полям: товары, поставщики, цена. Осуществляет поиск сведений о фирме-поставщике какого-то товара. Производит подсчет стоимости и количества оставшегося в магазине товара, а также выдает отчет об отсутствующих товарах.
Применяемая СУБД: АССЕSS 2003.
Исходные данные о магазине: магазин располагается в нескольких помещениях (склад, торговый зал). У фирмы есть поставщики, осуществляющие поставку изделий мебели (в разобранном и готовом виде) на склад магазина.
Так же в магазине есть свой штат сотрудников: менеджеры и консультанты, осуществляющие продажу товара, бухгалтер, кладовщики, водители, грузчики-сборщики.
Клиент, приходя в магазин, взаимодействует с менеджером, который, в свою очередь, осуществляет продажу изделий. Операции с денежными средствами и отбивку чека осуществляет так же менеджер. При покупке товара, клиент получает чек с указанием товара и его стоимости, на основании которого со склада ему отгружают необходимый товар.
При отсутствии товара на складе работник магазина выбирает отсутствующие товары и на основании этих данных составляет заявку на имя фирмы-поставщика.
1.2. РАЗРАБОТКА СТРУКТУРЫ БД
Удачная разработка базы данных обеспечивает простоту ее поддержания. Данные следует сохранять в таблицах, причем каждая таблица должна содержать информацию одного типа, например, сведения о поставщиках. Тогда достаточно будет обновить конкретные данные, такие как адрес, только в одном месте, чтобы обновленная информация отображалась во всей базе данных.
Одним из наиболее сложных этапов в процессе проектирования базы данных является разработка таблиц, так как результаты, которые должна выдавать база данных (отчеты, выходные формы и др.) не всегда дают полное представление о структуре таблицы. При проектировке таблиц рекомендуется руководствоваться следующими основными принципами:
1. Не должно быть повторений между таблицами. Когда определенная информация хранится только в одной таблице, то и изменять ее придется только в одном месте. Это делает работу более эффективной, а также исключает возможность несовпадения информации в разных таблицах. Например, в одной таблице должны содержаться адреса и фамилии клиентов.
2. Каждая таблица должна содержать информацию только на одну тему. Сведения на каждую тему обрабатываются намного легче, если содержаться они в независимых друг от друга таблицах. Например, адреса и заказы клиентов хранятся в разных таблицах, с тем, чтобы при удалении заказа информация о клиенте осталась в базе данных.
3. Каждое поле должно быть связано с темой таблицы.
4. Не рекомендуется включать в таблицу данные, которые являются результатом выражения.
5. В таблице должна присутствовать вся необходимая информация.
6. Информацию следует разбивать на наименьшие логические единицы. Например, поля «Имя» и «Фамилия», а не общее поле «Имя».
1.3. ИНФОЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ
Первым этапом и самым главным этапом в процессе проектирования и создания базы данных, является разработка инфологической модели.
Цель инфологического моделирования – обеспечение наиболее естественных для человека
способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).
Ключ – минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся.
Связь – ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных – это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи.
Между двумя сущностям, например, А и В возможны четыре вида связей.
Первый тип – связь “один-к-одному” (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В:
Студент может не "заработать" стипендию, получить обычную или одну из повышенных стипендий.
Второй тип – связь “один-ко-многим” (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.
Квартира может пустовать, в ней может жить один или несколько жильцов.
Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи “многие-к-одному” (М:1) и “многие-ко-многим” (М:N).
1.4. СТРУКТУРА И СОЗДАНИЕ ТАБЛИЦ
В таблицах данные распределяются по столбцам (которые называют полями) и строкам (которые называют записями). Все данные, содержащиеся в поле таблицы, должны иметь один и тот же тип. Основные типы данных:
-
Текстовый. Текст или числа, нетребующие проведения расчётов. -
МЕМО. Поле этого типа предназначено для хранения небольших текстовых данных (до 64000 символов). Поле этого типа не может быть ключевым или проиндексированным. -
Числовой. Этот тип данных содержит множество подтипов. От выбора подтипа (размера) зависит точность вычислений. -
Счётчик. Уникальные, последовательно возрастающие числа, автоматически вводящиеся при добавлении новой записи в таблицу. -
Логический. Логические значения, а так же поля, которые могут содержать одно из двух возможных значений. -
Денежный. Денежные значения и числовые данные, используемые в математических вычислениях. -
Дата/Время. Дата и время хранятся в специальном фиксированном формате. -
Поле объекта OLE. Включает звукозапись, рисунок и прочие типы данных. Поле этого типа не может быть ключевым или проиндексированным. -
Гиперсвязь. Содержит адреса Web-страниц.
В проектируемой базе данных будут присутствовать следующие типы (Рис.1):
Рис.1. Типы данных.
1.5. РЕЛЯЦИОННАЯ СХЕМА БАЗЫ ДАННЫХ
Реляционная база данных – это совокупность отношений, содержащих всю информацию, которая должна храниться в БД. Однако пользователи могут воспринимать такую базу данных как совокупность таблиц.
1. Каждая таблица состоит из однотипных строк и имеет уникальное имя.
2. Строки имеют фиксированное число полей (столбцов) и значений (множественные поля и повторяющиеся группы недопустимы).
3. Строки таблицы обязательно отличаются друг от друга хотя бы единственным значением, что позволяет однозначно идентифицировать любую строку такой таблицы.
4. Столбцам таблицы однозначно присваиваются имена, и в каждом из них размещаются однородные значения данных (даты, фамилии, целые числа или денежные суммы).
5. Полное информационное содержание базы данных представляется в виде явных значений данных, и такой метод представления является единственным. В частности, не существует каких-либо специальных "связей" или указателей, соединяющих одну таблицу с другой.
6. При выполнении операций с таблицей ее строки и столбцы можно обрабатывать в любом порядке безотносительно к их информационному содержанию.
Совокупность таблиц и связей между ними представлена следующим образом (Рис 2).
Рис.2. Реляционная схема базы данных
II. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ
2.1. ОПИСАНИЕ БИЗНЕС-ПРОЦЕССА
Представленные ниже IDEF0-диаграммы кратко отражают суть функционирования данного магазина.
IDEF0 – методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временна́я последовательность (WorkFlow).
Стандарт IDEF0 представляет организацию как набор модулей, здесь существует правило — наиболее важная функция находится в верхнем левом углу, кроме того есть правило стороны : — стрелка входа приходит всегда в левую кромку активности, — стрелка управления — в верхнюю кромку, — стрелка механизма — нижняя кромка, — стрелка выхода — правая кромка.