Створення інформаційної моделі

Введення

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

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

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

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

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

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

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

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

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

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

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

Аналіз даних: збір основних даних (наприклад, об'єкти, зв'язки між об'єктами).

Визначимо початкові дані:

Заявки - що надходять від магазинів на певний період.

Договору - укладаються з постачальниками на певний вид товару.

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

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

Рахунки - ведуться на етапі укладання договору з постачальниками, а також із замовниками.

Накладні - створюються на підставі отримання замовлення про замовника, для відвантаження.

Довідки - отримання/видача різних довідок як замовникові так і постачальника.

Товар - присутній на підставі заявки і договору з постачальником.

Визначення взаємозв'язків.

Взаємозв'язок висловлює відображення або зв'язок між двома множинами даних. Розрізняють взаємозв'язку типу "один до одного", "один до багатьох" і "багато до багатьох".

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

Наступний що представляє для нас інтерес об'єкт - Товар. Цей об'єкт має властивості "унікальний ключ товару", "найменування товару".

Другий даний об'єкт - Постачальник. Його властивостями є "унікальний ключ постачальника", "найменування постачальника".

Третій даний об'єкт - Замовник. Його властивостями є "унікальний ключ замовника", "найменування замовника".

Взаємозв'язок "один до одного" (між двома типами об'єктів)

Припустимо, у певний момент часу один замовник може зробити тільки одне замовлення. У цьому випадку між об'єктами Замовник і Товар встановлюється взаємозв'язок "один до одного".

Взаємозв'язок "один до багатьох" (між двома типами об'єктів)

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

Взаємозв'язок "один до одного" (між двома властивостями)

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

Взаємозв'язок "один до багатьох" (між двома властивостями)

Назва постачальника і його номер існують спільно. Постачальників з однаковими іменами може бути багато, але всі вони мають різні номери. Кожному постачальнику присвоюється унікальний номер. Це означає, що даному номеру постачальника відповідає тільки одне ім'я. Взаємозв'язок "один до багатьох" позначається подвійною стрілкою в напрямку до "одному" і подвійний стрілкою у напрямку до "багатьом".

Завдання первинних і альтернативних ключів, визначення властивостей об'єктів

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

Властивості, що включаються до складу БД для даної моделі, наведено в табл.1.

Таблиця 1. Властивості та первинні ключі об'єктів інформаційної моделі.

Об'єкт

Первинний ключ

Властивості

ТОВАР

Унікальний ключ товару

Найменування товару

ЗАМОВНИК

Унікальний ключ замовника

Найменування замовника

Юридична приналежність

П.І.Б. керівника

Адреса

Телефон/факс

Найменування товару

Кількість товару

Передбачувана ціна

ПОСТАЧАЛЬНИК

Унікальний ключ постачальника

Найменування постачальника

Юридична приналежність

П.І.Б. керівника

Адреса

Телефон/факс

Найменування товару

Кількість товару

Дата виготовлення

Акцизна марка

Розшифровка штрих-коду

Термін придатності

Вага Брутто

Вага Нетто

Ціна за одиницю

Сумарна ціна

Вид упаковки

Спосіб доставки

РАХУНКУ

Номер рахунку

Дата продажу

Найменування постачальника

Адреса постачальника

Юридична приналежність п.

Найменування замовника

Адреса замовника

Юридична приналежність з.

Найменування товару

Кількість товару

Сума

ПДВ

Сума до оплати

ДОГОВІР

Номер договору

Дата укладення

Номер рахунку

Найменування постачальника

Адреса постачальника

Юридична приналежність

Найменування товару

Кількість товару

Сума

ПДВ

НАКЛАДНІ

Номер накладної

Дата накладної

Позначка про оплату

Номер рахунку

Найменування замовника

Адреса замовника

Юридична приналежність

Найменування товару

Кількість товару

Сума

ПДВ

Приведення моделі до необхідного 1 рівню нормальної форми

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

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

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

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

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

Транзитивне залежність виявляє дублювання даних в одному відношенні. Якщо А, В і С - три властивості одного відносини і С залежить від В, а В від А, то говорять, що С транзитивній залежить від А. Перетворення в третю нормальну форму відбувається за рахунок розділення вихідного відносини на два.

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

Об'єкт

Первинний ключ

Властивості

ТОВАР

Унікальний ключ товару

Унікальний ключ постачальника

Унікальний ключ замовника

