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

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

Министерство образования РФ

Сибирский Государственный Технологический Университет

Факультет Автоматизации и информационных технологий

Кафедра Системотехники

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

На тему Реляционные базы данных: проектирование и реализация

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

Руководитель: Воробович Н. П.

Разработал: Студент Петренко А. С.

Красноярск 2005 г.

ЗАДАНИЕ

Разработать базу данных.

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

Нужно:

1. Выявить основные сущности. Начертить типичные диаграммы ER-экземпляров.

2. Для каждой диаграммы ER экземпляров начертить диаграмму ER-типа. Указать ключи сущностей для каждой сущности.

3. Разработать диаграмму ER-типов для всей предметной области с указанием ключей сущностей, типов связей между сущностями и классов принадлежности каждой сущности.

4. Определить перечень и состав доменов предметной области.

5. Определить перечень всех атрибутов предметной области; состав атрибутов полученных предварительных отношений; принадлежность каждого атрибута к соответствующему домену.

6. Оформить инфологическую модель предметной области.

7. Представьте окончательную концептуальную модель БД.

Разработать информационную систему.

1. Разработать формы для работы с информационной системой (должны быть формы типа “один к одному” и типа “один ко многим”). В формах должны быть различные средства управления.

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

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

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

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

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

СОДЕРЖАНИЕ

• ВВЕДЕНИЕ

1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ПРОЕКТИРОВАНИЯ И РАЗРАБОТКИ БД

• 2. СУЩЕСТВУЮЩАЯ ОРГАНИЗАЦИЯ БИЗНЕС-ПРОЦЕССОВ И ПРОЦЕССОВ ОБРАБОТКИ ДАННЫХ ИССЛЕДУЕМОГО ОБЪЕКТА
• 3. ДАТАЛОГИЧЕСКОЕ И ИНФОЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ БД
• 3.1 Выделение сущностей
• 3.2 Составление ER-диаграмм экземпляров и типов
• 3.3 Формирование отношений
• 3.4 Выявление функциональных зависимостей, нормализация и построение инфологической модели
• 4. ФИЗИЧЕСКАЯ ОРГАНИЗАЦИЯ ПРОЕКТИРУЕМОЙ БАЗЫ ДАННЫХ
• 4.1 Средства создания, изменения описания, удаления таблиц и данных
• 4.2 Способы повышения производительности доступа к данным
• 5. РАЗРАБОТКА ЕДИНОГО КОМПЛЕКСА ПРОГРАММ ПО СОЗДАНИЮ И ВЕДЕНИЮ БАЗ ДАННЫХ
• ЗАКЛЮЧЕНИЕ
• СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ

ВВЕДЕНИЕ

база функциональный программный инфологический

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

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

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

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

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

1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ПРОЕКТИРОВАНИЯ И РАЗРАБОТКИ БД

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

· иерархическая;

· сетевая;

· реляционная.

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

· постреляционная;

· многомерная;

· объектно-ориентированная.

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

СУБД, основанные на использовании реляционной модели данных, называют реляционными СУБД. На сегодняшний день это самая распространенная в использовании модель организации данных.

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

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

Примерами зарубежных реляционных СУБД для ПЭВМ являются следующие: dBaseIII Plus и dBase IY (фирма Ashton-Tate), DB2 (IBM), R:BASE (Microrim), FoxPro ранних версий и FoxBase (Fox Software), Paradox и dBASE for Windows (Borland), FoxPro более поздних версий, Visual FoxPro и Access (Microsoft), Clarion (Clarion Software), Ingres (ASK Computer Systems) и Oracle (Oracle).

К отечественным СУБД реляционного типа относятся системы: ПАЛЬМА (ИК АН УССР), а также система НуТесh (МИФИ).

Реляционная модель данных впервые была предложена сотрудником фирмы IBM Эдгаром Коддом и основывается на понятии отношение (relation).

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

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

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

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

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

Домен представляет собой множество всех возможных значений определенного атрибута отношения.

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

Основной единицей обработки данных в реляционных БД является отношение, а не отдельные его кортежи (записи).

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

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

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

· реляционная алгебра;

· реляционное исчисление.

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

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

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

С начала семидесятых годов слова “реляционная модель данных”, “реляционная база данных”, “реляционная алгебра”, “реляционное исчисление” стали общепринятыми терминами, употребляемыми в теории, методологии проектирования и использования баз данных. Самый общий термин - реляционный подход - обозначает определенную идеологию создания баз данных и баз знаний, идеологию, которая была объявлена основной в японском проекте ЭВМ пятого поколения (1980г.). Создатель реляционной модели данных Э.Ф.Кодд в 1981 г. получил за ее разработку премию Тьюринга Американской ассоциации по вычислительной технике.

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

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

