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

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

ЗМІСТ

• Перелік умовних скорочень
• Вступ
• 1 Аналіз предметної області
• 2 Аналіз технічного завдання
• 3 Інфологічне моделювання предметної області
• 4 Створення логічної моделі предметної області
• 5 Обгрунтування вибору СУБД, в середовищі якої розроблятименться додаток
• 6 Реалізація логічної моделі у середовищі Microsoft Access
• Висновки
• Перелік посилань

ПЕРЕЛІК УМОВНИХ СКОРОЧЕНЬ

СКБД - система керування базами даних

БД - база даних

ФЗ - функціональна залежність

3НФ - третя нормальна форма

Зв'язок 1:1 - зв'язок один до одного

Зв'язок 1:М - зв'язок один до багатьох

Зв'язок М:М - зв'язок багато до багатьох

ВСТУП

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

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

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

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

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

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



1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ

інформаційна система база дане мережа

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

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

Інформаційна система магазину мережного устаткуванняповинназберігати інформацію про:

1 Устаткування та матеріали, які необхідні для апаратної організації мережі, поділ їх на групи за призначенням

2 Виробників мережного устаткування (у тому числі з якої країни надходить устаткування)

3 Поставку устаткування та матеріалів по датам, на який склад, скільки одиниць

4 Ціну за кожну одиницю найменування

5 Загальну вартість в залежності від кількості та ціни устаткування чи матеріалу

6 Склади, устаткування на них.

Інформаційна система повинна генерувати для подальшого використання в документообігу наступні звіти:

1 Перелік комплектуючого устаткування та матеріалів по виробникам

2 Чек (загальні витрати на організацію мережі)

3 Прибуток з продажу по датам

4 Поставка устаткування та матеріалів на склади.

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

1 Введення інформації про нове комплектуюче устаткування та матеріали

2 Введення інформації про нових виробників

3 Введення інформації про нових покупців

Інформаційна система повинна також забезпечувати можливість легкого внесення змін в БД, оновлення інформації.

2 АНАЛІЗ ТЕХНІЧНОГО ЗАВДАННЯ

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

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

Окремо ведеться контроль устаткування на складі: на якому складі, яке устаткування та скільки його одиниць зберігається. Все устаткування поділено на групи, кожна група має свій код.

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

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

База даних повинна містити звіти. Адже звіти забезпечують представлення збереженої інформації, виведеної на паперовий носій.

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

3ІНФОЛОГІЧНЕ МОДЕЛЮВАННЯ ПРЕДМЕТНОЇ ОБЛАСТІ

На основі аналізу предметної області виділяються такі сутності, як: Країна, Виробник, Покупець, Група, Устаткування, Чек, Склад. Між ними існують наступні зв'язки:

? Країна - Виробник

? Група - Устаткування

? Виробник - Устаткування

? Покупець - Устаткування

? Чек - Устаткування

? Покупець - Чек

? Чек - Склад

? Склад - Устаткування

Стержневими сутностями являються Покупець та Устаткування.

Розглянемо детально дані зв'язки.

Зв'язок Країна - Виробник 1:М : У магазин надходять товари виробників з різних країн. Але устаткування певного виробника надходить лише з конкретної країни.

Зв'язок Устаткування - Група М:1 : Кожен вид устаткування обов'язково входить до складу якоїсь групи (зазначається в переліку Групи 1 раз). Кожна група обов'язково має у своєму складі декілька видів устаткування.

Зв'язок Виробник - Устаткування 1:М : Кожне устаткування має лише одного виробника. Фірма-виробник, в свою чергу, виготовляє та постачає багато видів устаткування.

Зв'язок Покупець - Устаткування М:М : Кожний покупець може придбати будь-яке устаткування. Кожне устаткування може купити будь-який покупець.

Даний зв'язок не може бути реалізований в реляційній моделі. Тому його необхідно розчепити на два.

Сутність Чек являється асоціативною, адже зв'язує сутність Покупець (в чеку вказується покупець) і Устаткування (в чеку вказується товар).

Зв'язок Покупець - Чек 1:М : Кожний покупець може отримати декілька чеків, але кожний чек видається лише конкретному покупцеві. Зв'язок зі сторони чеку обов'язковий, так як кожному покупцеві обов'язково видається чек.

Зв'язок Чек - Устаткування М:М : Кожний товар може бути вказаний в декількох чеках і в кожному чеку може бути вказано декілька найменувань устаткування.

