Разработка программного обеспечения средств автоматизации ресторанного бизнеса на C++Builder

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

МИНИСТЕРСТВО ПО РАЗВИТИЮ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ И КОММУНИКАЦИЙ РЕСПУБЛИКИ УЗБЕКИСТАН

ТАШКЕНТСКИЙ УНИВЕРСИТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

Разработка программного обеспечения средств автоматизации ресторанного бизнеса на C++Builder

Выпускник Арипов Н.М.

Научный руководитель

ТАШКЕНТ - 2015 г.

Аннотация

Выпускная работа посвящена разработке программного обеспечения средств автоматизации ресторанного бизнеса. Программное обеспечение представляет собой приложение под Windows XP, реализованное средствами языка C++ Builder 6. Приложение является законченным программным продуктом.

Annotation

Final work is dedicated to the development of software for the automation of restaurant business. The software is an application for Windows XP, implemented by means of language C ++ Builder 6. The application is a complete software package.

Мазмуннома

Битирув иш ресторан бизнес сохасида автоматлаштириш воситаларининг дастурий таъминотини ишлаб чикишга багишланган. Дастурий таъминот Windows XP учун, С++Builder 6 тилида узи билан илова булиб такдим этилади. Илова, тайёр дастурий махсулот булиб хисобланади.

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1. ОБЗОРНАЯ ЧАСТЬ. База данных и СУБД

1.1 Современный подход к автоматизации ресторанного бизнеса

1.2 Понятие базы данных и СУБД

1.3 Требования к базам данных

1.4 Информационные системы и базы данных

1.5 C++ Builder и базы данных

1.6 Выбор и обоснование инструментальных средств обработки

2. ОСНОВНАЯ ЧАСТЬ. Технологическая часть

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

2.2 Руководство программисту

2.2.1 Модули

2.2.2 Взаимосвязь модулей

2.3 Инструкция пользователю

3. БЕЗОПАСНОСТЬ ЖИЗНЕДЕЯТЕЛЬНОСТИ

3.1 Рациональная организация рабочего места

3.2 Чрезвычайные ситуации

3.3 Модели производственных процессов с точки зрения экологии

ЗАКЛЮЧЕНИЕ

СПИСОК ЛИТЕРАТУРЫ

ПРИЛОЖЕНИЕ

ВВЕДЕНИЕ

Глава нашего государства Ислам Каримов, постоянно развивает сферу ИКТ, разрабатывая различные программы и определяя перспективы направления дальнейшей деятельности. Для этого наш Президент принял постановление "О мерах по дальнейшему внедрению и развитию современных информационно-коммуникационных технологий.

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

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

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

В частности, задача разработки программного обеспечения средств автоматизации ресторанного бизнеса на C++ Builder является одной из важнейших задач автоматизации человеческой деятельности. Ввиду чего, поставленная в выпускной работе задача является актуальной в настоящее время.

Цель работы - разработка программного обеспечения средств автоматизации информационной системы ресторанного бизнеса на C++ Builder.

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

Одной из широко используемых сред разработки является Borland C++Builder, который позволяет создавать различные приложения: от простейших однооконных приложений до программ распределения баз данных.

При этом необходимо решить следующие задачи:

необходимо создать наглядный и удобный интерфейс для пользования данным программным продуктом;

создать надежную и защищенную базу данных;

определить основные принципы для обеспечения оптимальной работы;

провести анализ полученных результатов.

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

Для удобного и функционального написания подобного программного обеспечения лучше всего подходит среда объектно-ориентированного программирования на языке C++ Builder.

Основной упор объектно-ориентированной модели в C++ Builder делается на максимальном использовании кода. Это позволяет разработчикам строить приложения весьма быстро из заранее подготовленных объектов, а также дает им возможность создавать свои собственные объекты для среды C++ Builder. Никаких ограничений по типам объектов, которые могут создавать разработчики, не существует. Действительно, все в C++ Builder написано на нём же, поэтому разработчики имеют доступ к тем же объектам и инструментам, которые использовались для создания среды разработки. В результате нет никакой разницы между объектами, поставляемыми Borland или третьими фирмами, и объектами, которые вы можете создать.

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

Введения;

Обзорной части;

Основной части;

Раздела БЖД;

Заключения;

Списка используемой литературы;

