Смекни!
smekni.com

База даних студії веб-дизайну (стр. 2 из 6)

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

Необхідно фіксувати укладання договору обох сторін, дату укладання та виконання, його виконання / невиконання, причини невиконання договору, або його успішне виконання.

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

У базі даних буде міститися інформація:

1.Відомості про працівників фірми (ПІБ, посада, контактна інформація).

2.Відомомсті про послуги (вид послуги, у залежності від виду необхідні дані, ціна).

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

4.Статистика (фінансовий облік за місяць, квартал та рік, тобто доходи, витрати, чистий прибуток)


2. Розробка проекту програмного забезпечення з базою даних аптеки

2.1 Розробка концептуальної моделі даних (ER-діаграми)

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

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

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

Складемо діаграму сутностей – ER-діаграму для студії веб-дизайну (див. рисунок 5).

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

2.2 Розробка специфікації програмних модулів

Всі програмні модулі будуть розроблені в середовищі Microsoft Access і приведені в додатках в SQL-коді, а також конструкторах форм, запитів, таблиць. Специфікація програмних модулів має наступну структуру (таблиця 2):

Таблиця 2 - Специфікація програмних модулів

Рівні модулів Назва модулів Опис
0 Головнаформа Меню програми, пункти якого є окремими кнопками і показують основні можливості програми. Вхідними даними є операція яку необхідно зробити.
1 Додаваннязамовника Дає можливість додавати замовника. Вхідні дані: ID_виробника, його ПІБ,адреса, телефон тав назва фірми.
1 Складання прайс-листу Дає можливість складати прайс-лист та друкувати його на відповідному пристрої. Вхідні дані: ID_послуги, вид, назва послуги, ціна послуги.Вихідні дані:вид послуги, назва послуги, ціна послуги.
1 Оформлення договору Дає можливість оформлювати договір та друкувати його на відповідному пристрої. Вхідні дані: ID_договору, положення договору, дата заключенняВихідні дані: код договору, положення договору, дата заключення.
1 Додавання послуги Дає можливість додавати послуги, які виникають у разі необходності для роботи.Вхідні дані: код послуги, назва послуги, ціна послуги, вид, виконавець.
1 Додаваннявиконавця Дає можливість додавати виконавця у базу. Вхідні дані: ID_виконавця, його ПІБ,адреса, телефон,дата народження, посада, заробітна плата.
1 Звіт про виконані договори Дає можливість надання інформації про договіри, які були заключені за певний період.Вхідні дані: період.Вихідні дані: кількість договорів, дата заключення, виконан/невиконан, код договору.
1 Запит покупця за видом Дає можливість видавати інформацію про наявність послуги за її видом.Вхідні дані: вид послуги.Вихідні дані: характеристики товару (вид,назва, код, ціна, виконавець, додаткові матеріали).
1 Запит покупця за назвою Дає можливість видавати інформацію про наявність відповідної послуги.Вхідні дані: назва послуги.Вихідні дані: характеристики товару (вид,назва, код, ціна, виконавець, додаткові матеріали).
1 Звітність студії Дає можливість скласти звітність студії.Вхідні дані: загальна сума,заробітна плата виконавця,дата замовлення / здачі,код замовника,кількість виконаних / невиконаних договорівВихідні дані: доходи,витрати,чистий прибуток, кількість виконаних договорів
1 Звіт про надані послуги Дає можливість зробити звіт про надані послуги.Вхідні дані: дата замовлення, дата здачі, код замовника, код виконавця,код послуги, кількість, назва послуги, ціна послугиВихідні дані:код послуги, код виконавця, загальна сума.

2.3 Розробка логічної моделі бази даних студії веб-дизайну

Логічна модель відображає логічні зв'язки між елементами даних. Вона формулюється в термінах бази даних, але не залежить від конкретної СУБД. На основі концептуальної моделі розробляється логічна модель бази даних (БД). Для кожного атрибута таблиці визначається тип даних, а саме: N - число, S - рядок, D - дата.

Для кожного із ключів також прийняті скорочення: PK - основний ключ, FK - зовнішній ключ.

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

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

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