Розробка бази даних для автоматизованого вирішення комплексу функціональних задач "Облік оплати водопостачальних послуг"
Проект бази даних для автоматизованого вирішення задач "Облік оплати водопостачальних послуг". Опис інфологічної моделі бази даних та її складових частин. Побудова діаграми "Сутність-зв'язок". Реалізація проекту СУБД MS Access, MySQL та MS SQL Server.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | украинский |
| Дата добавления | 19.02.2017 |
| Размер файла | 1003,5 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.Allbest.ru/
Размещено на http://www.Allbest.ru/
Міністерство освіти і науки, молоді та спорту України
Державний вищий навчальний заклад
Київський національний економічний університет ім. В. Гетьмана
Криворізький економічний інститут
КУРСОВА РОБОТА
з дисципліни «Бази даних»
на тему:
Розробка бази даних для автоматизованого вирішення комплексу функціональних задач «Облік оплати водопостачальних послуг»
Кривий Ріг - 2011 р.
ЗМІСТ
- ВСТУП
- Розділ 1. Дослідження предметної області
- 1.1 Визначення функціональних задач предметної області
- Розділ 2. Створення проекту бази даних
- 2.1 Опис інфологічної моделі бази даних
- 2.2 Побудова та опис діаграми "Сутність-зв'язок"
- Розділ 3. Реалізація проекту бази даних
- 3.1 Реалізація проекту бази даних у СУБД MS Access
- 3.2 Реалізація проекту бази даних у СУБД MySQL
- 3.3 Реалізація проекту бази даних у СУБД Microsoft SQL Server
- ВИСНОВКИ
- СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ
- ВСТУП
- Забезпечення комфортних умов життя є актуальним та важливим питанням соціальної економіки. Вирішенням цього питання займаються житлово-комунальні підприємства. Цілком зрозуміло, що на будь-якому підприємстві для упорядкування вхідних та вихідних даних потрібно вести їх облік.
- Розгляд питань обліку житлово-комунальних послуг, а конкретно з теми курсової роботи - водопостачальних, потребує залучення різних засобів дослідження, обробки, представлення та зберігання інформації. Здійснення збору, аналізу та розрахунків даних у паперовому вигляді є не ефективним та працемістким процесом, що ускладнює виконання функціональних обов'язків працівника. Тому впровадження комп'ютерних технологій є актуальною темою не тільки для житлово-комунальної, але й взагалі - для усієї соціально-економічної діяльності.
- Фіксування особливостей вироблення та виконання житлово-комунальних послуг для забезпечення потреб фізичних чи юридичних осіб, є дуже важливим для взаємодії між постачальниками та користувачами, тому важливо виробити ефективні методи збору, обробки та використання даних. Саме таким інструментом є база даних. Головним завданням бази даних є гарантоване збереження значних обсягів інформації та надання доступу до неї користувачеві або ж прикладній програмі.
- Для обраної теми впровадження автоматизованої бази даних надасть такі переваги:
- поліпшення процесу нарахування та оплати населенням платежів за водопостачальні послуги;
- надання постачальникові можливості самостійно вести облік своїх абонентів та нараховувати суми до сплати за спожиті послуги;
- надання користувачеві можливості слідкування за споживанням послуг.
РОЗДІЛ 1. ДОСЛІДЖЕННЯ ПРЕДМЕТНОЇ ОБЛАСТІ
1.1 Визначення функціональних задач предметної області
Будь-яке дослідження полягає в спостереженні за властивостями об'єктів з метою з'ясування та оцінювання значущих відносин і взаємозв'язків між показниками цих властивостей. Предметна область включає в себе об'єкти, які розрізняються за властивостями і певним чином знаходяться в певному відношенні і взаємопов'язані між собою. Отже вирішення поставлених у курсовій роботі задач починається з дослідження предметної області.
Предметною областю для даної курсової роботи є підприємство, основне завдання якого -- надання послуг з водопостачання та водовідведення для населення. Розрахунки з користувачами по оплаті послуг займає особливе місце в системі обліку підприємчої установи. Так як темою роботи є саме облік оплати водопостачальних послуг, визначимо у таблиці 1.1 які саме функціональні задачі виконуються при взаємодії між підприємством та користувачами у даному випадку.
Таблиця 1.1
Комплекс функціональних задач предметної області
|
Найменування задачі |
Призначення задачі |
|
|
1 |
2 |
|
|
Облік користувачів послуг |
Збереження особистих даних користувача для зворотнього зв'язку |
|
|
Облік лічильників |
Збереження даних про наявність та кількість лічильників користувача послуг, а також місце їх установки |
|
|
Облік показаннь лічильників |
Збереження та обілк показників лічильників для виведення нарахувань за використані послуги |
Кожна фізична особа, яка бажає отримувати послуги даного підприємства, повинна зареєструвати свої дані у базі установи. Після реєстрації користувач отримає можливість передавати показання за використані послуги підприємству, яке після цього надасть користувачеві доступ до перегляду інформації про суми нарахування.
Для обліку використаних послуг у місці їх надання повинні бути встановлені лічильники. Так, наприклад, у житлових будинках можуть бути встановлені загальні лічильники на весь будинок, або ж кожна квартира будинку може мати індивідуальні лічильники.
Для розрахунку оплати за використані послуги підприємству потрібно мати показники лічильників. Вирахувавши різницю між поточними та попередніми показаннями, працівник отримує значення, яке після множення на встановлену ціну за послугу дає остаточну суму до нарахування користувачеві. В свою чергу користувач може прослідкувати правильність суми нарахувань за допомогою тих же показників лічильників.
РОЗДІЛ 2. СТВОРЕННЯ ПРОЕКТУ БАЗИ ДАНИХ
2.1. Опис інфологічної моделі бази даних
Для проектування бази даних потрібно уважно проаналізувати предметну область та виділити її основні складові частини: об'єкти та їх атрибути, а також визначити функціональні залежності між ними.
Для зберігання інформації про користувача створимо об'єкт «КАРТКА АБОНЕНТА». Детальний опис атрибутів об'єкта наведено у таблиці 2.1.
Таблиця 2.1
Приклад опису складових елементів об'єкта «КАРТКА АБОНЕНТА»
|
Назва атрибута |
Формат |
Відсоток наявності |
Обмеження на право звертання до значень атрибута |
Частота використання |
Виводимість значень |
Дублювання значень |
Область допустимих значень |
Роль атрибутів та їхні характеристики |
|
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
|
|
ID _картки_абонента |
9(4) |
100% |
Мають право робітники бухгалтерського відділу |
-- |
-- |
Ні |
-- |
Для ідентифікації користувача послуг |
|
|
ПІБ_власника |
А(20). А(1). А(1). |
100% |
-- |
-- |
Так |
-- |
Для зберігання прізвища та ініціалів користувача послуг |
||
|
Вулиця |
А(30) |
100% |
-- |
-- |
Так |
-- |
Для зберігання назви вулиці проживання користувача |
||
|
Дім |
9(2) |
100% |
-- |
-- |
Так |
-- |
Для зберігання номеру дому проживання користувача |
||
|
Квартира |
9(3) |
100% |
Мають право робітники бухгалтерського відділу |
-- |
-- |
Так |
-- |
Для зберігання номеру квартири проживання користувача |
|
|
ID_пільги |
9(2) |
50% |
-- |
-- |
Так |
-- |
Для зберігання номеру пільги |
||
|
ID_тарифа |
9(2) |
100% |
-- |
-- |
Так |
-- |
Для зберігання номеру тарифу, по якому обслуговується користувач |
Для зберігання інформації про тарифи, за якими обслуговується користувач створимо об'єкт «ТАРИФ». Детальний опис атрибутів об'єкта наведено у таблиці 2.2.
Таблиця 2.2
Приклад опису складових елементів об'єкта «ТАРИФ»
|
Назва атрибута |
Формат |
Відсоток наявності |
Обмеження на право звертання до значень атрибута |
Частота використання |
Виводимість значень |
Дублювання значень |
Область допустимих значень |
Роль атрибутів та їхні характеристики |
|
|
ID_тарифу |
9(8) |
100% |
Мають право робітники бухгалтерського відділу |
-- |
-- |
Ні |
-- |
Для ідентифікації тарифу |
|
|
Тип_тарифу |
А(20) |
100% |
-- |
-- |
Так |
-- |
Для зберігання типу тарифу |
||
|
ID_послуги |
9(8) |
100% |
-- |
-- |
Так |
-- |
Для зберігання типу наданої послуги |
||
|
Ціна_тарифу |
9(4).9(2) |
100% |
-- |
-- |
Так |
-- |
Для зберігання ціни за використання тарифу |
Для зберігання інформації про послуги, які підприємство надає користувачу створимо об'єкт «ПОСЛУГА». Детальний опис атрибутів об'єкта наведено у таблиці 2.3.
Для зберігання інформації про пільги, які може мати користувач послуг створимо об'єкт «ПІЛЬГА». Детальний опис атрибутів об'єкта наведено у таблиці 2.4.
Таблиця 2.3
Приклад опису складових елементів об'єкта «ПОСЛУГА»
|
Назва атрибута |
Формат |
Відсоток наявності |
Обмеження на право звертання до значень атрибута |
Частота використання |
Виводимість значень |
Дублювання значень |
Область допустимих значень |
Роль атрибутів та їхні характеристики |
|
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
|
|
ID_послуги |
9(2) |
100% |
Мають право робітники бухгалтерського відділу |
-- |
-- |
Ні |
-- |
Для ідентифікації наданої послуги |
|
|
Вид_послуги |
А(20) |
100% |
-- |
-- |
Так |
-- |
Для збереження виду наданої послуги |
Таблиця 2.4
Приклад опису складових елементів об'єкта «ПІЛЬГА»
|
Назва атрибута |
Формат |
Відсоток наявності |
Обмеження на право звертання до значень атрибута |
Частота використання |
Виводимість значень |
Дублювання значень |
Область допустимих значень |
Роль атрибутів та їхні характеристики |
|
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
|
|
ID_пільги |
9(2) |
100% |
Мають право робітники бухгалтерського відділу |
-- |
-- |
Ні |
-- |
Для ідентифікації пільги користувача |
|
|
Назва_пільги |
А(20) |
100% |
Мають право робітники бухгалтерського відділу |
-- |
-- |
Так |
-- |
Для зберігання назви пільги користувача |
|
|
Ціна_пільги |
9(4).9(2) |
100% |
-- |
-- |
Так |
-- |
Для зберігання ціни за наявну пільгу |
Для зберігання інформації про лічильники, які може мати користувач послуг створимо об'єкт «ЛІЧИЛЬНИК». Детальний опис атрибутів об'єкта наведено у таблиці 2.5.
Таблиця 2.5
Приклад опису складових елементів об'єкта «ЛІЧИЛЬНИК»
|
Назва атрибута |
Формат |
Відсоток наявності |
Обмеження на право звертання до значень атрибута |
Частота використання |
Виводимість значень |
Дублювання значень |
Область допустимих значень |
Роль атрибутів та їхні характеристики |
|
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
|
|
ID_лічильника |
9(8) |
100% |
Мають право робітники бухгалтерського відділу |
-- |
-- |
Ні |
-- |
Для ідентифікації лічильника користувача |
|
|
Місце_установки |
А(20) |
100% |
-- |
-- |
Так |
-- |
Для збереження інформації про місце установки лічильника |
||
|
Початкове_показання |
9(9) |
100% |
-- |
-- |
Так |
-- |
Для зберігання початкового показання лічильника |
||
|
ID_картки_абонента |
9(4) |
100% |
-- |
-- |
Так |
-- |
Для ідентифікації лічильника з користувачем по номеру картки |
Для зберігання інформації про лічильники, які може мати користувач послуг створимо об'єкт «ПОКАЗНИК ЛІЧИЛЬНИКА». Детальний опис атрибутів об'єкта наведено у таблиці 2.6.
Для зберігання інформації і розрахунку значень нарахування за використані послуги створимо об'єкт «КАРТКА РОЗРАХУНКІВ». Детальний опис атрибутів об'єкта наведено у таблиці 2.7.
Таблиця 2.6
Приклад опису складових елементів об'єкта «ПОКАЗНИК ЛІЧИЛЬНИКА»
|
Назва атрибута |
Формат |
Відсоток наявності |
Обмеження на право звертання до значень атрибута |
Частота використання |
Виводимість значень |
Дублювання значень |
Область допустимих значень |
Роль атрибутів та їхні характеристики |
|
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
|
|
Поточне_показання |
9(9) |
100% |
Мають право робітники бухгалтерського відділу |
-- |
-- |
Так |
-- |
Для зберігання значення поточного показання лічильника |
|
|
Дата |
9(2). 9(2). 9(4) |
100% |
-- |
-- |
Так |
-- |
Для зберігання дати внесення показань |
||
|
ID_лічильника |
9 (8) |
100% |
-- |
-- |
Так |
-- |
Для ідентифікації показання з лічильником по номеру лічильника |
||
|
ID_показання |
9(4) |
100% |
-- |
-- |
Ні |
-- |
Для ідентифікації лічильника користувача |
||
|
Попереднє_показання |
9(9) |
100% |
-- |
-- |
Так |
-- |
Для зберігання значення попереднього показання лічильника |
||
|
Розрахункове_значення_показань |
9(9) |
100% |
-- |
-- |
Так |
-- |
Для зберігання значення різниці між поточними та попередніми показаннями |
Таблиця 2.7
Приклад опису складових елементів об'єкта «КАРТКА РОЗРАХУНКІВ»
|
Назва атрибута |
Формат |
Відсоток наявності |
Обмеження на право звертання до значень атрибута |
Частота використання |
Виводимість значень |
Дублювання значень |
Область допустимих значень |
Роль атрибутів та їхні характеристики |
|
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
|
|
ID_розрахунку |
9(4) |
100% |
Мають право робітники бухгалтерського відділу |
-- |
-- |
Ні |
-- |
Для ідентифікації картки розрахунку |
|
|
Нарахування |
9(9) |
100% |
-- |
-- |
Так |
-- |
Для зберігання та виведення суми нарахування |
||
|
ID_показання |
9(9) |
100% |
-- |
-- |
Так |
-- |
Для ідентифікації розрахунку з показанням лічильника по номеру показання |
||
|
ID_картки_абонента |
9(4) |
100% |
-- |
-- |
Так |
-- |
Для ідентифікації розрахунку з користувачем по номеру картки |
Для видачі користувачу інформації про використані послуги та суми до сплати створимо об'єкт «КВИТАНЦІЯ». Детальний опис атрибутів об'єкта наведено у таблиці 2.8.
Таблиця 2.8
Приклад опису складових елементів об'єкта «КВИТАНЦІЯ»
|
Назва атрибута |
Формат |
Відсоток наявності |
Обмеження на право звертання до значень атрибута |
Частота використання |
Виводимість значень |
Дублювання значень |
Область допустимих значень |
Роль атрибутів та їхні характеристики |
|
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
|
|
ID_квитанції |
9(4) |
100% |
Мають право робітники бухгалтерського відділу |
-- |
-- |
Ні |
-- |
Для ідентифікації квитанції |
|
|
Сума_до_сплати |
9(4).9 (2) |
100% |
-- |
-- |
Так |
-- |
Для виведення суми до сплати користувачеві за використані послуги |
||
|
Сплачено |
9(4).9(2) |
100% |
-- |
-- |
Так |
-- |
Для виведення суми, яку сплатив користувач за використані послуги |
||
|
ID_картки_ абонента |
9(4) |
100% |
-- |
-- |
Так |
-- |
Для ідентифікації квитанції з користувачем по номеру картки |
||
|
ID_ розрахунку |
9(4) |
100% |
-- |
-- |
Так |
-- |
Для ідентифікації квитанції з розрахунком по номеру картки |
||
|
ID_послуги |
9(2) |
100% |
-- |
-- |
Так |
-- |
Для ідентифікації квитанції з послугою по номеру послуги |
Приклад опису об'єктів інфологічної моделі приведений в табл. 2.9.
Таблиця 2.9
Опис характеристик об'єктів
|
Найменування об'єкта |
Спосіб звертання до екземплярів |
Структурна активність |
Обмеження на право звертання |
Кількість екземплярів |
|
|
1 |
2 |
3 |
4 |
5 |
|
|
КАРТКА АБОНЕНТА |
К (ID_картки_абонента) |
-- |
-- |
20000 |
|
|
ТАРИФ |
К (ID_тарифу) |
-- |
-- |
1000 |
|
|
ПОСЛУГА |
К (ID_послуги) |
-- |
-- |
1000 |
|
|
ПІЛЬГА |
К (ID_пільги) |
-- |
-- |
1000 |
|
|
ЛІЧИЛЬНИК |
К (ID_лічильника) |
-- |
-- |
200000 |
|
|
ПОКАЗНИК ЛІЧИЛЬНИКА |
К (ID_показання) |
-- |
-- |
200000 |
|
|
КАРТКА РОЗРАХУНКІВ |
К (ID_розрахунку) |
-- |
-- |
20000 |
|
|
КВИТАНЦІЯ |
К (ID_квитанції) |
-- |
-- |
20000 |
2.2 Побудова та опис діаграми "Сутність-зв'язок"
Діаграми «сутність-зв'язок» призначені для розробки моделей даних і забезпечують стандартний спосіб визначення даних і відношень між ними. Фактично за допомогою цих діаграм здійснюється деталізація даних майбутньої системи, а також документуються сутності системи і способи їх взаємодії, включаючи ідентифікацію об'єктів, важливих для предметної області (сутностей), властивостей цих об'єктів (атрибутів) і їх відношень з іншими об'єктами (зв'язків).
Базовими компонентами для побудови такої моделі даних є сутність, атрибут і зв'язок. Отже визначимо для нашої предметної області базові компоненти.
Сутність -- це збірне поняття, деяка абстракція реально існуючого об'єкта, процесу, явища чи деякого уявлення про об'єкт. Проаналізувавши у попередніх розділах та підрозділах предметну область «підприємство» можна визначити наступні сутності: «Картка абонента», «Послуга», «Тариф», «Пільга», «Лічильник», «Показник лічильника», «Картка розрахунків», «Квитанція». Приклад вигляду сутності «Картка абонента» продемонстровано на рисунку «Рис. 2.1».
Рис. 2.1 Зображення сутності «Картка абонента»
Кожна сутність повинна мати один або декілька атрибутів, що або належать сутності, або успадковуються через зв'язок з іншою сутністю. Атрибут сутності являє собою одну з характеристик чи властивостей сутності.
Розглянемо окремо кожну сутність та визначимо її атрибути.
Сутність «Картка абонента» потрібна для запису персональних даних користувача водопостачальних послуг. Перерахуємо на рисунку «Рис. 2.2» атрибути даної сутності:
Рис. 2.2 Зображення сутності «Картка абонента» з визначенням атрибутів
Сутність «Тариф» потрібна для запису цін водопостачальних послуг для різних користувачів. Перерахуємо на рисунку «Рис. 2.3» атрибути даної сутності:
Рис. 2.3 Зображення сутності «Тариф» з визначенням атрибутів
Сутність «Послуга» потрібна для запису типів водопостачальних послуг, які може отримувати користувач. Перерахуємо на рисунку «Рис. 2.4» атрибути даної сутності:
Рис. 2.4 Зображення сутності «Послуга» з визначенням атрибутів
Сутність «Пільга» потрібна для запису видів та цін пільг, які може мати користувач водопостачальних послуг. Перерахуємо на рисунку «Рис. 2.5» атрибути даної сутності:
Рис. 2.5 Зображення сутності «Пільга» з визначенням атрибутів
Сутність «Лічильник» потрібна для запису інформації про лічильники кожного споживача водопостачальних послуг. Перерахуємо на рисунку «Рис. 2.6» атрибути даної сутності:
Рис. 2.6 Зображення сутності «Лічильник» з визначенням атрибутів
Сутність «Показник лічильника» потрібна для запису показань лічильників, знятих кожного місяця та для розрахунку значення показань для виведення нарахувань за використані послуги. Перерахуємо на рисунку «Рис. 2.7» атрибути даної сутності:
Рис. 2.7 Зображення сутності «Показник лічильника» з визначенням атрибутів
Сутність «Картка розрахунків» потрібна для запису розрахунків суми нарахувань за спожиті користувачем водопостачальні послуги. Перерахуємо на рисунку «Рис. 2.8» атрибути даної сутності:
Рис. 2.8 Зображення сутності «Картка розрахунків» з визначенням атрибутів
Сутність «Квитанція» потрібна для запису нарахувань та оплат користувача водопостачальних послуг. Перерахуємо на рисунку «Рис. 2.9» атрибути даної сутності:
Рис. 2.9 Зображення сутності «Квитанція» з визначенням атрибутів
Для можливості звернення однієї сутності до іншої або до багатьох інших потрібно встановити зв'язок між цими сутностями. Зв'язок -- це відношення однієї сутності до іншої або до самої себе. За допомогою зв'язку можливо по одній сутності знаходити інші, зв'язані з нею. Зв'язки між сутностями відповідають логічним відношенням між сутностями, які встановлюють суттєвий зв'язок у даній предметній області.
На рисунку 2.10 зображено зв'язки між усіма сутностями обраної предметної області.
Рис. 2.10 Зображення зв'язків між сутностями
Розглянемо кожен зв'язок окремо.
Зв'язок між сутностями «Картка абонента» та «Пільга»:
Рис. 2.11 Зображення зв'язку між сутностями «Картка абонента» та «Пільга»
Зі зв'язку на рисунку 2.11 визначаємо, що сутність «Пільга» є батьківською, а сутність «Картка абонента» дочірньою. Отже кожен користувач може мати певну пільгу, а кожна пільга може належати декільком користувачам.
Зв'язок між сутностями «Картка абонента» та «Лічильник»:
Рис. 2.12 Зображення зв'язку між сутностями «Картка абонента» та «Лічильник»
Зі зв'язку на рисунку 2.12 визначаємо, що сутність «Картка абонента» є батьківською, а сутність «Лічильник» дочірньою. Отже кожен користувач може мати декілька лічильників, а кожен лічильник може належати одному користувачу.
Зв'язок між сутностями «Картка абонента» та «Тариф»:
Рис. 2.13 Зображення зв'язку між сутностями «Картка абонента» та «Тариф»
Зі зв'язку на рисунку 2.13 визначаємо, що сутність «Тариф» є батьківською, а сутність «Картка абонента» дочірньою. Отже кожен тариф може визначати тарифікацію для декількох користувачів, а кожен користувач може обслуговуватися лише по одному тарифу.
Зв'язок між сутностями «Картка абонента» та «Квитанція»:
Рис. 2.14 Зображення зв'язку між сутностями «Картка абонента» та «Квитанція»
Зі зв'язку на рисунку 2.14 визначаємо, що сутність «Картка абонента» є батьківською, а сутність «Квитанція» дочірньою. Отже кожен користувач може мати декілька квитанцій, а кожен квитанція може належати лише по одному користувачу.
Зв'язок між сутностями «Картка абонента» та «Картка розрахунків»:
Рис. 2.15 Зображення зв'язку між сутностями «Картка абонента» та «Картка розрахунків»
Зі зв'язку на рисунку 2.15 визначаємо, що сутність «Картка абонента» є батьківською, а сутність «Картка розрахунків» дочірньою. Отже кожен користувач може надавати ID для декількох розрахунків, а кожна картка розрахунків може розраховувати лише для одного користувача.
Зв'язок між сутностями «Лічильник» та «Показник лічильника»:
Рис. 2.16 Зображення зв'язку між сутностями «Лічильник» та «Показник лічильника»
Зі зв'язку на рисунку 2.16 визначаємо, що сутність «Лічильник» є батьківською, а сутність «Показник лічильника» дочірньою. Отже лічильник може мати декілька показань, а кожен показник лічильника може належати лише одному лічильнику.
Зв'язок між сутностями «Показник лічильника» та «Картка розрахунків»:
Рис. 2.17 Зображення зв'язку між сутностями «Показник лічильника» та «Картка розрахунків»
Зі зв'язку на рисунку 2.17 визначаємо, що сутність «Показник лічильника» є батьківською, а сутність «Картка розрахунків» дочірньою. Отже кожен показник лічильника може надавати декілька значень показань для розрахунку, а кожна картка розрахунку може приймати лише одне значення показань для розрахунку.
Зв'язок між сутностями «Квитанція» та «Картка розрахунків»:
Рис. 2.18 Зображення зв'язку між сутностями «Квитанція» та «Картка розрахунків»
Зі зв'язку на рисунку 2.18 визначаємо, що сутність «Картка розрахунків» є батьківською, а сутність «Квитанція» дочірньою. Отже кожна картка розрахунку може розраховувати для декількох квитанцій, а кожна квитанція може приймати значення лише з одної картки розрахунків.
Зв'язок між сутностями «Послуга» та «Квитанція»:
Рис. 2.19 Зображення зв'язку між сутностями «Послуга» та «Квитанція»
Зі зв'язку на рисунку 2.19 визначаємо, що сутність «Послуга» є батьківською, а сутність «Квитанція» дочірньою. Отже кожна послуга може надавати своє ID для декількох квитанція, а кожна квитанція може приймати ID лише однієї послуги. Зв'язок між сутностями «Тариф» та «Послуга»:
Рис. 2.20 Зображення зв'язку між сутностями «Тариф» та «Послуга»
Зі зв'язку на рисунку 2.20 визначаємо, що сутність «Послуга» є батьківською, а сутність «Тариф» дочірньою. Отже кожна послуга може надавати своє ID для декількох тарифів, а кожен тариф може привласнювати ціну лише одній послузі.
Таким чином визначивши сутності, їх атрибути та зв'язки отримуємо логічну модель для нашої предметної області. Схема логічної моделі приведена у додатку А (Рис. А.1).
Логічна модель даних є універсальною і ніяк не пов'язана з конкретною реалізацією СУБД. Фізична модель даних, навпаки, залежить від конкретної СУБД. Тож для створення фізичної моделі оберемо три варіанти СУБД і представимо модель у кожній із них.
СУБД MS Access - це комплекс програм, який дозволяє не тільки зберігати великі масиви даних у певному форматі, а й обробляти їх, представляючи в зручному для користувачів вигляді. Схема фізичної моделі для СУБД MS Access приведена у додатку А (Рис. А.2).
СУБД MySQL - це система керування реляційними базами даних. Вона використовується, в першу чергу, для створення динамічних веб-сторінок, оскільки має чудову підтримку з боку різноманітних мов програмування. MySQL надає багатий набір функціональних можливостей, які підтримують безпечне середовище для зберігання, обслуговування і отримання даних. Схема фізичної моделі для СУБД MySQL приведена у додатку А (Рис. А.3).
СУБД Microsoft SQL Server - одна з найбільш потужних СУБД архітектури клієнт-сервер. Ця СУБД дозволяє задовольняти такі вимоги, що пред'являються до систем розподіленої обробки даних, як тиражування даних, паралельна обробка, підтримка великих баз даних на відносно недорогих апаратних платформах при збереженні простоти управління і використання. Схема фізичної моделі для СУБД MS SQL Server приведена у додатку А (Рис. А.4).
Виконавши усі необхідні пункти для створення проекту бази даних у підсумку згенеруємо стандартний звіт Table Reports-Table-Physical Properties з переліком таблиць моделі та їх стовпців за допомогою генератора звітів CASE-засобу CA ERwin Data Modeler. Звіт наведено у додатку Б (Таблиця Б.1).
РОЗДІЛ 3. РЕАЛІЗАЦІЯ ПРОЕКТУ БАЗИ ДАНИХ
3.1 Реалізація проекту бази даних у СУБД MS Access
Текст вихідного коду для створення бази даних у СУБД MS Access наведений у додатку Д (Лістинг Д.1).
Після створення схеми БД здійснімо перевірку складу таблиць реляційної бази даних, назви та основні властивості полів таблиць та міжтабличних зв'язків.
Склад таблиць та зв'язки між ними наведені схемі бази даних у додатку В (Рис. В.1).
Опис полів бази даних наведені у таблиці 3.1.
Таблиця 3.1
Опис властивостей стовпчиків таблиць реляційної бази даних
|
№ п/п |
Назва таблиці (стовпчика) |
Ім'я таблиці (стовпчика) |
Тип даних |
Властивості (первинний ключ, зовнішній ключ та інші обмеження) |
|
|
1 |
2 |
3 |
4 |
5 |
|
|
2 |
Картка_абонента |
ID_картки_абонента |
Long Integer |
Первинний ключ NOT NULL |
|
|
3 |
Картка_абонента |
ПІБ_власника |
Text(50) |
NULL |
|
|
4 |
Картка_абонента |
Вулиця |
Text(20) |
NULL |
|
|
5 |
Картка_абонента |
Дім |
Long Integer |
NULL |
|
|
6 |
Картка_абонента |
Квартира |
Long Integer |
NULL |
|
|
7 |
Картка_абонента |
ID_пільги |
Long Integer |
Зовнішній ключ NULL |
|
|
8 |
Картка_абонента |
ID_тарифа |
Long Integer |
Зовнішній ключ NULL |
|
|
9 |
Послуга |
ID_послуги |
Long Integer |
Первинний ключ NOT NULL |
|
|
10 |
Послуга |
Вид_послуги |
Text(50) |
NULL |
|
|
11 |
Тариф |
ID_тарифу |
Long Integer |
Первинний ключ NOT NULL |
|
|
12 |
Тариф |
Тип_тарифу |
Text(20) |
NULL |
|
|
13 |
Тариф |
ID_послуги |
Long Integer |
Зовнішній ключ NULL |
|
|
14 |
Тариф |
Ціна_тарифу |
Long Integer |
NULL |
|
|
15 |
Пільга |
ID_пільги |
Long Integer |
Первинний ключ NOT NULL |
|
|
16 |
Пільга |
Назва_пільги |
Text(20) |
NULL |
|
|
17 |
Пільга |
Ціна_пільги |
Long Integer |
NULL |
|
|
18 |
Квитанція |
ID_квитанції |
Long Integer |
Первинний ключ NOT NULL |
|
|
19 |
Квитанція |
Сума_до_сплати |
Long Integer |
NULL |
|
|
20 |
Квитанція |
Сплачено |
Long Integer |
NULL |
|
|
21 |
Квитанція |
ID_картки_абонента |
Long Integer |
Зовнішній ключ NULL |
|
|
22 |
Квитанція |
ID_розрахунку |
Long Integer |
Зовнішній ключ NULL |
|
|
23 |
Квитанція |
ID_послуги |
Long Integer |
Зовнішній ключ NULL |
|
|
24 |
Лічильник |
ID_лічильника |
Long Integer |
Первинний ключ NOT NULL |
|
|
25 |
Лічильник |
Місце_установки |
Text(20) |
NULL |
|
|
26 |
Лічильник |
Початкове_показання |
Long Integer |
NULL |
|
|
27 |
Лічильник |
ID_картки_абонента |
Long Integer |
Зовнішній ключ NULL |
|
|
28 |
Показник_лічильника |
Поточне_показання |
Long Integer |
Первинний ключ NOT NULL |
|
|
29 |
Показник_лічильника |
Дата |
Date\Time |
NULL |
|
|
30 |
Показник_лічильника |
ID_лічильника |
Long Integer |
Зовнішній ключ NULL |
|
|
31 |
Показник_лічильника |
ID_показання |
Long Integer |
Зовнішній ключ NULL |
|
|
32 |
Показник_лічильника |
Попереднє_показання |
Long Integer |
NULL |
|
|
33 |
Показник_лічильника |
Розрахункове_значення_показань |
Long Integer |
NULL |
|
|
34 |
Картка_розрахунків |
ID_розрахунку |
Long Integer |
Первинний ключ NOT NULL |
|
|
35 |
Картка_розрахунків |
Нарахування |
Long Integer |
NULL |
|
|
36 |
Картка_розрахунків |
ID_показання |
Long Integer |
Зовнішній ключ NULL |
3.2 Реалізація проекту бази даних у СУБД MySQL
Текст вихідного коду для створення бази даних у СУБД MySQL наведений у додатку Д (Лістинг Д.2). Після створення схеми БД здійснімо перевірку складу таблиць реляційної бази даних, назви та основні властивості полів таблиць та міжтабличних зв'язків. Склад таблиць та зв'язки між ними наведені схемі бази даних у додатку В (Рис. В.2). Опис полів бази даних наведені у таблиці 3.2.
Таблиця 3.2
Опис властивостей стовпчиків таблиць реляційної бази даних
|
№ п/п |
Назва таблиці (стовпчика) |
Ім'я таблиці (стовпчика) |
Тип даних |
Властивості (первинний ключ, зовнішній ключ та інші обмеження) |
|
|
1 |
2 |
3 |
4 |
5 |
|
|
2 |
Картка_абонента |
ID_картки_абонента |
INTEGER |
Первинний ключ NOT NULL |
|
|
3 |
Картка_абонента |
ПІБ_власника |
VARCHAR(50) |
NULL |
|
|
4 |
Картка_абонента |
Вулиця |
VARCHAR(20) |
NULL |
|
|
5 |
Картка_абонента |
Дім |
INTEGER |
NULL |
|
|
6 |
Картка_абонента |
Квартира |
INTEGER |
NULL |
|
|
7 |
Картка_абонента |
ID_пільги |
INTEGER |
Зовнішній ключ NULL |
|
|
8 |
Картка_абонента |
ID_тарифа |
INTEGER |
Зовнішній ключ NULL |
|
|
9 |
Послуга |
ID_послуги |
INTEGER |
Первинний ключ NOT NULL |
|
|
10 |
Послуга |
Вид_послуги |
VARCHAR(20) |
NULL |
|
|
11 |
Тариф |
ID_тарифу |
INTEGER |
Первинний ключ NOT NULL |
|
|
12 |
Тариф |
Тип_тарифу |
VARCHAR(20) |
NULL |
|
|
13 |
Тариф |
ID_послуги |
INTEGER |
Зовнішній ключ NULL |
|
|
14 |
Тариф |
Ціна_тарифу |
INTEGER |
NULL |
|
|
15 |
Пільга |
ID_пільги |
INTEGER |
Первинний ключ NOT NULL |
|
