База даних "Програмне забезпечення"

Призначення та класифікація систем управління базами даних (СУБД). Етапи роботи з БД: створення структури, введення даних, редагування, пошук інформації, оформлення звітів. Компоненти БД "Програмне забезпечення" (таблиці, форми, звіти, запити, макроси).

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык украинский
Дата добавления 16.12.2011
Размер файла 4,6 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Зміст

  • Вступ
  • 1. Призначення та класифікація систем управління базами даних (СУБД)
  • 2. Поняття бази даних
  • 3. Процес розробки
  • 4. Компоненти БД "Програмне забезпечення"
  • 4.1 Таблиці
  • 4.2 Форми
  • 4.3 Звіти
  • 4.4 Запити
  • 4.5 Макроси
  • Висновок
  • Література

Вступ

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

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

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

Робота з БД має такі етапи:

1) створення структури БД;

2) введення даних;

3) редагування структури i даних;

4) відшукання інформації в БД;

5) оформлення звітів.

Для виконання цих робіт є спеціальні програми, такі як Access, FoxPro, dBase-системи та iншi. Вони називаються системами управління базами даних (СУБД).

Основні функції СУБД:

Визначення даних (Data definition) - Ви можете визначити яка саме інформація буде зберігатись у даній БД, задати структуру даних і їх тип, а також вказати як ці дані зв'язані між собою.

Обробка даних (Data manipulation) - дані можна обробляти різними способами, можна вибирати різні поля, фільтрувати і сортувати дані. Можна об'єднати дані з іншою зв'язаною з ними інформацією і обчислювати результуючі значення.

Управління даними (Data control) - Ви можете вказати, кому дозволено ознайомлюватись із даними, коректувати і добавляти нову інформацію, визначити колективне користування.

1. Призначення та класифікація систем управління базами даних (СУБД)

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

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

Рис.1. Архітектура СУБД.

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

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

Приведена структура притаманна усім СУБД, котрі розрізняються обмеженнями та можливостями по виконанню відповідних функцій. Отже, процес порівняння і оцінки таких систем для одного конкретного застосування зводиться до співставлення можливостей наявних СУБД з вимогами користувачів.

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

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

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

В ієрархічній моделі зв'язок даних "один до одного" (1:

1) означає, що кожному значенню (екземпляру) елемента даних А відповідає одне і тільки одне значення, пов'язаного з ним елемента В. Наприклад, поміж такими елементами пар даних, як код готової продукції і її найменуванням є вищезазначений зв'язок, так як тільки кожному коду продукції відповідає одне її найменування.

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

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

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

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

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

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

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

база програмне забезпечення звіт

2. Поняття бази даних

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

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

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

незалежність даних від програм;

для пошуку та модифікації даних використовуються спільні механізми;

як правило, у складі БД існують засоби для підтримки її цілісності та захисту від неавторизованого доступу

Прокоментуємо додатково підкреслені слова та вирази у вищенаведеному описі, порівнюючи в основному з близьким попередником БД - файловими системами (ФС).

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

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

Приклад про мішок з різнокольоровими кульками.

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

Вимога мінімізації надлишковості полягає у мінімальній кількості копій для одних і тих же даних з урахуванням орієнтації на кілька застосувань. Ці надлишкові копії використовуються для підтримки зв'язків між даними. Як приклад, розглянемо відомості, що зберігаються у відділі кадрів деякого підприємства про своїх співробітників. Користувачами цієї інформації виступають адміністрація, профспілкова організація та бухгалтерія підприємства. Адміністрацію цікавлять дані про кваліфікацію, професійний рівень і досвід роботи, профспілки використовують відомості соціально-побутового характеру, а бухгалтерія оброблює ті дані, що потрібні для нарахувань заробітної плати та підрахунку податків, інших нарахувань та відрахувань. Хоча інформація і різнорідна, але все ж має значну спільну частину. Всім користувачам потрібні службовий номер, прізвище, ім'я, по-батькові співробітника, його рік народження, дані про умови праці. Інформація про сімейний стан та склад сім'ї використовується бухгалтерією і профспілками. Якщо для зберігання даних застосувати технологію ФС, то можливі два крайні варіанти: а) незалежні один від одного файли, відсортовані згідно з потребами того чи іншого користувача, передбачають значну надлишковість даних; б) всі дані знаходяться у одному файлі, відсортованому так, як потрібно одному з користувачів (наприклад, адміністрації) - надлишковість при цьому практично відсутня, але зручно працювати тільки одному з користувачів. Концепція БД займає проміжне становище між вищеописаними крайніми позиціями.

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

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

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

