59
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ ДВНЗ «КИЇВСЬКИЙ НАЦІОНАЛЬНИЙ ЕКОНОМІЧНИЙ УНІВЕРСИТЕТ ІМЕНІ ВАДИМА ГЕТЬМАНА» КАФЕДРА ІНФОРМАЦІЙНИХ СИСТЕМ В ЕКОНОМІЦІ КУРСОВИЙ ПРОЕКТ з дисципліни: «Організація баз даних та знань» на тему : « Проектування БД для визначення та нарахування вiдрядної бригадної заробiтної плати» Виконала: студентка 2-го курсу спеціальності 6101, 2 групи Багерян В.В. 1

Сalculation of piece-rate crew wage (ukrainian lang)

Embed Size (px)

Citation preview

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

ДВНЗ «КИЇВСЬКИЙ НАЦІОНАЛЬНИЙ ЕКОНОМІЧНИЙ УНІВЕРСИТЕТ ІМЕНІ ВАДИМА ГЕТЬМАНА»

КАФЕДРА ІНФОРМАЦІЙНИХ СИСТЕМ В ЕКОНОМІЦІ

КУРСОВИЙ ПРОЕКТ

з дисципліни:

«Організація баз даних та знань»

на тему : «Проектування БД для визначення та нарахування

вiдрядної бригадної заробiтної плати»

Виконала: студентка 2-го курсуспеціальності 6101,2 групиБагерян В.В.

1

Керівник проекту:

Гордієнко Ірина Василівна

Київ 2015АНОТАЦІЯ

Курсового проекту Багерян В.В. на тему

«Проектування БД для визначення та нарахування

вiдрядної бригадної заробiтної плати».

Тему курсового проеку «Проектування БД для

визначення та нарахування вiдрядної бригадної

заробiтної плати» було обрано через її

актуальність, з метою полегшення ведення

бухгалтерського обліку.

Головна ідея даного курсового проекту –

проаналізувати предметну область та спроектувати

базу даних для визначення та нарахування відрядної

бригадної заробітної плати. У роботі обґрунтовано

вибір теми дослідження, доведено її актуальність,

наведена характеристика предметної області,

розкрита необхідність застосованої бази даних та її

основні переваги.

У першому розділі розкривається теоретична

частина, яка містить предметну область та опис

2

БД. Тут викладена ціль функціонування,

характеристика предметної області, описана

інформація, що використовується при прийнятті

рішення. У другому розділі міститься проектна

частина та створення інфологічної моделі. У

третьому розділі міститься розробка даталогічної

моделі, організація інформаційного забезпечення,

організаційне, програмне та технічне забезпечення.

У четвертому розділі міститься опис структур і

таблиць бази даних, реалізація запитів та звіти.

РЕФЕРАТКурсового проекту Багерян В.В. на тему

«Проектування БД для визначення та нарахуваннявідрядної бригадної заробітної плати». - Київ:кафедра інформаційних систем в економіці, 2015 рік.

Відомості про обсяг проекту: Загальна кількість сторінок – 44; Кількість таблиць – 12;

3

Кількість ілюстрацій – 12; Використано літературних джерел – 5.

Перелік ключових слів: нарахування відрядної бригадної заробітної плати, робітник, заробітна плата, E-RWin, Microsoft SQL Server.

Об’єкт дослідження: Визначення та нарахування відрядноїбригадної заробітної плати.

Мета роботи: спроектувати оптимальну базу даних длявизначення та нарахування відрядної бригадноїзаробітної плати.

Пропозиції до впровадження результатів роботи: наявністькомп’ютера та принтера (матричного типу), вмінняроботи з ПК, і знання програми E-Rwin. Вимоги доапаратного забезпечення ПК – це мінімально допустимаконфігурація для встановлення програми E-RWin таMicrosoft SQL Server.Апаратура, використана при дослідженні:

- процесор – Intel Celeron (К) СЗГ 2.53GHz;- оперативна пам'ять – 768 МБ ОЗУ;- відео карта – RADEON, 256МБ;- жорсткий диск Western Digital 160 ГБ;- дисковод – DVD+-RW DVD+R;- дисплей –Samsung L1717S,

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

4

ЗМІСТ

АНОТАЦІЯ..........................................................................................................2РЕФЕРАТ.............................................................................................................3ВСТУП.................................................................................................................5РОЗДІЛ І. ДОСЛІДЖЕННЯ ПРЕДМЕТНОЇ ОБЛАСТІ..................................6

1.1. Характеристика структури предметної області ………..............6

1.2. Опис вхідних повідомлень................................................................8

1.3 Опис вихідних повідомлень…………………………….…....……10

1.4 Опис основних процедур перетворення даних……………..……11РОЗДІЛ ІІ. РОЗРОБКА ІНФОЛОГІЧНОЇ МОДЕЛІ......................................13

2.1. Інформаційні об’єкти та їх характеристика…………………..…13

2.2. Запити та запитувальні зв’язки ……………………………….….20

2.3. Структурні зв’язки та їх відображення на графі ІЛМ………..…22

2.4. Автоматизація проектування інфологічної моделі …….........….24РОЗДІЛ ІII. РОЗРОБКА ДАТАЛОГІЧНОЇ МОДЕЛІ....................................26

5

