База данных фирмы, проводящей аукционы. 2

КР 070590795

ФЕДЕРАЛЬНОЕ АГЕНТСТВО  ПО ОБРАЗОВАНИЮ

Государственное образовательное  учреждение высшего

профессионального образования

«ТИХООКЕАНСКИЙ ГОСУДАРСТВЕННЫЙ  УНИВЕРСИТЕТ»

 

 

Кафедра «Экономическая кибернетика»

 

 

 

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

Тема: «База данных фирмы, проводящей аукционы».

Дисциплина «Базы данных»

 

 

 

 

 

 

Выполнил студент  3 курс гр. ПИЭ-81

№ зачетной книжки:  070590795

                                   Гарнцева С.Ю.

Проверила:              Коношко А.Ю.

 

 

 

 

 

 

Хабаровск 2010г.

 

БЛАНК ЗАДАНИЯ

На выполнение курсовой работы по дисциплине

«БАЗЫ ДАННЫХ»

Студент группы ПИЭ - 81

Ф.И.О.  Гарнцева Светлана Юрьевна

 

Дата выдачи 1 октярбя 2010г.    Дата сдачи 25 декабря 2010г.

 

Тема:  База данных фирмы, проводящей аукционы.

 

 

 

Согласовано 

Заведующий  кафедрой                       

 

Преподаватель         А.Ю.Коношко

 

Содержание

 

 

Введение

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

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

Современные СУБД в основном являются приложениями Windows, так как данная среда позволяет более полно использовать возможности персонального компьютера. БД разработанная в Mircosoft Office Access  доступна практически любому пользователю, программа имеет понятный интерфейс, при необходимости позволяет редактировать своих элементов.

 

1. Понятие о СУБД

 

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

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

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

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

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

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

Свойство (атрибут) - определенная часть информации о некотором объекте. Хранится в виде столбца ( поля ) таблицы. Например, фамилия, имя, отчество - это свойства для объекта Студент.

Связь (отношение) - способ , которым  связана информация о разных объектах.

 

Типы связей между объектами

Основным структурным компонентом  базы данных, как правило, является таблица. При определении состава  таблиц следует руководствоваться  правилом: в каждой таблице должны храниться данные только об одном  классе объектов. Например, в одной  таблице нельзя хранить анкетные данные студента и фамилии преподавателей, которым он сдавал экзамены, т.к. это свойства разных классов объектов.

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

Связи между любыми двумя таблицами  относятся к одному из трех типов: один-к-одному (1:1) , один-ко-многим (1:М) и  много-ко-многим (М:М).

Связь типа “один-к-одному” (1:1)

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

Связь типа “один-ко-многим” (1:М)

При таком типе связи каждой записи в одной таблице соответствует  несколько записей в связанной  таблице. Этот наиболее распространенный тип связей. Для его реализации используются две таблицы. Одна из них представляет сторону "один", другая - сторону "много". Например, нужно иметь информацию о студентах и результатах сдачи ими экзаменов (дата сдачи, предмет, оценка и т.д.). Если все это хранить в одной таблице, то ее объем неоправданно возрастет, т.к. в ней для каждой записи об очередном экзамене должны повторяться все анкетные сведения о студенте. Поскольку Студент и Экзамены - это разные классы объектов, то и свойства их должны храниться в разных таблицах.

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

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

Связь типа “много-ко-многим” (М:М)

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

 

2. Основные понятия  о реляционных базах данных.

Понятие реляционный (англ. relation —  отношение) связано с разработками известного американского специалиста  в области систем баз данных, сотрудника фирмы IBM д-ра Е. Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks. CACM 13: 6, June 1970), которым впервые был применен термин «реляционная модель данных».

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

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

Реляционная модель ориентирована  на организацию данных в виде двумерных  таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:

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

База данных, построенная с помощью  отношений, называется реляционной базой данных.

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

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

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