Приложений.

В обзорной части представлены следующие вопросы: современный подход к автоматизации ресторанного бизнеса, требования к базам данных, информационные системы и базы данных, C++ Builder и базы данных, процессор баз данных Borland Database Engine, архитектура и функции BDE.

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

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

В приложении приводятся тексты программных модулей.

1. ОБЗОРНАЯ ЧАСТЬ. БАЗА ДАННЫХ И СУБД

1.1 Современный подход к автоматизации ресторанного бизнеса

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

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

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

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

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

1.2 Понятие базы данных и СУБД

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

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

Структурирование - это введение соглашений о способах представления данных.

Неструктурированными называют данные, записанные, например, в текстовом файле.

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

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

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

физическом размещении в памяти данных и их описаний;

механизмах поиска запрашиваемых данных;

проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);

способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;

поддержании баз данных в актуальном состоянии.

В качестве СУБД для реализации базы данных была использована Microsoft Access. Microsoft Access является настольной СУБД реляционного типа, которая имеет все необходимые средства для выполнения перечисленных выше функций. Система управления базами данных Microsoft Access является одним из самых популярных приложений в семействе настольных СУБД. Все версии Access имеют в своем арсенале средства, значительно упрощающие ввод и обработку данных, поиск данных и предоставление информации в виде таблиц, графиков и отчетов. Начиная с версии Access 2000, появились также Web-страницы доступа к данным, которые пользователь может просматривать с помощью программы Internet Explorer. Помимо этого, Access позволяет использовать электронные таблицы и таблицы из других настольных и серверных баз данных для хранения информации, необходимой приложению. Присоединив внешние таблицы, пользователь Access будет работать с базами данных в этих таблицах так, как если бы это были таблицы Access. При этом и другие пользователи могут продолжать работать с этими данными в той среде, в которой они были созданы.

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

1.3 Требования к базам данных

Итак, хорошо спроектированная база данных:

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

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

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

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

Следующие пункты представляют основные шаги проектирования базы данных:

Определить информационные потребности базы данных.

Проанализировать объекты реального мира, которые необходимо смоделировать в базе данных. Сформировать из этих объектов сущности и характеристики этих сущностей (например, для сущности “деталь” характеристиками могут быть “название”, “цвет”, “вес” и т.п.) и сформировать их список.

Поставить в соответствие сущностям и характеристикам - таблицы и столбцы (поля) в нотации выбранной Вами СУБД (Paradox, dBase, FoxPro, Access, Clipper, InterBase, Sybase, Informix, Oracle и т.д.).

Определить атрибуты, которые уникальным образом идентифицируют каждый объект.

Выработать правила, которые будут устанавливать и поддерживать целостность данных.

Установить связи между объектами (таблицами и столбцами), провести нормализацию таблиц.

Спланировать вопросы надежности данных и, при необходимости, сохранения секретности информации.

Шаги проектирования базы данных

Первый шаг состоит в определении:

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

сможет ли новая система объединить существующие приложения или их необходимо будет кардинально переделывать для совместной работы с новой системой;

какие данные используются разными приложениями; смогут ли Ваши приложения совместно использовать какие-либо из этих данных;

кто будет вводить данные в базу и в какой форме; как часто будут изменяться данные;

достаточно ли будет для Вашей предметной области одной базы или Вам потребуется несколько баз данных с различными структурами;

какая информация является наиболее чувствительной к скорости ее извлечения и изменения.

II. Следующий шаг включает в себя анализ объектов реального мира, которые необходимо смоделировать в базе данных.

Формирование концептуальной модели базы данных включает в себя:

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

идентификацию объектов, которые осуществляют эту функциональную деятельность, и формирование из их операций последовательности событий, которые помогут Вам идентифицировать все сущности и взаимосвязи между ними. Например, процесс “ведение учета работающих” идентифицирует такие сущности как РАБОТНИК, ПРОФЕССИЯ, ОТДЕЛ.

идентификацию характеристик этих сущностей. Например, сущность РАБОТНИК может включать такие характеристики как Идентификатор Работника, Фамилия, Имя, Отчество, Профессия, Зарплата.