3.1 Обгрунтування та вибір СКБД ……….……………………..…....26 3.2 Автоматизація даталогічного проектування та її результати.…..30IV. ПРОЕКТУВАННЯ ТА РЕАЛІЗАЦІЯ БД НА ФІЗИЧНОМУ РІВНІ…..32

4.1 Опис структур таблиць БД ……………………..……….………...32 4.2 Реалізація запитів, форм та звітів ………………………..…….…37ВИСНОВКИ.......................................................................................................41СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ..................................................42ДОДАТКИ..........................................................................................................43

6

ВCТУПРозробка бази даних, що буде автоматизувати

процес визначення та нарахування відрядної бригадної

заробітної плати має не тільки навчальне та

теоретичне значення, а й при вдалому проектуванні –

практичне значення, а саме прискорення пошуку даних

про нараховану заробітну плату, а сам процес буде

виконуватися не в ручну, а за допомогою сучасних

програмних продуктів - E-Rwin та Microsoft SQL

Server.

В наш час відрядна заробітна плата, наряду з

погодинною, є дуже популярною формою оплати праці.

Застосування відрядної оплати праці потребує:

правильний розрахунок розцінок;

правильного присвоєння робітникам тарифних

розрядів відповідно до їхньої кваліфікації і з

урахуванням кваліфікаційного рівня виконуваних

робіт;

Розроблена база даних визначає пряму відрядну

заробітну плату, без використання преміальних тощо.

Можна з впевненістю сказати, що дослідження

теми курсового проекту дасть практичні та теоретичні

навички по проектуванню баз даних та економіці праці.

7

РОЗДІЛ І. ДОСЛІДЖЕННЯ ПРЕДМЕТНОЇ ОБЛАСТІ

1.1. Характеристика функціональної структури

предметної області

Предметна область для визначення та нарахування

відрядної заробітної плати складається лише з

визначення та саме нарахування заробітної плати.

Перед початком роботи необхідно обрати з якого ж

боку підходити до предметної області. Цілком логічно,

що до питання нарахування заробітної плати можна

підійти з боку підприємства чи з боку працівника.

Підхід з боку працівника має суттєвий недолік:

необхідно для кожного працівника розробити власну

базу даних , що дозволить відстежити всі нарахування

заробітної плати за весь період роботи працівника.

8

Цей підхід направлений на роботу з працівником –

кожен працівник має власну базу даних, що

зберігається за ним при зміні місця роботи. Однак для

підприємства такий підхід є не дуже гарним, адже буде

важко відстежити правильність заповнення бази даних

тощо.

Підхід з боку підприємства є набагато кращим –

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

інформація про нарахування заробітної плати

працівника за весь період його роботи на цьому

підприємстві. Цей підхід є найкращим і для працівника

(працівник може відстежити всі нарахування на цьому

підприємстві і запросити інформацію з минулих місць

роботи), і для підприємства (легко відстежити

нарахування заробітної плати будь-якого працівника за

будь-який період).

Функціональні задачі бази слабо залежать від

потреб підприємства, так як відрядна заробітна плата

визначається подібно на будь-якому підприємстві.

Відмінності між інформаційними системами для різних

підприємств будуть незначними. Основні функціональні

задачі бази будуть наступними:

інформація про форму оплати праці певного робітника;

інформація про відпрацювання певним працівником;

інформація про відрядні норми певного працівника;

9

На виході роботи бази даних формується звіт, що

дозволяє переглянути заробітні плати працівників по

бригадах.

10

Ввід інформації в БД

Робітник

Бригада

Цех

Нарахування

Пррофесія

Дов.Детале

й

Розрахунок заробітної плати

на бригаду

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

відповідно до коефіцієнту

трудової участі

Звіт з нарахувань по бригадах

Звіт з нарахувань по робітниках

Бухгалтерія

1.2. Опис вхідних повідомлень

До вхідних повідомлень відносять документи, які

використовуються для формування оперативних файлів

бази даних; файли, що потрапляють на вхід задачі чи

комплексу з інших задач та їх комплексів…

Перелік і опис вхідних повідомлень наведено у

табл. 1.1.

Таблиця 1.1Назва

вхідного

повідомлення

Ідентифікатор Форма

подання

Термін і

частота

надходженн

я

Джерело

Робітник Worker Електронн

ий

Документ

По мірі

надходженн

я

Адміністра

тор

Довідник

деталей

DetailsDictionary

Електронн

ий

Документ

По мірі

надходженн

я

Адміністра

тор

Професія Profession Електронн

ий

Документ

По мірі

надходженн

я

Адміністра

тор

11

Цех Department Електронн

ий

Документ

По мірі

надходженн

я

Адміністра

тор

Бригада Crew Електронн

ий

Документ

По мірі

надходженн

я

Адміністра

тор

Нарахування Narahyvania Електронн

ий

Документ

По мірі

надходженн

я

Адміністра

тор

Визначення та нарахування відрядної бригадної заробітної

плати має такі реквізити:

Робітник;

Довідник деталей;

Професія;

Цех;

Бригада;

Нарахування;

12

1.3. Опис вихідних повідомлень

До вихідних повідомлень відносять  фінансові

документи, формовані бухгалтерією з метою визначити

та нарахувати заробітну плату відрядній бригаді,

тобто саме ті дані, які будуть оброблятися базою

