Разработка базы данных

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

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

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

Для работы с данными используются системы управления базами данных (СУБД). Основные функции СУБД — это определение данных (описание структуры баз данных), обработка данных и управление данными.

Microsoft Access является настольной СУБД реляционного типа. Microsoft Access хранит все данные в одном файле, хотя и распределяет их по разным таблицам.

В данной курсовой работе рассматривается:

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

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

2) Логическое проектирование.

3) Физическое проектирование Формирования запросов на языке SQL.

• 1. Системный проект
• 1.1 Описание предметной области
• Предметной областью данного курсового проекта является база ГИБДД.
• Для полноценной работы базы данных, необходимы следующие сущности:

· Водитель.

· Владелец.

· Транспортное средство.

· VIN.

· Протоколы нарушений Формулирование основной цели разработки.

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

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

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

Основные запросы, на которые ориентирована база данных:

1. Запрос о выводе владельца по номеру ПТС.

2. Запрос о выводе информации о нарушении и его участнике.

3. Запрос о выводе информации об участнике нарушения и сумма штрафа.

4. Запрос по VIN коду информации о владельце и страховке.

5. Запрос по государственному номеру информации о машине.

6. Запрос по поиску владельцев определенных марок машин и моделей.

7. Запрос о наличии ОСАГО и КАСКО Описание источников и форм исходных данных Источниками разработанной базы данных являются данные из Интернета.

Поэтому нельзя полностью доверять данной информации.

Требование к программному обеспечению.

Использовались следующие программы:

— Microsoft SQL Server 2005 Standart ver.9.0.1.

— Computer Associated ERWin 4.0.

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

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

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

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

1.2 Описание данных.

Схема данных в SQL Server 2005.

ER-модель в Erwin.

Logical.

Physical.

Таблица основных сущностей Основных сущностей для моей базы данных необходимо три:

· Сущность с информацией о водителе.

· Сущность с информацией о владельце.

· Сущность с информацией о VIN.

· Сущность с информацией о ТС.

· Сущность с информацией о нарушениях Водитель Владелец.

VIN.

Протокол Транспортное средство.

1.3 Проектирование логической структуры базы данных методом сущность-связь.

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

Средством моделирования предметной области на этапе концептуального проектирования является модель «сущность-связь». Часто ее называют ER-моделью. В ней моделирование структуры данных предметной области базируется на использовании графических средств — ER-диаграмм. В наглядном виде они представляют связи между сущностями.

Основными понятиями ER-диаграммы являются сущность, атрибут, связь.

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

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

В рассматриваемой предметной области ГАИ можно выделить три связи.

1. Водитель может иметь несколько автомобилей, а автомобиль принадлежит одному водителю, то создадим связь «имеет» между таблицами «водитель» и «автомобиль». В этом случае связь 1 имеет тип «один-ко-многим» (1:М). Так как каждый водитель обязательно имеет автомобиль, а каждый автомобиль обязательно принадлежит водителю, то класс принадлежности обеих сущностей является обязательным. На рис. 1. представлена ER-диаграмма для связи типа 1: М.

2. Водитель может получить несколько взысканий, взыскание применяется к одному водителю, то создадим связь «получает» между таблицами «водитель» и «взыскание». В этом случае связь 2 имеет тип «один-ко-многим» (1:М). Так как каждый водитель не обязательно получает взыскание, а каждое взыскание обязательно применяется к водителю, то класс принадлежности сущности «водитель» необязательный, а сущности «взыскание» обязательный.

3. Одному и тому же нарушению могут соответствовать несколько взысканий, взысканию соответствует единственное нарушение, то создадим связь «соответствует» между таблицами «нарушение» и «взыскание». В этом случае связь 3 имеет тип «один-ко-многим» (1:М). Так как нарушению не обязательно соответствует взыскание, а каждому взысканию обязательно соответствует нарушение, то класс принадлежности сущности «нарушение» необязательный, а сущности «взыскание» обязательный.

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

