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

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

Зміст

• Перелік умовних скорочень
• Вступ
• 1. Аналіз технічного завдання
• 2. Проектування бази даних
• 2.1 Концептуальне моделювання бази даних
• 2.2 Обгрунтування вибору СУБД
• 2.3 Логічне проектування бази даних
• Розробка додатку
• Висновки
• Література
• 
• Перелік умовних скорочень
• В процесі проектування бази даних будуть використані наступні скорочення:
• 1. СУБД - система управління базами даних
• 2. БД - база даних
• 3. ФЗ - функціональна залежність
• 4. 3НФ - третя нормальна форма
• 5. Зв'язок 1:1 - зв'язок один до одного
• 6. Зв'язок 1:М - зв'язок один до багатьох
• 7. Зв'язок М:М - зв'язок багато до багатьох

Вступ

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

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

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

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

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

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

1. Аналіз технічного завдання

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

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

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

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

- покупців, що придбають гітари у даному магазині;

- продавців, що працюють у магазині, їх адресу та номер телефону;

- гітари, їх особливості, клас, колір, звукознімачі, струни;

- виробників гітар;

- постачальників та об'єм поставок;

- кількість гітар на складі;

- товарообіг магазину;

- загальний прибуток магазину.

Інформація про кожного нового покупця заноситься в базу даних.

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

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

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

- введення, виведення і зберігання інформації про продавців;

- введення, виведення і зберігання інформації про гітари;

- виведення інформації про купівлю гітар по датах;

- видалення інформації про продавців;

- звіт з товарообігу магазина;

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

Для рішення цих задач необхідно розробити у додатку:

1. форми для введення інформації про покупців;

2. форми для введення інформації про продавців;

3. форми для введення інформації про гітари;

4. форму для перегляду наявності гітар на складі та підбору гітари за характеристикою;

5. форму для видалення інформації про продавців;

6. звіт з загального продажу магазину;

7. звіт з характеристиками гітар;

8. звіт про купівлю у певний день;

9. звіт з інформацією про продавців;

10. звіт з інформацією про покупців.

2. Проектування бази даних

2.1 Концептуальне моделювання бази даних

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

- Гитары - стержнева сутність

- Покупатели - стержнева сутність

- Продавцы - стержнева сутність

- Производители - стержнева сутність

- Поставщики - стержнева сутність

- Поставка

- Чек

- Склад - стержнева сутність

- Класс гитар

- Корпус

- Струны

- Звукосниматель

- Цвет

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

1. Зв'язок Класс гитар - Гитары (1:М )

Існує багато класів гітар, але гітара відноситься лише одного класу.

2. Зв'язок Корпус - Гитары (1:М)

Гітара може мати лише один корпус.

3. Зв'язок Производитель - Гитары (1:М)

Існує безліч виробників, але кожна гітара може мати лише одного.

4. Зв'язок Струны - Гитары (1:М)

Кожна гітара може мати лише один комплект струн, але самих комплектів безліч.

5. Зв'язок Звукосниматель - Гитары: (1:М)

Кожна гітара може мати лише один комплект звукознімачів.

6. Зв'язок Цвет - Гитары (1:М)

Кожна гітара може бути лише одного колір, але самих кольорів безліч.

7. Зв'язок Поставщики - Поставка (1:М)

Кожну поставку робить лише один постачальник.

8. Зв'язок Поставка - Гитары (М:М)

Цей тип звязку не може бути реалізований, тому вводимо сутність Склад.

9. Зв'язок Поставка - Склад (М:1)

Усі поставки надходять лише на один склад.



10. Склад - Гитары (1:М)

Усі гітари на одному складі.

11. Зв'язок Гитары - Покупатели (М:М)

Не може бути здійснено, тому вводимо сутність Чек.

12. Зв'язок Чек - Гитары (М:1)

Одну модель гітари можуть купувати багато разів.

13. Зв'язок Чек - Покупатели (М:1)

У чеку може бути зазначений лише один покупець.



14. Зв'язок Чек - Продавцы (М:1)

У чеку може бути зазначений лише один продавець.

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

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

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

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

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

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

2.2 Обгрунтування вибору СУБД

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

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

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

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

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

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

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