13

даних(вибірки по бригадах, розрахунок заробітної

плати)

Вихідними повідомленнями для задачі «Проектування

БД для визначення та нарахування вiдрядної бригадної

заробiтної плати» будуть :

Звіт з нарахувань по робітниках;

Звіт з нарахувань по бригадах.

Перелік і опис вихідних повідомлень наведено у

табл. 1.2.

Таблиця 1.2

Назва

вихідного

повідомленн

я

Ідентифікато

р

Форма

подання і

вимоги до

неї

Періодичніс

ть видання

Термін

видання і

допустими

й час

затримки

Користува

ч

інформаці

ї

1 2 3 4 5 6

Звіт з

нарахувань

по

робітниках

Worker_wage_sum

Електронни

й документ

За потребою За

потребою,

1 – 2

рази в

місяць

Бухгалтер

ія

Звіт з

нарахувань

по бригадах

Crew_wage_sumЕлектронни

й документ

За потребою За

потребою,

1 – 2

рази в

Бухгалтер

ія

14

місяць

1.4. Опис основних процедур перетворення даних

Розв’язання економічних задач зводиться до

виконання інформаційних процедур. Сукупність усіх

інформаційних процедур утворює інформаційний процес,

який є основою управлінської діяльності. Інформація,

що надходить з інформаційного середовища, має

відношення до того, що заведено називати системою

управління. Ця інформація пов’язана з подіями,

рішеннями, непередбаченими обставинами тощо. При

цьому послідовність процедур перетворення інформації

не є фіксованою — вона може не містити певних

процедур взагалі, а деякі, навпаки, можуть бути

повторені. Але, як правило, економічна інформація

проходить через усі інформаційні процедури

перетворення, до яких належать:

а) відбір показників оцінки поточного стану

об’єкта управління;

б) збирання та реєстрація;

в) кодування і декодування;15

г) передання;

д) збереження;

е) обробка;

є) оформлення та розмноження результативної

інформації;

ж) прийняття рішення про подальше функціонування

об’єкта управління.

Використовуючи процедури обробки економічної

інформації, технологічний процес обробки інформації

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

систему, що реалізує вказаний процес, визначити як

систему обробки даних.

За ступенем автоматизації процедури перетворення

інформації можна поділити на системи ручної обробки

даних, автоматизовані системи обробки даних за

участю людини та системи автоматичної обробки даних

з виключенням людини з процедури перетворення даних.

Колективна відрядна розцінка на одиницю виробу (Rк)

визначається за формулою:

(1.1)

де Σ ТСт - сума тарифних ставок членів бригади, грн

за годину;

Нбр- бригадна норма виробітку.

16

Другий варіант розрахунку колективної відрядної

розцінки заснований на калькуляції трудомісткості

виконуваної роботи. У даному випадку колективна

відрядна розцінка визначається за формулою:

(1.2)

де Σ Тст = Т1 + Т2 + Т3 + ... + Тn - сума тарифних

ставок, які відповідають розряду робіт, грн за

годину;

Σ Втр = Втр1 + Втр2 + Втр3 + ... + Втрn - сума

трудових витрат за встановленими нормами за кожним

розрядом виконуваних робіт.

Третій варіант (який реалізовано в даній роботі)

базується на коефіцієнті трудової участі кожного

робітника в бригаді.

Заробітна плата на бригаду нараховується як:

(1.3)

де Wbr(wage) - заробітна плата на бригаду,

DP(detail payment) - оплата за 1 деталь,

q (quantity) – кількість деталей, зроблених

бригадою.

17

Заробітна плата всередині бригади розраховується як:

(1.4)

де Wpr – зарплата працівника,

– сума коефіцієнтів трудової участі по

бригаді,

KTYpr – коефіцієнт трудової участі працівника.

РОЗДІЛ ІІ. РОЗРОБКА ІНФОЛОГІЧНОЇ МОДЕЛІ

2.1. Інформаційні об’єкти та їх характеристика

Метою інфологічного проектування є створення

структурованої інформаційної моделі предметної

області, для якої буде розроблятися база даних.

Сутність iнфологiчного проектування полягає у

визначенні інформаційних об’єктів (сутностей)

предметної області, якi підлягають зберіганню в БД,

визначенню характеристик об’єктів та структурних

зв’язків мiж ними. Результатом iнфологiчного

моделювання є iнформацiйно-логiчна модель предметної

області та опис її складових елементів. Iнфологiчна

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

прикладних програм.

18

Основними складовими елементами інфологічної моделі

є:

інформаційний об’єкт;

атрибут;

інформаційний запит;

запитувальний зв’язок;

структурний зв’язок.

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

етапами:

вилучення омонімії та синонімії;

- це означає , що кожен атрибут повинен мати

унікальне ім’я та унікальну семантику для однозначної

його ідентифікації.

- ні синонімії, ні омонімії в даному разі

немає.

агрегація атрибутів в інформаційні об’єкти.

Тобто усі атрибути агрегуються в об’єкти, яким

присвоюються унікальні імена;

перевірка на відповідність умовам нормалізації;

приведення до 3 чи 4 нормальної форми.

виділення інформаційних запитів та їх опис;

представлення інформаційних запитів у

структурованому вигляді.

перевірка запитальних зв’язків на