ER-модель в совокупности с наборами атрибутов сущностей может служить примером концептуальной модели предметной области или концептуальной схемы базы данных.

1.4 Проектирование логической структуры базы данных методом нормальных форм.

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

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

Правила генерации таблиц из ER-диаграмм опираются на два основных фактора — тип связи и класс принадлежности сущности. Изложим их.

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

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

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

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

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

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

На ER-диаграмме связи 1: М, представленной на рисунок 4, класс принадлежности сущностей «водитель», «автомобиль» является обязательным.

Анализ состава атрибутов полученных таблиц A, B, C, D, E, F показывает, что таблица C является составной частью таблицы А, таблица F — составной частью таблицы D. Поэтому таблицы C, F можно исключить из рассмотрения. Оставшиеся таблицы A, B, D, E можно связать посредством связи первичных и вторичных ключей. В результате получим реляционную модель для ER-модели предметной области ГАИ.

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

1) Минимизация избыточных данных;

2) Минимальное использование отсутствующих значений (Null-значений);

3) Предотвращение потери информации.

В базе данных присутствует избыточность, если одни и те же данные находятся в нескольких местах. Минимизировать избыточность данных позволяет процесс, называемый нормализацией таблиц. Методику нормализации таблиц разработал американский ученый А. Ф. Кодд в 1970 году. Ее суть сводится к приведению таблиц к той или иной нормальной форме. Были выделены три нормальные формы — 1НФ, 2НФ, 3НФ. Позже стали выделять нормальную форму Бойса-Кодда (НФБК), а затем 4НФ и 5НФ. Каждая последующая нормальная форма вводит определенные ограничения на хранимые в базе данные.

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

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

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

Определение 3НФ: таблица находится в 3НФ, если она удовлетворяет требованиям 2НФ и не содержит транзитивных зависимостей. Транзитивной зависимостью называется функциональная зависимость между неключевыми полями. Все созданные таблицы находятся в 3НФ. Таким образом, реляционная модель предметной области ГАИ после нормализации таблиц остается прежней.

2. Технический проект.

2.1 Выбор состава технических и программных средств.

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

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

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

Для обработки запросов к БД пишутся соответствующие программы, которые представляют прикладное программное обеспечение.

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

2.2 Физическая структура баз данных.

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

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

Создадим новую базу данных. Для этого запустим Access, выполнив команду Пуск / Программы/Microsoft Access. После чего в появившемся окне Microsoft Access нажмем Файл / Создать…/Новая база данных… (рис.).

Окно Microsoft Access.

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

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

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

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

Таблица «Автомобиль» в режиме конструктора Таблица «Взыскания» в режиме конструктора Таблица «Нарушения» в режиме конструктора Таблица «Автомобиль» в режиме просмотра Таблица «Взыскания» в режиме просмотра Таблица «Нарушения» в режиме просмотра Для связывания таблиц базы данных нужно вызвать окно схемы данных по команде Сервис / Схема данных основного меню или с помощью одноименной команды контекстного меню окна базы данных.

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

В окне схемы данных выполним команду Связи / Добавить таблицу, где в появившемся диалоговом окне выделим все таблицы и нажмем на кнопку Добавить. По каждому связываемому полю таблицы выполним следующее: выделим поле, при нажатой левой кнопке мыши протащим указатель к полю связи другой таблицы и отпустим кнопку. При этом Access предлагает определить вид и параметры связи в соответствующем диалоговом окне (рис.). Командой Файл / Сохранить сохраним схему данных.

Окно определения вида и параметров связи На рисунке представлена схема данных базы данных ГАИ.

Схема данных базы данных ГАИ.

Заключение.

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

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

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

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

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

1. Балалаев М. А. Проектирование баз данных: Методические указания по выполнению курсового проекта по дисциплине «Базы данных» / М. А. Балалаев; ДВГУПС.

2. Каф. «Системы автоматизированного проектирования». Хабаровск: Изд — во ДВГУПС, 2007. — 30 с.

