Размещено на http://allbest.ru

Министерство образования и науки Российской Федерации

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

«КАБАРДИНО-БАЛКАРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ им. Х.М. БЕРБЕКОВА»

Институт информатики, электроники и робототехники

Кафедра Информационной безопасности

КУРСОВОЙ ПРОЕКТ

На тему: «Разработка базы данных “Фирма по продаже запчастей”»

По дисциплине «Теория баз данных»

Выполнил: Мисиров Расул Исламович

Студент 2 курса, направление «ИБ»

Проверила: Москаленко Л.А.

Преподаватель каф. ИиИБ

Нальчик 2019г.



СОДЕРЖАНИЕ

Введение

1. Теоретические сведения

1.1 Общие положения

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

1.2.1 Инфологическое проектирование

1.2.2 Определение требований к операционной обстановке

1.2.3 Выбор СУБД и других программных средств

1.2.4 Логическое проектирование реляционной БД

1.2.5 Физическое проектирование БД

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

2. Проектирование реляционной базы данных «Фирма по продаже запчастей»

2.1 Инфологическое проектирование

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

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

2.2 Определение требований к операционной обстановке

2.3 Выбор СУБД и других программных средств

2.4 Логическое проектирование реляционной БД

2.4.1 Преобразование ER-диаграммы в схему базы данных

2.4.2 Составление реляционных отношений

2.4.3 Нормализация полученных отношений (до 4НФ)

2.4.4 Определение дополнительных ограничений целостности

2.4.5 Описание групп пользователей и прав доступа

2.5 Реализация проекта базы данных

Заключение

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



Введение

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

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

Обычно объемы информации, с которыми приходится иметь дело таким системам, достаточно велики, а сама информация имеет достаточно сложную структуру.

Поэтому весь объем информации легче всего представить в виде База Данных.

Базы данных (БД) стали основой информационных систем и изменили методы работы многих организаций.

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

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

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

БД могут применяться как вспомогательное средство, позволяющее реализовать какую-то полезную функцию.

Задачи работы: применить на практике знания, полученные в процессе изучения курса "Базы данных", и получение практических навыков создания автоматизированных информационных систем (АИС), основанных на базах данных; проанализировать и исследовать предметную область “Фирма по продаже запчастей”; построить ER и реляционную модель данных.



1. Теоретические сведения

1.1 Общие положения

Проектирование базы данных (БД) является одной из наиболее сложных и ответственных задач, связанных с созданием АИС.

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

Опишем вкратце процесс проектирования реляционной базы данных. (Подробно этот процесс изложен в [1, 2]).

База данных - это, фактически, модель предметной области (ПрО). Значит, для создания БД надо сначала проанализировать ПрО и создать её модель (это называется инфологическим проектированием).

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

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

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

Модель ПрО может быть описана любым удобным для разработчика способом (словесное описание, набор формул, диаграмма потоков данных и т.п.). Но, если при проектировании баз данных используется метод сущность-связь, то схема ПрО выполняется в виде ER-диаграммы (entity-relation diagram, диаграмма «сущность-связь»).

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

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

В результате всех этих операций создаётся концептуальная схема БД - основной документ для базы данных.

Далее, на этапе физического проектирования полученные отношения описываются на языке DDL (Data definition language) - языке определения данных, который поддерживается выбранной СУБД. Также необходимо определить способы хранения данных (кластеризация, хеширование) и способы доступа к данным (индексирование) и создать соответствующие индексы и кластеры (если нужно). Если пользователей АИС можно разделить на группы по характеру решаемых задач, то для каждой группы создаётся свой набор прав доступа к объектам БД.[5]

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

Итак, процесс проектирования включает в себя следующие шаги:

1. Определение задач, стоящих перед базой данных.

2. Сбор и анализ документов, относящихся к исследуемой предметной области.

3. Описание особенностей ПрО, которые позволяют установить зависимости и связи между объектами (субъектами) предметной области.

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

5. Определение групп пользователей и перечня задач, стоящих перед каждой группой.