Вводимо сутність Склад.

Зв'язок Чек - Склад М:1 : З кожного складу може бути виписано декілька чеків, але один чек виписується лише з одного конкретного складу. Зв'язок обов'язковий зі сторони чека, так як при видачі якого-небудь устаткування зі складу обов'язково виписується чек.

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

Необхідно також розчепити сутність Чек - Устаткування на Чек - Перелік устаткування та Устаткування - Перелік устаткування, ввівши сутність Перелік устаткування.

Зв'язок Устаткування - Устаткування на складі 1:1 : Одному виду устаткування відповідає один запис в переліку устаткування на складі.

Зв'язок Склад - Устаткування на складі 1:М : На складі зберігається багато устаткування. Але вид даного устаткування на конкретному складі один.

Зв'язок Чек - Перелік устаткування М:1 : Кожний чек обов'язково має декілька записів з переліку устаткування. Кожний запис з переліку устаткування входить в чек один раз.

Зв'язок Устаткування - Перелік устаткування 1:1 : Кожен вид устаткування входить у перелік, в кожному записі переліку устаткування кожний вид устаткування може зазначатися лише один раз.

При розробці інформаційної моделі було зроблено наступне:

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

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

визначено попередній перелік атрибутів та зв'язано їх з конкретними типами сутностей;

визначено первинні та потенційні ключі для кожного об'єкту бази даних;

побудованоER- діаграму.

У розроблюваній БД створені наступні сутності:



Зв'язок обов'язковий зі сторони Виробника.

Ключі - Код_Виробника, Код_Устаткування.

Зв'язок обов'язковий зі сторони Країни.

Ключі - Код_Країни, Код_Виробника.

Зв'язок обов'язковий зі сторони Групи.

Ключі - Код_Устаткування, Код_Групи.

Розщепляємо даний зв'язок.

Перший зв'язок обов'язковий зі сторони Чека.

Другий зв'язок розчіпляємо.

Ключі - Код_Покупця, Код_Устаткування.



Зв'язок Чек - Склад обов'язковий зі сторони Чека.

Ключі - Код_Устаткування, № Складу, Код_Покупця.

Інші два зв'язки М:М розчіплюємо.

Перший зв'язок обов'язковий зі сторони Складу. Другий зв'язок обов'язковий зі сторони Устаткування_На_Складі.

Ключі - № Складу, Код_Устаткування.

Ключ - Код_Устаткування.



Перший зв'язок обов'язковий зі сторони Перелік устаткування. Другий зв'язок обов'язковий зі сторони Перелік_Устаткування.

Ключі - Код_Устаткування, Код_Покупця.

Ключ - Код_Устаткування.

Загальний вид ER-моделі представлено на рисунку 3.1.

Рисунок 3.1 - ER-модель БД

4СТВОРЕННЯ ЛОГІЧНОЇ МОДЕЛІ ПРЕДМЕТНОЇ ОБЛАСТІ

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

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

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

На основі аналізу предметної області виділяються такі сутності, як

1. Виробник - характеристична сутність, оскільки розширює опис сутності Устаткування (вказує Виробника устаткування).

Виробник(Код_Виробника, Код_Країни, Виробник)

2. Група - характеристична сутність, оскільки розширює опис сутності Устаткування (вказує групу, до якої належить устаткування).

Група(Код_Групи, Група)

3. Країна - характеристична сутність, оскільки розширює опис сутності Виробник (вказує країну Виробника устаткування).

Країна(Код_Країни, Країна)

4. Покупець - базова сутність, тому що існує незалежно ні від чого і зберігає інформацію про покупців.

Покупець(Код_Покупця, Покупець)

5. Склад - характеристична сутність, оскільки розширює опис сутності Устаткування (вказує № складу, на якому зберігається певне устаткування, дату поставки устаткування).

Склад(№_Склада,Код_Устаткування, Кількість, Дата_Поставки)

6. Устаткування - базова сутність, тому що існує незалежно ні від чого і зберігає інформацію про мережне устаткування.

Устаткування(Код_Групи, Код_Устаткування, Код_Виробника, Устаткування, Ціна)

7. Склади - характеристична сутність, оскільки розширює опис сутності Склад.

Склади(Код_Склада, Склад)

8. Чек - асоціативна, тому що реалізує зв'язок між базовими сутностями - Устаткування та Покупець. Дані сутності входять у склад сутності Чек у вигляді зовнішніх ключів.

