Разработка СУБД "Японские автомобили"

Содержание

Введение………………………………………………………………………………стр. 3

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

2  Концептуальное  проектирование. ……………………………………………….стр. 5

2.1  Перечень  сущностей (обосновать список). …………………………….стр. 5

2.2  Перечень  атрибутов. ……………………………………………………..стр. 6

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

3.1  Модель  “сущность-связь”.……………………………………………….стр. 8

3.2  Классификация  связей. …………………………………………………..стр. 9

4  Реляционная  модель БД. …………………………………………………стр. 10

4.1  Функциональные  зависимости между атрибутами. …………………..стр.10

4.2  Выбор  ключей. ………………………………………………………….стр. 12

4.3  Нормализация  отношений. ……………………………………………..стр. 13

5  Даталогическое  проектирование БД. …………………………………………..стр. 14

5.1 Состав  таблиц БД. ……………………………………………………….стр. 14

5.2 Поддержание целостности. ……………………………………………..стр. 15

6  Запросы  к БД. …………………………………………………………………….стр. 18

7  Разработка  механизмов защиты данных от  несанкционированного доступа...стр.21

8  Требования  к техническому обеспечению. …………………………………….стр. 23

9  Инструкция  по использованию БД. …………………………………………….стр. 24

9.1 Вызов программы. ……………………………………………………….стр. 24

9.2 Описание отчетов. ……………………………………………………….стр. 30

Заключение………………………………………………………………………….стр. 31

Список использованной литературы………………………………………………стр. 32 
 
 
 
 

Введение

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

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

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

     В рамках данного курсового проекта  была разработана реляционная база данных для решения экономической  задачи «Японские автомобили».

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

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

     Автомобиль - это средство передвижения, оснащенное двигателем внутреннего сгорания.

     Япония  является одной из первых стран  в мире по производству автомобилей.

К японским автомобилям  относятся автомобили марок: Toyota,  Mitsubishi,  Honda,  Nissan, Mazda, Hunday и т.д.  Каждый автомобиль имеет свои индивидуальные характеристики: модель, цвет, номер двигателя и цену. Именно на эти индивидуальные характеристики обращает внимание  покупатель или поставщик.

      Участниками автомобильного бизнеса  являются:

• Клиент – организация или частное лицо покупающее автомобиль;
• Поставщик – организация или частное лицо поставляющее автомобили на продажу;

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

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

     Данное  приложение позволяет пользователю о:

• вносить в базу данных информацию о поставщиках и клиентах салона:

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

• вносить в базу данных информацию об автомобилях: модель, цвет, номер двигателя, цена;
• вносить информацию о проводимых операциях (купли, продажи):

код операции, дата операции, код поставщика (клиента), номер двигателя автомобиля над  которым проводилась экономическая  операция;

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

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

     Для вывода информации на экран были разработаны  специальные формы, упрощающие работу с записями таблиц БД. К выходной информации относится форма с  запросами, а так же формы, позволяющие  осуществить быстрый просмотр по записям: «Клиенты», «Автомобили», «Поставщики», «Журнал поставок», «Журнал реализации». Если необходимо вывести информацию на печать, то её можно предварительно просмотреть ее в форме отчетов.

     Данная  база данных предоставляется следующие  возможности:

1. Несколько уровней доступа пользователей с различными правами.
2. Просмотр интересующей информации в специальных формах.
3. Просмотр информации в форме отчетов.
4. Поиск информации по заданным критериям.
5. Добавление, изменение, удаление информации по изменению состояния на рынке автомобилей.

2. Концептуальное  проектирование

     2.1 Перечень сущностей

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

          На основе анализа предметной  области были выбраны следующие  сущности:

1. «авто» - (Автомобили) содержит краткую информацию об автомобилях;
2. «клиенты» (Клиенты) содержит информацию о клиентах салона;
3. «поставщ» (Поставщики) содержит информацию о поставщиках;
4. «журнал_постав» (Журнал поставки) содержит информацию о        поступивших в продажу автомобилях;
5. «журнал_реализ» (Журнал реализации) содержит информацию о операциях связанных с продажей автомобилей;
6. «пользователи» (Пользователи) содержит о пользователях и паролях; 

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

     2.2 Перечень атрибутов

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

          Ниже приведен перечень атрибутов  сущностей рассматриваемой предметной  области.

     Таблица «авто» содержит:

1. модель – модель автомобиля;
2. цвет – цвет автомобиля;
3. номер_двиг – номер двигателя автомобиля;
4. цена – цена автомобиля;

     Таблица «клиенты» содержит:

1. код_кл – код клиента;
2. наимен – наименование клиента;
3. адрес – адрес клиента;
4. тел – номер телефона клиента;
5. факс – номер факса клиента;
6. e_mail – email клиента

     Таблица «поставщ» содержит:

1. код_пост – код поставщика;
2. наимен – наименование поставщика;
3. адрес – адрес поставщика;
4. тел – телефон поставщика;
5. факс – факс поставщика;
6. e_mail – email поставщика.

     Таблица «журнал_постав» содержит:

1. код_опер_пос – код операции поступления;
2. дата – поставки автомобиля;
3. номер_двиг – номер двигателя  автомобиля поступленного в продажу;
4. код_пост – код поставщика.

     Таблица «журнал_реализ» содержит:

1. код_опер_реал – код_операции продажи;
2. дата – дата продажи автомобиля;
3. номер_двиг – номер двигателя проданного автомобиля;
4. код_кл – код клиента.

     Таблица «пользователи» содержит:

1. польз – наименование пользователя приложения;
2. пароль – пароль;

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

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

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

     3.1 Модель «сущность-связь»

     Модель  «сущность - связь» основана на использовании 3-х основных конструктивных элементах:

1. сущность
2. атрибут
3. связь

     Взаимосвязи между таблицами БД могут быть типизированы по следующим основным видам:

1. отношение “один к одному” (1:1) означает, что каждая запись одной таблицы соответствует только одной записи в другой таблице;
2. отношение “один ко многим”  (1:М) возникает, когда одна запись взаимосвязана со многими другими;
3. отношение “многие к одному” означает, что многие записи связаны с одной (М:1);
4. отношение “многие ко многим” (M:N) возникает между двумя таблицами в тех случаях, когда:

• одна  запись из первой таблицы может быть связана более чем с одной записью из второй таблицы;

• одна запись из второй таблицы может быть связана более чем с одной записью из первой таблицы.

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

2. Классификация связей

Таблица 3.1 «Классификация связей» 
 
 
 
 
 

4. Реляционная модель БД

1. Функциональные зависимости между атрибутами

     Атрибут Y функционально зависит от атрибута X, если в каждый момент времени каждому значению X соответствует единственное значение Y. Обозначается записью X → Y. 

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

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

  Таблица 4.1.1. Функциональные зависимости между  атрибутами сущности «пользователи»

  Таблица 4.1.2. Функциональные зависимости между атрибутами сущности «авто»

  Таблица 4.1.3. Функциональные зависимости между атрибутами сущности «журнал_реализ» 

Таблица 4.1.4. функциональные зависимости между атрибутами сущности «клиенты» 

     Таблица 4.1.5. Функциональные зависимости между атрибутами сущности «поставщ»

Таблица 4.1.6. Функциональные зависимости между атрибутами сущности «журнал_постав» 
 
 
 

2. Выбор ключей

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

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

Таблица 4.1.6. «Ключи» 

     Опишем  ключи, составленные для имеющихся  сущностей:

1. Сущность «авто» имеет ключ «номер_двиг».
2. Сущность «клиенты» имеет ключ «код_кл»
3. Сущность «поставщики» имеет ключ «код_пост»
4. Сущность «журнал_реализ» имеет ключ «код_опер_р»
5. Сущность «журнал_постав» имеет ключ «код_опер_п»

3. Нормализация  отношений

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

     Реляционная база данных считается эффективной, если она обладает следующими характеристиками:

• Отсутствие избыточности
• Минимальное использование null – значений
• Предотвращение потери информации

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

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

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

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

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

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

1. Состав  таблиц БД

     Таблица 5.1.1 «авто»