Проектування бази даних на ЕОМ

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

ЗМІСТ

Вступ

1 Дослідження предметної області «Розрахунок прибутку від продажу комп'ютерних комплектуючих»

1.1 Організаційно-економічна сутність предметної області

1.2 Опис системи вхідної, довідкової та вихідної інформації

2 Створення проекту бази даних «Розрахунок прибутку від продажу комп'ютерних комплектуючих»

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

2.2 Побудова та опис діаграми «Суттєвість-зв'язок»

3 Реалізація проекту бази даних «Розрахунок прибутку від продажу комп'ютерних комплектуючих»

3.1 Розробка структури бази даних на ЕОМ

3.2 Створення таблиць та запитів на мові MySQL

3.3 Підготовка даних контрольного прикладу та його виконання

Висновки

Список використаної літератури

ВСТУП

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

Останні декілька десятиліть реляційні бази даних розвивалися, удосконалювалися і, через властивих їм потужності і гнучкості займали домінуюче положення на ринку. Всі найбільш відомі СУБД (dBase, FoxPro, Microsoft Access, InterBase, Sybase, Oracle, MS SQL Server DB2 та інші) оперують саме з реляційними базами даних. Хоча, слід відмітити, що останнім часом (очевидно, у зв'язку з розвитком Internet) дещо активізувався інтерес до нереляційних баз даних. Не так давно фірмою Microsoft була розроблена нова модель доступу до даних, звана ActiveX Data Objects (ADO). Модель ADO, що використовує нову технологію OLE DB, дозволяє дістати доступ і до нереляційних баз даних. Проте, не дивлячись на це зауваження, реляційні бази даних є основним засобом зберігання і обробки інформації.

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

Основними завданнями даної курсової роботи є:

- поглиблення отриманих теоретичних знань стосовно проектування баз і сховищ даних;

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

- практика створення бази даних з використанням інструментальних засобів однієї з сучасних реляційних СУБД.

1 ДОСЛІДЖЕННЯ ПРЕДМЕТНОЇ ОБЛАСТІ «РОЗРАХУНОК ПРИБУТКУ ВІД ПРОДАЖУ КОМП'ЮТЕРНИХ КОМПЛЕКТУЮЧИХ»

1.1 Організаційно-економічна сутність предметної області

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

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

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

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

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

Досліджувана в роботі автоматизована система обробки економічної інформації з розрахунку прибутку від продажу передбачає виконання наступних задач:

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

2) облік товарів на складі. Вирішення задачі обліку товарі в зі складу, передбачає отримання такої інформації:

- фірма, яка виготовила товар;

- найменування;

- кількість товару на складі.

- номер складу

3) облік продажу товару. Вирішення задачі обліку продажу товару дозволяє отримувати наступні дані:

- кількість;

- ціна продажу;

- найменування;

4) облік надходження товару до магазину.

Вирішення задачі обліку надходження картин до галереї забезпечує отримання таких даних:

- кількість;

- ціна закупки;

- назва;

Задачі, на вирішення яких спрямоване проектування бази даних «Розрахунок прибутку від продажу комп'ютерних комплектуючих» представлено у вигляді таблиці:

Таблица

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

1.2 Опис системи вхідної, довідкової та вихідної інформації

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

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

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

- облік на складі;

- облік продажу товару;

- облік надходження товару до магазину.

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

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



база данні прибуток

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

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

2 СТВОРЕННЯ ПРОЕКТУ БАЗИ ДАНИХ «РОЗРАХУНОК ПРИБУТКУ ВІД ПРОДАЖУ КОМП'ЮТЕРНИХ КОМПЛЕКТУЮЧИХ»

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

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

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

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

