Автор работы: Пользователь скрыл имя, 17 Июня 2013 в 13:17, курсовая работа
В данной работе для физического проектирования и реализации, поддержки и обслуживания базы данных используется система управления базами данных Microsoft Access 2007. Эта система входит в состав пакета Microsoft Office и является наиболее подходящей для первоначального знакомства с базами данных. Она содержит средства для быстрого проектирования такие как мастера, шаблоны и конструкторы. Также Microsoft Access комплектуется языком программирования высокого уровня Visual Basic for Application, который открывает широчайший спектр как для начинающих, так и для опытных разработчиков.
Проектирование базы данных. ………………………………………………………………….….…4 стр.
Концептуальное проектирование базы данных. ……………………………………………………. 5 стр.
Построение диаграммы «Сущность-Связь» ………………………………………………………… 5 стр.
Логическое проектирование базы данных. ……………………………………………………..……9 стр.
Нормализация отношений………………………………………………………………………...… 10 стр.
Физическое проектирование базы данных: ……………………………………………………...…12 стр.
Основные характеристики используемой СУБД. ………………………………………………… 17 стр.
Создание запросов ………………………………………………………………………………...…18 стр.
Создание отчетов ……………………………………………………………………………….……24 стр.
Разработка интерфейса пользователя: ……………………………………………...………………26 стр.
Заключение: ……………………………………………………………………………………..……35 стр.
Список используемой литературы…………………………………………………..………………36 стр.
Вывод: Отношение Заказано находится во второй нормальной форме, т.к. в нем прослеживается полная функциональная зависимость. Только полный набор атрибутов однозначно определяет запись.
Третья нормальная форма. Отношение находится в третьей нормальной форме, если оно удовлетворяет требованиям второй нормальной формы, и в нем отсутствуют транзитивные зависимости. Определим все функциональные зависимости во всех отношениях:
Все отношения находятся в третьей нормальной форме. В них отсутствуют транзитивные зависимости.
Усиленная третья нормальная форма (Нормальная форма «Бойса-Кодда»). Если отношение удовлетворяет третьей нормальной форме и в нем имеется несколько потенциальных ключей связанных функционально с атрибутами, тогда между ними существует функциональные зависимости. Для их устранения необходимо привести отношение к усиленной третьей нормальной форме. Отношение находится в усиленной нормальной форме, если в нем детерминанты и ключи совпадают. Как видно из предыдущего пункта детерминанты всех функциональных зависимостей являются ключами в отношениях. Следовательно, все отношения находятся в усиленной третьей нормальной форме или нормальной форме «Бойса-Кодда».
Методами «Сущность-Связь» и нормализация отношений определили набор и структуру отношений будущей базы данных.
Физическое проектирование базы данных:
На данном этапе необходимо определить типы данных и их размер для каждого отношения в соответствии с возможностями конкретно СУБД. В данной работе для физического проектирования используется реляционная СУБД MS Access. Так же необходимо определить список полей, которые впоследствии будут индексированы. В этот список войдут поля, по которым в проектируемой базе данных будут осуществляться операции поиска. Индексирование некоторых полей позволяет существенно сократить время, затрачиваемое на операции поиска данных –поиск по неиндексированному полю требует в среднем обработки половины общего количества записей в обрабатываемом поле, в то время как поиск по индексированному полю требует обработки лишь записей, где N-количество записей в обрабатываемом поле. При больших N, во втором случае время поиска составляет величину на порядки меньшую в сравнении со временем последовательного поиска.
Таблица «ПЛИС»:
Рис.1. Конструктор таблицы «ПЛИС».
Ключом таблицы является поле «Тип».
Таблица «Заказано»:
Рис.2. Конструктор таблицы «Заказано».
В данном случае ключ таблицы составной, состоит из полей «КодЗаказа» и «Тип».
Таблица «Заказы»:
Рис.3. Конструктор таблицы «Заказы».
Ключом таблицы является поле «КодЗаказа».
Таблица «Потребители»:
маска ввода \(000\)000\-00\-00;;#.
Рис.4. Конструктор таблицы «Потребители».
Ключом таблицы является поле «КодПотребителя».
Таблица «Поставки»:
Рис.5. Конструктор таблицы «Поставки».
Ключом таблицы являются поля «ДатаПоставки» и «Тип».
Схема данных:
Рис.6. Схема данных БД «Программируемые Интегральные Логические Микросхемы».
Основные характеристики используемой СУБД.
Система MS Access обладает рядом уникальных возможностей:
СУБД Access относится к реляционной модели данных (от англ. Relation- “отношение”). Реляционная база данных представляет собой набор связанных таблиц.
Любая СУБД позволяет выполнить следующие операции с данными:
• Добавление записей в таблицу;
• Удаление записей из таблицы;
• Изменение значений некоторых полей в записях;
• Поиск записей, удовлетворяющих заданному условию.
Для выполнения этих операций создаются запросы. Для формулирования запросов к базе данных был создан специальный язык – язык структурированных запросов. (SQL – Structured Query Language).
Для предоставления информации в удобном для пользователя виде создают формы.
СУБД Access включает
все необходимые
Для разработки приложений MS Access может использоваться язык Visual Basic for Application (VBA) с добавлениями объектных расширений и языка структурированных запросов SQL. Как правило, профессиональное создание приложений MS Access требует применения VBA.
Важной функцией СУБД является управление
данными, под которым понимают защиту
данных от несанкционированного доступа,
поддержку многопользовательско
Защита от несанкционированного доступа состоит в том, что каждому пользователю разрешается видеть только те данные, которые определены его правами. Средства многопользовательского доступа обеспечивают одновременную работу с таблицами множества пользователей, и при этом они не позволяют нескольким пользователям одновременно изменить одни и те же данные. Средства обеспечения целостности и согласованности данных предотвращают их некорректные изменения, то есть такие изменения, которые могут привести к нарушению целостности.
Создание запросов
1.а. Вывод сведений о типе
и количество поставленного
SQL-код запроса «ЗапросПоставлено»:
SELECT Поставки.Тип, Sum(Поставки.Количество) AS Поставлено
FROM ПЛИС INNER JOIN Поставки ON ПЛИС.Тип=Поставки.Тип
GROUP BY Поставки.Тип;
1.б. Вывод сведений о типе и количество реализованного товара.
SQL-код запроса «ЗапросЗаказано»:
SELECT Заказано.Тип, Sum(Заказано.Количество) AS Заказано
FROM ПЛИС INNER JOIN Заказано ON ПЛИС.Тип=Заказано.Тип
GROUP BY Заказано.Тип;
1.в. Вывод сведений о типе ПЛИС и остатке на складе
SQL-код запроса «ЗапросОстаток»:
SELECT ЗапросЗаказано.Тип,
(ЗапросПоставлено.Поставлено-
FROM ЗапросЗаказано, ЗапросПоставлено
WHERE ЗапросЗаказано.Тип=
SQL-код запроса «ЗапросЧислСвяз&Техн»:
SELECT ПЛИС.*
FROM ПЛИС
WHERE (((ПЛИС.ЧислоСвязей)>=[Число
Рис.7. Конструктор запроса «ЗапросЧислСвяз&Техн».
В ходе выполнения запроса пользователю выводится вся информация о характеристиках ПЛИС, попадающих под введенные параметры поиска.
Результат выполнения запроса «ЗапросЧислСвяз&Техн»
Рис.8. Конструктор запроса «ЗапросЧислСвяз&Техн».
SQL-код запроса «ЗапросЧислСвяз&Задержка»:
SELECT ПЛИС.*
FROM ПЛИС
WHERE ЧислоСвязей=[Число
AND Задержка<=[Время задержки
Рис.9. Конструктор запроса «ЗапросЧислСвяз&Задержка».
В ходе выполнения запроса пользователю выводится вся информация о характеристиках ПЛИС, попадающих под введенные параметры поиска.
Результат выполнения запроса «ЗапросЧислСвяз&
Рис.10. Конструктор запроса «ЗапросЧислСвяз&Задержка».
SQL-код запроса «ПЛИС&Особенности»:
SELECT ПЛИС.Тип, ПЛИС.Особенности
FROM ПЛИС
WHERE (((ПЛИС.Тип)=[Введите тип]));
Рис.11. Конструктор запроса «ПЛИС&Особенности».
Результат выполнения запроса «ПЛИС&Особенности»
Рис.12. Конструктор запроса «ПЛИС&Особенности».
SQL-код запроса «ЗапросТип&ЦенаОбщ»:
SELECT ЗапросОстаток.Тип, (ЗапросОстаток.Остаток)*ПЛИС.
FROM ПЛИС INNER JOIN ЗапросОстаток ON ПЛИС.Тип = ЗапросОстаток.Тип
WHERE (((ЗапросОстаток.Тип)=[Тип
Рис.13. Конструктор запроса «ЗапросТип&ЦенаОбщ».
В ходе выполнения запроса пользователю выводится информация о типе ПЛИС и суммарной стоимости ПЛИС данного типа, имеющихся на складе.
Рис.14. Конструктор запроса «ЗапросТип&ЦенаОбщ».
SQL-код запроса «ЗапросОстаток&Фирма»:
SELECT ПЛИС.ФирмаИзготовитель, Sum(ЗапросОстаток.Остаток) AS Остаток
FROM ЗапросОстаток INNER JOIN ПЛИС ON ЗапросОстаток.Тип = ПЛИС.Тип
WHERE (((ПЛИС.ФирмаИзготовитель)=[
GROUP BY ПЛИС.ФирмаИзготовитель;
Рис.15. Конструктор запроса «ЗапросОстаток&Фирма».
В ходе выполнения запроса пользователю выводится информация о типе ПЛИС и количестве ПЛИС данного типа, имеющихся на складе.
Рис.16. Конструктор запроса «ЗапросОстаток&Фирма».
Создание отчетов
Создание отчета о выдаче ПЛИС со склада потребителям за определенный период с группировкой по кодам потребителей и сортировкой по типам микросхем.
Данный отчет будет
SQL-код запроса «ЗапросПродажиЗаПериод»:
SELECT Заказы.КодПотребителя, Заказано.Тип, Заказано.Количество, Заказы.ДатаВыдачи AS [Дата выдачи]
FROM Заказы INNER JOIN Заказано ON Заказы.КодЗаказ = Заказано.КодЗаказ
WHERE (((Заказы.ДатаВыдачи)>[Начало периода]
AND (Заказы.ДатаВыдачи)<[Конец периода]));
При создании отчета так жы выполнена группировка по кодам потребителя в качестве первого уровня группировки, а так же группировка по дате выдачи в качестве второго.
Рис.17. Конструктор отчета «ОтчетОПродажах».
Информация о работе База данных «Программируемые интегральные логические схемы»