Найменування товару

Дата виготовлення

Акцизна марка

Розшифровка штрих-коду

Термін придатності

Вага Брутто

Вага Нетто

Ціна за одиницю

Сумарна ціна

Вид упаковки

ЗАМОВНИК

Унікальний ключ замовника

Найменування замовника

Юридична приналежність

П.І.Б. керівника

Адреса

Телефон/факс

Передбачувана ціна

ПОСТАЧАЛЬНИК

Унікальний ключ постачальника

Найменування постачальника

Юридична приналежність

П.І.Б. керівника

Адреса

Телефон/факс

РАХУНКУ

Номер рахунку

Дата продажу

Унікальний ключ товару

ПДВ

Сума до оплати

ДОГОВІР

Номер договору

Дата укладення

Унікальний ключ постачальника

НАКЛАДНІ

Номер накладної

Унікальний ключ замовника

Позначка про оплату

Дата накладної

Таблична з певними зв'язками, остаточна концептуальна модель.

ТОВАР

Унік. ключ постачальника

Унік. ключ замовника

Найменування товару

Дата виготовлення

Акцизна марка

Расшіф. Штрих-код

ЗАМОВНИК

Термін придатності

ПОСТАЧАЛЬНИК

Унік. ключ замовника

Вага Брутто

Унік. ключ постачальника

найменш. Замовника

Вага Нетто

найменш. постачальника

Юрид-ська. принади.

Ціна за одиницю

Юрид-ська. принади.

П.І.Б. керівника

Сумарна ціна

П.І.Б. керівника

Адреса

Вид упаковки

Адреса

Телефон/факс

Унік. ключ товару

Телефон/факс

Передбачувана ціна

Номер договору

Номер накладної = "Times New Roman">

Дата укладення

Позначка про оплату

Дата накладної

РАХУНКУ

Унік. ключ товару

Номер рахунку

Дата продажу

ПДВ

Сума до оплати

Концептуальна модель переноситься потім в модель даних, сумісну з вибраної СУБД. Можливо, що відображені в концептуальної моделі взаємозв'язку між об'єктами виявляться згодом нереалізованим засобами вибраної СУБД. Це потребує зміни концептуальної моделі. Версія концептуальної моделі, яка може?? ыть забезпечена певної БД, називається логічною моделлю.

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

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

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

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

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

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

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

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

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

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

Таблиця 3. Проект таблиці для фізичної моделі.

№ п/п

Найменування поля

Примітка

ТОВАР

Key_tovar

Унікальний ключ товару

Key_postav

Унікальний ключ постачальника

Key_zakaz

Унікальний ключ замовника

Name_tovar

Найменування товару

Date

Дата виготовлення

Marka

Акцизна марка

Kod

Розшифровка штрих-коду

Srok_god

Термін придатності

Ves_b

Вага Брутто

10.

Ves_n

Вага Нетто

11.

Cena_1

Ціна за одиницю

12.

Cena

Сумарна ціна

13.

Upakovka

Вид упаковки

ЗАМОВНИК

Key_zakaz

Унікальний ключ замовника

Name_zakaz

Найменування замовника

Yrid_zakaz

Юридична приналежність

FIO_zakaz

П.І.Б. керівника

Adres_zakaz

Адреса

Tel_zakaz

Телефон/факс

Cena_z

Передбачувана ціна

Number_N

Номер накладної

Oplata

Позначка про оплату

10.

Date_N

Дата накладної

ПОСТАЧАЛЬНИК

Key_poctav

Унікальний ключ постачальника

Name_postav

Найменування постачальника

Yrid_poctav

Юридична приналежність

FIO_postav

П.І.Б. керівника

Adres_postav

Адреса

Tel_postav

Телефон/факс

Number_D

Номер договору

Date_Z

Дата укладення

РАХУНКУ

Number_S

Номер рахунку

Date_P

Дата продажу

Key_tovar

Унікальний ключ товару

NDS

ПДВ

Summa

Сума до оплати

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

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

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

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

Таблиця 4. Таблиця індексного файлу "ТОВАР" для індексних-послідовного методу доступу.

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

Індексний файл

Блок 7

Значення Ключа

Номер Блоку

Файл даних Блок 1

Індексний файл

Блок 10

Блок 2

Значення

Номер

Ключа

Блоку

Блок 3

Блок 8

Індекс 2-го рівня

Значення

Номер

Ключа

