База данных "Столовая" (курсовая - программа (база данных Visual FoxPro) и пояснительная записка)


СОДЕРЖАНИЕ

ВВЕДЕНИЕ    3
1. СИСТЕМНЫЙ АНАЛИЗ    4
2. ER-МОДЕЛЬ    14
3. ОПИСАНИЕ БАЗЫ ДАННЫХ «СТОЛОВАЯ»    21
4. ПРОГРАММА И ФОРМЫ БД    26
ЗАКЛЮЧЕНИЕ    34
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ    35

 

ВВЕДЕНИЕ

 

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

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

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

В рамках данной работы ставим перед собой следующие задачи:

  • рассмотреть вопрос применения системного анализа при проектировании БД
  • рассмотреть вопрос использования ER-модели при проектирование БД
  • спроектировать реляционную БД, находящуюся в третьей нормальной форме
  • реализовать проект БД в среде Visual Fox Pro

 

2. ER-МОДЕЛЬ

 

Рассмотрим некоторые черты одной из наиболее популярных семантических моделей данных – модель «Сущность-Связь» (часто ее называют кратко ER-моделью от Entity-Relationship).

Здесь следует сделать два замечания, касающиеся, главным образом, терминологии. Оба термина relation и relationship могут быть переведены на русский язык как отношение. Поэтому в русскоязычной литературе ER-модель иногда называют моделью сущность-отношение, а иногда и реляционной семантической моделью. Наверное, в этом нет ничего страшного, если говорить о ER-модели в отрыве от тематики проектирования реляционных баз данных.

Но если требуется одновременно использовать термины ER-модели и реляционной модели данных, то, безусловно, требуется применять для терминов relation и relationship разные русские эквиваленты. За этими терминами стоят весьма различные понятия. В реляционной модели отношение (relation) – это единственная родовая структура данных. С помощью этого же механизма представляются «связанные» сущности (вспомните, например, про внешние ключи). Как мы увидим немного позже, в ER-модели для представления схемы базы данных используются два равноправных понятия – сущность и связь. Связи в ER-модели играют роль, отличную от той, какую играют отношения в реляционной модели данных.

Кроме того, в русскоязычную терминологию вошла и чистая транслитерация термина relation именно в смысле отношение. Мы говорим, например, про реляционную модель данных, реляционную алгебру и т. д., понимая модель данных, основанную на отношениях, алгебру отношений и т. п. По этому поводу, по крайней мере, в контексте баз данных, разумно окончательно зарезервировать термины relation и отношение для обозначения понятий реляционной модели данных, а для термина relationship использовать другой допустимый русскоязычный эквивалент – связь.

На использовании разных вариантов ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Питером Ченом (Peter Chen) в 1976 г. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. Простота и наглядность представления концептуальных схем баз данных в ER-модели привели к ее широкому распространению в CASE-системах, поддерживающих автоматизированное проектирование реляционных баз данных. Среди множества разновидностей ER-моделей одна из наиболее популярных и развитых применялась в системе CASE компании Oracle. Мы обсудим некоторый упрощенный вариант этой модели. Если говорить более точно, сосредоточимся на ее структурной и целостной частях.

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

В диаграммах ER-модели  сущность представляется в виде прямоугольника, содержащего имя сущности. При этом имя сущности – это имя типа, а не некоторого конкретного экземпляра этого типа.

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

 

Рис. 2.1.  Пример типа сущности

 

На рис. 2.1 изображена сущность  АЭРОПОРТ с примерными экземплярами «Шереметьево» и «Хитроу». Эта примитивная диаграмма тем не менее несет важную информацию. Во-первых, она показывает, что в базе данных будут содержаться однотипные структуры данных (экземпляры сущности), описывающие аэропорты.

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

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

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

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

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

трехточечный вход в прямоугольник сущности, если для этой сущности в связи могут (или должны) использоваться много (many) экземпляров сущности;

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

Обязательный конец связи изображается сплошной линией, а необязательный – прерывистой линией.

Связь между сущностями  БИЛЕТ и ПАССАЖИР, показанная на рис. 2.2, связывает билеты и пассажиров. Конец связи с именем «для» позволяет связывать с одним пассажиром более одного билета, причем каждый билет должен быть связан с каким-либо пассажиром. Конец связи с именем «имеет» показывает, что каждый билет может принадлежать только одному пассажиру, причем пассажир не обязан иметь хотя бы один билет.

 