идентификацию взаимосвязей между сущностями. Например, каким образом сущности РАБОТНИК, ПРОФЕССИЯ, ОТДЕЛ взаимодействуют друг с другом? Работник имеет одну профессию (для простоты!) и значится в одном отделе, в то время как в одном отделе может находиться много работников.

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

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

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

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

Эти правила включают:

определение типа данных

выбор набора символов, соответствующего данной стране

создание полей, опирающихся на домены

установка значений по умолчанию

определение ограничений целостности

определение проверочных условий.

VI. На шестом шаге устанавливаются связи между объектами (таблицами и столбцами) и производится очень важная операция для исключения избыточности данных - нормализация таблиц. Каждый из различных типов связей должен быть смоделирован в базе данных. Существует несколько типов связей:

связь “один-к-одному”

связь “один-ко-многим”

связь “многие-ко-многим”.

Связь “один-к-одному” представляет собой простейший вид связи данных, когда первичный ключ таблицы является в то же время внешним ключом, ссылающимся на первичный ключ другой таблицы. Такую связь бывает удобно устанавливать тогда, когда невыгодно держать разные по размеру (или по другим критериям) данные в одной таблице. Например, можно выделить данные с подробным описанием изделия в отдельную таблицу с установлением связи “один-к-одному” для того чтобы не занимать оперативную память, если эти данные используются сравнительно редко. Связь “один-ко-многим” в большинстве случаев отражает реальную взаимосвязь сущностей в предметной области. Она реализуется уже описанной парой “внешний ключ-первичный ключ”, т.е. когда определен внешний ключ, ссылающийся на первичный ключ другой таблицы. Именно эта связь описывает широко распространенный механизм классификаторов. Имеется справочная таблица, содержащая названия, имена и т.п. и некие коды, причем, первичным ключом является код. В таблице, собирающей информацию - назовем ее информационной таблицей - определяется внешний ключ, ссылающийся на первичный ключ классификатора. После этого в нее заносится не название из классификатора, а код. Такая система становится устойчивой от изменения названия в классификаторах. Имеются способы быстрой “подмены” в отображаемой таблице кодов на их названия как на уровне сервера БД (для клиент-серверных СУБД), так и на уровне пользовательского приложения. Но об этом - в дальнейших уроках. Связь “многие-ко-многим” в явном виде в реляционных базах данных не поддерживается. Однако имеется ряд способов косвенной реализации такой связи, которые с успехом возмещают ее отсутствие. Один из наиболее распространенных способов заключается во введении дополнительной таблицы, строки которой состоят из внешних ключей, ссылающихся на первичные ключи двух таблиц. Например, имеются две таблицы: КЛИЕНТ и ГРУППА_ИНТЕРЕСОВ. Один человек может быть включен в различные группы, в то время как группа может объединять различных людей. Для реализации такой связи “многие-ко-многим” вводится дополнительная таблица, назовем ее КЛИЕНТЫ_В_ГРУППЕ, строка которой будет иметь два внешних ключа: один будет ссылаться на первичный ключ в таблице КЛИЕНТ, а другой - на первичный ключ в таблице ГРУППА_ИНТЕРЕСОВ. Таким образом в таблицу КЛИЕНТЫ_В_ГРУППЕ можно записывать любое количество людей и любое количество групп. Итак, после определения таблиц, полей, индексов и связей между таблицами следует посмотреть на проектируемую базу данных в целом и проанализировать ее, используя правила нормализации, с целью устранения логических ошибок. Важность нормализации состоит в том, что она позволяет разбить большие отношения, как правило, содержащие большую избыточность информации, на более мелкие логические единицы, группирующие только данные, объединенные “по природе”. Таким образом, идея нормализации заключается в следующем. Каждая таблица в реляционной базе данных удовлетворяет условию, в соответствии с которым в позиции на пересечении каждой строки и столбца таблицы всегда находится единственное значение, и никогда не может быть множества таких значений. После применения правил нормализации логические группы данных располагаются не более чем в одной таблице. Это дает следующие преимущества:

данные легко обновлять или удалять

исключается возможность рассогласования копий данных

уменьшается возможность введения некорректных данных.

