Размещено на http://www.allbest.ru/

Курсовая работа

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

Автоматизация учёта выработки и реализации энергии на атомной электростанции

(название темы)

Содержание

Введение

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

1.1 Основные понятия

1.2 Методы проектирования баз данных

1.2.1 Моделирование БД методом нормальных форм

1.2.2 Моделирование БД методом ER-диаграмм

1.3 Способы создания и типы запросов к БД

2. Создание приложения для доступа к БД.

2.1 Построение модели предметной области для Автоматизации учёта выработки энергии на электростанции

2.2 Создание таблиц БД

2.3 Создание форм доступа к БД

2.4 Создание запросов к БД

2.5 Создание отчётов БД

3. Тестирование приложения

Заключение

Список использованных источников

Приложение 1. Исходный текст программы

Введение

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

обеспечивать получение общих и/или детализированных отчетов по итогам работы;

позволять легко определять тенденции изменения важнейших показателей;

обеспечивать получение информации, критической по времени, без существенных задержек;

выполнять точный и полный анализ данных.

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

Среди наиболее ярких представителей систем управления базами данных можно отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Microsoft SQL Server и Oracle, используемые в приложениях, построенных по технологии «клиент-сервер». Фактически, у любой современной СУБД существует аналог, выпускаемый другой компанией, имеющий аналогичную область применения и возможности, любое приложение способно работать со многими форматами представления данных, осуществлять экспорт и импорт данных благодаря наличию большого числа конвертеров. Общепринятыми, также, являются технологии, позволяющие использовать возможности других приложений, например, текстовых процессоров, пакетов построения графиков и т.п., и встроенные версии языков высокого уровня (чаще - диалекты SQL и/или VBA) и средства визуального программирования интерфейсов разрабатываемых приложений. Поэтому уже не имеет существенного значения на каком языке и на основе какого пакета написано конкретное приложение, и какой формат данных в нем используется. Более того, стандартом «де-факто» стала «быстрая разработка приложений» или RAD (от английского Rapid Application Development), основанная на широко декларируемом в литературе «открытом подходе», то есть необходимость и возможность использования различных прикладных программ и технологий для разработки более гибких и мощных систем обработки данных. Поэтому в одном ряду с «классическими» СУБД все чаще упоминаются языки программирования Visual Basic 4.0 и Visual C++, которые позволяют быстро создавать необходимые компоненты приложений, критичные по скорости работы, которые трудно, а иногда невозможно разработать средствами «классических» СУБД. Современный подход к управлению базами данных подразумевает также широкое использование технологии «клиент-сервер».

Таким образом, на сегодняшний день разработчик не связан рамками какого-либо конкретного пакета, а в зависимости от поставленной задачи может использовать самые разные приложения. Поэтому, более важным представляется общее направление развития СУБД и других средств разработки приложений в настоящее время. [8]

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

При проведении декомпозиции главная цель разбивается на подцели, каждая из которых в свою очередь предполагает решение некоторого ряда задач:

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

1.1 Быбор наиболее подходящего метода проектирования;

1.2 Проектирование БД в рамках избранного метода.

2. Создание приложения, выполняющего функции обновления, дополнения, удаления и поддержания целостности информации созданной базы данных;

2.1 Разработка специальных форм представления информации базы данных для пользователя.

3. Обеспечение средства для выбора и вывода на печать информации из базы данных по запросам пользователя.

3.1 Разработка различных форм запросов;

3.2 Формирование отчёта по каждому запросу с целью вывода информации на печать.

4. Создание пользовательского интерфейса для работы с разработанным приложением.

4.1 Создание меню пользователя.

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

1.1 Основные понятия

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

Логическое проектирование заключается в определении числа и структуры таблиц, формировании запросов к БД, определении типов отчетных документов, разработке алгоритмов обработки информации, создании форм для ввода и редактирования данных в базе и решении ряда других задач.

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

При проектировании структур данных для автоматизированных систем можно выделить три основных подхода:

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

