Разработка базы данных для объекта автоматизации: гомеопатическая аптека
СОДЕРЖАНИЕ: МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ИНСТИТУТ РАДИОТЕХНИКИ, ЭЛЕКТРОНИКИ И АВТОМАТИКИ (ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ) Факультет Кибернетики Кафедра ИнтеллектуальныеМОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ИНСТИТУТ
РАДИОТЕХНИКИ, ЭЛЕКТРОНИКИ И АВТОМАТИКИ
(ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ)
Факультет Кибернетики
Кафедра Интеллектуальные
технологии и системы
КУРСОВОЙ ПРОЕКТ
По дисциплине «Теория и проектирование баз данных»
Тема «Разработка базы данных для объекта автоматизации: гомеопатическая аптека »
Группа ИУ-1-98
Студент
Преподаватель доцент Чумак Б.Б.
Москва 2001
Задание на курсовой проект.
1. Провести краткий системно-комплексный анализ выбранного объекта автоматизации.
2. Разработать структуру пользовательского интерфейса автоматизированной системы.
2.1 Разработать функциональный аспект информационной страты объекта.
2.2 Разработать структуру экранных форм пользовательского интерфейса.
3. Разработать концептуальную модель базы данных (база данных должна содержать не менее 30 атрибутов)
3.1 Разработать 1 уровень структурного аспекта информационной страты объекта.
3.2 Разработать 2 уровень структурного аспекта информационной страты объекта
3.3. Разработать функционально-структурный аспект информационной страты объекта.
3.4. Провести нормализацию полученных отношений ( в учебных целях до начала нормализации ввести в одно из отношений транзитивную зависимость и во 2 отношение—множественную зависимость.) Проверить методом табло и аналитическим методом отсутствие потерь при соединении отношений, разлагаемых при нормализации.
3.5 Разработать структурно-функциональный аспект информационной страты объекта.
3.6. Провести генерацию базы данных. Привести все таблицы базы данных с их именами , имена их атрибуты, тип данных и их размер. Указать связь между наименованием информационных элементов и таблицами, между компонентами информационных элементов и именами атрибутов.
4. Провести разработку проекта в СУБД Visual Fox Pro 5.0(6.0)
(В проекте должны быть использованы все базовые классы СУБД и собственные пользовательские классы, материалы всех лабораторных работ по курсу ТПБД).
Разработать главное меню, формы ввода данных со словарями, отчеты. Разработать систему планируемых запросов. Представить их в табличной форме и в виде графиков .
Реализовать взаимодействие с текстовым редактором «Word” и электронными таблицами “Exel”.
Содержание
стр.
1. Введение …………………………………………………………… 4
2. Системно-комплексный анализ объекта автоматизации……….. 5
3. Структура пользовательского интерфейса автоматизированной системы…………………………………………………………………7
3.1. Функциональный аспект информационной страты объекта.7
3.2. Структура экранных форм пользовательского интерфейса. 9
4. Концептуальная модель базы данных…………………………….10
4.1. Первый уровень структурного аспекта информационной страты объекта…………………………………………………………10
4.2. Второй уровень структурного аспекта информационной страты объекта…………………………………………………………11
4.3. Функционально-структурный аспект информационной страты объекта…………………………………………………………13
4.4. Нормализация отношений …………………………………..14
4.5. Структурно-функциональный аспект информационной страты объекта…………………………………………………………16
4.6. Генерация базы данных……………………………………..17
5. Заключение………………………………………………………….19
Литература………………………………………………………..20
Приложение 1. Дискета с программным обеспечением
курсового проекта
1. Введение.
Целью данного курсового проекта является структурирование данных и разработка пользовательского интерфейса.
В курсовом проекте рассмотрены следующие теоретические вопросы и практические задания:
- проведен системно-комплексный анализ выбранного объекта автоматизации
- разработана структура пользовательского интерфейса автоматизированной системы
- разработан функциональный аспект информационной страты объекта
- разработана структура экранных форм пользовательского интерфейса
- разработана концептуальная модель базы данных
- разработан 1 уровень структурного аспекта информационной страты объекта
- разработан 2 уровень структурного аспекта информационной страты объекта
- разработан функционально-структурный аспект информационной страты объекта
- проведена нормализация полученных отношений (в учебных целях до начала нормализации была введена в 1 из отношений транзитивная зависимость и во 2 отношение—множественная зависимость.) Далее было проверено методом табло и аналитическим методом отсутствие потерь при соединении отношений, разлагаемых при нормализации.
- разработан структурно-функциональный аспект информационной страты объекта
- проведена разработка проекта в СУБД Visual Fox Pro 6.0
2. Системно-комплексный анализ объекта автоматизации
При системно-комплексном анализе объект автоматизации рассматривается как концептуальная модель:
, где
- информационная страта;
- материальная страта;
- энергетическая страта;
- экономическая страта;
- организационная страта.
 |