відповідність умові канонічності;

побудова структурних зв’язків між об’єктами.

19

Існує два підходи до інфологічного проектування:

аналіз об’єктів і синтез атрибутів. Підхід, що

базується на аналізі об’єктів, називається нисхідним,

а на синтезі атрибутів — висхідним. Економіко-

організаційні системи найчастіше створюються з

використанням висхідного підходу, який полягає в

аналізі атрибутів і синтезі на їх основі

інформаційних об’єктів [3, ст.33].

В даному випадку використовується нисхідний

підхід. Наша база даних базується на таких

інформаційних об’єктах: довідник деталей, довідник

працівників , бригада, цех, довідник нарахувань

працівників табригад. Розглянемо ці об’єкти

детальніше.

Опис об’єкту «Робітник»

Найменування об’єкту – Робітник;Ідентифікатор об’єкту – Robitnik ;Найменування носію інформації –  HDD;Максимальний обсяг - 1000000 записів;Довжина запису - 133 символи;Метод організації – послідовний;Ключ упорядкування - код робітника.

Таблиця 2.1

20

Назва

атри

бута

Форм

ат

Обов’я

зковий

Обмеже

ння на

право

звер

танн

яПе

рвинни

й(вто

ринн

ий)

Відпов

ідніст

ь зн

ачен

ьДу

блюв

ання

значен

ь

Умов

и на

допу

стим

ізнач

ення

Інде

ксне

поле

Таблиця 2.1 (продовження)

WorkerId numeric(18, 0)

Так

Право назвертання маютьвсі

операційні

системи

ПК - Ні

Відповідно доправилсистеми

ІНД

WorkerPIB char(50,0)

Так - - Так - -

ProfessionCode numeric(18

, 0)

Так ВК Та

к Так

Відповідно доправилсистеми

-

DepartmentCode numeric(18

, 0)

Так ВК Та

к Так

Відповідно доправилсистеми

-

CrewCode numeric(18, 0)

Так ВК Та

к Так

Відповідно доправилсистеми

-

DateOfBirth dateТак ВК Та

к Так

Відповідно доправилсистеми

-

Опис об’єкту «Бригада»

Найменування об’єкту – Бригада; Ідентифікатор об’єкту – Crew; Найменування носія інформації – HDD;Максимальний обсяг - 20 записів;

21

Довжина запису - 68 символів; Метод організації – послідовний;Ключ упорядкування - код бригади.

Таблиця 2.2.

Назва

атри

бута

Форм

ат

Обов’я

зковий

(так

/ні)

Обмеже

ння на

право

звер

танн

я

Перв

инни

й(вто

ринн

ий)

Відпов

ідніст

ь зн

ачен

ьДу

блюв

ання

значен

ь

Умов

и на

допу

стим

ізнач

ення

Інде

ксне

поле

CrewCode numeric(18, 0)

Так

Право назвертання маютьвсі

операційні

ПК - Ні

Відповідно доправилсистеми

ІНД

Таблиця 2.2 (продовження)

CrewName char(50,0)

Так системи - - Так - -

Опис об’єкту «Цех»

Найменування об’єкту – Цех; Ідентифікатор об’єкту – Crew; Найменування носія інформації – HDD;Максимальний обсяг - 20 записів;Довжина запису - 68 символів; Метод організації – послідовний; Ключ упорядкування - код цеху.

Таблиця 2.3

22

Назва

атри

бута

Форм

ат

Обов’я

зковий

(так

/ні)

Обмеже

ння на

право

звер

танн

я

Перв

инни

й

Відпов

ідніст

Дублюв

ання

значен

ьУмов

и на

допу

стим

ізнач

ення

Інде

ксне

поле

DepartmentCode

numeric(18, 0) Так

Право назвертання маютьвсі

операційні

системи

ПК - Ні

Відповідно доправилсистеми

ІНД

DepartmentName char (50,

0)Так - - Так - -

Опис об’єкту «Професія»

Найменування об’єкту – Професія; Ідентифікатор об’єкту – Profession; Найменування носія інформації – HDD;Максимальний обсяг - 10 записів;Довжина запису - 68 символів; Метод організації – послідовний; Ключ упорядкування - код професії.

Таблиця 2.4

Назва

атрибу

та

Формат

Обов

’язк

овий

(так/н

і)Обме

женн

я на

право

звер

тання

Перв

инний

Відп

овід

ніст

Дублюван

нязнач

ень

Умови

надопу

стимі

значен

ня

Індекс

неполе

ProfessionCode

numeric(18, 0) Так

Право назвертання маютьвсі

операцій

ПК - Ні

Відповідно доправилсистеми

ІНД

ProfessionN Так - - Так - -

23

ame char (50, 0) ні

системи

Опис об’єкту «Нарахування на бригаду»

Найменування об’єкту –CrewPayments; Ідентифікатор об’єкту –CrewCode; Найменування носія інформації – HDD;Максимальний обсяг - 50 записів;Довжина запису - 86 символів; Метод організації – послідовний; Ключ упорядкування - код розряду.

Таблиця 2.5

Назва

атрибута

Формат

Обов

’язковий

(так/ні)

Обме

ження на

право

звертання

Первинний

Відп

овідніст

ь значень

Дублюван

нязнач

ень

Умови на

допустимі

значення

Індексне

