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

Федеральное агентство по образованию ГОУ ВПО «Сибирский государственный технологический университет»

Кафедра Системотехники КУРСОВАЯ РАБОТА На тему: «Проектирование базы данных«

Руководитель:

Воробович Н.П.

Выполнили студенты гр. 2204

Толстоногов Д.С.

Демидов Е.И.

Красноярск 2009

1. Теоретические основы проектирования и разработки БД

2. Существующая организация бизнес-процессов и процессов обработки данных исследуемого объекта

3. Даталогическое и инфологическое проектирование БД

3.1 Определение сущностей, атрибутов, взаимосвязей между сущностями, ключей

3.2 Разработка модели базы данных

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

4. Физическая реализация проектируемой БД

4.1 Основные файлы, используемые при проектировании БД

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

5. Физическая реализация проектируемой БД Заключение Список используемой литературы

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

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

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

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

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

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

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

Visual FoxPro является также объектно-ориентированным языком, что увеличило затраты (до 50−60%) проектного время на анализ и планирование системы. В объектно-ориентированных системах классы разрабатываются в расчете на повторное использование. Поиск устойчивых иерархий классов — довольно длительный процесс. Поэтому в системах нового типа на анализ и планирование действительно уходит больше времени. Однако это окупается качеством конечного продукта.

1. Теоретические основы проектирования и разработки БД

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

ОСНОВНЫЕ ПОНЯТИЯ МЕТОДА Основными понятиями метода сущность-связь являются следующие:

· сущность,

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

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

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

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

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

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

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

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

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

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

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

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

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

· диаграммы ER-muna, или ER-диаграммы.

На начальном этапе проектирования БД выделяются атрибуты, составляющие ключи сущностей.

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

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

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

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

ЭТАПЫ ПРОЕКТИРОВАНИЯ Процесс проектирования базы данных является итерационным — допускающим возврат к предыдущим этапам для пересмотра ранее принятых решений и включает следующие этапы:

1. Выделение сущностей и связей между ними.

2. Построение диаграмм ER-типа с учетом всех сущностей и их связей.

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

4. Добавление неключевых атрибутов в отношения.

5. Приведение предварительных отношений к нормальной форме Бойса-Кодда, например, с помощью метода нормальных форм.

6. Пересмотр ER-диаграмм в следующих случаях:

· некоторые отношения не приводятся к нормальной форме Бойса-Кодда;

· некоторым атрибутам не находится логически обоснованных мест в предварительных отношениях.

После преобразования ER-диаграмм осуществляется повторное выполнение предыдущих этапов проектирования (возврат к этапу 1).

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

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

ПРАВИЛА ФОРМИРОВАНИЯ ОТНОШЕНИЙ

Правила формирования отношений основываются на учете следующего:

· степени связи между сущностями (1:1, 1: М, М:1, М: М);

· класса принадлежности экземпляров сущностей (обязательный и необязательный). Рассмотрим формулировки шести правил формирования отношений на основе диаграмм ER-тина.

Формирование отношений для связи 1:1

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

Правило 2. Если степень связи 1:1 и класс принадлежности одной сущности обязательный, а второй — необязательный, то под каждую из сущностей формируется по отношению с первичными ключами, являющимися ключами соответствующих сущностей. Далее к отношению, сущность которого имеет обязательный КП, добавляется в качестве атрибута ключ сущности с необязательным КП.

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

Правило 4. Если степень связи между сущностями 1: М (или М:1) и класс принадлежности М-связной сущности обязательный, то достаточно формирование двух отношений (по одному на каждую из сущностей). При этом первичными ключами этих отношений являются ключи их сущностей. Кроме того, ключ 1-связной сущности добавляется как атрибут (внешний ключ) в отношение, соответствующее М-связной сущности.

Правило 5. Если степень связи 1: М (М:1) и класс принадлежности М-связной сущности является необязательным, то необходимо формирование трех отношений (рис. 1.1).

Рис. 1.1 Диаграмма и отношение для правила 5

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

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

На рис. 1.2 приведены диаграмма ER-типа и отношения, сформированные по правилу 6. Нами показан вариант с классом принадлежности сущностей Н-Н, хотя, согласно правилу 6, он может быть произвольным.

Рис. 1.2 Диаграмма и отношения для правила 6

2. Существующая организация бизнес-процессов и процессов обработки данных исследуемого объекта

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

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

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

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

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

3. Даталогическое и инфологическое проектирование БД

3.1 Определение сущностей, атрибутов, взаимосвязей между сущностями, ключей

1. Zakaz (z_num, z_name, z_client, z_adress, z_priem, z_ust, z_price z_predopl,)

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

2. Product (p_num, p_name, p_summ, p_zak)

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

3. Details (d_num, d_name, d_razm1, d_razm2, d_razm3,d_kol, d_price, d_product, d_edizm, d_komp, d_summ)

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

4. Komplekt (k_num, k_name, k_price, k_mat, k_edizm).

Эта сущность отводится для хранения номера шаблона, названия шаблона детали, цены шаблона, материала из которого изготовлен шаблон, единиц измерения. Первичный ключ k_num, а вторичный k_mat. Пример шаблона (боковая стенка м²⁾.

5. Material (M_num, m_name, m_price)

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

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

Рис. 3.1

3.2 Разработка модели базы данных

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

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

Диаграмма ER-типа:

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

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

база данные ключ доступ

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

· Z_num (z_name, z_client, z_adress, z_priem, z_ust, z_price, z_predopl)

· P_num (p_name, p_summ, p_zak)

· D_num (d_name, d_razm1, d_razm2, d_razm3,d_kol, d_price, d_product, d_edizm, d_komplekt, d_summ)

· K_num (k_name, k_price, k_mat, k_edizm)

· M_num (m_name, m_price)

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

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

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

4. Физическая реализация проектируемой БД

4.1 Основные файлы, используемые при проектировании БД

Разработка информационной системы в среде объектно-ориентированной СУБД Visual FoxPro.

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

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

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

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

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

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

Вторичный индекс определен для поля: Номер заказа изделия (p_zakaz) — Regular;

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

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

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

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

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

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

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

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

Вторичные индексы определены для полей: не определены Входные файлы базы данных:

· файл Zakaz. dbf

· файл Product. dbf

· файл Details. dbf

· файл Komplekt. dbf

· файл Material. dbf

База данных, включающая эти таблицы:

· data1. dbc

Формы:

· main. scx

· new_zakaz.scx

· predoplata. scx

Отчеты:

· ustanovka. frx

· z_dolg.frx

Проект:

· kurs. pjx — kurs. pjt

Приложение:

· kurs. app — kurs. exe

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

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

5. Физическая реализация проектируемой БД

Рисунок 5.1 Текущие заказы Рисунок 5.2 Изделия и детали заказа Рисунок 5.3 Новый заказ Рисунок 5.4 Прием предоплаты

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

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

Заключение

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

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

Воробович Н. П. Базы данных. Курс лекций для студентов специальностей 220 400 и 552 800, изучающих курс «Базы данных», очной, очной сокращенной и заочной форм обучения. — Красноярск: СибГТУ, 2006. — 240 с.

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

Visual FoxPro 9 / Лебедев А. Н. — М.: НТ Пресс, 2005. — 328 с.: ил. — Самоучитель.