Процесс нормализации заключается в приведении таблиц в так называемые нормальные формы. Существует несколько видов нормальных форм: первая нормальная форма (1НФ), вторая нормальная форма (2НФ), третья нормальная форма (3НФ), нормальная форма Бойса-Кодда (НФБК), четвертая нормальная форма (4НФ), пятая нормальная форма (5НФ). С практической точки зрения, достаточно трех первых форм - следует учитывать время, необходимое системе для “соединения” таблиц при отображении их на экране. Поэтому мы ограничимся изучением процесса приведения отношений к первым трем формам.

Этот процесс включает:

устранение повторяющихся групп (приведение к 1НФ)

удаление частично зависимых атрибутов (приведение к 2НФ)

удаление транзитивно зависимых атрибутов (приведение к 3НФ).

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

кто будет иметь права (и какие) на использование базы данных

кто будет иметь права на модификацию, вставку и удаление данных

нужно ли делать различие в правах доступа

каким образом обеспечить общий режим защиты информации и т.п.

Информационные системы и базы данных

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

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

Структурирование -- это введение соглашений о способах представления данных.

Неструктурированными называют данные, записанные, например, в текстовом файле.

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

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

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

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

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

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

Централизованная база данных хранится в памяти одной вычислительной системы. Если эта вычислительная система является компонентом сети ЭВМ, возможен распределенный доступ к такой базе. Такой способ использования баз данных часто применяют в локальных сетях ПК.

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

По способу доступа к данным базы данных разделяются на базы данных с локальным доступом и базы данных с удаленным (сетевым) доступом.

Системы централизованных баз данных с сетевым доступом предполагают различные архитектуры подобных систем:

* файл-сервер;

* клиент-сервер.

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

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

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

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

имя, например. Фамилия, Имя, Отчество, Дата рождения;

тип, например, символьный, числовой, календарный;

длина, например, 15 байт, причем будет определяться максимально возможным количеством символов;

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

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

Файл (таблица) -- совокупность экземпляров записей одной структуры.

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

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

Модель данных -- совокупность структур данных и операций их обработки.

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

Рассмотрим три основных типа моделей данных: иерархическую, сетевую и реляционную.

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

К основным понятиям иерархической структуры относятся: уровень, элемент (узел), связь. Узел -- это совокупность атрибутов данных, описывающих некоторый объект. На схеме иерархического дерева узлы представляются вершинами графа. Каждый узел на более низком уровне связан только с одним узлом, находящимся на более высоком уровне. Иерархическое дерево имеет только одну вершину (корень дерева), не подчиненную никакой другой вершине и находящуюся на самом верхнем (первом) уровне. Зависимые (подчиненные) узлы находятся на втором, третьем и т.д. уровнях. Количество деревьев в базе данных определяется числом корневых записей.

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

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

Понятие реляционный (англ. relation -- отношение) связано с разработками известного американского специалиста в области систем баз данных Е. Кодда.

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

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

каждый элемент таблицы -- один элемент данных;

все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину;

каждый столбец имеет уникальное имя;

одинаковые строки в таблице отсутствуют;

порядок следования строк и столбцов может быть произвольным.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Третья нормальная форма

Понятие третьей нормальной формы основывается на понятии нетранзитивной зависимости.

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

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

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

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

один к одному (1:1);

один ко многим (1: М);

многие ко многим (М: М).

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

При связи один ко многим (1:М) одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с 1 экземпляром объекта А. Графически данное соответствие имеет вид.

Связь многие ко многим (М:М) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В и наоборот.

1.5 C++ Builder и базы данных

Базы данных считаются основным достоинством C++ Builder. Это действительно так. Хотя язык и не создавался специально под эту предметную область программирования, но реализация работы с данными здесь просто поражает. Даже специализированные языки, которые предназначены для работы с базами данных (такие, как MS Visual FoxPro), явно уступают C++ Builder по простоте и мощи программирования.

C++ Builder скрывает все сложности и в то же время предоставляет широчайшие возможности при создании баз данных. Практически любую задачу в этой предметной области можно реализовать средствами этого языка, причем за довольно короткий промежуток времени. Главное здесь то, что реализация приложения очень удобна и проста в понимании.

Для работы с базами в C++ Builder есть несколько наборов компонентов. Каждый набор очень хорошо подходит для решения определенного круга задач. Почему такое разнообразие компонентов? Все они используют разные технологии доступа к данным и отличаются по своим возможностям. Microsoft встроила в свои в свои продукты разработки только технологию доступа к данным ADO, собственной разработки. Фирма Borland предоставила разнообразные средства, работающие через разные технологии, и не ограничивает программиста только своими разработками. Такое положение вещей дает громадные преимущества. Помимо этого, есть группы компонентов, которые могут использоваться в любом случае.