Чек(Код_Покупця, Код_Устаткування, Кількість, Ціна, Вартість, Дата_Покупки).

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

Зв'язок Країна - Виробник 1:М. Зв'язок з боку сутності Виробник необов'язковий, зв'язок з боку сутності Країна обов'язковий. Створюємо два відношення - по одному для кожної сутності, ключ кожної сутності стає ключем відношення, ключ сутності, з необов'язковою участю стає зовнішнім ключем для сутності з обов'язковою участю.

Зв'язок Виробник - Устаткування 1:М. . Зв'язок з боку сутності Виробник обов'язковий, зв'язок з боку сутності Устаткування необов'язковий. Створюємо два відношення - по одному для кожної сутності, ключ кожної сутності стає ключем відношення, ключ сутності, з необов'язковою участю стає зовнішнім ключем для сутності з обов'язковою участю.

Зв'язок Устаткування - Група М:1. Зв'язок з боку сутності Устаткування необов'язковий, зв'язок з боку сутності Група обов'язковий. Створюємо два відношення - по одному для кожної сутності, ключ кожної сутності стає ключем відношення, ключ сутності, з необов'язковою участю стає зовнішнім ключем для сутності з обов'язковою участю.

Зв'язок Покупець - Чек 1:М. Зв'язок з боку сутності Покупець необов'язковий, зв'язок з боку сутності Чек обов'язковий. Створюємо два відношення - по одному для кожної сутності, ключ кожної сутності стає ключем відношення, ключ сутності, з необов'язковою участю стає зовнішнім ключем для сутності з обов'язковою участю.

Зв'язок Устаткування - Склад 1:М. Зв'язок з боку сутності Склад обов'язковий, зв'язок з боку сутності Устаткування необов'язковий. Створюємо два відношення - по одному для кожної сутності, ключ кожної сутності стає ключем відношення, ключ сутності, з необов'язковою участю стає зовнішнім ключем для сутності з обов'язковою участю.

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

5 ОБГРУНТУВАННЯ ВИБОРУ СУБД, В СЕРЕДОВИЩІ ЯКОЇ РОЗРОБЛЯТИМЕТЬСЯ ДОДАТОК

Кожна СУБД повинна розв'язувати такі задачі:

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

2. Введення даних в пам'ять - здійснюється контроль за вводом СУБД, вона керує розміщенням даних у пам'яті.

3. Експлуатація бази даних - користувач може обновити базу даних, додати чи вилучити, вибрати з бази даних необхідну інформацію.

4. Захист даних - він необхідний у випадку раптового виключення живлення і якщо декілька користувачів одночасно здійснюють доступ до даних.

5. Обробка даних - найчастіше це сортування даних, математична обробка даних, об'єднання даних.

6. Вивід даних на екран або тверді копії.

Перші СУБД почали виникати в 70-х роках. На даний час існують різні СУБД: dBase, FoxBase, SQLServer, FoxProMSAccess і т.д. Найчастіше використовуються СУБД SQL Server,FoxPro і Access. Нижче приведена коротка характеристика цих СУБД.

Можливості SQL Server 2008 відносяться до чотирьох основних напрямків розвитку представлень Mіcrosoft про платформу даних.

Mіssіon Crіtіcal Platform - SQL Server 2008 дозволяє організаціям виконувати найскладніші додатки, попутно спрощуючи відділам ІТ роботу з інфраструктурою керування даними. Це безпечна, надійна платформа, що захищає інформацію в додатках і підвищує її доступність. Включена в неї інноваційна інфраструктура керування, заснована на політиках, дозволяє визначати політики для явного й автоматичного адміністрування серверних сутностей на одному чи декількох серверах. Крім того, оптимізована платформа SQL Server 2008 відкриває шлях до передбачуваної продуктивності обробки запитів.

Dynamіc Development - SQL Server 2008 у сполученні с .NET Framework спрощує розробку нових додатків. Середовище ADO.NET Entіty Framework підвищує ефективність роботи розроблювачів, оскільки тепер вони мають справу не безпосередно з таблицями і полями, а з логічними інформаційними сутностями. Більш того, вони можуть створювати додатки, що дозволяють користувачам копіювати дані на власні пристрої, а пізніше синхронізувати їх з центральними серверами.

