Базы данных (стр. 1 )

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

ВОЛГОГРАДСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

КАМЫШИНСКИЙ ТЕХНОЛОГИЧЕСКИЙ ИНСТИТУТ (ФИЛИАЛ)

ВОЛГОГРАДСКОГО ГОСУДАРСТВЕННОГО ТЕХНИЧЕСКОГО УНИВЕРСИТЕТА

КАФЕДРА «ИНФОРМАТИКА»

Базы данных

Методические указания к практическим занятиям

РПК «Политехник»

Волгоград

2007 г

УДК 00

Б 17

Базы данных: Методические указания к практическим занятиям / Сост. , ; Волгоград. гос. техн. ун-т. – Волгоград, 2007. – 50 с.

Приведены теоретические и практические сведения по СУБД FoxPro 6.0. Охвачены все разделы проектирования базы данных конкретной предметной области, предусмотренные образовательными стандартами по специальности 230103.51 "Автоматизированные системы обработки информации и управления (по отраслям)". Предназначены для студентов СПО.

Ил. 24. Табл. 7. Библиогр.: 3 назв.

Рецензент:

Печатается по решению редакционно-издательского совета

Волгоградского государственного технического университета

Составители: Тамара Мухамедовна Мартиросова, Денис Васильевич Медведев

Базы данных

Методические указания к практическим занятиям

Под редакцией авторов

Темплан 2007 г., поз. № 33.

Подписано в печать г. Формат 60×84 1/16.

Бумага листовая. Печать офсетная.

Усл. печ. л. 3,13. Усл. авт. л. 3,0.

Тираж 100 экз. Заказ №

Волгоградский государственный технический университет

400131 Волгоград, просп. им. , 28.

РПК «Политехник»

Волгоградского государственного технического университета

400131 Волгоград, ул. Советская, 35.

Ó Волгоградский

государственный

технический

университет, 2007

1. ПРЕДИСЛОВИЕ

Данные методические указания предназначены для проведения практических занятий по дисциплине “Базы данных” в соответствии со стандартом по специальности 2202 "Автоматизированные системы обработки информации и управления в промышленности" и рабочего учебного плана. Результатом выполненных практических работ является курсовой проект, состоящий из разработанной студентом информационной системы и пояснительной записки к ней.

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

-  закрепление знаний, полученных ранее по дисциплине “Базы данных”;

-  привитие практических навыков применения норм проекти-рования, методик расчётов, типовых проектов, стандартов и других нормативных материалов.

В методических указаниях рассматриваются вопросы, касающиеся разработки и создания баз данных. Рассматривается самая популярная СУБД - Microsoft Visual FoxPro 6.0 и примеры лучшего ее применения при проектировании и создании баз данных. Рассматриваются многие функции и возможности Microsoft Visual FoxPro 6.0, которые могут быть использованы в повседневной практике. Практическая работа №1 посвящена обсуждению вопросов концептуального проектирования. В ней рассматриваются традиционные базовые вопросы: объекты, отношения, атрибуты. Концептуальное проектирование является основой подхода к проектированию реляционных баз данных. Практическая работа №2 посвящена реляционной модели данных и ее использованию в проектировании реляционной модели баз данных. Определяются конструкции модели, обсуждается процесс нормализации таблиц. Рассматривается вопрос преобразования концептуальной модели данных в реляционную модель. В практической работе №3 студентам предстоит приобрести навыки работы с формами и методами ее создания. Практическая работа № 4 посвящена вопросам созданию запросов к базе данных, рассматривается возможности создания запроса QUERY-BY-EXAMPLE (запросы по образцу) и его применение в конкретной коммерческой системе. В практической работе № 5 рассматриваются средства Visual FoxPro 6.0, предназначенные для создания отчетов: конструктор отчетов, мастер отчетов. Рассмотрены вопросы создания табличного отчета и отчета в свободной форме. Практическая работа № 6 предназначена для изучения специфического объекта БД называемого отчет. Отчеты формируются для анализа информации при решении конкретной экономической задачи. Отчеты - традиционная форма представления информации для управления. Отчеты выводятся на экран, принтер или файл для передачи по каналам связи, размещаются на WEB-серверах. Практическая работа № 7. Обычно законченное приложение имеет свое собственное меню, которое заменяет основное меню Visual FoxPro 6.0и содержит команды, предназначенные для выполнения конкретных задач. В работе рассматривается использование конструкто-ра меню для создания приложения, а также команды Visual FoxPro 6.0, позволяющее создавать меню приложения в кратчайшие сроки. Практическая работа № 8 посвящена вопросу написания пояснительной записки к курсовому проекту.

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

2. ПРАВИЛА ВЫПОЛНЕНИЯ ПРАКТИЧЕСКИХ РАБОТ

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

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

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

