зміст
Введення. 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.1. Збір даних
Повнота і достатність бази даних у будь-якої предметної області в значній мірі залежить від збору інформації.Збір інформації та її попередня обробка має одночасно відповідати цілям кінцевого користувача інформації так і розробника БД (прикладних програмістів). Загальна схема моделі збору та опису інформації наведена на малюнку 1.
У концептуальної моделі об'єднуються дві вистави: концептуальне уявлення об'єктивно існуючої предметної області та концептуальне уявлення суб'єктивних інформаційних вимог розробників.
Перше з цих уявлень відображає об'єкти, процеси та предмети реального світу як складові частини предметної області, їх суттєві властивості, а також взаємозв'язку між цими елементами. Друге подання описує дані і зв'язку з точки зору їх обробки в СУБД.
Процес побудови концептуальної моделі поділяється на два етапи:
1 етап - збір та змістовний аналіз апріорної (переддослідний) інформації про предметну область і прикладних задачах користувачів;
2 етап - аналіз даних і синтез концептуальної моделі.
Перший етап передбачає збір даних (результатів змін або спостережень, звітів і різних документів технічного, економічного, бухгалтерського і їм подібного характеру, опитування експертів фахівців у даній галузі) та виявлення переліку завдань організації або її відділів, які можуть бути вирішені з використанням розробляється БД .
Після збору даних здійснюється візуальний контроль, реєстрація, кодування та комплектування їх.
Візуальний контроль здійснюється для перевірки чіткості заповнення, наявності реквізитів і відсутність пропусків даних.
Кодування даних означає присвоєння кодів тим реквізитами, де є великий обсяг інформації. Зазвичай кодуються найменування за спеціальним довідників і класифікаторів. Якщо їх немає, то створюються свої коди.
Комплектування даних - це розбиття великих обсягів даних на комплекти (пачки), щоб полегшити їх пошук.
Складання списку всіх використовуваних і створюваних елементів даних може здійснюватися в рамках однієї таблиці (одного відносини) або декількох таблиць.
На першому етапі проводиться концептуальний аналіз, наявний інформації, метою якого є виявлення елементів предметної області, їх властивостей і взаємозв'язку. Іншими словами - побудова моделі предметної області.
1.2. Побудова інформаційної логічної моделі бази даних
Інформаційно-логічна модель (Илм) відображає дані предметної області у вигляді сукупності інформаційних об'єктів і зв'язків між ними.Інформаційний об'єкт - це опис деякої сутності предметної області - реального об'єкта, процесу явища чи події. Інформаційний об'єкт утворюється сукупністю логічно взаємозалежних атрибутів, що представляють якісні і кількісні характеристики сутності.
При проектуванні Илм можна виділити три основні підходи.
Збір інформації про об'єкти предметної області в рамках однієї таблиці і наступна декомпозиція її на декілька взаємозалежних таблиць (інформаційних об'єктів) на основі процедури нормалізації відносин.
Формулювання знань про систему (визначення типів вихідних даних та їх взаємозв'язків) і вимог до обробки даних, одержання за допомогою системи автоматизації проектування і розробки баз даних готової схеми БД і навіть готової прикладної інформаційної системи.
Структурування інформації для використання в БД у процесі проведення системного аналізу на основі сукупності правил і рекомендацій.
Нижче розглянемо перший з названих підходів, що є класичним і історичним першим.
Інформаційні об'єкти виділяються шляхом визначення функціональних залежностей між атрибутами. Сукупність атрибутів інформаційного об'єкта повинна відповідати вимогам нормалізації. Нормалізація - це процес перетворення ієрархічної, мережевої структури чи вихідної єдиної таблиці даних у реляційну структуру.
Основні вимоги нормалізації.
Атрибути кожного інформаційного об'єкта повинен містити унікальний ідентифікатор - ключ. Ключ є простим, якщо він складається з одного атрибута, чи складовим, якщо з декількох.
Всі неунікальні ідентифікатори - описові атрибути повинні бути взаємозалежні (тобто між ними не повинно бути функціональних залежностей).
Всі атрибути, що входять у складений ключ, повинні бути також взаємозалежні.
Кожен описовий атрибут повинен бути функціонально повно залежати від ключа, тобто кожному значенню ключа повинно відповідати тільки одне значення описового атрибута.
При складеному ключі описові атрибути повинні залежати цілком від усієї сукупності атрибутів, створюючих ключ.
Кожен описовий атрибут не повинен залежати від ключа транзитивно, тобто через інший проміжний атрибут.
У разі транзитивної залежності між атрибутами можна виконати розщеплення сукупності атрибутів з утворенням двох інформаційних об'єктів замість одного.
Виконання вимог нормалізації забезпечує побудову реляційної БД без дублювання даних і можливість підтримання цілісності при внесенні змін.
Таблиця 1. Автомобілі
| Автомобілі | ||||||||||||
| Номерний знак | Зареєстрований в | Марка, модель | Випуск | Виробництво | Двигун | Кузов | Колір | Паспорт ТЗ | Свідоцтво про реєстрацію | Сума прокату | Вартість ТЗ | Фото |
| Е427ВУ30 | МОТОР ГИБДД м. Астрахані | Chevrolet Lanos | 2006 | України | 178618R | Y6DTF69Y0600259 | сріблястий | серія 77 ТН № 827176 від 28.06. | серія 30 ЗУ № 177300 від 09.08. | 37200 | 360000 | |
| Е433ВУ30 | МОТОР ГИБДД м. Астрахані | ВАЗ21074 | 2006 | Тольятті | 8700290 | 2421794 | темно-вишневий | серія 63 МО № 784275 від 09.08. | серія 30 ЗУ № 1730406 від 09.08. | 20150 | 180000 | |
| М962ВХ30 | МОТОР ГИБДД м. Астрахані | RenaultMegane2p2a16a115e | 2006 | Туреччина | К4МС813R006592 | 36419983 | світло-сріблястий | серія 77 ТТ № 652069 від 04.09. | серія 30 РК № 049880 від 06.12. | 77500 | 600000 | |
| О877ВХ30 | МОТОР ГИБДД м. Астрахані | ВАЗ21074 | 2006 | Тольятті | 8770115 | 2488783 | яскраво-білий | серія 63 МК № 375264 від 28.11. | серія 30 РК № 052292 від 25.12. | 20150 | 180000 | |
| Р542ВУ30 | МОТОР ГИБДД м. Астрахані | Chevrolet Lanos | 2006 | України | 190736R | Y6DTF69Y060034722 | сріблястий | серія 77 ТТ № 682388 від 05.09. | серія 30 РА № 539052 від 23.09. | 37200 | 360000 | |
| Р812ВТ30 | МОТОР ГИБДД м. Астрахані | ВАЗ21121 | 2006 | Тольятті | 1553594 | 0397653 | біло-зелений | серія 63 МО № 614814 від 04.05. | серія 30 ОС № 665700 від 02.06. | 26350 | 250000 | |
| С946ВТ30 | МОТОР ГИБДД м. Астрахані | ВАЗ21150 | 2006 | Тольятті | 4403032 | 4222062 | світло-сріблястий | серія 63 МО № 111876 від 13.06. | серія 30 ЗУ № 168920 від 23.06. | 26350 | 250000 | |
| С947ВТ30 | МОТОР ГИБДД м. Астрахані | ВАЗ21101 | 2006 | Тольятті | 1587750 | 0966158 | біло-зелений | серія 63 МО № 111890 від 13.06. | серія 30 ЗУ № 168921 від 23.06. | 27900 | 260000 | |
| С948ВТ30 | МОТОР ГИБДД м. Астрахані | ВАЗ21140 | 2006 | Тольятті | 4403102 | 4221229 | світло-сріблястий | серія 63 МО № 575735 від 13.06. | серія 30 ЗУ № 168922 від 23.06. | 26350 | 250000 | |
| У578ВУ30 | МОТОР ГИБДД м. Астрахані | Nissan Primera | 2006 | Сполучене Королівство | 0756760 | 4135344 | сріблястий | серія 77 ТН № 899545 від 10.06. | серія 30 ДГ № 920170 від 07.11. | 77500 | 700000 | |
| У901ВТ30 | МОТОР ГИБДД м. Астрахані | ВАЗ2115 | 2006 | Тольятті | 4403032 | 4221247 | світло-сріблястий | серія 63 МО № 101558 ВІД 05.06. | серія 30 ЗУ № 168923 від 23.06. | 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 є спеціальний об'єкти - звіти, призначені для виведення на друк. Звіти можуть містити різноманітні відомості і мати досить привабливий вигляд, містити підсумкові та проміжні результати.На відміну від форм, які теж можна вивести на друк, звіт дозволяє гнучко розташувати матеріал на сторінці (наприклад, в колонках). В якості джерела даних для звітів можуть використовуватися як таблиці, так і запити.
Так як звіти призначені для виведення інформації на принтер, тому для розрахунку розташування даних на друкованій сторінці програма повинна «знати» всі необхідні дані про принтер. Ці дані вона отримує від операційної системи, відповідно принтер в системі повинен бути встановлений.
Висновок
Сучасний рівень інформатизації суспільства зумовлює використання новітніх технічних, технологічних, програмних засобів у різних інформаційних системах економічних об'єктів. методів і моделей, технічних, програмних, технологічних засобів і фахівців, призначену для обробки інформації та прийняття управлінських рішень.Комп'ютерна технологія характеризується рядом особливостей, які слід враховувати при оцінці умов і процедур контролю. Відмінності комп'ютерної обробки даних від неавтоматизованої, в основному, наступні:
Однакове виконання операцій. Комп'ютерна обробка припускає використання одних і тих самих команд при виконанні ідентичних операцій обліку, що практично виключає появі випадкових помилок, звичайно властивій ручній обробці. Навпаки, програмні помилки (інші чи систематичні помилки в апаратних або програмних засобах) приводять до неправильної обробки всіх ідентичних операцій при однакових умовах.
Поділ функцій. Комп'ютерна система може здійснити безліч процедур внутрішнього контролю, які в неавтоматизованих системах виконують різні фахівці. Така ситуація залишає фахівцям, що мають доступ до комп'ютера, можливість втручання в інші функції. У підсумку комп'ютерні системи можуть зажадати введення додаткових заходів для підтримки контролю на необхідному рівні, який в неавтоматизованих системах досягається простим поділом функцій. До подібних мір може ставитися система паролів, які запобігають дії, не припустимі з боку фахівців, що мають доступ до інформації про активи та облікові документи через термінал в діалоговому режимі.
Потенційні можливості появи помилок і неточностей. У порівнянні з неавтоматизованими системами обліку комп'ютерні системи більш відкриті для несанкціонованого доступу, включаючи осіб, які здійснюють контроль. Вони також відкриті для прихованої зміни даних і прямого чи непрямого одержання інформації про активи. Чим менше людина втручається в машинну обробку операцій обліку, тим нижче можливість виявлення помилок і неточностей. Помилки, допущені при розробці чи коригуванні прикладних програм, можуть залишатися непоміченими протягом тривалого періоду.
Ініціювання виконання операцій у комп'ютері. Комп'ютерна система може виконувати деякі операції автоматично, причому їхнє санкціонування не обов'язково документується, як це робиться в неавтоматизованих системах обліку, оскільки сам факт прийняття такої системи в експлуатацію адміністрацією припускає в неявному виді наявність відповідних санкцій.
Створення АІС сприяє підвищенню ефективності виробництва економічного об'єкта і забезпечує якість управління.
Список використаної літератури
1. Атре Ш. Структурний підхід до організації баз даних. - М.: Фінанси і статистика, 1983. - 320 с.2. Бойко В.В., Савінков В.М. Проектування баз даних інформаційних систем. - М.: Фінанси і статистика, 1989. - 351 с.
3. Голіцина О.Л., Максимов Н.В., Попов І.І. Бази даних: Навчальний посібник. - М.: ФОРУМ: ИНФРА-М, 2003. - 352 с.
4. Джексон Г. Проектування реляційних баз даних для використання з мікроЕОМ. - М.: Світ, 1991. - 252 с.
5. Карпова Т.С. Бази даних: моделі, розробка, реалізація. - СПб.: Пітер, 2002. - 304 с.
6. Кирилов В.В. Структурізованние мову запитів (SQL). - СПб.: ІТМО, 1994. - 80 с.
7. Корнєєв І.К., Машурцов В.А. Інформаційні технології в управлінні. - М.: ИНФРА-М, 2001. - 158 с.
8. Мартін Дж. Планування розвитку автоматизованих систем. - М.: Фінанси і статистика, 1984. - 196 с.
9. Мартьянова А.Є. Методичний посібник з проектування баз даних; Астрахань,
10. Хаббард Дж. Автоматизоване проектування баз даних. - М.: Світ, 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 (((Договор. Код) = [Введіть номер договору]));