Организационная страта
:
Информационная (
) и материальная (
) страта:
1. Поток людей, обращающихся для приема на работу.
2. Поток людей, увольняющихся с работы.
3. Поток людей, направленных в торговый отдел.
4. Поток людей, увольняющихся из торгового отдела.
5. Поток информации в бухгалтерию, в том числе и о принятых работниках.
6. Контрольная информация из бухгалтерии.
7. Ответы поставщика на заказ.
8. Заказ продукции у поставщика.
9. Заказ покупателя на продукцию.
10. Ответы покупателю на заказ.
11. Информационный запрос по растениям.
12. Ответ на запрос по растениям.
13. Поток контрольной информации из торгового отдела в бухгалтерию.
Экономическая страта :
1. 
Товары от поставщика.
2. Оплаты товара поставщика.
3. Товар отпускаемый покупателю.
4. Оплата товара .
5. Денежный поток из бухгалтерии.
6. Денежный поток в бухгалтерию.
7. Налоги, выплачиваемые государству.
8. Вклады в банк.
9. Банковские дивиденды.
3. Структура пользовательского интерфейса автоматизированной системы
3.1 Функциональный аспект информационной страты объекта.
Концептуальная модель функционального аспекта информационной страты объекта автоматизации может быть записана следующим образом:
, где
- Входные вектора объекта.
- Выходные вектора объекта.
- – функции преобразования
- параметр функции преобразования (в данном курсовом проекте рассматриваться не будет).
- параметр определяет как изменяются первые 4 элемента в концептуальной модели (в данном курсовом проекте они не изменяются).
 |
Графическое представление функционального аспекта информационной страты объекта.
Рассмотрим входные вектора объекта:
= ( номер сотрудника, фамилия сотрудника, имя сотрудника, отчество сотрудника, телефон сотрудника, адрес сотрудника, должность сотрудника, оклад сотрудника ) – личная карточка сотрудника.
=( номер поставщика, фамилия поставщика, имя поставщика, отчество поставщика, телефон поставщика, адрес поставщика, состояние счета) – личная карточка поставщика.
=( номер покупателя, фамилия покупателя, имя покупателя, отчество покупателя, телефон покупателя, адрес покупателя, состояние счета) – личная карточка покупателя.
= ( номер растения, название растения, действие, применение растения, изображение растения, количество на складе, цена растения) – словарь растений.
Рассмотрим выходные вектора:
=(номер сотрудника, номер договора, дата договора, номер поставщика, растение, количество растений, цена) – договор с поставщиком.
=(номер сотрудника, номер договора, дата договора, номер покупателя, растение, количество растений, цена) – договор с покупателем.
На основании этих векторов можно выделить следующие функции объекта автоматизации:
- функции заключения нового договоров с покупателем и поставщиком.
- поиск заключенных договоров.
- редактирование договоров (только на стадии выполнения заказа).
- функции администратора базы данных – добавление, редактирование и удаление данных в словарях.
3.2. Структура экранных форм пользовательского интерфейса.
В соответствии с функциями объекта, структуру экранных форм можно представить следующим образом:
4. Концептуальная модель базы данных
Концептуальную модель базы данных можно представить следующим образом:
, где
- структурный аспект.
- функциональный аспект.
- аспект управления.
Функциональный аспект информационной страты объекта автоматизации уже рассмотрели. Структурный аспект будет разобран далее. Аспект управления в данном курсовом проекте рассматриваться не будет.
4.1. Первый уровень структурного аспекта информационной страты объекта
Рассмотрим первый уровень структурного аспекта информационной страты объекта автоматизации:
, где
- информационные элементы объекта автоматизации.
- связи между информационными элементами.
- конфигурация связей.
- параметр связи между элементами.
- параметр, определяющий изменение элементов структурного аспекта во времени.
Анализируя деятельность аптеки можно выделить следующие информационные элементы:
- Е1 – Данные по договорам.
- Е2 – Сотрудники.
- Е3 – Поставщики.
- Е4 – Покупатели.
- Е5 – Растения.
Связи между информационными элементами можно представить графически следующим образом:
 |
