MPLS сеть на базе технологии WiMAX

ОБРАЗОВАТЕЛЬНАЯ АВТОНОМНАЯ НЕКОММЕРЧЕСКАЯ ОРГАНИЗАЦИЯ ВЫСШЕГО  ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«ВОЛЖСКИЙ УНИВЕРСИТЕТ  ИМ. В.Н. ТАТИЩЕВА» 

(ИНСТИТУТ)

Кафедра «Информатика и системы управления»

 

 

 

 

 

 

 

ДИПЛОМНЫЙ ПРОЕКТ

по специальности 230101.65

«Вычислительные машины, комплексы, системы и сети»

на тему

«MPLS сеть на базе технологии WiMAX»

 

 

 

 

Студент группы ИС-504

_________________ Д.М. Щепетков

Руководитель дипломного проекта

к.т.н., доцент, профессор  кафедры ПИ

_________________ Н.О. Куралесова

 

 

 

 

 

 

г.о. Тольятти 2011 г.

 

 

 

 

Содержание

 

Введение           3

Постановка  задачи         4

Задание          4

Назначение  БД          5

Выполняемые функции        5

Категории пользователей       6

Обоснование Выбора СУБД      6

Проектирование  БД         7

 Инфологическое  проектирование     7

Сущности          8

Взаимосвязи сущности       9

Разработка  Концептуальной инфологической модели  9

Даталогическое  проектирование      10

Отношения и  атрибуты       12

Ключевые поля и индексы       17

Нормализация  отношений       19

Схема данных         21

Особенности реализации        22

Учет специфики  предметной области     22

Разработанные алгоритмы       22

Пользовательский  интерфейс       25

Запросы          25

Форма          35

Отчеты          43

Заключение          46

Литература          47

 

Введение

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

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

Современные СУБД в основном являются приложениями Windows, так как данная среда позволяет более полно использовать возможности персональной ЭВМ, нежели среда DOS. Снижение стоимости высокопроизводительных ПК обусловил не только широкий переход к среде Windows, где разработчик программного обеспечения может в меньше степени заботиться о распределении ресурсов, но также сделал программное обеспечение ПК в целом и СУБД в частности менее критичными к аппаратным ресурсам ЭВМ.

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

 

1. Постановка задачи

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

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

Хранение большого объема информации, выборка необходимой информации по заданным критериям, для дальнейшего  его использования в принятии решений.

1. Задание

В данном курсовом проекте поставлена задача создания экономической информационной системы ресторанного предприятия.

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

«Зал обслуживания» предназначена  непосредственно для приёма посетителей, предоставляя им места (столики), где они могут воспользоваться основными услугами ресторана.

«Комната для персонала» предназначена, в предоставлении необходимых нужд штатным сотрудникам. всем необходимым.

Предприятие имеет штат сотрудников, занимающие различные должности: например, официант, менеджер, повар и управляющий.

Официант работает в «Зале обслуживания», обслуживает клиентов, принимает заказы от клиента и вносит их в базу, следит за выполнением заказа до его погашения, а именно оплаты клиента за услугу.

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

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

2. Назначение БД

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

Выполняемые функции

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

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

 

 

Категории пользователей

 

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

Сотрудники: Официант, Менеджер, Повар.

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

Менеджеры выполняет функции снабжения ресторана продукцией необходимой для приготовления блюд и необходимым инвентарем для нормальной работы ресторана. Интерфейсом для менеджера будет служить формы «Справочник Поставщиков» и «Поставка».

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

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

 

Обоснование Выбора СУБД

 

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

В Microsoft Access для обработки  данных базовых таблиц используется мощный язык SQL (структурированный язык запросов). Используя SQL  можно выделить из одной или нескольких таблиц необходимую для решения конкретной задачи информацию. Access значительно упрощает задачу обработки данных. Совсем не обязательно знать язык SQL. При любой обработке данных из нескольких таблиц Access использует однажды заданные связи между таблицами.

 

2. Проектирование БД

1.  Инфологическое проектирование

Цель инфологического  этапа проектирования состоит в  получении семантических (концептуальных) моделей, отражающих предметную область  и информационные потребности пользователей. В качестве инструмента для построения семантических моделей данных на этапе инфологического проектирования является неформальная модель "Сущность-Связь" (ER-модель - Entity-Relationship). Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов.

Сущность (объект) - это  реальный или представляемый объект предметной области, информация о котором  должна сохраняться и быть доступна. Различают такие понятия, как  тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных предметов, событий, личностей, выступающих как единое целое. Экземпляр сущности относится к конкретной вещи в наборе.

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

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

