Розробка бази даних Access Автосервис

Загальні питання баз даних різних моделей, принципи організації текстових, мережевих і реляційних баз. Підхід до проектування баз даних для ведення підрахунків складального цеху автозаводу та процес її конструювання і побудови. Прийоми створення запитів.

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык украинский
Дата добавления 08.03.2014
Размер файла 2,1 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

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

РЕФЕРАТ

Курсова робота: 39 сторінок, 37 скріншотів, 5 джерел.

Мета роботи-створення програми для ведення підрахунків складального цеху автозаводу.

У курсовій роботі розглянуті загальні питання баз даних різних моделей, принципи організації текстових, мережевих і реляційних баз. Описано підхід до проектування баз даних. На конкретному прикладі розглянуто базу даних для ведення підрахунків складального цеху автозаводу та показаний процес конструювання і побудови бази даних. Розкрито прийоми створення запитів.

ЗМІСТ

  • ВСТУП
  • 1. БАЗИ ДАНИХ
    • 1.1 Текстові бази даних
    • 1.2 Мережні бази даних
    • 1.3 Реляційні бази даних
  • 2. СУБД ACCESS ТА ОПИС ПРИНЦИПІВ РОБОТИ
  • 3. РОЗРОБКА БАЗИ ДАНИХ
    • 3.1 Таблиці
    • 3.2 Запити
  • ВИСНОВОК
  • ЛІТЕРАТУРА

ВСТУП

Програмне забезпечення для роботи з базами даних використовується на персональних комп'ютерах досить давно. Взагалі, база даних - це набір записів і файлів, які організовані спеціальним чином. В комп'ютері, наприклад, можна зберігати прізвища і адреси друзів або клієнтів. Можливо, зберігати всі свої листи, і вони згруповані по адресатам, або набір файлів з даними по фінансовим справам: отримані або виставлені рахунки, витрати по чековій книжці або балансам. Один з типів баз даних - це документи, які набрані за допомогою текстових редакторів і згруповані за темами. Другий тип - файли електронних таблиць, які об'єднані в групи по характеру їх використання. Щоб керувати даними, які розкидані по сотням таблиць і файлів використовуються системи управління базами даних (СУБД). Microsoft Access саме є такою системою.

Майже всі сучасні системи побудовані на реляційній моделі керування базами даних. Назва “реляційна” пов'язана з тим, що кожний запис в такій базі даних має інформацію, яка відноситься тільки до одного конкретного об'єкту. В реляційній СУБД всі дані представлені в вигляді таблиць. Інформація про об'єкти визначеного виду представляється в табличному вигляді - в стовпчиках таблиці містяться різні характеристики об'єктів - атрибути (наприклад, адреси клієнтів), а рядки призначені для опису величин всіх атрибутів окремого об'єкта (наприклад, дані про конкретного клієнта). В випадку, коли використовуються функції СУБД для вибору інформації з однієї або декількох таблиць (виконується запит, що є темою даної курсової роботи), результат представляється у вигляді таблиці. Більше того, можна виконати запит із використанням результатів іншого запиту. Можна об'єднати інформацію з декількох таблиць або запитів.

Система управління базами даних дає можливість контролювати структуру і опис даних, роботу з ними і організацію колективного користування інформацією. СУБД також суттєво збільшує можливості і полегшує каталогізацію і ведення великих об'ємів інформації, яка зберігається в численних таблицях. СУБД включає в себе три основних типа функцій: визначення даних, їх обробка й керування даними. Усі ці функціональні можливості в повній мірі реалізовані в Microsoft Access.

В базі даних Access основними об'єктами є таблиці, запити, форми, звіти, макроси і модулі. Таблиця - об'єкт, який використовується для збереження даних. Таблиця складається з полів (стовпчиків), в яких зберігаються різні дані, і записів (рядків). В записи зібрана вся інформація про деякий об'єкт. Запит - об'єкт, який дозволяє користувачу отримати потрібні дані з одної або декількох таблиць. Для створення запиту можна використовувати бланк QBE(запит по зразку) або інструкцію SQL. Можна створювати запити на вибірку, поновлення, видалення або додавання даних. За допомогою запитів також можна створювати нові таблиці, використовуючи дані з одної або декількох існуючих таблиць. Форма - об'єкт, призначений в основному для вводу даних, відображення їх на екрані або керування роботою додатку. Звіт - об'єкт, призначений для створення документа, який в подальшому може бути роздрукований або включений в документ іншого додатку.

1. БАЗИ ДАНИХ

В самій суті база даних - це набір записів та файлів,організованих особливим образом. В комп'ютері , наприклад, можна зберігати прізвища та адреси друзів, або клієнтів. Можливо , ви зберігаєте усі свої листи, і вони згруповані по адресатам, а можливо, у вас є набір файлів з фінансовими даними: отриманими, або виставленими рахунками, витратами по чековій книжці, або балансам.

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