Рис. 2.2.  Пример типа связи

 

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

каждый БИЛЕТ предназначен для одного и только одного ПАССАЖИРА;

каждый ПАССАЖИР может иметь один или более БИЛЕТОВ.

На следующем примере (рис. 2.3) изображена рекурсивная связь, связывающая сущность  МУЖЧИНА с ней же самой. Конец связи с именем «сын» определяет тот факт, что несколько людей могут быть сыновьями одного отца. Конец связи с именем «отец» означает, что не у каждого мужчины должны быть сыновья.

 

Рис.2.3.  Пример рекурсивного типа связи

 

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

каждый МУЖЧИНА является сыном одного и только одного МУЖЧИНЫ;

каждый МУЖЧИНА может являться отцом одного или более МУЖЧИН.

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

Пример типа сущности  ЧЕЛОВЕК с указанными атрибутами показан на рис. 2.4. С технической точки зрения атрибуты  типа сущности в ER-модели похожи на атрибуты отношения в реляционной модели данных. И в том, и в другом случаях введение именованных атрибутов вводит некоторую типовую структуру данных, имя которой совпадает с именем типа сущности в случае ER-модели или с именем переменной отношения в случае реляционной модели. Этой типовой структуре должны следовать все экземпляры типа сущности или все кортежи отношения. Но имеется и важное отличие. Напомним, что в реляционной модели данных атрибут определяется как упорядоченная пара <имя_атрибута, имя_домена> (или <имя_атрибута, имя_базового_типа_данных>, если понятие домена не поддерживается). Заголовок отношения, определяемый как множество таких пар, представляет собой полный аналог структурного типа данных в языках программирования.

 

Рис. 2.4.  Пример типа сущности с атрибутами

 

При определении атрибутов типа сущности в ER-модели указание домена атрибута не является обязательным, хотя это и возможно (см. ниже). Обсудим, чем вызвана эта возможность «ослабленного» определения атрибутов. Прежде всего, как отмечалось в разделе «Введение», семантические модели данных используются для построения концептуальных схем БД, и эти схемы преобразуются в реляционные схемы БД, которые поддерживаются той или иной СУБД.

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

Кроме того, напомним, что при определении атрибута отношения допускается использование имен атрибутов, совпадающих с именами своих доменов (это два разных пространства имен, и наличие одинаковых имен у атрибутов и доменов не вызывает коллизий). Поэтому при определении атрибутов типов сущности можно так подбирать их имена, что они в дальнейшем будут подсказывать, какие домены у этих атрибутов имеются в виду. Пониманию предполагаемой сути доменов способствует и возможность указания примеров значений атрибутов. Например, на рис. 2.4 имеется атрибут  год рождения, в качестве примерного значения которого указано «1976». Это подсказывает, что в реляционной схеме при определении соответствующего атрибута наиболее естественным базовым типом данных будет темпоральный тип «ДАТА», значения которого задают дату с точностью до года.

3. ОПИСАНИЕ БАЗЫ ДАННЫХ «СТОЛОВАЯ»

 

База данных «Столовая» служит для автоматизации работы учреждения общественного питания. БД структурно состоит из 6 таблиц, некоторые из которых соединены по смыслу посредством внешних ключей.  На рис. 3.1., 3.2., 3.3., 3.4.,3.5., 3.6. изображены структуры таблиц БД. Таблица Blyuda и Napitki не имеют внешних связей, так как в контексте данной базы данных они не требуются. При разработке более сложной базы данных и увеличении числа таблиц такие внешние связи, вероятно, потребовались бы. Эти таблицы хранят информацию обо всех блюдах и напитках, предлагаемых в столовой, порциях и ценах этих порций. Поля Blyudo_id и Napitok_id – это соответственно поля первичного ключа для обоих таблиц, значения которого должны быть уникальны.

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

Таблицы Produkty (продукты) и Postav (поставщики) связаны по полю post_id (идентификатор поставщика). В таблице Produkty хранится информация о продуктах, имеющихся в столовой – их название, единицы измерения и запасы.

В таблице Postav хранится информация о поставщиках продуктов – название предприятий-поставщиков, их адреса и телефоны, а также задолженность столовой переел ними за поставленную продукцию.

 

Рис. 3.1. Структура таблицы Blyuda (блюда)

 

Рис. 3.2. Структура таблицы Napitki (напитки)

 