4.2. Второй уровень структурного аспекта информационной страты объекта.
Второй уровень структурного аспекта информационной страты объекта представляется так:
, где
- компонент информационного элемента Еi
.
- связи между еij
и еik
.
- конфигурация связей между информационными элементами.
- параметр связи между элементами еij
и еik
.
- параметр, определяющий изменение элементов структурного аспекта во времени.
Раскроем содержание информационных элементов и покажем связи между ними.
Е1 :
е11
– номер договора.
е12 – номер сотрудника.
е13 – номер клиента.
е14 – дата договора.
е15 – название растения.
е16 – количество растений.
е17 – цена растений.
Е2 :
е21
– номер сотрудника.
е22 – фамилия сотрудника.
е23 – имя сотрудника.
е24 – отчество сотрудника.
е25 – телефон сотрудника.
е26 – адрес сотрудника.
е27 – должность сотрудника.
е28 – оклад сотрудника.
Е3
:
е31 – номер поставщика.
е32 – фамилия поставщика.
е33 – имя поставщика.
е34 – отчество поставщика.
е35 – телефон поставщика.
е36 – адрес поставщика.
е37 – счет поставщика.
Е4 :
е41
– номер покупателя.
е42 – фамилия покупателя.
е43 – имя покупателя.
е44 – отчество покупателя.
е45 – телефон покупателя.
е46 – адрес покупателя.
е47 – счет покупателя.
Е5 :
е51
– номер растения.
е52 – название растения.
е53 – действие, оказываемое растением.
е54 – применение растения.
е55 – изображение растения.
е56 – количество на складе.
е57 – цена растения.
4.3. Функционально-структурный аспект информационной страты объекта
В общем виде информационную страту объекта можно представить так:
 |
Между компонентами входных векторов Хi и компонентами информационных элементов Еj должно быть однозначное соответствие. Например:
х11 = е21
х24 = е34
х36 = е46
Между компонентами выходных векторов Yj и компонентами информационных элементов Еi должно быть соответствие, которое можно сформулировать следующим образом: множество элементов еk , принадлежащих информационным элементам Еi должно быть достаточным для получения множества элементов уm векторов Yi . Например:
у11 = е12
у13 = е14
у24 = е13
4.4. Нормализация отношений
Анализ второго уровня концептуальной модели показывает, что в отношении Е1 существует множественная зависимость, поэтому его следует нормализовать. Это отношение следует представить в четвертой нормальной форме. Таким образом исходное отношение разлагается на три отношения: Е6 = (номер договора, номер сотрудника, номер клиента), Е7 = (номер договора, название растения) и Е8 = (номер договора, количество растений, цена растений):
 |