4.  Сохранять создаваемые файлы только в своей папке на сервере. Например, для студентки академической группы КАС-051 Пышненко путь к личной папке следующий:

S (СТФ на “Fileserver”):\КАС051\ Пышненко.

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

6.  Соблюдать технику безопасности.

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

3. ОПИСАНИЕ РАБОЧЕГО МЕСТА

Для выполнения практических работ необходимо:

1)  аппаратное обеспечение – персональный компьютер семейства IBM модели Pentium с минимальной комплектацией;

2)  программное обеспечение – операционная система Windows XP, электронная таблица Microsoft Visual FoxPro 6.0;

3)  методическое обеспечение – методические указания к практи-ческим работам «”Базы данных” Методические указания к практическим занятиям».

4. ПРАКТИЧЕСКие РАБОТЫ

4.1Практическая работа №1

Тема: Концептуальное проектирование базы данных.

Цель практической работы

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

После выполнения практической работы студент должен:

Знать: назначение концептуальной схемы в проектировании БД, ”, методы создания схемы, рассмотреть пример создания концептуальной схемы с помощью модели “сущность-связь.

Уметь: создать концептуальную схему для простейшей задачи.

Время выполнения – 2 часа.

Пояснения к работе

Порядок выполнения практической работы:

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

2. Выполнить задание, спроектировав концептуальную схему БД по своему индивидуальному варианту.

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

Предварительная подготовка

Трехуровневая архитектура БД.

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

Рис. 1. Трехуровневая архитектура БД.

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

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

Отсюда можно вывести концептуальную логическую схему (модель) БД.

Концептуальный уровень –определяет логическую схему БД.

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

Концептуальная модель данных.

С начала 70-х годов было предложено несколько концептуальных моделей данных. Например, двоичная семантическая модель данных, категорно-относительная модель Чена, функциональная модель данных, семантическая модель данных Хаммера и Мак Леода.

Концептуальная модель БД легко преобразуется в реальные модели. (см. рис. 2)

Рис. 2 Преобразование концептуальной модели в реализуемую.

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

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

2.  сложность модели для изучения пользователем;

3.  наглядность структуры данных;

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

Создание концептуальную модель БД рассмотрим на примере модели ”сущность-связь”. Ее отличает относительная простота, приме-нение естественного языка, легкость понимания.

Модель “сущность – связь”.

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

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

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

Атрибут – это поименованная характеристика объекта или сущ-ности, которая принимает значение из некоторого множества значений.

Например: книга – объект. Атрибуты - название, автор и т. д.

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

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

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

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

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

Два или более элементов модели идентичны, если имеют одинаковое смысловое значение.

Агрегация позволяет рассматривать связь между элементами модели как новый элемент (например, экзамен {фам_студента, наз_дисциплины, ФИО_препод, оценка}

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

Проектирование схемы БД “Ресторан”

Проектирование базы данных «Ресторан». Будет производиться на основе описания реального объекта – ресторана.

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

Исходя, из этих вопросов выделяются объекты предметной области, о которых нужно собрать информацию в БД. Это следующие объекты: Персонал, Заказ, Блюдо, Склад. Объекты также можно выделить исходя из тех форм, которые циркулируют в той или иной предметной области. Мы не можем опереться на этот подход, так как у нас форм нет. Составляем концептуальную модель данных, объекты на ней представ-ляем в виде прямоугольников, свойства объектов в виде овалов. Вид модели представлен на рис. 3.

В представленной схеме модели данных показано, как объекты связаны друг с другом. Объекты представлены квадратами, а отношения между ними отрезками. Символы «1» и «*» обозначают как именно они взаимодействуют.

·  Отношения между объектами Персонал и Заказ(один ко многим): Каждый Служащий(официант) может выполнять один или нескольких Заказов (*).

·  Каждый Заказ может состоять из одного или нескольких блюд (*).Отношение между объектом Заказ и Блюдо(один ко многим).

·  Каждое блюдо может иметь несколько ингредиентов(*).

Мы видим тип отношений: один-ко-многим, существует еще один тип отношения не представленный на схеме. Это отношение один-к-одному.

Задания

В соответствии с индивидуальным вариантом создайте концептуальную схему базы данных.

Примерные варианты индивидуальных заданий:

 

Рис. 3 . Концептуальная схема базы данных “Ресторан”

Таблица 1

№	Подсистема	Объекты и их характеристики	Запросы	Отчеты
1	«Кадры предприятия»	Работник: таб. номер, ФИО, дата рождения, адрес, должность, дата принятия, дата увольнения; Цех:номер, наименование, ФИО начальника, число бригад, количество рабочих в бригаде; Бригада:номер, наименование, цех, ФИО бригадира, план, факт.	1.  Состав бригад по стажу работы; 2.  ФИО и адреса бригадиров; 3.  ФИО и адреса начальников цехов; 4.  ФИО работников, выходящих в этом году на пенсию.	1.  Список работников ,поступивших на предприятие в течение последнего месяца; 2.  ФИО работников, уходящих в текущем месяце в отпуск.
2	«Материально-техническое снабжение»	Товар: наименование, шифр, ед. измерения; Движение: товар, поставщик, получатель, количество; Получатель:шифр, наименование, № счета.	1.  Ведомость наличия товара на складе на i - е число; 2.  Список поставщиков; 3.  Список получателей.	1.  Ведомость прихода; 2.  Ведомость расхода.

Порядок отчета практической работы

При отчете практической работы необходимо:

1)  Продемонстрировать выполненные задания по индивидуальному варианту, прокомментировать порядок его выполнения и объяснить полученные результаты

