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

 

 

Содержание

 

Введение  2

1. Постановка  цели 2

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

          Сущности 4

Связи 5  

Атрибуты 8

ER-диаграмма 10

Ключи 11

3. Перенос логической  модели данных в среду СУБД 12

4. Разработка  программной оболочки 14

Среда разработки 14

Интерфейс программы 14

Формы добавления/редактирования 16

Отображение данных 18

Отчеты 21

Примеры кода 23

5. Запросы, используемые  в программе 25

Литература 28   

 

 

 

 

 

 

 

 

 

 

 

 

 

Введение

  

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

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

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

 

1. Постановка  цели

 

Фирма «Арт-Склад» занимается розничной продажей музыкальных  инструментов. Процесс происходит следующим  образом:

 

1. Поставка товара, акт поставки заносится в реестр поставок;

2. Занесение  товара в реестр товаров;

3. Установление  розничной цены на товар;

4. Покупатель  приобретает товар, при этом  в реестр продаж заносится  общая стоимость, и количество  проданного товара;

5. Заносятся изменения в реестр товаров.

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

     Основными  компонентами системы являются:

     - служащие;

     - поставщики;

     - товар (музыкальные инструменты);

     - реестр товаров.

    

     Для  того, чтобы понять, как происходит  выполнение задач, поставленных  перед персоналом фирмы, необходимо  разобраться со списком основных  бизнес-процессов:

 

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

 

     Вопрос «Где происходят данные процессы?» больше относится к проблемам телекоммуникаций и организации совместной работы персонала. Ведь в случае, например, большого объема операций, которые выполняются вне территории фирмы торговыми агентами, придется учитывать проблемы синхронизации данных. При наличии филиалов весьма непростой проблемой является оптимальный выбор системы распределения данных. Можно централизовать всю обработку данных, и филиалы будут выполнять свои операции, пользуясь возможностями телекоммуникаций. Работа с данными в этом случае упрощается, но следует учитывать негативную реакцию клиента, когда вы ему сообщите, что не можете взять у него несколько тысяч гривен и продать необходимый ему товар, так как прервалась связь с центральным офисом. В рассматриваемом примере допустим, что все операции выполняются в пределах одного здания, а организация совместного использования данных основана на возможностях локальной сети и сервера БД.

 

Перечень вводимой информации:

* Название, мнемокод, адрес и телефон поставщика;

* Дата и количество  товара в поставке;

* Вид, фирма-производитель,  название, описание и розничная  цена товара;

* ФИО продавца, его должность, адрес, дата  рождения и телефон;

* Дата продажи и количество проданного товара.

Перечень  печатных отчетов:

* Остатки товара  на складе;

* Архив поставок;

* Архив продаж.

 

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

 

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

* Товар;

* Поставщик;

* Поставка;

* Продажа;

* Служащий, осуществивший  продажу.

Немного раскроем значения этих сущностей:

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

 

    Для  облегчения процесса сортировки  и выборки я декомпозировал  из сущности Товар два свойства: Вид и Производитель (таблица  «Фирмы»).

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

Связь – это функциональная зависимость между сущностями.

Тип связи – осмысленная ассоциация между сущностями разных типов.

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

Рассмотрим взаимосвязи  между сущностями, включенными в  информационную модель бизнес-процесса фирмы «Арт-Склад»:

 

Сущность		Связь		Сущность		Тип
Товар	Имеет		Вид		M:1
Товар	Имеет		Производитель		M:1
Поставка	Содержит		Товар		1:M
Продажа	Содержит		Товар		1:M
Поставщик	Осуществляет		Поставка		1:M
Служащий	Осуществляет		Продажа		1:M

 

Определим кардинальность и степень участия каждой из связей.

1. Товар имеет вид: обязательна для товара и обязательна для вида, каждый товар имеет только один вид, а вид может содержать много товаров.
2. Товар имеет производителя: обязательна для товара и обязательна для вида, каждый товар имеет только одного производителя, а производитель может поставлять много товаров.
3. Поставка содержит товар: обязательна для поставки и для товара, одна поставка может содержать несколько моделей товара, а у товара может быть много поставок.
4. Продажа содержит товар: обязательна для продажи и необязательна для товара, одна продажа может содержать несколько моделей товара, а у товара может быть много продаж.
5. Поставщик осуществляет поставку: необязательна для поставщика и обязательна для поставки, одна поставка может осуществляться одним поставщиком, а поставщик может совершать много поставок.
6. Служащий осуществляет продажу: необязательна для служащего и обязательна для продажи, одна продажа может осуществляться одним служащим, а служащий может совершать много продаж.

 

На этапе определения  атрибутов сущностей необходимо выявить все данные, описывающие  сущности и связи, выделенные в создаваемой  модели базы данных. Для наглядности  я создал диаграмму связей и атрибутов  проектируемой базы данных средствами редактора диаграмм, входящего в состав MS SQL Enterptise 2005.

 

 

 

 

 

Атрибуты  сущностей

Сущность	Атрибут	Домен атрибута
Товар	ID	Int
	ID_вид	Int
	ID_фирма	Int
	Модель	nText
	Описание	nText
	Розн_цена	Money
	Количество	Int
Поставщик	ID	Int
	Название	Text
	Мнемокод	Text
	Адрес	Text
	Телефон	Text
Поставка	ID	Int
	Товар	Text
	Поставщик	Text
	Количество	Int
	Дата	DateTime
Продажа	ID	Int
	Товар	Text
	Количество	Int
	Стоимость	Money
	Продавец	Text
	Дата	DateTime
Служащие	ID	Int
	ФИО	Text
	Должность	Text
	Дата_Рожд	DateTime
	Адрес	Text
	Телефон	Text
Вид	ID	Int
	Вид	Text
Фирмы	ID	Int
	Название	Text

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

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

На данном этапе следует  на основе созданной ER-диаграммы определить наборы отношений (таблиц), необходимые  для представления сущностей  и связей.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

– обязательная степень участия сущности в связи,

    – необязательная степень участия сущности в связи.

 

 

 

 

Список таблиц с ключами

 

Таблица	Первичный ключ	Внешние ключи
Товар	Уникальный ключ товара	Уникальный ключ вида Уникальный ключ производителя
Вид	Уникальный ключ вида	–
Производитель	Уникальный ключ производителя	–
Поставщик	Уникальный ключ поставщика	–
Служащие	Уникальный ключ продавца	–
Продажа	Уникальный ключ продажи	Уникальный ключ товара Уникальный ключ продавца
Поставка	Уникальный ключ поставки	Уникальный ключ товара Уникальный ключ поставщика