Розробка автоматизованого обліку та руху товарів на складах засобами СУБД Microsoft Access (стр. 2 из 4)

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

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

2.1 Інфологічна модель

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

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

Атрибут - пойменована характеристика суті. Його найменування повинне бути унікальним для конкретного типу суті, але може бути однаковим для різного типу суті (наприклад, колір може бути визначений для багатьох сутей: кіт, автомобіль, сукня і т.д.). Атрибути використовуються для визначення того, яка інформація повинна бути зібрана про суть. Прикладами атрибутів для суті автомобіль є тип, модель, номерний знак, колір і т.д. Тут також існує відмінність між типом і екземпляром. Тип атрибуту колір має багато екземплярів або значень проте кожному екземпляру суті привласнюється тільки одне значення атрибуту.

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

Ключ - мінімальний набір атрибутів, по значеннях яких можна однозначно знайти необхідний екземпляр суті. Мінімальність означає, що виключення з набору будь-якого атрибуту не дозволяє ідентифікувати суть по тих, що залишилися. Для суті Розклад ключем є атрибут Номер_рейса або набір: Пункт_відправлення. Час_вильоту і Пункт_призначення (за умови, що з пункту в пункт вилітає в кожен момент часу один літак).

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

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

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

2.2 Обґрунтування вибору інструментального засобу проектування

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

Microsoft Access в даний час є однією з найпопулярніших серед настільних (персональних) програмних систем управління базами даних. Серед причин такої популярності слід зазначити:

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

• глибоко розвинені можливості інтеграції з іншими програмними продуктами, що входять до складу Microsoft Office, а також з будь-якими програмними продуктами, що підтримують технологію OLE;

• багатий набір візуальних засобів розробки.

Не можна не відзначити, що істотною причиною такого широкого розповсюдження MS Access є і могутня рекламна підтримка, здійснювана фірмою Microsoft. В процесі розробки даного продукту на ринок представлялися його різні версії. Найбільш відомими стали Access 2.0, Access 7.0 (він вперше був включений до складу програмного комплексу MS Office 95). Пізніше з'явилися версії Access 97 (у складі MS Office 97) і Access 2000 (у складі MS Office 2000). Очевидно, що відправною крапкою в процесі роботи з будь-якою СУБД є створення файлу (або групи файлів) бази даних. На мал. 1 показано вікно, яке з'являється після створення нової бази.

Мал. 1. Головне вікно бази даних в Access

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

Інтерфейс роботи з об'єктами бази даних уніфікований. По кожному з них передбачені стандартні режими роботи:

• Створити — призначений для створення структури об'єктів;

• Конструктор — призначений для зміни структури об'єктів;

• Відкрити (Перегляд. Запуск) — призначений для роботи з об'єктами бази даних.

Важливим засобом, що полегшує роботу з Access для користувачів, що починають, є майстри — спеціальні програмні надбудови, призначені для створення об'єктів бази даних в режимі послідовного діалогу. Для досвідчених і просунутих користувачів існують можливості гнучкішого управління ресурсами і можливостями об'єктів СУБД в режимі конструктора. Специфічною особливістю СУБД Access є те, що вся інформація, що відноситься до однієї бази даних, зберігається в єдиному файлі. Такий файл має розширення *.mdb. Дане рішення, як правило, зручно для непрофесійних користувачів, оскільки забезпечує простоту при перенесенні даних з одного робочого місця на інше. Внутрішня організація даних в рамках mdb-формату мінялася від версії до версії, але фірма Microsoft підтримувала їх сумісність від низу до верху, тобто бази даних з файлів у форматі ранніх версій Access можуть бути конвертовані у формат, використовуваний у версіях пізніших.

Розділ 3. Розробка автоматизованого обліку та руху товарів на складах засобами СУБД Microsoft Access

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

• розробка і опис структур таблиць даних;

• розробка схеми даних і завдання системи взаємозв'язків між

• таблицями:

• розробка системи запитів до таблиць бази даних і (при необхідності) їх інтеграція в схему даних;

• розробка екранних форм введення/висновку даних;

• розробка системи звітів по даним;

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

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

Очевидно, що між перерахованими етапами існує велика кількість зворотних зв'язків, повернення до перших кроків, виходячи з обставин, що знов відкрилися, які неможливо було наперед врахувати або передбачати.

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