В качестве СУБД была выбрана система, Visual DBase реализованная в средстве визуальной разработки FoxPro60. Основные причины данного выбора следующие:

· СУБД FoxPro60- один из последних форматов организации СУБД, имеющий широкие возможности.

2. СУЩЕСТВУЮЩАЯ ОРГАНИЗАЦИЯ БИЗНЕС-ПРОЦЕССОВ И ПРОЦЕССОВ ОБРАБОТКИ ДАННЫХ ИССЛЕДУЕМОГО ОБЪЕКТА

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

Основным алгоритмом является алгоритм по расчету деталей. Расчет деталей происходит исходя из их размеров, цены и количества.

Стоимость деталей = габаритные размеры * цена за ед. * количество

Цена изделия формируется исходя из суммы всех деталей изделия, а стоимость заказа исходя из стоимости изделий заказа.

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

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

3. ДАТАЛОГИЧЕСКОЕ И ИНФОЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ БД

3.1 Выделение сущностей

1.Zakaz (Zak_num, zak_name zak_client, zak_adress, zak_priem , zak_ust, zak_price zak_predopl,)

Эта сущность отводится для хранения номера заказа, название заказа, Ф.И.О клиента, адрес клиента, дата приема, дата установки, сумма заказа, внесение предоплаты. Первичным ключом является zak_num. Пример (комплект корпусной мебели).

2.Product (Prod_num , prod_name, prod_summ, prod_zak )

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

3.Details (Det_num, det_name det_razm1, det_razm2, det_razm3 ,det_kol, det_price, det_prod ,det_edizm, det_komp, det_summ)

Эта сущность отводится для хранения, номера детали, названия детали, ее размер, количество деталей, цена за единицу, единицы измерения детали, стоимости детали. Первичный ключ det_num , а внешний ключ det_prod. Пример детали (боковая стенка 500/600/3 шт.).

4. Komplekt (Komp_num , komp_name, , komp_price, komp_mat ,komp_edizm). Эта сущность отводится для хранения номера шаблона, названия шаблона детали, цены шаблона, материала из которого изготовлен шаблон, единиц измерения. Первичный ключ komp_num , а вторичный komp_mat.Пример шаблона (боковая стенка м² ).

5.Material (Mat_num,mat_name,mat_price)

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

Более наглядное представление сущностей представлено на рис. 3.1.1

рис. 3.1.1

3.2 Составление ER-диаграмм экземпляров и типов

Составим диаграмму ER-экземпляров:

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

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

Рис 3. 2. 1. Диаграмма ER-экземпляров базы данных

Составим диаграмму ER-типов, на которой указаны также ключи сущностей.



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

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

Рис 3. 2. 2. Диаграмма ER-типов базы данных

3.3 Формирование отношений

На основе диаграмм построим отношения:

1.Zakaz (Zak_num, zak_name zak_client, zak_adress, zak_priem , zak_ust, zak_price zak_predopl,)

Эта сущность отводится для хранения номера заказа, название заказа, Ф.И.О клиента, адрес клиента, дата приема, дата установки, сумма заказа, внесение предоплаты. Первичным ключом является zak_num. Пример (комплект корпусной мебели).

2.Product (Prod_num , prod_name, prod_summ, prod_zak )

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

3.Details (Det_num, det_name det_razm1, det_razm2, det_razm3 ,det_kol, det_price, det_prod ,det_edizm, det_komp, det_summ)

Эта сущность отводится для хранения, номера детали, названия детали, ее размер, количество деталей, цена за единицу, единицы измерения детали, стоимости детали. Первичный ключ det_num , а внешний ключ det_prod. Пример детали (боковая стенка 500/600/3 шт.).

4. Komplekt (Komp_num , komp_name, , komp_price, komp_mat ,komp_edizm). Эта сущность отводится для хранения номера шаблона, названия шаблона детали, цены шаблона, материала из которого изготовлен шаблон, единиц измерения. Первичный ключ komp_num , а вторичный komp_mat.Пример шаблона (боковая стенка м² ).

5.Material (Mat_num,mat_name,mat_price)

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

3.4 Выявление функциональных зависимостей, нормализация и построение инфологической модели

Выделим следующие функциональные зависимости:

· Zak_num ( zak_name zak_client, zak_adress, zak_priem , zak_ust, zak_price zak_predopl,)

· Prod_num ( prod_name, prod_summ, prod_zak )

· Det_num (det_name det_razm1, det_razm2, det_razm3 ,det_kol, det_price, det_prod ,det_edizm, det_komp, det_summ)

· Komp_num ( komp_name, , komp_price, komp_mat ,komp_edizm)