2.Формулирование знаний о системе (определение типов исходных данных и их взаимосвязей) и требований к обработке данных, получение с помощью CASE-системы (системы автоматизации проектирования и разработки баз данных) готовой схемы БД или даже готовой прикладной информационной системы.

3.Структурирование информации для использования в информационной системе в процессе проведения системного анализа на основе совокупности правил и рекомендаций.

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

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

1.представление предметной области в том виде, как она реально существует;

2.как ее воспринимает человек (имеется в виду проектировщик базы данных);

3.как она может быть описана с помощью символов.

То есть говорят, что мы имеем дело с реальностью, описанием (представлением) реальности и с данными, которые отражают это представление.

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

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

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

1.исследование предметной области, изучение ее информационной структуры;

2.выявление всех фрагментов, каждый из которых характеризуется пользовательским представлением, информационными объектами и связями между ними, процессами над информационными объектами;

3.моделирование и интеграция всех представлений.

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

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

Физическое проектирование - определение особенностей хранения данных, методов доступа и т.д.

Существует два подхода к проектированию баз данных на логическом уровне: метод нормальных форм и метод ER-диаграмм (метод «сущность-связь»).

База данных - совокупность информации, включающая принципы хранения и доступа к данным, которая объединена вместе по определённым признакам. Примером базы данных может служить расписание поездов.

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

Иерархическая модель;

Сетевая модель;

Реляционная модель;

Объектно-ориентированная модель.

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

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

Для описания предметной области используют следующие понятия:

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

2. Атрибут -- это информационное отображение свойств объекта. Каждый объект характеризуется рядом основных атрибутов. Например, для описания свойств объекта КНИГА можно использовать атрибуты НАЗВАНИЕ, АВТОР, ГОД ИЗДАНИЯ.

Атрибут, который характеризует заданный объект, однозначно называют ключом. Ключ может быть простым и составным.

Атрибуты объектов могут вступать в следующие зависимости:

функциональные,

транзитивные,

многозначные.

Определим каждую зависимость.

Атрибут В функционально зависит от А, если каждому значению А соответствует в точности одно значение В. Такую зависимость обозначают АВ.

Частичной зависимостью называется зависимость атрибута от части составного ключа.

Полная функциональная зависимость - зависимость не ключевого атрибута полностью от составного ключа.

Многозначная зависимость возникает тогда, когда каждому атрибуту А соответствует множество значений В. Многозначные зависимости могут быть вида один-ко-многим, многие-ко-многим, многие-к-одному.

Транзитивная зависимость возникает между атрибутами А и С тогда, когда для атрибутов А, В и С выполняется условие: АВ, ВС.

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

Каждая запись одной таблицы состоит из конечного (и одинакового!) числа полей, причем конкретное поле каждой записи одной таблицы может содержать данные только одного типа.

Значение данных представляет собой действительные данные, содержащиеся в каждом элементе данных.

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

Ограничения:

1. Все строки таблицы должны быть уникальны, т. е. не может быть строк с одинаковыми первичными ключами.

2. В таблице не должно быть столбцов с повторяющимися именами [1,2]

1.2 Методы проектирования базы данных

1.2.1 Метод нормальных форм

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

Первая нормальная форма

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

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

Основной операцией метода является операция проекции. Поясним ее на примере. Предположим, что в отношении R(A,B,C,D,E...) устранение функциональной зависимости CD позволит перевести его в следующую нормальную форму. Для решения этой задачи выполним декомпозицию отношения R на два новых отношения R1(A,B,C,E...) и R2(C,D). Отношение R2 является проекцией отношения R на атрибуты С и D.

Вторая нормальная форма

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

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

* построить проекцию без атрибутов, находящихся в частичной функциональной зависимости от первичного ключа;

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

Третья нормальная форма

Отношение находится в третей нормальной форме, если оно находится во второй нормальной форме и между атрибутами нет транзитивных зависимостей.

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

1.2.2 Проектирования структуру базы дынных методом ERдиаграмм

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