2)  Ответить на контрольные вопросы.

Контрольные вопросы

1)  Перечислите основные этапы проектирования БД?

2)  Определите соотношение понятия “сущность”, “связь”?

3)  В чем заключается концептуальное проектирование для конкретной предметной области?

4.2 Практическая работа №2

Тема: Реляционная модель базы данных.

Цель практической работы

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

После выполнения практической работы студент должен:

Знать: назначение реляционной модели данных в проектировании БД, рассмотреть пример создания реляционной модели путем.

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

Время выполнения – 2 часа.

Пояснения к работе

Порядок выполнения практической работы:

1. Проработать все описанные упражнения самостоятельно.

2. Выполнить индивидуальное задание, руководствуясь методическими указаниями.

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

Предварительная подготовка

Создание реляционной БД и процесс нормализации таблиц.

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

Таблица состоит из строк и столбцов и имеет уникальное имя в базе данных. База данных содержит множество таблиц, связь между которыми устанавливается с помощью совпадающих полей. В каждой из таблиц содержится информация о каком-либо объекте одного типа(группы). Каждая запись в таблице идентифицирует один объект группы. В качес-тве идентификационного признака используется первичный ключ. Ключ (Первичный ключ) таблицы – это атрибут или набор атрибутов, одно-значно определяющий каждую строку реляционной таблицы. Отношение между объектами определяет отношение между таблицами. Visual FoxPro поддерживает четыре типа отношений между таблицами: один-к-одному, один-ко-многим, много-к-одному, много-ко-многим.

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

Проектирование нормализованных баз данных.

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

§  Обеспечить быстрый доступ к данным в таблицах.

§  Исключить ненужное повторение данных.

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

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

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

Персонал{ФИО, адрес, телефон, год рождения, должность, оклад, паспортные данные}

Заказ{код заказа, дата заказа, блюдо, порции, Фио}

Внешний ключ ФИО ссылается на таблицу Персонал, внешний ключ Блюдо ссылается на таблицу Блюдо.

Блюдо{Блюдо, Категория, Ингредиент, Вес}

Внешний ключ Ингредиент ссылается на таблицу склад.

Склад{Ингредиент, Вес, Цена, Количество}

Из схемы видно, что база данных ресторан состоит из четырех таблиц: Персонал, Заказ, Блюдо, Склад. Ясно, что строка таблицы персонал содержит информацию о конкретном служащем. Каждая запись таблицы идентифицирует один объект. Первичным ключом таблицы Персонал является атрибут ФИО. В таблице Заказ - первичным ключом является атрибут код заказа, в таблице Блюдо – блюдо, в таблице Склад - атрибут ингредиент. Отношение между объектами определяет отношение между таблицами.

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

После небольшого анализа легко видеть что, реляционные таблицы спроектированы неудачно. Например, официант может выполнять несколько заказов, а в каждом заказе может быть заказано несколько блюд. В строках таблицы Заказ атрибуты: код заказа, дата заказа, ФИО официанта, наименование блюда могут иметь одно и тоже значение. Это повторение или избыточность приводит не только к потере места на диске, но может вызвать нарушение целостности данных в БД.

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

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

1.  Таблица не должна иметь повторяющихся записей.

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

3.  Строки и столбцы должны быть не упорядочены.

Выше перечисленные таблицы удовлетворяют этим требованиям.

О таблице говорят, что она находится во второй нормальной форме, если:

1.  Она удовлетворяет условиям первой нормальной формы.

2.  Любое неключевое поле однозначно идентифицируется полным набором ключевых полей.

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

Рис. 4

Для приведения таблиц ко второй нормальной форме, разобьем таблицу Заказ на две таблицы Заказ и Заказ_Блюда. Таблицу Блюдо на две таблицы Блюдо и Состав_блюда.

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

