Організація баз даних

Інформатика, програмування

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

РОСІЙСЬКОЇ ФЕДЕРАЦІЇ

Таганрозький державний радіотехнічний університет

Кафедра обчислювальної техніки

_________________________________________________________________________

Дистанційне навчання

1999 - 2000 навчальний рік

О Т Ч Е Т

про виконання практичних завдань

по курсу

ОРГАНІЗАЦІЯ БАЗ ДАНИХ

студента групи ВД - 39

. Найденко Олексія Володимировича

П.І.Б. повністю У в е д е н і е

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

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

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

Попереднє планування, підготовка даних,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Третій даний об'єкт - Замовник. Його властивостями є «унікальний ключ замовника», «найменування замовника». Взаємозв'язок «один до одного» (між двома типами об'єктів)

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

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

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

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

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

Первісна схема даних Функціональна модель Дослідження струмів Даних Дані виявлені в ході розробки Відділ обробки заявок Заявки Договору Договорів Постачальники Замовники Ведення рахунків Рахунки Навантаження Накладні Товар Інвентаризація Довідки Визначення об'єктів

Виділимо наступні об'єкти:

1. ТОВАР - ( Т );

2. ЗАМОВНИК - ( З );

3. ПОСТАЧАЛЬНИК - ( П );

4. РАХУНКУ - ( С );

5. ДОГОВІР - ( Д );

6. НАКЛАДНІ - ( Н ).

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

Т З П З Н Д

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

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

Властивості, що включаються до складу БД для даної моделі, наведено в табл.1. Таблиця 1. Властивості та первинні ключі об'єктів інформаційної моделі. Об'єкт Первинний ключ Властивості ТОВАР Унікальний ключ товару Унікальний ключ товару Найменування товару ЗАМОВНИК Унікальний ключ замовника Унікальний ключ замовника Найменування замовника Юридична приналежність П.І.Б. керівника Адреса Телефон/факс Найменування товару Кількість товару Передбачувана ціна ПОСТАЧАЛЬНИК Унікальний ключ постачальника Унікальний ключ постачальника Найменування постачальника Юридична приналежність П.І.Б. керівника Адреса Телефон/факс Найменування товару Кількість товару Дата виготовлення Акцизна марка Розшифровка штрих-коду Термін придатності Вага Брутто Вага Нетто Ціна за одиницю Сумарна ціна Вид упаковки Спосіб доставки РАХУНКУ Номер рахунку Номер рахунку Дата продажу Найменування постачальника Адреса постачальника Юридична приналежність п. Найменування замовника Адреса замовника Юридична приналежність з. Найменування товару Кількість товару Сума ПДВ Сума до оплати ДОГОВІР Номер договору Номер договору Дата укладення Номер рахунку Найменування постачальника Адреса постачальника Юридична приналежність Найменування товару Кількість товару Сума ПДВ НАКЛАДНІ Номер накладної Номер накладної Дата накладної Позначка про оплату Номер рахунку Найменування замовника Адреса замовника Юридична приналежність Найменування товару Кількість товару Сума ПДВ

Графічне подання першої таблиці

З З П Т Н Д

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

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

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

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

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

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

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

Таблиця 2. Властивості та первинні ключі змінених або доданих об'єктів інформаційної моделі. Об'єкт Первинний ключ Властивості ТОВАР Унікальний ключ товару Унікальний ключ товару Унікальний ключ постачальника Унікальний ключ замовника Найменування товару Дата виготовлення Акцизна марка Розшифровка штрих-коду Термін придатності Вага Брутто Вага Нетто Ціна за одиницю Сумарна ціна Вид упаковки ЗАМОВНИК Унікальний ключ замовника Унікальний ключ замовника Найменування замовника Юридична приналежність П.І.Б. керівника Адреса Телефон/факс Передбачувана ціна ПОСТАЧАЛЬНИК Унікальний ключ постачальника Унікальний ключ постачальника Найменування постачальника Юридична приналежність П.І.Б. керівника Адреса Телефон/факс РАХУНКУ Номер рахунку Номер рахунку Дата продажу Унікальний ключ товару ПДВ Сума до оплати ДОГОВІР Номер договору Номер договору Дата укладення Унікальний ключ постачальника НАКЛАДНІ Номер накладної Номер накладної Унікальний ключ замовника Позначка про оплату Дата накладної

Графічне представлення другої таблиці

З Н Т П Д З

Таблична з певними зв'язками, остаточна концептуальна модель. ТОВАР Унік. ключ постачальника Унік. ключ замовника Найменування товару Дата виготовлення Акцизна марка Расшіф. Штрих-код ЗАМОВНИК Термін придатності ПОСТАЧАЛЬНИК Унік. ключ замовника Вага Брутто Унік. ключ постачальника Найменш. Замовника Вага Нетто Найменш. постачальника Юрид-ська. принади. Ціна за одиницю Юрид-ська. принади. П.І.Б. керівника Сумарна ціна П.І.Б. керівника Адреса Вид упаковки Адреса Телефон/факс Унік. ключ товару Телефон/факс Передбачувана ціна Номер договору Номер накладної Дата укладення Позначка про оплату Дата накладної РАХУНКУ Унік. ключ товару Номер рахунку Дата продажу ПДВ Сума до оплати

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

З Т П З

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

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

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

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

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

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

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

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

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

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

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

Таблиця 3. Проект таблиці для фізичної моделі. № п/п Найменування поля Примітка ТОВАР 1. Key_tovar Унікальний ключ товару 2. Key_postav Унікальний ключ постачальника 3. Key_zakaz Унікальний ключ замовника 4. Name_tovar Найменування товару 5. Date Дата виготовлення 6. Marka Акцизна марка 7. Kod Розшифровка штрих-коду 8. Srok_god Термін придатності 9. Ves_b Вага Брутто 10. Ves_n Вага Нетто 11. Cena_1 Ціна за одиницю 12. Cena Сумарна ціна 13. Upakovka Вид упаковки ЗАМОВНИК 1. Key_zakaz Унікальний ключ замовника 2. Name_zakaz Найменування замовника 3. Yrid_zakaz Юридична приналежність 4. FIO_zakaz П.І.Б. керівника 5. Adres_zakaz Адреса 6. Tel_zakaz Телефон/факс 7. Cena_z Передбачувана ціна 8. Number_N Номер накладної 9. Oplata Позначка про оплату 10. Date_N Дата накладної ПОСТАЧАЛЬНИК 1. Key_poctav Унікальний ключ постачальника 2. Name_postav Найменування постачальника 3. Yrid_poctav Юридична приналежність 4. FIO_postav П.І.Б. керівника 5. Adres_postav Адреса 6. Tel_postav Телефон/факс 7. Number_D Номер договору 8. Date_Z Дата укладення РАХУНКУ 1. Number_S Номер рахунку 2. Date_P Дата продажу 3. Key_tovar Унікальний ключ товару 4. NDS ПДВ 5. Summa Сума до оплати

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

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

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

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

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

Примітка (Доходячи через індекси до файлу даних, за допомогою самого індексу зчитується найменування товару і далі вся інформація по полях знаходиться в записі, згідно таблиці ТОВАР). Індексний файл Блок 7 Значення Ключа Номер Блоку Файл даних Блок 1 10 1 01 15 2 05 Індексний файл 10 Блок 10 Блок 2 Значення Номер 11 Ключа Блоку 15 15 7 25 8 Блок 3 35 9 Блок 8 16 Індекс 2-го рівня Значення Номер 20 Ключа Блоку 20 3 25 4 Блок 4 21 25 Блок 5 Блок 9 26 Значення Номер 30 Ключа Блоку 30 5 Блок 6 35 6 31 Індекс 1-го рівня 35

Унікальний ключ товару Найменування товару Унікальний ключ постачальника Унікальний ключ замовника Дата виготовлення Акцизна марка Розшифровка штрих-коду Термін придатності Вага Брутто Вага Нетто Ціна за одиницю Сумарна ціна Вид упаковки Форма «ГОЛОВНА Кнопковий ФОРМА »

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