Метод сущность-связь называют также методом «ER-диаграмм»: во-первых, ER - аббревиатура от слов Essence (сущность) и Relation (связь), во-вторых, метод основан на использовании диаграмм, называемых соответственно диаграммами ER-экземпляров и диаграммами ER-типа.

Основными понятиями метода сущность-связь являются следующие:

сущность,

атрибут сущности,

ключ сущности,

связь между сущностями,

степень связи,

класс принадлежности экземпляров сущности,

диаграммы ER-экземпляров,

диаграммы ER-типа.

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

Атрибут представляет собой свойство сущности. Это понятие аналогично понятию атрибута в отношении.

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

Связь двух или более сущностей - предполагает зависимость между атрибутами этих сущностей. Название связи обычно представляется глаголом. [5]

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

Шаг 1. Каждая простая сущность превращается в таблицу. Простая сущность - сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем таблицы.

Шаг 2. Каждый атрибут становится возможным столбцом с тем же именем; может выбираться более точный формат. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, не могут.

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

Шаг 4. Связи многие-к-одному (и один-к-одному) становятся внешними ключами, т.е. делается копия уникального идентификатора с конца связи "один", и соответствующие столбцы составляют внешний ключ. Необязательные связи соответствуют столбцам, допускающим неопределенные значения; обязательные связи - столбцам, не допускающим неопределенные значения.

Шаг 5. Индексы создаются для первичного ключа (уникальный индекс), внешних ключей и тех атрибутов, на которых предполагается в основном базировать запросы.

Шаг 6. Если в концептуальной схеме присутствовали подтипы, то возможны два способа:

1.все подтипы в одной таблице (а);

2.для каждого подтипа - отдельная таблица (б).

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

При использовании метода (б) для каждого подтипа первого уровня (для более нижних - представления) супертип воссоздается с помощью представления UNION (из всех таблиц подтипов выбираются общие столбцы - столбцы супертипа).

Шаг 7. Имеется два способа работы при наличии исключающих связей:

1.общий домен (а);

2.явные внешние ключи (б).

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

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

В каждом поле таблиц базы данных хранятся данные одного типа. Базы данных Microsoft Access 2007 работают со следующими типами данных:

1.Текстовый - тип данных, используемый для хранения обычного неформатированного текста ограниченного размера (до 255 символов).

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

3.Числовой - тип данных для хранения действительных чисел.

4.Дата/время - тип данных для хранения календарных дат и текущего времени.

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

6.Счетчик - специальный тип данных для уникальных (не повторяющихся в поле) натуральных чисел с автоматическим наращиванием. Естественное использование - для порядковой нумерации записей.

7.Логический - тип для хранения логических данных (могут принимать только два значения, например Да или Нет).

8.Поле объекта OLE - тип для хранения объектов размером до 1Гб, таких как страницы Microsoft Excel, документы Microsoft Word, изображения, аудио-файлы и прочие данные. Объект может быть вставлен как ссылка или может быть связан с базой данных.

9.Гиперссылка - специальное поле для хранения адресов URL Web-объектов Интернета. При щелчке на ссылке автоматически происходит запуск браузера и воспроизведение объекта в его окне.

10.Вложение - файл любого типа, поддерживаемый Microsoft Access. Поля данного типа позволяют присоединять к базе данных любые файлы, аналогично прикреплению вложений к электронной почте. Данный тип данных занимает меньше памяти, чем поля объектов OLE, так как не создает точечного изображения (значка) исходного файла.

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

1.3 Способы создания и типы запросов к БД

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

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

Инструментальные средства

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

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

Результаты выполнения запроса выводятся в режиме таблицы. Окно запроса в режиме таблицы аналогично окну просмотра таблицы базы данных. В этом режиме становится активной панель инструментов Запрос в режиме таблицы (Query Datasheet) с перечнем кнопок, аналогичным тому, который представлен на панели Таблица в режиме таблицы (Table Datasheet).

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

Мастера создания запросов

Простейшие запросы некоторых видов могут быть созданы с помощью мастеров Access. С помощью мастера можно создать:

1.простой запрос на выборку;

2. перекрестный запрос (рисунок 4);

3.запрос для поиска повторяющихся записей (записей с повторяющимися значениями в полях);

4.запрос для поиска записей, не имеющих подчиненных (рисунок 5).

Мастер запросов ускоряет процесс создания запроса, автоматически выполняя первоначальные простейшие действия по подготовке запроса. Вызванный мастер запрашивает у пользователя сведения и создает запрос на основе его ответов. При необходимости можно отредактировать запрос в режиме конструктора (рисунок 3). Создание запроса с помощью мастера начинается с выбора в окне базы данных объекта Запросы (Queries) и нажатия кнопки Создать (New). В окне диалога Новый запрос (New Query) надо выбрать один из предлагаемых видов запроса: Простой (Simple Query Wizard), Перекрестный запрос (Crosstab Query Wizard), Повторяющиеся записи (Find Duplicates Query Wizard), Записи без подчиненных (Find Unmatched Query Wizard).

Далее следует выполнять инструкции, выводящиеся в окнах диалога мастера. В последнем окне диалога предлагается выбрать запуск запроса или просмотр структуры запроса в режиме конструктора (рисунки 1-2).

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

Рисунок 1 - Добавление таблицы в процессе создания запроса

Рисунок 2 - Создание запроса при помощи конструктора

Рисунок 3- Создание запроса с помощью мастера запросов

Рисунок 4- Создание перекрёстного запроса

Рисунок 5- Создание запроса для поиска записей, не имеющих подчинённых

2. Создание приложения для доступа к базе данных.

2.1 Построение модели предметной области для автоматизации учёта выработки энергии на электростанции

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

1.

АЭС
АЭС
Количество энергоблоков
Тип РУ
Дополнительная информация
Изображение

2.

Идентификация типа аварии по критериям
АЭС
Энергоблок
Дата
Критерий 1
Критерий 2
Тип аварии

3.

Классификация реакторных установок
Тип РУ
Назначение
Вид замедлителя
Вид теплоносителя
Энергетический спектр нейтронов

4.

Основные события
АЭС
Энергоблок
Дата
Основные события
Наличие неисправностей

5.

Основные технико-экономические характеристики блоков АЭС
Мощность турбогенератора
Число турбин в блоке
Давление пара перед турбиной
КПД
Мощность блока

6.

Режимы работы энергоблоков
АЭС
Энергоблок
Выбор группы режимов
Выбор подгруппы режимов

7.

Список исполнителей
АЭС
Энергоблок
ФИО исполнителя

8.

Справочник по типам аварий
Код типа аварии
Тип аварии

Преобразовали полученную модель данных, получив 8 таблиц.

2.2 Создание таблиц

Для создания базы данных «Автоматизация учета выработки и реализации энергии на атомной электростанции» запустим на выполнение СУБД Microsoft Access.

Создадим приложение для работы с базой данных в среде Microsoft Access. Для этого в окне базы данных выбираем Таблицы>Создать>Новая таблица>Конструктор.

На экране пустое окно конструирования таблицы, состоящее из двух частей. В верхней части окна вводятся имена полей, типы данных и комментарии (описание). В нижней части вводится описание свойств выделенного поля (параметры) (рисунок 8).

Ввели описание полей таблицы в окне конструирования:

1.В первую строку столбца ПОЛЕ введите с клавиатуры АЭС. В этой же строке в столбце Тип данных щелкнули левой клавишей мыши по кнопке раскрывшегося списка ("выбор из списка"). В появившемся списке выбрали "Текстовый" и щелкнули по нему левой клавишей мыши. В нижней части таблицы в разделе Свойства поля установили курсор на пункт Обязательное поле и щелкнули левой клавишей мыши по кнопке "выбор из списка". В появившемся списке установили курсор на "Да" и нажали левую клавишу мыши.

Аналогичным образом в поле Пустые строки указали "Нет". В поле Индексированное поле указали Да (Совпадения не допускаются).

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