поле

CrewCode numeric(18, 0) Так Право на

звертаннямають всіопераційні системи

ПК - Ні

Відповідно доправилсистеми

ІНД

DetailsDone numeric(18

, 0)Так - - Так - -

Таблиця 2.5 (продовження)

DetailsType

char(50, 0) Так - - Ні

Відповідно доправил

підприємства

-

24

Опис об’єкту «Нарахування на працівника»

Найменування об’єкту –WorkerPayments; Ідентифікатор об’єкту –WorkerCode; Найменування носія інформації – HDD;Максимальний обсяг – 50 записів;Довжина запису - 46 символів; Метод організації – послідовний; Ключ упорядкування - код розряду.

Таблиця 2.6

Назв

аатрибута

Формат

Обов’язков

ий(так/ні)

Обмеження

направ

озверта

ння

Первин

ний

(вторинний)

Відповідні

стДубл

ювання

значень

Умови на

допуст

имі

значення

Індексне

поле

WorkerCode

numeric(18, 0) Так

Право назвертаннямають всіопераційні системи

ПК - Ні

Відповідно доправилсистеми

ІНД

PaymentDate date Так - - Так - -

KTYnumeric(18, 0) Так - - Ні

Відповідно доправил

підприємства

-

Опис об’єкту «Довідник деталей»

Найменування об’єкту –DetailsDictionary; Ідентифікатор об’єкту –DetailType; Найменування носія інформації – HDD;

25

Максимальний обсяг - 15 записів;Довжина запису - 36 символів; Метод організації – послідовний; Ключ упорядкування - код розряду.

Таблиця 2.7

Назв

аат

рибу

та

Формат

Обов

’язк

овий

(так/н

і)Обме

женн

я на

прав

озвер

тання

Перв

инний

(втори

нний

)Відп

овід

ніст

ь зн

ачень

Дубл

юван

нязнач

ень

Умови

надопу

стимі

значен

ня

Індекс

неполе

DetailType

numeric(18, 0)

Так

Право назвертаннямають всіопераціоні системи

- - Так Відповідно доправилсистеми

-

AmountOfPayment

numeric(18, 0)

Так ВК Та

к Так

Відповідно доправилсистеми

-

Основними носіями iнформації для вирішення задачі

для визначення та нарахування відрядної бригадної

заробітної плати є машинні носії (для збереження та

обробки оперативної та нормативно-довідкової

інформації) і паперові носії (для формування

відповідної документації). Розподіл інформації між

різними носіями повинен відповідати вимогам

цілісності даних, зручності їх сприйняття, швидкого

їх отримання, а також економії машинної пам'яті та

захисту від несанкціонованого доступу.

26

Відповідальність за достовірність інформації,

внесеної до БД, несуть адміністратор системи та

клієнт. Під час роботи системи здійснюється

програмний контроль введення даних: перевіряються

окремі ноля на правильність їх введення за існуючою

маскою, діапазон змін значень атрибутів,

контролюється наявність кодів в нормативно-довідкових

масивах та ін.

2.2. Запити та запитувальні зв’язки

Інформаційний запит – це словесний опис

інформаційної потреби користувача чи прикладної

програми.

На основі запиту будується запитувальний зв’язок,

що являє собою структурований опис інформаційного

запиту, в якому відображено об’єкти, необхідні для

його реалізації з урахуванням навігації між ними. У

цьому разі під навігацією мають на увазі шлях

інформаційного пошуку при виконанні запиту. Можна

навести ще таке значення запиту вального зв’язку – це

формалізований опис інформаційного запиту, який

відображає певну процедуру, що передбачає в алгоритмі

процес переходу від екземплярів одних об’єктів, що

27

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

об’єктів.

Запитувальний зв’язок будується на основі запиту.

Він являє собою структурований опис інформаційного

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

реалізації об’єкти з урахуванням навігації (шляхів

інформаційного пошуку) між ними. [3, c. 32]

Запити створюються користувачем для вибірки

потрібних даних з однієї або декількох зв'язаних

таблиць. За допомогою запитів можна виконати

необхідне сортування, обчислити якийсь вираз або

спільно обробити відразу кілька зв’язаних таблиць.

Запит може формуватися за допомогою запитів за

зразком QBE або за допомогою мови структурованих

запитів SQL. За допомогою запиту можна також

обновити, видалити, додати дані в таблиці або

створити нові таблиці на основі вже існуючих.

При виконанні запиту підсумкові дані

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

зберігаються і тому носять назву динамічних наборів

даних.

Динамічний набір даних – це тимчасова таблиця, яка

створюється запитом. В цій таблиці розміщуються

записи, які задовольняють вимогам певного запиту.

Запити можна використовувати приблизно так, як і

таблиці - можна відкрити і переглянути відповідний

28

динамічний набір даних. Крім того, динамічні набори

можна вносити зміни, які відобразяться в тих

таблицях, з яких були вибрані ті чи інші дані.

Запити можна поділити на такі дві групи: запити-

вибірки та запити-дії.

Запити-вибірки – це найбільш поширений тип

запитів. За допомогою таких запитів не виконується

жодних перетворень з даними, а лише здійснюється

пошук даних за певними умовами, які відображають

поточні інформаційні потреби користувача.

Запити-дії – це запити, за допомогою яких можна

