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

ЗМІСТ

Вступ

Розділ 1. Встановлення вимог до програмного забезпечення з програм-аналогів для обраної предметної області

1.1 Українська онлайн-аптека “Пані Аптека”

1.2 Російська онлайн аптека «Piluli»

1.3 Канадська онлайн-аптека “Canadian Pharmacy”

1.4 Німецька онлайн-аптека “Apotheke online 24”

1.5 Основні вимоги до програмного забезпечення БД аптеки

Розділ 2. Специфікація вимог до програмного продукту

Розділ 3. Моделювання предметної області

3.1 Моделювання предметної області на логічному рівні

3.2 Моделювання предметної області на фізичному рівні

Розділ 4. Розробка програмного забезпечення згідно створених моделей предметної області

4.1 Організація редагування даних в інформаційній системі

4.2 Забезпечення обробки даних в інформаційній системі

4.3 Публікація результатів обробки даних інформаційної системи на паперових носіях чи в електронних документах

4.4 Публікація результатів обробки даних інформаційної системи в локальній та глобальній мережі

4.5 Засоби автоматизації управління системою

Розділ 5. Результати тестування програмного забезпечення

Розділ 6. Опис доповнень та нереалізованих можливостей

Висновки

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



ВСТУП

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

Розробленість теми роботи. Найпоширенішими інформаційними системами автоматизації аптечного обліку у наш час є, безумовно, 1С Бухгалтерія та Парус. Причому перша з них орієнтована на комерційні організації а друга - на державні. В цих системах аптечний облік розглядається як складова частина бухгалтерського обліку організації і тому вони здатні повністю автоматизувати фінансову складову діяльності. Поряд з цим, згадані системи не можуть повністю задовольнити інформаційні потреби, оскільки не містять різноманітних аналітичних та порівняльних форм і звітів. Ринок програмних продуктів пропонує також цілий ряд альтернативних систем (наприклад, X-Door), але такі розробки або мають вузьку спеціалізацію або також зорієнтовані на автоматизацію фінансової складової діяльності аптеки. Документації систем цього напрямку містять лише детальні вказівки стосовно їх експлуатації, але не розкривають структур розроблених моделей і не описують семантичні особливості створених БД. З іншого боку, в технічній та навчально-методичній літературі стосовно БД описано достатньо прикладів проектів та ІС гуртових складів (див., наприклад, [1, c. 50-127], [3, c.45-208]), але всі вони носять навчально-декларативний а не практичний характер. Саме тому в даній курсовій роботі описано спробу розробки нетривіальної інформаційно-логічної моделі БД та відповідної ІС практичного спрямування.

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

Завдання роботи випливають з поставленої мети:

- проаналізувати предметну область, наявні вхідні та вихідні документи та здійснити проектування на зовнішньому рівні БД аптеки;

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

- створити БД аптеки за допомогою СУБД MS Access, охарактеризувати структуру розроблених таблиць, обґрунтувати параметри кожного встановленого структурного зв'язка між таблицями;

- розробити форми для забезпечення редагування даних таблиць БД;

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

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

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

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

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

Об'єктом дослідження даної курсової роботи є аптека.

Предметом дослідження є проектування БД та створення ІС автоматизації обліку обігу препаратів аптеки.

Методи дослідження обумовлені об'єктом та предметом аналізу курсової роботи:

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

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

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

- при створенні інфологічної моделі та в процесі виконання проектування БД на даталогічному рівні був використаний метод моделювання.

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

Розділ 1. Встановлення вимог до програмного забезпечення з програм-аналогів для обраної предметної області

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

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

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

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

- Знаходження вимог

- Аналіз вимог

- Специфікація

- Тестування

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

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



1.1 Українська онлайн-аптека «Пані Аптека»

Адреса головної сторінки цієї електронної аптеки http://paniapteka.ua, а її вигляд наведено на рис. 1.1.

Рис. 1.1 Українська онлайн-аптека “Пані Аптека”

Дана аптека доставляє товари по всій Україні. Аптека пропонує асортимент не лише препаратів для людей, а й зоопрепаратів, медичних приладів, рецепти харчування тощо.

Переваги:

1. Зручний та зрозумілий інтерфейс;

2. Візуалізація товарів з допомогою відповідних зображень;

3. Відсутність реклами;

4. Легкий перехід між сторінками;

5. Легкий доступ до контактної інформації.