Інформаційний об'єкт - це деяка сутність предметної області, яку потрібно відобразити в базі даних з точки зору програми або користувача бази даних. Сутність - будь який відмінний об'єкт (об'єкт, який ми можемо відрізнити від іншого), інформацію про який необхідно зберігати у базі даних. Сутностями можуть бути люди, міста, літаки, смак, колір та інше. Необхідно розрізняти такі поняття, як тип сутності та екземпляр сутності. Поняття тип сутності відноситься до однорідних предметів, випадків або ідей, що виступають як одне ціле. На відміну від типу, екземпляр сутності відноситься до конкретного об'єкту в цьому наборі однорідності. Наприклад, типом сутності може бути «назва художнього твору», а екземпляром - «Drained».

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

Ключ суті - група атрибутів, така, що відображення набору суті у відповідну групу наборів значень є взаємооднозначним відображенням. Іншими словами: ключ суті - це один або більш атрибутів тих, що унікально визначають дану суть. У випадку даної теми роботи для сутності «Номер квартири» ключем є атрибут «Номер квартири», сутності «Комунальні платежі» ключем є атрибут «Дата», сутності «Мешканці» ключем є атрибут «Код», сутності «Платежі» ключем є атрибут «Номер квартири», сутності «Показники лічильника» ключем є комбінація атрибутів «Дата» та «Номер квартири»

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

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

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

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

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

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

- прізвище, ім'я та по-батькові, дата народження, код мешканців;

- номер, площа, код власника квартири;

- показники лічильника

- показники тарифів

- розмір сплачених платежів

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

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

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

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

- кожен стовпчик повинен мати унікальне ім'я, проте порядок стовпців у таблиці несуттєвий;

- таблиця не може містити двох однакових рядків, але порядок рядків у таблиці також є несуттєвим.

Для нашої моделі вихідна інформація може бути представлена у вигляді п'яти таблиць.

1. Продукція:

- індекс товару;

- найменування;

- фірма;

- текущая ціна;

- кількість

2. Продукція на складі:

- кількість;

- індекс товару;

- № складу;

- ціна;

3. Склад:

- № складу;

- індекс товару;

4. Накладна:

- код накладної;

- код клієнта;

- дата;

- № складу;

5. Клієнт:

- код клієнта;

- ФІО;

- адреса;

- телефон;

6. Заказ:

- кількість;

- номер заказу;

- індекс товару;

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

2.2 Побудова та опис діаграми «Суттєвість-зв'язок»

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

- один - до - одного

- один - до - багатьох

- безліч - до - багатьох

Графічно зв'язок зображується лінією, що з'єднує дві сутності.

Кожен зв'язок може належати до одного з наступних видів зв'язків:

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

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

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

В розробленій базі даних можна побудувати наступну діаграму «сутність-зв'язок»:

Діаграма «Сутність - Зв'язок»

Приведена схема побудована на наступних припущеннях:

- у магазині є певна кількість товару з певною ціною ;

- на складі є певна кількість товару з певною ціною;

- клієнт купує товар у магазині заказ оформлюється через накладну;

3 РЕАЛІЗАЦІЯ ПРОЕКТУ БАЗИ ДАНИХ «РОЗРАХУНОК ПРИБУТКУ ВІД ПРОДАЖУ КОМП'ЮТЕРНИХ КОМПЛЕКТУЮЧИХ»

3.1 Розробка структури бази даних на ЕОМ

Щоб реалізувати проект бази даних «Розрахунок від продажу комп'ютерних комплектуючих» було обрано СУБД «MySQL».

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

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

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

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

Таблиця - Опис властивостей стовпчиків таблиць реляційної бази даних

№ п/п	Назва таблиці	Ім'я стовпчика	Властивості
1	Продукция	Индекс товара	Числовой (4 символа), нулевого значения нет
		Наименование	Текстовый(до 100 символов)
		Текущая цена	Денежный(4 символа), нулевого значения нет
		фирма	Текстовый(10 символов)
		количество	Числовой(5 символов), нулевого значения нет
2	Продукция на складе	Количество	Числовой(5 символов), нулевого значения нет
		Индекс товара	Числовой(4 символа), нулевого значения нет
		№ склада	Числовой(5 символов), нулевого значения нет
		цена	Денежный(4 символа), нулевого значения нет
3	Склад	№ склада	Числовой(4 символа), нулевого значения нет
		Индекс товара	Числовой(4 символа), нулевого значения нет
4	Накладная	Код накладной	Числовой(4 символа), нулевого значения нет
		Код клиента	Числовой(4 символа), нулевого значения нет
		Дата	Дата/время
		№ скалада	числовой(4 символа), нулевого значения нет
5	Клиент	Код клиента	Числовой числовой(4 символа), нулевого значения нет
		ФИО	Текстовый(20 символов)
		Адрес	Текстовый(20 символов)
		Телефон	Числовой(10 символов)
6	Заказ	Количество	Числовой(4 символа), нулевого значения нет
		Номер заказа	Числовой(4 символа), нулевого значения нет
		Индекс товара	Числовой(4 символа), нулевого значения нет

3.2 Створення таблиць та запитів на мові MySQL

Наступним етапом реалізації бази даних є створення таблиць та запитів. Код для створення таблиці «Продукция»:

CREATE TABLE `Продукция ` (

`Индекс товара ` int (4) NOT NULL,

`Наименование ` char(100),

`Текущая цена ` int (4) NOT NULL,

`Фирма ` char(10),

`Количество` int(5) NOT NULL,

/* Keys */

PRIMARY KEY (`Индекс товара`)

) ENGINE = MyISAM;

Код для створення таблиці «Продукция на складе»:

CREATE TABLE `Продукция на складе` (

`Количество` int (5) NOT NULL,

`Индекс товара` int (4) NOT NULL,

`№ склада` int (5) NOT NULL,

`цена` (4) NOT NULL,

/* Keys */

PRIMARY KEY (`Индекс товара`,`№ склада`)

) ENGINE = InnoDB;

Код для створення таблиці «Склад»:

CREATE TABLE `Склад` (

`№ склада` int (4) NOT NULL,

`Индекс товара` int (4) NOT NULL,

) ENGINE = InnoDB;

/* Keys */

PRIMARY KEY (`Индекс товара`)

Код для створення таблиці «Накладная»:

CREATE TABLE `Накладная` (

`Код накладной` int (4) NOT NULL,

`Код клиента` int (4) NOT NULL,

`Дата` date

`№ склада` int (4) NOT NULL

/* Keys */

PRIMARY KEY (`Код накладной`)

) ENGINE = InnoDB;

Код для створення таблиці «Клиент»:

CREATE TABLE `Клиент` (

`Код клиента` int (4) NOT NULL ,

`ФИО` char(20),

`Адрес` char(20),

`Телефон` int (10)

/* Keys */

PRIMARY KEY (`Код клиента`)

) ENGINE = InnoDB;

Код для створення таблиці «Заказ»:

CREATE TABLE `Заказ` (

`Количество` int (4) NOT NULL ,

`Номер заказа` int (4) NOT NULL ,

`Индекс товара` int (4) NOT NULL

Створення запиту «Данные о затратах», який буде виводити показники що необхідні будуть для розрахунку затрат:

SELECT [Продукции на складе]. [Индекс товара], Продукция. Количество, [Продукции на складе].Цена

FROM Продукция INNER JOIN [Продукции на складе] ON Продукция. [Индекс товара] = [Продукции на складе].[Индекс товара];

Створення запиту «Затраты», який буде виводити загальні затрати:

SELECT Sum ([Даные о затратах] ! [Количество] * [Даные о затратах] ! [Цена]) AS Затраты

FROM [Даные о затратах];

Створення запиту «Данные о доходах», який буде виводити показники що необхідні будуть для розрахунку доходу:

SELECT Заказ.[Индекс товара], Заказ. Количество, Продукция.[Текущая цена]

FROM Продукция INNER JOIN Заказ ON Продукция.[Индекс товара] = Заказ.[Индекс товара];

Створення запиту «Доход», який буде виводити загальний доход:

SELECT Sum ([Даные о доходе] ! [Количество] * [Даные о доходе] ! [Текущая цена]) AS Доход

FROM [Данные о доходе];

Створення запиту «Прибыль», який буде виводити прибуток:

SELECT [Доход] ! [Доход] - [Затраты] ! [Затраты] AS Прибыль

FROM Доход, Затраты;

3.3 Підготовка даних контрольного прикладу та його виконання

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

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

ВИСНОВКИ

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

В процесі формування структури бази даних здійснено визначення функціональних зв'язків і залежностей між елементами бази. Найдетальнішим чином описано весь перелік полів, що входять до складу таблиць бази даних. Описану базу для практичного використання підготовлено за допомогою використання ЕОМ за допомогою СУБД «MySQL». Під час виконання роботи більш змістовно засвоєно знання щодо проектування баз даних, набуто нових вмінь та навичок, необхідних для розробки подібних проектів.

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

СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ

1. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. - М.: Финансы и кредит, 1989.

2. Дейт К.Дж. Введение в системы баз данных. Пер. с англ. - К.; М.; СПб.: Издательский дом «Вильямс», 1999.

3. Дженнингс, Роджер. Использование Microsoft Access 97: Пер. с англ. - 2-е изд. - К.; М.; СПб.: Издательский дом «Вильямс», 1998.

4. Диго С.М. Проектирование и использование баз данных. - М.: Финансы и статистика, 1995.

5. Єрьоміна Н.В. Проектування баз даних: Навчальний посібник. - К.: КНЕУ, 1998.

6. Мартин Дж. Организация баз данных в вычислительных системах. - М.: Мир, 1980.

7. Мейер Д. Теория реляционных баз данных. М.: Мир, 1987.

8. Озкарахан Э. Машины баз данных и управление базами данных. - М.: Мир, 1989.

9. Тиори Т., Фрай Дж. Проектирование структур баз данных. - М.: Мир, 1985.

10. Хаббард Дж. Автоматизированное проектирование баз данных. - М.: Мир, 1984.

11. Хэлворсон М., Янг М. Эффективная работа с Microsoft Office 2000 - СПб: Питер, 2001. - 1232 с.: ил.

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