содержание
Глава 1. Проектирование базы данных
1.2. Построение информационной логической модели базы данных
1.3. Логическая структура базы данных
2.1. Краткая характеристика Access
2.2. Разработка структуры таблиц
Список использованной литературы
Введение
Актуальность темы. Одним из важнейших условий обеспечения эффективного функционирования любой организации является наличие развитой автоматизированной информационной системы (АИС). Под АИС понимают все системы, реализующие автоматизированный сбор, обработку и манипулирование данными и включающие технические средства обработки данных, программное обеспечение и обслуживающий персонал. Современной формой АИС являются автоматизированные банки данных (АБД), которые включают в свой состав вычислительную систему, одну или несколько БД, систему управления базами данных (СУБД) и набор прикладных программ (ПП).
Степень изученности темы. Подсистемы АИС, занимающиеся хранением, поиском и выдачей информации, получили название автоматизированные банки информации (АБИ). В процессе развития существенно изменились принципы организации информации в АБИ. Ранее, подлежащие обработке данные хранились на магнитной ленте в виде простых последовательных файлов, а описание данных включалось в программы их обработки. При этом данные и программы оказывались жёстко связанными, что являлось существенным недостатком файловой организации информации. Действительно, при необходимости изменения организации информации, приходилось переделывать и программу. Для устранения этих недостатков был разработан новый подход к организации данных, разделивший данные от использующих их программ. Такая новая организация массивов данных получила название баз данных (БД).
Цель курсовой работы – проектирование базы данных «Клиенты» проката автомобилей.
В соответствии с поставленной целью в работе предполагается решить следующие задачи:
- сбор данных;
- построение информационной логической модели базы данных;
- логическая структура базы данных;
- краткая характеристика Access;
- разработка структуры таблиц;
- ввод данных;
- создание схемы данных;
- создание форм;
- создание запросов;
- создание отчетов.
В настоящее время практически во всех сферах человеческой деятельности используются базы данных. В том числе решение перечисленных задач позволит достигнуть цели, поставленной в курсовой работе, а именно, реализовать базу данных «Система учёта магазина », что позволит следить за движением товаров от момента их поступления от поставщиков до продажи клиентам. Данная база данных может применяться в различных организациях, занимающихся куплей-продажей товаров. Для обеспечения надежности системы управления данными необходимо выполнить следующие основные требования:
целостность и непротиворечивость данных,
достоверность данных,
простота управления данными,
безопасность доступа к данным.
Этим требованиям удовлетворяют реляционные базы данных, реализованные в современных профессиональных СУБД.
В реляционных моделях данных также сочетаются два фактора, которые и определяют большую популярность этой модели. Это простота и наглядность модели для пользователей-непрограммистов, с одной стороны, и серьезное теоретическое обоснование, с другой стороны. Кроме того, развитие формального аппарата представления и манипулирования данными в рамках реляционной модели сделали ее наиболее перспективной для использования в системах представления знаний, что обеспечивает качественно иной подход к обработке данных в больших информационных системах.
Глава 1. Проектирование базы данных
1.1. Сбор данных
Полнота и достаточность базы данных в какой-либо предметной области в значительной степени зависит от сбора информации.
Сбор информации и её предварительная обработка должно одновременно отвечать целям конечного пользователя информации так и разработчика БД (прикладных программистов). Общая схема модели сбора и описания информации приведена на рисунке 1.
В концептуальной модели объединяются два представления: концептуальное представление объективно существующей предметной области и концептуальное представление субъективных информационных требований разработчиков.
Первое из этих представлений отображает объекты, процессы и предметы реального мира как составные части предметной области, их существенные свойства, а также взаимосвязи между этими элементами. Второе представление описывает данные и связи с точки зрения их обработки в СУБД.
Процесс построения концептуальной модели разделяется на два этапа:
1 этап – сбор и содержательный анализ априорной (доопытной) информации о предметной области и прикладных задачах пользователей;
2 этап – анализ данных и синтез концептуальной модели.
Первый этап предполагает сбор данных (результатов изменений или наблюдений, отчётов и различных документов технического, экономического, бухгалтерского и им подобного характера, опрос экспертов специалистов в данной предметной области) и выявление перечня задач организации или её отделов, которые могут быть решены с использованием разрабатываемой БД.
После сбора данных осуществляется визуальный контроль, регистрация, кодирование и комплектование их.
Визуальный контроль осуществляется для проверки чёткости заполнения, наличия реквизитов и отсутствие пропусков данных.
Кодирование данных означает присвоение кодов тем реквизитам, где имеется большой объём информации. Обычно кодируются наименования по специальным справочникам и классификаторам. Если их нет, то создаются свои коды.
Комплектование данных – это разбиение больших объёмов данных на комплекты (пачки), чтобы облегчить их поиск.
Составления списка всех используемых и создаваемых элементов данных может осуществляться в рамках одной таблицы (одного отношения) или нескольких таблиц.
На первом этапе проводится концептуальный анализ, имеющийся информации, целью которого является выявление элементов предметной области, их свойств и взаимосвязи. Другими словами – построение модели предметной области.
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 | |
1.3. Логическая структура базы данных
Последним этапом проектирования является построение логической структуры БД. Структура реляционной БД Access является адекватным отображением полученной информационно – логической модели предметной области, но требует дополнительных преобразований.
Каждый информационный объект модели данных отображается соответствующей реляционной таблицей. Структура таблиц определяется составом атрибутов соответствующего информационного объекта, где каждое поле (столбец) соответствует одному атрибуту объекта.
Ключевые атрибуты объекта образуют уникальный ключ реляционной таблицы. Строки (записи) таблицы соответствуют экземплярам объекта и формируются при заполнении таблицы.
Связи между объектами реализуются одинаковыми атрибутами – ключами связи в соответствующих таблицах. При этом ключом связи всегда является уникальный ключ главной таблицы. Ключом связи в подчинённой таблице является либо некоторая часть уникального ключа в ней, либо поле, не входящее в состав первичного ключа.
В Access может быть создана схема данных, наглядно отображающая логическую структуру БД. Внешний вид схемы данных практически совпадает с графическим представлением ИЛМ.
На этой схеме прямоугольники изображают таблицы БД с полным списком их полей, а связи показывают, по каким полям осуществляется взаимосвязь таблиц. Имена ключевых полей для наглядности выделены и находятся в верхней части полного списка полей каждой таблицы.
На этом заканчивается внемашинный этап проектирования реляционной БД и начинается этап создания БД непосредственно с помощью СУБД Access на компьютере.
Глава 2. Создание базы данных
2.1. Краткая характеристика Access
Система управления базой данных – это программные средства, с помощью которых можно создавать базы данных, наполнять их и работать с ними. Многие СУБД на самом деле являются не законченными продуктами, а специализированными языками программирования, с помощью которых каждый, освоивший данный язык, может сам создавать такие структуры, какие ему удобны, и вводить в них необходимые элементы управления.
Необходимость программирования всегда сдерживала широкое внедрение баз данных в управление и производство в малом бизнесе. Крупные предприятия могли позволить себе сделать заказы на программирование специализированной системы «под себя». Малым предприятиям зачастую не по силам было не только решить, но даже и правильно сформулировать эту задачу.
Положение изменилось с появлением в пакете MS Office СУБД Access. Ранние версии имели номера Access 2.0 и Access 95. Затем была версия Access 97 и последняя версия Access 2000. В настоящее время наиболее широкое распространение получила версия Access 97.
СУБД Access 97 является удобным средством для создания и эксплуатации достаточно мощных баз данных без необходимости что-либо программировать. В тоже время работа с Access не исключает возможности программирования. При желании систему можно развивать и настраивать собственными силами, но для этого надо владеть основами программирования на языке Visual Basic for Application (VBA).
Ещё одним дополнительным достоинством этой СУБД является интегрированность этой программы с MS Excel, Word и другими программными пакетами MS Office 97.
Система управления БД Access является системой управления реляционной БД и содержит комплекс прикладных программ, предназначенных для создания локальной БД на одном компьютере (ПК), общей базы данных в локальной сети с файл–сервером или создания приложения пользователя, работающего с БД на SQL – сервере.
Сеть обеспечивает аппаратную и программную поддержку обмена данными между компьютерами. СУБД Access следит за разграничением доступа разных пользователей к БД и обеспечивает защиту данных. База данных в сети с файл-сервером размещается на файловом сервере и может быть также на каждом ПК (рабочей станции). Но в любом случае, операции с ней производятся всегда с рабочей станции (ПК) пользователя. Для пользователя работа в сети со средствами Access практически не зависят от конфигурации сети и размещения СУБД.
2.2. Разработка структуры таблиц
На этапе проектирования определяется число информационных объектов (таблиц) базы, набор их полей (атрибутов), тип данных в этих полях, ключевые поля и связи между таблицами. Создание базы данных начинается с создания таблиц.
2.3. Ввод данных
Как бы тщательно не была спроектирована база данных, всегда возникает необходимость корректировать, изменять, добавлять и удалять данные, в общем, редактировать её объекты. Для этого можно использовать традиционные в Windows - приложениях инструменты: буфер Обмена и мышь.
Большинство данных, при редактировании которых курсор становиться текстовым (I), могут быть скопированы в БО, а именно:
- имена файлов, полей, таблиц;
- подписи, названия типов, тексты справок.
При работе с БО используются команды:
- вырезать (CTRL+X);
- копировать (CTRL+C);
- вставить (CTRL+V).
Использование БО при редактировании данных не всегда является удобным, поэтому предпочтительнее в этих случаях применять мышь.
В уже созданной таблице всегда можно переименовать название поля (столбца). Для этого надо дважды щёлкнуть мышью по имени поля и ввести новое имя.
Ширина строк и столбцов таблиц задана по умолчанию и для изменения их надо установить курсор на разграничительную линию и, нажав левую кнопку мыши, перетащить линию на нужное расстояние. Чтобы ширина столбца автоматически соответствовала длине записи надо дважды щёлкнуть мышью по разграничительной линии.
Программа MSA использует тот же интерфейс, что и остальные Windows-приложения. Поэтому, чтобы выполнить какие-либо действия над объектами, необходимо их выделить. Для выделения столбца необходимо щёлкнуть мышью в области его заголовка. Аналогично выделяется и строки. Чтобы выделить ячейку, надо установить курсор мыши в левом верхнем углу ячейки (курсор в виде +) и щёлкнуть мышью. Если просто щёлкнуть мышью в ячейке, то будут выделены только данные.
Для выделения блока ячеек необходимо выделить ячейку в левом верхнем углу блока и, нажав и удерживая левую кнопку мыши, протащить в правый нижний угол блока. Операции копирования, вставки, перемещения, удаления ячеек аналогичны приёмам работы с ячейками в электронных таблицах Excel.
Чтобы удалить таблицу в базе данных, надо на вкладке ТАБЛИЦЫ окна БД выделить её имя и нажать клавишу DELETE.
2.4. Создание схемы данных
Основным преимуществом создания БД в МSA является наличие связей с использованием ключевых полей таблиц. Вместо того, чтобы создавать одну большую громадную таблицу, создают несколько небольших и устанавливают между ними связи. Взаимосвязи позволяют объединить в запросах, формах и отчетах данные из разных таблиц.
Связи между таблицами графически отображаются в окне СХЕМА ДАННЫХ, где таблицы представлены списками полей, а связи - линии между полями.
Схема данных, прежде всего, ориентирована на работу с таблицами, отвечающими требованиям нормализацию. Это означает, что между таблицами могут быть установлены связи 1: М и 1: 1, для которых может автоматически поддерживаться связная целостность. Поэтому схему связи целесообразно строить в соответствии с ИЛМ, разработанной на этапе проектирования.
При построении схемы данных Access автоматически определяет по выбранному полю связи тип отношений между таблицами. Если поле, по которому нужно установить связь является уникальным ключом как в одной таблице, так и в другой, MSA выявляет отношение 1: 1. Если поле связи является уникальным ключом в одной таблице (главной), а в другой таблице (подчинённой) является не ключевым или входит в составной ключ, то есть значения его могут повторяться, программа выявляет отношение 1: М между записями главной таблицы к подчинённой. В этом случае можно задавать автоматическое поддержание целостности связей.
Между двумя таблицами может быть установлена связь - объединение по некоторому полю связи. Для связи-объединения может быть выбран один из трёх способов объединения записей:
Объединение только тех записей, в которых связанные поля обеих таблиц совпадают (устанавливается по умолчанию).
Объединение тех записей, в которых связанные поля обеих таблиц совпадают, а также объединение всех записей из первой таблицы, для которых нет связанных во второй, с пустой записью второй таблицы.
Объединение тех записей, в которых связанные поля обеих таблиц совпадают, а также объединение всех записей из второй таблицы, для которых нет связанных в первой, с пустой записью в первой таблицы.
Такие типы связей могут быть определены, если связь характеризуется 1: 1 или 1: М, а также, если тип отношения не может быть определён системой.
Связать таблицы можно двумя способами: с помощью Мастера подстановок или с помощью команды Схема данных.
2.5. Создание форм
Заполнение таблиц в базе данных трудоемкий и кропотливый процесс. Для упрощения ввода данных используются специальные объекты – формы. Форма представляет собой некий электронный бланк, в котором имеются поля для ввода данных. Данные в таблицы можно вносить и без форм, но существует несколько причин, по которым форма является незаменимым средством ввода данных.
Малоквалифицированному персоналу нельзя предоставлять доступ к таблицам (данным), чтобы он не мог «испортить» или удалить ценные данные.
Разные сотрудники фирмы имеют разные права доступа к информации, хранимой в БД. Например, один имеет право вводить только адреса и имена клиентов, другой расчётные счета, а третий денежные суммы на них. Сговор между ними может быть исключён тем, что для ввода данных им предоставляют разные формы, а данные из них могут поступать в одну таблицу.
Ввод данных в таблицу - утомительное дело и через несколько часов работы будут возникать ошибки. К тому же можно настроить управление формой так, чтобы осуществлялась первичная проверка данных при вводе.
Информацию в базе данных, как правило, берут из бумажных документов (бланков, анкет, заявлений, счетов, приказов и т.д.). Экранные формы можно сделать точной копией бумажных бланков и благодаря этому снижается утомляемость оператора, а, следовательно, и число его ошибок.
Формы можно создавать в MSA как вручную, так и автоматически, причём несколькими способами. Ручной способ создания форм требует знания некоторых тонкостей работы СУБД и программирования.
2.6. Создание запросов
Система управления базой данных позволяет не только хранить какую-либо информацию, но также и обрабатывать её. Это производится с помощью запросов, которые при обращении к БД получают конкретную, выборочную информацию.
Круг задач, решаемых при помощи запросов, чрезвычайно широк и многообразен, но в целом все виды запросов условно можно разделить на три большие группы.
Запросы, позволяющие производить простой отбор каких-либо конкретных данных из таблиц.
Запросы для модификации записей таблицы. С их помощью можно удалять строки (записи), изменять отдельные ячейки и добавлять записи.
Запросы для преобразования одной таблицы в другую путём, самый простой случай, создания новой таблицы, содержащей выборочную информацию из исходной (исходных) таблицы. В более сложных видах запросов можно использовать так называемые вычисляемые поля (по формулам), создавать перекрёстные таблицы (сводные, итоговые), строки и столбцы которых соответствуют значениям полей исходной таблицы и т.д.
Работа с запросами мало чем отличается от работы с таблицами. Можно открыть запрос и просмотреть так называемый динамический набор данных в табличном режиме. На основе запроса можно создать отчёт или форму. Сведения в запросе можно сохранять, изменять с параллельным сохранением изменений в самой таблице. Гибкость запросов позволяет пользоваться ими чаще, чем таблицами. Вместо просмотра всех таблиц можно получить ограниченный набор данных по различным условиям.
Окно запроса состоит из двух частей: области для отображения таблиц и сетки QBE (функция графического запроса по образцу). Данная функция приемлема как для создания нового запроса, так и для редактирования имеющегося.
2.7. Создание отчетов
При работе с БД приходится часто использовать различные сведения, которые желательно иметь в виде твердой бумажной копии. Для этого в MSA есть специальный объекты – отчеты, предназначенные для вывода на печать. Отчеты могут содержать разнообразные сведения и иметь довольно привлекательный вид, содержать итоговые и промежуточные результаты.
В отличие от форм, которые тоже можно вывести на печать, отчет позволяет гибко расположить материал на странице (например, в колонках). В качестве источника данных для отчетов могут использоваться как таблицы, так и запросы.
Так как отчёты предназначены для вывода информации на принтер, поэтому для расчёта расположения данных на печатной странице программа должна «знать» все необходимые данные о принтере. Эти данные она получает от операционной системы, соответственно принтер в системе должен быть установлен.
Заключение
Современный уровень информатизации общества предопределяет использование новейших технических, технологических, программных средств в различных информационных системах экономических объектов. методов и моделей, технических, программных, технологических средств и специалистов, предназначенную для обработки информации и принятия управленческих решений.
Компьютерная технология характеризуется рядом особенностей, которые следует учитывать при оценке условий и процедур контроля. Отличия компьютерной обработки данных от неавтоматизированной, в основном, следующие:
Единообразное выполнение операций. Компьютерная обработка предполагает использование одних и тех же команд при выполнении идентичных операций учета, что практически исключает появлению случайных ошибок, обыкновенно присущих ручной обработке. Напротив, программные ошибки (или другие систематические ошибки в аппаратных либо программных средствах) приводят к неправильной обработке всех идентичных операций при одинаковых условиях.
Разделение функций. Компьютерная система может осуществить множество процедур внутреннего контроля, которые в неавтоматизированных системах выполняют разные специалисты. Такая ситуация оставляет специалистам, имеющим доступ к компьютеру, возможность вмешательства в другие функции. В итоге компьютерные системы могут потребовать введения дополнительных мер для поддержания контроля на необходимом уровне, который в неавтоматизированных системах достигается простым разделением функций. К подобным мерам может относиться система паролей, которые предотвращают действия, не допустимые со стороны специалистов, имеющих доступ к информации об активах и учетных документах через терминал в диалоговом режиме.
Потенциальные возможности появления ошибок и неточностей. По сравнению с неавтоматизированными системами учета компьютерные системы более открыты для несанкционированного доступа, включая лиц, осуществляющих контроль. Они также открыты для скрытого изменения данных и прямого или косвенного получения информации об активах. Чем меньше человек вмешивается в машинную обработку операций учета, тем ниже возможность выявления ошибок и неточностей. Ошибки, допущенные при разработке или корректировке прикладных программ, могут оставаться незамеченными на протяжении длительного периода.
Инициирование выполнения операций в компьютере. Компьютерная система может выполнять некоторые операции автоматически, причем их санкционирование не обязательно документируется, как это делается в неавтоматизированных системах учета, поскольку сам факт принятия такой системы в эксплуатацию администрацией предполагает в неявном виде наличие соответствующих санкций.
Создание АИС способствует повышению эффективности производства экономического объекта и обеспечивает качество управления.
Список использованной литературы
Атре Ш. Структурный подход к организации баз данных. – М.: Финансы и статистика, 1983. – 320 с.
Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – М.: Финансы и статистика, 1989. – 351 с.
Голицина О.Л., Максимов Н.В., Попов И.И. Базы данных: Учебное пособие. – М.: ФОРУМ: ИНФРА-М, 2003. – 352 с.
Джексон Г. Проектирование реляционных баз данных для использования с микроЭВМ. - М.: Мир, 1991. – 252 с.
Карпова Т.С. Базы данных: модели, разработка, реализация. – СПб.: Питер, 2002. – 304 с.
Кириллов В.В. Структуризованный язык запросов (SQL). – СПб.: ИТМО, 1994. – 80 с.
Корнеев И.К., Машурцов В.А. Информационные технологии в управлении. – М.: ИНФРА-М, 2001. – 158 с.
Мартин Дж. Планирование развития автоматизированных систем. – М.: Финансы и статистика, 1984. – 196 с.
Мартьянова А.Е. Методическое пособие по проектированию баз данных; Астрахань, 2003 г., 143 с.
Хаббард Дж. Автоматизированное проектирование баз данных. – М.: Мир, 1984. – 294 с.
Приложения
П 2. Листинг SQL-запросов
Запрос «Договор аренды автомобиля»
SELECT Договор. Код, Договор. [Дата договора], Клиенты. [Фамилия Имя Отчество] AS [Клиенты_Фамилия Имя Отчество], Клиенты. [Дата рождения] AS [Клиенты_Дата рождения], Договор. Паспорт, Клиенты. [Дата выдачи] AS [Клиенты_Дата выдачи], Клиенты. [Кем выдан] AS [Клиенты_Кем выдан], Клиенты. [Адрес регистрации] AS [Клиенты_Адрес регистрации], Клиенты. [Вод удостоверение] AS [Клиенты_Вод удостоверение], Клиенты. [Дата выдачи2] AS [Клиенты_Дата выдачи2], Клиенты. [Орган ГАИ] AS [Клиенты_Орган ГАИ], Поручители. [Фамилия Имя Отчество] AS [Поручители_Фамилия Имя Отчество], Поручители. [Дата рождения] AS [Поручители_Дата рождения], Договор. Паспорт2, Поручители. [Дата выдачи] AS [Поручители_Дата выдачи], Поручители. [Кем выдан] AS [Поручители_Кем выдан], Поручители. [Адрес регистрации] AS [Поручители_Адрес регистрации], Поручители. [Вод удостоверение] AS [Поручители_Вод удостоверение], Поручители. [Дата выдачи2] AS [Поручители_Дата выдачи2], Поручители. [Орган ГАИ] AS [Поручители_Орган ГАИ], Договор. [Номерной знак], Автомобили. [Зарегистрированный в], Автомобили. [Марка, модель], Автомобили. Выпуск, Автомобили. Производство, Автомобили. Двигатель, Автомобили. Кузов, Автомобили. Цвет, Автомобили. [Паспорт ТС], Автомобили. [Свидетельство о регистрации], Автомобили. Собственник, Автомобили. [Сумма проката], Автомобили. [Стоимость ТС], Договор. Залог, Договор. [Дата возврата ТС], Автомобили. Фото
FROM Автомобили INNER JOIN (Поручители INNER JOIN (Клиенты INNER JOIN Договор ON Клиенты. Паспорт = Договор. Паспорт) ON Поручители. Паспорт2 = Договор. Паспорт2) ON Автомобили. [Номерной знак] = Договор. [Номерной знак]
WHERE (((Договор. Код) = [Введите номер договора]));