6. Выбор аппаратной и программной платформы для реализации БД.

7. Выбор СУБД (системы управления базой данных).

8. Создание логической схемы БД.

9. Создание схем отношений, определение типов данных атрибутов и ограничений целостности.

10. Нормализация отношений (до третьей или четвёртой нормальной формы).

11. Определение прав доступа пользователей к объектам БД.

12. Написание текста создания основных объектов базы данных на языке SQL в синтаксисе выбранной СУБД (пользователи, таблицы и др.).

13. Написание текста создания вспомогательных объектов базы данных (представления, индексы, триггеры, роли и т.д.).

Эти шаги можно объединить с 5 этапов:

Инфологическое проектирование (1-5).

Определение требований к операционной обстановке, в которой будет функционировать информационная система (6).

Выбор системы управления базой данных (СУБД) и других инструментальных программных средств (7).

Логическое проектирование БД (8-11).

Физическое проектирование БД (12-13).

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

1.2.1 Инфологическое проектирование

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

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

Основными подходами к созданию инфологической модели предметной области являются [1]:

1. Функциональный подход к проектированию БД ("от задач").

2. Предметный подход к проектированию БД ("от предметной области").

3. Метод "сущность-связь" (entity-relation, ER-method).

Мы будем использовать метод "сущность-связь" как наиболее распространённый. Приведём основные термины, которыми мы будем пользоваться:

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

Атрибут - свойство сущности. Различают:

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

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

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

Основные и производные атрибуты. Значение основного атрибута не зависит от других атрибутов; значение производного атрибута вычисляется на основе значений других атрибутов. Например, возраст вычисляется на основе даты рождения и текущей даты.

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

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

Связь - это осмысленная ассоциация между сущностями. Для связи указывается название, тип (факультативная или обязательная), степень (1:1, 1:n или m:n) и кардинальность (унарная, бинарная, тернарная или n-арная).

1.2.2 Определение требований к операционной обстановке

На этом этапе производится оценка требований к вычислительным ресурсам, необходимым для функционирования системы, определение типа и конфигурации конкретной ЭВМ, выбор типа и версии операционной системы. Объём вычислительных ресурсов зависит от предполагаемого объёма проектируемой базы данных и от интенсивности их использования. Если БД будет работать в многопользовательском режиме, то требуется подключение её к сети и наличие соответствующей многозадачной операционной системы [1].

1.2.3 Выбор СУБД и других программных средств

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



1.2.4 Логическое проектирование реляционной БД

На этапе логического проектирования разрабатывается логическая (концептуальная) структура БД. Для реляционной модели существуют формальные правила, которые позволяют преобразовать инфологическую модель ПрО в виде ER-диаграммы в логическую схему базы данных. Кроме получения схемы БД в целом на этом этапе выполняют создание схем отношений и их нормализацию. Этот этап более подробно рассмотрен в п.2 "Пример проектирования реляционной базы данных".[3]

1.2.5 Физическое проектирование БД

Этап физического проектирования заключается в определении схемы хранения, т.е. физической структуры БД. Схема хранения зависит от той физической структуры, которую поддерживает выбранная СУБД. Физическая структура БД, с одной стороны, должна адекватно отражать логическую структуру БД, а с другой стороны, должна обеспечивать эффективное размещение данных и быстрый доступ к ним. Результаты этого этапа документируются в форме схемы хранения на языке определения данных (DDL, Data Definition Language) выбранной СУБД. Принятые на этом этапе решения оказывают огромное влияние на производительность системы.

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



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

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

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

При неправильно спроектированной схеме БД могут возникнуть аномалии модификации данных. Они обусловлены отсутствием средств явного представления типов множественных связей между объектами ПрО и неразвитостью средств описания ограничений целостности на уровне модели данных.[4]

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

Механизм нормализации реляционных отношений разработал Э.Ф. Кодд (E.F. Codd).

Этот механизм позволяет по формальным признакам любое отношение преобразовать к третьей нормальной форме.