Перші СУБД почали виникати в 70-х роках. На даний час існують різні СУБД: dBase, FoxBase, SQL Server, FoxPro MS Access і т.д. Найчастіше використовуються СУБД 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 підвищує ефективність роботи розроблювачів, оскільки тепер вони мають справу не безпосередно з таблицями і полями, а з логічними інформаційними сутностями. Більш того, вони можуть створювати додатки, що дозволяють користувачам копіювати дані на власні пристрої, а пізніше синхронізувати їх з центральними серверами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3 Логічне проектування бази даних

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

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

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

1. Гитары - стержнева сутність

Гитары(код_гитары; код_класса; код_производителя; код_корпуса; код_струн; количество_струн; код_звукоснимателя; код_цвета; модель; цена)

Таблиця 2.1 - Структура сутності «Гитары»
Атрибут	Тип даних	Припустиме значення	Обов'язковість	Примітка
код_гитары	Лічильник	Довге ціле	Так
код_класса	Чисельний	Довге ціле	Так
код_производителя	Чисельний	Довге ціле	Так
код_корпуса	Чисельний	Довге ціле	Так
код_струн	Чисельний	Довге ціле	Так
количество_струн	Чисельний	Довге ціле	Так
код_звукоснимателя	Чисельний	Довге ціле	Так
код_цвета	Чисельний	Довге ціле	Так
модель	Текстовий	255 символів	Так
цена	Чисельний	Довге ціле	Так

2. Покупатели - стержнева сутність

Покупатели(код_покупателя; фамилия_покупателя; имя_покупателя; телефон_покупателя)

Таблиця 2.2 - Структура сутності «Покупатели»
Атрибут	Тип даних	Припустиме значення	Обов'язковість	Примітка
код_покупателя	Лічильник	Довге ціле	Так
имя_покупателя	Текстовий	50 символів	Так
фамилия_покупателя	Текстовий	50 символів	Так
Телефон_покупателя	Чисельний	Довге ціле	Ні

3. Продавцы - стержнева сутність

Продавцы(код_продавца; фамилия_продавца; имя_продавца; отчество_продавца; номер_телефона_продавца; адрес_продавца)

Таблиця 2.3 - Структура сутності «Партії»
Атрибут	Тип даних	Припустиме значення	Обов'язковість	Примітка
код_продавца	Лічильник	Довге ціле	Так
фамилия_продавца	Текстовий	50 символів	Так
имя_продавца	Текстовий	50 символів	Так
отчество_продавца	Текстовий	50 символів	Так
номер_телефона_продавца	Чисельний	Довге ціле	Ні
адрес_продавца	Текстовий	255 символів	Так

4. Производители - стержнева сутність

Производители(код_производителя; производитель)

Таблиця 2.4 - Структура сутності «Производители»
Атрибут	Тип даних	Припустиме значення	Обов'язковість	Примітка
код_производителя	Лічильник	Довге ціле	Так
производитель	Текстовий	25 символів	Так

5. Поставщики - стержнева сутність

Поставщики(код_поставщика; поставщик)

Таблиця 2.5 - Структура сутності «Поставщики»
Атрибут	Тип даних	Припустиме значення	Обов'язковість	Примітка
код_поставщика	Лічильник	Довге ціле	Так
поставщик	Текстовий	50 символів	Так

6. Поставка - асоціативна сутність, тому що реалізує зв'язок між базовими сутностями Поставщики та Склад.



Таблиця 2.6 - Структура сутності «Поставка»
Атрибут	Тип даних	Припустиме значення	Обов'язковість	Примітка
код_поставки	Лічильник	Довге ціле	Так
код_гитары	Чисельний	Довге ціле	Так
код_поставщика	Чисельний	Довге ціле	Так
количество	Чисельний	Довге ціле	Так
дата_поставки	Дата/час	дата	Так

7. Чек - асоціативна сутність, тому що реалізує зв'язок між базовими сутностями Покупатели, Продавцы та Склад.

Чек(код_чека; код_покупателя; код_гитары; количество; код_продавца; дата_покупки)