2. КОЛИЧЕСТВО ЭНЕРГОБЛОКОВ - числовое поле

Обязательное поле: ДА

Пустые строки: нет

Индексированное поле: НЕТ

3. ТИП РУ - текстовое поле

Обязательное поле: ДА

Пустые строки: ДА

Индексированное поле: ДА(совпадения допускаются)

4. ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ - гиперссылка

Обязательное поле: НЕТ

Пустые строки: ДА

ИЗОБРАЖЕНИЕ - поле объекта OLE

Создали составной ключ таблицы, включающий поля АЭС и ТИП РУ

Рисунок 6- Внешний вид таблицы «АЭС»

2.Аналогичным образом создали таблицу «Идентификация типа аварии по критериям» (рисунок 7).

1. АЭС - текстовый

Обязательное поле: ДА

Пустые строки: нет

Индексированное поле: НЕТ

2. ЭНЕРГОБЛОК - числовой

Обязательное поле: ДА

Пустые строки: нет

Индексированное поле: ДА(совпадения допускаются)

3.ДАТА- дата/время

Обязательное поле: ДА

Пустые строки: НЕТ

Условие на значение:<=Date()

Сообщение об ошибке: введите корректное значение даты

4. КРИТЕРИЙ 1 - числовой

5. КРИТЕРИЙ 2 - числовой

6.ТИП АВАРИИ - текстовый

Значение по умолчанию: не наблюдалось

Создали составной ключ таблицы, включающий поля АЭС, ЭНЕРГОБЛОК, ДАТА

Рисунок 7 - Внешний вид таблицы «Идентификация типа аварии по критериям»

3. Создали таблицу «Классификация реакторных установок» (рисунок 8).

1. ТИП РУ- текстовый

Обязательное поле: ДА

Пустые строки: нет

2. НАЗНАЧЕНИЕ- текстовый

3.ТИП ЗАМЕДЛИТЕЛЯ- текстовый

4.ТИП ТЕПЛОНОСИТЕЛЯ- текстовый

5. ЭНЕРГЕТИЧЕСКИЙ СПЕКТР НЕЙТРОНОВ- текстовый

Создали ключ таблицы, включающий поле ТИП РУ

Рисунок 8 - Внешний вид формы «Классификация реакторных установок»

4.Создали таблицу «Основные события» (рисунок 9).

1. АЭС - текстовый

Обязательное поле: ДА

Пустые строки: нет

Индексированное поле: НЕТ

2. ЭНЕРГОБЛОК - числовой

Обязательное поле: ДА

Пустые строки: нет

Индексированное поле: ДА(совпадения допускаются)

3.ДАТА- дата/время

Обязательное поле: ДА

Пустые строки: НЕТ

Условие на значение:<=Date()

Сообщение об ошибке: введите корректное значение даты

4. ОСНОВНЫЕ СОБЫТИЯ - поле МЕМО

5. НАЛИЧИЕ НЕИСПРАВНОСТЕЙ - логический

Создали составной ключ таблицы, включающий поля АЭС, ЭНЕРГОБЛОК, ДАТА

Рисунок 9 - Внешний вид таблицы «Основные события»

5.Аналогичным образом создали таблицу «Основные технико-экономические характеристики блоков АЭС » (рисунок 10).

1. ТИП РУ - текстовый

Обязательное поле: ДА

Пустые строки: нет

Индексированное поле: НЕТ

2. МОЩНОСТЬ ТУРБОГЕНЕРАТОРА- числовой

3.ЧИСЛО ТУРБИН В БЛОКЕ- числовой

4.ДАВЛЕНИЕ ПАРА ПЕРЕД ТУРБИНОЙ- числовой

5. КПД - числовой

6.МОЩНОСТЬ БЛОКА- числовой

Создали ключ таблицы, включающий поле ТИП РУ

Рисунок 10 - Внешний вид таблицы «Основные технико-экономические характеристики блоков АЭС»

выработка энергия база данных

6.Создали таблицу «Режимы работы РУ» (рисунок 11).

1. АЭС - текстовый

