Разработка АРМ "Меню"

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

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

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

 

Таблица 1 – Даталогическая модель таблицы «Типы блюд»

Название поля	Тип данных	Ключевое/неключевое
Код типа	Числовой, счетчик	Первичный ключ
Наименование	Текстовый	Неключевое

 

Таблица 2 – Даталогическая модель таблицы «Блюда»

Название поля	Тип данных	Ключевое/неключевое
Код блюда	Числовой, счетчик	Первичный ключ
Код типа	Числовой	Внешний ключ
Наименование блюда	Текстовый	Неключевое
Состав	Текстовый	Неключевое

 

Таблица 3 – Даталогическая модель таблицы «Меню»

Название поля	Тип данных	Ключевое/неключевое
Код записи	Числовой, счетчик	Первичный ключ
Код блюда	Числовой	Внешний ключ
Выод (гр)	Текстовый	Неключевое
Цена (тг)	Текстовый	Неключевое

 

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

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

Атрибут – поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, цвет может быть определен для многих сущностей: собака, автомобиль, дым и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности автомобиль являются тип, марка, номерной знак, цвет и т.д. Здесь также существует различие между типом и экземпляром. Тип атрибута цвет имеет много экземпляров или значений: красный, синий, банановый, белая ночь и так далее, однако каждому экземпляру сущности присваивается только одно значение атрибута. Абсолютное различие между типами сущностей и атрибутами отсутствует. Атрибут является таковым только в связи с типом сущности. В другом контексте атрибут может выступать как самостоятельная сущность. Например, для автомобильного завода цвет – это только атрибут продукта производства, а для лакокрасочной фабрики цвет – тип сущности.

Ключ – минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Для сущности Расписание. ключом является атрибут номер рейса или набор: пункт отправления, время вылета и пункт назначения (при условии, что из пункта в пункт вылетает в каждый момент времени один самолет).

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

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

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

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

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

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

• отношение – Таблица (иногда Файл),
• кортеж – Строка (иногда Запись),
• атрибут – Столбец, Поле.

При этом принимается, что "запись" означает "экземпляр  записи", а "поле" означает "имя и тип поля".

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

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

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

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

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

5. Полное информационное  содержание базы данных представляется  в виде явных значений данных  и такой метод представления  является единственным. В частности,  не существует каких-либо специальных "связей" или указателей, соединяющих одну таблицу с другой. Так, связи между строкой с БЛ = 2 таблицы "Блюда" на рис. 3.2 и строкой с ПР = 7 таблицы продукты (для приготовления Харчо нужен Рис), представляется не с помощью указателей, а благодаря существованию в таблице "Состав" строки, в которой номер блюда равен 2, а номер продукта – 7.

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

На рисунке 2 представлена инфологическая модель базы данных системы, созданной в СУБД «MS SQL Server 2000».

 

Рисунок 2 – Инфологическая модель базы данных

 

Для создания базы данных был выбран Microsoft Office Access.

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

1.2.2.1.2. РАЗРАБОТКА ИНФОРМАЦИОННОГО  ПРИЛОЖЕНИЯ ПОДСИСТЕМЫ «МЕНЮ»

 

 

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

К прикладному  программному обеспечению (application software) относятся компьютерные программы, написанные для пользователей или самими пользователями, для задания компьютеру конкретной работы.

Delphi представляет собой среду программирования. Выбор именно этой среду обуславливает два критерия:

1. Создаваемые на Delphi программы могут работать не только под управлением Windows.
2. Delphi относится к классу инструментальных средств ускоренной разработки.

Delphi имеет очень мощный язык Object Pascal. Отличие этого языка от многих других является простота семантики языка. В Delphi есть инсрументы для создания программных продуктов связанными с базой данных.

 Программный комплекс состоит из основной программы и базы данных (БД). В БД хранятся данные о блюдах и меню.

Основная программа  выполняет следующие задачи – ввод, просмотр, редактирование и удаление данных о из/в справочниках, формирование меню, вывод отчетов в MS EXCEL.

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

Формы - это строительные блоки интерфейса пользователя. Хороший  дизайн форм включает нечто большее, чем просто добавление элементов управления и программирование процедур обработки событии. Чтобы создать хорошо спроектированную форму, вы должны уяснить ее назначение, способ и время использования, а также ее связи с другими элементами программы. Кроме того в приложении может находиться несколько форм, каждая из которых будет отображаться по мере необходимости. Одни пользователи широко используют многозадачность Windows, другие предпочитают работать только с одним приложением. Необходимо помнить об этом во время разработки интерфейса пользователя (UI) Вы должны максимально реализовать все возможности Windows, чтобы пользователи с любыми навыками работы могли эффективно применять созданное вами приложение.

Проектирование форм ввода данных

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