Якщо ви організована людина, то спеціальна структура каталогів та підкаталогів, можливо, допоможе вам впоратись з кількома сотнями електронних таблиць. В цьому випадку ви є диспетчером бази даних. Але що робити коли, виконувана вами задача стає надто великою? Як зібрати інформацію про всіх клієнтів та їх замовленнях, якщо дані розкидані по окремих текстових файлах та електронних таблицях? Як зберегти зв'язки між файлами при введені нової інформації? Як переконатися, що дані введені правильно? Що робити , коли одна і та ж інформація може знадобитися одразу кільком користувачам, але при цьому не можна допустити, щоб дві людини одночасно змінювали одні і ті ж дані? Коли з'являються подібні проблеми, вам потрібна система управління базами даних (СУБД).

Система управління базами даних надає вам повний контроль над процесом визначення даних , їх обробкою та використанням СУБД також істотно полегшує обробку великих об'ємів інформації, які зберігаються в багаточисленних таблицях. Різноманітні засоби СУБД забезпечують виконання трьох основних функцій: визначення даних, обробка даних та оперування даними. Але ж, що ж таке дані?

Дані - це набір різнорідної неорганізованої інформації, подібний до рахунків, кинутих у ящик столу, або сюжету останнього поганого роману. І якщо ви коли-небудь намагались знайти потрібний вам рахунок у своєму ящику, або хороші розділ поганого роману, ви знаєте, що самі по собі дані не принесуть користі . Для того щоб дані стали корисними, вам потрібний засіб управління ними - система управління базою даних. Вам потрібно упорядкувати усі розкидані рахунки з тим, щоб можна було легко знайти те, що потрібно в даний момент. Організований набір даних і є базою даних.

Бази даних поділяються на такі види:

1. Текстові бази даних

2. Мережні бази даних

3. Реляційні бази даних

Розглянемо більш детальніше види баз даних.

1.1 Текстові бази даних

Об'єктами зберігання в текстових БД є тексти. Під текстом будуть розумітися неструктуровані дані, побудовані з рядків.

Основною метою будь-якої текстової БД є зберігання, пошук і видача документів, що відповідають запиту користувача. Такі документи прийнято називати релевантними. З огляду на те, що автоматизований пошук документів на природних мовах досить утруднений, виникає питання про проектування деяких формальних мов, призначених для відображення основного змісту документів і запитів у БД.

Такі мови називають інформаційно-пошуковими. В даний час розроблено досить велику кількість інформаційно-пошукових мов, які відрізняються не тільки за своїми образотворчим властивостями, але і за ступенем семантичної сили.

В основі підходу до побудови класифікаційних мов лежить уявлення про те, що накопичені знання можуть бути розділені на взаємовиключні класи і підкласи. Існує система правил, якій має підкорятися будь-яка мова класифікаційного типу, зокрема:

- розподіл галузей знань на класи і підкласи проводиться по одній підставі;

- підкласи повинні виключати один одного;

- при розподілі класів на підкласи повинна дотримуватися безперервність.

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

Дескрипторні мови прив'язані до лексики текстів. Ключові слова з текстів вибираються виходячи з різних цілей, відповідно, критерії вибору можуть різнитися. Для побудови дескрипторної мови критерієм відбору ключових слів, як правило, слугують інформативність слова і частота його народження у тексті.

Універсальними структурами дескрипторної мови є лексичні одиниці, парадигматичні та синтагматичні відношення.

Лексична одиниця - найменша смислова одиниця, що задається при побудові мови.

У більшості автоматизованих інформаційних систем при індексуванні документів і запитів застосовується контроль за допомогою тезауруса. Контроль може здійснюватися в автоматизованому або ручному режимі. По суті справи тезаурус представляє собою словник - довідник, в якому присутні всі лексичні одиниці дескрипторної інформаційно-пошукової мови з введеними парадигматичними відносинами. Парадигматичні відносини можуть задаватися як:

- відносини вид - рід (вищестоящий дескриптор);

- відносини рід - вид (нижчестоящі дескриптори);

- синоніми;

- асоціативні зв'язку

У тезауруси поміщаються дескриптори і недескріптори, хоча існують тезауруси тільки з дескрипторів.

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

Парадигматичні відносини являють собою поза текстові відносини між лексичними одиницями. На їх підставі відбувається угруповання лексичних одиниць у парадигми.

Синтагматичні відносини являють собою відносини лексичних одиниць у тексті, тобто вони висловлюють семантику контексту.

При перекладі основного змісту документів і запитів з природної мови на дескрипторну інформаційно-пошуковий мову існують певні правила, звані системою індексування. Результатом перекладу документа є пошуковий образ документа, а запиту - пошуковий образ запиту.

З перерахованих інформаційно-пошукових мов саме дескрипторні мови найкращим чином пристосовані для опису документів і запитів при автоматизованому пошуку в текстових БД. Мови ці володіють такою перевагою, як гнучкість, відкритість, близькість до природної мови; це мови дворівневі (рівень ключових слів і рівень дескрипторів). Дескрипторні інформаційно-пошукові мови дозволяють формулювати документи і запити в різних термінах. До основних недоліків мов даного класу можна віднести недостатню повноту опису змісту документів і запитів.

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

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

1.2 Мережні бази даних

Одним з найбільш ефективних методів представлення знань є мережні моделі.

В основі моделей лежить поняття мережі, вершинами якої є поняття, що відповідають об'єктам, подіям, процесам, явищам, а дугами - відносини між цими поняттями.