3. Гурвиц Г. А. Мюгозой Ассезз 2007. Разработка приложений на реальном примере/ Г. А. Гурвиц. — СПб.: БХВ-Петербург, 2007. — 672 с.

4. Кучма В. Н. Стандарты проектирования автоматизированных систем обработки данных: Учебное пособие для ВУЗов / В. Н. Кучма; ДВГУПС. Каф. «Информационные технологии и системы». — Хабаровск: Изд-во ДВГУПС, 2006. — 80 с.

5. Боровский А. Н. Программирование в Ое1рЫ 2005/ А. Н. Боровский. — СПб.: БХВ-Петербург, 2007. — 448 с.

6. Кандзюба СП. Ое1рЫ 5. Базы данных и приложения. Лекции и упражнения. /, СП. Кандзюба, В. Н. Громов — К.: Диасофт, 2010. — 592 с.

7. Дейт К.Дж. Введение в системы баз данных. Изд. 7 — М. — СПб. — Киев: Вильяме, 2011. — 1072 с.

8. Крёнке Д. Теория и практика построения баз данных. Изд. 8 — СПб.: Питер, 2008.-800 с.

9. Хансен Г., Хансен Дж. Базы данных. Разработка и управление. — М.: Бином, 2012. — 700 с.

10. Конноли Т., Бегг К., Страчан А. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. — М. — СПб. — Киев: Вильяме, 2010. — 1112 с.

Приложения.

Приложение 1.

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

Приложение 2.

Листинг SQL-запросов.

SELECT.

DvijeniaTovara. VidDvijeniaTovara, DvijeniaTovara. OptovaiPriceZacypki, DvijeniaTovara. PoznichhaiPriceProdaji, Tovar. Vid, Tovar. Price, Tovar. Quantity.

FROM DvijeniaTovara, Tovar.

WHERE (((DvijeniaTovara. CodeTovara)=[Tovar]. [CodeTovara]));

SELECT.

DvijeniaTovara. VidDvijeniaTovara, DvijeniaTovara. OptovaiPriceZacypki, DvijeniaTovara. PoznichhaiPriceProdaji, Postavchik. Surname, Postavchik. Name, Postavchik. Patronymic, Postavchik. Phone, Postavchik. Address, Tovar. Vid, Tovar. Price, Tovar. Quantity.

FROM DvijeniaTovara, Postavchik, Tovar.

WHERE (((DvijeniaTovara. CodeTovara)=[Tovar]. [CodeTovara]) AND ((DvijeniaTovara. CodePostavchika)=[Postavchik]. [CodePostavchika])).

ORDER BY Tovar. Vid;

SELECT DvijeniaTovara. OptovaiPriceZacypki, DvijeniaTovara. PoznichhaiPriceProdaji, Slujachi. Surname, Slujachi. Name, Slujachi. Patronymic, Slujachi. Address, Slujachi. Phone, Slujachi. Doljnost, Slujachi. Zarplata, Slujachi. Obrazovanie, Tovar. Vid, Tovar. Price, Tovar. Quantity.

FROM DvijeniaTovara, Slujachi, Tovar.

WHERE (((DvijeniaTovara. CodeSlujachego)=[Slujachi]. [CodeSlujachego]) AND ((DvijeniaTovara. CodeTovara)=[Tovar]. [CodeTovara]));

SELECT Postavchik. Surname, Postavchik. Name, Postavchik. Patronymic, Postavchik. Phone, Postavchik. Address, Tovar. Vid, Tovar. Price, Tovar. Quantity.

FROM Postavchik, Tovar.

WHERE (((Postavchik. CodeTovara)=[Tovar]. [CodeTovara]));

SELECT Slujachi. Surname, Slujachi. Name, Slujachi. Patronymic, Slujachi. Address, Slujachi. Phone, Slujachi. Doljnost, Slujachi. Zarplata, Slujachi. Obrazovanie, Tovar. Vid, Tovar. Price, Tovar. Quantity.

FROM Slujachi, Tovar;