6. Можливість пошуку за ключовими словами;

7. Зручне редагування корзини.

Недоліки:

1. Відсутність відгуків про товари;

2. Одномовний інтерфейс.

1.2 Російська онлайн аптека «Piluli»

Адреса сайту: http://www.piluli.ru. Вигляд головної сторінки аптеки наведено на рис. 1.2.

Рис. 1.2 Російська онлайн-аптека «Piluli»

Російська онлайн-аптека має відносно зручний користувацький інтерфейс та великий асортимент товарів також пропонує безкоштовну доставку товарів по всій території Росії.

Переваги:

1. Можливість пошуку за ключовими словами;

2. Відсутність реклами;

3. Можливісь залишати та переглядати відгуки;

4. Зручне редагування корзини.

Недоліки:

1. Одномовний інтерфейс;

2. Незручна навігація по сайту;

3. Відсутність інформації про доставку;

4. Відсутність гарантії доставки товарів.



1.3 Канадська онлайн-аптека “Canadian Pharmacy”

Адреса сайту: http://pharmacysole.com. Вигляд головної сторінки аптеки наведено на рис. 1.3.

Рис. 1.3 Канадська онлайн-аптека “ Canadian Pharmacy ”

Канадська онлайн-аптека пропонує доставку товарів по всій території Канади.

Переваги:

1. Можливість зміни мови інтерфейсу;

2. Відсутність реклами;

3. Подання контактної інформації і термінів доставки;

4. Подання інформації про акційні товари на головній сторінці.

Недоліки:

1. Нема можливості реєструватись;

2. Немає можливості залишити відгук.

1.4 Німецька онлайн-аптека “Apotheke online 24”

Адреса сайту: http://www.apothekeonline24.com. Вигляд головної сторінки аптеки наведено на рис. 1.4.

Рис. 1.4 Німецька онлайн-аптека «Apotheke online 24»

Дана аптека пропонує безкоштовну доставку препаратів по всій території Німеччини.

Переваги:

1. Зручний інтерфейс;

2. Навігація по сайту зручна;

3. Наявність відгуків про препарати і магазину в цілому;

4. Візуалізація товарів;

5. Детальна інформація про доставку.

Недоліки:

1. Надмірність анімацій і переходів між сторінками;

2. Одномовний інтерфейс;

3. Мала кількість товарів;

4. Немає можливості пошуку.

1.5 Основні вимоги до програмного забезпечення БД аптеки

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

Таблиця 1.1

Дані порівняльного аналізу онлайн-аптек

Порівняльна ознака	Порядковий номер онлайн-магазину
	1	2	3	4
Зручний інтерфейс	+	-	-	+
Можливість пошуку	+	+	+	-
Багатомовність	-	-	+	-
Контактна інформація	+	+	+	+
Інформація про доставку	+	-	+	-
Відгуки про ліки	-	+	-	+
Широкий асортимент	+	+	+	-
Легке редагування корзини	+	+	-	-
Легка навігація	+	-	+	+
Реклама	+	-	+	-

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



Розділ 2. Специфікація вимог до програмного продукту

Призначення

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

Обсяг проекту і функції продукту

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

Посилання (інтернет-ресурси)

1. Українська онлайн-аптека «Аптека Пані»

2. Російська онлайн-аптека «Piluli»

3. Канадська онлайн-аптека “Canadian Pharmacy”

4. . Німецька онлайн-аптека “Apotheke online 24”

5. Накладна обігу препаратів (рис. 2.1).

Рис. 2.1 Типова накладна аптеки

Загальний опис

Перспективи продукту

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

Основні функції програмного продукту:

Експорт-імпорт даних;

Авторизація користувачів;

Розрахунок вартості замовлення та його оформлення;

Облік співробітників та їх закріплень за відділами;

Оформлення звітів;

Нарахування заробітної плати.

Класи користувачів та їх характеристики

Клас користувача	Характеристика користувача
Менеджер	Менеджер - це користувач, який керує базою постачальників, клієнтів та співробітників. Список можливостей: 1. Додавання інформації про нових клієнтів, співробітників, постачальників. 2. Редагування інформації. 3. Оформлення замовлень на продукцію.
Консультант	Консультант - це користувач, який володіє інформацією про особливості роботи VISA та на вимогу клієнта надає йому необхідну інформацію. Список можливостей: 1. Пошук запитуваної користувачем інформації в системі VISA. 2. Зв'язок з клієнтом. 3. Зв'язок з менеджером у випадку відсутності відповіді на запитувану інформацію.
Бухгалтер	Бухгалтер - це користувач, який відповідає за контроль над фінансовим обігом та за вчасне формування звітності. Список можливостей: 1. Нарахування заробітної плати. 2. Доступ до всіх грошових транзакцій.