Вузли і зв'язку можна наочно зображати у вигляді діаграм.

Якщо вершини мережі не мають своєї внутрішньої структури, то мережа буде простою. Якщо ж вершини мають деякою структурою у вигляді мережі, то мережа називається ієрархічною. Якщо відносини між вершинами однакові, то мережа однорідна, в іншому випадку - мережа неоднорідна. Характер відносин, приписуваний дуг, може бути різний. Відповідно до цього виділяють такі типи мереж:

- функціональні мережі відображають декомпозицію певної обчислювальної або інформаційної процедури, а дуги показують функціональний зв'язок між декомпонірованнимі частинами; цю мову недостатньо багатий для представлення знань;

- сценарії, що представляють собою однорідні мережі з єдиним відношенням у вигляді несуворого порядку. Семантика відносин може бути різною. Ставлення може трактуватися як класифікує, тимчасове і т.п. Сценарії часто використовуються при формуванні допустимих планів по досягненню мети;

- семантичні мережі використовують відносини різних типів, а вершини в них можуть мати різну інтерпретацію, По суті справи семантична мережа є класом, до якого включаються як сценарії, так і функціональні мережі. Найбільш часто використовуються в мережі зв'язку типу «це є». Вони дозволяють побудувати у вигляді мережі ієрархію понять, в яких вузли нижчих рівнів успадковують властивості вузлів більш високих рівнів. Саме таким механізмом перенесення властивостей обумовлена ефективність семантичних мереж.

1.3 Реляційні бази даних

Бази даних називаються реляційними, якщо управління ними засноване на математичній моделі, що використовує методи реляційної алгебри та реляційного числення. С. Дейт дає наступне неформальне визначення реляційних баз даних:

- вся інформація в базі даних представлена у вигляді таблиць.

- підтримуються три реляційних оператора - вибору, проектування й об'єднання, за допомогою яких можна отримати будь-які необхідні дані, закладені в таблиці.

Доктор І.Ф. Кодд, автор реляційної моделі, розробив цілий список критеріїв, яким повинна задовольняти реляційна модель. Опис цього списку, який часто називають «12 правил Кодда», вимагає введення складної термінології і виходить за рамки курсової роботи. Тим не менше можна назвати деякі правила Кодда для реляційних систем. Щоб вважатися реляційної по Кодда, система управління базами даних повинна:

- представляти всю інформацію у вигляді таблиць;

- підтримувати логічну структуру даних, незалежно від їх фізичного представлення;

- використовувати мову високого рівня для структурування, виконання запитів і зміни інформації в базах даних;