Beyond Relatіonal Data - SQL Server 2008 дозволяє розроблювачам керувати з даними будь-яких типів - від традиційних до географічних (geospatіal). Це відкриває дорогу до створення додатків нового покоління з урахуванням інформації про розташування і можливість керування документами.

Pervasіve Busіness Іnsіght - інфраструктура SQL Server 2008 стала більш масштабуючою. Вона здатна формувати звіти і виконувати аналіз будь-якого обсягу і складності, одночасно полегшуючи користувачам доступ до даних за рахунок більш тісної інтеграції з Mіcrosoft Offіce. У результаті ІТ-спеціалісти можуть поширити використання бізнес-аналітики по всій організації. SQL Server 2008 дозволяє користувачам консолідувати різнорідні дані в корпоративному сховищі, виводячи організацію сховищ даних на новий рівень.

Загальна характеристика СУБД VisualFoxPro

СУБД VFP -- це реляційна база даних. Кожна таблиця зберігається в окремому файлі з розширенням dbf. Усі інші об'єкти -- форми (form), запити (query), звіти (report), програми (program), меню (menu), уявлення (view) теж зберігаються в окремих файлах з відповідними типами.

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

Система управління базами даних Microsoft Access

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

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

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

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

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

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

? контекстне меню;

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

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

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

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

Етапи створення бази даних у середовищі MicrosoftAccess:

? визначення мети створення бази даних;

? визначення таблиць, які повинна містити база даних;

? визначення структури таблиць (полів та їх типів);

? призначення ключів таблиць та створення потрібних індексів;

? визначення зв'язків між таблицями;

? завантаження даних;

? створення інших об'єктів бази даних: запитів, форм, звітів, макросів та модулів;

? аналіз ефективності бази даних за допомогою майстра таблиць (меню СЕРВИС =>АНАЛИЗ =>ТАБЛИЦА) та аналізатора швидкодії (меню СЕРВИС =>АНАЛИЗ =>БЬІСТРОДЕЙСТВИЕ).

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

6 РЕАЛІЗАЦІЯ ЛОГІЧНОЇ МОДЕЛІ У СЕРЕДОВИЩІ MICROSOFT ACCESS

База даних створена у середовищі СКБД Access 2003.

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

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

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

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

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

кожне поле має бути пов'язане з темою таблиці;

не рекомендується включати до таблиці дані, що є результатом виразу;

у таблиці має бути вся необхідна інформація;

інформацію варто розбивати на найменші логічні одиниці.

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

Розроблювана БД складається з восьми таблиць (рис. 6.1):Виробник, Група, Країна, Покупець, Склад, Устаткування, Склади, Чек. Всі таблиці створювались у режимі Конструктора.У таблицях дані розміщені по стовпцях та рядках (кортежах). Всі дані одного стовпця одного типу, описують інформацію одної категорії. Таблиці містять інформацію щодо виробників устаткування; груп, на які поділене устаткування; країн-виробників; покупців; складу, устаткування на ньому та кількість; устаткування; покупок устаткування.



Рисунок6.1- Таблиці створюваної БД

Таблиця Виробник

Атрибути:

1. Код_Виробника - тип даних - числовий, обов'язкове поле, збіги не допускаються.

2. Код_Країни - тип даних - числовий, обов'язкове поле, збіги допускаються.

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

Рисунок 6.2- Таблиця Виробник



Таблиця Група

Атрибути:

1. Код_Групи - тип даних - текстовий, обов'язкове поле, пусті рядки не допускаються, збіги не допускаються.

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

Рисунок6.3 - Таблиця Група

Таблиця Країна

Атрибути:

1. Код_Країни - тип даних - числовий, обов'язкове поле, збіги не допускаються.

2. Країна - тип даних - текстовий, обов'язкове поле, збіги не допускаються, пусті рядки не допускаються.



Рисунок 6.4- Таблиця Країна

Таблиця Покупець

Атрибути:

1. Код_Покупця - тип даних - лічильник, збіги не допускаються.

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

Рисунок 6.5- Таблиця Покупець



Таблиця Склад

Атрибути:

1. №_Склада - тип даних - числовий, обов'язкове поле, збіги допускаються.

2. Код_Устаткування - тип даних - текстовий, обов'язкове поле, збіги допускаються, пусті рядки не допускаються.

3. Кількість - тип даних - числовий, обов'язкове поле, збіги допускаються.

Рисунок 6.6- Таблиця Склад