Середовище функціонування

Програмний продукт є крос-платформеним, тому встановлюється і експлуатується в ОС Windows 2000 / XP / Vista / Win7 / Win8, а також в ОС сімейства Linux. Як сервер баз даних використовується Oracle, який може бути встановлений як на Windows, так і на Unix-подібних ОС.

Обмеження проектування та реалізації

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

2. Для забезпечення крос-платформеності основні сценарії повинні бути реалізовані на Java.

3. Інтерфейс та довідка програмного продукту повинні повністю підтримувати українську мову.

Документація користувача

1. Покрокова ілюстрована інструкція для встановлення програмного продукту на різних ОС.

2. Система повинна підтримувати ієрархічну систему довідки з доступом до мережі, яка описує та ілюструє всі функції системи.

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

4. Програмний продукт повинен через розумні проміжки часу повідомляти користувача про поточний стан системи.

Характеристики системи

ь Вхід в систему

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

Пріоритет - середній.

Послідовність «дія-відгук»

Дія: Користувач вводить необхідні дані, заповнюючи типову форму.

Відгук: Система надає доступ до певних даних.

Функціональні вимоги

1. Система повинна перевіряти, чи заповнені всі обов'язкові поля.

2. Система повинна перевіряти поля на коректність введених даних.

3. Система повинна співставляти введені дані з зареєстрованими в БД.

Введення нової інформації про постачальника, клієнта або співробітника

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

Пріоритет - високий.

Послідовність «дія-відгук»

Дія : Користувач вводить дані, використовуючи типовий інтерфейс.

Відгук: Система формує і додає новий запис до вже існуючої бази даних.

Функціональні вимоги

1. Система повинна перевіряти, чи заповнені всі обов'язкові поля.

2. Система повинна перевіряти поля на коректність введених даних.

Формування звітів

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

Пріоритет - середній.

Послідовність «дія-відгук»

Дія: Користувач вводить необхідний запит.

Відгук: Система повертає запитувану інформацію.

Функціональні вимоги

1. Система повинна перевіряти, чи заповнені всі обов'язкові поля.

2. Система повинна перевіряти поля на коректність введених даних.

3. Система повинна відображати статус виконуваної операції.



Вимоги зовнішніх інтерфейсів

Користувацькі інтерфейси

1. Система повинна забезпечувати посилання на довідку в кожному вікні програми для пояснення, як користуватися цим вікном.

2. Система повинна постійно відображати поточний статус системи.

3. Система повинна виділяти поля, обов'язкові для заповнення.

4. Система повинна перевіряти коректність введених даних.

5. Кожне вікно програми повинне відповідати єдиному стандарту стилю та вигляду.

Апаратні інтерфейси

1. Принтер для друку звітів.

2. Зчитувач штрих-кодів товарів.

Програмні інтерфейси

1. Експорт/імпорт даних між програмою та базою даних.

2. Зв'язок між програмою та онлайн-довідкою в браузері.

Комунікаційні інтерфейси

1. Синхронізований інтерфейс обміну електронними формами між програмою та СУБД.

2. Шифровані версії протоколів для передачі особистої інформації абонента та даних економічного характеру.

Нефункційні вимоги

Вимоги продуктивності

1. Система повинна обслуговувати багатьох користувачів в одиничний проміжок часу без втрат продуктивності.

2. Система повинна виводити користувачу повідомлення про підтвердження операції не більше ніж через 3 секунди після того, як користувач завершує її введення.

Вимоги надійності

1. Система повинна вести журнал обліку всіх операцій для запобігання втрат даних користувача.

2. Система повинна бути стійкою до збоїв зовнішніх систем (СУБД), повинен бути реалізований механізм відкату транзакцій.

Вимоги безпеки

1. Всі мережеві операції, що включають фінансову чи особисту інформацію, повинні бути зашифровані.

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

3. Система повинна оцінювати надійність паролю при створенні облікового запису та повідомляти користувача про це.