Таблиця 2.7 - Структура сутності «Чек»
Атрибут	Тип даних	Припустиме значення	Обов'язковість	Примітка
код_чека	Лічильник	Довге ціле	Так
код_покупателя	Чисельний	Довге ціле	Так
код_гитары	Чисельний	Довге ціле	Так
код_количество	Чисельний	Довге ціле	Так
код_продавца	Чисельний	Довге ціле	Так
дата_покупки	Дата/час	Дата	Так

8. Склад - стержнева сутність

Склад(код_гитары; количество)

Таблиця 2.8 - Структура сутності «Склад»
Атрибут	Тип даних	Припустиме значення	Обов'язковість	Примітка
код_гитары	Чисельний	Довге ціле	Так
количество_на_складе	Чисельний	Довге ціле	Так

9. Класс гитар - характеристична сутність, тому що розширює сутність Гитары.

Класс гитар(код_класса; класс)



Таблиця 2.9 - Структура сутності «Класс гитар»
Атрибут	Тип даних	Припустиме значення	Обов'язковість	Примітка
код_класса	Лічильник	Довге ціле	Так
класс	Текстовий	15 символів	Так

10. Корпус - характеристична сутність, тому що розширює сутність Гитары.

Корпус(код_корпуса; тип)

Таблиця 2.10 - Структура сутності «Корпус»

Атрибут	Тип даних	Припустиме значення	Обов'язковість	Примітка
код_корпуса	Лічильник	Довге ціле	Так
тип	Текстовий	15 символів	Так

11. Струны - характеристична сутність, тому що розширює сутність Гитары.

Струны(код_струн; струны)

Таблиця 2.11 - Структура сутності «Струны»
Атрибут	Тип даних	Припустиме значення	Обов'язковість	Примітка
код_струн	Лічильник	Довге ціле	Так
струны	Текстовий	10 символів	Так

12. Звукосниматель - характеристична сутність, тому що розширює сутність Гитары.

Звукосниматель(код_звукоснимателя; звукосниматель)

Таблиця 2.12 - Структура сутності «Звукосниматель»
Атрибут	Тип даних	Припустиме значення	Обов'язковість	Примітка
код_звукоснимателя	Лічильник	Довге ціле	Так
звукосниматель	Текстовий	15 символів	Так

13. Цвет - характеристична сутність, тому що розширює сутність Гитары.

Таблиця 2.13 - Структура таблиці «Цвет»
Атрибут	Тип даних	Припустиме значення	Обов'язковість	Примітка
код_цвета	Лічильник	Довге ціле	Так
цвет	Текстовий	10 символів	Так

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

Розробка додатку

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 3.1 - Таблиці створюваної бази даних

Таблиця «Гитары»

Спочатку треба визначитись які саме дані буде мати таблиця. Бачимо, що це основна таблиця із кодами та класифікацією гітар. Таблиця створюється у режимі конструктора. У стовпці «Имя поля» вказується унікальне ім'я кожного необхідного нам поля. Бажано щоб ім'я не співпадали навіть у різних таблицях. Перше поле - «код_гитары». Присвоюємо тип даних лічильник, та у розділі «Индексированное поле» обираємо «Да(совпадения не допускаются)». Це означає що кожна нова гітара буде мати свій унікальний номер-код. Це дозволяє нам уникнути конфлікту коли б дві різні гітари мали б один код. Наступний атрибут - «код_класса». Формат - «Числовой», поле обов'язкові, бо гітара не може не мати класу. Було обрано саме такий формат даних, бо цей атрибут розширюється в іншій таблиці. Таким же чином робляться й наступні поля.

Рисунок 3.2 - Таблиця «Гитары»

Таким же чином проектуємо наступні таблиці:

- Таблиця «Звукосниматель»

Містить інформацію про звукознімачі

- Таблиця «Класс гитар»

Містить інформацію про класифікацію гітар.

- Таблиця «Корпус»

Містить інформацію пр. окорпуси гітар.

- Таблиця «Покупатели»

Містить інформацію про покупців.

- Таблиця «Поставка»

Містить інформацію про поставки на склад.

- Таблиця «Поставщики»

Містить інформацію про поставників.

- Таблиця «Продавцы»

Містить інформацію про продавців.