Среди бинарных связей существуют три фундаментальных вида связи: один-к-одному (1:1), один-ко-многим (1:M), многие-ко-многим (M:M). Связь один-к-одному (1:1) существует, когда один экземпляр одной сущности связан с единственным экземпляром другой сущности. Связь один-ко-многим (1:M) имеет место, когда один экземпляр одной сущности связан с одним или более экземпляром другой сущности и каждый экземпляр второй сущности связан только с одним экземпляром первой сущности. Связь многие-ко-многим (М:N) существует, когда один экземпляр одной сущности связан с одним или более экземпляром другой сущности и каждый экземпляр второй сущности связан с одним или более экземпляром первой сущности.

 

Сущности

 

Определим сущности:

1. Заказ;
2. Сотрудники (управляющий и обслуживающий составы);
3. Поставка;
4. Блюдо;
5. Организация, поставляющая продукцию;
6. Столик;
7. Акт Списания

 

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

 

 

1. Заказ:

- Номер заказа;

- Дата заказа;

- Номер столика;

- Сотрудник;

- Оплата заказа;

- Заказываемые блюда;

 

2.  Сотрудники:

- Код Сотрудника;

- Имя;

- Фамилия;

- Отчество;

- Должность;

- Адрес;

- Телефон;

- Дата приема на работу;

 

3. Блюдо:

- Код Блюда;

- Категория;

- Наименование блюда;

- Размер порции блюда;

- Цена за порцию;

- Описание блюда;

 

4. Организация, поставляющая продукцию:

- Код Организации;

- Название организации;

- Контактное лицо;

- Контактный телефон;

- Адрес организации;

 

5. Поставка

- Номер Поставки;

- Поставщик;

- Дата поставки;

- Приемщик;

- Товар;

- Тип Продукта;

- Кол-во Продукта;

- Единица измерения;

- Цена за единицу;

 

6. Столик:

- Номер столика;

- Количество мест;

 

 

7. Акт Списания;

- Номер Акта

- Сотрудник;

- Дата Списания;

- Товар;

- Тип Продукта;

- Кол-во Продукта;

- Единица измерения;

 

2. Взаимосвязи сущности

Связи между сущностями представлены в таблице 2.1.

Таблица 2.1 – Взаимосвязи сущностей

Сущность 1	Сущность 2	Связь	Описание
Сотрудник	Поставка	1 - N	Один сотрудник может  принять несколько поставок. Одна любая поставка может иметь только одного приемщика.
Сотрудник	Заказ	1 - N	Один сотрудник может  принять несколько заказов. Один любой заказ может иметь только одного сотрудника
Организация	Поставка	1 - N	Одна организация может  произвести несколько поставок. Одну поставку может поставить только одна организация.
Блюдо	Заказ	1 - N	Одно Блюдо может  быть  в нескольких заказах. В одном заказе одно блюдо может быть только один раз
Столик	Заказ	1 - N	Один столик может  быть  в нескольких заказах. В  заказе может быть только один столик.
Сотрудник	Акт Списания	1 - N	Один сотрудник может  оформить несколько Актов. Один любой  Акт может иметь только одного оформителя.

 

Разработка  Концептуальной инфологической модели

Инфологическая модель баз данных Сущность-связь Основные понятия Цель инфологического моделирования обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных (рисунок 2.1).

Рисунок 2.1 - Инфологическая модель

Даталогическое  проектирование

 

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

 

 

рис2.1   (Связь «Объект - Свойство» для объекта

«Поставка»)

 

 

 

рис2.2   (Связь «Объект - Свойство» для объекта

«Блюдо»)

рис2.3   (Связь «Объект - Свойство» для объекта

«Сотрудник»)

 

 

рис2.4   (Связь «Объект - Свойство» для объекта

«Заказ»)

 

 

 

рис2.5   (Связь «Объект - Свойство»  для объекта

«Акт Списания»)

 

 

 

 

рис2.6   (Связь «Объект - Свойство»  для объекта

«Поставщик»)

 

 

 

 

рис2.7   (Связь «Объект - Свойство» для объекта

«Столик»)

 

 

 

 

 

 

 

рис2.8   (Связь «Объект - Свойство» для объекта

«Категория»)

 

 

 

 

 

рис2.9   (Связь «Объект - Свойство» для объекта

«Тип продукта»)

 

 

 

 

 

 

 

рис2.10   (Связь «Объект - Свойство» для объекта

«Товар»)

 

 

 

 

Отношения и атрибуты

 

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

 

Таблица 2 – «Заказ»

Таблица	Атрибут	Тип Данных	Описание
Заказ	НомерЗаказа	Счетчик	Уникальный номер заказа
	НомерСтолика	Числовой	Номер столика с которого был сделан заказ
	Сотрудник	Числовой	Фамилия и Имя сотрудника принявшего заказ
	ДатаЗаказа	Дата/время	Дата занесения заказа в базу
	Оплачено	Логический	Идентификатор погашения  заказа (галачка = заказ оплачен)

 