Блоку

Блок 4

Блок 5

Блок 9

Значення

Номер

Ключа

Блоку

Блок 6

Індекс 1-го рівня

Форма "ГОЛОВНА кнопочна форма"

Option Compare Database

Option Explicit

Private Sub Form_Open (Cancel As Integer)

'Згортання вікна бази даних, ініціалізація форми.

'Перехід на сторінку кнопкової форми, зазначену для використання за замовчуванням.

Me.Filter = "[ItemNumber] = 0 AND [Argument] = 'за замовчуванням'"

Me.FilterOn = True

End Sub

Private Sub Form_Current ()

'Оновлення заголовка та заповнення списку команд.

Me.Caption = Nz (Me! [ItemText], "")

FillOptions

End Sub

Private Sub FillOptions ()

'Заповнення команд для сторінки кнопкової форми.

'Число кнопок у формі.

Const conNumButtons = 8

Dim dbs As Database

Dim rst As Recordset

Dim strSQL As String

Dim intOption As Integer

'Установка фокуса на першу кнопку форми, приховування всіх кнопок форми, крім першого.

'Поле з фокусом приховати не можна.

Me! [Option1]. SetFocus

For intOption = 2 To conNumButtons

Me ( "Option" & intOption). Visible = False

Me ( "OptionLabel" & intOption). Visible = False

Next intOption

'Відкриття таб. елементів кнопкової форми, пошук першого елемента поточної сторінки форми.

Set dbs = CurrentDb ()

strSQL = "SELECT * FROM [Елементи кнопкової форми]"

strSQL = strSQL & "WHERE [ItemNumber]> 0 AND [SwitchboardID] =" & Me! [SwitchboardID]

strSQL = strSQL & "ORDER BY [ItemNumber];"

Set rst = dbs.OpenRecordset (strSQL)

'Вивід повідомлення за відсутності елементів на сторінці кнопкової форми.

'В інших випадках - заповнення сторінки елементами.

If (rst.EOF) Then

Me! [OptionLabel1]. Caption = "Елементи кнопкової форми відсутні"

Else

While (Not (rst.EOF))

Me ( "Option" & rst! [ItemNumber]). Visible = True

Me ( "OptionLabel" & rst! [ItemNumber]). Visible = True

Me ( "OptionLabel" & rst! [ItemNumber]). Caption = rst! [ItemText]

rst.MoveNext

Wend

End If

'Закриття набору записів і бази даних.

rst.Close

dbs.Close

End Sub

Private Function HandleButtonClick (intBtn As Integer)

'Ця функ. викликається при натисканні кнопки. Аргумент intBtn вказує, яка кнопка була натиснута.

'Константи для виконуваних команд.

Const conCmdGotoSwitchboard = 1

Const conCmdOpenFormAdd = 2

Const conCmdOpenFormBrowse = 3

Const conCmdOpenReport = 4

Const conCmdCustomizeSwitchboard = 5

Const conCmdExitApplication = 6

Const conCmdRunMacro = 7

Const conCmdRunCode = 8

'Особлива помилка.

Const conErrDoCmdCancelled = 2501

Dim dbs As Database

Dim rst As Recordset

On Error GoTo HandleButtonClick_Err

'Пошук запису, що відповідає натиснутій кнопці, у таблиці елементів кнопкової форми.

Set dbs = CurrentDb ()

Set rst = dbs.OpenRecordset ( "Елементи кнопкової форми", dbOpenDynaset)

rst.FindFirst "[SwitchboardID] =" & Me! [SwitchboardID] & "AND [ItemNumber] =" & intBtn

'Якщо потрібна запис не знайдено, висновок про помилку, а вихід з функції.

If (rst.NoMatch) Then

MsgBox "Помилка при читанні таблиці елементів кнопкової форми."

rst.Close

dbs.Close

Exit Function

End If

Select Case rst! [Command]

'Перехід до іншої кнопкової формі.

Case conCmdGotoSwitchboard

Me.Filter = "[ItemNumber] = 0 AND [SwitchboardID] =" & rst! [Argument]

'Відкриття форми в режимі додавання записів.

Case conCmdOpenFormAdd

DoCmd.OpenForm rst! [Argument],,,, acAdd

'Відкриття форми.

Case conCmdOpenFormBrowse

DoCmd.OpenForm rst! [Argument]

'Відкриття звіту.

Case conCmdOpenReport