Нормализация схемы отношения выполняется путём декомпозиции схемы. Декомпозицией схемы отношения R называется замена её совокупностью схем отношений А_i таких, что

,

и не требуется, чтобы отношения А_i были непересекающимися.

Первая нормальная форма относится к понятию простого и сложного (составного или многозначного) атрибута (см. п.1.2.1).

Первая нормальная форма (1НФ). Отношение приведено к 1НФ, если все его атрибуты простые.

Для того чтобы привести к 1НФ отношение, содержащее сложные атрибуты, нужно:

1) разбить составные атрибуты на простые,

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

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

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

Атрибут X в функциональной зависимости XY называется детерминантом отношения.

В нормализованном отношении все неключевые атрибуты функционально зависят от ключа отношения.

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

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

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

Для того чтобы привести отношение ко 2НФ, нужно:

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

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

Третья нормальная форма основана на понятии транзитивной зависимости.

Пусть X, Y, Z - атрибуты некоторого отношения. При этом XY и YZ, но обратное соответствие отсутствует, т.е. Z не зависит от Y или Y не зависит от X. Тогда говорят, что Z транзитивно зависит от X (XZ).

Третья нормальная форма (3НФ). Отношение находится в 3НФ, если оно находится во 2НФ и каждый неключевой атрибут нетранзитивно зависит от первичного ключа.

Для того чтобы привести отношение к 3НФ, нужно:

построить проекцию, исключив транзитивно зависящие от ключа атрибуты;

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

Исключение составляют случаи, когда для транзитивной зависимости XZ (XY и YZ) либо Z зависит от Y, либо Y зависит от X, т.е. между атрибутами X и Y, например, существует связь 1:1. В такой ситуации декомпозиция отношения не производится.[5]

Четвертая нормальная форма основана на понятии многозначной зависимости. Многозначная зависимость существует, если заданным значениям атрибута X соответствует множество, состоящее из нуля (или более) значений атрибута Y (X-»Y).

Различают тривиальные и нетривиальные многозначные зависимости. Тривиальной называется такая многозначная зависимость X-»Y, для которой Y X или X U Y = R, где R - рассматриваемое отношение.

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

Четвертая нормальная форма (4НФ). Отношение находится в 4НФ, если оно находится в 3НФ и в нём отсутствуют нетривиальные многозначные зависимости.

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

Описание этого метода достаточно подробно изложено в [1], поэтому, чтобы не повторяться, будем рассматривать этот метод на примере проектирования конкретной базы данных.



2. Проектирование реляционной базы данных «Фирма по продаже запчастей»

2.1 Инфологическое проектирование

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

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

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

В соответствии с предметной областью система строится с учётом следующих особенностей:

- Каждый сотрудник оформляет множество накладных, накладную может оформлять несколько сотрудников.

- Сотрудник может участвовать в нескольких продажах, но конкретную продажу может проводить лишь конкретный сотрудник.

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

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

- На складе может поставлять товар несколько поставщиков, каждый поставщик может доставить товар на любой склад.



Для создания ER-модели необходимо выделить сущности предметной области:

1) Накладные. Атрибуты: код заказчика, код товара, № накладной, дата заключения.

2) Продажи. Атрибуты: дата, заказчик, данные заказчика, код товара, количество товара, № покупки, полученная сумма.

3) Заказчики. Атрибуты: ФИО, код заказчика, адреса, телефоны.

4) Склад. Атрибуты: код поставщика, код товара, количество(шт), наименование, отдел, стоимость.

5) Поставщики. Атрибуты: код поставщика, поставщик, телефоны, адреса.

6) Сотрудники. Атрибуты: ФИО, пол, оклад, должность, дата рождения, адреса, телефоны, дата приема на работу.

Рис. 1. ER-диаграмма «Фирма по продаже запчастей»



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

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

1. Руководители фирмы:

- руководство фирмой;

- развитие отношений с корпоративными клиентами;

- расширение клиентской базы;