додавати, змінювати чи вилучати дані.

Курсовий проект містить наступні запити:

1. Розрахувати КТУ по бригаді.

2. Розрахувати оплату по бригаді.

3. Розрахувати оплату працівника.

29

2.3. Структурні зв’язки та їх відображення на графі

ІЛМ

Структурний зв'язок – це асоціації, що описують

ієрархічні зв’язки між парами інформаційних об’єктів,

один з яких виступає як власник, а інший – як

підпорядкований об’єкт. Екземпляр структурного

зв’язку являє собою екземпляр об’єкта власникам та

певну сукупність зв’язаних з ним екземплярів

підпорядкованого об’єкта.

При інфологічному проектуванні може виникнути

певна складність, пов’язана з тим, що вважати

атрибутом, а що – об’єктом. Слід зазначити, що немає

чіткої межі між цими двома поняттями, і дуже часто

атрибут може виступати як самостійний об’єкт.

Ключовим моментом при визначенні структури

інформаційних об’єктів є вивчення типів співвідношень

між атрибутами, які можуть бути 1:1, 1:Б, Б:1 і Б:Б.

Тип співвідношення «один до одного» існує тоді,

коли одному і тому самому значенню атрибута

відповідають не більше ніж одне значення другого

атрибута.

30

Тип співвідношення «один до багатьох» існує тоді,

коли одному значенню атрибута має відповідати багато

значень другого атрибута.

Тип співвідношення «багато до одного» існує, коми

одному значенню атрибута відповідає щонайбільше одне

значення другого атрибута, а будь-якому значенню

другого атрибута може відповідати багато значень

першого атрибута.

Тип співвідношення «багато до багатьох» означає, що

будь-якому значенню одного атрибута може відповідати

кілька значень другого атрибута і водночас, навпаки,

будь-якому значенню другого атрибута може відповідати

кілька значень першого атрибута.

В таблиці 2.8 подані співвідношення для даної

бази даних.

Таблиця 2.8

Працівник Нарахування 1:∞ Один

працівник

має декілька

нарахувань.Працівник Професія 1:∞ Один

працівник

може мати

31

декілька

професій.Працівник Бригада 1:1 Один

працівник

може бути

членом

тільки 1

бригади.Цех Бригада 1:∞ Декілька

бригад

об’єднуються

в цех.Бригада Нарахування 1:∞ Одна бригада

має декілька

нарахувань.Нарахування Довідник

деталей

1:∞ Одна бригада

може робити

деталі

різного типу

32

2.4. Автоматизація проектування інфологічної

моделі

На сучасному етапі при розробці баз даних широко

застосовуються CASE-системи. Вони використовуються не

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

програмних продуктів, але й як ефективний інструмент

вирішення дослідницьких і проектних задач, пов’язаних

з початковими етапами розробки баз даних, таких як

аналіз предметної області, розробка проектних

специфікацій, випуск проектної документації,

планування і контроль розробок, моделювання

прикладного програмного забезпечення.

CASE-засоби представляють собою програмні засоби,

які підтримують процеси створення і/чи супроводу БД,

такі як: аналіз і формулювання вимог, проектування

баз даних і прикладного програмного забезпечення,

генерація кодів програм, тестування, управління

конфігурацією проекту.

При проектування бази даних було використано CASE-

засіб ERwin, який дозволяє автоматизувати

проектування БД і генерацію її опису мовою вибраної

СКБД, а також виконати реінжиніринг бази даних. В

ERwin існує два рівні представлення моделі БД:

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

інформаційна модель предметної області (інфологічна

33

модель), на фізичному рівні проектується модель з

урахуванням специфіки та особливостей вибраної СКБД

(даталогічна модель).

Проаналізувавши всю інформацію і вивчивши

предметну область перейдемо до створення сутностей та

заповнення їх атрибутами за допомогою CASE – засобу

Erwin (Рис. 2.4.1). Між сутностями встановимо

зв’язки, між більшістю сутностей зв'язок

необов’язковий неідентифікований - це означає що

значення атрибутів не може бути нуль.

Реалізація в ERWin

34

Рис 2.1. Логічний рівень проектування ІМ

35

РОЗДІЛ ІII. РОЗРОБКА ДАТАЛОГІЧНОЇ МОДЕЛІ

3.1 Обгрунтування та вибір СКБД

Вибір конкретної архітектури побудови бази даних

включає в себе два основні компоненти: вибір серверної

платформи та вибір платформ для клієнтських робочих

місць. При виборі бази даних дуже важливо вибрати таку,

яка найбільше відповідає вимогам інфологічної моделі ,

необхідно визначитися яка модель автоматизації

реалізується. В першу чергу при виборі СКБД необхідно

взяти до уваги наступні фактори:

1. максимальна кількість користувачів, які одночасно

звертаються до бази даних;

2. характеристики клієнтської предметної області;

3. апаратні компоненти сервера;

4. серверна операційна система;

5. рівень кваліфікації персоналу.

На сьогоднішній день відома велика кількість різних

серверів баз даних SQL. Найбільш відомими і передовими

серверними СКБД є: Microsoft SQL Server, Oracle8i, IBM

DB2 та Informix.

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

відрядної бригадної заробітної плати було вибрано

Microsoft SQL Server через її популярність та простоту у