- підтримувати основні реляційні операції (вибір, проектування і об'єднання), а також теоретико-множинні операції, такі як об'єднання, перетин і доповнення;

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

- розрізняти в таблицях невідомі значення (nulls), нульові значення і пропуски в даних;

- забезпечувати механізми для підтримки цілісності, авторизації, транзакцій і відновлення даних.

Перше правило Кодда говорить, що вся інформація в реляційних базах даних представляється значеннями в таблицях. У реляційних системах таблиці складаються з горизонтальних рядків і вертикальних стовпців. Всі дані представляються в табличному форматі - іншого способу переглянути інформацію в базі даних не існує. Набір пов'язаних таблиць утворює базу даних. Таблиці в реляційної базі розділені, але повністю рівноправні. Між ними не існує жодної ієрархії.

Кожна таблиця складається з рядків і стовпців. Кожен рядок описує окремий об'єкт або сутність - учня, предмет, день тижня або що-небудь інше. Кожен стовпець описує одну характеристику об'єкта. Кожен елемент даних, або значення, визначається перетинанням рядка та стовпця. Щоб знайти потрібний об'єкт даних, необхідно знати ім'я таблиці, що містить його, стовпець і значення його первинного ключа, або унікального ідентифікатора.

У реляційній базі даних існує два типи таблиць - користувальницькі таблиці та системні таблиці. Користувальницькі таблиці містять інформацію, для підтримки якої власне і створювалися реляційні бази даних. Системні таблиці звичайно підтримуються самою СУБД, проте доступ до них можна отримати так само, як і до будь-якої іншої таблиці. Можливість отримання доступу до системних таблиць, за аналогією з будь-якими іншими таблицями, складає основу другого правила Кодда для реляційних систем.

Реляційна модель забезпечує незалежність даних на двох рівнях - фізичному і логічному. Фізична незалежність даних означає з точки зору користувача, що подання даних абсолютно не залежить від способу їх фізичного зберігання. Як наслідок цього, фізичне переміщення даних жодним чином не може вплинути на логічну структуру бази даних. Інший тип незалежності, забезпечуваний реляційними системами - логічна незалежність - означає, що зміна взаємозв'язків між таблицями і рядками не впливає на правильне функціонування програмних додатків і поточних запитів. база проектування автозавод мережевий

У визначенні системи керування реляційними базами даних згадуються три операції по вибірці даних - проектування, вибір і об'єднання, які дозволяють суворо вказати системі, які дані необхідно показати. Операція проектування вибирає стовпці, операція вибору - рядки, а операція об'єднання збирає разом дані з пов'язаних таблиць.

Віртуальні таблиці можна розглядати як деяку переміщувану за таблицями рамку, через яку можна побачити тільки необхідну частину інформації. Віртуальні таблиці можна отримати з однієї або декількох таблиць бази даних (зокрема й інші віртуальні таблиці), використовуючи будь-які операції вибору, проектування та об'єднання. Віртуальні таблиці, на відміну від «справжніх», або базових таблиць, фізично не зберігаються в базі даних. У той же час необхідно усвідомлювати, що віртуальні таблиці це не копія деяких даних, що поміщається в іншу таблицю. Коли ви змінюєте дані у віртуальній таблиці, то тим самим змінюєте дані в базових таблицях. В ідеальній реляційної системі з віртуальними таблицями можна оперувати як і з будь-якими іншими таблицями. У реальному світі на віртуальні таблиці накладаються певні обмеження, зокрема на оновлення. Одне з правил Кодда говорить, що в істинно реляційної системі над віртуальними таблицями можна виконувати всі «теоретично» можливі операції. Більшість сучасних систем управління реляційними базами даних не задовольняють цим правилом повністю.

У реальному світі управління інформацією дані часто є невідомими або неповними: невідомий телефонний номер, не захотіли вказати вік. Такі пропуски інформації створюють «дірки» в таблицях. Проблема, звичайно, полягає не в простій непривабливості подібних дірок. Небезпека полягає в тому, що через них база даних може стати суперечливою. Щоб зберегти цілісність даних в реляційній моделі, так само, як і в правилах Кодда, для обробки пропущеної інформації використовується поняття нуля.

«Нуль» не означає порожнє поле або звичайний математичний нуль. Він відображає той факт, що значення невідоме, недоступне або не застосовується. Істотно, що використання нулів ініціює перехід з двозначною логіки (так/ні) на тризначну (так/ні/може бути). З точки зору іншого експерта з реляційних систем, Дейта, нулі не є повноцінним вирішенням проблеми пропусків інформації. Тим не менше вони є складовою частиною більшості офіційних стандартів різних реляційних СУБД.

Цілісність - дуже складне і серйозне питання при управлінні реляційними базами даних. Неузгодженість між даними може виникати з цілої низки причин. Неузгодженість чи суперечливість даних може виникати внаслідок збою системи - проблеми з апаратним забезпеченням, помилки в програмному забезпеченні або логічної помилки в додатках. Реляційні системи управління базами даних захищають дані від такого типу неузгодженості, гарантуючи, що команда або буде виконана до кінця, або буде повністю скасована. Цей процес зазвичай називають управлінням транзакціями.

Інший тип цілісності, званий об'єктної цілісністю, пов'язаний з коректним проектуванням бази даних. Об'єктна цілісність вимагає, щоб ні один первинний ключ не мав нульового значення.

Третій тип цілісності, званої посилальної цілісністю, означає несуперечність між частинами інформації, повторюваними в різних таблицях. Наприклад, якщо ви змінюєте неправильно введений номер картки страхового поліса в одній таблиці, інші таблиці, які містять цю ж інформацію, продовжують посилатися на старий номер, тому необхідно оновити і ці таблиці. Надзвичайно важливо, щоб при зміні інформації в одному місці, вона відповідно змінювалася і у всіх інших місцях. Ці можливості в тому чи іншому вигляді реалізовані в більшості систем.

2. СУБД ACCESS ТА ОПИС ПРИНЦИПІВ РОБОТИ

Система управління базами даних Microsoft Access входить до складу пакета Microsoft Office. Вона дозволяє розв'язувати широке коло завдань користувачів без програмування і доступна для широкого кола непрофесійних користувачів персональних комп'ютерів.

Система управління базами даних (СУБД) Access розроблена для експлуатації у комп'ютерних мережах у середовищі Windows.

Одна з основних переваг СУБД Ассеss полягає у тому, що вона має прості та зручні засоби обробки кількох таблиць у одній базі даних. Таблиця є основним об'єктом бази даних. У одній базі даних зберігається кілька таблиць та засоби зв'язування таблиць.

У системі Acсess є різні способи управління даними, а саме:

- система меню;

- панелі інструментів;

- контекстивне меню;

- укажчик миші;

- комбінації клавіш.

СУБД Access має значну кількість спеціальних програм - “майстрів”. Є майстер таблиць, майстер кнопок, майстер форм та ін. Майстри здійснюють діалог з користувачем, у процесі якого визначаються дані, необхідні для розв'язування відповідної задачі. Для зручності роботи кожен майстер має певні етапи (кроки). Будь-який етап можна пропустити або звернутись до попередніх.

Формою видачі даних на екран користувач може управляти. Важливо правильно конструювати форми, оскільки саме з ними працює користувач при введенні і редагуванні записів бази даних. Крім того, форми можна використовувати для збирання та виведення інформації

СУБД Access є системою управління базами даних реляційного типу. Дані зберігаються в такій базі у вигляді таблиць, рядки (записи) яких складаються з наборів полів певних типів. З кожною таблицею можуть бути пов'язані індекси (ключі), що задають потрібні користувачу порядки на безлічі рядків. Таблиці можуть мати однотипні поля (стовпці), і це дозволяє встановлювати між ними зв'язки, виконувати операції реляційної алгебри. Типовими операціями над базами даних є визначення, створення і видалення таблиць, модифікація визначень (структур, схем) існуючих таблиць, пошук даних у таблицях за певними критеріями (виконання запитів), створення звітів про вміст бази даних.

СУБД дозволяє задавати типи даних і способи їх зберігання. Можна також задати критерії (умови), які СУБД буде в подальшому використовувати для забезпечення правильності введення даних. У самому простому випадку умова на значення має гарантувати, що не буде введений випадково в числове поле буквений символ. Інші умови можуть визначати область або діапазони допустимих значень, що вводяться.

Microsoft Access надає максимальну свободу в завданні типу даних (текст, числові дані, дати, час, грошові значення, малюнки, звук, електронні таблиці). Можна задавати також формати зберігання подання цих даних при виведенні на екран або друк. Для впевненості, що в базі зберігаються тільки коректні значення, можна задати умови на значення різного ступеня складності.

Так як Microsoft Access є сучасним додатком Windows, можна використовувати в роботі всі можливості DDE (динамічний обмін даними) і OLE (зв'язок і впровадження об'єктів). DDE дозволяє здійснювати обмін даними між Access і будь-яким іншим підтримує DDE додатком Windows. У Microsoft Access можна за допомогою макросів або Access Basic здійснювати динамічний обмін даними з іншими додатками.

OLE є більш витонченим засобом Windows, яке дозволяє встановити зв'язок з об'єктами іншої програми або впровадити будь-які об'єкти в базу даних Access. Такими об'єктами можуть бути картинки, діаграми, електронні таблиці або документи з інших підтримуючих OLE додатків Windows.

У Microsoft Access для обробки даних базових таблиць використовується потужна мова SQL (структурована мова запитів). Використовуючи SQL можна виділити з однієї або декількох таблиць необхідну для вирішення конкретного завдання інформацію. Access значно спрощує задачу обробки даних. Зовсім не обов'язково знати мову SQL. При будь-якій обробці даних з декількох таблиць Access використовує одного разу задані зв'язки між таблицями.

У Microsoft Access є також просте і в той же час багате можливостями засіб графічного завдання запиту - так званий «запит на зразок» (query by example), яке використовується для завдання даних, необхідних для вирішення певної задачі. Використовуючи для виділення і переміщення елементів на екрані стандартні прийоми роботи з мишею в Windows і кілька клавіш на клавіатурі, можна буквально за секунди побудувати досить складний запит.

Microsoft Access спроектований таким чином, що він може бути використаний як в якості самостійної СУБД на окремій робочій станції, так і в мережі - у режимі «клієнт-сервер». Оскільки в Microsoft Access до даних можуть мати доступ одночасно кілька користувачів, в ньому передбачені надійні засоби захисту та забезпечення цілісності даних. Можна заздалегідь вказати, які користувачі або групи користувачів можуть мати доступ до об'єктів (таблиць, форм, запитів) бази даних. Microsoft Access автоматично забезпечує захист даних від одночасного їх коригування різними користувачами. Access також пізнає і враховує захисні засоби інших приєднаних до бази даних структур (таких, як бази даних Paradox, dBASE і SQL).

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

Microsoft Access надає додаткові засоби розробки додатків, які можуть працювати не тільки з власними форматами даних, але і з форматами інших найбільш поширених СУБД. Можливо, найбільш сильною стороною Access є його здатність обробляти дані електронних таблиць, текстових файлів, файлів dBASE, Paradox, Btrieve, FoxPro і будь-який інший бази даних SQL, що підтримує стандарт ODBE. Це означає, що можна використовувати Access для створення такого додатка Windows, яке може обробляти дані, що надходять з мережевого сервера SQL або бази даних SQL на головній ЕОМ.

Все вище сказане дозволило зупинити вибір на СУБД Access для постановки та вирішення задачі автоматизації процесу ведення документації та звітності в навчальному закладі.

3. РОЗРОБКА БАЗИ ДАНИХ

3.1 Таблиці

Для ведення підрахунків складального цеху автозаводу база даних міститиме три таблиці "Вузли", "Замовлення", "Постачальники".

Таблиця "Вузли" містить інформацію про автомобілю, що поставляються до складального цеху (рис. 3.1.1).

Рис. 3.1.1 Таблиця "Вузли"

Таблиця "Замовлення" містить дані про вузли автомобілю, що необхідно поставити до цеху (рис. 3.1.2).

Рис. 3.1.2 Таблиця " Замовлення"

Таблиця "Постачальники" містить дані про постачальників автомобільних вузлів, з якими укладені угоди. (рис. 3.1.3).

Рис. 3.1.3. Таблиця " Постачальники"

Також визначаються реляційні зв'язки між таблицями. Кінцевим результатом даного етапу є таблиця реляційних зв'язків (рис. 3.1.4).

Рис. 3.1.4. Схема даних

3.2 Запити

Запити виконують відбір даних з бази даних за певними критеріями.

Призначення запитів ясно з їхньої назви: завдяки запитам ми отримуємо вибірки даних які нас цікавлять. Застосування запитів обумовлено, як правило, необхідністю пошуку і відбору конкретної інформації, оскільки вручну це зробити у великих таблицях практично неможливо: таблиці в міру їхнього наповнення стають просто неосяжними. За допомогою запитів можна не просто відібрати дані, але і скласти зведені дані з декількох таблиць.

3.2.1. на певну дату постачання (яка може бути введена як параметр) у таблиці замовлення.

Цей запит відноситься до найбільш часто використовуваних на практиці, на його основі ми будемо будувати деякі інші запити. У великих таблицях, що містять безліч полів, пошук конкретних даних ускладнюється тим, що на екрані ми бачимо не тільки потрібні дані, але і масу інформації, яка в даний момент не представляє інтересу. У цьому випадку допоможе звичайний запит на вибірку, який скоротить кількість відображуваних на екрані стовпців або зведе воєдино інформацію з декількох пов'язаних таблиць.

Для створення запиту в діалоговому вікні База даних потрібно перейти на вкладку «Створити» і натиснути на кнопці «Конструктор Запитів».

Після цього відкриється вікно конструктора запитів і поверх нього діалогове вікно Додавання таблиці (рис. 3.2.2). У цьому вікні потрібно вказати, на основі якої таблиці буде створений запит. Виділимо необхідну таблицю і натиснемо кнопку Додати. Після закінчення натиснемо кнопку Закрити. Тим самим перейдемо в режим конструктора запиту.

Рис. 3.2.2. Додавання таблиць.

У верхній частині вікна конструктора запитів знаходяться прямокутні області таблиць зі списками їх полів (рис 3.2.3).

Рис. 3.2.3. Додавання полів

Результатом роботи запиту буде таблиця зображена на (рис. 3.2.4).

Рис. 3.2.4. Запит на певну дату постачання у таблиці замовлення

3.2.2 підсумувати кількість найменувань вузлів для кожного постачальника.

Для створення запиту спочатку робимо дії як у попередньому запиті. Додаємо таблиці «Постачальники» і «Вузли». Встановлюємо необхідні поля, а саме «Назва постачальника» та «Код постачальника».

Для того щоб отримати підсумковий запит на наступному кроці натискаємо на іконку Зведення і в нас з'являється новий рядок де можна задати необхідні параметри, напроти поля «Код постачальника» вибираємо з розгорнутого списку значення «Count» (рис. 3.2.5).

Рис. 3.2.5. Параметр зведення.

В результаті цих дій ми отримаємо підсумкову таблицю (рис. 3.2.6).

Рис. 3.2.6. Підсумковий запит

3.2.3 по назві вузла та по назві виробника - код вузла

Даний вид запиту відноситься до перехресного запиту. Припустимо, що необхідно регулярно переглядати код вузла згідно назві вузла та назві виробника . У подібній ситуації не потрібно кожного разу складати новий запит, достатньо звернутися до можливостей перехресного запиту.

Для створення перехресного запиту необхідно включити режим Майстра запитів і вибрати перехресний запит (рис. 3.2.7).

Рис. 3.2.7. Створення перехресного запиту

Натискаємо далі і вибираємо таблицю вузли, натискаємо далі і майстер запитів пропонує нам вибрати необхідні поля, де ми додаємо до списку поля назва вузла та назва виробника, і натискаємо далі. У наступному кроці майстер запитів запропонує нам вибрати поля для використання їх в якості заголовків стовпчиків. Вибираємо поле код вузла, натискаємо далі. Далі Access пропонує нам вибрати необхідні обчислення для нашого запиту. Вибираємо наприклад поле вартість одиниці продукції та значення сума. Також у цьому вікні Access пропонує на підрахувати підсумок для кожного рядка, цю галочку ми знімаємо, так як нам це не потрібно (рис. 3.2.8). Натискаємо далі, готово і маємо результат нашого запиту (рис. 3.2.9).

Рис. 3.2.8. Додавання полів до перехресного запиту

Рис. 3.2.9. Перехресний запит

3.2.4 для кожного замовлення розрахувати вартість та суму до сплати(вартість замовлення +20%ПДВ).

Створення цього запиту після створення звичайного запиту додаємо поля для підрахунку, та створюємо поле «Вартість замовлення» з параметром - Стоимость заказа: [Количество]*[Стоимость_еденицы_продукции], поле «ПДВ 20%» з параметром - ПДВ 20%: '0,2'*[Стоимость заказа] і таким же чином створюємо поле «До сплати» з таким параметром - К оплате: [Стоимость заказа]+[ПДВ 20%] (рис. 3.2.10).

Рис. 3.2.10 Поля запиту «Сума до сплати»

Результат роботи (Рис.3.2.11).

Рис.3.2.11 Результат роботи запиту «До сплати».

3.2.5 суму замовлень для кожного постачальника на певну дату.

Цей запит створюємо на основі попереднього запиту, з якого додаємо поле «До сплати» з параметром Sum. Поле «Кількість замовлень» робимо з параметром Count, для підрахунку усіх замовлень для певного постачальника. Також створюємо умову відбору для поля «Дата замовлення» (рис. 3.2.12). Результат роботи (рис.3.2.13).

Рис.3.2.12

Рис.3.2.13 Результат роботи запиту

3.2.6 які вузли зовсім не використовувались за попередній квартал?

Запит створено з двох таблиць, де в полі Дата_замовлення введена умова відбору Not Between Date() And Date()-90 (Рис.3.2.14).

Рис.3.2.14 Конструктор запита.

Результат роботи (Рис.3.2.15).

Рис.3.2.15 вузли які зовсім не використовувались за попередній квартал.

3.2.7 для певного виробника збільшити тариф на 10%.

1) створюється запит на основі таблиці «Вузли» де буде використано лише два поля «Вартість_одиниці_продукції» та «Виробник». Поле «Виробник » вводимо умову відбору по назві виробника;