- организация эффективной и бесперебойной работы фирмы;

- контроль поставок;

- выполнение финансовых показателей;

- управление персоналом;

- определение потребности фирмы в кадрах и подбор персонала.

2. Отдел продаж:

- налаживание сбыта товаров;

- прогнозирование роста объема в продажах на перспективу;

- обеспечение качественного сервиса;

- продажа запчастей.

3. Отдел закупок:

- обеспечение фирмы всеми необходимыми для ее деятельности материальными ресурсами требуемого качества;

- поиск, анализ данных, выбор поставщиков;

- заключение договоров и контроль исполнения;

- ведение реестра поставщиков;

- контроль за выполнением планов закупок, составление соответствующей отчетности.

4. Склад:

- складирование и хранение товара;

- транспортировка грузов;

- разгрузка и приемка товара;

- обеспечение безопасности содержимого склада.

5. Бухгалтерия:

- подготовка и принятие плана счетов;

- своевременное предоставление полной и достоверной бухгалтерской и управленческой информации о деятельности фирмы;

- учет всех хозяйственных операций фирмы;

- учет исполнения бюджетов фирмы.

2.2 Определение требований к операционной обстановке

Информационная система «Фирма по продаже запчастей» является продуктом, направленным на конкретный диапазон деятельности, поэтому она должна отвечать требованиям предметной области:

- являться программой, использование которой возможно только в данной предметной области;

- поддерживать современные технологии и протоколы передачи данных посредством Microsoft Access.

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

- одновременно осуществляется около пяти проектов(заказов), работа над проектом(заказом) продолжается в среднем 20 минут (по 1К на каждый проект);

- каждый проект (заказ) состоит в среднем из четырёх этапов (по 0,5К на этап);

- в фирме работают около 20 сотрудников (по 0,5К на каждого сотрудника);

- в выполнении каждого проекта (заказа) в среднем участвуют 2 сотрудника (по 0,2К);

- данные о совершенных сделках (выполненных заказах) переводятся в архив (накапливаются в архиве БД).

- Тогда объём памяти для хранения данных за первый год примерно составит:

M_д = 2(10*1+10*4*0,5+20*0,5+(10*2*0,2)) = 90 К

Для данной БД требуемый объём памяти мал, поэтому никаких специальных требований к объёму внешней и оперативной памяти компьютера не предъявляется.

2.3 Выбор СУБД и других программных средств

Анализ информационных задач показывает, что для реализации требуемых функций подходят почти все СУБД для ПЭВМ (MS Access, Firebird, MySQL и др.).

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

Для выполнения своей курсовой работы я выбрал Microsoft Office Access или -- реляционная система управления базами данных (СУБД) корпорации Microsoft. Входит в состав пакета Microsoft Office. Имеет широкий спектр функций, включая связанные запросы, связь с внешними таблицами и базами данных. Благодаря встроенному языку VBA, в самом Access можно писать приложения, работающие с базами данных.[6]

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



2.4 Логическое проектирование реляционной БД

2.4.1 Преобразование ER-диаграммы в схему базы данных

База данных создаётся на основании схемы базы данных. Для преобразования ER-диаграммы в схему БД приведём уточнённую ER-диаграмму, содержащую атрибуты сущностей (рис.2).

Рис. 2. Уточнённая ER-диаграмма «Фирма по продаже запчастей»

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

Все отношения в данной базе данных имеют связь типа 1:n (один-ко-многим). Данный тип связи реализуется через внешний ключ. Внешнему ключу должен соответствовать первичный или уникальный ключ основного (родительского) отношения.[7]

Для схемы базы данных используются обозначения, представленные на рис. 3.

Рис. 3. Обозначения, используемые на схеме базы данных

Полученная схема реляционной базы данных (рис.4):

Рис. 4. Схема РБД «Фирма по продаже запчастей», полученная из ER-диаграммы

2.4.2 Составление реляционных отношений

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