Обязательное поле: ДА

Пустые строки: нет

Индексированное поле: НЕТ

2. ЭНЕРГОБЛОК - числовой

Обязательное поле: ДА

Пустые строки: нет

Индексированное поле: ДА(совпадения допускаются)

3.ГРУППА РЕЖИМОВ - текстовый

4. ПОДГРУППА РЕЖИМОВ- текстовый

Рисунок 11 - Внешний вид таблицы «Режимы работы РУ»

7.Создали таблицу «Список исполнителей» (рисунок 12).

1. АЭС - текстовый

Обязательное поле: ДА

Пустые строки: нет

Индексированное поле: НЕТ

2. ЭНЕРГОБЛОК - числовой

Обязательное поле: ДА

Пустые строки: нет

Индексированное поле: ДА(совпадения допускаются)

3.ФИО ИСПОЛНИТЕЛЯ- текстовый

Создали составной ключ таблицы, включающий поля АЭС, ЭНЕРГОБЛОК

Рисунок 12 - Внешний вид таблицы «Список исполнителей»

8.Создали таблицу «Справочник по типам аварий» (рисунок 13).

1. КОД - числовой

Обязательное поле: ДА

Пустые строки: нет

Индексированное поле: ДА

2. ТИП АВАРИИ- текстовый

Обязательное поле: ДА

Пустые строки: нет

Рисунок 13 - Внешний вид таблицы «Справочник по типам аварий»

Установили связь между полученными таблицами следующим образом (рисунки 14-15):

Рисунок 14- Схема базы данных

Рисунок 15-Реализация связи таблиц

2.3 Создание форм доступа к БД

В окне БАЗА ДАННЫХ нажали кнопку СОЗДАТЬ, а затем корешок ФОРМЫ.

В ходе разработки проекта были созданы следующие формы (рисунки 16-27):

1. «Первая»;

2. Главная кнопочная форма;

3. «АЭС»;

4. «Идентификация типа аварии по критериям»;

5. «Классификация реакторных установок»;

6. «Основные события»;

7. «Основные технико-экономические характеристики блоков АЭС»;

8. «Справочник по типам аварий».

1. Открытие формы «Первая» инициирует выполнение программы (рисунок 17), текст которой приведён в приложении 1.

Рисунок 16 - Внешний вид формы «Первая»

Рисунок 17 - Программа, выполняемая при открытии формы «Первая»

Рисунок 18 - Внешний вид главной кнопочной формы

Рисунок 19 - Переключение на форму «АЭС»

Рисунок 20 - Внешний вид формы «Идентификация типа аварии по критериям»

Рисунок 21 - Внешний вид формы «Классификация реакторных установок»

Рисунок 22 - Внешний вид формы «Основные события»

Рисунок 24 - Внешний вид формы «Основные технико-экономические характеристики блоков АЭС»



Рисунок 23- Создание вычисляемого поля с помощью построителя выражений

Рисунок 25 - Внешний вид формы «Режимы работы энергоблоков»

Рисунок 26 - Внешний вид формы «Список исполнителей»

Рисунок 27 - Внешний вид формы «Справочник по типам аварий»

2.4 Создание запросов к БД

В ходе разработки проекта были созданы следующие запросы:

1. «Аварии на АЭС» (рисунок 28)

2. «Аварийные ситуации» (рисунок 29)

3. «Журнал аварийных ситуаций на текущую дату» (рисунок 30)

4. «Количество энергоблоков» (рисунок 31)

5. «Основные технико-экономические характеристики блоков АЭС» (рисунок 32)

6. «По количеству энергоблоков и типу РУ» (рисунок 33)

7. «Сводка по авариям на текущую неделю» (рисунок 34)

8. «Тип РУ» (рисунок 35)

9. Запрос на обновление (рисунок 36)

10. Запрос на удаление (рисунок 37)

11. «Матрица аварийных ситуаций» (рисунок 38)

12.

Рисунок 28 - конструктор запроса «Аварии на АЭС»