- Таблиця «Производитель»

Містить інформацію про виробників.

- Таблиця «Склад»

Містить інформацію про кількість гітар на складі.

- Таблиця «Струны»

Містить інформацію про струни.

- Таблиця «Цвет»

Містить інформацію про кольори гітар.

- Таблиця «Чек»

Містить інформацію про покупки, дату, кількість та вартість.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Найпростіше форми створювати у режимі майстра за допомогою простого редагування.

- Форма «Подбор гитары»

Спочатку треба чітко визначитись для чого нам буде потрібна форма та що вона буде відображати. Наприклад, форма «подбор гитары» дозволяє проглядати дані про гітари та обрати зі списку існуючих саме ту, що підходить. Реалізується завдяки підлеглої форми та запиту «Запрос на гитары».



Рисунок 3.5 - Форма «Подбор гитары»

Для створення головної форми треба в майстрі створення форм обрати потрібну нам таблицю. Обираємо таблицю «Гитары». Обираємо в ній ті поля, якими будуть визначатися критерії пошуку та підбору. Це поля: код_класса, код_производителя, код_корпуса, код_струн, код_звукоснимателя, код_цвета. Усі інші поля форма буде генерувати сама. Далі треба перетворити поле у поле зі списком. Це робиться через контекстне меню. Обирається єлемень «Преобразовать элемент в» та у випадаючому меню обирається «Поле со списком». Перетворюємо таким чином усі поля. Набагато зручніше було б обирати певні назви аніж їх коди, тому треба щоб у списку відображалися самі назви. У контекстному меню «Свойства» елемента обирається закладень «Данные» та у полі «Источник строк» треба натиснути на кнопку. Відкривається вікно конструктора запитів. У цьому вікні необхідно обрати таблицю, в якій зазначені елементи обраного поля зі списку. Наприклад, обрали поле «класс_струн», тому таблицю треба обрати «Струны». Обираємо усі поля таблиці та закриваємо запит. Обирається закладень «Макет», та у графі «Число столбцов» треба зазначити «2», бо підключили 2 стовпці. У графі «Ширина стоблцов» треба зазначити «0;2,54», таким чином виділяємо для першого стовпця «код_класса» 0 см (його буде не видно), а на поле із назвою зазначили 2,54 см. Те ж саме робиться із наступними стовпцями.

Головну форму створено, але вона ще нічого не генерує. Треба створити запит, який би обирав за потрібними крітеріями гітари. Запит зручніше створювати у режимі конструктора.

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

У головній формі на панелі інструментів обирається «подчинённая форма/отчёт» та виділяється область, на якій саме буде розміщено нову підлеглу форму. Зі списку обираємо запит, який автоматично збережеться як підлегла форма.

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

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

- Форма «Чек»

Форма дозволяє додавати нові записи про купівлю гітар та перераховує кількість гітар на складі.

Робиться майстром із таблиці «Чек». Для додавання можна вставити кнопку та при виборі її функції обрати «Добавление записи».

- Форма «Новые покупатели»

Форма дозволяє додавати інформацію про нових покупців.

- Форма «Продавцы»

Форма дає можливість додавати, та видаляти записи стосовно продавців.

- Форма «Добавление гитар»

Форма дає можливість вводити інформацію про нові гітари.

- Форма «Поставка»

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

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

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

- Звіт «Покупатели»

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

Рисунок 3.7 - звіт «Покупатели»

- Звіт «Продавцы»

Звіт генерує інформацію про продавців магазину.

- Звіт «Покупки по дням»

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

- Звіт «Характеристики гитар»

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

- Звіт «Чек»

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

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

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

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

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

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

- Запит «Характеристики»

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

- Запит «Запрос на гитары»

Запит для формування підлеглої форми для виведення інформації по подбору гітари.

- Запит «Покупки по датам»

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

- Запит «Чек2»

Запит дає можливість перегляду загального продажу гітар.

- Запит «Обновить склад»

Оновлює інформацію про гітари на складі.

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

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

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

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



Висновки

У курсовому проекті була розроблена інформаційна система гітарного магазину.

База даних розроблялася в середовищі Microsoft Access.

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

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

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

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

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

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

...