Розробка бази даних для автоматизованого вирішення комплексу функціональних задач "Облік оплати водопостачальних послуг"
Проект бази даних для автоматизованого вирішення задач "Облік оплати водопостачальних послуг". Опис інфологічної моделі бази даних та її складових частин. Побудова діаграми "Сутність-зв'язок". Реалізація проекту СУБД 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 |
|
16 |
Пільга |
Назва_пільги |
VARCHAR(20) |
NULL |
|
17 |
Пільга |
Ціна_пільги |
INTEGER |
NULL |
|
18 |
Квитанція |
ID_квитанції |
INTEGER |
Первинний ключ NOT NULL |
|
19 |
Квитанція |
Сума_до_сплати |
INTEGER |
NULL |
|
20 |
Квитанція |
Сплачено |
INTEGER |
NULL |
|
21 |
Квитанція |
ID_картки_абонента |
INTEGER |
Зовнішній ключ NULL |
|
22 |
Квитанція |
ID_розрахунку |
INTEGER |
Зовнішній ключ NULL |
|
23 |
Квитанція |
ID_послуги |
INTEGER |
Зовнішній ключ NULL |
|
24 |
Лічильник |
ID_лічильника |
INTEGER |
Первинний ключ NOT NULL |
|
25 |
Лічильник |
Місце_установки |
VARCHAR(20) |
NULL |
|
26 |
Лічильник |
Початкове_показання |
INTEGER |
NULL |
|
27 |
Лічильник |
ID_картки_абонента |
INTEGER |
Зовнішній ключ NULL |
|
28 |
Показник_лічильника |
Поточне_показання |
INTEGER |
Первинний ключ NOT NULL |
|
29 |
Показник_лічильника |
Дата |
DATE |
NULL |
|
30 |
Показник_лічильника |
ID_лічильника |
INTEGER |
Зовнішній ключ NULL |
|
31 |
Показник_лічильника |
ID_показання |
INTEGER |
Зовнішній ключ NULL |
|
32 |
Показник_лічильника |
Попереднє_показання |
INTEGER |
NULL |
|
33 |
Показник_лічильника |
Розрахункове_значення_показань |
INTEGER |
NULL |
|
34 |
Картка_розрахунків |
ID_розрахунку |
INTEGER |
Первинний ключ NOT NULL |
|
35 |
Картка_розрахунків |
Нарахування |
INTEGER |
NULL |
|
36 |
Картка_розрахунків |
ID_показання |
INTEGER |
Зовнішній ключ NULL |
|
37 |
Картка_розрахунків |
ID_картки_абонента |
INTEGER |
Зовнішній ключ NULL |
3.3 Реалізація проекту бази даних у СУБД Microsoft SQL Server
Текст вихідного коду для створення бази даних у СУБД Microsoft SQL Server наведений у додатку Д (Лістинг Д.3.).
Після створення схеми БД здійснімо перевірку складу таблиць реляційної бази даних, назви та основні властивості полів таблиць та міжтабличних зв'язків.
Склад таблиць та зв'язки між ними наведені схемі бази даних у додатку В (Рис. В.3.).
Опис полів бази даних наведені у таблиці 3.3.
Таблиця 3.3
Опис властивостей стовпчиків таблиць реляційної бази даних
№ п/п |
Назва таблиці (стовпчика) |
Ім'я таблиці (стовпчика) |
Тип даних |
Властивості (первинний ключ, зовнішній ключ та інші обмеження) |
|
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 |
|
16 |
Пільга |
Назва_пільги |
varchar(20) |
NULL |
|
17 |
Пільга |
Ціна_пільги |
integer |
NULL |
|
18 |
Квитанція |
ID_квитанції |
integer |
Первинний ключ NOT NULL |
|
19 |
Квитанція |
Сума_до_сплати |
integer |
NULL |
|
20 |
Квитанція |
Сплачено |
integer |
NULL |
|
21 |
Квитанція |
ID_картки_абонента |
integer |
Зовнішній ключ NULL |
|
22 |
Квитанція |
ID_розрахунку |
integer |
Зовнішній ключ NULL |
|
23 |
Квитанція |
ID_послуги |
integer |
Зовнішній ключ NULL |
|
24 |
Лічильник |
ID_лічильника |
integer |
Первинний ключ NOT NULL |
|
25 |
Лічильник |
Місце_установки |
varchar(20) |
NULL |
|
26 |
Лічильник |
Початкове_показання |
integer |
NULL |
|
27 |
Лічильник |
ID_картки_абонента |
integer |
Зовнішній ключ NULL |
|
28 |
Показник_лічильника |
Поточне_показання |
integer |
Первинний ключ NOT NULL |
|
29 |
Показник_лічильника |
Дата |
integer |
NULL |
|
30 |
Показник_лічильника |
ID_лічильника |
datetime |
Зовнішній ключ NULL |
|
31 |
Показник_лічильника |
ID_показання |
integer |
Зовнішній ключ NULL |
|
32 |
Показник_лічильника |
Попереднє_показання |
integer |
NULL |
|
33 |
Показник_лічильника |
Розрахункове_значення_показань |
integer |
NULL |
|
34 |
Картка_розрахунків |
ID_розрахунку |
integer |
Первинний ключ NOT NULL |
|
35 |
Картка_розрахунків |
Нарахування |
integer |
NULL |
|
36 |
Картка_розрахунків |
ID_показання |
integer |
Зовнішній ключ NULL |
|
37 |
Картка_розрахунків |
ID_картки_абонента |
integer |
Зовнішній ключ NULL |
інфологічний база даний облік водопостачальний
ВИСНОВКИ
Виконавши всі вимоги поставленої у курсовій роботі задачі ми отримали цілком працездатну, базу даних з обліку оплати водопостачальних послуг, яка відповідає усім вимогам. Кожен з трьох етапів розробки вирізнявся специфічністю виконання, тож варто приділити увагу у підсумку виконаної роботи кожному з них.
Етап дослідження предметної області можна назвати фундаментом курсової роботи, адже на цьому етапі ми визначаємо основні функціональні одиниці майбутнього проекту. Потрібно бути уважним до деталей, адже від чіткого аналізу залежить правильність подальшого виконання роботи.
На другому етапі виконання курсової роботи ми провели опис інфологічної моделі бази даних, виділили її основні складові частини та описали ці частили у вигляді таблиць. Також було створено ER-діаграми логічної та фізичної моделі, які значно полегшують проектування бази даних.
На останньому третьому етапі було реалізовано розроблений проект бази даних у наступних СУБД: MS Access, MySQL та MS SQL Server.
У майбутньому, покращивши знання з дисципліни бази даних можна вдосконалювати отриманий проект, або ж створювати нові використовуючи навички, здобуті при виконанні даної курсової роботи.
СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ
Методичні вказівки до самостійного вивчення системи управління базами даних MySQL. Частина 1. Уведення до MySQL. - Кривий Ріг: КЕІ ДВНЗ «КНЕУ ім. В.Гетьмана», 2008.
Методичні вказівки до самостійного вивчення системи управління базами даних MySQL. Частина 2. Команди модифікації та доступу до даних мови СУБД MySQL. - Кривий Ріг: КЕІ ДВНЗ «КНЕУ ім. В.Гетьмана», 2008.
Алан Бьюли "Изучаем SQL" Символ-Плюс, 2007 год.
Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management. -- 3-е изд. -- М.: Вильямс, 2003.
Peter Pin-Shan Chen «The Entity-Relationship Model -- Toward a Unified View of Data» (англ.) // ACM Transactions on Database Systems (TODS) : Сб. -- Нью-Йорк: ACM, 1976.
ГОСТ Р 51929-2002: Услуги жилищно-коммунальные. Термины и определения.
Карпов Александр Евгеньевич. Постановка и автоматизация управленческого учета. -- М.: Результат и Качество, 2008. -- С. 504
Когаловский М.Р. Энциклопедия технологий баз данных. -- М.: Финансы и статистика, 2002. -- 800 с.
ДОДАТОК A
Зображення моделей «сутність-зв'язок»
Рис. А.1 Зображення логічної моделі
Рис. А.2 Зображення фізичної моделі для СУБД MS Access
Рис. А.3 Зображення фізичної моделі для СУБД MySQL
Додаток Б
Звіт Table Reports-Table-Physical Properties
Таблиця Б.1
Table Reports-Table-Physical Properties
Column Table Name |
Column Name |
Column Datatype |
Column Null Option |
Column Is PK |
Column Is FK |
|
1 |
2 |
3 |
4 |
5 |
6 |
|
Послугa |
ID_послуги |
integer |
NOT NULL |
Yes |
No |
|
Вид_послуги |
varchar(20) |
NULL |
No |
No |
||
Картка_ абонента |
ID_картки_абонента |
integer |
NOT NULL |
Yes |
No |
|
ПІБ_власника |
varchar(50) |
NULL |
No |
No |
||
Вулиця |
varchar(20) |
NULL |
No |
No |
||
Дім |
int |
NULL |
No |
No |
||
Квартира |
int |
NULL |
No |
No |
||
ID_тарифа |
integer |
NULL |
No |
Yes |
||
ID_пільги |
integer |
NULL |
No |
Yes |
||
Тариф |
ID_тарифа |
integer |
NOT NULL |
Yes |
No |
|
Тип_тарифу |
varchar(20) |
NULL |
No |
No |
||
Ціна_тарифу |
integer |
NULL |
No |
No |
||
ID_послуги |
integer |
NULL |
No |
Yes |
||
Пільгa |
ID_пільги |
integer |
NOT NULL |
Yes |
No |
|
Назва_пільги |
varchar(20) |
NULL |
No |
No |
||
Ціна_пільги |
integer |
NULL |
No |
No |
||
Квитанція |
ID_квитанції |
integer |
NOT NULL |
Yes |
No |
|
Сума_до_сплати |
integer |
NULL |
No |
No |
||
Сплачено |
integer |
NULL |
No |
No |
||
ID_картки_абонента |
integer |
NULL |
No |
Yes |
||
ID_послуги |
integer |
NULL |
No |
Yes |
||
ID_розрахунку |
integer |
NULL |
No |
Yes |
||
Лічильник |
ID_лічильника |
integer |
NOT NULL |
Yes |
No |
|
Місце_установки |
varchar(20) |
NULL |
No |
No |
||
Початкове_показання |
integer |
NULL |
No |
No |
||
ID_картки_абонента |
integer |
NULL |
No |
Yes |
||
Показник_ лічильникa |
Поточне_показання |
integer |
NULL |
No |
No |
|
Дата |
datetime |
NULL |
No |
No |
||
ID_показання |
integer |
NOT NULL |
Yes |
No |
||
Попереднє_показання |
integer |
NULL |
No |
No |
||
Розрахункове_значення_показань |
integer |
NULL |
No |
No |
||
ID_лічильника |
integer |
NULL |
No |
Yes |
||
Картка_ розрахунків |
ID_розрахунку |
integer |
NOT NULL |
Yes |
No |
|
Нарахування |
integer |
NULL |
No |
No |
||
ID_показання |
integer |
NULL |
No |
Yes |
||
ID_картки_абонента |
integer |
NULL |
No |
Yes |
ДОДАТОК В
Схеми даних у СУБД
Рис. В.1 Схема даних у СУБД MS Access
Рис. В.2 Схема даних у СУБД MySQL
Рис. В.3 Схема даних у СУБД MS SQL
ДОДАТОК Д
Лістинги команд створення таблиць бази даних
Лістинг Д.1. Лістинг вихідного коду на мові VBA для створення схеми бази даних у середовищі СУБД MS Access:
Dim ERwinWorkspace As Workspace
Dim ERwinDatabase As Database
Dim ERwinTableDef As TableDef
Dim ERwinQueryDef As QueryDef
Dim ERwinIndex As Index
Dim ERwinField As Field
Dim ERwinRelation As Relation
Set ERwinWorkspace = DBEngine.WorkSpaces(0)
Set ERwinDatabase =
ERwinWorkspace.OpenDatabase("D:\учеба\универ\3 курс\Базы
данных (курсовая)\курсовая\kyrsDB.mdb")
CREATE TABLE Картка абонента
Set ERwinTableDef = ERwinDatabase.CreateTableDef("Картка
абонента")
Set ERwinField = ERwinTableDef.CreateField("ID_картки абонента",
DB_LONG)
ERwinField.Required = True
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("ПІБ власника",
DB_TEXT, 50)
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("Вулиця", DB_TEXT, 20)
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("Дім", DB_LONG)
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("Квартира", DB_LONG)
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("ID_пільги", DB_LONG)
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("ID_тарифа", DB_LONG)
ERwinTableDef.Fields.Append ERwinField
ERwinDatabase.TableDefs.Append ERwinTableDef
Set ERwinField = ERwinTableDef.Fields("ID_картки абонента")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "ID_картки
абонента:")
Set ERwinField = ERwinTableDef.Fields("ПІБ власника")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "ПІБ власника:")
Set ERwinField = ERwinTableDef.Fields("Вулиця")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "Вулиця:")
Set ERwinField = ERwinTableDef.Fields("Дім")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "Дім:")
Set ERwinField = ERwinTableDef.Fields("Квартира")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "Квартира:")
Set ERwinField = ERwinTableDef.Fields("ID_пільги")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "ID_пільги:")
Set ERwinField = ERwinTableDef.Fields("ID_тарифа")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "ID_тарифа:")
' CREATE INDEX XPKКартка абонента
Set ERwinTableDef = ERwinDatabase.TableDefs("Картка абонента")
Set ERwinIndex = ERwinTableDef.CreateIndex("XPKКартка абонента")
Set ERwinField = ERwinIndex.CreateField("ID_картки абонента")
ERwinIndex.Fields.Append ERwinField
ERwinIndex.Primary = True
ERwinTableDef.Indexes.Append ERwinIndex
' CREATE TABLE Картка розрахунків
Set ERwinTableDef = ERwinDatabase.CreateTableDef("Картка
розрахунків")
Set ERwinField = ERwinTableDef.CreateField("ID_розрахунку",
DB_LONG)
ERwinField.Required = True
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("Нарахування",
DB_LONG)
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("ID_показання",
DB_LONG)
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("ID_картки абонента",
DB_LONG)
ERwinTableDef.Fields.Append ERwinField
ERwinDatabase.TableDefs.Append ERwinTableDef
Set ERwinField = ERwinTableDef.Fields("ID_розрахунку")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "ID_розрахунку:")
Set ERwinField = ERwinTableDef.Fields("Нарахування")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "Нарахування:")
Set ERwinField = ERwinTableDef.Fields("ID_показання")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "ID_показання:")
Set ERwinField = ERwinTableDef.Fields("ID_картки абонента")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "ID_картки
абонента:")
' CREATE INDEX XPKКартка розрахунків
Set ERwinTableDef = ERwinDatabase.TableDefs("Картка розрахунків")
Set ERwinIndex = ERwinTableDef.CreateIndex("XPKКартка
розрахунків")
Set ERwinField = ERwinIndex.CreateField("ID_розрахунку")
ERwinIndex.Fields.Append ERwinField
ERwinIndex.Primary = True
ERwinTableDef.Indexes.Append ERwinIndex
' CREATE TABLE Квитанція
Set ERwinTableDef = ERwinDatabase.CreateTableDef("Квитанція")
Set ERwinField = ERwinTableDef.CreateField("ID_квитанції",
DB_LONG)
ERwinField.Required = True
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("Сума до сплати",
DB_LONG)
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("Сплачено", DB_LONG)
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("ID_картки абонента",
DB_LONG)
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("ID_розрахунку",
DB_LONG)
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("ID_послуги", DB_LONG)
ERwinTableDef.Fields.Append ERwinField
ERwinDatabase.TableDefs.Append ERwinTableDef
Set ERwinField = ERwinTableDef.Fields("ID_квитанції")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "ID_квитанції:")
Set ERwinField = ERwinTableDef.Fields("Сума до сплати")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "Сума до сплати:")
Set ERwinField = ERwinTableDef.Fields("Сплачено")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "Сплачено:")
Set ERwinField = ERwinTableDef.Fields("ID_картки абонента")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "ID_картки
абонента:")
Set ERwinField = ERwinTableDef.Fields("ID_розрахунку")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "ID_розрахунку:")
Set ERwinField = ERwinTableDef.Fields("ID_послуги")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "ID_послуги:")
' CREATE INDEX XPKКвитанція
Set ERwinTableDef = ERwinDatabase.TableDefs("Квитанція")
Set ERwinIndex = ERwinTableDef.CreateIndex("XPKКвитанція")
Set ERwinField = ERwinIndex.CreateField("ID_квитанції")
ERwinIndex.Fields.Append ERwinField
ERwinIndex.Primary = True
ERwinTableDef.Indexes.Append ERwinIndex
' CREATE TABLE Лічильники
Set ERwinTableDef = ERwinDatabase.CreateTableDef("Лічильники")
Set ERwinField = ERwinTableDef.CreateField("ID_лічильника",
DB_LONG)
ERwinField.Required = True
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("Місце установки",
DB_TEXT, 20)
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("ID_картки абонента",
DB_LONG)
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("Початкове показання",
DB_LONG)
ERwinTableDef.Fields.Append ERwinField
ERwinDatabase.TableDefs.Append ERwinTableDef
Set ERwinField = ERwinTableDef.Fields("ID_лічильника")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "ID_лічильника:")
Set ERwinField = ERwinTableDef.Fields("Місце установки")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "Місце
установки:")
Set ERwinField = ERwinTableDef.Fields("ID_картки абонента")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "ID_картки
абонента:")
Set ERwinField = ERwinTableDef.Fields("Початкове показання")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "Початкове
показання:")
' CREATE INDEX XPKЛічильники
Set ERwinTableDef = ERwinDatabase.TableDefs("Лічильники")
Set ERwinIndex = ERwinTableDef.CreateIndex("XPKЛічильники")
Set ERwinField = ERwinIndex.CreateField("ID_лічильника")
ERwinIndex.Fields.Append ERwinField
ERwinIndex.Primary = True
ERwinTableDef.Indexes.Append ERwinIndex
' CREATE TABLE Пільги
Set ERwinTableDef = ERwinDatabase.CreateTableDef("Пільги")
Set ERwinField = ERwinTableDef.CreateField("ID_пільги", DB_LONG)
ERwinField.Required = True
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("Назва пільги", DB_TEXT,
20)
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("Ціна пільги", DB_LONG)
ERwinTableDef.Fields.Append ERwinField
ERwinDatabase.TableDefs.Append ERwinTableDef
Set ERwinField = ERwinTableDef.Fields("ID_пільги")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "ID_пільги:")
Set ERwinField = ERwinTableDef.Fields("Назва пільги")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "Назва пільги:")
Set ERwinField = ERwinTableDef.Fields("Ціна пільги")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "Ціна пільги:")
' CREATE INDEX XPKПільги
Set ERwinTableDef = ERwinDatabase.TableDefs("Пільги")
Set ERwinIndex = ERwinTableDef.CreateIndex("XPKПільги")
Set ERwinField = ERwinIndex.CreateField("ID_пільги")
ERwinIndex.Fields.Append ERwinField
ERwinIndex.Primary = True
ERwinTableDef.Indexes.Append ERwinIndex
' CREATE TABLE Показники лічильників
Set ERwinTableDef = ERwinDatabase.CreateTableDef("Показники
лічильників")
Set ERwinField = ERwinTableDef.CreateField("Поточне показання",
DB_LONG)
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("Дата", DB_DATETIME)
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("ID_лічильника",
DB_LONG)
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("ID_показання",
DB_LONG)
ERwinField.Required = True
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("Попереднє показання",
DB_LONG)
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("Розрахункове значення
показань",
DB_LONG)
ERwinTableDef.Fields.Append ERwinField
ERwinDatabase.TableDefs.Append ERwinTableDef
Set ERwinField = ERwinTableDef.Fields("Поточне показання")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "Поточне
показання:")
Set ERwinField = ERwinTableDef.Fields("Дата")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "Дата:")
Set ERwinField = ERwinTableDef.Fields("ID_лічильника")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "ID_лічильника:")
Set ERwinField = ERwinTableDef.Fields("ID_показання")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "ID_показання:")
Set ERwinField = ERwinTableDef.Fields("Попереднє показання")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "Попереднє
показання:")
Set ERwinField = ERwinTableDef.Fields("Розрахункове значення
показань")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "Розрахункове
значення
показань:")
' CREATE INDEX XPKПоказники лічильників
Set ERwinTableDef = ERwinDatabase.TableDefs("Показники
лічильників")
Set ERwinIndex = ERwinTableDef.CreateIndex("XPKПоказники
лічильників")
Set ERwinField = ERwinIndex.CreateField("ID_показання")
ERwinIndex.Fields.Append ERwinField
ERwinIndex.Primary = True
ERwinTableDef.Indexes.Append ERwinIndex
' CREATE TABLE Послуги
Set ERwinTableDef = ERwinDatabase.CreateTableDef("Послуги")
Set ERwinField = ERwinTableDef.CreateField("ID_послуги", DB_LONG)
ERwinField.Required = True
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("Вид послуги", DB_TEXT,
20)
ERwinTableDef.Fields.Append ERwinField
ERwinDatabase.TableDefs.Append ERwinTableDef
Set ERwinField = ERwinTableDef.Fields("ID_послуги")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "ID_послуги:")
Set ERwinField = ERwinTableDef.Fields("Вид послуги")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "Вид послуги:")
' CREATE INDEX XPKПослуги
Set ERwinTableDef = ERwinDatabase.TableDefs("Послуги")
Set ERwinIndex = ERwinTableDef.CreateIndex("XPKПослуги")
Set ERwinField = ERwinIndex.CreateField("ID_послуги")
ERwinIndex.Fields.Append ERwinField
ERwinIndex.Primary = True
ERwinTableDef.Indexes.Append ERwinIndex
' CREATE TABLE Тарифи
Set ERwinTableDef = ERwinDatabase.CreateTableDef("Тарифи")
Set ERwinField = ERwinTableDef.CreateField("ID_тарифа", DB_LONG)
ERwinField.Required = True
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("Тип тарифу", DB_TEXT,
20)
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("ID_послуги", DB_LONG)
ERwinTableDef.Fields.Append ERwinField
Set ERwinField = ERwinTableDef.CreateField("Ціна тарифу", DB_LONG)
ERwinTableDef.Fields.Append ERwinField
ERwinDatabase.TableDefs.Append ERwinTableDef
Set ERwinField = ERwinTableDef.Fields("ID_тарифа")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "ID_тарифа:")
Set ERwinField = ERwinTableDef.Fields("Тип тарифу")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "Тип тарифу:")
Set ERwinField = ERwinTableDef.Fields("ID_послуги")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "ID_послуги:")
Set ERwinField = ERwinTableDef.Fields("Ціна тарифу")
Call SetFieldProp(ERwinField, "Caption", DB_TEXT , "Ціна тарифу:")
' CREATE INDEX XPKТарифи
Set ERwinTableDef = ERwinDatabase.TableDefs("Тарифи")
Set ERwinIndex = ERwinTableDef.CreateIndex("XPKТарифи")
Set ERwinField = ERwinIndex.CreateField("ID_тарифа")
ERwinIndex.Fields.Append ERwinField
ERwinIndex.Primary = True
ERwinTableDef.Indexes.Append ERwinIndex
' CREATE RELATIONSHIP R/16
Set ERwinRelation = ERwinDatabase.CreateRelation("R/16", "Пільги",
"Карткаабонента")
Set ERwinField = ERwinRelation.CreateField( "ID_пільги" )
ERwinField.ForeignName = ID_пільги
ERwinRelation.Fields.Append ERwinField
ERwinDatabase.Relations.Append ERwinRelation
' CREATE RELATIONSHIP R/17
Set ERwinRelation = ERwinDatabase.CreateRelation("R/17", "Тарифи",
"Карткаабонента")
Set ERwinField = ERwinRelation.CreateField( "ID_тарифа" )
ERwinField.ForeignName = ID_тарифа
ERwinRelation.Fields.Append ERwinField
ERwinDatabase.Relations.Append ERwinRelation
' CREATE RELATIONSHIP R/15
Set ERwinRelation = ERwinDatabase.CreateRelation("R/15", "Показники
лічильників", "Картка розрахунків")
Set ERwinField = ERwinRelation.CreateField( "ID_показання" )
ERwinField.ForeignName = ID_показання
ERwinRelation.Fields.Append ERwinField
ERwinDatabase.Relations.Append ERwinRelation
' CREATE RELATIONSHIP R/21
Set ERwinRelation = ERwinDatabase.CreateRelation("R/21", "Картка
абонента",
"Картка розрахунків")
Set ERwinField = ERwinRelation.CreateField( "ID_картки абонента" )
ERwinField.ForeignName = ID_картки абонента
ERwinRelation.Fields.Append ERwinField
ERwinDatabase.Relations.Append ERwinRelation
' CREATE RELATIONSHIP R/13
Set ERwinRelation = ERwinDatabase.CreateRelation("R/13", "Картка
абонента",
"Квитанція")
Set ERwinField = ERwinRelation.CreateField( "ID_картки абонента" )
ERwinField.ForeignName = ID_картки абонента
ERwinRelation.Fields.Append ERwinField
ERwinDatabase.Relations.Append ERwinRelation
' CREATE RELATIONSHIP R/14
Set ERwinRelation = ERwinDatabase.CreateRelation("R/14", "Картка
розрахунків",
"Квитанція")
Set ERwinField = ERwinRelation.CreateField( "ID_розрахунку" )
ERwinField.ForeignName = ID_розрахунку
ERwinRelation.Fields.Append ERwinField
ERwinDatabase.Relations.Append ERwinRelation
' CREATE RELATIONSHIP R/20
Set ERwinRelation = ERwinDatabase.CreateRelation("R/20", "Послуги",
"Квитанція")
Set ERwinField = ERwinRelation.CreateField( "ID_послуги" )
ERwinField.ForeignName = ID_послуги
ERwinRelation.Fields.Append ERwinField
ERwinDatabase.Relations.Append ERwinRelation
' CREATE RELATIONSHIP R/7
Set ERwinRelation = ERwinDatabase.CreateRelation("R/7", "Картка
абонента",
"Лічильники")
Set ERwinField = ERwinRelation.CreateField( "ID_картки абонента" )
ERwinField.ForeignName = ID_картки абонента
ERwinRelation.Fields.Append ERwinField
ERwinDatabase.Relations.Append ERwinRelation
' CREATE RELATIONSHIP R/19
Set ERwinRelation = ERwinDatabase.CreateRelation("R/19",
"Лічильники",
"Показники лічильників")
Set ERwinField = ERwinRelation.CreateField( "ID_лічильника" )
ERwinField.ForeignName = ID_лічильника
ERwinRelation.Fields.Append ERwinField
ERwinDatabase.Relations.Append ERwinRelation
' CREATE RELATIONSHIP R/18
Set ERwinRelation = ERwinDatabase.CreateRelation("R/18", "Послуги",
"Тарифи")
Set ERwinField = ERwinRelation.CreateField( "ID_послуги" )
ERwinField.ForeignName = ID_послуги
ERwinRelation.Fields.Append ERwinField
ERwinDatabase.Relations.Append ERwinRelation
ERwinDatabase.Close
ERwinWorkspace.Close
' Terminating Access Basic DAO Session...
Лістинг Д.2 Лістинг вихідного коду на мові SQL для створення схеми бази даних у середовищі СУБД MySQL
CREATE TABLE Kartka_abonenta
(
ID_kartky_abonenta INTEGER NOT NULL,
PIB_vlasnyka VARCHAR(50) NULL,
Vylytsya VARCHAR(20) NULL,
Dim integer NULL,
Kvartyra integer NULL,
ID_pilgi INTEGER NULL,
ID_taryfa INTEGER NULL
);
ALTER TABLE Kartka_abonenta
ADD PRIMARY KEY (ID_kartky_abonenta);
CREATE TABLE Kartka_rozrahynkiv
(
ID_rozrahynky INTEGER NOT NULL,
Narahyvannya INTEGER NULL,
ID_pokazannya INTEGER NULL,
ID_kartky_abonenta INTEGER NULL
);
ALTER TABLE Kartka_rozrahynkiv
ADD PRIMARY KEY (ID_rozrahynky);
CREATE TABLE Kvytancii
(
ID_kvytancii INTEGER NOT NULL,
Syma_do_splaty INTEGER NULL,
Splacheno INTEGER NULL,
ID_kartky_abonenta INTEGER NULL,
ID_rozrahynky INTEGER NULL,
ID_poslygu INTEGER NULL
);
ALTER TABLE Kvytancii
ADD PRIMARY KEY (ID_kvytancii);
CREATE TABLE Lichilnyku
(
ID_lichilnyka INTEGER NOT NULL,
Misce_ystanivky VARCHAR(20) NULL,
ID_kartky_abonenta INTEGER NULL,
Pochatkove_pokazannya INTEGER NULL
Подобные документы
Форми вихідних документів. Перелік запитів до бази даних. Побудова інфологічної моделі, її структурні компоненти: сутності, зв’язки та відносини. Перелік таблиць, опис запитів. Загальна характеристика та головний зміст форм розроблюваної бази даних.
курсовая работа [414,5 K], добавлен 31.01.2014Теоретичні відомості про пакет ІЗВП Borland Delphi та СУБД MS Access, оцінка їх функціональних особливостей. Опис структури бази даних. Проектування інтерфейсу програми, опис її логічної структури та функцій. Контроль коректності вхідних, вихідних даних.
курсовая работа [4,5 M], добавлен 03.01.2014Розробка бази даних в середовищі Microsoft SQL Server 2008 для обліку послуг фітнес-клубу. Таблиці для баз даних, їх властивості. Аналіз сукупності вхідних і вихідних параметрів, опис інформаційної бази, розробка логічної і фізичної моделі даних в ІС.
курсовая работа [449,9 K], добавлен 09.05.2016Властивості та функції бази даних. Вибір та обгрутування програмного забезпечення Microsoft Access. Розробка бази даних за методом сутність-зв’язок. Етапи розробки бази даних "Відділ комп’ютерних комплектуючих" за допомогою СУБД Microsoft Office Access.
курсовая работа [7,4 M], добавлен 12.06.2019Розробка бази даних для обробки інформації про діяльність туристичного агентства. Визначення предметної області, вхідних та вихідних даних, їх організації. Генерація схеми бази даних. Реалізація функціональних вимог. Інструкція з експлуатації системи.
курсовая работа [5,3 M], добавлен 12.05.2015Аналіз та проектування бази даних по організації обліку та руху товарів на складах, обґрунтування вибору інструментального засобу. Застосування СУБД Microsoft Access, розробка таблиць бази даних. запитів, форм, конструювання звітів і організація захисту.
курсовая работа [463,3 K], добавлен 07.06.2010Проектування і реалізація реляційної бази даних для централізованого зберігання інформації з метою полегшення і систематизації даних замовлень клієнтів готельного комплексу. Розробка сценаріїв для створення бази даних і базових таблиць проекту.
курсовая работа [147,2 K], добавлен 02.06.2019Аналіз предметної галузі, постановка задачі, проектування бази даних. UML-моделювання, побудова ER-діаграми, схеми реляційної бази даних у третій нормальній формі. Призначення і логічна структура. Опис фізичної моделі бази даних, програмної реалізації.
курсовая работа [3,5 M], добавлен 28.11.2011Опис вхідних та вихідних повідомлень, процедури перетворення даних. Розробка інфологічної моделі, інформаційні об’єкти та їх характеристика. Автоматизація даталогічного проектування. Опис структур таблиць бази даних на фізичному рівні, реалізація запитів.
курсовая работа [2,5 M], добавлен 02.01.2014Система управління базами даних (СУБД) як сукупність програм загального користування. Створення СУБД у середовищі MS Access для підприємства послуг зв’язку "NewTone". Основні споживачі послуг підприємства. Ієрархічна структура елементів бази даних.
курсовая работа [5,0 M], добавлен 24.02.2011