Таблиця Устаткування

Атрибути:

1. Код_Групи - тип даних - текстовий, обов'язкове поле, збіги допускаються, пусті рядки не допускаються.

2. Код_Устаткування - тип даних - текстовий, обов'язкове поле, збіги не допускаються, пусті рядки не допускаються.

3. Код_Виробника - тип даних - числовий, обов'язкове поле, збіги допускаються.

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

5. Ціна - тип даних - грошовий, обов'язкове поле, збіги допускаються.

Рисунок 6.7- Таблиця Устаткування

Таблиця Чек

Атрибути:

1. Код_Покупця - тип даних - числовий, обов'язкове поле, збіги допускаються.

2. Код_Устаткування - тип даних - текстовий, обов'язкове поле, збіги допускаються, пусті рядки не допускаються.

3. Кількість - тип даних - числовий, обов'язкове поле, збіги допускаються.

4. Ціна - тип даних - грошовий, обов'язкове поле, збіги допускаються.

5. Вартість - тип даних - грошовий, обов'язкове поле, збіги допускаються.

6. Дата_Покупки - тип даних - дата/час, обов'язкове поле, збіги допускаються.

Рисунок 6.8- Таблиця Чек

Таблиця Склади

Атрибути:

1. Код_Склада - тип даних - лічильник, збіги не допускаються.

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



Рисунок 6.9- Таблиця Склади

БД містить форми (рис. 6.10), які використовують для введення, редагування, зміни даних у таблицях. У формах можна додавати, переглядати, сортувати та розшукувати необхідні дані.

Рисунок 6.10- Форми бази даних



Форма являє собою деякий електронний бланк, у якому є поля для введення даних. Розроблювач БД вводить дані в ці поля, і дані автоматично заносяться в таблиці бази.

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

По-перше, малокваліфікованому персоналу не можна давати доступ до таблиць (найціннішому з того, що є в базі).

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

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

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

Форма Виробник

Дана форма дозволяє вводити нову інформацію про виробників мережного устаткування, редагувати вже внесену та видаляти непотрібну. Ці дії виконуються за допомогою кнопок, які розміщені на формі (рис.6.11).Поле країна - поле зі списком.

Рисунок 6.11- Форма Виробник

Форма Група

Форма дозволяє проглядати дані про групи устаткування, що вже були занесені до БД, додавати нові записи та видаляти непотрібні.

Рисунок 6.12- Форма Група

Форма Країна

Форма дає можливість вносити зміни щодо інформації по країнам-виробникам - заносити та видаляти записи.



Рисунок 6.13- Форма Країна

Форма Покупець

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

Рисунок 6.14- Форма Покупець

Форма Покупка

Дана форма дозволяє вносити зміни щодо покупок устаткування. Поля Покупецьта Устаткування перетворені в поля зі списком (рис. 6.16). Користувач має змогу обрати потрібного покупця та устаткування. На формі присутня кнопка Ціна на устаткування, що дозволяє за вказаним вище кодом устаткування швидко знайти його ціну. Це спрощує роботу з формою. Кнопка Просмотр чека - дозволяє переглянути інформацію з таблиці Чек.

На основі даних цієї форми формуються звіти Чек та Чек для 1 покупця.

Рисунок 6.15 - Форма Покупка

Рисунок 6.16- Поле зі списком

Форма Склад

Працюючи з формою Склад, користувач може редагувати дані щодо складів - проглядати, додавати та видаляти записи. Поля № Склада та Устаткування перетворено в поля зі списком.



Рисунок 6.17- Форма Склад

Форма Устаткування

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

Рисунок 6.18- Форма Устаткування



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

Рисунок 6.19- Звіти бази даних

Звіт Виробник

Звіт генерує в собі інформацію про виробників устаткування, яке представлене в магазині.



Рисунок 6.20- Звіт Виробник

Звіт Група

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

Рисунок 6.21 - Звіт Група



Звіт Країна

Звіт Країна виводить інформацію про країни-виробники.

Рисунок 6.22- Звіт Країна

Звіт Склад

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

Звіт Устаткування

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

Звіт Устаткування по виробникам

Звіт виводить інформацію про устаткування , яке виробляє кожен виробник. Рівні групування - Код_Виробника та Код_Групи. Спочатку дані сортуються за кодом виробника, а потім всередині рівня по групам.

Рисунок 6.23- Звіт Склад



Рисунок 6.24- Звіт Устаткування

