ДИПЛОМНА РОБОТА
ТЕМА: "Розробка бази даних для інформатизації діяльності підприємства малого бізнесу Delphi 7.0"
Зміст
Введение_______________________________________________ ____ _3
Глава 1. Аналітична часть____________________________ ____ _5
1.1. Структура ремонтно-будівельної компаніі_________________6
1.2. Постановка задачи.________________________________________8
1.3. Аналіз необхідності впровадження автоматизованої
системи. ___________________________________________________ 10
1.4. Технічне завдання на разработку.________________ ______ __15
Глава 2. Інформаційно-програмна часть.________ ___ ______19
Функціональні можливості сістеми_________ ________ ___20
2.2. Побудова моделі БД. _______________________ _______ ____21
2.3. Инфологическая модель БД________________________ ______ _22
2.4. Вибір СУБД._____________________________________ ______ 28
2.5. Побудова датологіческой моделі.________________________33
Глава 3.ОРГАНІЗАЦІЙНА - технологічна частина _____________43
3.1. Загальна структура організації робіт по
проектування ПП.______________________________ ____ ___ ___ _44
3.1.1. Постановка задачі.______________________________ _______ _44
Складання проекта.________________________ ___________ 45
Алгоритмізація. ___________________________ ___________ _46
3.1.4. Програмування. _____________________________ _______ _49
3.1.5. Препарацuя ___________________________________ _______ __50
3.1.6. Трансляція. ___________________________________ _______ _50
3.1.7. Отладка._______________________________________ _______ _51
3.1.8. Оформлення программи._________________________ ____ _52
3.1.9. Перевірка правильності расчетов.__________________ ___ _53
Звіт про роботу. _______________________________ __ _54
3.2. Необхідність налагодження розробленого програмного продукта_______________________________________________55
Методи і засоби отладкі_________________________58
Контроль программи____________________________ _ _58
3.3.2. Контроль результатов___________________________ ___ _60
3.3.3. Класифікація методів контроля_________________ ___ _63
3.3.4. Локалізація ошібок.____________________________ ___ _64
3.3.5. Технологія налагодження программи___________________ ___ _67
Введення.
Поступово з розвитком програмного забезпечення ЕОМ з'явилися ідеї створення управляючих систем, які дозволяли б накопичувати, зберігати і оновлювати взаємопов'язані дані з цілого комплексу розв'язуваних завдань. Ці ідеї знайшли своє втілення в системах управління базами даних (СКБД). СУБД взаємодіють не з локальними, а взаємопов'язаними за інформацією масивами, званими базами даних. З появою персональних комп'ютерів СУБД стають найбільш популярним засобом обробки табличної інформації. Вони є інструментальним засобом проектування банків даних при обробці великих обсягів інформації.
На сьогоднішній день обробка заявок в ремонтно-будівельної компанії (РСК) проводиться «вручну», що призводить до великих витрат часу, що в більшості випадків викликає невдоволення клієнтів.
Дана система управління заснована на взаємодії декількох баз даних, створених за допомогою середовища ACCESS. Вищевказана система стосується тієї частини роботи РСК, яка пов'язана з надходженням і обробкою заявки на ремонт. Описуваний програмний комплекс сприяє скороченню тимчасового інтервалу від звернення замовника в РСК до укладення договору про проведення робіт; знижує витрати на обробку первинної інформації про об'єкт; містить нормативно - довідкову інформацію; веде облік клієнтів.
Основна перевага системи полягає в обробці заявок за структурою: First Input First Output (F. I. F. O.), Тому що при надходженні заявки, відбувається її обробка, і клієнт одразу ж отримує відповідь про вартість проведення ремонту і список матеріалів, необхідних для виконання ремонтних робіт. Таким чином створюється сприятливий психологічний клімат при роботі менеджера РСК з клієнтами.
Так само до достоїнств програми варто віднести те, що вона розроблена в рамках дипломного проекту, що значно знижує її собівартість.
Глава 1.
Аналітична частина.
Розробив Солнцев М. А.
Керівник Гагаріна Л. Г.
1.1. Структура ремонтно-будівельної компанії
У даному дипломному проекті зачіпається діяльність фірми, яка надає послуги в галузі ремонту та будівництва житлових будинків і громадських споруд.
На сьогоднішній день, для нормального функціонування, будь-яка ремонтно-будівельна компанія (РСК) обов'язково повинна мати у своєму складі хоча б наступні підрозділи:
Адміністративний відділ;
Розрахунково-економічний відділ;
Відділ маркетингу;
Відділ по роботі з клієнтами;
Відділ постачання;
Виробничий відділ.
Адміністративний відділ, в особі директора, забезпечує загальне керівництво колективом і вирішення принципових технічних завдань, пов'язаних з вибором портфеля замовлень, забезпеченням конструкторської та технологічної документації, закупівлею обладнання і стандартною оснащення і т.п.
Він же веде оперативне управління справами підприємства. При вирішенні цих завдань керівник при необхідності залучає інших фахівців, доручаючи їм виконання конкретних завдань.
Розрахунково-економічний відділ здійснює бухгалтерську звітність та техніко-економічне планування. Бухгалтер виконує розрахункові роботи, оформляє необхідну документацію. Стежить за точністю і своєчасністю розрахунків з споживачами, постачальниками та органами податкового контролю. Складає підсумкові бюджетні звіти для надання в податкові органи. Бере активну участь в плануванні в області податкової і цінової політики підприємства.
Основним завданням відділу маркетингу є ефективне управління рекламною компанією фірми. Сюди можна віднести аналіз рекламних видань і розміщення реклами в найбільш популярних з них, розповсюдження листівок, участь у спеціалізованих виставках і т.п.
Відділ по роботі з клієнтами займається прийомом і обробкою заявок громадян і організацій в РСК на проведення ремонтно-будівельних робіт. Потім первинна інформація передається виконробу фірми (особі, що займається проведенням робіт на об'єктах і складанням кошторисної документації), який зустрічається з потенційним замовником, робить необхідні заміри об'єкта, після чого проводить розрахунок вартості послуг на проведення робіт. На підставі цього розрахунку замовник приймає рішення про укладення договору з даною компанією.
Відділ постачання займається закупівлею і доставкою матеріалів, необхідного інвентарю та інструменту на об'єкти під час проведення робіт. Тут так само виробляють підбір матеріалу за якісними і вартісними характеристиками. Постачання комплектуючих здійснюється відповідно до складеного виконробом графіку проведення робіт на об'єкті.
Виробничий відділ займається безпосередньо проведенням робіт на об'єктах, з якими укладено договори підряду. За кожним об'єктом закріплюється особа відповідальна за проведення робіт на даному об'єкті (виконроб). Виконроб займається розрахунком і підбором необхідної кількості фахівців для проведення ремонту, складає докладний поетапний графік проведення робіт. Під час ремонту суворо контролюється дотримання графіка, технології та якості робіт.
1.2. Постановка завдання.
Вище були розглянуті функції різних підрозділів РСК. Безсумнівно, робота кожного з них дуже важлива, але хотілося б приділити особливу увагу відділу по роботі з клієнтами, від ефективності роботи якого багато в чому залежить фінансовий стан всього підприємства в цілому.
У даній дипломній роботі була поставлена задача по розробці програмного продукту (ПП), який дозволить ремонтно-будівельної компанії (РСК) значно скоротити проміжок часу від звернення потенційного клієнта фірми до укладення договору про проведення робіт. У той же час розробляється ПП дозволить скоротити роботу персоналу компанії по обробці «порожніх», тобто не проходять замовлень. Це, у свою чергу, веде до значної економії коштів, тому що обробка одного замовлення займає не менше восьми годин висококваліфікованого фахівця. Відзначу також, що програма дозволяє фахівцеві Відділу по роботі з клієнтами проводити облік звернень і кваліфіковано вести діалог із замовниками, представляючи досить складну спеціальну інформацію.
1.3. Аналіз необхідності впровадження автоматизованої системи.
В даний час в РСК обробка звернень громадян і організацій, з приводу проведення ремонтно-будівельних робіт, відбувається «вручну», що відображує на рис.1.
Рис.1 Структурна схема неавтоматизованої системи обробки заявок
На вищенаведеною схемою простежується кілька етапів передачі інформації:
Замовник звертається на фірму до менеджера по роботі з клієнтами, для подачі заявки на проведення ремонтно-будівельних робіт.
Менеджер по роботі з клієнтами відправляє відомості про замовлення виконробу.
Виконроб виїжджає на об'єкт, для уточнення відомостей про ремонтні роботи, проводить необхідні виміри. Після цього складається кошторисна документація.
Складені документи передаються менеджеру по роботі з клієнтами.
Менеджер представляє кошторисну документацію замовнику.
Замовник, на підставі наданого пропозиції, приймає рішення про подальшу співпрацю з РСК.
Результати прийнятого рішення менеджер надає директору фірми.
При обопільній згоді укладається договір між фірмою і замовником.
При такому положенні справ на обробку однієї заявки витрачається кілька днів. Крім того, менеджер вищевказаного відділу повинен володіти досить великим обсягом спеціальної інформації. Так само не можна забувати, що в такій схемі обробки інформації бере участь ще одна особа - виконроб. Від нього залежить, наскільки швидко він зможе зв'язатися з замовником, провести розрахунки і скласти необхідну документацію. При цьому не слід забувати, що виконроб так само буває зайнятий виробництвом робіт на інших об'єктах. Пропонований ПП «Автоматизована інформаційна система ремонтно-будівельного підприємства (АІС РСК)» передбачає зовсім інший підхід до обробки заявок. Це можна побачити на рис. 2:
Рис.2. Структурна схема автоматизованої системи обробки заявок
На цій схемі проходження інформації здійснюється наступним чином:
Замовник звертається на фірму до менеджера по роботі з клієнтами для подачі заявки на проведення ремонтно-будівельних робіт.
Менеджер по роботі з клієнтами звертається до АІС РСК. Він заповнює картку клієнта, і система видає всі необхідні розрахунки та інформацію згідно запитів.
На підставі отриманої інформації замовник приймає рішення про подальшу співпрацю з РСК
Результати прийнятого рішення менеджер надає директору фірми.
При обопільній згоді укладається договір між фірмою і замовником.
На підставі поданої схеми та описи можна побачити, що процес обробки заявок значно спрощується. Завдяки АІС необхідну інформацію про вартість робіт на об'єкті клієнт отримує протягом декількох хвилин. Так само ми бачимо, що на цьому етапі роботи підприємства зникає необхідність в яких-небудь дії з боку виконроба. Обсяг інформації, якою повинен володіти менеджер по роботі з клієнтами значно зменшується, тому що всю необхідну спеціальну інформацію містить АІС.
Виходячи з усього вище сказаного, користь від пропонованої програми безсумнівна.
1.4. Технічне завдання на розробку.
Автоматизована інформаційна система обліку та обробки заявок громадян у ремонтно-будівельну компанію.
Введення.
Найменування
Автоматизована інформаційна система ремонтно-будівельної компанії (АІС РСК) по обліку і опрацювання заявок громадян.
Коротка характеристика і області застосування.
АІС РСК являє собою інформаційну систему для автоматизації введення, реєстрацію та видачу інформації про вартість проведення робіт. АІС призначена в основному, для використання в малих і середніх РСК.
Підстава для розробки:
Завдання на дипломний проект.
Призначення та мета створення системи
. Призначення розробки:
Програмний продукт (ПП) призначений для обліку та обробки заявок громадян і організацій в РСК, та подання звітів у вигляді калькуляційних відомостей.
3.2.Целі створення:
Автоматизація обліку та обробки заявок громадян в РСК;
Скорочення тимчасового інтервалу від звернення замовника в РСК до укладення договору про проведення робіт;
Зниження витрат на обробку первинної інформації про об'єкт;
Створення сприятливого психологічного клімату при роботі з клієнтами.
Технічні вимоги
Вимоги до функціональних характеристик
Склад виконуваних функцій:
надання готових форм для введення вихідних даних;
оброблення вихідних даних та складання кошторисів;
складання спеціальних форм звітів.
Організація вхідних і вихідних даних:
Вхідні дані - вносяться користувачем відомості про замовлення на роботи (реквізити замовника, види робіт, обсяг робіт тощо). Вихідні дані - звіти про вартість робіт, а так само кількість і вартість матеріалів необхідних для проведення цих робіт.
Тимчасові характеристики:
Машинна обробка даних становить кілька секунд.
Вимоги до надійності
У період дослідної експлуатації правильність роботи системи перевіряється тестовим введенням вихідних даних.
Вимоги до умов експлуатації
Програма орієнтована на мінімальні вимоги до комп'ютерної підготовки користувачів.
Вимоги до складу і параметрів технічних засобів
IBM PC 486/16 MB і вище.
Вимоги до інформаційної та програмної сумісності
Інформаційні структури на вході і виході:
ОС Windows NT/9x/200x;
Office 9x Pro.
Методи рішення:
Побудова СУБД на основі инфологической і датологіческой моделі предметної області.
4 .5.3. Мови програмування та програмні засоби, що використовуються в програмі
Визначаються на етапі ескізного проектування.
4.6. Вимоги до упаковки, маркування, транспортування та зберігання
Відсутні.
Вимоги до програмної документації
Склад програмної документації:
керівництво користувача;
лістинг програми.
Техніко-економічні показники розробляються в економічній частині проекту.
Стадії та етапи розробки
визначаються відповідно до регламенту розробки дипломного проекту.
Порядок контролю і приймання
Загальні вимоги до приймання робіт:
тестування програмних модулів;
дослідна експлуатація.
Виконавець ___________ / М.А. Солнцев /
2002
Глава 2.
Інформаційно-програмна частина.
Розробив Солнцев М. А.
Керівник Гагаріна Л. Г.
Функціональні можливості системи
Перед початком проектування будь-якої системи необхідно в першу чергу визначити склад тих операцій, які будуть закладені в проектований комплекс програмних засобів, та проаналізувати необхідність і можливість реалізації функцій засобами конкретної системи проектування. АІС РСК з обліку та опрацювання заявок громадян призначена, як вже було сказано вище, в першу чергу для підвищення ефективності роботи менеджера з обробки заявок. Тому функціональні можливості програмного комплексу повинні бути спрямовані на вирішення конкретних завдань що виникають у процесі роботи.
У проектованої системі необхідно закласти можливості, що забезпечують нижче перераховані сервісні та інформаційно-розрахункові функції:
автоматичний облік звернень фізичних та юридичних осіб;
можливість надання готових форм для введення вихідних даних;
автоматична обробка вихідних даних;
видача спеціальних форм звітів згідно запитів;
можливість доповнення і зміни інформації в базах даних (БД);
2.2. Побудова моделі БД.
Для проектування структури БД необхідна початкова інформація про предметну область бажано у формалізованому вигляді. Предметною областю (ПО) називається частина реальної системи, що представляє інтерес для даного дослідження.
При проектуванні автоматизованих інформаційних систем ПЗ представляється у вигляді моделей даних декількох рівнів. Число використовуваних рівнів залежить від складності системи, але в будь-якому випадку включає логічний і фізичний рівні. ПЗ може ставитися до будь-якого типу організації (інститут, завод, мале підприємство і т.п.).
Необхідно розрізняти повну ПО підприємства в цілому та організаційну одиницю цієї ПЗ. Організаційна одиниця, у свою чергу, може представляти свою ПЗ (відділи).
Інформація, необхідна для опису ПЗ, залежить від реальної моделі й може включати відомості про персонал, заробітної плати, товари, тобто відомості про людей, місцях, предметах, подіях і поняттях.
Опис ПЗ, без орієнтації на використовувані програмні та технічні засоби, називається инфологической моделлю (Илм).
2.3. Инфологическая модель БД
Компоненти инфологической моделі
Компоненти инфологической моделі включають ряд описів об'єктів ВО і зв'язку між ними. Опис ПЗ завжди представлено в якійсь знаковій системі. Тому крім відносин, властивих ПЗ, виникають ще й відносини, зумовлені особливостями відображення ПЗ в мовному середовищі.
В даний час не існує єдиного стандарту чи загальноприйнятого способу побудови Илм. Для опису Илм використовуються як мови аналітичного (описового) типу, так і графічні засоби.
У процесі аналізу в ПЗ виділяють класи об'єктів. Класом об'єктів називають сукупність об'єктів, що володіють однаковим набором властивостей. Наприклад, якщо як ПО розглянути вуз, то в ній можна виділити такі класи об'єктів: учні, викладачі, аудиторії і т. д. Об'єкти можуть бути реальними або абстрактними, як, наприклад, предмети, які вивчають студенти.
При відображенні в ІС кожен об'єкт представляється своїм ідентифікатором, який відрізняє один об'єкт класу від іншого, а кожен клас об'єктів представляється ім'ям цього класу. Так, для об'єктів класу "вивчаються предмети» ідентифікатором кожного об'єкта буде «Назва предмета». Ідентифікатор повинен бути унікальним. Кожен об'єкт має певним набором властивостей. Для об'єктів одного класу набір цих властивостей однаковий, а їхні значення можуть різнитися.
Кожному класу об'єктів у Илм присвоюється унікальне ім'я.
При описі ПО треба відобразити зв'язку між об'єктом і характеризують його властивостями. Це зображується у вигляді лінії, що з'єднує позначення об'єкта та його властивостей.
Зв'язок між об'єктом та його властивістю може бути різною. Об'єкт може володіти тільки одним значенням якогось властивості. Наприклад, кожна людина може мати тільки одну дату народження. Назвемо такі властивості одиничними. Для інших властивостей можливе існування одночасно кількох значень у одного об'єкта. Нехай, наприклад, при описі «Співробітника» фіксується в якості його властивості «Іноземна мова», якою він володіє. Так як співробітник може знати кілька іноземних мов, то таке властивість будемо називати множинним. При зображенні зв'язку між об'єктом і його властивостями для одиничних властивостей будемо використовувати одинарні стрілку, а для множинних властивостей - подвійну. Крім того, деякі властивості є постійними, їх значення не може змінитися з плином часу. Назвемо такі властивості статичними, а ті властивості, значення яких може змінюватися з часом, будемо називати динамічними.
Окрім зв'язку між об'єктом і його властивостями, в Илм фіксуються зв'язки між об'єктами різних класів. Розрізняють зв'язку типу «один до одного» (1:1), «один до багатьох» (1: М), «багато до одного» (М: 1) і «багато до багатьох» (М: М). Іноді ці типи зв'язків називаються ступенем зв'язку. Крім ступеня зв'язку в Илм для характеристики зв'язку між різними сутностями треба вказувати так званий клас приналежності, який показує, чи може бути відсутнім зв'язок об'єкта даного класу з будь-яким об'єктом іншого класу. Клас приналежності суті повинен бути або обов'язковим, або необов'язковим.
З урахуванням перерахованих вище особливостей побудови Илм були розроблені вісім об'єктів даних:
Об'єкт Картка клієнта містить: дані про замовника, дату надходження замовлення і вихідні дані про об'єкт для розрахунків: площа об'єкта, висота стін, остаточний матеріал підлоги, стін і стелі.
Об'єкт Матеріали включає: найменування будівельного матеріалу, одиниці виміру (м.кв., м.п., шт. Тощо) та вартість.
Об'єкт Норми витрати містить у собі інформацію тому, скільки витрачається того чи іншого матеріалу на одиницю кожного типу робіт: найменування або код робіт, найменування матеріалу, одиниці виміру і кількість.
Об'єкт Одиниці виміру містить допоміжні відомості про всілякі одиницях вимірювання різних матеріалів.
Об'єкт Роботи включає наступні аргументи: найменування, ціну на одиницю виміру, а так само тип виконуваних робіт (штукатурні, малярні і т.п.).
Об'єкт Типи робіт містить допоміжні відомості підстановки про всі типи виконуваних робіт.
Об'єкт Список робіт призначений для вибірки всіх робіт, які необхідно виконати перед виконанням остаточної роботи.
Об'єкт ЗаказиРаботи є допоміжним і призначений для зв'язку об'єктів Картка клієнта і Список робіт, тому що між ними повинна бути зв'язок «багато до багатьох».
На підставі описаних властивостей об'єктів і їх призначення побудуємо Илм нашої бази даних (див. рис. 3.1).
Рис. 2.1 Инфологическая модель бази даних.
Рис. 2.1 Инфологическая модель бази даних (продовження).
Илм предметної області будується першою ще на передпроектній стадії і потім уточнюється на більш пізніх стадіях. Потім на її основі будується ДЛМ. Фізична та зовнішня моделі після цього можуть будуватися в будь-якій послідовності, в тому числі і паралельно. При проектуванні БД можливе повернення на попередні рівні. При цьому можливі два види повернень: перший вид обумовлений необхідністю перегляду результату проектування (наприклад, для поліпшення отриманих характеристик, «обходу» обмежень і т. п.), другий вид викликаний необхідністю уточнення попередньої моделі (зазвичай инфологической) з метою отримання додаткової інформації для проектування або при виявленні протиріч в моделі.
2.4. Вибір СУБД.
Після побудови Илм необхідно вибрати СУБД, за допомогою якої ми будемо керувати нашими БД.
На сьогоднішній день існує багато різноманітних систем управління базами даних. Це такі СУБД як Paradox, FoxPro, Clipper, Access і ін Для роботи з більшістю з них потрібні досить глибокі знання даної СУБД і досвід програмування.
Успіх Microsoft Access полягає в прекрасній реалізації продукту, розрахованого як на початківця, так і кваліфікованого користувача. Microsoft Access - це сама популярна сьогодні настільна система керування базами даних.
У Microsoft Access присутня мова програмування Visual Basic, який дозволяє створювати масиви, свої типи даних, контролювати роботу додатків. MS Access має один з найкращих наборів візуальних засобів розробки та подання інформації серед аналогічних програмних продуктів.
Одне з основних переваг MS Access - інтеграції з популярним офісним пакетом Microsoft Office.
Вся робота з базою даних здійснюється через вікно контейнера бази даних. Звідси здійснюється доступ до всіх об'єктів: таблиць, запитів, форм, звітів, макросів, модулів.
Вбудована мова запитів SQL дозволяє максимально гнучко працювати з даними і значно прискорює доступ до зовнішніх даних.
Access сприймає велику кількість форматів даних, включаючи файлові структури інших СУБД. Тому додаток в Access може імпортувати з текстових файлів або електронних таблиць і експорт в них: надавати прямий доступ і оновлювати файли Paradox, FoxPro і інших БД. Можна також імпортувати дані з цих файлів у таблиці Access.
Перевагою Access є наявність засобів проектування програми БД без знання мови програмування. Робота в Access починається з визначення реляційних таблиць і полів, призначених для зберігання даних. Відразу після цього за допомогою форм, звітів, макросів і VBA можна визначати дії над цими даними. Форми і звіти використовуються для виводу на екран і додаткових обчислень при роботі з таблицями. У разі розробки більш складного програми можна використовувати мову Visual Basic.
Архітектура Access називає об'єктами все, що може мати ім'я. В БД Access основними об'єктами є таблиці, запити, форми, звіти, макроси та модулі. Термін БД звичайно відноситься лише до файлів, в яких зберігаються дані. У Access БД включає всі об'єкти, пов'язані з збереженими даними, у тому числі й ті, які визначаються для автоматизації роботи (див. Табл. 2.1.).
Таблиця 2.1.
Компоненти СУБД Access.
Об'єкт | |
Таблиця | Містить інформацію про об'єкти. Поля (стовпці) зберігають характеристики об'єктів, а кожна запис (рядок) містить відомості про об'єкт. |
Запит | Фіксує потрібні дані з однієї або декількох таблиць. Для запиту можна використовувати запит за зразком або інструкцію SQL-запити на вибірку і оновлення даних. |
Форма | Відбиває вимоги до даних таблиць або запитів. Форми можна роздрукувати. За допомогою форми можна запустити макрос або VBA. |
Об'єкт форматування, обчислення підсумків та друку даних. | |
Макрос | Опис дій Access у відповідь на подію. Макрос відкриває іншу форму, може перевіряти поля при зміні його вмісту, відкривати таблиці, запити, перегляд або друк, запустити інший макрос або процедуру VBA. |
Модуль | Програма мовою Visual Basic для додатків, виявлення помилки, які не виявляє макрос. Модулі можуть бути незалежними об'єктами, які містять функції, що викликаються з будь-якої програми або звіту для реакції на події. |
У таблицях зберігаються дані. Використовуючи форми, можна виводити дані на екран або змінювати їх. Форми і звіти отримують дані як безпосередньо з таблиць, так і через запити. Для виконання обчислень запити можуть використовувати вбудовані функції або функції, створені за допомогою Visual Basic для додатків.
Події у формах або звітах можуть запускати макроси або процедури VBA. Подія - будь-яка зміна стану об'єкта Access, наприклад відкриття форми, закриття форми, введення нового рядка у форму, зміна вмісту поточного запису або елемента керування. Для обробки події можна створити макрос або процедуру VBA, за допомогою яких можна передбачити реакцію на будь-яку дію користувача, аж до натискання певних клавіш під час введення даних. За допомогою макросів і модулів можна змінювати хід виконання програми; відкривати, фільтрувати і змінювати дані у формах і звітах; виконувати запити і створювати нові таблиці. Використовуючи VBA, можна створювати, модифікувати і видаляти будь-який об'єкт Access, обробляти дані по рядках і по стовпцях або яким-небудь іншим способом. Можна також викликати процедури з бібліотек динамічного компонування Windows, щоб використовувати в додатку не тільки вбудовані в Access функції, але й можливості Windows.
Враховуючи все вищесказане, ми зупинимося на СУБД Access для розробки нашого програмного продукту.
2.5. Побудова датологіческой моделі.
З урахуванням побудованої инфологической моделі і знаючи обмеження, що накладаються на збережені дані використовуваною системою управління базами даних, будується датологіческая модель бази даних.
Датологіческая модель будується в термінах бази даних. Так як у нашому випадку використовується СУБД ACCESS, то ми будуємо реляційну модель бази даних у реалізації MS ACCESS.
Вона дозволяє організовувати опис об'єктів у вигляді таблиць. При цьому можна задавати обмеження на типи даних, що зберігаються в стовпці, первинні ключі для завдання зв'язку декількох таблиць. Нарешті можна задавати обмеження цілісності за допомогою тригерів і процедур.
Крім того таблиці підтримують обмеження на непорожнє значення поля і унікальне поле. Можливо так само завдання індексації полів для подальшого прискорення пошуку даних у таблицях.
Побудована датологіческая модель БД, з урахуванням особливостей MS ACCESS, виглядає наступним чином:
Таблиця 2.2.
Таблиця «Картка клієнта»
Ім'я поля | Тип даних | Опис |
КодЗаказа | Лічильник | Ідентифікатор |
ФІОНаіменованіе | Текстовий | Ім'я замовника |
Числовий | Телефон замовника | |
Адреса | Текстовий | Адреса замовника |
ДатаОбращенія | Дата / час | Дата звернення |
Площа | Поле МЕМО |