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

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

 

 

 

Кафедра ССОД

 

 

 

 

 

КУРСОВАЯ РАБОТА

по дисциплине «Базы  Данных»

 

 

Задание №13

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

 

 

 

 

 

Факультет: АВТ         Преподаватель

Группа:      АИ-72         доц. Щетинин Ю.И.

Студент:    Спитченко В.М.

      Отметка  о защите:

          ________________

 

Дата защиты: «____»___________2009г.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Новосибирск

2009

Содержание

Проектирование базы данных. ………………………………………………………………….….…4 стр.

Концептуальное проектирование базы данных. ……………………………………………………. 5 стр.

Построение диаграммы «Сущность-Связь» ………………………………………………………… 5 стр.

Логическое проектирование базы данных. ……………………………………………………..……9 стр.

Нормализация отношений………………………………………………………………………...… 10 стр.

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

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

Создание запросов ………………………………………………………………………………...…18 стр.

Создание отчетов ……………………………………………………………………………….……24 стр.

Разработка интерфейса пользователя: ……………………………………………...………………26 стр.

Заключение: ……………………………………………………………………………………..……35 стр.

Список используемой литературы…………………………………………………..………………36 стр.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Задание:

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

 

Сведения:

• Тип микросхемы,
• Фирма – изготовитель,
• Время задержки распространения сигнала,
• Число выводов,
• Число программируемых связей,
• Термы произведений,
• Технология,
• Дополнительные сведения (особенности ПЛИС, их использования и др.),
• Стоимость (цена),
• Дата поступления, поставщик,
• Код потребителя, ответственное лицо, телефон.
• Дата выдачи, количество и типы выданных микросхем.

 

Запросы:

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

 

Отчет:

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Введение

 

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

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

В данной работе для физического  проектирования и реализации, поддержки  и обслуживания базы данных используется система управления базами данных Microsoft Access 2007. Эта система входит в состав пакета Microsoft Office и является наиболее подходящей для первоначального знакомства с базами данных. Она содержит средства для быстрого проектирования такие как мастера, шаблоны и конструкторы. Также Microsoft Access комплектуется языком программирования высокого уровня  Visual Basic for Application, который открывает широчайший спектр как для начинающих, так и для опытных разработчиков.

 

 

 

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

 

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

 

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

 

Сущность – некоторый  объект представляющий интерес будущей  базы данных. Определим в нашем  задании все сущности:

1) ПЛИС,

2) Заказано,

3) Заказы,

4) Потребители

5) Поставки. 

Рассмотрим каждую сущность в отдельности  со своим набором атрибутов:

 

1. Сущность «ПЛИС» – это сильная сущность, т.к. её существование не зависит от другой сущности. Атрибуты данной сущности: тип, фирма-изготовитель, задержка, число выводов, число связей, термы произведений, технология, особенности, цена.

 

 

 

 

 

 

 

 

 

 

 

 

 

2. Сущность «Заказано» – это слабая сущность, её существование напрямую зависит от существования сущностей «ПЛИС» и «Заказы». Для существования связи между слабой и сильными сущностями в неё необходимо включить дополнительные общие поля, которыми являются «Тип» и «Код заказа». Атрибуты данной сущности: Тип, код заказа, количество.

 

 

 

 

 

 

 

 

 

3. Сущность «Заказы» – это слабая сущность, её существование напрямую зависит от существования сущности «Потребители». Для существования связи между слабой и сильной сущностями в неё необходимо включить дополнительное общее поле, которым является «Код заказа». Атрибуты данной сущности: Код заказа, код потребителя, дата выдачи.

 

 

 

 

 

 

 

4. Сущность «Потребители» – это сильная сущность, её существование не зависит от другой сущности. Атрибуты сущности «Потребители»:  Код потребителя, ФИО, контактный телефон.

 

 

 

 

 

5. Сущность «Поставки» – это слабая сущность, её существование напрямую зависит от существования сущности «ПЛИС». Для существования связи между слабой и сильной сущностями в неё необходимо включить дополнительное общее поле, которым является «Тип». Атрибуты данной сущности: Тип, Дата поставки, количество.

 

 

 

 

 

 

 

Между сущностями существуют связи  или отношения. Связь между сущностями выражается глаголом. Построим все  связи между полученными сущностями. Определим показатель кардинальности каждой связи и её степень. Степень  связи – количество сущностей участвующих в связи. Показатель кардинальности – количество экземпляров сущности  участвующих в определенной сущности.

 

1. «Поставки» пополняют «ПЛИС».

Это бинарная связь со степенью кардинальности  один ко многим. В связи участвуют  две сущности, и одному значению  сущности «Поставки» может соответствовать несколько значений в сущности «ПЛИС».

 

 

 

2. «ПЛИС» отбираются в «Заказано».

Это бинарная связь со степенью кардинальности  один ко многим. В связи участвуют  две сущности, и одному значению  сущности «ПЛИС» может соответствовать несколько значений в сущности «Заказано».

 

 

 

 

3. «Заказы» составляют «Заказано».

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

 

 

 

 

 

 

4. «Потребители» делают «Заказы».

 

 

 

 

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

После того как определили все сущности и связи между ними, построим  всю диаграмму «Сущность-Связь».

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
Логическое проектирование базы данных.

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

 

Для каждой сильной сущности строится отдельное отношение:

1. Сущность «Потребители». Отношение: Потребители (код потребителя, ФИО, контактный телефон);

2. Сущность «ПЛИС». Отношение ПЛИС  (тип, фирма-изготовитель, задержка, число выводов, число связей, термы произведений, технология, особенности, цена);

 

Для каждой слабой сущности создается отдельное отношение, а для существования связи добавляется общее поле.

3. Слабая сущность «Заказано».

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

Отношение Заказано  (тип, код заказа, количество);

4. Слабая сущность «Заказы». Отношение Заказы (код заказа, потребителя, дата выдачи);

5. Слабая сущность «Поставки». Отношение Заказы (тип, дата выдачи, количество);

 

На данном этапе мы определили основной набор отношений из диаграммы  «Сущность - Связь», ввели дополнительные поля в необходимые отношения для осуществления связи. В итоге получилось 6 отношения с определенным набором атрибутов.

 

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

 

Нормализация отношений

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

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

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

 

Первая нормальная форма. Отношение находится в первой нормальной форме, если в нем нет дубликатов записей и все атрибуты простые (атомарные). Дубликатов в отношении не будет, если есть ключ – он запрещает повторение записей. Во всех из четырех отношений, полученных методом «Сущность-Связь», есть простые и составные ключи. Это обеспечит нам отсутствие дубликатов. Все атрибуты данных отношений простые. Следовательно, все отношения находятся в первой нормальной форме.

 

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