DoCmd.OpenReport rst! [Argument], acPreview

'Налаштування кнопкової форми.

Case conCmdCustomizeSwitchboard

'Обробка ситуації, коли диспетчер

'кнопкових форм не встановлено

'(наприклад, при скороченому встановлення).

On Error Resume Next

Application.Run "WZMAIN80.sbm_Entry"

If (Err <> 0) Then MsgBox "Команда недоступна."

On Error GoTo 0

'Оновлення форми.

Me.Filter = "[ItemNumber] = 0 AND [Argument] = 'за замовчуванням'"

Me.Caption = Nz (Me! [ItemText], "")

FillOptions

'Вихід з програми.

Case conCmdExitApplication

CloseCurrentDatabase

'Запуск макросу.

Case conCmdRunMacro

DoCmd.RunMacro rst! [Argument]

'Виконання програми.

Case conCmdRunCode

Application.Run rst! [Argument]

'Інші команди не підтримуються.

Case Else

MsgBox "Невідома команда."

End Select

'Закриття набору записів і бази даних.

rst.Close

dbs.Close

HandleButtonClick_Exit:

Exit Function

HandleButtonClick_Err:

'Якщо виконання перервано користувачем, повідомлення про помилку не виводиться.

'Замість цього виконання продовжується з наступного рядка.

If (Err = conErrDoCmdCancelled) Then

Resume Next

Else

MsgBox "Помилка при виконанні команди.", vbCritical

Resume HandleButtonClick_Exit

End If

End Function

Форма "ЗАМОВНИК"

Option Compare Database

Option Explicit

Private Sub Кнопка18_Click ()

On Error GoTo Err_Кнопка18_Click

DoCmd.DoMenuItem acFormBar, acEditMenu, 8,, acMenuVer70

DoCmd.DoMenuItem acFormBar, acEditMenu, 6,, acMenuVer70

Exit_Кнопка18_Click:

Exit Sub

Err_Кнопка18_Click:

MsgBox Err.Description

Resume Exit_Кнопка18_Click

End Sub

Private Sub Кнопка20_Click ()

On Error GoTo Err_Кнопка20_Click

Dim stDocName As String

stDocName = "Запрос2"

DoCmd.OpenReport stDocName, acPreview

Exit_Кнопка20_Click:

Exit Sub

Err_Кнопка20_Click:

MsgBox Err.Description

Resume Exit_Кнопка20_Click

End Sub

Private Sub Кнопка33_Click ()

On Error GoTo Err_Кнопка33_Click

Dim stDocName As String

Dim stLinkCriteria As String

stDocName = "Товари"

DoCmd.OpenForm stDocName,,, stLinkCriteria

Exit_Кнопка33_Click:

Exit Sub

Err_Кнопка33_Click:

MsgBox Err.Description

Resume Exit_Кнопка33_Click

End Sub

Sub ПолеСоСпіском34_AfterUpdate ()

'Пошук запису, що відповідає цьому елементу управління.

Me.RecordsetClone.FindFirst "[Name_zakaz] = '" & Me! [ПолеСоСпіском34] & "'"

Me.Bookmark = Me.RecordsetClone.Bookmark

End Sub

Форма "ПОСТАЧАЛЬНИК"

Option Compare Database

Option Explicit

Private Sub Кнопка18_Click ()

On Error GoTo Err_Кнопка18_Click

DoCmd.DoMenuItem acFormBar, acEditMenu, 8,, acMenuVer70

DoCmd.DoMenuItem acFormBar, acEditMenu, 6,, acMenuVer70

Exit_Кнопка18_Click:

Exit Sub

Err_Кнопка18_Click:

MsgBox Err.Description

Resume Exit_Кнопка18_Click

End Sub

Private Sub Кнопка20_Click ()

On Error GoTo Err_Кнопка20_Click

Dim stDocName As String

stDocName = "Запрос1"

DoCmd.OpenReport stDocName, acPreview

Exit_Кнопка20_Click:

Exit Sub

Err_Кнопка20_Click:

MsgBox Err.Description

Resume Exit_Кнопка20_Click

End Sub

Форма "ТОВАР"

Option Compare Database

Option Explicit

Sub ПолеСоСпіском18_AfterUpdate ()

'Пошук запису, що відповідає цьому елементу управління.

Me.RecordsetClone.FindFirst "[Name_tovar] = '" & Me! [ПолеСоСпіском18] & "'"