Рисунок 29 - конструктор запроса «Аварийные ситуации»

Рисунок 30 - конструктор запроса «Журнал аварийных ситуаций на текущую дату»

Рисунок 31 - конструктор запроса «Количество энергоблоков»

Рисунок 32 - конструктор запроса «Основные технико-экономические характеристики блоков РУ»

Рисунок 33 - конструктор запроса «По количеству энергоблоков и типу РУ»

Рисунок 34 - конструктор запроса «Сводка по авариям на текущую неделю»

Рисунок 35 - конструктор запроса «Тип РУ»

Рисунок 36 - конструктор запроса на обновление

Рисунок 37 - конструктор запроса на удаление

Рисунок 38 - конструктор перекрёстного запроса «Матрица аварийных ситуаций»

3.5 Создание отчётов БД

В ходе разработки проекта для каждого запроса были созданы отчёты, внешний вид которых представлен на рисунках 17-22:

Рисунок 39 - Представление отчёта «Аварии на АЭС»

Рисунок 40 - Представление отчёта «Журнал аварийных ситуаций на текущую дату»

Рисунок 41 - Отчёт «Количество энергоблоков»

Рисунок 42 - Отчёт «Основные технико-экономические характеристики блоков АЭС»

Рисунок 43 - Отчёт «По количеству энергоблоков и типу РУ»

Рисунок 44 - Отчёт «По типу РУ»

3. Тестирование приложения.

Результаты тестирования полученного приложения представлены на рисунках 45-53:

Рисунок 45 - результат запуска приложения

Рисунок 46 - событие, инициируемое запуском формы «Первая»

Рис. 47

Рисунок 48 - результат нажатия кнопки «АЭС»

Рисунок 49 - результат нажатия кнопки Печать

Рисунок 50 - результат нажатия кнопки «Запрос на удаление»

Рисунок 51 - результат выполнения запроса «Аварии на АЭС»

Рисунок 52 - результат выполнения запроса «Аварийные ситуации»

Рисунок 53 - результат выполнения запроса «Матрица аварийных ситуаций»

Заключение

Таким образом, в ходе выполнения данной курсовой работы в рамках заданной предметной области в среде Microsoft Access была спроектирована и протестирована база данных.

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

Список использованных источников

1. Кириллов В.В. Структуризованный язык запросов (SQL). - СПб.: ИТМО, 1994. - 80 с.

2. Мейер М. Теория реляционных баз данных. М. Мир, 1987. - 608 с.

3. Штайнер Г. Access 2000. - М.: Лаборатория Базовых Знаний, 2000. - 480с.

4. Шевченко Н.А. Access 2003. Искусство создания базы данных / Шевченко Н.А. - М.: НТ Пресс, 2007. - 160с.: ил. - (Просто о сложном).

5. http://top.list.ru/jump?from=58469

6. Майкл Дж. Хернандес, Джон Л. Вьескас. SQL - запросы для простых смертных. Практическое руководство по манипулированию данными в SQL.-М.: «Лори», 2003

7. http://www.lessons-tva.info/

8. Самоучитель Microsoft Access 2003 Бекаревич Ю.Б., Пушкина Н.В.

9. Дементьев Б. А. Ядерные энергетические реакторы: Учебник для ВУЗов - М.: Энергоатомиздат, 1984. - 280 с., ил.

10. Джулия Келли. Access 97. Самоучитель - СПб: Питер. - 1999. - 336с.

11. Microsoft Access 97. Шаг за шагом: Практ. пособ./Пер. с англ. -

М.: Издательство ЭКОМ. - 1999. - 328с.

Приложение

Option Compare Database

Private Sub Form_Open(Cancel As Integer)

Me.TimerInterval = 5000

End Sub

Private Sub Form_Timer()

If Me.TimerInterval <> 0 Then

Me.TimerInterval = 0

DoCmd.OpenForm "Кнопочная форма"

End If

DoCmd.Close acForm, "form1"

End Sub

«Аварии на АЭС»