За критерієм виразової потужності інструментальні засоби специфікації умов цілісності можна підрозділити на такі групи:

порівняння поля запису (або атрибута) з константою або з іншим полем цього ж запису; приклад такої умови наводився вище;

порівняння поля запису з полем або кількома полями інших записів;

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

Зауважимо також, що вищенаведений поділ на групи має в своїй основі не тільки виразову потужність, а і складність алгоритмів реалізації.

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

3. Процес розробки

Процес розробки складається з таких кроків:

1. Визначення мети створення бази даних. Допомагає підготуватися до виконання наступних кроків.

2. Пошук і впорядкування потрібних відомостей. Збирає всі типи даних, які потрібно зберегти в базі даних, наприклад, назва товару та номер замовлення.

3. Розділення даних на таблиці. Розділяє елементи даних на групи або теми, наприклад, "Товари" або "Замовлення". Кожну тему буде перетворено на таблицю.

4. Перетворення елементів даних на стовпці. Вирішіть, які дані потрібно зберегти в кожній таблиці. Кожен елемент буде перетворено на поле та відображено як стовпець у таблиці. Наприклад, таблиця "Працівники" може містити такі поля, як "Прізвище" та "Дата прийому на роботу".

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

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

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

8. Застосування правил нормалізації. Застосуйте правила нормалізації даних, щоб переглянути правильність структури таблиці. Якщо потрібно, внесіть до таблиць зміни.

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

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

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

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

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

Для надсилання клієнтам повідомлень електронної пошти потрібно записати ще один елемент. Якщо відомо, що клієнт бажає отримувати повідомлення електронної пошти, потрібно також знати адресу його електронної пошти, на яку їх надсилати. Отже, для кожного клієнта потрібно записати адресу електронної пошти.

Доцільним буде створення прототипу для кожного звіту або списку виводу, а також визначення елементів, які потрібно використати для створення звіту. Наприклад, аналіз стандартного листа допоможе виявити кілька елементів. Якщо потрібно включити належне привітання - наприклад, рядок "Пан" або "Пані", з якого починатиметься привітання, необхідно створити елемент привітання. Зазвичай лист можна почати з фрази "Шановний пане Смоленко", а не з "Шановний пане Іван Смоленко". Це передбачає, що зазвичай прізвище потрібно зберігати окремо від імені.

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

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

Щоб поділити дані на таблиці, виберіть основні групи або теми. Наприклад, після пошуку та впорядкування відомостей для бази даних продажу товарів попередній список може мати такий вигляд:

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

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

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

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

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

Також слід визначити, чи база даних міститиме відомості місцевого або міжнародного походження. Наприклад, якщо заплановано зберігати міжнародні адреси, краще використати стовпець "Регіон" замість стовпця "Область", оскільки цей стовпець може об'єднувати області вашої країни та регіони інших країн. Аналогічно, краще використати стовпець "Поштовий індекс" або стовпець "Поштовий індекс для США" ("Zip Code"), якщо заплановано збереження міжнародних адрес.

У поданому нижче списку містяться кілька порад для визначення стовпців.

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

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

Після вдосконалення стовпців даних у кожній таблиці можна вибрати первинний ключ для кожної таблиці.

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

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

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

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

Часто як первинний ключ використовується довільне унікальне числове значення. Наприклад, кожному замовленню можна призначити унікальне числове значення замовлення. Єдиним призначенням номера замовлення є ідентифікація замовлення. Призначений номер не можна змінити.