Рисунок 6.25- Звіт Устаткування по виробникам



Звіт Чек

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

Рисунок 6.26- Звіт Чек

Звіт Чек для 1 покупця

Даний звіт відрізняється від попереднього тим, що виконується на основі запиту з параметром - введіть код покупця (рис. 6.27), а також звіт виводить не всю інформацію про зроблені в магазині покупки, а лише ту інформацію, що стосується конкретного покупця та його покупки (рис. 6.28). У цьому звіті виводиться інформація щодо придбаного мережного устаткування, вартості покупки та дата покупки.



Рисунок 6.27- Введення значення параметру

Рисунок 6.28- Звіт Чек для 1 покупця

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

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

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

Рисунок 6.29 - Запити бази даних



Запит Оновлення ціни

Даний запит - на оновлення(UpdateQuery). Він змінює значення поля Ціна у записах таблиці Устаткування (рис. 6.32). Запит з параметрами - введіть нову ціну та введіть код устаткування (рис. 6.30 та рис. 6.31). Спочатку вводиться ціна, яку потрібно обновити, а потім код устаткування на цю ціну.

Рисунок6.30 - Введення значення параметру



Рисунок 6.31 - Введення значення параметру

Рисунок 6.32 - Оновлення записів у таблиці Устаткування

Запит Покупка_Чек

Даний запит - на створення таблиці (Make-Table Query), створює таблицю Чек на основі даних, що містяться в запиті на вибірку. В запиті також міститься обчислюване поле - вираховується вартість покупки.

Запит Чек для 1 покупця

Даний запит - на вибірку, містить умови добору даних і повертає вибірку, що відповідає зазначеним умовам, без зміни даних. Умова вибірки - параметр запиту. Вводиться код покупця (рис. 6.34), а потім видається таблиця (рис. 6.35) з зазначенням устаткування, що купується покупцем, його ціна та вартість покупки.

Рисунок 6.33 - Запит на створення таблиці

Рисунок 6.34 - Запит на вибірку

Рисунок 6.35 - Результат запиту на вибірку



Запит Чек1

Запит на вибірку. Запит вираховує вартість покупки покупця.

Рисунок 6.36 - Запит Чек1

Генерація схеми бази даних

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

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

1. Сервис Схема данных

2. У вікні Добавление таблицы за допомогою кнопки Добавить послідовно обираємо всі таблиці, між якими встановлюється зв'язок закрити вікно Добавление таблицы

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

4. У вікні Изменение связей встановлюємо прапорець Обеспечение целостности данных, Каскадное обновление связанных полей та Каскадное удаление связанных записей Создать

У вікні Схема данных з'являється лінія зв'язку між відповідними полями, звичайно, 1:М або 1:1.

Рисунок 6.37 - Схема бази даних

У базі даних, що розробляється в курсовому проекті, була створена кнопкова форма (рис.39).

Кнопкова форма є не що інше, як Меню для роботи в базі даних. У меню може бути декілька вкладених підменю.

При створенні бази даних за допомогою майстра автоматично створюється кнопкова форма, що допомагає переміщатися по базі даних. На кнопкову панель поміщаються кнопки, при натисканні яких відкриваються форми або звіти (або відкриваються інші кнопкові форми, за допомогою яких відкриваються інші форми або звіти), здійснюється вихід з Microsoft Access або змінюється сама кнопкова форма. При створенні кнопкової форми за допомогою диспетчера кнопкових форм Microsoft Access створює таблицю Элементы кнопочной формы, яка містить опис кнопок, що виводяться у формі, і виконуваних ними дій.

Дана кнопкова форма є стартовою - відкривається за замовчуванням при запуску бази даних.Саму базу даних сховано. 

Рисунок 6.38 - Кнопкова форма

ВИСНОВКИ

У курсовому проекті була розроблена база даних магазину мережного устаткування.

БД розроблялася в середовищі MicrosoftAccess. Нижче наведені основні етапи проектування бази даних:

? визначення мети створення бази даних;

? визначення таблиць, які повинна містити база даних;

? визначення структури таблиць (полів та їх типів);

? призначення ключів таблиць;

? визначення зв'язків між таблицями;

? завантаження даних;

? створення інших об'єктів бази даних: запитів, форм, звітів, макросів та модулів;

? аналіз ефективності бази даних за допомогою майстра таблиць.

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

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

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

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

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

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