Потенциальными ключами отношения ЗАКАЗЧИКИ являются атрибуты Код заказчика и Фамилия. Код заказчика - первичный ключ, так как занимает меньше места.

Таблица 1. Схема отношения Заказчики (Clients)

Содержание поля	Имя поля	Тип, длина	Примечания
Код заказчика	C_CODE	N(10)	первичный ключ
ФИО	C_NAME	C(100)	обязательное поле
Адрес	C_ADDR	C(40)	многозначное поле
Телефон	C_PHONE	N(20)	многозначное поле

В отношении СОТРУДНИКИ потенциальным ключом является поле ФИО, но так как оно занимает достаточно много места. Введем суррогатный первичный ключ Табельный номер.

Таблица 2. Схема отношения Сотрудники (Employees)

Содержание поля	Имя поля	Тип, длина	Примечания
Табельный номер	E_ID	N(4)	суррогатный первичный ключ
ФИО	E_NAME	C(100)	обязательное поле
Дата рождения	E_BORN	D	обязательное поле
Пол	E_GENDER	C(1)	обязательное поле, 'м' или 'ж'
Должность	E_POST	C(30)	обязательное поле
Оклад	E_SAL	N(10)	обязательное поле, >6000
Дата приема на работу	E_DATE	D	обязательное поле
Адрес	E_ADDR	C(30)	многозначное поле
Телефон	E_PHONE	N(20)	многозначное поле



Потенциальным ключом для отношения НАКЛАДНЫЕ является атрибут Код товара.

Таблица 3. Схема отношения Накладные (Overhead)

Содержание поля	Имя поля	Тип, длина	Примечания
Код заказчика	O_ID	N(10)	обязательное поле
Код товара	O_PRODUCT	N(10)	первичный ключ
№ накладной	O_NUMBER	N(10)	обязательное поле
Дата заключения	O_DATE	D	обязательное поле

Потенциальным ключом для отношения ПОСТАВЩИКИ является атрибут Код поставщика.

Таблица 4. Схема отношения Поставщики (Supplier)

Содержание поля	Имя поля	Тип, длина	Примечания
Код поставщика	S_CODE	N(10)	первичный ключ
Поставщик	S_SUPP	C(50)	обязательное поле
Адрес	S_ADDR	C(30)	многозначное поле
Телефон	S_PHONE	N(20)	многозначное поле

Первичным ключом отношения СКЛАД является атрибут Код товара

Таблица 5. Схема отношения Склад (Storage)

Содержание поля	Имя поля	Тип, длина	Примечания
Код товара	S_CODE	N(10)	первичный ключ
Код поставщика	S_SUPP	N(10)	обязательное поле
Наименование товара	S_TITLE	C(40)	обязательное поле
Отдел	S_DEPART	C(30)	обязательное поле
Количество	S_COUNT	N(10)	обязательное поле
Стоимость	S_COST	N(10)	обязательное поле



Потенциальным ключом отношения ПРОДАЖИ является атрибут Код товара

Таблица 6. Схема отношения Продажи (Sale)

Содержание поля	Имя поля	Тип, длина	Примечания
Код товара	S_ CODE	N(10)	первичный ключ
Код заказчика	S_ CLIENT	N(10)	обязательное поле
Дата покупки	S_DATE	D	обязательное поле
Количество товара	S_QUANTITY	N(10)	обязательное поле
№ покупки	S_NUMBER	N(10)	обязательное поле
Полученная сумма	S_SUMM	N(8)	обязательное поле

2.4.3 Нормализация полученных отношений (до 4НФ)

1НФ. Для приведения таблиц к 1НФ составим прямоугольные таблицы (одно значение атрибута - одна ячейка таблицы) и разобьем сложные атрибуты на простые.

В отношениях СОТРУДНИКИ и ЗАКАЗЧИКИ разделим атрибут ФИО на два атрибута Фамилия и Имя, отчество.