Якщо не вдалося вибрати стовпець або набір стовпців для використання як первинного ключа, краще використати стовпець із типом даних "Автонумерація". У разі використання типу даних "Автонумерація" Access автоматично призначає значення. Такий ідентифікатор не містить даних; він не містить фактичних даних, що описують рядок, якому він відповідає. Беззмістовні ідентифікатори є оптимальними для використання як первинного ключа, оскільки вони не змінюються.

Після створення необхідних таблиць, полів і зв'язків таблиці слід заповнити зразками даних і спробувати виконати з ними певні операції: створення запитів, додавання нових записів тощо. Виконання цих дій допоможе виявити потенційні проблеми - наприклад, може знадобитися додати стовпець, який не було додано під час процесу розробки, або поділити одну таблицю на дві для видалення повторюваних даних.

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

Під час випробування початкової бази даних можна виявити можливості для її вдосконалення. Перевірте таке:

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

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

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

Наявність таблиць із великою кількістю полів, обмеженою кількістю записів і пустими полями в окремих записах. У такому разі може знадобитися змінення структури таблиці, щоб скоротити кількість полів і збільшити кількість записів.

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

Наявність у кожному стовпці відомостей, які відповідають темі таблиці. Якщо стовпець містить дані, які не відповідають темі таблиці, їх потрібно перемістити в іншу таблицю.

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

Наступним кроком створення бази даних є застосування правил нормалізації даних (або правил нормалізації). Ці правила використовуються для перевірки правильності структури таблиці. Процес застосування цих правил до структури бази даних називається нормалізацією бази даних (або просто нормалізацією).

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

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

4. Компоненти БД "Програмне забезпечення"

4.1 Таблиці

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

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

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

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

В базі даних є три таблиці з наступною структурою:

1. "CD-ROM":

a. Шифр диска (ключове поле);

b. Назва диска;

c. Дата випуску;

d. Шифр власника.

2. "Власники":

a. Шифр власника (ключове поле);

b. Прізвище, ім'я, по батькові;

c. Адреса;

d. Телефон.

3. "Файли":

a. Назва файлу (пакета);

b. Обсяг в Кбайтах;

c. Шифр диска;

d. Пояснення про призначення і властивості.

Рис.2. Схема даних.

Рис.3. Таблиця "CD-ROM"

Рис.4. Таблиця "Власники"

Рис.5. Таблиця "Файли"

4.2 Форми

Форми іноді називаються "екранами вводу даних". Це інтерфейси, які використовуються під час роботи з даними, тому вони часто містять кнопки для виконання різних команд. Можна створити базу даних без використання форм, просто редагуючи дані в таблицях даних. Проте більшість користувачів баз даних використовують форми для перегляду, введення та редагування даних у таблицях.

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

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

БД "Програмне забезпечення" включає в себе

1) 3 форми, які відображають дані відповідно до кожної з таблиць;

2) кнопочну форму;

3) підпорядковану форму;

4) форму, яка містить поля звіту.

Рис.6. Форма "CD-ROM"

Рис.7. Форма "Власники"

Рис.8. Форма "Файли"

Рис.9. Форма "CD-картотека"

Рис.10. Форма "CD-картотека"

Рис.11. Форма "CD-ROM (запит)"

4.3 Звіти

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

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

БД "Програмне забезпечення включає" в себе звіт, який містить такі поля:

· Назва диску;

· Дата випуску;

· ПІБ власника;

· Телефон.

Рис.12. Звіт "CD-ROM"

4.4 Запити

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

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

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

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

БД "Програмне забезпечення включає" в себе запит, який містить такі поля:

· Назва диску;

· Дата випуску;

· ПІБ власника;

· Телефон.

Рис.13. Звіт "CD-ROM"

4.5 Макроси

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

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

Рис.14. Макрос "Відкрити CD-ROM"

Висновок

Розроблена БД містить дані з предметної області "Програмне забезпечення" і складається з 3-ох таблиць:

· "CD-ROM" (Шифр диска (ключове поле); Назва диска; Дата випуску; Шифр власника)

