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

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

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

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

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

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

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

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

О В І Т про виконання практичних завдань

по курсу

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

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

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

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

Завдання виконав ________________ ____________________ підпис студента дата виконання

Завдання перевірив ________________ ____________________ оцінка підпис викладача

____________________

дата виконання завдання

Рецензія викладача
___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________

В в е д е н н я

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Первісна схема даних

Визначення об'єктів

Виділимо наступні об'єкти:
1. ТОВАР - (Т);
2. ЗАМОВНИК - (З);
3. ПОСТАЧАЛЬНИК - (П);
4. РАХУНКУ - (С);
5. ДОГОВІР - (Д);
6. НАКЛАДНІ - (Н).

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

| | Т | |
| З | | П |
| | З | |
| Н | | Д |

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

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

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

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

| | | | З | |
| | | | | З |
| | | | П | |
| | Т | | | Н |
| | | | Д | |

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

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

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

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

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

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

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

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

| | | | З | Н |
| | | | | |
| | Т | | П | Д |
| | | | | |
| | | | З | |

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

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

| | | | З | |
| | | | | |
| | Т | | П | |
| | | | | |
| | | | З | |

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наведемо приклад таблиці індексів і їх зв'язку з наявними файламиданих, згідно варіанту.
Таблиця 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

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;