База данных по продаже автомобилей
СОДЕРЖАНИЕ
Введение......................
РАЗДЕЛ 1 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ ИССЛЕДОВАНИЯ……….8
- Предметная область……………………………………………………8
- Атрибуты…………………………………………………………
……10 - Объекты……………………………………………………………
…..13
1.4 Концептуальная модель………………………………………………16
Раздел 2 ПОСТРОЕНИЕ МАТЕМАТИЧЕСКОЙ МОДЕЛИ……………….19
2.1 Основные понятия теории реляционных баз данных………………19
2.2 Методы проектирования отношений………………………………...21
2.3 Нормализация отношений методом ER-диаграмм………………….25
РАЗДЕЛ 3 ОПИСАНИЕ ПРОГРАМНОГО ПРОДУКТА……………………..
3.1 Выбор языка программирования……………………………………
3.2 Предназначение и условия использования программы……………35
3.3 Формирование запросов……………………………………………...36
3.4 Описание програмной реализации…………………………………..39
ЗАКЛЮЧЕНИЕ……………………………………………………
Список использованной литературы…………………………………………..42
ПРИЛОЖЕНИЕ А Экранные формы программы……………………………..43
ВВЕДЕНИЕ
В настоящее время среди разработчиков базы данных (БД) большой популярностью пользуется реляционная СУБД ACCESS, входящая в состав пакета Microsoft Office. Дружественный интерфейс и простота настройки, эффективные средства создания таблиц, форм, запросов, интеграция с другими приложениями пакета, средства организации работы с базами данных и защита информации - вот далеко не полный перечень достоинств этого приложения.
Основные функции СУБД – это описание структуры базы данных, обработка данных и управление данными.
База данных – это совокупность сведений о реальных объектах, процессах, событиях или явлениях, относящихся к определённой теме или задаче, организованная таким образом, чтобы обеспечить удобное представление этой совокупности, как в целом, так и любой её части. Реляционная база данных представляет собой множество взаимосвязанных таблиц, каждая из которых содержит информацию об объектах определённого типа. Каждая строка таблицы содержит данные об одном объекте (например, клиенте, автомобиле, документе), а столбцы таблицы содержат различные характеристики этих объектов – атрибуты (например, наименования и адреса клиентов, марки и цены автомобилей). Строки таблицы называются записями, все записи имеют одинаковую структуру – они состоят из полей, в которых хранятся атрибуты объекта. Каждое поле в записи содержит одну характеристику объекта и имеет строго определённый тип данных (например, текстовая строка, число, дата). Все записи имеют одни и те же поля, только в них содержатся разные значения атрибутов.
Любая СУБД позволяет выполнять четыре простейшие операции с данными:
- добавить в таблицу одну или несколько записей;
- удалить из таблицы одну или несколько записей;
- обновить значения некоторых полей в одной или нескольких записях;
- найти одну или
несколько записей, удовлетворя
Для выполнения этих операций используется механизм запросов. Результатом выполнения запросов является либо отобранное по определённым критериям множество записей, либо изменение в таблицах.
Важным преимуществом применения БД в информационных системах является обеспечение независимости данных от прикладных программ. Это дает возможность пользователям не заниматься проблемами представления данных на физическом уровне: размещение данных в памяти, методов доступа к ним и т.п.
Такая независимость достигается поддерживаемым СУБД многоуровневым представлением данных на логическом (пользовательскому) и физическом уровне. Вообще под СУБД можно понимать любой программный продукт, который поддерживает процессы создания, ведения и использования БД.
За моделью данных СУБД (как и БД) разделяют на иерархических, сетевых, реляционных, объектно-ориентированые и другие типы. Некоторые СУБД могут одновременно поддерживать несколько моделей данных.
РАЗДЕЛ 1
АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ ИССЛЕДОВАНИЯ
- Предметная область
В данном курсовом проекте в качестве предметной области рассматривается фирма, которая занимается продажей компьютеров и комплектующих. Будущая база данных должна решать следующие задачи: учёт товара, выдача данных о поставщиках и поставляемых ими товарах (фирма-поставщик, его реквизиты, наименование товаров, характеристики, цены), вычисляет суммы оплаты.
Магазин является юридическим
лицом и имеет в своей
Магазин располагается в нескольких помещениях (склад, торговый зал). Фирма имеет персонал, который состоит из: директора, заместитель директора, главный бухгалтер, бухгалтер, менеджер по продажам, программист, который является системным администратором и консультантом по программному обеспечению одновременно, секретарь, продавцы-консультанты. При видении любого рода документации сотрудника отличает его собственный код сотрудника, который присваивается ему при приёме на работу. Так же при приёме нового сотрудника про него записывают следующие данный: домашний адрес, мобильный телефон, которые служат для связи с работником; идентификационный код – для проведения финансовых операций (выплата зарплаты, налоговый сбор).
У фирмы есть поставщики, осуществляющие поставку компьютеров и комплектующих на склад магазина. Поставка товара осуществляется при наличии заявки на поставку оформленную на имя фирмы-поставщика. Каждый поставщик инициализируется с помощью присвоенного ему кода поставщика. В магазине каждый поставщик оставляет о себе контактную информацию: контактный телефон, адрес, название своей фирмы, ФИО представителя. С помощью этой информации данная фирма поддерживает связь с поставщиками. Для того, чтобы идентифицировать фирму-поставщика, магазин присваивает ей уникальный код. В случае, если фирма-поставщик не укладывается в срок, фирма-заказчик может ждать, пока её товар прибудет, а может отказаться от покупки товара.
Клиент, приходя в магазин, взаимодействует с менеджером, который, в свою очередь, осуществляет продажу компьютеров или комплектующих. Операции с денежными средствами и отбивку чека осуществляет так же менеджер. Клиенту предоставляется широкий выбор товаров, малая часть которых находится в выставочном зале. По товарам, которые отсутствуют в зале, имеется некоторая информация: наименование товара, стоимость продажи, описание, технические характеристики и наличие. При отсутствии товара на складе магазина менеджер проверяет наличие его на складе фирмы поставщика. Товар на складе различают по его уникальному коду и, конечно же, наименованию. Когда клиент делает заявку на определенный вид продукта, он оформляется, как физическое лицо и ему присваивается уникальный код. Если клиент заинтересован и готов приобрести товар, то клиент с сотрудником составляют заявку на заказ. Для этого клиент должен предоставить свои личные данные: ФИО, контактный телефон, адрес проживания. Так как фирма может делать только один заказ в день на поставку товара, то конечная форма на поставку имеет свой уникальный код, а так же информацию о: дата заказа, код товара, количество товара, код сотрудника, который делала заказ, код клиента, который заказывал тот или иной товар связанный с клиентом по уникальному коду товара. Уникальные данные позволяет фирме следит когда, кем и для кого был сделан данный заказ. После оплаты покупаемого товара, клиент получает чек с указанием товара и его стоимости, на основании которого со склада ему отгружают необходимый товар.
- Атрибуты
Таким образом на основании рассмотренных данных можно выделить такие атрибуты:
Про сотрудников фирмы известны такие данные: ФИО сотрудника, код сотрудника, должность, домашний адрес, мобильный телефон, идентификационный код.
Про клиента фирма тоже имеет определенные данные: ФИО клиента, идентификационный код клиента, мобильный телефон, адресс.
Поставщик предоставляет такую информацию: Название поставщика, код поставщика, ФИО представителя, адрес, контактный телефон.
Так как предприятие заказывает продукцию у поставщика, заметим, что заказывать можем только один раз в день, то есть за один день мы можем дать только один заказ. Заказ имеет свои атрибуты: Код заказа, дата подачи заявки, код товара, количество товара, код сотрудника, код клиента.
В свою очередь товар, который заказывают, имеет такие атрибуты: код товара, код поставки, наименование товара, стоимость закупки, стоимость продажи, количество, технические характеристики, описание, наличие.
Теперь определим типы
связей между существующими
ФИО сотрудника - Должность (M:N)
ФИО сотрудника - домашний адрес (M:N)
ФИО сотрудника - мобильный телефон (1:N)
ФИО сотрудника - идентификационный код (1:N)
ФИО сотрудника - код сотрудника (1:N)
Должность - домашний адрес (M:N)
Должность - мобильный телефон (1:N)
Должность - идентификационный код (1:N)
Должность - код сотрудника (1:N)
домашний адрес - мобильный телефон (M:N)
домашний адрес – идентификационный код (1:N)
домашний адрес - код сотрудника (1:N)
мобильный телефон - идентификационный код (1:1)
мобильный телефон - код сотрудника (1:1)
идентификационный код - код сотрудника (1:1)
Название поставщика - код поставщика (1:N)
Название поставщика - ФИО представителя (M:N)
Название поставщика - Адрес (M:N)
Название поставщика - мобильный телефон (1:N)
код поставщика - ФИО представителя (N:1)
код поставщика - Адрес (1:1)
код поставщика - мобильный телефон (1:1)
ФИО представителя - Адрес (1:N)
ФИО представителя - мобильный телефон (1:N)
Адрес - мобильный телефон (1:N)
Код заявки - дата заказа (1:1)
Код заявки – дата поставки (1:1)
Код заявки - количество товара (M:N)
дата заказа - количество товара (M:N)
код товара - количество товара (M:N)
код товара - наименование товара (N:1)
код товара - стоимость закупки (N:1)
код товара - стоимость продажи (N:1)
код товара - количество (M:N)
код товара – технические характеристики (N:1)
код товара – описание (N:1)
код поставки - наименование товара (M:N)
код поставки - стоимость закупки (M:N)
код поставки - стоимость продажи (M:N)
код поставки - количество (M:N)
код поставки - технические характеристики (M:N)
код поставки - описание (M:N)
наименование товара - стоимость закупки (N:1)
наименование товара - стоимость продажи (N:1)
наименование товара - количество (N:1)
наименование товара - технические характеристики (1:1)
наименование товара - описание (1:1)
стоимость закупки - стоимость продажи (1:1)
стоимость закупки - количество (M:N)
стоимость закупки - технические характеристики (M:N)
стоимость закупки - описание (M:N)
стоимость продажи - количество (M:N)
стоимость продажи - технические характеристики (M:N)
стоимость продажи - описание (M:N)
технические характеристики - описание (1:1)
ФИО клиента - идентификационный код клиента (1:N)
ФИО клиента - мобильный телефон (1:N)
ФИО клиента - адрес (1:N)
идентификационный код клиента - мобильный телефон (1:1)
идентификационный код клиента - адрес (1:1)
адрес - мобильный телефон (1:N)
1.3 Объекты
После того как установлены связи между атрибутами и на основе предметной области можно выделить такие объекты: Сотрудник, Клиент, Заказ, Товар, Поставщик.
Объект Сотрудник с такими атрибутами: ФИО сотрудника, должность, домашний адрес, мобильный телефон, идентификационный код. Рассмотрим типы связей между атрибутами:
ФИО сотрудника- Должность (M:N)
ФИО сотрудника- домашний адрес (M:N)
ФИО сотрудника- мобильный телефон (1:N)
ФИО сотрудника- идентификационный код (1:N)
ФИО сотрудника- код сотрудника (1:N)
Должность- домашний адрес (M:N)
Должность- мобильный телефон (1:N)
Должность- идентификационный код (1:N)
Должность- код сотрудника (1:N)
домашний адрес- мобильный телефон (M:N)
домашний адрес- идентификационный код (1:N)
домашний адрес- код сотрудника (1:N)
мобильный телефон- идентификационный код (1:1)
мобильный телефон- код сотрудника (1:1)
идентификационный код- код сотрудника (1:1)
Анализируя все связи мы, можем определить каждую составляющую объекта Сотрудник код сотрудника, таким образом, код сотрудника – первичный ключ.
Объект Клиент (ФИО клиента, идентификационный код клиента, адрес, мобильный телефон), рассмотрим его типы связей:
ФИО клиента- идентификационный код клиента (1:N)
ФИО клиента- мобильный телефон (1:N)
ФИО клиента - адрес (1:N)
идентификационный код клиента - мобильный телефон (1:1)
идентификационный код клиента - адрес (1:1)
адрес - мобильный телефон (1:N)
Анализируя все связи мы, можем определить каждую составляющую объекта Клиент через идентификационный код клиента, таким образом, идентификационный код клиента – первичный ключ.
Объект Заказ (Код заказа дата заказа, дата поставки, количество товара), рассмотрим его типы связей:
Код заявки - дата заказа (1:1)
Код заявки - дата поставки (1:1)
Код заявки - количество товара (M:N)
дата заказа - количество товара (M:N)
Объект Поставщик (Название поставщика, код поставщика, ФИО представителя, адрес, контактный телефон), рассмотрим его типы связей:
Название поставщика - код поставщика (1:N)
Название поставщика - ФИО представителя (M:N)
Название поставщика - Адрес (M:N)
Название поставщика - контактный телефон (1:N)
код поставщика - ФИО представителя (N:1)
код поставщика - Адрес (1:1)
код поставщика - контактный телефон (1:1)
ФИО представителя - Адрес (1:N)
ФИО представителя - контактный телефон (1:N)
Адрес - контактный телефон (1:N)
Анализируя все связи мы можем определить каждую составляющую объекта Поставщик через код поставщика, таким образом код поставщика – первичный ключ.
Объект Товар (код товара, код поставки, наименование товара, стоимость закупки, стоимость продажи, количество, технические характеристики, описание, наличие), рассмотрим его типы связей:
Код товара - код поставки (N:1)
код товара - наименование товара (N:1)
код товара - стоимость закупки (N:1)
код товара - стоимость продажи (N:1)
код товара - количество (M:N)
код товара – технические характеристики (N:1)
код товара – описание (N:1)
код товара – наличие (N:1)
код поставки - наименование товара (M:N)
код поставки - стоимость закупки (M:N)
код поставки - стоимость продажи (M:N)
код поставки - количество (M:N)
код поставки - технические характеристики (M:N)
код поставки - описание (M:N)
наименование товара - стоимость закупки (N:1)
наименование товара - стоимость продажи (N:1)
наименование товара - количество (N:1)
наименование товара - технические характеристики (1:1)
наименование товара - описание (1:1)
стоимость закупки - стоимость продажи (1:1)
стоимость закупки - количество (M:N)
стоимость закупки - технические характеристики (M:N)
стоимость закупки - описание (M:N)
стоимость продажи - количество (M:N)
стоимость продажи - технические характеристики (M:N)
стоимость продажи - описание (M:N)
технические характеристики - описание (1:1)
Анализируя все связи мы, можем определить каждую составляющую объекта Товар через код товара, таким образом, код товара – первичный ключ.
1.4 Концептуальная модель
Первым этапом и самым главным этапом в процессе проектирования и создания базы данных, является разработка концептуальной модели.
Цель концептуального моделирования – обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Основными конструктивными элементами концептуальных моделей являются сущности, связи между ними и их свойства (атрибуты).
Сущность – любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе.
Атрибут – поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей.
Ключ – минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся.
Связь – ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных – это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи.
Установим тип связи между объектами. Зная, что тип связи между объектами это тип связи между их ключами, будем иметь:
Код сотрудника à код заявки (1:N).
Значит тип связи между объектами Сотрудник и Заявка «один ко многим». Это очевидно, так как один сотрудник может делать несколько заявок.
Код клиента à код заявки (1:N)
Тип связи между объектами Сотрудник и Заявка «один ко многим», так как один клиент может подавать несколько заявок на товар.
Код заявки à код товара (1:N)
Тип связи между объектами Заявка и Товар «один ко многим», так как в одной заявке может быть заказано несколько товаров.
Код поставщика à код товара (1:N).
Тип связи между объектами Поставщик и Товар «один ко многим», так как один поставщик поставляет много товара.
Проиллюстрируем вышесказанное концептуальной моделью.
Сотрудник |
Код сотрудника |
ФИО сотрудника |
должность |
домашний адрес |
мобильный телефон |
дата рождения |
идентификационный код |
КЛИЕНТ |
Код клиента |
ФИО клиента |
домашний адрес |
мобильный телефон |
Заказ |
Код заказа |
дата заказа |
дата поставки |
Товар |
Код товара |
наименование товара |
стоимость закупки |
стоимость продажи |
количество |
технические характеристики |
описание |
наличие |
Поставщик |
Код поставщика |
название поставщика |
ФИО представителя |
адрес |
контактный телефон |
должность представителя |
РАЗДЕЛ 2
ПОСТРОЕНИЕ МАТЕМАТИЧЕСКОЙ МОДЕЛИ
2.1 Основные понятия теории реляционных баз данных
База данных - это совокупность взаимосвязанных данных с таким минимальным избытком, которая дает возможность их использования оптимальным способом для одного или нескольких дополнений в определенной предметной области человеческой деятельности.
Для построения БД из предметной области выделяют объекты, которые представляют интерес для пользователей БД.
Предметная область - это отображение в базе данных совокупности объектов реального мира с их связями, которые относятся к области знаний и имеют практическую ценность.
Объект – информационная единица предметной области . Различают понятие тип объекта и экземпляр объекта.
Тип объекта - это совокупность его свойств (атрибутов).
Экземпляр объекта – физический представитель данного объекта.
Каждый объект имеет свои характерные свойства, которые имеют название атрибутов.
Атрибут – логично неделимый элемент, который относится к свойству некоторого объекта или процесса.
Для каждого объекта определено некоторое множественное число его значений, которое имеет название домен.
Атрибуты делятся на атрибуты-признаки и атрибуты-основы. Атрибуты-признаки (ключи) являются качественной характеристикой объекта и чаще всего используются в логических операциях: выборка, сравнение, сортировка, и т.п.
Атрибуты-основы характеризуют количественную сторону объекта и используются в вычислительных операциях.
Атрибуты могут быть простыми или сложными. Например, атрибут адрес может быть простым, а может состоять из отдельных элементов – индекс, город, улица, дом, квартира, но обрабатываться вместе.
Между атрибутами существует связь. Тип связи определяется таким образом:
1:1 (один экземпляр атрибута А связанный только с одним экземпляром атрибута В)
1:N (один экземпляр атрибута А связанный с несколькими экземплярами атрибута В)
M:N (несколько экземпляров атрибута А связанные с несколькими экземплярами атрибута В)
Аналогичные типы связей существуют между объектами.
Атрибут объекта, по значению которого можно однозначно определить значение всех основных атрибутов называют возможным ключом данного объекта.
Среди возможных ключей различают первобытный ключ и альтернативные ключи.
Первобытный ключ назначается самим проектировщиком.
Совокупность объектов и связей между ними представляют собой концептуальную модель предметной области.
Реляционная база данных представляет собой совокупность отношений, которые содержат всю информацию, которая должна храниться в БД.
Математическое отношение определяется следующим образом.
Пусть данные “N” множественных чисел D1, D2.,Dn, тогда R –видношення над этими множественными числами, если R – множественное число упорядоченных n-кортежей вида <d1,d2.,dn>, где d1 – элемент из D1, d2 – элемент из D2., dn – элемент из Dn. D1, D2.,Dn называются доменами отношения R.
Число n называют арностью отношения, а количество кортежей называет мощностью отношения.
Любой первичный документ
можно представить в виде отношения.
База данных определенной предметной
области представлена в виде совокупности
первичных документов, преобразованных
в отношение может
Однако такая база данных имеет целый ряд недостатков: избыточность, дублирование информации, противоречивость, аномалии, связаны из исключением новых данных и удалением старых. Для ликвидации таких неудобств при проектировании баз данных используется теория нормализации отношений. Теория нормализации отношений представляет набор формальных процедур, которые позволяют формировать такие наборы отношений для хранения в базе данных, которые владеют накращими свойствами при редактировании и наименее избыточные в сравнении с другими отношениями, которые содержат такую же информацию.
2.2 Методы проектирования отношений
Существует два метода проектирования отношений: декомпозиция и метод ER-диаграмм.
Рассмотрим метод декомпозиции.
Сначала создается универсальное отношение, которое включает в себя все атрибуты, выделенные в предметной области. Универсальное отношение может содержать как простые так и составные атрибуты. Составной атрибут состоит из двух или больше простых атрибутов.
Первая нормальная форма отношения - это такая форма отношения, в которой все его атрибуты простые.
Пусть x и y- два атрибута некоторого отношения. Y функционально зависит от x, если в любой момент каждому значению x отвечает одно значение атрибута y.
х→y - х в функциональной зависимости выступает детерминантом.
Вторая нормальная форма – отношение находится во второй нормальной форме, если оно находится в первой нормальной форме, и каждый детерминант представляется возможным ключом.
Третья нормальная форма - отношение находится в третьей нормальной форме, если оно находится во второй нормальной форме и не имеет транзитивных зависимостей.
Нормальная форма Бойса - Кодда (усилена третья нормальная форма) изучает зависимость ключевых атрибутов от не ключевых, если такие зависимости существуют, то необходимо лишить отношение от них.
При декомпозиции необходимо следить за тем, чтобы обратная операция слияния была выполнена без потерь.
Метод декомпозиции целесообразно использовать, если количество атрибутов не превышает 20.
Рассмотрим метод ER-диаграмм.
ER-диаграммы представляются графическим отображением связи между объектами (сущностями). Объекты изображаются в виде прямоугольников, а связки – в виде ромбов.
Выделяют все возможные
Как было сказано выше, проектирование может вестись двумя способами: декомпозицией и методом ER-диаграмм.
Моделирование предметной области с помощью объектов (сущностей) реального мира и связей между ними называется концептуальным проектированием. Наиболее важная и распространенная модель, полученная в результате концептуального проектирования - это ER (Escence Relation)-модель, или модель Сущность - Связь. Основные понятия ER-модели: сущность, связь, атрибут. Моделирование предметной области с помощью этого метода базируется на использовании диаграмм, которые содержат небольшое число разных компонентов: сущность, атрибут, класс принадлежности сущности, связь, степень связи. Метод декомпозиции не рационально использовать при количестве атрибутов больше 20. Следовательно, для проектирования используем метод ER-диаграмм.
Для правильного построения диаграмм используют правила:

- База данных по продажи сотовых телефонов
- База данных, построенная на основе классов
- База данных по учету успеваемости ВУЗа
- База данных «Продажа косметики»
- База данных «Продажи книг»
- База данных проектной организации
- База данных "Производство мягкой мебели"
- База данных отдела кадров
- База данных отдела кадров предприятия ОПТТОРГ
- База данных по гарантийным талонам
- База данных под управлением клиента C#
- База данных по ИКС
- База данных по информатике
- База данных «Поликлиника»