Предложив реляционную модель данных, Э.Ф.Кодд создал и инструмент для удобной работы с отношениями – реляционную алгебру. Каждая операция этой алгебры использует одну или несколько таблиц (отношений) в качестве ее операндов и продуцирует в результате новую таблицу, т.е. позволяет "разрезать" или "склеивать" таблицы.

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

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

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

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

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

Данная  модель позволяет определять:

• операции по запоминанию и поиску данных;
• ограничения, связанные с обеспечением целостности данных.

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

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

Основным  преимуществом реляционных СУБД является возможность связывания на основе определенных соотношений файлов БД.

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

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

• поддерживает реляционную структуру данных;
• реализует по крайней мере операции селекции, проекции и соединения отношений.

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

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

Основным достоинством реляционных  баз данных является совместимость  с самым популярным языком запросов SQL.

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

Но выявлены и недостатки рассмотренной модели баз данных:

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

 

3. Проектирование  базы данных «Фирма, проводящая аукционы».

3.1. Анализ предметной  области.

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

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

    3.2. Назначение базы данных.

 

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

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

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

3.3.Структура базы данных.

3.3.1. Таблицы.

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

Таблица «Продавцы»

Предназначена для хранения данных о продавцах.

 

Таблица «Изделия».

Содержит информацию о продаваемых  изделиях.

 

 

 

 

 

Таблица «Аукционы».

В ней содержатся данные о проводимых аукционах.

 

Таблица «Покупатель».

Данная таблица содержит данные о покупателях. Она может дополняться.

 

Таблица «Изделия на аукционах»

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

3.3.2. Схема связей между таблицами.

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

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

 

3.3.3. Формы.

 

1. Главная форма.

 

 

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

 

2. Форма «Аукционы»

 

 

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

форму «Сумма доходов аукционов  по специфике»

можно увидеть  соответствующую  форму с вычисленным значением  суммарного дохода по специфике,  и  форму «Сумма дохода аукционов по городам»,

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

Форма «Поиск по месту»

Эта форма имеет подчиненную  форму «Аукционы». Выбрав город из списка – «поиск по месту», можно  увидеть какие аукционы в нем проводились. 
3. Форма «Изделия»

Позволяет просмотреть список изделий, которые продавались или продаются  на аукционах данной фирмы. Из выпадающего  списка можно выбрать параметр поиска «Дата поступления». В поле со списком – «Поиск по названию изделия» - нужно ввести изделие и дальше выбрать его из списка, при нажатии Enter форма покажет искомое изделие.

Нажав на кнопку «Изделии в наличии» можно увидеть те изделия, которые  на данный момент еще не проданы, выводится  соответствующая форма

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

 

4. Форма «Изделия на аукционах»

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

 

5. Форма «Покупатели»

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

Форма «Затраты покупателей»

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

6. Форма «Продавцы»

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

Кнопка «Доход продавцов» открывает  соответствующую форму:

Возможно распечатать отчет, нажав  на соответствующую кнопку.

 

3.3.4. Запросы.

 

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

 

Запрос 1. Определение сумму дохода всех аукционов от продажи изделий. Доход рассчитывается по формуле : «Выражение1: ([Цена покупки]-[Стартовая цена])*0,5», т.к. договор между продавцом и фирмой предполагает, что выручка сверх стартовой цены делится пополам между фирмой и продавцом.

 

Запрос 2. Определяет доходы всех продавцов. Рассчитывается по формуле: Выражение1: Sum(([Цена покупки]-[Стартовая цена])*0,5+[Стартовая цена]), т.к. договор между продавцом и фирмой предполагает, что выручка сверх стартовой цены делится пополам между фирмой и продавцом, а продавцу полагается еще и цена за сам предмет.

 

 

 

Запрос 3. Показывает затраты покупателей

 

 

Запрос 4. Показывает изделия в наличии

 

Запрос 5. Показывает проданные предметы.

 

 

Запрос 6. Определяет сумму дохода аукционов по специфике.

 

 

 

