База данных «Программируемые интегральные логические схемы»

Автор работы: Пользователь скрыл имя, 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 стр.

Прикрепленные файлы: 1 файл

КУРСАЧ_БД.doc

— 997.00 Кб (Скачать документ)

 

  1. Код заказа, тип à Количество,
  2. Тип, дата поставки à Количество.

 

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

 

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

 

  1. Код потребителя à ФИО, контактный телефон.
  2. Тип à фирма-изготовитель, задержка, число выводов, число связей, термы произведений, технология, особенности, цена.
  3. Код заказа, тип àколичество.
  4. Код заказа à код потребителя, дата выдачи,
  5. Тип, дата поставки à количество.

 

Все отношения находятся в третьей  нормальной форме. В них отсутствуют  транзитивные зависимости.

 

Усиленная третья нормальная форма (Нормальная форма «Бойса-Кодда»). Если отношение удовлетворяет третьей нормальной форме и в нем имеется несколько потенциальных ключей связанных функционально с атрибутами, тогда между ними существует функциональные зависимости. Для их устранения необходимо привести отношение к усиленной третьей нормальной форме. Отношение находится в усиленной нормальной форме, если в нем детерминанты и ключи совпадают. Как видно из предыдущего пункта детерминанты всех функциональных зависимостей являются ключами в отношениях. Следовательно, все отношения находятся в усиленной третьей нормальной форме или нормальной форме «Бойса-Кодда».

Методами «Сущность-Связь» и нормализация отношений определили набор и  структуру отношений будущей  базы данных.

 

 

Физическое проектирование базы данных:

 

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

 

Таблица «ПЛИС»:

    • Тип: тип поля - текстовый, размер 32 символа.
    • ФирмаИзготовитель: тип поля – текстовый, размер 32 символа.
    • Задержка: тип поля – числовой, целое.
    • Число выводов: тип поля – числовой, целое.
    • Число связей: тип поля – числовой, целое.
    • ТермыПроизведений: тип поля – числовой, длинное целое.
    • Технология: тип поля - текстовый, размер 16 символов.
    • Особенности: тип поля – MEMO.
    • Цена: тип поля – денежный, число десятичных знаков – 2.

 

Рис.1.   Конструктор таблицы «ПЛИС».

 

 

 

Ключом таблицы является поле «Тип».

 

Таблица «Заказано»:

    • Код заказа: тип поля – числовой, целое.
    • Тип: тип поля - текстовый, размер 32 символа.
    • Количество: тип поля – числовой, целое.

 

Рис.2.   Конструктор таблицы «Заказано».

 

В данном случае ключ таблицы составной, состоит из полей «КодЗаказа» и «Тип».

 

 

 

Таблица «Заказы»:

    • Код заказа: тип поля – числовой, целое.
    • КодПотребителя: тип поля – числовой, длинное целое.
    • ДатаВыдычи: тип поля – дата/время, краткий формат даты.

 

Рис.3.   Конструктор таблицы «Заказы».

 

Ключом таблицы является поле «КодЗаказа».

 

Таблица «Потребители»:

    • КодПотребителя: тип поля – числовой, длинное целое.
    • ФИО: тип поля – текстовый, размер 32 символа.
    • Телефон: тип поля – текстовый, размер 14 символов,

маска ввода \(000\)000\-00\-00;;#.

 

Рис.4.   Конструктор таблицы «Потребители».

 

Ключом таблицы является поле «КодПотребителя».

 

Таблица «Поставки»:

    • Тип: тип поля - текстовый, размер 32 символа.
    • ДатаПоставки: тип поля – дата/время, краткий формат даты.
    • Количество: тип поля – числовой, целое.

 

Рис.5.   Конструктор таблицы «Поставки».

 

Ключом таблицы являются поля «ДатаПоставки» и «Тип».

 

Схема данных:

 

Рис.6. Схема данных БД «Программируемые Интегральные Логические Микросхемы».

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Основные характеристики используемой СУБД.

Система MS Access обладает рядом уникальных возможностей:

 

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

 

СУБД  Access относится к реляционной  модели данных (от англ. Relation- “отношение”). Реляционная база данных представляет  собой набор связанных таблиц.

 

Любая СУБД позволяет выполнить  следующие операции с данными:

• Добавление записей в таблицу;

• Удаление записей из таблицы;

• Изменение значений некоторых  полей в записях;

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

 

Для выполнения этих операций создаются  запросы. Для формулирования запросов к базе данных был создан специальный  язык – язык структурированных запросов. (SQL – Structured Query Language).

Для предоставления  информации в  удобном для пользователя виде создают формы.

 

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

Для разработки приложений MS Access может использоваться язык Visual Basic for Application (VBA) с добавлениями объектных  расширений и языка структурированных запросов SQL. Как правило, профессиональное создание  приложений MS Access требует применения VBA.

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

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

 

 

 

Создание запросов

 

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

 

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 ЗапросЗаказано.Тип, 

(ЗапросПоставлено.Поставлено-ЗапросЗаказано.Заказано) AS Остаток

FROM ЗапросЗаказано, ЗапросПоставлено