Me.Bookmark = Me.RecordsetClone.Bookmark

End Sub

Private Sub Кнопка25_Click ()

On Error GoTo Err_Кнопка25_Click

DoCmd.Close

Exit_Кнопка25_Click:

Exit Sub

Err_Кнопка25_Click:

MsgBox Err.Description

Resume Exit_Кнопка25_Click

End Sub

Форма "ПРО ПРОГРАМУ"

Option Compare Database 'Сортування даних бази для порівняння рядків.

Option Explicit 'Обов'язкове опис змінних перед застосуванням.

Private Sub Отмена_Click ()

'Програма, створена майстром кнопок.

On Error GoTo Err_Cancel_Click

'Закриття форми.

DoCmd.Close

Exit_Cancel_Click:

Exit Sub

Err_Cancel_Click:

MsgBox Err.Description

Resume Exit_Cancel_Click

End Sub

Private Sub ОК_Click ()

On Error GoTo Err_OK_Click

Dim strMsg As String, strTitle As String

Dim intStyle As Integer

'Якщо звіт про продажі по роках не було відкрито для перегляду або друку, виникає помилка.

'(Перем. blnOpening має значення True, тільки якщо для звіту сталася подія Open.)

If Not Reports! [Дата]. blnOpening Then Err.Raise 0

'Приховування форми.

Me.Visible = False

Exit_OK_Click:

Exit Sub

Err_OK_Click:

strMsg = "Для використання форми потрібно переглядати або друкувати звіт 'Продажі по роках' з вікна бази даних або конструктора."

intStyle = vbOKOnly

strTitle = "Відкриття зі звіту"

MsgBox strMsg, intStyle, strTitle

Resume Exit_OK_Click

End Sub

Private Sub Кнопка5_Click ()

On Error GoTo Err_Кнопка5_Click

DoCmd.Close

Exit_Кнопка5_Click:

Exit Sub

Err_Кнопка5_Click:

MsgBox Err.Description

Resume Exit_Кнопка5_Click

End Sub

Форма "підлеглі форми ТОВАРУ"

Option Compare Database

Option Explicit

Private Sub Кнопка22_Click ()

On Error GoTo Err_Кнопка22_Click

DoCmd.DoMenuItem acFormBar, acEditMenu, 8,, acMenuVer70

DoCmd.DoMenuItem acFormBar, acEditMenu, 6,, acMenuVer70

Exit_Кнопка22_Click:

Exit Sub

Err_Кнопка22_Click:

MsgBox Err.Description

Resume Exit_Кнопка22_Click

End Sub

Private Sub Кнопка23_Click ()

On Error GoTo Err_Кнопка23_Click

DoCmd.DoMenuItem acFormBar, acEditMenu, 8,, acMenuVer70

DoCmd.DoMenuItem acFormBar, acEditMenu, 6,, acMenuVer70

Exit_Кнопка23_Click:

Exit Sub

Err_Кнопка23_Click:

MsgBox Err.Description

Resume Exit_Кнопка23_Click

End Sub

ЗАПРОС1

SELECT Товари.Name_tovar, Sum (Товари.Cena) AS Sum_Cena, Поставщік.Name_postav, Поставщік.Number_D, Поставщік.Date_Z

FROM Постачальник INNER JOIN Товари ON Поставщік.Key_postav = Товари.Key_tovar

WHERE (((Поставщік.Name_postav) = [Forms]! [Постачальник]! [Name_postav]))

GROUP BY Товари.Name_tovar, Поставщік.Name_postav, Поставщік.Number_D, Поставщік.Date_Z;

ЗАПРОС2

SELECT Заказчік.Name_zakaz, Заказчік.Adres_zakaz, Заказчік.Number_N, Заказчік.Date_N, Товари.Name_tovar, Товари.Srok_god, Товари.Ves_b, Товари.Ves_n, Товари.Cena, Товари.Date

FROM [Замовник] INNER JOIN Товари ON Заказчік.Name_tov = Товари.Name_tovar

WHERE (((Заказчік.Name_tov) = [Forms]! [Заказчік1]! [Name_tov]))

GROUP BY Заказчік.Name_zakaz, Заказчік.Adres_zakaz, Заказчік.Number_N, Заказчік.Date_N, Товари.Name_tovar, Товари.Srok_god, Товари.Ves_b, Товари.Ves_n, Товари.Cena, Товари.Date;