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

РефератДопомога в написанніДізнатися вартістьмоєї роботи

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

МІНІСТЕРСТВО СПІЛЬНОГО І ПРОФЕСІЙНОГО ОБРАЗОВАНИЯ.

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

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

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

Дистанційне обучение.

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 |.

|Уни|Наи|Уни|Уни|Дат|Акц|Рас|Сро|Вес|Вес|Цен|Сум|Вид| |кал|мен|кал|кал|а |изн|шиф|к |Бру|Нет|а |мар|упа| |ьны|ова|ьны|ьны|изг|ая |ров|год|тто|то |за |ная|ков| |і |ние|й |і |ото|мар|ка |ніс| | |еди|цен|ки | |клю|тов|клю|клю|вле|ка |штр|ти | | |ниц|а | | |год |ара|ч |год |ния| |їх-| | | |у | | | |тов| |пос|зак| | |код| | | | | | | |ара| |тав|азч| | |а | | | | | | | | | |щик|ика| | | | | | | | | | | | |а | | | | | | | | | | |.

Форма «ГОЛОВНА КНОПКОВА ФОРМА».

[pic].

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.

Форма «ЗАКАЗЧИК».

[pic].

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.

Форма «ПОСТАВЩИК».

[pic].

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.

Форма «ТОВАР».

[pic].

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.

Форма «Про ПРОГРАММЕ».

[pic].

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;

Показати весь текст

Заповнити форму поточною роботою