Многозначные атрибуты Адрес и Телефон из отношения СОТРУДНИКИ вынесем в отдельное отношение АДРЕСА-ТЕЛЕФОНЫ СОТРУДНИКИ. Также домашние и мобильные телефоны, адреса клиентов из отношений ЗАКАЗЧИКИ, ПОСТАВЩИКИ вынесем в отношение АДРЕСА-ТЕЛЕФОНЫ ЗАКАЗЧИКИ, АДРЕСА-ТЕЛЕФОНЫ ПОСТАВЩИКИ.

В отношениях АДРЕСА-ТЕЛЕФОНЫ СОТРУДНИКИ и АДРЕСА-ТЕЛЕФОНЫ ЗАКАЗЧИКИ, АДРЕСА-ТЕЛЕФОНЫ ПОСТАВЩИКИ нет потенциальных ключей, т.к. на эти отношения никто не ссылается.

2НФ. Все отношения находятся во 2НФ, т.к. нет составного первичного ключа.

3НФ. В отношении СОТРУДНИКИ атрибут Оклад зависит от атрибута Должность. Создадим отношение ДОЛЖНОСТИ, перенесём в него атрибуты Должность и Оклад, а первичным ключом сделаем название должности.

4НФ. Отношения АДРЕСА-ТЕЛЕФОНЫ клиентов и сотрудников нарушают 4НФ, т.к. не всякий телефон привязан к конкретному адресу (т.е. мы имеем две многозначных зависимости в одном отношении). Но выделять Телефоны в отдельное отношение не стоит, т.к. эти сведения носят справочный характер и не требуется их автоматическая обработка.[8]

Отношения, полученные после нормализации, приведены в табл. 7-15.

Таблица 7. Схема отношения Сотрудники (Employees)

Содержание поля	Имя поля	Тип, длина	Примечания
Табельный номер	E_ID	N(4)	суррогатный первичный ключ
Фамилия	E_SURNAME	C(25)	обязательное поле
Имя Отчество	E_NAME	C(30)	обязательное поле
Дата рождения	E_BORN	D	обязательное поле
Пол	E_GENDER	C(1)	обязательное поле, 'м' или 'ж'
Должность	E_POST	C(30)	внешний ключ (к Posts)
Дата приема на работу	E_DATE	D	обязательное поле

Таблица 8. Схема отношения Адреса-Телефоны Сотрудники (AdrTelEmp)

Содержание поля	Имя поля	Тип, длина	Примечания
Табельный номер	A_ID	N(4)	внешний ключ (к Employees)
Адрес	A_ADDR	C(30)
Телефон	A_PHONE	N(20)

Таблица 9. Схема отношения Заказчики (Clients)

Содержание поля	Имя поля	Тип, длина	Примечания
Код заказчика	C_CODE	N(10)	первичный ключ
Фамилия	C_SURNAME	C(25)	обязательное поле
Имя, отчество	C_NAME	C(30)	обязательное поле



Таблица 10. Схема отношения Адреса-Телефоны Заказчики (AdrTelClients)

Содержание поля	Имя поля	Тип, длина	Примечания
Код заказчика	A_ CODE	N(10)	внешний ключ (к Clients)
Адрес	A_ADDR	C(30)
Телефон	A_PHONE	N(20)

Таблица 11. Схема отношения Должности (Posts)

Содержание поля	Имя поля	Тип, длина	Примечания
Название должности	P_POST	C(30)	первичный ключ
Оклад	P_SAL	N(10)	обязательное поле, >6000

Таблица 12. Схема отношения Накладные (Overhead)

Содержание поля	Имя поля	Тип, длина	Примечания
Код заказчика	O_ID	N(10)	обязательное поле
Код товара	O_PRODUCT	N(10)	первичный ключ
№ накладной	O_NUMBER	N(10)	обязательное поле
Дата заключения	O_DATE	D	обязательное поле

Таблица 13. Схема отношения Поставщики (Supplier)

Содержание поля	Имя поля	Тип, длина	Примечания
Код поставщика	S_CODE	N(10)	первичный ключ
Поставщик	S_SUPP	C(50)	обязательное поле
Адрес	S_ADDR	C(30)	многозначное поле
Телефон	S_PHONE	N(20)	многозначное поле