Атрибути якості програмного продукту

1. Система повинна надавати користувачу швидкий доступ до потрібних йому даних.

2. Система повинна мінімізувати ризики втрати даних.

3. Система повинна бути зрозумілою в користуванні для всіх груп користувачів.

Інші вимоги

Вимоги інтернаціоналізації

1. Система повинна забезпечити можливість вибору мови інтерфейсу для кожного користувача.

Вимоги бази даних

1. Система повинна дозволяти доступ до баз даних для внесення змін тільки менеджеру та бухгалтеру.

2. База даних повинна зберігати інформацію про історію покупок кожного зареєстрованого клієнта.



Розділ 3. Моделювання предметної області

3.1 Моделювання предметної області на логічному рівні

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

Вигляд логічної моделі аптеки продемонстровано на рис. 3.1.

Рис. 3.1 Зображення логічної моделі аптеки

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

1) Виробники виготовляють ліки, вказується упаковка після чого постачальники постачають ліки. Ліки групуються, обліковуються, вказуються після чого продаються співробітниками які в свою чергу переміщуються після чого вказується посада.

3.2 Моделювання предметної області на фізичному рівні

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

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

Вигляд фізичної моделі аптеки продемонстровано на рис. 3.2.

Рис. 3.2 Зображення фізичної моделі аптеки

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

Вигляд схеми даних аптеки продемонстровано на рис. 3.3.

Рис. 3.3 Зображення схеми даних аптеки

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

- атрибут Код співробітника в таблиці Співробітники містить унікальний внутрішній ідентифікаційний номер кожного співробітника, в таблиці Відомості про переміщення цей самий атрибут містить код того співробітника, що переміщався, в таблиці Постачання - Код співробітника, що приймав замовлення, а в таблиці Продажі - Код співробітника, що продав ліки;

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

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

Дані про ліки в БД також зберігаються в двох таблицях: Групи Ліків та Довідник Аптекаря. Перша з них зберігає дані про групу ліків а друга містить відомості про ліки. Між таблицями Групи Ліків та Довідник Аптекаря встановлено співвідношення 1:?, оскільки до одної групи може відноситися багато назв.

Дані про продажі в БД також зберігаються в двох таблицях: Продажі та Що продається. Перша з них зберігає дані про сам факт продажі а друга містить відомості про ліки. Між таблицями Продажі та Що продається встановлено співвідношення 1:?, оскільки до одної продажі може відноситися багато ліків.

Між таблицями Посади і Відомості про переміщення встановлено співвідношення 1:?, оскільки одна посада може містити багато співробітників.

Таблиці Відомості про переміщення і Співробітники мають співвідношення 1:?, оскільки один співробітник може переміщатися багато раз.

Між таблицями Співробітники і Продажі, 1:?, оскільки один клієнт може продавати багато ліків.

Між таблицями Поставки і Виробники встановлено співвідношення 1:?, оскільки виробник може виробляти багато ліків.

Між таблицями Постачальники і Постачання встановлено співвідношення 1:?, оскільки постачальник може постачати багато ліків.

Таблиці Постачання і Поставки мають співвідношення 1:?, оскільки

постачання може поставлятися багато разів.

Для створення ІС згідно розробленого проекту БД нами було обрано СУБД MS Access, оскільки вона дозволяє:

- розробляти нескладні додатки обробки БД в інтерактивному режимі без створення програмного коду;

- ефективно модифікувати створені об'єкти в режимі конструктора;

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

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

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

Недоліки СУБД MS Access пов'язані з проблемами надійного захисту даних та продуктивної одночасної роботи з ІС багатьох користувачів. Але для ІС гуртового складу вони не мають особливого значення, оскільки з такою системою працює обмежене коло співробітників з декількох осіб.

Таблиці ІС розроблені згідно інформаційно-логічної моделі БД (див. рис. 3.1). Розглянемо структуру кожної таблиці:

Таблиця

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

Ім'я поля	Тип даних	Розмір поля	Підпис
Код співробітника	Лічильник	Довге ціле	Співробітник
Фамілія	Текстове	50	Фамілія
Ім'я	Текстове	25	Ім'я
По-батькові	Текстове	50	По-батькові
Адреса	Текстове	50	Адреса
Дата народження	Дата\Час		Дата народження
Оклад	Числове	Довге ціле	Оклад



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