SELECT [Идентификация типа аварии по критериям].АЭС, [Идентификация типа аварии по критериям].Энергоблок, [Идентификация типа аварии по критериям].Дата, [Идентификация типа аварии по критериям].[Тип аварии]

FROM [Идентификация типа аварии по критериям]

WHERE ((([Идентификация типа аварии по критериям].АЭС)=[Укажите название АЭС]));

«Аварийные ситуации»

SELECT [Основные события].АЭС, [Основные события].Энергоблок, [Основные события].Дата, [Основные события].[Основные события], [Идентификация типа аварии по критериям].[Тип аварии]

FROM [Основные события] INNER JOIN [Идентификация типа аварии по критериям] ON ([Основные события].Дата = [Идентификация типа аварии по критериям].Дата) AND ([Основные события].Энергоблок = [Идентификация типа аварии по критериям].Энергоблок) AND ([Основные события].АЭС = [Идентификация типа аварии по критериям].АЭС)

WHERE ((([Основные события].[Наличие неисправностей])=True));

«Журнал аварийных ситуаций на текущую дату»

SELECT [Идентификация типа аварии по критериям].АЭС, [Идентификация типа аварии по критериям].Энергоблок, [Идентификация типа аварии по критериям].Дата, [Идентификация типа аварии по критериям].[Тип аварии], [Основные события].[Основные события]

FROM [Основные события] INNER JOIN [Идентификация типа аварии по критериям] ON ([Основные события].Дата = [Идентификация типа аварии по критериям].Дата) AND ([Основные события].Энергоблок = [Идентификация типа аварии по критериям].Энергоблок) AND ([Основные события].АЭС = [Идентификация типа аварии по критериям].АЭС)

WHERE ((([Идентификация типа аварии по критериям].Дата)=Date()));

«Количество энергоблоков»

SELECT АЭС.АЭС, АЭС.[Тип РУ], АЭС.[Дополнительная информация], АЭС.Изображение, АЭС.[Количество энергоблоков]

FROM АЭС

WHERE (((АЭС.[Количество энергоблоков])=[Укажите количество энергоблоков ]));

«Количество энергоблоков и тип РУ»

SELECT АЭС.АЭС, АЭС.[Количество энергоблоков], АЭС.[Тип РУ], АЭС.[Дополнительная информация], АЭС.Изображение, [Режимы работы энергоблоков].Энергоблок, [Режимы работы энергоблоков].[Группа режимов], [Режимы работы энергоблоков].[Подгруппа режимов]

FROM АЭС INNER JOIN [Режимы работы энергоблоков] ON АЭС.АЭС=[Режимы работы энергоблоков].АЭС

WHERE (((АЭС.[Количество энергоблоков])=[Укажите количество энергоблоков]) AND ((АЭС.[Тип РУ])=[Укажите тип РУ]));

«Сводка по авариям на текущую неделю»

SELECT [Идентификация типа аварии по критериям].АЭС, [Идентификация типа аварии по критериям].Энергоблок, [Идентификация типа аварии по критериям].Дата, [Идентификация типа аварии по критериям].[Тип аварии]

FROM [Идентификация типа аварии по критериям]

WHERE (((DateDiff("d",[Идентификация типа аварии по критериям]![Дата],Date()))<7));

Запрос на обновление.

UPDATE [Список исполнителей] SET [Список исполнителей].[ФИО исполнителя] = [Введите запись обновления]

WHERE ((([Список исполнителей].[ФИО исполнителя])=[Запись, которую необходимо обновить]));

«Матрица аварийных ситуаций»

TRANSFORM Sum([Идентификация типа аварии по критериям].Критерий1) AS [Sum-Критерий1]

SELECT [Идентификация типа аварии по критериям].АЭС, [Идентификация типа аварии по критериям].Энергоблок

FROM [Идентификация типа аварии по критериям]

GROUP BY [Идентификация типа аварии по критериям].АЭС, [Идентификация типа аварии по критериям].Энергоблок

PIVOT Format([Дата],"Short Date");

Размещено на Allbest.ru