Создание базы данных

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

Приступаем к созданию таблиц БД, в которые будет вводиться информация. Создание таблиц с помощью конструктора таблиц представляет более широкие возможности по определению создаваемых таблиц. Таблицу можно представить как реализацию объекта из нашей модели. В таблице данные расположены в виде полей и записей(столбцы и строки соответственно). Например: таблица Персонал состоит из полей ФИО, адрес, телефон, год рождения, должность, оклад, паспорт-ные данные. Поля описывают характеристики объекта, важные для проектировщика. Каждое поле таблицы характеризуется наименование, типом и шириной поля. Кроме того, в Visual FoxPro первичные ключи используются при определении отношений между таблицами. Для того, чтобы создать индекс, в конструкторе таблиц имеется вкладка Indexes. Каждый индекс имеет имя, на которое можно в дальнейшем ссылаться при упорядочивании данных. Каждый индекс имеет тип. Например, первичному ключу соответствует индекс с типом Primary. Структура созданной таблицы Персонал представленная в окне конструктора таблиц показана на рис. 5.

Рис. 5. Структура таблицы Персонал

Рис. 6. Структура таблицы Должность

Рис. 7. Структура таблицы Блюдо

Рис. 8. Структура таблицы Состав_блюда

Рис. 9. Структура таблицы Заказ

Рис. 10. Структура таблицы Заказ_блюда

Рис. 11. Структура таблицы Склад

На рис. 5-11 представлены структуры таблиц в конструкторе для рассматриваемой предметной области.

Задания

Спроектировать реляционную модель данных для своего индивиду-ального варианта

Порядок отчета практической работы

При отчете практической работы необходимо:

1)  Продемонстрировать выполненные задания по индивидуальному варианту, прокомментировать порядок его выполнения и объяснить полученные результаты

2)  Ответить на контрольные вопросы.

Контрольные вопросы

Дайте определение реляционной модели и назовите ее элементы? Приведите математическое описание понятия отношения? Что представляет собой первичный ключ отношения, для чего он задается?

4.3 Практическая работа №3

Тема: Проектирование форм базы данных.

Цель практической работы

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

После выполнения практической работы студент должен:

Знать: назначение форм в проектировании БД, рассмотреть пример создания формы однотабличной для классификатора, многотабличной для ввода оперативной информации.

Уметь: создавать формы с помощью мастера, с помощью конструктора.

Время выполнения - 2 часа.

Пояснения к работе

Порядок выполнения практической работы:

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

2. Выполнить задание, создать формы ввода информации для своего варианта.

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

Предварительная подготовка

Формы

Существует два формата отображения содержимого таблицы – в виде таблицы и в виде формы. Формы являются мощным и гибким средством представления информации. Например, при разработке законченного приложения по бухгалтерии можно создать ряд форм, которые будут выглядеть на экране монитора точно так же, как стандартные бланки бухгалтерских документов. Макет формы строится из элементов управления, расположенных на Панели элементов(Form Controls). Панель выводится на экран с помощью команды меню ViewàToolbars. Для формы, связанной с одной таблицей или представ-лением, область данных может иметь вид: в один столбец, ленточная, табличная. Многотабличные формы содержат одну главную и несколько подчиненных таблиц. Наиболее просто форму создать с помощью Мастера форм. При выборе полей следует руководствоваться необходи-мостью каждого выбранного поля для построения формы. Ключи связи таблиц выбираются из главной таблицы. Состав полей должен обес-печивать необходимые действия в форме. При создании многотабличной формы «главной » объявляется таблица с учетом схемы данных и специфики обработки данных через форму. Формы учитывают специи-фику информации и характер работы с данными. Так, для справочников создаются однотабличные формы, которые обеспечивают ввод и редак-тирование записей справочника. Для оперативной информации создаются формы, обеспечивающие ввод и редактирование оперативной информа-ции, автоматическое заполнение справочной информации путем ее выбора из списка возможных значений. Создаются формы, в которых обеспечивается подготовки параметров для отчета или запроса.

Создадим форму для ввода и редактирования справочника. Такие формы в нашем проекте: склад, персонал, должность, ингредиенты блюда. При создании экранной формы используют мастер или конструктор форм. Предпочтительно создать сначала стандартную форму с использованием Wizard Form(Мастера форм), а затем преобразовать ее с помощью Form Designer(Конструктор форм).

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

МАСТЕР ФОРМ – Form Wizard позволяет создать форму в виде набора полей для работы с данными одной таблицы. Основное достоинство Мастера форм заключается в создании функционально законченного элемента пользовательского приложения, который имеет все необходимые средства просмотра, поиска и редактирования данных.