Введение. 2
Глава 1. Проектирование базы данных. 5
1.1. Сбор данных. 5
1.2. Построение информационной логической модели базы данных. 7
1.3. Логическая структура базы данных. 1
Глава 2. Создание базы данных. 2
2.1. Краткая характеристика Access. 2
2.2. Разработка структуры таблиц. 3
2.3. Ввод данных. 4
2.4. Создание схемы данных. 6
2.5. Создание форм.. 8
2.6. Создание запросов. 11
2.7. Создание отчетов. 12
Заключение. 14
Список использованной литературы.. 16
Приложения. 17
Актуальность темы. Одним из важнейших условий обеспечения эффективного функционирования любой организации является наличие развитой автоматизированной информационной системы (АИС). Под АИС понимают все системы, реализующие автоматизированный сбор, обработку и манипулирование данными и включающие технические средства обработки данных, программное обеспечение и обслуживающий персонал. Современной формой АИС являются автоматизированные банки данных (АБД), которые включают в свой состав вычислительную систему, одну или несколько БД, систему управления базами данных (СУБД) и набор прикладных программ (ПП).
Степень изученности темы. Подсистемы АИС, занимающиеся хранением, поиском и выдачей информации, получили название автоматизированные банки информации (АБИ). В процессе развития существенно изменились принципы организации информации в АБИ. Ранее, подлежащие обработке данные хранились на магнитной ленте в виде простых последовательных файлов, а описание данных включалось в программы их обработки. При этом данные и программы оказывались жёстко связанными, что являлось существенным недостатком файловой организации информации. Действительно, при необходимости изменения организации информации, приходилось переделывать и программу. Для устранения этих недостатков был разработан новый подход к организации данных, разделивший данные от использующих их программ. Такая новая организация массивов данных получила название баз данных (БД).
Цель курсовой работы – проектирование базы данных «Клиенты» проката автомобилей.
В соответствии с поставленной целью в работе предполагается решить следующие задачи:
- сбор данных;
- построение информационной логической модели базы данных;
- логическая структура базы данных;
- краткая характеристика Access;
- разработка структуры таблиц;
- ввод данных;
- создание схемы данных;
- создание форм;
- создание запросов;
- создание отчетов.
В настоящее время практически во всех сферах человеческой деятельности используются базы данных. В том числе решение перечисленных задач позволит достигнуть цели, поставленной в курсовой работе, а именно, реализовать базу данных «Система учёта магазина », что позволит следить за движением товаров от момента их поступления от поставщиков до продажи клиентам. Данная база данных может применяться в различных организациях, занимающихся куплей-продажей товаров. Для обеспечения надежности системы управления данными необходимо выполнить следующие основные требования:
целостность и непротиворечивость данных,
достоверность данных,
простота управления данными,
безопасность доступа к данным.
Этим требованиям удовлетворяют реляционные базы данных, реализованные в современных профессиональных СУБД.
В реляционных моделях данных также сочетаются два фактора, которые и определяют большую популярность этой модели. Это простота и наглядность модели для пользователей-непрограммистов, с одной стороны, и серьезное теоретическое обоснование, с другой стороны. Кроме того, развитие формального аппарата представления и манипулирования данными в рамках реляционной модели сделали ее наиболее перспективной для использования в системах представления знаний, что обеспечивает качественно иной подход к обработке данных в больших информационных системах.
Полнота и достаточность базы данных в какой-либо предметной области в значительной степени зависит от сбора информации.
Сбор информации и её предварительная обработка должно одновременно отвечать целям конечного пользователя информации так и разработчика БД (прикладных программистов). Общая схема модели сбора и описания информации приведена на рисунке 1.
В концептуальной модели объединяются два представления: концептуальное представление объективно существующей предметной области и концептуальное представление субъективных информационных требований разработчиков.
Первое из этих представлений отображает объекты, процессы и предметы реального мира как составные части предметной области, их существенные свойства, а также взаимосвязи между этими элементами. Второе представление описывает данные и связи с точки зрения их обработки в СУБД.
Процесс построения концептуальной модели разделяется на два этапа:
1 этап – сбор и содержательный анализ априорной (доопытной) информации о предметной области и прикладных задачах пользователей;
2 этап – анализ данных и синтез концептуальной модели.
Первый этап предполагает сбор данных (результатов изменений или наблюдений, отчётов и различных документов технического, экономического, бухгалтерского и им подобного характера, опрос экспертов специалистов в данной предметной области) и выявление перечня задач организации или её отделов, которые могут быть решены с использованием разрабатываемой БД.
После сбора данных осуществляется визуальный контроль, регистрация, кодирование и комплектование их.
Визуальный контроль осуществляется для проверки чёткости заполнения, наличия реквизитов и отсутствие пропусков данных.
Кодирование данных означает присвоение кодов тем реквизитам, где имеется большой объём информации. Обычно кодируются наименования по специальным справочникам и классификаторам. Если их нет, то создаются свои коды.
Комплектование данных – это разбиение больших объёмов данных на комплекты (пачки), чтобы облегчить их поиск.
Составления списка всех используемых и создаваемых элементов данных может осуществляться в рамках одной таблицы (одного отношения) или нескольких таблиц.
На первом этапе проводится концептуальный анализ, имеющийся информации, целью которого является выявление элементов предметной области, их свойств и взаимосвязи. Другими словами – построение модели предметной области.
Информационно-логическая модель (ИЛМ) отображает данные предметной области в виде совокупности информационных объектов и связей между ними.
Информационный объект – это описание некоторой сущности предметной области – реального объекта, процесса явления или события. Информационный объект образуется совокупностью логически взаимосвязанных атрибутов, представляющих качественные и количественные характеристики сущности.
При проектировании ИЛМ можно выделить три основных подхода.
Сбор информации об объектах предметной области в рамках одной таблицы и последующая декомпозиция её на несколько взаимосвязанных таблиц (информационных объектов) на основе процедуры нормализации отношений.
Формулирование знаний о системе (определение типов исходных данных и их взаимосвязей) и требований к обработке данных, получение с помощью системы автоматизации проектирования и разработки баз данных готовой схемы БД и даже готовой прикладной информационной системы.
Структурирование информации для использования в БД в процессе проведения системного анализа на основе совокупности правил и рекомендаций.
Ниже рассмотрим первый из названных подходов, являющийся классическим и историческим первым.
Информационные объекты выделяются путём определения функциональных зависимостей между атрибутами. Совокупность атрибутов информационного объекта должна отвечать требованиям нормализации. Нормализация – это процесс превращения иерархической, сетевой структуры или исходной единой таблицы данных в реляционную структуру.
Основные требования нормализации.
Атрибуты каждого информационного объекта должен содержать уникальный идентификатор – ключ. Ключ является простым, если он состоит из одного атрибута, или составным, если из нескольких.
Все неуникальные идентификаторы – описательные атрибуты должны быть взаимозависимы (то есть между ними не должно быть функциональных зависимостей).
Все атрибуты, входящие в составной ключ, должны быть также взаимозависимы.
Каждый описательный атрибут должен быть функционально полно зависеть от ключа, то есть каждому значению ключа должно соответствовать только одно значение описательного атрибута.
При составном ключе описательные атрибуты должны зависеть целиком от всей совокупности атрибутов, образующих ключ.
Каждый описательный атрибут не должен зависеть от ключа транзитивно, то есть через другой промежуточный атрибут.
В случае транзитивной зависимости между атрибутами можно выполнить расщепление совокупности атрибутов с образованием двух информационных объектов вместо одного.
Выполнение требований нормализации обеспечивает построение реляционной БД без дублирования данных и возможность поддержания целостности при внесении изменений.
Таблица 1. Автомобили
| Автомобили | ||||||||||||
| Номерной знак | Зарегистрированный в | Марка, модель | Выпуск | Производство | Двигатель | Кузов | Цвет | Паспорт ТС | Свидетельство о регистрации | Сумма проката | Стоимость ТС | Фото |
| Е427ВУ30 | МОТОР ГИБДД г. Астрахани | Chevrolet Lanos | 2006 | Украина | 178618R | Y6DTF69Y0600259 | серебристый | серия 77 ТН №827176 от 28.06. 2006 г. | серия 30 ОУ №177300 от 09.08. 2006 г. | 37200 | 360000 | |
| Е433ВУ30 | МОТОР ГИБДД г. Астрахани | ВАЗ21074 | 2006 | Тольятти | 8700290 | 2421794 | темно-вишневый | серия 63 МЕ №784275 от 09.08. 2006 г. | серия 30 ОУ №1730406 от 09.08. 2006 г. | 20150 | 180000 | |
| М962ВХ30 | МОТОР ГИБДД г. Астрахани | RenaultMegane2p2a16a115e | 2006 | Турция | К4МС813R006592 | 36419983 | светло-серебристый | серия 77 ТТ №652069 от 04.09. 2006 г. | серия 30 РК №049880 от 06.12. 2006 г. | 77500 | 600000 | |
| О877ВХ30 | МОТОР ГИБДД г. Астрахани | ВАЗ21074 | 2006 | Тольятти | 8770115 | 2488783 | ярко-белый | серия 63 МК №375264 от 28.11. 2006 г. | серия 30 РК №052292 от 25.12. 2006 г. | 20150 | 180000 | |
| Р542ВУ30 | МОТОР ГИБДД г. Астрахани | Chevrolet Lanos | 2006 | Украина | 190736R | Y6DTF69Y060034722 | серебристый | серия 77 ТТ №682388 от 05.09. 2006 г. | серия 30 РА №539052 от 23.09. 2006 г. | 37200 | 360000 | |
| Р812ВТ30 | МОТОР ГИБДД г. Астрахани | ВАЗ21121 | 2006 | Тольятти | 1553594 | 0397653 | бело-зеленый | серия 63 МЕ №614814 от 04.05. 2006 г. | серия 30 ОС №665700 от 02.06. 2006 г. | 26350 | 250000 | |
| С946ВТ30 | МОТОР ГИБДД г. Астрахани | ВАЗ21150 | 2006 | Тольятти | 4403032 | 4222062 | светло-серебристый | серия 63 МЕ №111876 от 13.06. 2006 г. | серия 30 ОУ №168920 от 23.06. 2006 г. | 26350 | 250000 | |
| С947ВТ30 | МОТОР ГИБДД г. Астрахани | ВАЗ21101 | 2006 | Тольятти | 1587750 | 0966158 | бело-зеленый | серия 63 МЕ №111890 от 13.06. 2006 г. | серия 30 ОУ №168921 от 23.06. 2006 г. | 27900 | 260000 | |
| С948ВТ30 | МОТОР ГИБДД г. Астрахани | ВАЗ21140 | 2006 | Тольятти | 4403102 | 4221229 | светло-серебристый | серия 63 МЕ №575735 от 13.06. 2006 г. | серия 30 ОУ №168922 от 23.06. 2006 г. | 26350 | 250000 | |
| У578ВУ30 | МОТОР ГИБДД г. Астрахани | Nissan Primera | 2006 | Соединенное Королевство | 0756760 | 4135344 | серебристый | серия 77 ТН №899545 от 10.06. 2006 г. | серия 30 ОХ №920170 от 07.11. 2006 г. | 77500 | 700000 | |
| У901ВТ30 | МОТОР ГИБДД г. Астрахани | ВАЗ2115 | 2006 | Тольятти | 4403032 | 4221247 | светло-серебристый | серия 63 МЕ №101558 ОТ 05.06. 2006 г. | серия 30 ОУ №168923 от 23.06. 2006 г. | 26350 | 250000 | |
Последним этапом проектирования является построение логической структуры БД. Структура реляционной БД Access является адекватным отображением полученной информационно – логической модели предметной области, но требует дополнительных преобразований.