Запрос 7. Показывает затраты покупателей. Расчет из суммы цен покупки купленных предметов.

Результатами запросов являются таблицы либо результаты, отражающиеся в виде форм.

 

 

 

3.3.5. Отчеты.

Отчеты предназначены  для вывода на печать данных полученных в результате выполнения запросов.

 

Отчет 1. Сумму дохода аукционов  по специфике.

Отчет 2. Доходы продавцов

 

 

Отчет 3. Затраты покупателей

 

Отчет 4. Изделия в наличии

 

Отчет 5 : Доходы всех аукционов

 

Руководство пользователя

 

 

1. Запустите файл «БД Фирма, проводящая аукционы.mbd»
2. В появившемся окне «Предупреждение системы безопасности» нажимаем открыть.
3. Далее появляется форма-навигатор (главная форма)

4. На ней располагаются 6 кнопок: Аукционы, Изделия, Изделия на аукционах, Продавцы, Покупатели, Сохранить/Выйти.

 

 

 

 

 

 

 

 

 

 

 

1. Кнопка «Аукционы»

Открывает форму «Аукционы».

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

4.2. Кнопка «Изделия»

 Нажатие на кнопку «Изделия», приведет к открытию новой формы «Изделия». В ней содержится информации обо всех изделиях, участвующих в деятельности фирмы, дате их поступления, продавцах и типе. Поиск можно осуществить 2мя способами: выбрать дату поступления или же ввести наименование изделия  и нажать Enter на клавиатуре. Кнопка «Изделия в наличии» покажет изделия в наличии, а кнопка «Проданные изделия» соответственно покажет их.

 

 

 

 

 

 

3.  Кнопка «Изделия на аукционах»

Открывает форму «Изделия на аукционах».

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

4. Кнопка «Покупатели»

Открывает форму «Покупатели».

В ней содержатся данные обо всех покупателях, участвующих  в аукционах, купивших тот или  иной предмет. Поиск осуществляется путем ввода фамилии в поле «Поиск по ФИО» или же можно выбрать из выпадающего списка. Кнопка «Затраты покупателей» открывает новую форму, в которой можно увидеть суммы, которые истратили покупатели на аукционах. Можно добавить или удалить записи, нажав на соответствующие кнопки.

5. Кнопка «Продавцы»

Открывает форму «Продавцы».

В ней содержатся данные обо всех продавцах, выставляющих на аукцион свои изделия. Поиск осуществляется путем ввода фамилии в поле «Поиск по ФИО» или же можно выбрать  из выпадающего списка. Кнопка «Доход продавцов» открывает новую форму, в которой можно увидеть какой доход получил каждый продавец (стартовая цена изделия + 50% от суммы, полученной сверх стартовой цены, остальное получает фирма). Можно добавить или удалить записи, нажав на соответствующие кнопки.

 

6.  Кнопка «Сохранить/Выйти»

Сохраняет Базу данных и закрывает приложение.

 

Заключение.

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

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

Средствами СУБД Access из пакета программ Microsoft Office 2000-2003 была разработана база данных, предназначенная для автоматизации работы фирмы, работающей в сфере аукционов. Был проведен анализ предметной области и изучена ее специфика, поэтому база должна быть понятна и удобна работникам данного учреждения.

База максимально настроена  на выполнение требований персонала и имеет приятный внешний вид.

 

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

 

1. Гетц Кен «Access. Сборник рецептов для профессионалов»; Спб; 2005 г; 782 с.;
2. Горев А., Макашарипов С, Ахаян Р. Эффективная работа с СУБД. СПб, «Питер», 2002
3. Хомоненко А.Д. «Базы данных»; Спб.: КОРОНА принт;2004г; 736с.
4. Золотова С.И. Практикум по Access – М.: Финансы и статистика, 2001г.
5. Кузин А.В., Демин В.М.Разработка баз данных в системе Microsoft Access: Учебник – Учебник – м.: Форум: Инфра-М, 2005г.