Проектування інформаційної системи Меблевий салон

Вступ

Microsoft Access на сьогоднішній день є одним з найпоширеніших настільних додатків для роботи з базами даних. Це пов'язане з тим, що Access має дуже широкий діапазон засобів для уведення, аналізу й подання даних. Ці засоби є не тільки простими й зручними, але й високопродуктивними, що забезпечує високу швидкість розробки додатків. Споконвічно Access мала ряд унікальних можливостей, таких як уміння зводити воєдино інформацію із самих різних джерел (електронних таблиць, текстових файлів, інших баз даних), подання даних у зручному для користувача виді за допомогою таблиць, діаграм, звітів, інтеграція з іншими компонентами Microsoft Office [4].

Будь-яка інформаційна система по своїй природі є антропоморфною. Звичайно такі системи проектуються на основі досвіду, інтуїції й взаємодії із замовником. Застосовуються технології SSDAM у методології структурного аналізу й проектування системи, в основі якої – наступність при проектуванні. З 1993 року ця технологія є стандартом Великобританії, а з 1998 – європейським стандартом. Відповідно до цього стандарту, відповідальним етапом проектування інформаційної системи є предпроектна стадія, на якій проводиться співбесіда з виконавцями робіт, які підлягають автоматизації. Ці працівники в перспективі і є користувачами інформаційної системи [1].

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

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

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

1. Опис предметної області

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

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

Для розробки інформаційної системи «Меблевий салон» необхідні наступні дані:

· Інформація про продукцію: назва, ціна, тип.

· Інформація про партнерів: назва магазина, адреса, місто, телефон.

· Інформація про виготовлювача: виготовлювач.

2 Проектування інформаційної системи

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

Важливим і відповідальним етапом проектування інформаційної системи є предпроектна стадія, на якій проводиться співбесіда з виконавцями робіт, які підлягають автоматизації. Ці працівники в перспективі і є користувачами інформаційної системи [2].

2.1 Концептуальне (інфологічне) проектування

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

Початковою стадією проектування системи баз даних є побудова семантичної моделі предметної області, що базується на аналізі властивостей і природи об'єктів предметної області [2].

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

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

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

Зв'язок – це графічно зображувана асоціація, призначена для позначення виділеного відношення між двома або більше сутностями [2].

У даній інформаційній системі основними об'єктами є:

· склад: № п/п, партнер, продукція, кількість, дата поставки, дата продажу, тип операції.

· продукція: код продукції, назва, вага, ціна, виготовлювач.

· партнер: ідентифікаційний номер, магазин, адреса, місто, телефон.

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

2.1.1 Побудова ER-діаграми

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

1. Сутності зображуються прямокутниками.

2. Атрибути позначаються овалами.

3. Зв'язки зображуються ромбами.

2.1.2 Нормалізація ER-діаграми

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

- відновлення;

- видалення;

- уведення.

Надмірність і продуктивність інформаційної системи суперечливе, тому повне усунення надмірності іноді недоцільно.

Поняття нормалізації ставиться як до ER-діаграм, так і до таблиць реляційних баз даних.