Рис. 3.3. Структура таблицы Personal (персонал)

 

Рис. 3.4. Структура таблицы Dolzh (должность)

 

Рис. 3.5. Структура таблицы Produkty (продукты)

 

Рис. 3.6. Структура таблицы Postav (поставщики)

 

На этапе проектирования системы была разработана ее инфологическая модель или ER-модель (рис.3.7.). Поясним значение этой модели с точки зрения нотации описания ER моделей. Рассмотрим сначала связь таблиц Personal и Dolzh. Отношение между ними имеет формат один ко многим, что и показано на рисунке «лапкой» на конце линии связи между этим таблицами.

 

Рис. 3.7. ER-модель базы данных

 

Перпендикуляр означает, что по крайней мере один экземпляр сущности участвует в связи, то есть у каждого работника обязательно должна быть по крайней мере одна должность, в соответствии с которой  он получает оклад. «Кружочек» же у таблицы Personal означает, что вхождение сущности в связь не обязательно. Это может быть, например, если какая-то должность вакантна и еще никем не занята, но тем не менее существует и ей соответствует определенный оклад.

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

На рис. 3.8. изображена реляционная модель структуры БД. Данная модель соответствует физической реализации БД в среде Visual Fox Pro.

 

База данных "Столовая"

Рис. 3.8. Структура БД «Столовая»

 

4. ПРОГРАММА И ФОРМЫ БД

 

Для облегчения работы пользователя с БД и для представления информации в удобном для пользователя виде, мы используем в БД визуальные компоненты – формы, с элементами управления – кнопками (Buttons), полями ввода текста (Text Boxes),  раскрывающимися списками (Check Boxes). При нажатии на кнопки происходит выполнение написанного нами программного кода с использованием языка SQL.

Программа выполняется под управлением СУБД Fox Pro путем запуска главного программного модуля mainprg на выполнения с помощью нажатия кнопки Run.

 

Рис. 4.1. Запуск программы под управлением СУБД Fox Pro

 

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

 

Рис. 4.2. Запуск основной формы программы

 

Рис. 4.3. Получение информации о блюдах в столовой

 

Отбор данных может происходить и из нескольких таблиц, то есть путем выполнения сложного SQL запроса (рис. 4.4.).

 

База данных "Столовая"

Рис. 4.4. Отбор информации из нескольких таблиц с помощью сложного SQL запроса

 

Приведем листинг кода процедуры Combo1.Click, которая отвечает за отображение информации в объекте Grid после выбора условия в раскрывающемся списке Combo:

 

IF ThisForm.PF.Page1.Combo1.Value = "Блюда"

SELECT Blyuda.Nazvanie,Blyuda.Porciya, Blyuda.Cena FROM Blyuda INTO Cursor Curss NOCONSOLE ORDER BY Blyuda.Nazvanie

ThisForm.PF.Page1.Grid1.RecordSource = "Curss"

ThisForm.PF.Page1.Grid1.ColumnCount=3

ThisForm.PF.Page1.Grid1.Column1.Width = int(Wid/3)

ThisForm.PF.Page1.Grid1.Column2.Width = int(Wid/3)

ThisForm.PF.Page1.Grid1.Column3.Width = int(Wid/3)

ThisForm.PF.Page1.Grid1.Column1.Header1.Caption = "Блюдо"

ThisForm.PF.Page1.Grid1.Column2.Header1.Caption = "Порция"

ThisForm.PF.Page1.Grid1.Column3.Header1.Caption = "Цена"

ENDIF

IF ThisForm.PF.Page1.Combo1.Value = "Напитки"

SELECT Napitki.Nazvanie,Napitki.Porciya, Napitki.Cena FROM Napitki INTO Cursor Curss NOCONSOLE ORDER BY Napitki.Nazvanie

ThisForm.PF.Page1.Grid1.RecordSource = "Curss"

ThisForm.PF.Page1.Grid1.Column1.Width = int(Wid/3)

ThisForm.PF.Page1.Grid1.Column2.Width = int(Wid/3)

ThisForm.PF.Page1.Grid1.Column3.Width = int(Wid/3)

ThisForm.PF.Page1.Grid1.Column1.Header1.Caption = "Напиток"

ThisForm.PF.Page1.Grid1.Column2.Header1.Caption = "Порция"

ThisForm.PF.Page1.Grid1.Column3.Header1.Caption = "Цена"