WHERE ЗапросЗаказано.Тип=ЗапросПоставлено.Тип;

 

 

 

  1. Вывод сведений о ПЛИС с числом программируемых связей не менее  … и с определенной технологией изготовления.

 

SQL-код запроса «ЗапросЧислСвяз&Техн»:

 

SELECT ПЛИС.*

FROM ПЛИС

WHERE (((ПЛИС.ЧислоСвязей)>=[Число программируемых  связей не менее]) AND ((ПЛИС.Технология)=[Технология изготовления]));

 

Рис.7.   Конструктор запроса «ЗапросЧислСвяз&Техн».

 

В ходе выполнения запроса пользователю выводится вся информация о характеристиках  ПЛИС, попадающих под введенные параметры  поиска.

 

 

Результат выполнения запроса «ЗапросЧислСвяз&Техн»

 

Рис.8.   Конструктор запроса «ЗапросЧислСвяз&Техн».

 

  1. Вывод сведений о ПЛИС с числом программируемых связей […] временем задержки распространения сигнала не более […]

 

 SQL-код запроса «ЗапросЧислСвяз&Задержка»:

 

SELECT ПЛИС.*

FROM ПЛИС

WHERE ЧислоСвязей=[Число программируемых  связей]

AND Задержка<=[Время задержки распространения  сигнала не более, нс];

 

 

Рис.9.   Конструктор запроса «ЗапросЧислСвяз&Задержка».

 

В ходе выполнения запроса пользователю выводится вся информация о характеристиках ПЛИС, попадающих под введенные параметры поиска.

 

 

Результат выполнения запроса «ЗапросЧислСвяз&Задержка»

 

Рис.10.   Конструктор запроса  «ЗапросЧислСвяз&Задержка».

 

  1. Вывод дополнительных сведений микросхемы ПЛИС типа …,

 

SQL-код запроса «ПЛИС&Особенности»:

 

SELECT ПЛИС.Тип, ПЛИС.Особенности

FROM ПЛИС

WHERE (((ПЛИС.Тип)=[Введите тип]));

 

 

Рис.11.   Конструктор запроса «ПЛИС&Особенности».

 

Результат выполнения запроса «ПЛИС&Особенности»

 

 

Рис.12.   Конструктор запроса  «ПЛИС&Особенности».

 

 

 

 

 

 

  1. Вывод сведений о суммарной стоимости имеющихся на складе микросхем типа …

 

SQL-код запроса «ЗапросТип&ЦенаОбщ»:

 

SELECT ЗапросОстаток.Тип, (ЗапросОстаток.Остаток)*ПЛИС.Цена AS [Сумма,руб]

FROM ПЛИС INNER JOIN ЗапросОстаток ON ПЛИС.Тип  = ЗапросОстаток.Тип

WHERE (((ЗапросОстаток.Тип)=[Тип ПЛИС]));

 

Рис.13.   Конструктор запроса «ЗапросТип&ЦенаОбщ».

 

В ходе выполнения запроса пользователю выводится информация о типе ПЛИС и суммарной стоимости ПЛИС данного типа, имеющихся на складе.

 

Рис.14.   Конструктор запроса «ЗапросТип&ЦенаОбщ».

 

  1. Вывод сведений о количестве имеющихся на складе микросхем определенной фирмы – производителя ...

 

SQL-код запроса «ЗапросОстаток&Фирма»:

 

SELECT ПЛИС.ФирмаИзготовитель, Sum(ЗапросОстаток.Остаток) AS Остаток

FROM ЗапросОстаток INNER JOIN ПЛИС ON ЗапросОстаток.Тип = ПЛИС.Тип

WHERE (((ПЛИС.ФирмаИзготовитель)=[Изготовитель]))

GROUP BY ПЛИС.ФирмаИзготовитель;

 

Рис.15.   Конструктор запроса «ЗапросОстаток&Фирма».

 

В ходе выполнения запроса пользователю выводится информация о типе ПЛИС и количестве ПЛИС данного типа, имеющихся на складе.

 

Рис.16.   Конструктор запроса  «ЗапросОстаток&Фирма».

 

Создание отчетов

 

Создание отчета о выдаче ПЛИС со склада потребителям за определенный период с группировкой по кодам потребителей и сортировкой по типам микросхем.

 

Данный отчет будет основываться на запроса, выводящем сведения о коде потребителя, типе ПЛИС, выданном количестве,и дате выдачи.

 

SQL-код запроса «ЗапросПродажиЗаПериод»:

 

SELECT Заказы.КодПотребителя, Заказано.Тип,  Заказано.Количество, Заказы.ДатаВыдачи AS [Дата выдачи]

FROM Заказы INNER JOIN Заказано ON Заказы.КодЗаказ = Заказано.КодЗаказ

WHERE (((Заказы.ДатаВыдачи)>[Начало  периода] 

AND (Заказы.ДатаВыдачи)<[Конец периода]));

 

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

 

Рис.17. Конструктор отчета «ОтчетОПродажах».

Информация о работе База данных «Программируемые интегральные логические схемы»