· Mat_num (mat_name,mat_price)

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

На основе полученных отношений построим инфологическую модель базы данных:

Рис 3. 4. 1. Типичные экземпляры отношений базы данных

4. ФИЗИЧЕСКАЯ ОРГАНИЗАЦИЯ ПРОЕКТИРУЕМОЙ БАЗЫ ДАННЫХ

4.1 Средства создания, изменения описания, удаления таблиц и данных

Таблицы базы данных были созданы в FoxPro 7.0 реализованные в средстве визуальной разработки FoxPro 7.0. Описание полей таблиц, типы полей, ключи и индексы представлены ниже:

1. Отношение Заказ (файл Zakaz.dbf)

Значение	Имя поля	Тип поля (длина)
Название заказа	zak_name	Character
Ф.и. о клиента	zak_client	Character
Адрес клиента	zak_adress	Character
Дата приема	zak_priem	Data
Дата установки	zak_ust	Data
Стоимость заказа	zak_price	Currency
Предоплата	zak_predopl	Numeric

Первичный ключ отношения (Primary) - Номер заказа (Zak_num).

Вторичные индексы определены для полей: не определены

2. Отношение Изделие (файл Product.dbf)

Значение	Имя поля	Тип поля (длина)
Название изделия	prod_name	Character
Стоимость изделия	prod_summ	Currency
Номер заказа изделия	prod_zak	Integer
Номер изделия	Prod_num	Integer

Первичный ключ отношения (Primary) -Номер изделия (Prod_num).

Вторичный индекс определен для поля:

· Номер заказа изделия (prod_zak) -Regular;

3. Отношение Детали (файл Details.dbf)

Значение	Имя поля	Тип поля (длина)
Название детали	det_name	Character
Размер по длине	det_razm1	Float
Размер по ширине	det_razm2	Float
Размер по глубине	det_razm3	Float
Количество деталей	det_kol	Integer
Цена за ед.	det_price	Integer
Номер изделия, где находится деталь	det_prod	Integer
Единицы измерения	det_edizm	Integer
Тип шаблона детали	det_komp	Integer
Стоимость детали	det_summ	Currency
Номер детали	det _num	Integer

Первичный ключ отношения (Primary) -Номер детали (det_num).

Вторичные индексы определены для полей:Номер изделия, где находится деталь (det_prod) - Regular; Тип шаблона детали (det_komp) -Regular; .

4. Отношение Шаблоны (файл Komplekt .dbf)

Значение	Имя поля	Тип поля (длина)
Название шаблона	komp_name	Character
Цена за ед. шаблона	komp_price	Currency
Номер материала шаблона	komp_mat	Integer
Ед. изм. шаблона	komp_edizm	Integer
Номер шаблона	Komp_num	Integer

Первичный ключ отношения (Primary)- Номер шаблона (Komp_num).

Вторичный индекс определен для поля: Материал шаблона ( komp_mat )- Regular;.

Отношение Материалы (файл Material.dbf)

Значение	Имя поля	Тип поля (длина)
Название материала	mat_name	Character
Цена материала	mat_price	Currency
Номер материала	Mat_num	Integer

Первичный ключ отношения (Primary) - Номер материала (Mat_num).

Вторичные индексы определены для полей: не определены

Таким образом, входные файлы базы данных:

· файл Zakaz.dbf

· файл Product.dbf

· файл Details.dbf

· файл Komplekt .dbf

· файл Material.dbf

4.2 Способы повышения производительности доступа к данным

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

5. РАЗРАБОТКА ЕДИНОГО КОМПЛЕКСА ПРОГРАММ ПО СОЗДАНИЮ И ВЕДЕНИЮ БАЗ ДАННЫХ

Рисунок-5.1 Текущие заказы

Рисунок-5.2 Изделия и детали заказа



Рисунок-5.3 Новый заказ

Рисунок-5.4 Прием предоплаты



Рисунок-5.5 Отчет по неоплаченным заказам

Рисунок-5.6 Отчет по графику установки



Рисунок-5.7 Отчет заказов на текущее число

ЗАКЛЮЧЕНИЕ

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

СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ

1.Стернс Т.,Стернс Л., Изучи сам Visual FoxPro 3.0….сегодня / Пер.с англ.:Худ . обл.М.В.Драко.-Мн,.ООО ”Попурри” ,1997.-480 с.

2.Л.Омельченко Самоучитель по Visual FoxPro 6.0 - СПб.:БХВ-Санкт-Петербург,2000.-512с.: ил.

3.Дж. Грофф, П. Вайнберг ,Энциклопедия SQL,3-е издание.(+CD) - СПб.:Питер,2003.-869с.: ил.

4.Н.П. Воробович Электронный учебник по БД

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