Произведем краткий обзор имеющихся средств доступа к базам данных.

На вкладке Data Access расположены основные компоненты доступа к данным. Эти компоненты общие для всех и могут использоваться совместно с другими группами компонентов.

На вкладке Dala Controls расположены компоненты для отображения и редактирования данных в таблицах. Эти компоненты так же используются в независимости от используемой на данный момент технологии доступа к данным.

Вкладка BDE содержит компоненты, позволяющие получить доступ к базам данных по технологии, разработанной фирмой Borland, под названием Borland Database Engine. Она хорошо работает базами данных, например, такими как Paradox и dBase.

DBExpress -- это новая технология доступа к данным фирмы Borland. Она отличается большей гибкостью и хорошо подходит для программирования клиент-серверных приложений, использующих базы данных. Компоненты с одноименной вкладки желательно использовать с базами данных, построенных по серверной технологии, например, Oracle, DB2 или MySQL.

ADO (Active Data Objects) -- технология доступа к данным, разработанная корпорацией Microsoft. Очень хорошая библиотека, но использовать ее желательно только с базами данных Microsoft, а именно MS Access или MS SQL Server. Еe также можно использовать, если у вас специфичный сервер баз данных, который может работать только через ODBC.

Выбор и обоснование инструментальных средств обработки

Для создания своего проекта была выбрана среда программирования C++ Builder.C++ Builder представляет собой SDI-приложение, главное окно которого содержит настраиваемую инструментальную панель (слева) и палитру компонентов (справа). Помимо этого, по умолчанию при запуске C++ Builder появляются окно инспектора объектов (слева) и форма нового приложения (справа). Под окном формы приложения находится окно редактора кода.

Формы являются основой приложений C++ Builder. Создание пользовательского интерфейса приложения заключается в добавлении в окно формы элементов объектов C++ Builder, называемых компонентами. Компоненты C++ Builder располагаются на палитре компонентов, выполненной в виде многостраничного блокнота. Важная особенность C++ Builder состоит в том, что он позволяет создавать собственные компоненты и настраивать палитру компонентов, а также создавать различные версии палитры компонентов для разных проектов. ++ Builder первоначально создавалась только для платформы MicrosoftWindows. Поздние версии, содержащие Кроссплатформенную компонентную библиотеку Borland, поддерживают и Windows и Linux.

В 2003 Borland выпустила C++ BuilderX (CBX), написанный при помощи той же инфраструктуры, что и JBuilder, который при этом был мало похож на C++ Builder или Delphi. Этот продукт предназначался для разработки больших программ для крупных предприятий, но коммерческого успеха не достиг. В конце 2004 года Borland объявила, что продолжит развитие классического C++ Builder и объединит его со средой разработки Delphi, прекратив, таким образом, разработку C++ BuilderX.

Спустя примерно год после этого объявления, Borland выпустила BorlandDeveloperStudio 2006, который включал в себя Borland C++ Builder 2006, предлагавший улучшенное управление конфигурацией и отладкой. BorlandDeveloperStudio 2006 - единственный полноценный комплект, содержащий Delphi, C++Builder и C#Builder.

Используя Borland C++ Builder, можно создать приложения, работающие как с однопользовательскими базами данных (БД), так и с серверными системами управления базами данных (СУБД), такими как Oracle, Sybase, Informix, Interbase, MS SQL Server, DB2, а также с ODBC-источниками. Возможности C++ Builder, связанные с созданием приложений, использующих базы данных, весьма обширны для того, чтобы описать их в одной статье. Поэтому сегодня мы рассмотрим лишь простейшие возможности работы с таблицами баз данных.

Набор данных в C++ Builder является потомком абстрактного класса TDataSet (абстрактный класс - это класс, от которого можно порождать другие классы, но нельзя создать экземпляр объекта данного класса). Например, классы TQuery, TTable и TStoredProc, содержащиеся на странице палитры компонентов Data Access, - наследники TDBDataSet, который, в свою очередь, является наследником TDataSet. TDataSet содержит абстракции, необходимые для непосредственного управления таблицами или запросами, обеспечивая средства для того, чтобы открыть таблицу или выполнить запрос и перемещаться по строкам.