· "Власники" (Шифр власника (ключове поле); Прізвище, ім'я, по батькові; Адреса; Телефон)

· "Файли" (Назва файлу (пакета); Обсяг в Кбайтах; Шифр диска; Пояснення про призначення і властивості).

Для полегшення роботи з даними в таблицях створив форми, до яких для додав керуючі елементи:

· СD-ROM;

· Власники;

· Файли;

· СD-ROM (запит);

· Кнопочна форма;

· СD-картотека;

· Підпорядкована форма;

Для зручного представлення даних з різних полів таблиць в БД додав звіт і запит, який включає такі поля: Назва диску; Дата випуску; ПІБ власника; Телефон.

Отже Microsoft Access - потужний інструмент для роботи з базами даних, основними компонентами якого є:

конструктор таблиць;

конструктор екранних форм;

конструктор SQL-запитів (мова SQL в MS Access не відповідає стандарту ANSI);

конструктор звітів, що виводяться на друк.

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

Література

1. Савчук Т.О. Організація баз даних і знань. Вінниця: ВДТУ, 2000 р.

2. Антифеев Дм. Д. Современные средства построения корпоративных систем поддержки принятия управленческих решений "Терн", М., 2001.

3. Рогач І.Ф., Сендзюк М.А., Антонюк В.А. Інформаційні системи у фінансово-кредитних установах: Нанч. посібник. - 2-ге вид.

4. http://uk. wikipedia.org/.

5. http://office. microsoft.com/ru-ru/training/.

Размещено на Allbest.ru


Подобные документы

  • Використання системи керування базами даних (СКБД) Microsoft Access на реляційній моделі. Основні об’єкти баз даних: таблиці, запити, форми, звіти, макроси і модулі. Виконання обрахунків у запитах, підсумкові та перехресні запити, їх використання.

    курсовая работа [569,6 K], добавлен 01.11.2011

  • Систематизація знань як основна функція бази даних. Логічне та фізичне проектування бази даних. Створення таблиць у базі даних, визначення основних зв'язків. Інструментальні засоби проектування та створення програмного забезпечення для обробки даних.

    курсовая работа [1,4 M], добавлен 29.04.2010

  • Особливості використання інформаційних систем у фінансово-економічних установах, використоване програмне забезпечення. Основи роботи з базами даних Acces та програмою бухгалтерського обліку 1С. Правила переходу від програми 1С Бухгалтерія 6.0 до 1С 7.7.

    контрольная работа [17,4 K], добавлен 05.02.2009

  • База даних як сумісно використовуваний набір логічно зв'язаних даних, передбачений для задоволення інформаційних потреб. Програмне забезпечення, яке взаємодіє з прикладними програмами користувачів, апаратне забезпечення, дані, процедури і користувачі.

    реферат [160,9 K], добавлен 20.06.2010

  • Системне та прикладне програмне забезпечення ПК. Файлові менеджери. Системи автоматизованого проектування, управління базами даних. Текстові та табличні процесори. Операційна система WINDOWS XP. Робота з довідковою інформацією. Графічний редактор Paint.

    контрольная работа [54,2 K], добавлен 24.11.2008

  • Персональна СУБД Microsoft Access як засіб управління базами даних. Ознайомлення із її основними функціями – зберіганням і видобуванням даних, представленням інформації в зручному для користувача вигляді. Принципи розробки та роботи з даною програмою.

    контрольная работа [295,3 K], добавлен 14.05.2011

  • Організована структура, призначена для зберігання інформації. Системи управління базами даних. Зберігання та пошук інформації про можливості використання ресурсів психологічних тестів мережі Internet. Створення об'єктів бази даних та запити до них.

    курсовая работа [3,1 M], добавлен 21.10.2012

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

    курсовая работа [2,7 M], добавлен 10.11.2010

  • Поняття бази даних та основне призначення системи управління. Access як справжня реляційна модель баз даних. Можливості DDE і OLE. Модулі: Visual Basic for Applications програмування баз даних. Система управління базами даних Microsoft SQL Server 2000.

    реферат [41,2 K], добавлен 17.04.2010

  • Розрахунок кількості медичного персоналу усіх спеціальностей по районах і м. Тернополю. Створення табличних документів в Excel, їх опис й фільтрація даних. Таблиці, екранні й звітні форми, запити, макроси й головна кнопочна форма бази даних в Access.

    курсовая работа [6,3 M], добавлен 20.05.2015

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.