Таблица 14. Схема отношения Склад (Storage)

Содержание поля	Имя поля	Тип, длина	Примечания
Код товара	S_CODE	N(10)	первичный ключ
Код поставщика	S_SUPP	N(10)	обязательное поле
Наименование товара	S_TITLE	C(40)	обязательное поле
Отдел	S_DEPART	C(30)	обязательное поле
Количество	S_COUNT	N(10)	обязательное поле
Стоимость	S_COST	N(10)	обязательное поле



Таблица 15. Схема отношения Продажи (Sale)

Содержание поля	Имя поля	Тип, длина	Примечания
Код товара	S_ CODE	N(10)	первичный ключ
Код заказчика	S_ CLIENT	N(10)	обязательное поле
Дата покупки	S_DATE	D	обязательное поле
Количество товара	S_QUANTITY	N(10)	обязательное поле
№ покупки	S_NUMBER	N(10)	обязательное поле
Полученная сумма	S_SUMM	N(8)	обязательное поле

2.4.4 Определение дополнительных ограничений целостности

Перечислим ограничения целостности, которые не указаны в табл. 7-15.

1. В поле Оклад хранится величина минимального оклада сотрудника. Значение поля больше 6000.

2. Атрибут Пол может принимать одно из двух значений: 'м' или 'ж'

Схема базы данных после нормализации приведена на рис. 5.

Рис. 5. Окончательная схема БД «Фирма по продаже запчастей»



2.4.5 Описание групп пользователей и прав доступа

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

s - чтение данных (select);

i - добавление данных (insert);

u - модификация данных (update);

d - удаление данных(delete).

Таблица 16. Права доступа к таблицам для групп пользователей

Таблицы	Группы пользователей (роли)
	Руководители фирмы	Руководители отдела закупок	Сотрудники отдела продаж	Сотрудники отдела кадров
Накладные	SIUD	S	SIUD
Продажи	SIUD	S	SIUD
Сотрудник	S			SIUD
Должности	S			SIUD
Адреса-телефоны сотрудники	S			SIUD
Склад	S	SIUD	SUID
Поставщики	S	SIUD	S	S
Заказчики	S	SIUD	S	S
Адреса-телефоны заказчики	S	SIUD	S	S

2.5 Реализация проекта базы данных

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

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

Заполняем поля нашими данными: код заказчика, код товара, № накладной, дата заключения.

Каждому полю присваиваем тип данных. Типы данных необходимо выбрать из раскрывающегося списка.[9]

Рис. 6. Таблица «Накладные»

Таким же образом создаем ещё 8 таблиц, называем их «Заказчики», «Сотрудники», «Поставщики», «Продажи», «Должности», «Склад», «Адреса-телефоны сотрудники» и «Адреса-телефоны заказчики».

Рис. 7. Таблица «Заказчики»



Рис. 8. Таблица «Сотрудники»

Рис. 9. Таблица «Поставщики»

Рис. 10. Таблица «Продажи»

Рис. 11. Таблица «Должности»



Рис. 12. Таблица «Склад»

Рис. 13. Таблица «Адреса-телефоны сотрудники»

Рис. 14. Таблица «Адреса-телефоны заказчики»

Следующий шаг - это установка связей между таблицами в окне Схема данных.

Для этого в окне Схема данных необходимо переместить поле «Код поставщика» из таблицы Поставщики на соответствующее поле таблицы Склад, в результате этой операции появится окно «Изменение связей».

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

Рис. 15. Схема базы данных

информационный операционный реляционный база

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

В базе данных «Фирма по продаже запчастей» были созданы следующие запросы:

Рис. 16. Запрос «Адреса и телефоны сотрудников женского пола»

Рис. 17. «Запрос на остаток товара»

Рис. 18. «Запрос на сопоставление товара и поставщика»

Рис. 19. Запрос «Сотрудники с окладом больше 20000»