Процес нормалізації складається з декількох етапів, на кожному з яких визначаються так називані нормальні форми: 1NF, 2NF, 3NF, BCNF (Бойка Кодла), 4NF, 5NF (форма проекції з'єднань) – PJ/NF. У більшості проектів третя нормальна форма завершує процес нормалізації.

Стосовно до ER-діаграм можна сформулювати наступні визначення нормалізації форм:

1NF – усунуті повторювані атрибути або групи атрибутів, виявлені неявні сутності.

2NF – усунуті атрибути, що залежать тільки від частини унікального складеного ключа. Ця частина визначає окрему сутність.

3NF – усунуті атрибути, що залежать від атрибутів, які не входять в унікальний ключ.

Дана ER-діаграма перебуває в 3NF, тому що сутності не мають властивостей, що залежать від не ключових властивостей [3].

2.2 Датологічне проектування бази даних

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

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

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

Реляційна модель даних має наступні властивості:

1. Кожен елемент таблиці – один елемент даних.

2. Всі поля в таблиці є однорідними, тобто мають один тип.

3. Кожне поле має унікальне ім'я.

4. Однакові записи в таблиці відсутні.

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

Таблиця 1 – «Замовлення»

Таблиця 2 – «Клієнти»

Таблиця 3 – «Меблі»

Таблиця 4 – «Назва»

Таблиця 5 – «Найменування»

Таблиця 6 – «Тип меблів»

Таблиця 7 – «Кольори»

Структура таблиць ставиться до 3 NF:

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

2. Первинні ключі таблиць однозначно визначають запис і не надлишкові.

3. Значення кожного поля не входить у первинний ключ, не залежить від значення іншого поля також не вхідного в первинний ключ.

2.3 Фізичне проектування інформаційних систем

Для розробки інформаційної системи була обрана СУБД Access.

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

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

Стадія фізичного проектування БД включає:

1. Вибір способу організації БД.

2. Розробку специфікації внутрішньої схеми БД засобами моделі даних.

3. Опис відображення концептуальної схеми БД у внутрішній структурі керування файлами.

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

· Вибір СУБД.

· Відновлення структури таблиць.

· Призначення типів полів для розподілу атрибутів сутностей.

· Можливе створення таких додаткових об'єктів як індекси, тригери (оброблювачі подій) і збережені процедури, що полегшують пошук у таблицях й обробку даних контролю цілісності [3].

2.4 Створення таблиць

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

Рисунок 2.3 – Таблиця «Замовлення»

Рисунок 2.4 – Таблиця «Клієнти»

Рисунок 2.5 – Таблиця «Меблі»

Рисунок 2.6 – Таблиця «Назва»

Рисунок 2.7 – Таблиця «Найменування»

Рисунок 2.8 – «Тип меблів»

Рисунок 2.9 – «Кольори»

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

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

Рисунок 2.10 – Створення зв'язків між таблицями

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

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

Рисунок 2.11 – Схема даних

2.3.2 Створення запитів

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

Для одержання інформації об замовлення за період

1) Запит Замовлення за період

Рисунок 2.12 – Запит на вибірку

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

2) Для більше наочного подання інформації використався перехресний запит заснований на запиті «Допоміжний»

Рисунок 2.14 – Перехресний запит

Рисунок 2.15 – Результат перехресного запиту

2) Запит на вибірку Кількість замовлень по типу меблів

Рисунок 2.16 – Запит на вибірку

Рисунок 2.17 – Кількість замовлень по типі меблів

2.3.3 Створення форм

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

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

Рисунок 2.18 – Головна форма

Основною формою є форма «Меблі», у якій представлені всі види меблів

Рисунок 2.19 – Форма Меблі

Додаткові форми відкриваються при натисканні на відповідні кнопки.

Кнопка «Клієнти» відкриває форму «Клієнти».

Рисунок 2.20 – форма «Клієнти»

Кнопка «Замовлення» відкриває форму «Замовлення».

Рисунок 2.21 – форма «Замовлення»

Кнопка «Запити» відкриває форму «Запити».

Рисунок 2..22 – форма «Запити»

Висновки

У даній курсовій роботі була спроектована інформаційна система «Меблевий салон», що може істотно полегшити роботу менеджера, директори. Ця інформаційна система була реалізована в СУБД Access.

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

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

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

У наслідку дану систему можна вдосконалювати, відповідно до потреб користувачів.

Курсова робота була виконана відповідно до завдання й у повному обсязі.

Дана БД займає місця на носії 56,2 МБ.

БД «Меблевий салон» містить:

· 7 таблиць;

· 8 запиту;

· 13 форм.

Список використаних джерел

1. Голицына О.Л., Максимов Н.В., Попов И.И. Базы данных – М.: Форум: Инфра-М, 2003. – 352 с.: ил.

2. Конспект лекций по предмету «Проектирование и эксплуатация информационных систем»

3. Петров В.Н. Информационные системы – СПб.: Питер, 2002. – 668 с.: ил.

4. Электронная книга «500 BOOKS»