Таблица 3 – «ЗаказДопТаб»

Таблица	Атрибут	Тип Данных	Описание
ЗаказДопТаб	НомерЗаказа	Числовой	Номер заказа
	Категория	Числовой	Категория нахождения блюда
	Блюдо	Числовой	Название блюда
	Кол-воПорций	Числовой	Кол-во заказанный порций блюда
	ЦенаПорции	Денежный	Цена одной порции
	Исполнено	Логический	Повар приготовил это  блюдо

 

 

 

Таблица 4 – «Поставка»

Таблица	Атрибут	Тип Данных	Описание
Поставка	НомерПоставки	Счетчик	Уникальный номер поставки
	Организация	Числовой	Название поставщика
	ДатаПоставки	Дата/время	Дата принятия поставки
	Приемщик	Числовой	Фамилия и Имя сотрудника, принимающего поставку

 

Таблица 5 – «ПоставкаДопТаб»

Таблица	Атрибут	Тип Данных	Описание
ПоставкаДопТаб	НомерПоставки	Числовой	Номер поставки
	Товар	Текстовый	Название постовляемого  продукта
	ТипПродукта	Текстовый	Категория типа продукта
	Кол-во	Числовой	Кол-во поставляемого  продукта
	ЕдИзм	Числовой	Единица измерения поставляемого продукта
	ЦенаЗаЕд	Денежный	Цена за одну единицу  продукта
	ЦенаОбщая	Денежный	Общая цена за один поставляемый продукт

 

Таблица 6 – «СписаниеПродукта»

Таблица	Атрибут	Тип Данных	Описание
СписаниеПродукта	НомерАкта	Счетчик	Уникальный номер акта
	ДатаАкта	Дата/время	Дата оформления акта
	Сотрудник	Числовой	Фамилия и Имя сотрудника принимающего акт

 

 

 

Таблица 7 – «СписаниеДопТаб»

Таблица	Атрибут	Тип Данных	Описание
СписаниеДопТаб	НомерАкта	Числовой	Номер акта
	Товар	Текстовый	Наименование списанного продукта
	ТипПродукта	Текстовый	Тип продукта
	Кол-во	Числовой	Кол-во списанного продукта
	ЕдИзм	Числовой	Единица измерения списанного продукта

 

 

Таблица 8 – «СправочникЕдИзм»

Таблица	Атрибут	Тип Данных	Описание
Справочник ЕдИзм	КодЕдИзм	Счетчик	Уникальный номер единицы измерения
	НазваниеЕдИзм	Текстовый	Полное название единицы  измерения
	Сокращение	Текстовый	Краткое название единицы  измерения

 

 

Таблица 9 – «СправочникКатегорий»

Таблица	Атрибут	Тип Данных	Описание
Справочник Категорий	КодКатегории	Счетчик	Уникальный номер категории
	ИмяКатегории	Текстовый	Уникальное название категории

 

 

Таблица 10 – «СправочникМеню»

Таблица	Атрибут	Тип Данных	Описание
Справочник Меню	КодБлюда	Счетчик	Уникальный номер блюда Уникальный номер блюда
	Категория	Числовой	Ктегория в которой  находится блюдо
	Блюдо	Текстовый	Уникальное название блюда
	РазмерПорции	Текстовый	Общая масса порции
	ЦенаПорции	Денежный	Общая цена за одну порцию
	ОписаниеБлюда	Текстовый	Краткое описание блюда

 

Таблица 11 – «СправочникПоставщиков»

Таблица	Атрибут	Тип Данных	Описание
Справочник Поставщиков	КодОрг	Счетчик	Уникальный номер организации
	НазваниеОрг	Текстовый	Название организации  постовляющая продукцию
	КонтактноеЛицо	Текстовый	Контактное лицо фирмы  поставщика
	Телефон	Числовой	Номер контактного телефона организации
	Адрес	Текстовый	Адрес местонахождения  организации

 

Таблица 12 – «СправочникСотрудников»

Таблица	Атрибут	Тип Данных	Описание
Справочник Сотрудников	КодСотрудника	Счетчик	Персональный номер  сотрудника
	Фамилия	Текстовый	Фамилия сотрудника предприятия
	Имя	Текстовый	Имя сотрудника предприятия
	Отчество	Текстовый	Отчество сотруника  предприятия
	Должность	Текстовый	Указывается какую должность  занимает данный сотрудник
	Адрес	Текстовый	Адрес проживания сотрудника
	Телефон	Числовой	Контактный номер телефона сотрудника
	ДатаР	Дата/время	День Рождения сотрудника
	ПриемНаРаботу	Дата/время	Дата начала работы сотрудника

 