2) в режимі Конструктора на панелі інструментів активувати кнопку Оновлення. В рядку Оновлення поля «Вартість_одиниці_продукції» вводимо вираз - [Стоимость_еденицы_продукции]*([Наценка]+100)/100 (Рис.3.2.16).

Рис.3.2.16 Конструктор «Збільшення тарифу на 10%»

Результат роботи (Рис.3.2.17).

До

Після

Рис.3.2.17 Збільшення тарифу на 10%

3.2.8 створити таблицю найменувань вузлів для певного виробника.

Запит створюємо на базі таблиці «Вузли», додаємо необхідні поля. В режимі конструктора активуємо кнопку Створення таблиці (Рис.3.2.18).

Рис.3.2.18 Конструктор запиту на створення.

В результаті роботи запиту буде створено таблицю в якій розміститься найменування вузлів для певного виробника (Рис.3.2.19).

Рис.3.2.19 Запит на створення.

3.2.9 видалити з таблиці дані по певному вузлу.

Запит виконується з таблиці «Вузли», де буде використане лише одне поле «Назва вузла». В режимі конструктора на панелі інструментів активуємо кнопку «Видалення» та додаємо умову відбору поля «Назва вузла»(Рис.3.2.20).

Рис.3.2.20 Конструктор запиту на видалення.