Ім'я поля	Властивість	Значення	Призначення
Код співробітника	Нове значення	Послідовне	Забезпечує послідовну нумерацію записів таблиці
	Індексоване поле	Да (збіг не допускаються)	Забезпечує швидкий пошук, сортування та фільтрування по значенню поля

Таблиця

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

Ім'я поля	Тип даних	Розмір поля	Підпис
Номер запису	Лічильник	Довге ціле	Номер запису
Код співробітника	Числове	Довге ціле	Співробітник
КодПосади	Числове	Довге ціле	Посада
Дата постанови	Дата\Час		Дата постанови
Номер постанови	Числове	Довге ціле	Номер постанови
Підстави	Текстове	100	Підстави
Причина переводу	Текстове	100	Причина переводу
Період з	Дата\Час		Період з
по	Дата\Час		по

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

Ім'я поля	Властивість	Значення	Призначення
Номер запису	Нове значення	Послідовне	Забезпечує послідовну нумерацію записів таблиці
	Індексоване поле	Да (збіг не допускаються)	Забезпечує швидкий пошук, сортування та фільтрування по значенню поля

Таблиця

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

Ім'я поля	Тип даних	Розмір поля	Підпис
Код посади	Лічильник	Довге ціле	Посада
Посада	Текстове	40	Посада



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

Ім'я поля	Властивість	Значення	Призначення
Код посади	Нове значення	Послідовне	Забезпечує послідовну нумерацію записів таблиці
	Індексоване поле	Да (збіг не допускаються)	Забезпечує швидкий пошук, сортування та фільтрування по значенню поля

Таблиця

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

Ім'я поля	Тип даних	Розмір поля	Підпис
Код Поставки	Лічильник	Довге ціле	Поставки
Код лікарського засобу	Числове	Довге ціле	Лікарський засіб
Код Упаковки	Числове	Довге ціле	Упаковка
Код виробника	Числове	Довге ціле	Виробник
Ціна закупки	Числове	Довге ціле	Ціна закупки
Код постачання	Числове	Довге ціле	Постачання
Кількість	Числове	Довге ціле	Кількість

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

Ім'я поля	Властивість	Значення	Призначення
КодПоставки	Нове значення	Послідовне	Забезпечує послідовну нумерацію записів таблиці
	Індексоване поле	Да (збіг не допускаються)	Забезпечує швидкий пошук, сортування та фільтрування по значенню поля

Таблиця

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

Ім'я поля	Тип даних	Розмір поля	Підпис
Код виробника	Лічильник	Довге ціле	Виробник
Назва виробника	Текстове	40	Виробник
Індекс	Числове	Довге ціле	Індекс
Країна	Текстове	40	Країна
Місто	Текстове	40	Місто
Адреса	Текстове	50	Адреса

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

Ім'я поля	Властивість	Значення	Призначення
Код виробника	Нове значення	Послідовне	Забезпечує послідовну нумерацію записів таблиці
	Індексоване поле	Да (збіг не допускаються)	Забезпечує швидкий пошук, сортування та фільтрування по значенню поля

Таблиця

Що продається має наступну структуру, розміри полів та підписи:

Ім'я поля	Тип даних	Розмір поля	Підпис
Номер запису	Лічильник	Довге ціле	Номер запису
Код продажу	Числове	Довге ціле	Продаж
КодПоставки	Числове	Довге ціле	Поставка
Кількість	Числове	Довге ціле	Кількість
Код лікарського засобу	Числове	Довге ціле	Лікарський засіб
Ціна реалізації	Числове	Довге ціле	Ціна реалізації

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

Ім'я поля	Властивість	Значення	Призначення
Номер запису	Нове значення	Послідовне	Забезпечує послідовну нумерацію записів таблиці
	Індексоване поле	Да (збіг не допускаються)	Забезпечує швидкий пошук, сортування та фільтрування по значенню поля

Таблиця

Продажі має наступну структуру, розміри полів та підписи:

Ім'я поля	Тип даних	Розмір поля	Підпис
Код продажу	Лічильник	Довге ціле	Продаж
Дата	Дата\Час		Дата
Час	Дата\Час		Час
Скидка	Числове	Довге ціле	Скидка
Код співробітника	Числове	Довге ціле	Співробітник
Оплачено	Числове	Довге ціле	Оплачено

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