Таблица 13 – «СправочникСтолов»

Таблица	Атрибут	Тип Данных	Описание
Справочник Столов	НомерСтолика	Счетчик	Уникальный номер столика
	Кол-воМест	Числовой	Кол-во сидячих мест за столиком

 

Таблица 14 – «СправочникТипПродукта»

Таблица	Атрибут	Тип Данных	Описание
Справочник ТипПродукта	КодПродукта	Счетчик	Уникальный номер типа продукта
	ТипПродукта	Текстовый	Класификацинное название типа продукта
	Описание	Текстовый	Кратное описание типа продукта

 

 

 

Ключевые поля и индексы

Ключ - одно или несколько полей, однозначно определяющих каждую запись базы данных.

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

Таблица 15 – Обозначения  ключей и индексов

Таблица	Атрибут	Ключи и Индексы
Заказ	НомерЗаказа	ключ, индекс уник
	НомерСтолика	Индекс не уникален
	Сотрудник	Индекс не уникален
	ДатаЗаказа	Индекс не уникален
	Оплачено	Индекс не уникален
ЗаказДопТаб	НомерЗаказа	Внешний ключ, Индекс не уникален
	Категория	Индекс не уникален
	Блюдо	Внешний ключ, Индекс не уникален
	Кол-воПорций	Не индексирован
	ЦенаПорции	Индекс не уникален
	Исполнено	Индекс не уникален
Поставка	НомерПоставки	Ключ, Индекс уникален
	Организация	Индекс не уникален
	ДатаПоставки	Индекс не уникален
	Приемщик	Индекс не уникален
ПоставкаДопТаб	НомерПоставки	Внешний ключ Индекс не уникален
	Товар	Ключ, Индекс не уникален
	ТипПродукта	Индекс не уникален
	Кол-во	Не индексирован
	ЕдИзм	Индекс не уникален
	ЦенаЗаЕд	Индекс не уникален
	ЦенаОбщая	Не индексирован
Списание	НомерАкта	Ключ, Индекс уникален
	ДатаАкта	Индекс не уникален
	Сотрудник	Индекс не уникален
СписаниеДопТаб	НомерАкта	Ключ, Индекс уникален
	Товар	Ключ, Индекс не уникален
	ТипПродукта	Индекс не уникален
	Кол-во	Не индексирован
	ЕдИзм	Индекс не уникален
СправочникЕдИзм	КодЕдИзм	Ключ, Индекс уникален
	НазваниеЕдИзм	Не индексирован
	Сокращение	Не индексирован
СправочникКатегорий	КодКатегории	Ключ, Индекс уникален
	ИмяКатегории	Индекс уникален
СправочникМеню	КодБлюда	Ключ, Индекс уникален
	Категория	Индекс не уникален
	Блюдо	Индекс уникален
	РазмерПорции	Не индексирован
	ЦенаПорции	Не индексирован
	ОписаниеБлюда	Не индексирован
СправочникПоставщиков	КодОрг	Ключ, Индекс уникален
	НазваниеОрг	Индекс уникален
	КонтактноеЛицо	Не индексирован
	Телефон	Не индексирован
	Адрес	Не индексирован
СправочникСотрудников	КодСотрудника	Клюя, Индекс уникален
	Фамилия	Не индексирован
	Имя	Не индексирован
	Отчество	Не индексирован
	Должность	Индекс не уникален
	Адрес	Не индексирован
	Телефон	Не индексирован
	ДатаР	Индекс не уникален
	ПриемНаРаботу	Индекс не уникален
СправочникСтолов	НомерСтолика	Ключ, Индекс уникален
	Кол-воМест	Не индексирован
СправочникТипПродукта	КодПродукта	Индекс уникален
	ТипПродукта	Ключ, Индекс уникален
	Описание	Не индексирован

 

Нормализация  отношений

 

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

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

Нормализация отношений  — формальный аппарат ограничений на формирование отношений (таблиц), который позволяет устранить дублирование, обеспечивает непротиворечивость хранимых в базе данных, уменьшает трудозатраты на ведение (ввод, корректировку) базы данных.

Выделены три нормальные формы отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей (самой совершенной) нормальной форме.

 

• Первая нормальная форма

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

Например, отношение Сотрудник = (Номер, Фамилия, Имя, Отчество, Дата Рождения) наводится в первой нормальной форме.

К первой нормальной форме, относятся  таблицы: СправочникЕдИзм,

СправочникКатегорий,  СправочникМеню,  СправочникТипПродукта, СправочникПоставщиков,  СправочникСотрудников,  СправочникСтолов.

3. Вторая нормальная форма

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

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

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

Такое определение функциональной зависимости позволяет при анализе  всех взаимосвязей реквизитов предметной области выделить самостоятельные информационные объекты.