Результаті роботи видалення запиту з таблиці «Вузли» (Рис.3.2.21).

До

Після

Рис.3.2.21 Запит на видалення.

ВИСНОВОК

Вирішуючи деяку задачу з використанням електронної таблиці або документу текстового процесора, ви одночасно визначаєте дані та задаєте необхідні функції і формули. Для нескладних задач з невеликими об'ємами даних такий шлях досить раціональний. Але з мірою накопичування інформації стає все трудніше працювати з великим числом електронних таблиць, або текстових файлів. В якийсь момент з доданням всього однієї транзакції (будь то надходження наказу чи нове вкладання засобів в вашому “інвестиційному “портфелі”) стає вже неможливо відстежувати усі файли. Крім того подібне додання може призвести до перевищення доступних об'ємів пам'яті вашої системи або пам'яті, що виділена для зберігання даних в вашій програмі. В зв'язку з тим, що більшість програм, що працюють з електронними таблицями, повинні завантажувати в оперативну пам'ять увесь файл електронної таблиці, саме недостатність виділених ресурсів, можливо і буде основною причиною, яка змусить вас звернутися до СУБД.

У даному курсовому проекті були розглянуто основні види баз даних, принципи роботи СУБД ACCESS. На прикладі бази даних «Складальний цех автозаводу» було розкрито прийоми створення таблиць, розглянуто та розкрито принципи створення різних видів запитів.