В типичных приложениях с базами данных компонент DataSource, как правило, связан с одним компоненом TDataSet (TTable или TQuery) и с одним или более компонентами Data Controls (такими, как DBGrid, DBEdit и др.). Связь этого компонента с компонентами TDataSet и DataControls осуществляется с использованием следующих свойств и событий:

? Cвойство DataSet компонента DataSource идентифицирует имя компонента TDataSet. Можно присвоить значение свойству DataSet на этапе выполнения или с помощью инспектора объектов на этапе проектирования.

? Cвойство Enabled компонента DataSource активизирует или останавливает взаимосвязь между компонентами TDataSource и Data Controls. Если значение свойства Enabled равно true, то компоненты Data Controls, связанные с TDataSource, воспринимают изменения набора данных. Использование свойства Enabled позволяет временно разъединять визуальные компоненты Data Controls и TDataSource, например, для того, чтобы в случае поиска в таблице с большим количеством записей не отображать на экране пролистывание всей таблицы.

? Свойство AutoEdit компонента DataSource контролирует, как инициируется редактирование в компонентах Data Controls. Если значение свойства AutoEdit равно true, то режим редактирования начинается непосредственно при получении фокуса компонентом Data Controls, связанным с данным компонентом TDataSet. В противном случае режим редактирования начинается, когда вызывается метод Edit компонента TDataSet, например, после нажатия пользователем кнопки Edit на компоненте DBNavigator. Событие OnDataChange компонента DataSource наступает, когда происходит изменение значения поля, записи, таблицы, запроса.

2. ОСНОВНАЯ ЧАСТЬ. ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ

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

Разработать программное обеспечение средств автоматизации ресторанного бизнеса на C++ Builder.

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

программный автоматизация ресторанный

2.2 Руководство программисту

1.Цель: разработать программное обеспечение средств автоматизации ресторанного бизнеса.

2.Язык программирования: C++ Builder.

3.Утилита для создания структуры базы данных: Borland Database Desktop 7.0.

4.Движок баз данных: Borland Database Engine 5.0.

5.Тип базы данных: локальная.

6.Формат СУБД: Paradox 7.

1.Основные функции системы следующие:

- составление, просмотр, изменение существующих меню, распечатка меню на любой период;

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

- внесение изменения в уже существующее меню, рецепт, список продуктов;

- составление, просмотр, изменение существующих остатков и имеющееся остатков продуктов.

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

- отображение в сравнительном отчете последней цены закупки каждого продукта.

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

3. Программа должна выполнять следующие функции:

1. Добавление информации;

2. Правка информации;

3. Вывод информации;

4. Удаление информации;

5. Поиск информации;

6. Вывод информации на печать;

4.Минимальные аппаратные требования: P1, 32 Mb ОЗУ, mouse, клавиатура, 20 Mb свободного места на жестком диске;

Минимальные системные требования: Windows 98/ME/2000/XP, для работы программы требуется наличие BDE.

2.2.1 Модули

DataModule.cpp - Модуль данных;

AddNewUser. cpp - Модуль окна изменения данных таблиц “Sotrudniki”, “Login”, “Doljnosti”;

NewTovar. cpp - Модуль окна внесения и изменения данных таблицы “Tovar”, “Sklad”;

Main. cpp - Модуль главного окна программы;

Entertosystem. cpp - Модуль окна проверки значений при входе в систему;

TovarOnSklad. cpp - Модуль окна изменения данных таблиц “Sklad”, “Tovar”;

SpisSosklada. cpp - Модуль окна внесения и изменения данных таблицы “Sklad”, “Spisanie”;

Zakaz. cpp - Модуль внесения изменений в таблицы “Sklad”, “Ingrid”, “TempZakaz”,” SaveZakaz”, “JurnalZakazov”;

JurnalProdaj cpp - Модуль внесения, просмотра данных таблицы “JurnalProdaj”;

JurnalSpisaniy. cpp - Модуль внесения, просмотра данных таблицы “Spisanie”

Report. cpp - Модуль вывода отчётов;

datamodule.CPP

Компоненты:

DSLogin:: TdataSource - Компонент связи набора данных с компонентом;

TableLogin:: Ttable - Таблица;

DSDoljnosti:: TDataSource- Компонент связи набора данных с компонентом;

TableDoljnosti:: TTable - Таблица;

DsPostavshiki:: TDataSource- Компонент связи набора данных с компонентом;

TablePostavshiki:: TTable - Таблица;

DsSklad:: TdataSource- Компонент связи набора данных с компонентом;

DsSpis:: TDataSource- Компонент связи набора данных с компонентом;

TableSklad:: TTable - Таблица;

TableSpis:: TTable - Таблица;

DsQuery:: TDataSource- Компонент связи набора данных с компонентом;

Query:: Tquery - Компонент, связи с запросом SQL;

DsTovar: TDataSource- Компонент связи набора данных с компонентом;

TableTovar:: TTable - Таблица;

DSSotrudniki:: TdataSource - Компонент связи набора данных с компонентом;

TableSotrudniki:: TTable; - Таблица;

Query1:: TQuery - Компонент, связи с запросом SQL;

DSQuery1:: TDataSource - Компонент связи набора данных с компонентом;

DSQuery2:: TDataSource - Компонент связи набора данных с компонентом;

Query2:: TQuery - Компонент, связи с запросом SQL;

DSTempZakaz:: TDataSource TDataSource - Компонент связи набора данных с компонентом;

TableTempZakaz:: Ttable - Таблица;

DataSource1:: TDataSource TDataSource - Компонент связи набора данных с компонентом;

DSSaveZakaz:: TDataSource - Компонент связи набора данных с компонентом;

TableSaveZakaz:: TTable - Таблица;

dsJurnalZakazov:: TDataSource - Компонент связи набора данных с компонентом;

TableJurnalZakazov:: TTable - Таблица;

ADDNEWUSER.CPP

Функции:

btnAddNewUserClick(TObject *Sender) - Щелчок на кнопке;

procedure btnCancelClick(TObject *Sender) - Щелчок на кнопке;

FormClose(TObject *Sender) - Закрытие формы;

FormShow(TObject *Sender) - Отображение формы;

Button3Click(TObject *Sender) - Щелчок на кнопке;

DBGrid1CellClick(TObject *Sender) - Щелчок на ячейке сетки;

CbFamSotrClick(TObject *Sender) - Щелчок по выпадающему списку;

CbLoginClick(TObject *Sender) - Щелчок по выпадающему списку;

btnNewPassClick(TObject *Sender) - Щелчок на кнопке;

btnPostClick(TObject *Sender) - Щелчок на кнопке;

BitBtn3Click(TObject *Sender) - Щелчок на кнопке;

BitBtn2Click(TObject *Sender) - Щелчок на кнопке;

FormKeyDown(TObject *Sender) - Событие нажатия клавиши на форме;

Glav.CPP

Функции:

EnterToSystemClick(TObject *Sender) - Щелчок по кнопке;

AddLoginClick(TObject *Sender) - Щелчок по кнопке;

UsersClick(TObject *Sender) - Щелчок по пункту меню;

FormCreate TObject *Sender) - Создание формы;

FormClose(TObject *Sender) - Закрытие формы;

N7Click(TObject *Sender) - Выбор пункта меню;

N9Click(TObject *Sender) - Выбор пункта меню;

N11Click(TObject *Sender) - Выбор пункта меню;

N12Click(TObject *Sender) - Выбор пункта меню;

N3Click(TObject *Sender) - Выбор пункта меню;

N5Click(TObject *Sender) - Выбор пункта меню;

N14Click(TObject *Sender) - Выбор пункта меню;

ChangeUserClick(TObject *Sender) - Выбор пункта меню;

ExitClick(TObject *Sender) - Выбор пункта меню;

N15Click(TObject *Sender) - Выбор пункта меню;

FormShow(TObject *Sender) - Отображение формы;

N10Click(TObject *Sender) - Выбор пункта меню.

OpenTable(TObject *Sender) -Прописывание алиаса к базе данных.

Entertosystem.СPP

Функции

FormClose(TObject *Sender) - Закрытие формы;

btnCancelClick(TObject *Sender) - Щелчок на кнопке;

btnEnterClick(TObject *Sender) - Щелчок на кнопке;

...