Ім'я поля	Властивість	Значення	Призначення
Код продажу	Нове значення	Послідовне	Забезпечує послідовну нумерацію записів таблиці
	Індексоване поле	Да (збіг не допускаються)	Забезпечує швидкий пошук, сортування та фільтрування по значенню поля

Таблиця

Постачальники має наступну структуру, розміри полів та підписи:

Ім'я поля	Тип даних	Розмір поля	Підпис
Код постачальника	Лічильник	Довге ціле	Постачальник
Назва	Текстове	40	Назва
Телефон	Числове	Довге ціле	Телефон
Дата реєстрації	Дата\Час		Дата реєстрації

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

Ім'я поля	Властивість	Значення	Призначення
Код постачальника	Нове значення	Послідовне	Забезпечує послідовну нумерацію записів таблиці
	Індексоване поле	Да (збіг не допускаються)	Забезпечує швидкий пошук, сортування та фільтрування по значенню поля

Таблиця

Постачання має наступну структуру, розміри полів та підписи:

Ім'я поля	Тип даних	Розмір поля	Підпис
Код постачання	Лічильник	Довге ціле	Постачання
Код постачальника	Числове	Довге ціле	Постачальник
Код співробітника	Числове	Довге ціле	Співробітник
Дата постачання	Дата\Час		Дата постачання

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



Ім'я поля	Властивість	Значення	Призначення
Код постачальника	Нове значення	Послідовне	Забезпечує послідовну нумерацію записів таблиці
	Індексоване поле	Да (збіг не допускаються)	Забезпечує швидкий пошук, сортування та фільтрування по значенню поля

Таблиця

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

Ім'я поля	Тип даних	Розмір поля	Підпис
Код лікарського засобу	Лічильник	Довге ціле	Лікарський засіб
Назва	Текстове	50	Назва
КодГрупиЛіків	Числове	Довге ціле	Група ліків

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

Ім'я поля	Властивість	Значення	Призначення
Код лікарського засобу	Нове значення	Послідовне	Забезпечує послідовну нумерацію записів таблиці
	Індексоване поле	Да (збіг не допускаються)	Забезпечує швидкий пошук, сортування та фільтрування по значенню поля

Таблиця

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

Ім'я поля	Тип даних	Розмір поля	Підпис
Код лікарського засобу	Лічильник	Довге ціле	Лікарський засіб
Дата	Дата\Час		Дата
Наявність на початок дня	Числове	Довге ціле	Наявність на початок дня

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

Ім'я поля	Властивість	Значення	Призначення
Код лікарського засобу	Нове значення	Послідовне	Забезпечує послідовну нумерацію записів таблиці
	Індексоване поле	Да (збіг не допускаються)	Забезпечує швидкий пошук, сортування та фільтрування по значенню поля



Таблиця

Упаковка має наступну структуру, розміри полів та підписи:

Ім'я поля	Тип даних	Розмір поля	Підпис
КодУпаковки	Лічильник	Довге ціле	Формаупаковки
Форма упаковки	Текстове	50	Форма упаковки

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

Ім'я поля	Властивість	Значення	Призначення
КодУпаковки	Нове значення	Послідовне	Забезпечує послідовну нумерацію записів таблиці
	Індексоване поле	Да (збіг не допускаються)	Забезпечує швидкий пошук, сортування та фільтрування по значенню поля

Таблиця

Групи ліків має наступну структуру, розміри полів та підписи:

Ім'я поля	Тип даних	Розмір поля	Підпис
КодГрупиЛіків	Лічильник	Довге ціле	Фармакотерапевтична група
Фармакотерапевтична група	Текстове	50	Фармакотерапевтична група

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

Ім'я поля	Властивість	Значення	Призначення
КодУпаковки	Нове значення	Послідовне	Забезпечує послідовну нумерацію записів таблиці
	Індексоване поле	Да (збіг не допускаються)	Забезпечує швидкий пошук та сортування

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

Розділ 4. Розробка програмного забезпечення згідно створених моделей предметної області

4.1 Організація редагування даних в інформаційній системі

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

Рис. 4.1 Вигляд форми Співробітники в режимі форми

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

Для редагування даних таблиці Виробники розроблено форму з аналогічною назвою (рис. 4.2)

Рис. 4.2 Вигляд форми Виробники в режимі форми

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

Для редагування даних таблиці Постачальники розроблено форму з аналогічною назвою (рис. 4.3)

Ри...