У результаті проведеної роботи була створена БД «Складальний цех автозаводу», яка зберігає інформацію про вузли, замовлення, постачальники та за допомогою запитів полегшує роботу з БД.

ЛІТЕРАТУРА

1. В. Андерсен.Ю.,Базы данных Microsoft Access. Проблемы и решения М.: Издательство ЭКОМ, 2001 г;

2. Винтер Рик, Microsoft Access 97, Справочник, С.-Пб., «Питер», 1999

3. Золотова С.И. Практикум по Access - М.: Финансы и статистика, 2001г.

4. Информатика. Практикум по технологии работы на компьютере./ Под ред. Н.В. Макаровой - м.: Финансы и статистика, 2005г.

5. Кузин А.В., Демин В.М.Разработка баз данных в системе Microsoft Access: Учебник - Учебник - м.: Форум: Инфра-М, 2005г.

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

...

Подобные документы

  • Створення баз даних з використанням платформи Microsoft Access 2010 та структурованих запитів SQL. ER-діаграма бази даних з описом кожної сутності та її атрибутів. Розробка інтерфейсу, елементів навігації та макросів для автоматичного виконання запитів.

    курсовая работа [3,1 M], добавлен 21.08.2014

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

    дипломная работа [3,1 M], добавлен 16.11.2014

  • Визначення необхідних даних для створення бази даних "Бібліотека", групування їх по таблицях. Передбачення ключових полів, зв’язків між таблицями Access. Створення запитів для функціонування фільтрів у головній формі, а також інтерфейсу користувача.

    курсовая работа [2,5 M], добавлен 22.01.2015

  • Проектування бази даних, що реалізує звіти про графік робіт на об’єктах впродовж місяця. Графічне зображення нагромаджувачів даних. Побудова діаграм потоків даних і переходів станів, таблиць у вигляді двовимірного масиву, запитів. Створення бази даних.

    курсовая работа [1,2 M], добавлен 29.02.2012

  • Реляційна модель баз даних. Цілісність бази даних. Нормалізація, нормальні форми та функціональні залежності. Нормальна форма Бойса-Кодда. Запити та форми Access. Процес нормалізації при побудові бази даних "Музей" та система запитів над даними.

    курсовая работа [2,9 M], добавлен 06.11.2013

  • Створення інформаційних таблиць бази даних. Створення екранних форм як засобу організації інтерфейсу користувача. Створення запитів для вибору, сортування і обчислення з використанням даних однієї таблиці. Оформлення звітів за допомогою команд MS Access.

    лабораторная работа [397,7 K], добавлен 09.09.2010

  • Система управління базами даних, ієрархічна модель даних, її проектування та створення. Інтерфейс Microsoft Access, створення структури таблиці, запитів, форм, звітів, макросів. Аналіз зв'язків між таблицями, що описують поняття проблемного середовища.

    курсовая работа [2,7 M], добавлен 10.11.2010

  • Вибір технологічного інструментарію для реалізації проекту. Розробка сценаріїв для створення бази даних і базових таблиць. Аналіз забезпечення декларативної цілісності реляційних даних. Особливість створення об'єктів для маніпулювання інформацією.

    курсовая работа [275,7 K], добавлен 17.05.2019

  • Основні поняття та особливості розробки баз даних в Microsoft Access. Побудова бази даних магазину побутової техніки: створення таблиць та встановлення зв’язків між ними, створення запитів, форм та звітів. Охорона праці і гігієна користувача комп'ютера.

    курсовая работа [2,5 M], добавлен 19.01.2010

  • Розробка структури бази даних. ER-моделі предметної області. Проектування нормалізованих відношень. Розробка форм, запитів, звітів бази даних "Автосалон". Тестування роботи бази даних. Демонстрація коректної роботи форми "Додавання даних про покупців".

    курсовая работа [4,0 M], добавлен 02.12.2014

  • Історія розробки систем управління базами даних. Принципи проектування баз даних. Розробка проекту "клієнт-серверного" додатку, який гарантує дотримання обмежень цілісності, виконує оновлення даних, виконує запити і повертає результати клієнту.

    курсовая работа [1,8 M], добавлен 22.04.2023

  • Аналіз та проектування бази даних по організації обліку та руху товарів на складах, обґрунтування вибору інструментального засобу. Застосування СУБД Microsoft Access, розробка таблиць бази даних. запитів, форм, конструювання звітів і організація захисту.

    курсовая работа [463,3 K], добавлен 07.06.2010

  • Визначення мети створення бази даних магазину та таблиць, які вона повинна містити. Розгляд видів полів та ключів таблиць. Створення запитів, форм, звітів, макросів та модулів. Вибір системи управління базами даних. Реалізація моделі у Microsoft Access.

    курсовая работа [3,8 M], добавлен 20.07.2014

  • Розробка бази даних "Автовокзал". Функціональні залежності між атрибутами. Ідентифікація атрибутів, які в реляційної моделі даних використовуються в якості первинних ключів реляційних відносин. Організація вибірки інформації з бази за допомогою запиту.

    курсовая работа [35,6 K], добавлен 19.08.2012

  • Форми вихідних документів. Перелік запитів до бази даних. Побудова інфологічної моделі, її структурні компоненти: сутності, зв’язки та відносини. Перелік таблиць, опис запитів. Загальна характеристика та головний зміст форм розроблюваної бази даних.

    курсовая работа [414,5 K], добавлен 31.01.2014

  • Основні відомості про реляційні бази даних, система управління ними. Основні директиви для роботи в середовищі MySQ. Визначення та опис предметної області. Створення таблиць та запитів бази даних автоматизованої бази даних реєстратури в поліклініці.

    курсовая работа [2,9 M], добавлен 06.11.2011

  • Розробка концептуальної і фізичної моделей бази даних по обліку концертних заходів, організаторів, артистів та призерів конкурсів. Код запиту на створення бази даних. Загальні види запитів в інформаційній системі. Розробка програмного коду головної форми.

    курсовая работа [1,5 M], добавлен 11.12.2011

  • Проектування і реалізація реляційної бази даних для централізованого зберігання інформації з метою полегшення і систематизації даних замовлень клієнтів готельного комплексу. Розробка сценаріїв для створення бази даних і базових таблиць проекту.

    курсовая работа [147,2 K], добавлен 02.06.2019

  • Відомості про бази даних, їх історія становлення та загальна інформація про Microsoft Visual FoxPro. Установка Visual FoxPro, створення проекту, таблиць, запитів. Аналіз реляційної бази даних. Прийоми проектування і реалізації реляційної бази даних.

    курсовая работа [1,6 M], добавлен 22.04.2019

  • Використання баз даних та інформаційних систем у сучасному житті. Основні відомості про реляційні бази даних. Зв'язування відносин. Структурована мова запитів SQL. Сутність та загальний опис бази даних "Архітектурна компанія". Приклад створення таблиці.

    курсовая работа [320,7 K], добавлен 19.06.2015

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.