Прежде чем использовать полученные зависимости их нужно проверить на отсутствие соединения без потерь, то есть при обратном соединении отношений Е6 , Е7 , Е8 в отношение Е1 не должна пропадать или появляться новая информация. Для проверки можно использовать метод табло. Этот метод позволяет в табличной форме увидеть отсутствие соединения без потерь.
Метод табло – заполнение таблицы:
| е11 |
е12 |
е13 |
е14 |
е15 |
е16 |
е17 |
|
| Е6 |
а1 |
а2 |
а3 |
а4 |
b65 |
b66 |
b67 |
| Е7 |
а1 |
b72 |
b73 |
b74 |
а5 |
b76 |
b77 |
| Е8 |
b81 |
b82 |
b83 |
b84 |
а5 |
а6 |
а7 |
Метод табло – проверка функциональных зависимостей из Е6 :
| е11 |
е12 |
е13 |
е14 |
е15 |
е16 |
е17 |
|
| Е6 |
а1 |
а2 |
а3 |
а4 |
b65 |
b66 |
b67 |
| Е7 |
а1 |
а2 |
а3 |
а4 |
а5 |
b76 |
b77 |
| Е8 |
а1 |
а2 |
а3 |
а4 |
а5 |
а6 |
а7 |
Метод табло – проверка функциональных зависимостей из Е7 :
| е11 |
е12 |
е13 |
е14 |
е15 |
е16 |
е17 |
|
| Е6 |
а1 |
а2 |
а3 |
а4 |
а5 |
b66 |
b67 |
| Е7 |
а1 |
а2 |
а3 |
а4 |
а5 |
b76 |
b77 |
| Е8 |
а1 |
а2 |
а3 |
а4 |
а5 |
а6 |
а7 |
Метод табло – проверка функциональных зависимостей из Е8 :
| е11 |
е12 |
е13 |
е14 |
е15 |
е16 |
е17 |
|
| Е6 |
а1 |
а2 |
а3 |
а4 |
а5 |
а6 |
а7 |
| Е7 |
а1 |
а2 |
а3 |
а4 |
а5 |
а6 |
а7 |
| Е8 |
а1 |
а2 |
а3 |
а4 |
а5 |
а6 |
а7 |
Как видно из таблиц соединение отношений Е6 , Е7 и Е8 в отношение Е1 происходит без потерь.
Отношение Е2 содержит зависимость:
е21
– номер сотрудника.
е22 – фамилия сотрудника.
е23 – имя сотрудника.
е24 – отчество сотрудника.
е25 – телефон сотрудника.
е26 – адрес сотрудника.
е27 – должность сотрудника.
е28 – оклад сотрудника.
Данное отношение можно нормализовать в третью нормальную форму, то есть получить из исходного отношения Е2 отношения Е2 (е21 , е22 , е23 , е24 , е25 , е26 , е27 ) и Е2 (е23 , е28 ). Прежде чем использовать полученные отношения в дальнейшей работе следует проверить отсутствие аномалий при соединении отношений. Другим методом проверки отсутствия аномалий является аналитический метод. Для проведения проверки аналитическим методом следует задать исходную базу данных отношения Е2 .
| е21 |
е22 |
е23 |
е24 |
е25 |
е26 |
е27 |
е28 |
| 3 |
Сергеев |
Сергей |
Сергеевич |
6666666 |
г. Москва |
Менеджер |
10,00 |
| 10 |
Тимофеев |
Илья |
Петрович |
2222222 |
г. Чугуев |
Генеральный директор |
99,99 |
На основе имеющейся таблицы можно сформировать таблицы отношений Е2 и Е2
| Е2 |
Е2 |
|||||||
| е21 |
Е22 |
е23 |
е24 |
е25 |
е26 |
е27 |
е27 |
е28 |
| 3 |
Сергеев |
Сергей |
Сергеевич |
6666666 |
г. Москва |
Менеджер |
Менеджер |
10,00 |
| 10 |
Тимофеев |
Илья |
Петрович |
2222222 |
г. Чугуев |
Генеральный директор |
Генеральный директор |
99,99 |
Для проверки правильности нормализации следует выполнить естественное соединение отношений: Е2 [е27 = е27 ] Е2 = Е2 . Результат такого соединения показан в таблице:
| Е2 |
Е2 |
|||||||
|
|
е22 |
е23 |
е24 |
е25 |
е26 |
е27 |
е27 |
е28 |
| 3 |
Сергеев |
Сергей |
Сергеевич |
6666666 |
г. Москва |
Менеджер |
Менеджер |
10,00 |
| 10 |
Тимофеев |
Илья |
Петрович |
2222222 |
г. Чугуев |
Генеральный директор |
Генеральный директор |
99,99 |
е21
Анализ исходных данных показывает, что при соединении таблиц Е2 и Е2 получается исходная таблица Е2 .
4.5. Структурно-функциональный аспект информационной страты объекта
Структурно-функциональный аспект информационной страты объекта показывает взаимодействие между таблицами и формами в базе данных. Структурно-функциональный аспект представлен в следующей таблице:
| Формы |
Требуемые отношения |
| Сотрудники |
Е2 , Е2 |
| Поставщики |
Е3 |
| Покупатели |
Е4 |
| Растения |
Е5 |
| Договора покупателей |
Е4 , Е6 |
| Договора поставщиков |
Е3 , Е6 |
| Товар покупателей |
Е4 , Е7 , Е8 |
| Товар поставщиков |
Е3 , Е7 , Е8 |
4.6. Генерация базы данных
В результате генерации базы данных формируются связанные таблицы с набором атрибутов. Связь между именами таблиц и названиями отношений, а так же именами атрибутов и компонентами отношений показана в таблице:
| Компоненты отношений |
Атрибуты |
Тип |
Размер |
| Е2 – sotr |
|||
| e11 |
N_sotr |
Numeric |
5 |
| e12 |
Fam_sotr |
Character |
50 |
| e13 |
Im_sotr |
Character |
20 |
| e14 |
Othc_sotr |
Character |
20 |
| e15 |
Tel_sotr |
Numeric |
11 |
| e16 |
Adres_sotr |
Character |
80 |
| e17 |
Dolg_sotr |
Character |
20 |
| E3 – post |
|||
| e21 |
N_post |
Numeric |
5 |
| e22 |
Fam_post |
Character |
50 |
| e23 |
Im_post |
Character |
20 |
| e24 |
Otch_post |
Character |
20 |
| e25 |
Tel_post |
Numeric |
11 |
| e26 |
Adres_post |
Character |
80 |
| e27 |
Balance_post |
Numeric |
3 |
| E4 – pokyp |
|||
| e31 |
N_ pokyp |
Numeric |
5 |
| e32 |
Fam_ pokyp |
Character |
50 |
| e33 |
Im_ pokyp |
Character |
20 |
| e34 |
Otch_ pokyp |
Character |
20 |
| e35 |
Tel_ pokyp |
Numeric |
11 |
| e36 |
Adres_ pokyp |
Numeric |
80 |
| e37 |
Balance_ pokyp |
Numeric |
3 |
| E5 – rastenia |
|||
| e41 |
N_rast |
Numeric |
5 |
| e42 |
Rastenie |
Character |
30 |
| e43 |
Deistvie |
Character |
254 |
| e44 |
Priminenie |
Character |
100 |
| e45 |
Risynok |
General |
4 |
| e46 |
Kol_vo_rast |
Numeric |
5 |
| e47 |
Cena_rast |
Numeric |
4 |
| Компоненты отношений |
Атрибуты |
Тип |
Размер |
| Е6 – raspisanie |
|||
| e61 |
N_dog |
Numeric |
5 |
| e61 |
N_sotr |
Numeric |
5 |
| e61 |
N_kl |
Numeric |
5 |
| e61 |
Data_dog |
Date |
8 |
| E7 – dog |
|||
| e71 |
N_dog |
Numeric |
5 |
| e71 |
N_rast |
Numeric |
5 |
| e71 |
Kol_vo |
Numeric |
5 |
| e71 |
Cena |
Numeric |
3 |
| Е2 - dolgn |
|||
| е27 |
Dolg_sotr |
Character |
20 |
| е28 |
Oklad |
Numeric |
5;2 |
5. Заключение
Данный курсовой проект был выполнен в среде Visual Fox Pro 6.0. Эта среда позволяет пользователю быстро и точно создавать базы данных при помощи различных мастеров. Базы данных могут содержать необходимое пользователю количество таблиц. Элементами таблиц могут быть как символьные, так и графические элементы, что делает эту среду достаточно универсальной. Чтобы облегчить работу пользователя базы данных имеется мастер форм, которые, в свою очередь, очень многофункциональны, но в целом, предназначены для создания интерфейса. Также в этой среде имеются мастера, которые позволяют создать запросы, отчеты и др. Эти элементы базы данных один раз настроенные способны автоматически изменять свое значение с изменением данных.
В данной работе были рассмотрены следующие вопросы:
- освоение среды VFP60;
- выбор объекта автоматизации и его краткий системно-комплексный анализ;
- разработки структуры пользовательского интерфейса;
- разработка концептуальной модели базы данных;
- освоение методов проверки отсутствия потерь при соединении отношений, разлагаемых при нормализации.
Литература
1. Курс лекций по ТПБД 2001 год.
2. И.Ю. Баженова «Visial Fox Pro 6.0.»