Курсовые работы / Разработка приложения на ЯВУ для доступа к базе данных

Национальный исследовательский институт Московский Энергетический Институт (Технический Университет)

Институт Автоматики и Вычислительной Техники Кафедра Прикладной математики

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

по дисциплине: «Базы данных и экспертные системы»

на тему:

Разработка приложения на языке высокого уровня

для доступа к базе данных

Выполнил:

Бочаров Иван Андреевич Проверила:

доц. Сидорова Наталья Петровна

Москва

2011 г.

Оглавление
Введение.........................................................................................................	3
Проектирование БД ......................................................................................	4
Инфологическая модель БД .....................................................................	4
Логическое проектирование ....................................................................	7
Обоснование нахождения отношений в 3НФ ........................................	8
Физическое проектирование..................................................................	10
Разработка программного продукта..........................................................	15
Описание используемых технологий....................................................	15
СУБД MSSQL Server 2008 .................................................................	15
Язык программирования C# ..............................................................	16
ADO .NET ............................................................................................	17
Описание процесса реализации .............................................................	17
Создание триггеров для обеспечения целостности данных ...................	25
Внешние ключи .......................................................................................	25
Прочие триггеры .....................................................................................	26
Заключение ..................................................................................................	29
Список использованной литературы ........................................................	31
Приложения .................................................................................................	32
Приложение 1. Функциональные зависимости ...................................	32
Приложение 2. Код хранимой процедуры............................................	34
Приложение 3. Код триггера..................................................................	35

2

Введение

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

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

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

то нам стоит использовать базу данных.

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

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

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

выбор задачи проектирования и метода еѐ решения

описание всех этапов проектирования БД: инфологическое, логическое и физическое проектирование

анализ результатов проектирования

описание используемых средств реализации

пример использования реализации проекта

3

Проектирование БД

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

Основные задачи этого процесса:

Обеспечение хранения в БД всей необходимой информации

Обеспечение возможности получения данных по всем необходимым запросам

Сокращение избыточности и дублирования данных

Обеспечение целостности данных (правильности их содержания):

исключение противоречий в содержании данных, исключение их потери и т.д.

Инфологическая модель БД

Опишем работу аптеки на естественном языке.

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

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

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

примеру, различается дозировка или поставщик). Лекарства могут иметь одинаковые наименования, но все они различаются по своему уникальному шифру (ID).

В аптеке ведется учет постоянных покупателей. Хранятся имя,

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

4

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

Также будем хранить информацию о каждом сотруднике (ФИО, номер паспорта, номер трудовой, даты принятия на работу и увольнения с работы),

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

Отразим данную информацию при помощи ER-диаграммы, созданной в

CASE-средстве ERWin Data Modeller:

Приведем таблицу, описывающую мощность отношений:

Отношение
Имя	Мощность
Покупатель-Покупка	0	или 1 к 0, 1 или более
Сотрудник-Покупка	1	к 0 или более
Лекарство - Поставка	1	к 0 или более
Поставщик - Поставка	1	к 0 или более
Поставка-Покупка	1	к 0 или более
Склад - Поставщик	1	к 0 или более

Для поддержания целостности данных используем следующие ограничения:

5

Лекарство

o Доза не меньше 0 и не больше 1000 мг

oСпособ применения – непустая строка длиной не более 255

символов

oИмя – непустая строка длиной не более 255 символов

Сотрудник

oФИО – непустая строка длиной не более 255 символов

o Зарплата – произвольное неотрицательное число

o Дата принятия на работу меньше даты увольнения,

значение по умолчанию – текущее время

o Номер паспорта – непустая строка длиной 10 символов

o Номер трудовой книжки – непустая строка длиной 255

символов

Покупатель

o ФИО – непустая строка длиной не более 255 символов

o Контактный телефон – строка из 13 символов формата

XXX-XXX-XX-XXСклад

o Адрес – непустая строка длиной не более 255 символов

o Контактный телефон – строка из 13 символов формата

XXX-XXX-XX-XX

o Дата открытия меньше даты закрытия, значение по умолчанию – текущее время

Поставка

oЦена – произвольное положительное число

Покупка

oКоличество лекарства – произвольное положительное число

Поставщик

6

o Имя организации – непустая строка длиной не более 255

символов

o Контактный телефон – строка из 13 символов формата

XXX-XXX-XX-XX

o Дата подписания договора меньше даты расторжения договора, значение по умолчанию – текущее время

Логическое проектирование

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

Преобразуем модель, следуя следующим принципам:

1) Если между объектами связь 1:1, то достаточно одной таблицы,

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

2)Если между объектами связь 1:n, то необходимы две таблицы, по таблице для каждого объекта, при этом ключевой атрибут односвязного объекта добавляется к атрибуту n-связанного объекта.

3)Если связь между объектами n:m, то необходимо три таблицы, по одной для связанных объектов и одна таблица для связи. При этом таблица для связи должна содержать ключевые атрибуты связанных объектов.

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

7

Обоснование нахождения отношений в 3НФ

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

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

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

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

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

Проанализируем функциональные зависимости в каждом из отношений:

8

Отношение «Работник»

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

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

Отношение «Склад»

Все неключевые атрибуты функционально полно зависят от ключевого атрибута Warehouse_ID. Дата открытия и закрытия склада, его телефон и адрес определяются его ID.

Отношение «Поставщик»

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

Warehouse_ID.

Отношение «Покупатель»

Все неключевые атрибуты функционально полно зависят от ключевого атрибута Customer_ID. Имя, фамилия и контактный телефон покупателя однозначно определяются его ID.

Отношение «Лекарство»

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

9

Отношение «Поставка»

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

Отношение «Покупка»

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

3 нормальная форма

Согласно определению Кодда, таблица находится в 3NF тогда и только тогда, когда выполняются следующие условия:

Отношение R (таблица) находится во второй нормальной форме

Каждый непервичный атрибут R находится в нетранзитивной (то есть прямой) зависимости от каждого ключа R.

Во всех отношениях отсутствуют транзитивные зависимости от ключа,

следовательно, БД находится в третьей нормальной форме.

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

Физическое проектирование

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

10