Рис. 20. Запрос «Товары, подходящие к концу»

Рис. 21. Запрос «Учет продаж по магазину»

Рис. 22. Запрос «Учет продаж (по отделу грузовые автомобили)»

Рис. 23. Запрос «Учет продаж (по отделу легковые автомобили)»



Рис. 24. Запрос на добавление записи «Сотрудники»

Рис. 25. Запрос на удаление

Разработка приложения базы данных (формы, отчеты). Для каждой таблицы, может быть создана ленточная форма.

Форма - средство отображения данных на экране и управления ими.

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

Наиболее удобными способами создания форм являются создание формы с помощью конструктора и с помощью мастера.

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

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

В данной базе данных были созданы следующие формы:

Рис. 26. Форма «Адреса-Телефоны Сотрудников»

Рис. 27. Форма «Оклад сотрудников»



Рис. 28. Форма «Продажи»

Рис. 29. Форма «Склад»

Рис. 30. Форма «Сотрудники»



После создания форм, приступаем к созданию отчета.

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

Отчёты могут быть открыты в трёх режимах: в режиме конструктора, в режиме предварительного просмотра и в режиме мастера. Режим конструктора используют для создания нового или изменения структуры существующего отчета. Режим предварительного просмотра позволяет просматривать данные в том виде, в котором они будут размещены на печатных страницах. В режиме просмотра образца отображается макет отчёта с образцами данных. Если форма или отчёт создаются с помощью мастера, то по умолчанию задаются стандартные характеристики формы или отчёта, определяемые используемым шаблоном.

В данной базе данных были созданы следующие отчеты:

Рис. 31. Отчет «Адреса-Телефоны Сотрудники»



Рис.32. Отчет «Заказчики»

Рис.33. Отчет «Сотрудники»

Рис.34. Отчет «Товары, подходящие к концу»



Рис.35. Отчет «Учет продаж по магазину»

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

Рис.36. Главная кнопочная форма



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

Рис.37. Администрирование базы данных



Заключение

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

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

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

В процессе работы над курсовым проектом приобретены практические навыки создания базы данных в СУБД MicrosoftAccess с момента обследования предметной области и до настройки параметров запуска.



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

Основная литература

1. Карпова Т.С. Базы данных: модели, разработка, реализация. - СПб.: Питер,2002.-304 с.

2. С.М. Диго. Базы данных. М.: Финансы и статистика, 2005. - 590 с.

3. Советов Б.Я. Базы данных: теория и практика. Учебник для бакалавров - Изд. Юрайт. - 2007.

4. Агальцов В.П. Базы данных. В 2-х кн. Учебник. - М.: ИД «ФОРУМ»: ИНФРА-М, 2011.- 360 с.

5. Диго С.М. Access 2000. Учебное пособие. - М: ТК Велби, 2006. - 240 с.

6. Давыдова Е.М. Новгородова Н.А. Базы данных. - Изд. ТУСУР. 2007 (ЭБС Лань).

7. Муравьев А.И. Базы данных. - Изд. ТУСУР. 2006 (ЭБС Лань).

8. Омельченко Л.Н. Самоучитель Visual FoxPro 8. - СПб.:БХВ - -Петербург, 2003.- 688 с.

9. Максимов Е.М., Бахтадзе Н.Н. Базы данных в системах управления производственными процессами: учебное пособие. - Изд. Московского государственного открытого университета. - 2011 г. (ЭБС Книгафонд).

10. Васильева М.А.,Балакина Е.П. Введение в базы данных: Учебное пособие. - Издательство: МИИТ, 2007 г. (ЭБС Книгафонд).

Периодические издания

1. "Открытые системы / СУБД": Журнал. - АО "Открытые системы"

Интернет-ресурсы

1.Интернет-ресурс «Интернет университет инфор. технологий» www.intuit.ru

2. Основы современных баз данных. С.Д. Кузнецов. http://www.citforum.ru/database/osbd/contents.shtml

Размещено на Allbest.ru

...