ENDIF

IF ThisForm.PF.Page1.Combo1.Value = "Персонал"

SELECT Personal.FIO,Dolzh.Nazvanie, Dolzh.Oklad FROM Personal INNER JOIN Dolzh ON (Personal.Dolzh_id = Dolzh.Dolzh_id)INTO Cursor Curss NOCONSOLE ORDER BY Personal.FIO

ThisForm.PF.Page1.Grid1.RecordSource = "Curss"

ThisForm.PF.Page1.Grid1.ColumnCount=3

ThisForm.PF.Page1.Grid1.Column1.Width = int(Wid/3)

ThisForm.PF.Page1.Grid1.Column2.Width = int(Wid/3)

ThisForm.PF.Page1.Grid1.Column3.Width = int(Wid/3)

ThisForm.PF.Page1.Grid1.Column1.Header1.Caption = "ФИО"

ThisForm.PF.Page1.Grid1.Column2.Header1.Caption = "Должность"

ThisForm.PF.Page1.Grid1.Column3.Header1.Caption = "Оклад"

ENDIF

IF ThisForm.PF.Page1.Combo1.Value = "Продукты"

SELECT Produkty.Nazvanie,Produkty.Zapas, Produkty.Ed_Izmer, Postav.Nazvanie FROM Produkty INNER JOIN Postav ON (Produkty.Post_id = Postav.Post_id)INTO Cursor Curss NOCONSOLE ORDER BY Produkty.Nazvanie

ThisForm.PF.Page1.Grid1.RecordSource = "Curss"

ThisForm.PF.Page1.Grid1.ColumnCount=4

ThisForm.PF.Page1.Grid1.Column1.Width = int(Wid/4)

ThisForm.PF.Page1.Grid1.Column2.Width = int(Wid/10)

ThisForm.PF.Page1.Grid1.Column3.Width = int(Wid/10)

ThisForm.PF.Page1.Grid1.Column4.Width = int(Wid/2)

ThisForm.PF.Page1.Grid1.Column1.Header1.Caption = "Продукт"

ThisForm.PF.Page1.Grid1.Column2.Header1.Caption = "Запас"

ThisForm.PF.Page1.Grid1.Column3.Header1.Caption = "Единица измерения"

ThisForm.PF.Page1.Grid1.Column4.Header1.Caption = "Поставщик"

ENDIF

IF ThisForm.PF.Page1.Combo1.Value = "Поставщики"

SELECT Postav.Nazvanie,Postav.Adres, Postav.Telefon, Postav.Dolg FROM Postav INTO Cursor Curss NOCONSOLE ORDER BY Postav.Nazvanie

ThisForm.PF.Page1.Grid1.RecordSource = "Curss"

ThisForm.PF.Page1.Grid1.ColumnCount=4

ThisForm.PF.Page1.Grid1.Column1.Width = int(Wid/3)

ThisForm.PF.Page1.Grid1.Column2.Width = int(Wid/3)

ThisForm.PF.Page1.Grid1.Column3.Width = int(Wid/6)

ThisForm.PF.Page1.Grid1.Column4.Width = int(Wid/6)

ThisForm.PF.Page1.Grid1.Column1.Header1.Caption = "Поставщик"

ThisForm.PF.Page1.Grid1.Column2.Header1.Caption = "Адрес"

ThisForm.PF.Page1.Grid1.Column3.Header1.Caption = "Телефон"

ThisForm.PF.Page1.Grid1.Column4.Header1.Caption = "Долг"

ENDIF


На вкладке Добавление и удаление происходит добавление или удаление блюда или напитка в БД (рис. 4.5.)

 

Рис. 4.5. Добавление/удаление объекта в БД

 

С помощью переключателей мы выбираем c какой таблицей работать – Blyuda или Napitki и что делать – добавлять или удалять (рис. 4.6.). Заполняем текстовые поля с описанием блюда и нажимаем кнопку «Подтвердить».

 

Рис. 4.6. Добавления нового блюда

 

Если мы хотим удалить блюдо или напиток из БД, мы отмечаем опцию «Удалить» (рис. 4.7.). С помощью SQL запроса из нужной таблицы БД получаем список блюд или напитков в элемент Combo (раскрывающийся список). Выбираем элемент на удаление и нажимаем кнопку «Подтвердить».

 

 

Заказать курсовую

 

Добавить комментарий


Защитный код
Обновить