використанні.

Головними характеристиками даної СКБД – це:

36

1)простота адміністрування,

2)можливість підключення до Web,

3)швидкодіючі і функціональні можливості механізму

сервера СКБД,

4)наявність засобів віддаленого доступу,

5)багаторазовість використання даних,

6)економія витрат та створення і введення,

7)зменшення надлишковості даних,

8)швидкість оброблення непередбачуваних запитів до

системи,

9)простота і зручність внесення змін до бази даних,

10) відсутність аномалій при внесенні змін до бази

даних.

В комплекті засобів адміністративного управління

даною СКБД входить цілий набір спеціальних майстрів і

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

Також дана БД оснащена прекрасними засобами тиражування ,

які дозволяють синхрозувати дані ПК з інформацією БД та

навпаки. Вхідний в комплект поставки сервер OLAP дає

можливість зберігати та аналізувати всі наявні у

користувача дані. В принципі дана СКБД представляє собою

сучасну повнофункціональну базу даних, яка ідеально

підходить для малих і середніх організацій. Необхідно

зазначити, що SQL Server поступається іншим СКБД по двох

важливих показниках: програмованість і засоби роботи. При

розробці клієнтських БД додатків на основі мови Java,

37

HTML часто виникає проблема недостатньої кількості

програмних засобів SQL Server і користуватися цією СКБД

буде важче, ніж системами DB2, Informix, Oracle або

Sybase. Світовою тенденцією ХХІ століття став практично

всюди перехід на платформу LINUX, а SQL Server функціонує

тільки у Windows. [2]

В таблиці 3.1 приведено порівняльні характеристики

двох найбільш популярних та розповсюджених на

сьогоднішній день рішень на базі Microsoft SQL Server та

Oracle8i. Таблиця 3.1

Microsoft SQL

Server

Oracle8i

Адміністративне

управління

Добре Відмінно

Графічні

інструменти

Відмінно Добре

Простота

обслуговування

Добре Відмінно

Механізм даних Добре ВідмінноРобота з

декількома ЦП

Допустимо Відмінно

Таблиця 3.1 (продовження)

Функція з’єднання Відмінно Відмінно

38

та вибору

індексів Одночасний доступ

декількох

користувачів

Добре Відмінно

Підключення до

Web

Погано Відмінно

Обробка аудіо,

відео, зображень

Погано Відмінно

Пошук по тексту Добре ВідмінноФункціональна

сумісність

Добре Допустимо

Сумісність з

іншими БД

Добре Погано

Єдина регістрація Добре ДобреРобота під

управлінням

різних ОС

Допустимо Добре

Можливість

програмування

Допустимо Відмінно

Зберігаючі

процедури та

трігери

Добре Відмінно

Внутрішня мова

програмування

Погано Відмінно

Побудова баз Добре Відмінно

39

данихМова SQL Відмінно ВідмінноОб’єктно-

орієнтовані

системи

Погано Відмінно

Робота з

філіалами

Відмінно Відмінно

Тиражування Відмінно ВідмінноРозподілена

обробка

транзакцій

Відмінно Відмінно

З огляду на недоліки SQL Server, була використана ОС

Windows через зручність інтерфейсу і популярність серед

користувачів.

40

3.1. Автоматизація даталогічного проектування та її

результати

Завданням наступної стадії проектування бази даних є

вибір підходящої СКБД і відображення особливостей

інфологічної моделі предметної області. Цю стадію

називають логічним (або даталогічним) проектуванням бази

даних, а її результатом є схема бази даних, що включає

визначення всіх інформаційних елементів і зв'язків, у

тому числі завдання типів, характеристик та імен. [2,

c. 369]

Дана база даних є реляційною. У ній об'єкти й зв'язки

між ними представляються у вигляді таблиць (відносин), що

41

складаються з рядків і стовпців. Стовпець – це поле,

рядок – це запис. Кожне поле має ім'я й тип. Імена полів

– це атрибути (вони визначаються властивостями об'єкта).

Тип задає спосіб подання атрибута.

Основна властивість таблиці в реляційною базі даних

полягає в тому, що в ній не повинне бути однакових

записів. Це означає, що в таблиці повинні бути один або

кілька атрибутів, які забезпечують унікальність кожного

рядка. Такі атрибути називаються ключем. Ключів у таблиці

може бути кілька. З них вибирається один, котрий буде

надалі представляти (заміняти) кожен запис таблиці. Такий

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

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

як властиво дані (у вигляді таблиць), так і способи

роботи й маніпуляції з ними (у вигляді зв'язків). Інакше

кажучи, у реляційній БД використається кілька таблиць,

між якими встановлюються зв'язки. Таким чином,

інформація, уведена в одну таблицю, може бути пов'язана з

однієї або декількома записами з іншої таблиці.

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

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

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

один тип.

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

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

42

Тепер згенеруємо інфологічну модель бази даних в CASE

– засобі E-RWin з вибраною СКБД Microsoft SQL Server і

отримуємо схему даних в середовищі Microsoft SQL Server

(Рис.3.1).

Рис. 31. Схема даних бази даних в середовищі MicrosoftSQL Server.

43

IV. ПРОЕКТУВАННЯ ТА РЕАЛІЗАЦІЯ БД НА ФІЗИЧНОМУ

РІВНІ

4.1. Опис структур таблиць БДЗгенерувавши інфологічну модель бази даних в CASE –

засобі Erwin з вибраною СКБД Microsoft SQL Server ми

отримали схему даних в середовищі Microsoft SQL Server.

В той же час в базі даних CrewPayments.dbo створилися

наступні таблиці (Рис. 4.1-4.8) з відповідними їм

атрибутами.

Для кожного атрибута було встановлено свій тип даних

згідно до якого були заповнені поля в таблицях.

44

Рис. 4.1 Таблиця Бригада

Рис. 4.2 Таблиця Нарахування на бригаду

45

Рис. 4.3 Таблиця Цех

Рис. 4.4 Таблиця Довідник деталей

46

Рис. 4.5 Таблиця Професія

47

Рис. 4.6 Таблиця Працівник

Рис. 4.7 Таблиця Нарахування на працівника

48

4.2. Реалізація запитів, форм та звітів

Запити створюються користувачем для вибірки потрібних

даних з однієї або декількох зв'язаних таблиць. За

допомогою запитів можна виконати необхідне сортування,

обчислити якийсь вираз або спільно обробити відразу

кілька зв’язаних таблиць. Запит може формуватися за

допомогою запитів за зразком QBE або за допомогою мови

структурованих запитів SQL. За допомогою запиту можна

також обновити, видалити, додати дані в таблиці або

створити нові таблиці на основі вже існуючих.

При виконанні запиту підсумкові дані відображуються у

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

носять назву динамічних наборів даних.

Динамічний набір даних – це тимчасова таблиця, яка

створюється запитом. В цій таблиці розміщуються записи,

які задовольняють вимогам певного запиту.

49

Запити можна використовувати приблизно так, як і

таблиці - можна відкрити і переглянути відповідний

динамічний набір даних. Крім того, динамічні набори можна

вносити зміни, які відобразяться в тих таблицях, з яких

були вибрані ті чи інші дані.

Запити можна поділити на такі дві групи: запити-

вибірки та запити-дії.

Запити-вибірки – це найбільш поширений тип запитів.

За допомогою таких запитів не виконується жодних

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

певними умовами, які відображають поточні інформаційні

потреби користувача.

Запити-дії – це запити, за допомогою яких можна

додавати, змінювати чи вилучати дані.

Курсовий проект містить наступні запити:

4. Розрахувати КТУ по бригаді.

5. Розрахувати оплату по бригаді.

6. Розрахувати оплату працівника.

Займемось реалізацією цих запитів у середовищі

Microsoft SQL Server. (Рис.4.8)

50

Рис. 4.8 Розрахунок КТУ по бригаді.

51

Рис. 3.1.2 Розрахунок оплати по бригаді.

52

Рис. 3.1.3 Комплексний запит-представлення для

розрахунку оплати працівника.

53

ВИСНОВКИ

Проектування даної бази даних було виконано згідно з

усіма етапами проектування баз даних: зовнішнього,

інфологічного, даталогічного та внутрішнього.

На зовнішньому рівні було досліджено предметну

область: охарактеризовано функцiональну структуру

предметної областi, описано вхiдні та вихiдні

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

перетворення даних.

На етапі інфологічного проектування було досліджено

та охарактеризовано інформаційні об’єкти, проаналізовано

можливі запити користувачів та прикладних програм до

проектованої бази, а також описано запитувальні зв’язки.

Після аналізу запитувальних зв’язків на одновимірність та

багато вимірність, було створено структурні зв’язки та

представлено їх на графі ІЛМ. Для автоматизованого

проектування інфологічної моделі використано CASE-засіб

ERwin.

На даталогічному рівні проектування БД було обрано

цільову СКБД Microsoft SQL Server, та обґрунтовано цей

вибір, а також наведена стисла характеристика обраної

СКБД. Результатом виконання даного етапу проектування БД54

є створення даталогічної моделі, для проектування якої

також було використано один із найсучасніших CASE-засобів

ERwin.

На фізичному рівні було спроектовано та реалізовано

на фізичному рівні БД у обрану СКБД. Описано структуру

таблиць та сформованих запитів.

Спроектована БД є повноцінною функціональною, тобто

може практично застосовуватися для нарахування бригадної

відрядної заробітної плати.

55

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

1.Апопій В. В. Інтернет-торгівля: проблеми і

перспективи розвитку / Апопій В. В. // Регіональна

економіка. - 2003. - № 1. - С. 25.

2.Береза А. М. Основи створення баз даних: Навч.

посібник. - 2-ге вид., перероб. і доп.-К.: КНЕУ,

2011. - 214 с.

3.Ситник Н.В. Проектування баз і сховищ даних: Навч.

Посібник. – К.: КНЕУ, 2004. – 348 с.

4.Р. Шелдон, Дж. Мойє. My SQL. Базовий курс. //Литера.

- 2006. - С. 25-250

5.https://uk.wikipedia.org/ - Вільна енциклопедія

56

ДОДАТКИЗВІТ

Про нараховану заробітну плату по робітниках

№_________від “____”________________________ __________ р.

№ з/п ПІБ працівника Загальна сума

57

ЗВІТПро нараховану заробітну плату по бригадах

№_________від “____”________________________ __________ р.

№ з/п Код бригади Загальна сума

58

59