План
Введення ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .2
Глава 1. Теоретичні аспекти СУБД
1. Основні поняття ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .3
2. Функціональні можливості СУБД ... ... ... ... ... ... ... 7
3. Архітектура систем управління ... ... ... ... ... ... ... ... ... .. 9
4. Типи СУБД ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 13
Глава 2. Розробка бази даних ... ... ... ... ... ... 16
Висновок ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .21
Список літератури ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 22
Введення.
Розвиток засобів обчислювальної техніки забезпечило для створення і широкого використання систем обробки даних різноманітного призначення. Розробляються інформаційні системи для обслуговування різних систем діяльності, систем управління господарськими і технічними об'єктами, модельні комплекси для наукових досліджень, системи автоматизації проектування і виробництва, всілякі тренажери і навчальні системи. Однією з важливих передумов створення таких систем стала можливість оснащення їх «пам'яттю» для накопичення, зберігання і систематизація великих обсягів даних. Іншою істотною передумовою потрібно визнати розробку підходів, а також створення програмних і технічних засобів конструювання систем, призначених для колективного користування. У зв'язку з цим треба було розробити спеціальні методи і механізми управління такого роду спільно використовуваними ресурсами даних, які стали називатися базами даних. Дослідження і розробки, пов'язані з проектуванням, створенням та експлуатації баз даних, а також необхідних для цих цілей мовних і програмних інструментальних засобів призвели до появи самостійної гілки інформатики, що отримала назву системи управління даними.
Такі програмні комплекси виконують досить складний набір функцій, пов'язаний з централізованими управліннями, даними в базі даних інтерфейсах всієї сукупності її користувачів. По суті, система управління базами даних служить посередником між користувачами і базою даних.
В даний час розроблені і використовуються на персональних комп'ютерах близько двадцяти систем управління базами даних. Вони представляють користувачеві зручні засоби інтерактивної взаємодії з БД і мають розвинену мову програмування
Дана робота буде представлена деякі теоретичні аспекти теорії Б, основні поняття, функціональні можливості систем управління БД, а також описано БД по ринку побутової хімії міста Улан-Уде.
I. Теоретичні аспекти СУБД.
1. Основні поняття БД.
Будь-яка прикладна програма є відображенням будь - то частини реального світу і тому містить його формалізований опис у вигляді даних. Великі масиви даних розміщують, як правило, окремо від виконуваного програми, і організують у вигляді Бази даних. Починаючи з 60-х років для роботи з даними, стали використовувати особливі програмні комплекси, звані системами управління базами даних (СКБД). Системи управління базами даних відповідають за:
- Фізичне розміщення даних та їх описів;
- Пошук даних;
- Підтримка баз даних в актуальному стані;
- Захист даних від некоректних відновлень і несанкціонованого доступу;
обслуговування одночасних запитів до даних від декількох користувачів (прикладних програм).
Моделі даних.
Збережені в базі даних мають певну логічну структуру, тобто, представлені деякою моделлю, підтримуваної СУБД. До числа найважливіших відносяться такі моделі даних:
- Ієрархічна;
- Мережева;
- Реляційна;
- Об'єктно - орієнтована;
В ієрархічній моделі дані представляються у вигляді дерева (ієрархічної) структури. Вона зручна для роботи з ієрархічно упорядкованою інформацією і громіздка для інформації із складними логічними зв'язками.
Мережева модель означає представлення даних у вигляді довільного графа. Перевагою мережевої та ієрархічної моделей даних є можливість їх ефективної реалізації показників витрат пам'яті й оперативності. Недоліком мережевої моделі даних є висока складність і жорсткість схеми БД, побудованої на її основі.
Реляційна модель даних (РМД) назву отримала від англійського терміна Relation - ставлення. Модель даних описує деякий набір родових понять і ознак, якими повинні володіти всі конкретні СУБД і керовані ними БД, якщо вони грунтуються на цій моделі.
Об'єктно-орієнтовна модель даних - це коли в базі зберігаються не тільки дані, але і методи їх обробки у вигляді програмного коду. Це перспективний напрям, поки також не отримало активного поширення через складність створення і застосування подібних СУБД.
База даних - це сукупність записів різного типу, що містить перехресні посилання.
Файл - це сукупність записів одного типу, в якому перехресні посилання відсутні.
Більше того, у визначенні немає згадки про комп'ютерну архітектурі. Справа в тому, що, хоча в більшості випадків БД дійсно являє собою один або (частіше) кілька файлів, фізична їх організація істотно відрізняється від логічної. Таблиці можуть зберігатися як в окремих файлах, так і всі разом. І, навпаки, для зберігання однієї таблиці іноді використовуються декілька файлів. Для підтримки перехресних посилань і швидкого пошуку звичайно виділяються додаткові спеціальні файли.
Тому при роботі з базами даних звичайно застосовуються поняття більш високого логічного рівня: запис і таблиця, без заглиблення в подробиці їх фізичної структури.
Таким чином, сама по собі база даних - це лише набір таблиць з перехресними посиланнями. Щоб універсальним способом витягувати з неї групи записів, обробляти їх, змінювати і видаляти, потрібні спеціальні програми, називаються СУБД.
За характером використання СУБД ділять на персональні (СУБДП) і розраховані на багато (СУБДМ).
До персональних СУБД відносяться VISUAL FOXPRO, ACCESS та ін До багатокористувацьким СУБД відносяться, наприклад, СУБД ORACLE і INFORMIX. Сітьові СУБД включають в себе сервер БД і клієнтську частину, працюють в неоднорідному обчислювальному середовищі допускаються різні типи ЕОМ і різні операційні системи. Тому на базі СУБДМ можна створити інформаційну систему, яка функціонує по технології клієнт-сервер. Універсальність багатокористувацьких СУБД відображається відповідно на високій ціні і комп'ютерних ресурсах, необхідних для підтримки
СУБДП являє собою сукупність мовних і програмних засобів, призначених для створення, ведення і використання БД.
Персональні СУБД забезпечують можливість створення персональних БД і недорогих додатків, що працюють з ними, і при необхідності створення додатків, що працюють з сервером БД.
Для обробки команд користувача або операторів програм у СУБДП використовуються інтерпретатори команд (операторів) і компілятори. За допомогою компіляторів у ряді СУБДП можна отримувати виконавчі автономно програми-ехе-програми.
Забезпечення цілісності БД-необхідна умова успішного функціонування БД. Цілісність БД-властивість БД, що означає, що база даних містить повну й несуперечливу інформацію, Для забезпечення цілісності БД накладають обмеження цілісності у вигляді деяких умов, яким повинні задовольняти зберігаються в базі даних. Прикладом таких умов може служити обмеження діапазонів можливих значень атрибутів об'єктів, відомості про які зберігаються в БД, або відсутність повторюваних записів у таблицях реляційних БД.
Забезпечення безпеки досягається СУБД шифруванням прикладних програм, даних, захисту паролем, підтримкою рівнів доступу до бази даних, до окремої таблиці.
Розширення можливостей користувача СУБДП досягається за рахунок підключення систем поширення Сі чи Асемблера.
Підтримка функціонування в мережі забезпечується:
- Засобами управління доступом користувачів до спільно використовуваних даних, тобто засобами блокування файлів (таблиць), записів, полів, які в різній мірі реалізовані в різних СУБДП;
- Засобами механізму транзакцій, що забезпечують цілісність БД при функціонуванні в мережі.
Тепер розглянемо функції СУБД трохи докладніше:
Визначення даних.
СУБД повинна допускати визначення даних (зовнішні схеми, концептуальну схему, внутрішню схему, а також всі пов'язані відображення) у вихідній формі і перетворювати ці визначення в форму відповідних об'єктів. Інакше кажучи, СУБД повинна включати в себе компонент мовного процесора для різних мов визначень даних. СУБД має також «розуміти» синтаксис мови визначень даних.
Обробка даних.
СУБД повинна вміти обробляти запити користувача на вибірку, зміна або видалення існуючих даних в базі даних або на додавання нових даних у базу даних. Іншими словами, СУБД повинна включати в себе компонент процесора мови обробки даних.
Запити мови обробки даних бувають «плановані» і «не плановані».
1. Планований запит-це запит, необхідність якого передбачена заздалегідь. Адміністратор бази даних, можливо, має налаштувати фізичний проект БД таким чином, щоб гарантувати достатню швидкодію для таких запитів.
2. Чи не планований запит-це, навпаки, спеціальний запит, необхідність якого не була передбачена заздалегідь. Фізичний проект БД може підходити, а може і не підходити для розглянутого спеціального запиту. Загалом, отримання можливої найбільшої продуктивності для не планованих запитів являє собою одну з проблем СУБД. (Докладніше цю проблему буде обговорено в наступних частинах книги.)
Безпека та цілісність даних.
СУБД повинна контролювати запити користувачів і припиняти спроби порушення правил безпеки і цілісності, певні АБД.
Відновлення даних і дублювання.
СУБД або інший пов'язаний з нею програмний компонент, зазвичай званий адміністратором транзакцій, повинні здійснювати необхідний контроль над відновленням даних і дублюванням. Подробиці використання цих функцій системи наводяться далі в цій книзі.
Словник даних.
СУБД повинна забезпечити функцію словника даних. Сам словник даних можна по праву вважати БД (але не для користувача, а системою). Словник «містить дані про дані» (іноді звані метаданими), тобто визначення інших об'єктів системи, а не просто «сирі дані». Зокрема, вихідна і об'єктна форми різних схем (зовнішніх, концептуальних і т.д.) і відображень будуть збережені в словнику. Розширений словник буде включати також перехресні посилання, що показують, наприклад, які з програм яку частину БД використовують, які звіти потрібні тим чи іншим користувачам, які термінали підключені до системи і т.д. Словник може бути (а насправді навіть повинен бути) інтегрований в визначається ним БД, а значить, повинен містити опис самого себе. Звичайно, має бути можливість звернення до словника, як і до іншої БД, наприклад, для того дізнатися, які програми та / або користувачі будуть порушені при передбачуваному внесення зміни в систему. (Подальше обговорення цього питання наводиться в наступних розділах книги.)
Продуктивність.
Очевидно, що СУБД повинна виконувати всі зазначені функції з максимально можливою ефективністю.
Підводячи підсумок сказаному, можна зробити висновок, що в цілому призначенням СУБД є надання користувальницького інтерфейсу з БД. Інтерфейс користувача може бути визначений як межа в системі, нижче за яку всі невидимо для користувача. Отже, за визначенням користувальницький інтерфейс знаходиться на зовнішньому рівні. Тим не менш, іноді трапляються випадки, коли зовнішнє уявлення навряд чи значно відрізняється від відноситься, в міру в сучасних комерційних продуктах.
У висновку коротко порівняти описану СУБД з системою файлами (або з управлінням файлами). У своїй основі система управління файлами є компонентом загальної системи, яка управляє збереженими файлами; простіше кажучи, вона «ближче до диску», ніж СУБД. Таким чином, користувач системи управління файлами може створювати і знищувати збережені файли, а також виконувати прості операції вибірки та безпека збережених записів в таких файлах. Однак, на відміну від СУБД, системи управління файлами мають деякі недоліки.
2. Функціональні можливості СУБД.
Керуючим компонентом багатьох СУБД є ядро, яке виконує наступні функції:
- Управління даними у зовнішній пам'яті;
- Управління буферами оперативної пам'яті (робочими областями, в які здійснюється підкачка даних з бази для підвищення швидкості роботи);
- Управління транзакціями.
1. Безпосереднє управління даними у зовнішній пам'яті.
Ця функція включає забезпечення необхідних структур зовнішньої пам'яті, як для зберігання даних, які безпосередньо входять у базу даних так і для службових цілей. Наприклад, для прискорення доступу до даних у деяких випадках (звичайно для цього використовується індекс).
У деяких реалізаціях СУБД активно використовується можливість існуючих файлових систем. У інших робота проводиться аж до рівня пристроїв зовнішньої пам'яті. Але підкреслимо, що в розвинених СУБД користувач у будь-якому випадку не зобов'язаний знати використання СУБД файлову систему і якщо використовує, то, як організовані файли. Зокрема СУБД підтримує власну систему і найменування об'єктів баз даних.
2. Управління Бутор оперативної пам'яті.
СУБД зазвичай працює з БД, принаймні, цей розмір звичайно існує, більше доступний об'єму оперативної пам'яті. Що якщо при зверненні до будь-якого елементу даних буде проводитися обсяг із зовнішньою пам'яттю, то вся система буде працювати зі швидкістю пристрою зовнішньої пам'яті. Практичним єдиним способом реально збільшення цієї швидкості є буферизація даних в оперативній пам'яті. При цьому навіть якщо операційна система проводить загальносистемну буферизацію. Цього не достатньо для мети СУБД, яка має в своєму розпорядженні набагато більше інформації про корисність буферизації, тобто тієї чи іншої частини БД. Тому в розвинених СУБД підтримується власний набір буферів оперативної пам'яті, власної дисципліни заміни буферів. Зауважимо, що існують окремі напрями СУБД, які орієнтовано, але постійно присутні в оперативній пам'яті БД. Цей напрям грунтується на припущення, що на стільки великий, що дозволить, не турбується про буферизації. (Пака ця робота знаходиться в стадії розвитку).
3. Управління транзакціями.
Транзакція - це послідовність операцій над БД, розглянута СУБД як єдине ціле. При виконанні транзакція може бути або успішно завершена, і СУБД зафіксує зроблені зміни у зовнішній пам'яті, або, наприклад, при збої в апаратній частині ПК, жодного з змін не відіб'ється в БД. Поняття транзакція необхідно для підтримки логічної цілісності БД. Таким чином, підтримка механізму транзакції є обов'язковою умовою навіть однокористувацьких СУБД. (Якщо така система заслуговує СУБД). Але поняття транзакція набагато більш важливо багато користувач СУБД, то властивість, то кожна транзакція починається при цілісному стані БД і залишає цей стан цілісне після свого завершення, робить дуже зручним, використання поняття транзакція як одиниці активності користувача по відношенню БД. При відповідному управлінні керуючими транзакціями з боку СУБД кожним використанням може в принципі відчувати себе єдиним користувачем СУБД. Управління транзакції багатокористувацької СУБД пов'язані важливі поняття серіалізация транзакції і серіального плану виконання суміші транзакції. Під стерилізацією виконанні паралельно серіалізация розуміють такий порядок планування їх робіт при якій сумарний ефект суміші транзакції еквівалентний ефекту їх деякого послідовного управління. Серіальний план виконання суміші транзакції це такий план, який призводить до серіалізация транзакції. Що якщо вдається домогтися дійсного серіального виконання суміші транзакції, то для кожного користувача з ініціативи, якої освічена транзакція присутність інших транзакцій буде непомітно (якщо не вважати деякого уповільнення роботи в порівнянні з одно користуванням режимом). Існує кілька базових алгоритмів серіалізация транзакції. Централізованих СУБД найбільш поширені алгоритми, засновані на синхронізації захоплення об'єктів БД. При використанні будь-якого алгоритму можлива ситуація конфлікту між двома або більше транзакціями з доступу об'єкта БД. У цьому випадку для підтримки серіалізация необхідні, виконувати відкат однієї чи більше транзакції. Це один із випадків, коли користувач багатокористувацької СУБД може реально (і досить неприємно) відчути присутність в системі транзакції інших користувачів.
Введення ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .2
Глава 1. Теоретичні аспекти СУБД
1. Основні поняття ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .3
2. Функціональні можливості СУБД ... ... ... ... ... ... ... 7
3. Архітектура систем управління ... ... ... ... ... ... ... ... ... .. 9
4. Типи СУБД ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 13
Глава 2. Розробка бази даних ... ... ... ... ... ... 16
Висновок ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .21
Список літератури ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 22
Введення.
Розвиток засобів обчислювальної техніки забезпечило для створення і широкого використання систем обробки даних різноманітного призначення. Розробляються інформаційні системи для обслуговування різних систем діяльності, систем управління господарськими і технічними об'єктами, модельні комплекси для наукових досліджень, системи автоматизації проектування і виробництва, всілякі тренажери і навчальні системи. Однією з важливих передумов створення таких систем стала можливість оснащення їх «пам'яттю» для накопичення, зберігання і систематизація великих обсягів даних. Іншою істотною передумовою потрібно визнати розробку підходів, а також створення програмних і технічних засобів конструювання систем, призначених для колективного користування. У зв'язку з цим треба було розробити спеціальні методи і механізми управління такого роду спільно використовуваними ресурсами даних, які стали називатися базами даних. Дослідження і розробки, пов'язані з проектуванням, створенням та експлуатації баз даних, а також необхідних для цих цілей мовних і програмних інструментальних засобів призвели до появи самостійної гілки інформатики, що отримала назву системи управління даними.
Такі програмні комплекси виконують досить складний набір функцій, пов'язаний з централізованими управліннями, даними в базі даних інтерфейсах всієї сукупності її користувачів. По суті, система управління базами даних служить посередником між користувачами і базою даних.
В даний час розроблені і використовуються на персональних комп'ютерах близько двадцяти систем управління базами даних. Вони представляють користувачеві зручні засоби інтерактивної взаємодії з БД і мають розвинену мову програмування
Дана робота буде представлена деякі теоретичні аспекти теорії Б, основні поняття, функціональні можливості систем управління БД, а також описано БД по ринку побутової хімії міста Улан-Уде.
I. Теоретичні аспекти СУБД.
1. Основні поняття БД.
Будь-яка прикладна програма є відображенням будь - то частини реального світу і тому містить його формалізований опис у вигляді даних. Великі масиви даних розміщують, як правило, окремо від виконуваного програми, і організують у вигляді Бази даних. Починаючи з 60-х років для роботи з даними, стали використовувати особливі програмні комплекси, звані системами управління базами даних (СКБД). Системи управління базами даних відповідають за:
- Фізичне розміщення даних та їх описів;
- Пошук даних;
- Підтримка баз даних в актуальному стані;
- Захист даних від некоректних відновлень і несанкціонованого доступу;
обслуговування одночасних запитів до даних від декількох користувачів (прикладних програм).
Моделі даних.
Збережені в базі даних мають певну логічну структуру, тобто, представлені деякою моделлю, підтримуваної СУБД. До числа найважливіших відносяться такі моделі даних:
- Ієрархічна;
- Мережева;
- Реляційна;
- Об'єктно - орієнтована;
В ієрархічній моделі дані представляються у вигляді дерева (ієрархічної) структури. Вона зручна для роботи з ієрархічно упорядкованою інформацією і громіздка для інформації із складними логічними зв'язками.
Мережева модель означає представлення даних у вигляді довільного графа. Перевагою мережевої та ієрархічної моделей даних є можливість їх ефективної реалізації показників витрат пам'яті й оперативності. Недоліком мережевої моделі даних є висока складність і жорсткість схеми БД, побудованої на її основі.
Реляційна модель даних (РМД) назву отримала від англійського терміна Relation - ставлення. Модель даних описує деякий набір родових понять і ознак, якими повинні володіти всі конкретні СУБД і керовані ними БД, якщо вони грунтуються на цій моделі.
Об'єктно-орієнтовна модель даних - це коли в базі зберігаються не тільки дані, але і методи їх обробки у вигляді програмного коду. Це перспективний напрям, поки також не отримало активного поширення через складність створення і застосування подібних СУБД.
База даних - це сукупність записів різного типу, що містить перехресні посилання.
Файл - це сукупність записів одного типу, в якому перехресні посилання відсутні.
Більше того, у визначенні немає згадки про комп'ютерну архітектурі. Справа в тому, що, хоча в більшості випадків БД дійсно являє собою один або (частіше) кілька файлів, фізична їх організація істотно відрізняється від логічної. Таблиці можуть зберігатися як в окремих файлах, так і всі разом. І, навпаки, для зберігання однієї таблиці іноді використовуються декілька файлів. Для підтримки перехресних посилань і швидкого пошуку звичайно виділяються додаткові спеціальні файли.
Тому при роботі з базами даних звичайно застосовуються поняття більш високого логічного рівня: запис і таблиця, без заглиблення в подробиці їх фізичної структури.
Таким чином, сама по собі база даних - це лише набір таблиць з перехресними посиланнями. Щоб універсальним способом витягувати з неї групи записів, обробляти їх, змінювати і видаляти, потрібні спеціальні програми, називаються СУБД.
За характером використання СУБД ділять на персональні (СУБДП) і розраховані на багато (СУБДМ).
До персональних СУБД відносяться VISUAL FOXPRO, ACCESS та ін До багатокористувацьким СУБД відносяться, наприклад, СУБД ORACLE і INFORMIX. Сітьові СУБД включають в себе сервер БД і клієнтську частину, працюють в неоднорідному обчислювальному середовищі допускаються різні типи ЕОМ і різні операційні системи. Тому на базі СУБДМ можна створити інформаційну систему, яка функціонує по технології клієнт-сервер. Універсальність багатокористувацьких СУБД відображається відповідно на високій ціні і комп'ютерних ресурсах, необхідних для підтримки
СУБДП являє собою сукупність мовних і програмних засобів, призначених для створення, ведення і використання БД.
Персональні СУБД забезпечують можливість створення персональних БД і недорогих додатків, що працюють з ними, і при необхідності створення додатків, що працюють з сервером БД.
Для обробки команд користувача або операторів програм у СУБДП використовуються інтерпретатори команд (операторів) і компілятори. За допомогою компіляторів у ряді СУБДП можна отримувати виконавчі автономно програми-ехе-програми.
Забезпечення цілісності БД-необхідна умова успішного функціонування БД. Цілісність БД-властивість БД, що означає, що база даних містить повну й несуперечливу інформацію, Для забезпечення цілісності БД накладають обмеження цілісності у вигляді деяких умов, яким повинні задовольняти зберігаються в базі даних. Прикладом таких умов може служити обмеження діапазонів можливих значень атрибутів об'єктів, відомості про які зберігаються в БД, або відсутність повторюваних записів у таблицях реляційних БД.
Забезпечення безпеки досягається СУБД шифруванням прикладних програм, даних, захисту паролем, підтримкою рівнів доступу до бази даних, до окремої таблиці.
Розширення можливостей користувача СУБДП досягається за рахунок підключення систем поширення Сі чи Асемблера.
Підтримка функціонування в мережі забезпечується:
- Засобами управління доступом користувачів до спільно використовуваних даних, тобто засобами блокування файлів (таблиць), записів, полів, які в різній мірі реалізовані в різних СУБДП;
- Засобами механізму транзакцій, що забезпечують цілісність БД при функціонуванні в мережі.
Тепер розглянемо функції СУБД трохи докладніше:
Визначення даних.
СУБД повинна допускати визначення даних (зовнішні схеми, концептуальну схему, внутрішню схему, а також всі пов'язані відображення) у вихідній формі і перетворювати ці визначення в форму відповідних об'єктів. Інакше кажучи, СУБД повинна включати в себе компонент мовного процесора для різних мов визначень даних. СУБД має також «розуміти» синтаксис мови визначень даних.
Обробка даних.
СУБД повинна вміти обробляти запити користувача на вибірку, зміна або видалення існуючих даних в базі даних або на додавання нових даних у базу даних. Іншими словами, СУБД повинна включати в себе компонент процесора мови обробки даних.
Запити мови обробки даних бувають «плановані» і «не плановані».
1. Планований запит-це запит, необхідність якого передбачена заздалегідь. Адміністратор бази даних, можливо, має налаштувати фізичний проект БД таким чином, щоб гарантувати достатню швидкодію для таких запитів.
2. Чи не планований запит-це, навпаки, спеціальний запит, необхідність якого не була передбачена заздалегідь. Фізичний проект БД може підходити, а може і не підходити для розглянутого спеціального запиту. Загалом, отримання можливої найбільшої продуктивності для не планованих запитів являє собою одну з проблем СУБД. (Докладніше цю проблему буде обговорено в наступних частинах книги.)
Безпека та цілісність даних.
СУБД повинна контролювати запити користувачів і припиняти спроби порушення правил безпеки і цілісності, певні АБД.
Відновлення даних і дублювання.
СУБД або інший пов'язаний з нею програмний компонент, зазвичай званий адміністратором транзакцій, повинні здійснювати необхідний контроль над відновленням даних і дублюванням. Подробиці використання цих функцій системи наводяться далі в цій книзі.
Словник даних.
СУБД повинна забезпечити функцію словника даних. Сам словник даних можна по праву вважати БД (але не для користувача, а системою). Словник «містить дані про дані» (іноді звані метаданими), тобто визначення інших об'єктів системи, а не просто «сирі дані». Зокрема, вихідна і об'єктна форми різних схем (зовнішніх, концептуальних і т.д.) і відображень будуть збережені в словнику. Розширений словник буде включати також перехресні посилання, що показують, наприклад, які з програм яку частину БД використовують, які звіти потрібні тим чи іншим користувачам, які термінали підключені до системи і т.д. Словник може бути (а насправді навіть повинен бути) інтегрований в визначається ним БД, а значить, повинен містити опис самого себе. Звичайно, має бути можливість звернення до словника, як і до іншої БД, наприклад, для того дізнатися, які програми та / або користувачі будуть порушені при передбачуваному внесення зміни в систему. (Подальше обговорення цього питання наводиться в наступних розділах книги.)
Продуктивність.
Очевидно, що СУБД повинна виконувати всі зазначені функції з максимально можливою ефективністю.
Підводячи підсумок сказаному, можна зробити висновок, що в цілому призначенням СУБД є надання користувальницького інтерфейсу з БД. Інтерфейс користувача може бути визначений як межа в системі, нижче за яку всі невидимо для користувача. Отже, за визначенням користувальницький інтерфейс знаходиться на зовнішньому рівні. Тим не менш, іноді трапляються випадки, коли зовнішнє уявлення навряд чи значно відрізняється від відноситься, в міру в сучасних комерційних продуктах.
У висновку коротко порівняти описану СУБД з системою файлами (або з управлінням файлами). У своїй основі система управління файлами є компонентом загальної системи, яка управляє збереженими файлами; простіше кажучи, вона «ближче до диску», ніж СУБД. Таким чином, користувач системи управління файлами може створювати і знищувати збережені файли, а також виконувати прості операції вибірки та безпека збережених записів в таких файлах. Однак, на відміну від СУБД, системи управління файлами мають деякі недоліки.
2. Функціональні можливості СУБД.
Керуючим компонентом багатьох СУБД є ядро, яке виконує наступні функції:
- Управління даними у зовнішній пам'яті;
- Управління буферами оперативної пам'яті (робочими областями, в які здійснюється підкачка даних з бази для підвищення швидкості роботи);
- Управління транзакціями.
1. Безпосереднє управління даними у зовнішній пам'яті.
Ця функція включає забезпечення необхідних структур зовнішньої пам'яті, як для зберігання даних, які безпосередньо входять у базу даних так і для службових цілей. Наприклад, для прискорення доступу до даних у деяких випадках (звичайно для цього використовується індекс).
У деяких реалізаціях СУБД активно використовується можливість існуючих файлових систем. У інших робота проводиться аж до рівня пристроїв зовнішньої пам'яті. Але підкреслимо, що в розвинених СУБД користувач у будь-якому випадку не зобов'язаний знати використання СУБД файлову систему і якщо використовує, то, як організовані файли. Зокрема СУБД підтримує власну систему і найменування об'єктів баз даних.
2. Управління Бутор оперативної пам'яті.
СУБД зазвичай працює з БД, принаймні, цей розмір звичайно існує, більше доступний об'єму оперативної пам'яті. Що якщо при зверненні до будь-якого елементу даних буде проводитися обсяг із зовнішньою пам'яттю, то вся система буде працювати зі швидкістю пристрою зовнішньої пам'яті. Практичним єдиним способом реально збільшення цієї швидкості є буферизація даних в оперативній пам'яті. При цьому навіть якщо операційна система проводить загальносистемну буферизацію. Цього не достатньо для мети СУБД, яка має в своєму розпорядженні набагато більше інформації про корисність буферизації, тобто тієї чи іншої частини БД. Тому в розвинених СУБД підтримується власний набір буферів оперативної пам'яті, власної дисципліни заміни буферів. Зауважимо, що існують окремі напрями СУБД, які орієнтовано, але постійно присутні в оперативній пам'яті БД. Цей напрям грунтується на припущення, що на стільки великий, що дозволить, не турбується про буферизації. (Пака ця робота знаходиться в стадії розвитку).
3. Управління транзакціями.
Транзакція - це послідовність операцій над БД, розглянута СУБД як єдине ціле. При виконанні транзакція може бути або успішно завершена, і СУБД зафіксує зроблені зміни у зовнішній пам'яті, або, наприклад, при збої в апаратній частині ПК, жодного з змін не відіб'ється в БД. Поняття транзакція необхідно для підтримки логічної цілісності БД. Таким чином, підтримка механізму транзакції є обов'язковою умовою навіть однокористувацьких СУБД. (Якщо така система заслуговує СУБД). Але поняття транзакція набагато більш важливо багато користувач СУБД, то властивість, то кожна транзакція починається при цілісному стані БД і залишає цей стан цілісне після свого завершення, робить дуже зручним, використання поняття транзакція як одиниці активності користувача по відношенню БД. При відповідному управлінні керуючими транзакціями з боку СУБД кожним використанням може в принципі відчувати себе єдиним користувачем СУБД. Управління транзакції багатокористувацької СУБД пов'язані важливі поняття серіалізация транзакції і серіального плану виконання суміші транзакції. Під стерилізацією виконанні паралельно серіалізация розуміють такий порядок планування їх робіт при якій сумарний ефект суміші транзакції еквівалентний ефекту їх деякого послідовного управління. Серіальний план виконання суміші транзакції це такий план, який призводить до серіалізация транзакції. Що якщо вдається домогтися дійсного серіального виконання суміші транзакції, то для кожного користувача з ініціативи, якої освічена транзакція присутність інших транзакцій буде непомітно (якщо не вважати деякого уповільнення роботи в порівнянні з одно користуванням режимом). Існує кілька базових алгоритмів серіалізация транзакції. Централізованих СУБД найбільш поширені алгоритми, засновані на синхронізації захоплення об'єктів БД. При використанні будь-якого алгоритму можлива ситуація конфлікту між двома або більше транзакціями з доступу об'єкта БД. У цьому випадку для підтримки серіалізация необхідні, виконувати відкат однієї чи більше транзакції. Це один із випадків, коли користувач багатокористувацької СУБД може реально (і досить неприємно) відчути присутність в системі транзакції інших користувачів.
4. Архітектура СУБД.
Три рівня архітектури.
Архітектура ANSI / SPARC включає три рівні: внутрішній, концептуальний і зовнішній. У загальних рисах вони є наступними:
- Внутрішній рівень-це рівень, найбільш близький до фізичного зберігання, тобто пов'язаний зі способами збереження інформації на фізичних пристроях зберігання.
- Зовнішній рівень найбільш близький до користувачів, тобто він пов'язаний зі способами представлення даних для окремих користувачів.
-
Зовнішній рівень (індивідуальні уявлення користувачів).
Концептуальний рівень (узагальнене уявлення користувачів).
Внутрішній рівень (подання до
пам'яті).
Якщо зовнішній рівень з індивідуальними уявленнями користувачів, то концептуальний рівень пов'язаний з узагальненим уявленням користувачів. Інакше кажучи, може бути декілька зовнішніх уявлень, кожне з яких складається з більш-менш абстрактного уявлення певної частини БД, і може бути тільки одне концептуальне уявлення, що складається з абстрактного уявлення БД в цілому.
Зовнішній рівень-це індивідуальний рівень користувача. Користувач може бути прикладним програмістом або кінцевим користувачем з будь-яким рівнем професійної підготовки. Особливе місце серед користувачів займає адміністратор БД. (На відміну від інших користувачів його цікавить також концептуальний і внутрішній рівень.)
У кожного користувача є своя мова спілкування.
- Для прикладного програміста це або один з найпоширеніших мов програмування, такої як C, COBOL або PL / 1, або спеціальна мова розглянутої системи. Такі оригінальні мови називають (неформально!) мовами четвертого покоління на тій підставі, що машинний код, мова асемблера і такі мови, як COBOL, можна вважати мовами трьох перших «поколінь», а оригінальні мови модернізовані у порівнянні з мовами третього покоління так само, як мови третього покоління покращувані в порівнянні з мовою асемблера.
- Для кінцевого користувача це спеціальна мова запитів, або мова спеціального призначення, можливо, заснований на формах і меню, створений спеціально з урахуванням вимог і підтримуваний деяким оперативним додатком.
Загалом, зовнішнє уявлення складається з безлічі екземплярів кожного типу зовнішньої записи, які, у свою чергу, аж ніяк не обов'язково повинні збігатися з ранимими записами. Що знаходиться у розпорядженні користувача под'язик даних визначено в термінах зовнішніх записів; наприклад, операція вибірки мови обробки даних буде проводити вибірку з примірників зовнішніх, а не збережених записів.
Концептуальний рівень.
Концептуальне подання - це подання всієї інформації БД в дещо більш абстрактній формі (як і випадку зовнішнього подання) в порівнянні з фізичним способом зберігання даних. Однак концептуальне уявлення істотно відрізняється від способу подання даних якому-небудь окремому користувачеві. Взагалі кажучи, концептуальне уявлення - це уявлення даних такими, які «вони є насправді», а не такими, якими змушений їх бачити користувач в рамках, наприклад, певної мови або використовуваного апаратного забезпечення.
Концептуальне уявлення складається з безлічі екземплярів кожного типу концептуальної запису. Наприклад, воно може складатися з набору екземплярів записів, що містять інформацію про окремі, плюс набір примірників, що містять інформацію про деталі і т.д. Концептуальна запис зовсім не обов'язково повинна збігатися з зовнішньої записом, з одного боку, і з збереженої записом-з іншого.
Концептуальне уявлення визначається за допомогою концептуальної схеми, яка включає визначення кожного типу концептуальних записів. Концептуальна схема використовує іншу мову визначення даних - концептуальний.
Концептуальне подання - це представлення всього вмісту бази даних, а концептуальна схема - це визначення такого подання. Проте було б помилкою вважати, що концептуальна схема - це не більше ніж набір визначень, що більше нагадують прості відносини записів у програмі на мові COBOL (або якому-небудь іншому).
Тепер перейдемо до більш детального дослідження трьох рівнів архітектури.
Внутрішній рівень.
Третім рівнем архітектури є внутрішній рівень. Внутрішнє подання - це подання нижнього рівня всієї БД; воно складається з багатьох екземплярів кожного типу внутрішньої запису. Термін «внутрішня запис» належить термінології ANSI / SPARC і означає конструкцію, звану збереженої записом. Внутрішнє подання так само, як зовнішнє і концептуальне, не пов'язане з фізичним рівнем, так як в ньому не розглядаються фізичні області пристрої зберігання, такі як циліндри та доріжки. Іншими словами, внутрішнє представлення передбачає нескінченне лінійне адресний простір; подробиці того, як адресний простір відображує на фізичний пристрій зберігання, дуже залежать від системи і навмисне не включені в загальну архітектуру.
Внутрішнє представлення описується за допомогою внутрішньої схеми, яка визначає не тільки різні типи збережених записів, але також існуючі індекси, способи подання збережених полів, фізичну послідовність збережених записів і т.д. Внутрішня схема пишеться з використанням ще однієї мови визначення даних - внутрішнього.
У висновку відзначимо, що в деяких виняткових ситуаціях прикладні програми, зокрема ті, які називають утилітами можуть виконувати операції безпосередньо на внутрішньому, а не на зовнішньому рівні. Звичайно, такою практикою користуватися не рекомендується; вона визначає ризик з точки зору безпеки (правила безпеки ігноруються) і цілісності (правила цілісності теж ігнорується), до того ж програма буде залежати від завантажених даних, але іноді це може бути єдиним способом досягти виконання необхідної функції або добитися необхідної швидкодії - так само, як користувачу мови високого рівня іноді з тих же причин необхідно вдатися до мови асемблера.
Програми, що використають бази даних, зазвичай прийнято відносити до однієї з програмних архітектур, які мають свої плюси і мінуси.
Локальна архітектура.
І програма, і база даних розташовані на одному комп'ютері. У такій архітектурі працює більшість настільних додатків.
Файл - серверна архітектура.
База даних розташована на потужному виділеному комп'ютері (сервері), а персональні комп'ютери підключені до нього по локальній мережі. На цих комп'ютерах встановлені клієнтські програми, які звертаються до бази даних по мережі. Перевага такої архітектури полягає в можливості одночасної роботи декількох користувачів з однією базою даних.
Недолік такого підходу - великі обсяги інформації, переданої по мережі. Вся обробка виконується на клієнтських місцях, де фактично формується копія бази даних. Це приводиться до обмеження максимально можливого числа користувачів і більших затримок при роботі з базою. Ці затримки викликаються тим, що на рівні конкретної таблиці одночасний доступ неможливий. Поки програма на одному з клієнтських місць не закінчить роботу з таблицею (наприклад, не виконає модифікацію записів), інші програми не можуть звертатися до цієї таблиці. Це називається блокуванням на рівні таблиці і виключає виникнення плутанини в її вміст.
Клієнт - серверна архітектура.
У такій архітектурі на сервері не тільки зберігається БД, а й працює програма СУБД, обробна запити користувачів і повертає їм набори записів. При цьому програми користувачів вже не працюють, наприклад, з БД як набором фізичних фалів, а звертаються до СУБД, яка виконує операції. Навантаження з клієнтських місць при цьому знімається, тому що більша частина роботи відбувається на сервері. СУБД автоматично стежить за цілісністю і збереженням БД, а також контролює доступ до інформації за допомогою служби паролів. Клієнт - серверні СУБД допускають блоки на рівні запису і навіть окремого поля. Це означає, що з таблицею може працювати будь-яке число користувачів, але доступ до функції зміни конкретної запису або одного з її полів забезпечений тільки одному з них.
Основний недолік цієї архітектури не дуже висока надійність. Якщо сервер виходить з ладу, вся робота зупиняється.
Розподілена архітектура.
У мережі працює кілька серверів, і таблиці баз даних розподілені між ними для досягнення підвищеної ефективності. На кожному сервері функціонує своя копія СУБД. Крім того, в подібній архітектурі зазвичай використовуються спеціальні програми, так звані сервери додатків. Вони дозволяють оптимізувати обробку запитів великої кількості користувачів і рівномірно розподілити навантаження між комп'ютерами в мережі.
Недолік розподіленої архітектури полягає в досить складному і дорогому процесі її створення та супроводу (адміністрування), а також а високих вимогах до сервером комп'ютерів.
Інтернет - архітектура.
Доступ до бази даних і СУБД (розповсюджених на одному комп'ютері або в мережі) здійснюється з оглядача за стандартним протоколом. Це ставить мінімальні вимоги до клієнтського обладнання. Такі програми називають «тонкими клієнтами», бо вони здатні працювати навіть на ПК з процесором 80386. Завдяки стандартизації всіх протоколів і впроваджувати. Наприклад, можна не організовувати локальну мережу, а звертатися до сервера через Інтернет в локальній мережі (в такому випадку говорять про технології інтранет). У цьому випадку не потрібно розробляти спеціальні клієнтські програми або придумувати власні специфікації обміну даними між сервером і клієнтськими місцями. Досить використовувати готові оглядача і програмні рішення.
4. Типи СУБД.
Системою управління базами даних називають програмну систему, призначену для створення на ЕОМ загальної бази даних для безлічі додатків, підтримки її актуальному стані та забезпечення ефективності доступу користувачів до містяться в ній даними в рамках наданих їм повноважень. СУБД призначена, таким чином, для централізованого управління БД як соціальним ресурсом в інтересах всієї сукупностей її користувачів. Доступ до бази даних окремих користувачів при цьому можливий тільки за посередництвом СУБД.
За ступенем їх універсальності розрізняються два види СУБД - системи загального призначення і спеціалізовані системи. СУБД загального призначення не орієнтовані на будь - яку конкретну предметну область або на інформаційні потреби конкретної групи користувачів. Кожна система такого роду реалізується як програмний продукт, здатний функціонувати на деякій моделі ЕОМ у певної обстановки, і поставляється багатьом користувачам як комерційне виріб. СУБД загального призначення мають засоби налаштування на роботу з конкретною БД в умовах конкретного застосування.
Використання СУБД загального призначення в якості інструментального засобу для створення автоматизованих інформаційних систем, заснованих на технології БД, дозволяє істотно скорочувати терміни розробки, економити трудові ресурси. Розвинені функціональні можливості таких СУБД, притаманна їм, як правило, функціональна надмірність дозволяють мати значний «запас потужності», необхідний для безболісного еволюційного розвитку побудованих на їх основі інформаційних систем в рамках їх життєвого циклу. Разом з тим засоби налаштування дають можливість досягти прийнятного рівня продуктивності інформаційної системи в процесі її експлуатації.
Однак у деяких випадках доступні СУБД загального призначення не дозволяють домогтися необхідних характеристик продуктивності і / або задовольнити задані обмеження за обсягом пам'яті, що надається для зберігання БД. Тоді доводиться розробляти спеціалізовану СУБД для даного конкретного застосування. Вирішення зазначених проблем при цьому може виявитися можливим завдяки знанню специфічних особливостей даного застосування, до яких виявляються нечутливими засоби налаштування доступних СУБД загального призначення, або за рахунок обмеження будь-яких функцій системи, що не мають життєво важливого значення. Як правило, в цій ролі виявляються, перш за все функції, що забезпечують комфортну роботу користувача.
Створення спеціалізованої СУБД - вельми трудомістка справа навіть у порівняно простих випадках, і для того, щоб обрати цей шлях, потрібно мати справді вагомі підстави і тверду убеждаемость в неможливості або недоцільності використання будь - якої СУБД загального призначення.
СУБД загального призначення - це складні програмні комплекси, призначені для виконання всієї сукупності функцій, пов'язаних зі створенням та експлуатацією БД інформаційної системи. Вони дозволяють визначити структуру створюваної БД, ініціалізувати її і провести початкове завантаження даних. Системні механізми виконують також функції управління ресурсами середовища зберігання, забезпечення логічної і фізичної незалежності даних, надання доступу користувачам до БД, захисту логічної цілісності БД, забезпечення її фізичної цілісності - захисту від руйнувань. Інша важлива група функцій - управління повноваженнями користувачів на доступ до БД, настроювання на конкретні умови застосування, організація паралельного доступу користувачів до бази даних в соціальній користувача середовищі, підтримка діяльності системного персоналу, відповідального за експлуатацію БД.
Для створення БД розробник описує її логічну структуру, організацію в середовищі зберігання, а також способи бачення бази даних користувачами. При цьому використовуються надаються СУБД мовні засоби визначення даних, і система налаштовується на роботу з конкретною БД. Такі описи БД називаються відповідно схемою (або логічною схемою, або концептуальною схемою) БД, схемою зберігання (або внутрішньою схемою) і зовнішніми схемами.
Обробляючи схеми БД, СУБД створює порожню БД необхідної структури - сховище, яке можна далі наповнити даними про предметної області почати експлуатувати для задоволення інформаційних потреб користувачів.
Принципово важлива властивість СУБД полягає в тому, що вона дозволяє розрізняти і підтримувати два незалежних погляду на БД - погляд користувача, втілювалася в «логічному» поданні даних, і «погляд» системи - «фізичне» уявлення, що характеризує організацію збережених даних. Користувача не цікавить при його роботі з БД байти і біти, що представляють дані в середовищі зберігання, їх розміщення в пам'яті, покажчика, підтримують зв'язки між структурними різними компонентами даних, що зберігаються, обрані методи доступу. У той же час ці фактори важливі для виконання функцій управління даними самої СУБД.
Забезпечення логічної незалежності даних - одна з найважливіших функцій СУБД, що надає певну ступінь свободи варіації «логічного» подання БД без необхідності відповідної модифікації «фізичного» уявлення. Завдяки цьому досягається можливість адаптації погляду користувача на БД до його реальним потребам, конструювання різних «логічних» поглядів на одну й ту ж «фізичну» БД, що дуже важливо в соціальній користувача середовищі.
Під «фізичної» незалежністю даних розуміється здатність СУБД надавати деяку свободу модифікації способів організації БД в середовищі зберігання, не викликаючи необхідність внесення відповідних змін до «логічне» уявлення. Завдяки цьому вносити зміни до організації збережених даних, проводити налаштування системи з метою підвищення її ефективності, не зачіпаючи створених прикладних програм, що використовують базу даних. «Фізична» незалежність даних реалізується в СУБД за рахунок тих же самих трансформаційних механізмів архітектури системи, які забезпечують «логічну» незалежність даних.
Підтримка логічної цілісності (несуперечності) бази даних - інша важлива функція СУБД. У розвинених системах обмеження цілісності бази даних оголошуються у схемі бази даних, і їх перевірка здійснюється при кожному оновленні об'єктів даних або зв'язків між ними, що є аргументами таких обмежень.
Глава 2. Розробка бази даних по ринку побутової хімії.
Процес розробки (проектування) бази даних включає два етапи: розробку логічної організації бази даних і створення її на носії. Логічна організація бази даних - це надання користувача про предметної області, інформація про яку повинна зберігатися в базі даних. Під фізичною організацією бази даних розуміється сукупність засобів і методів розміщення даних у зовнішній пам'яті і на їх основі внутрішня модель даних. Внутрішня модель є засобом відображення логічної моделі даних, показує, яким чином записи розміщуються в базі даних, як вони упорядковуються, як організуються зв'язку, яким шляхом можна здійснити вибірку і так далі.
В даний час розроблені і використовуються на персональних комп'ютерах близько двадцяти систем управління базами даних. Вони представляють користувачеві зручні засоби інтерактивної взаємодії з БД і мають розвинену мову програмування. Однією з найпопулярніших настільних програмних СУБД є Microsoft Access.
Однією з основних причин такої популярності Access полягає в тому, що, є по суті настільної СУБД, цей додаток увібрало в себе багато можливостей систем управління реляційними базами даних архітектури клієнт-сервер, званої також SQL базою даних. Незважаючи на те, що, Access включають в себе складні функції і може послужити прекрасним інструментом для професійного розробника додатків БД, його використання не повинне викликати проблем і у непрофесійної користувачів і навіть тих, хто раніше не працював з СУБД. Кнопки на панелях інструментів дублюють основні команди меню, розширений набір майстрів і налаштувань управляє практично всіма параметрами створення і зміни об'єктів БД (таблиць, форм, звітів, запитів і т.д.). За допомогою ACCESS можна створювати багатокористувацьких додатків, в яких файли бази даних є розділяютьсяресурсами в локальній мережі. У ACCESS реалізованого доступу до об'єктів бази даних. Microsoft Access для зберігання об'єктів БД має власну унікальну структуру для зберігання всіх зв'язаних таблиць, форм, звітів, запитів і макрософт в одному файлі. Також має можливість імпорту та експорту даних в багато широкі поширені формати БД, електронних таблиць та текстових файлів. ACCESS дозволяє пов'язувати БД із зовнішніми таблицями в форматах dBase, FoxPro, Paradox і працювати з ними у вихідному форматі. Також Access можна використовувати в якості клієнтської частини архітектури клієнт-сервер, що забезпечує застосування Microsoft Access не тільки в якості професійної системи управління бази даних, але і як потужний інструментальний засіб для створення додатків клієнт-сервер.
База даних по побутовій техніці міста Улан-Уде була розроблена в програмі Microsoft Access. Вся необхідна інформація представлена у двох таблицях. Таблиця бази даних - це сукупність відомостей. Так, наприклад, у таблиці «торгові салони» відображена інформація про торговельне салоні, адресу, телефон (рис. 1), а в таблиці «товари» - інформація про послуги, торговим салоном товари (рис. 2). Кожне поле надає собою стовпець таблиці і містить певну категорію інформації. Кожна запис надає собою рядок таблиці і містить інформацію про певний товар. Можна створити взаємозв'язку між таблицями (Мал. 10), замість того, щоб зберігати всю інформацію в одній великій таблиці, уникаючи тим самим непотрібного дублювання даних, економії пам'яті комп'ютера, а також збільшення швидкості і точності обробки інформації. Так, наприклад, кожен запис в таблиці «всі товари» містить інформацію про фірму і наданих нею товари (рис. 3). Запити використовуються приблизно також, як і таблиці. Ви можете відкрити запит і переглянути набір даних у табличному поданні. При створенні запиту вказуються таблиці, з яких буде проводиться вибірка даних, вказуються поля таблиці, які повинні бути внесені в результат запиту, зазначена умова відбору даних. У даному випадку при виборі запиту «пошук по салону» (рис. 4), вказавши назву салону, ви отримаєте цікаву для вас інформацію про товари в цьому салоні.
При виборі запиту «пошук по товарах» (рис. 3) ви отримаєте інформацію про запропоновані фірмою товари.
За допомогою форм можна відображати дані, що містяться в таблицях чи запитах, в ще більш зручне для сприйняття вигляді. За допомогою форм можна додавати в таблиці нові дані або змінювати і видаляти існуючі. Форма може містити малюнки, графіки та інші об'єкти. Форми створюються з набору окремих елементів, званих елементами управління (графічний об'єкт для надання даних). Форму для надання даних Microsoft Access надає автоматично. Після її заповнення можна переглянути інформацію повністю або частково за допомогою процедур пошуку, запиту, сортування. Для перегляду необхідної інформації за допомогою форм в моїй базі даних представлені 6 різних форм: кнопкова, всі товари, всі торгові салони, пошук, пошук по салону, пошук по товару (рис. 5-10). При виборі тієї чи іншої форми, вказавши, якщо є необхідність, назва товару, ви отримаєте цікаву для вас інформацію.
Висновок.
Таким чином, БД є найважливішою складовою частиною інформаційних систем, які призначені для зберігання і обробки інформації. Спочатку такі системи існували в письмовому вигляді. Для цього використовувалися різні картотеки, папки, журнали, бібліотечні каталоги. Розвиток засобів обчислювальної техніки забезпечило можливість для створення та широкого використання автоматизованих інформаційних систем. Розробляються інформаційні системи для обслуговування різних систем діяльності, системи управління господарськими і технічними об'єктами, модельні комплекси для наукових досліджень, системи автоматизації проектування і виробництва, всілякі тренажери і навчальні системи. Сучасні інформаційні системи засновані на концепції інтеграції даних, що характеризують великими об'єктами даних, що зберігаються, складною організацією, необхідністю задовольняти різноманітні вимоги численних користувачів. Для управління цими даними та забезпечення ефективності доступу до них були створені системи управління даними.
Таким чином, СУБД називають програмну систему, призначену для створення ЕОМ загальної бази даних для безлічі додатків, підтримки її в актуальному стані та забезпечення ефективності доступу користувачів до містяться в ній даними в рамках наданих їм повноважень.
Наведена для прикладу база даних по побутовій хімії міста Улан-Уде розроблена в програмі Microsoft Access, яка є однією з найпопулярніших серед настільних програмних систем управління базами даних. Серед причин такої популярності слід зазначити:
- Високий ступінь універсальності та продуманості інтерфейсу, який розрахований на роботу з користувачами самої різної кваліфікації. Зокрема, реалізована система управління об'єктами бази даних, що дозволяє гнучко й оперативно переходити з режиму конструктора в режим їх безпосередньої експлуатації;
- Глибоко розвинені можливості інтеграції з іншими програмними продуктами, що входять до складу Microsoft Office, а також з будь-якими програмами продуктами, що підтримують технологію OLE;
- Багатий набір візуальних засобів розробки.
Список літератури:
1. С. Бобровський С. - П. 2001р. «DELPHI 5».
2. А.Д. Хоменко «Основи сучасних комп'ютерних технологій». М. 2000р.
3. А. Я. Архангальскій «Програмування в Delphi 5» М. 2000р.
4. Ю. Бекаревич, Н. Пушкіна «MS ACCESS 2000 ЗА 30 занять».
5. С. М. Кандзюба, В. М. Громова «DELPHI 5».
6. Марко кент «DELPHI 5».
7. В. Гофман, А. Хаменко «Робота з БД в DELPHI».
8. К. Дейт «Введення
9. Введення в системи баз даних »К.2000г.
10. СУБД Microsoft Access 2.0 "Крок за кроком» М. 1995р.
Кафедра МіМІД
Виконала студент 2 курсу
Очного відділення 425 групи
Кваліфікація «Менеджер
Інформаційних систем »
Перевалов Станіслав Миколайович
Науковий керівник
Робота здана на рецензію «_____»______________________ 2002р. Допущена до захисту «_____»____________________________ 2002р.
Захищена з оцінкою ___________________________
Улан-Уде
2002р.
Три рівня архітектури.
Архітектура ANSI / SPARC включає три рівні: внутрішній, концептуальний і зовнішній. У загальних рисах вони є наступними:
- Внутрішній рівень-це рівень, найбільш близький до фізичного зберігання, тобто пов'язаний зі способами збереження інформації на фізичних пристроях зберігання.
- Зовнішній рівень найбільш близький до користувачів, тобто він пов'язаний зі способами представлення даних для окремих користувачів.
-
Зовнішній рівень (індивідуальні уявлення користувачів).
Концептуальний рівень (узагальнене уявлення користувачів).
Внутрішній рівень (подання до
пам'яті).
Якщо зовнішній рівень з індивідуальними уявленнями користувачів, то концептуальний рівень пов'язаний з узагальненим уявленням користувачів. Інакше кажучи, може бути декілька зовнішніх уявлень, кожне з яких складається з більш-менш абстрактного уявлення певної частини БД, і може бути тільки одне концептуальне уявлення, що складається з абстрактного уявлення БД в цілому.
Зовнішній рівень-це індивідуальний рівень користувача. Користувач може бути прикладним програмістом або кінцевим користувачем з будь-яким рівнем професійної підготовки. Особливе місце серед користувачів займає адміністратор БД. (На відміну від інших користувачів його цікавить також концептуальний і внутрішній рівень.)
У кожного користувача є своя мова спілкування.
- Для прикладного програміста це або один з найпоширеніших мов програмування, такої як C, COBOL або PL / 1, або спеціальна мова розглянутої системи. Такі оригінальні мови називають (неформально!) мовами четвертого покоління на тій підставі, що машинний код, мова асемблера і такі мови, як COBOL, можна вважати мовами трьох перших «поколінь», а оригінальні мови модернізовані у порівнянні з мовами третього покоління так само, як мови третього покоління покращувані в порівнянні з мовою асемблера.
- Для кінцевого користувача це спеціальна мова запитів, або мова спеціального призначення, можливо, заснований на формах і меню, створений спеціально з урахуванням вимог і підтримуваний деяким оперативним додатком.
Хоча з точки зору архітектури зручно розрізняти под'язик даних і включає його базова мова, на практиці вони можуть бути невиразними настільки, наскільки це має відношення до користувача. Безумовно, з точки зору користувача, краще, щоб вони не чіткі або важко помітним, їх називають сильно пов'язаними. Якщо вони ясно і легко розрізняються, кажуть, що вони слабко пов'язані. Більшість систем на сьогоднішній день підтримує лише слабкий зв'язок. Система з сильним зв'язком могли б надати користувачеві більш уніфікований набір можливостей, але, очевидно, вимагають більше зусиль з боку системних проектувальників і розробників (які, ймовірно, розраховують на статус-кво), а проте є підстави припускати, що протягом наступних декількох років буде відбуватися поступове просування до більш сильно зв'язаних систем.
Мова обробки даних складається з таких виконуваних операторів PL / 1, які передають інформацію в і з БД; знову ж таки, можливо, включаючи, нові спеціальні оператори.Загалом, зовнішнє уявлення складається з безлічі екземплярів кожного типу зовнішньої записи, які, у свою чергу, аж ніяк не обов'язково повинні збігатися з ранимими записами. Що знаходиться у розпорядженні користувача под'язик даних визначено в термінах зовнішніх записів; наприклад, операція вибірки мови обробки даних буде проводити вибірку з примірників зовнішніх, а не збережених записів.
Концептуальний рівень.
Концептуальне подання - це подання всієї інформації БД в дещо більш абстрактній формі (як і випадку зовнішнього подання) в порівнянні з фізичним способом зберігання даних. Однак концептуальне уявлення істотно відрізняється від способу подання даних якому-небудь окремому користувачеві. Взагалі кажучи, концептуальне уявлення - це уявлення даних такими, які «вони є насправді», а не такими, якими змушений їх бачити користувач в рамках, наприклад, певної мови або використовуваного апаратного забезпечення.
Концептуальне уявлення складається з безлічі екземплярів кожного типу концептуальної запису. Наприклад, воно може складатися з набору екземплярів записів, що містять інформацію про окремі, плюс набір примірників, що містять інформацію про деталі і т.д. Концептуальна запис зовсім не обов'язково повинна збігатися з зовнішньої записом, з одного боку, і з збереженої записом-з іншого.
Концептуальне уявлення визначається за допомогою концептуальної схеми, яка включає визначення кожного типу концептуальних записів. Концептуальна схема використовує іншу мову визначення даних - концептуальний.
Концептуальне подання - це представлення всього вмісту бази даних, а концептуальна схема - це визначення такого подання. Проте було б помилкою вважати, що концептуальна схема - це не більше ніж набір визначень, що більше нагадують прості відносини записів у програмі на мові COBOL (або якому-небудь іншому).
Тепер перейдемо до більш детального дослідження трьох рівнів архітектури.
Внутрішній рівень.
Третім рівнем архітектури є внутрішній рівень. Внутрішнє подання - це подання нижнього рівня всієї БД; воно складається з багатьох екземплярів кожного типу внутрішньої запису. Термін «внутрішня запис» належить термінології ANSI / SPARC і означає конструкцію, звану збереженої записом. Внутрішнє подання так само, як зовнішнє і концептуальне, не пов'язане з фізичним рівнем, так як в ньому не розглядаються фізичні області пристрої зберігання, такі як циліндри та доріжки. Іншими словами, внутрішнє представлення передбачає нескінченне лінійне адресний простір; подробиці того, як адресний простір відображує на фізичний пристрій зберігання, дуже залежать від системи і навмисне не включені в загальну архітектуру.
Внутрішнє представлення описується за допомогою внутрішньої схеми, яка визначає не тільки різні типи збережених записів, але також існуючі індекси, способи подання збережених полів, фізичну послідовність збережених записів і т.д. Внутрішня схема пишеться з використанням ще однієї мови визначення даних - внутрішнього.
У висновку відзначимо, що в деяких виняткових ситуаціях прикладні програми, зокрема ті, які називають утилітами можуть виконувати операції безпосередньо на внутрішньому, а не на зовнішньому рівні. Звичайно, такою практикою користуватися не рекомендується; вона визначає ризик з точки зору безпеки (правила безпеки ігноруються) і цілісності (правила цілісності теж ігнорується), до того ж програма буде залежати від завантажених даних, але іноді це може бути єдиним способом досягти виконання необхідної функції або добитися необхідної швидкодії - так само, як користувачу мови високого рівня іноді з тих же причин необхідно вдатися до мови асемблера.
Програми, що використають бази даних, зазвичай прийнято відносити до однієї з програмних архітектур, які мають свої плюси і мінуси.
Локальна архітектура.
І програма, і база даних розташовані на одному комп'ютері. У такій архітектурі працює більшість настільних додатків.
Файл - серверна архітектура.
База даних розташована на потужному виділеному комп'ютері (сервері), а персональні комп'ютери підключені до нього по локальній мережі. На цих комп'ютерах встановлені клієнтські програми, які звертаються до бази даних по мережі. Перевага такої архітектури полягає в можливості одночасної роботи декількох користувачів з однією базою даних.
Недолік такого підходу - великі обсяги інформації, переданої по мережі. Вся обробка виконується на клієнтських місцях, де фактично формується копія бази даних. Це приводиться до обмеження максимально можливого числа користувачів і більших затримок при роботі з базою. Ці затримки викликаються тим, що на рівні конкретної таблиці одночасний доступ неможливий. Поки програма на одному з клієнтських місць не закінчить роботу з таблицею (наприклад, не виконає модифікацію записів), інші програми не можуть звертатися до цієї таблиці. Це називається блокуванням на рівні таблиці і виключає виникнення плутанини в її вміст.
Клієнт - серверна архітектура.
У такій архітектурі на сервері не тільки зберігається БД, а й працює програма СУБД, обробна запити користувачів і повертає їм набори записів. При цьому програми користувачів вже не працюють, наприклад, з БД як набором фізичних фалів, а звертаються до СУБД, яка виконує операції. Навантаження з клієнтських місць при цьому знімається, тому що більша частина роботи відбувається на сервері. СУБД автоматично стежить за цілісністю і збереженням БД, а також контролює доступ до інформації за допомогою служби паролів. Клієнт - серверні СУБД допускають блоки на рівні запису і навіть окремого поля. Це означає, що з таблицею може працювати будь-яке число користувачів, але доступ до функції зміни конкретної запису або одного з її полів забезпечений тільки одному з них.
Основний недолік цієї архітектури не дуже висока надійність. Якщо сервер виходить з ладу, вся робота зупиняється.
Розподілена архітектура.
У мережі працює кілька серверів, і таблиці баз даних розподілені між ними для досягнення підвищеної ефективності. На кожному сервері функціонує своя копія СУБД. Крім того, в подібній архітектурі зазвичай використовуються спеціальні програми, так звані сервери додатків. Вони дозволяють оптимізувати обробку запитів великої кількості користувачів і рівномірно розподілити навантаження між комп'ютерами в мережі.
Недолік розподіленої архітектури полягає в досить складному і дорогому процесі її створення та супроводу (адміністрування), а також а високих вимогах до сервером комп'ютерів.
Інтернет - архітектура.
Доступ до бази даних і СУБД (розповсюджених на одному комп'ютері або в мережі) здійснюється з оглядача за стандартним протоколом. Це ставить мінімальні вимоги до клієнтського обладнання. Такі програми називають «тонкими клієнтами», бо вони здатні працювати навіть на ПК з процесором 80386. Завдяки стандартизації всіх протоколів і впроваджувати. Наприклад, можна не організовувати локальну мережу, а звертатися до сервера через Інтернет в локальній мережі (в такому випадку говорять про технології інтранет). У цьому випадку не потрібно розробляти спеціальні клієнтські програми або придумувати власні специфікації обміну даними між сервером і клієнтськими місцями. Досить використовувати готові оглядача і програмні рішення.
4. Типи СУБД.
Системою управління базами даних називають програмну систему, призначену для створення на ЕОМ загальної бази даних для безлічі додатків, підтримки її актуальному стані та забезпечення ефективності доступу користувачів до містяться в ній даними в рамках наданих їм повноважень. СУБД призначена, таким чином, для централізованого управління БД як соціальним ресурсом в інтересах всієї сукупностей її користувачів. Доступ до бази даних окремих користувачів при цьому можливий тільки за посередництвом СУБД.
За ступенем їх універсальності розрізняються два види СУБД - системи загального призначення і спеціалізовані системи. СУБД загального призначення не орієнтовані на будь - яку конкретну предметну область або на інформаційні потреби конкретної групи користувачів. Кожна система такого роду реалізується як програмний продукт, здатний функціонувати на деякій моделі ЕОМ у певної обстановки, і поставляється багатьом користувачам як комерційне виріб. СУБД загального призначення мають засоби налаштування на роботу з конкретною БД в умовах конкретного застосування.
Використання СУБД загального призначення в якості інструментального засобу для створення автоматизованих інформаційних систем, заснованих на технології БД, дозволяє істотно скорочувати терміни розробки, економити трудові ресурси. Розвинені функціональні можливості таких СУБД, притаманна їм, як правило, функціональна надмірність дозволяють мати значний «запас потужності», необхідний для безболісного еволюційного розвитку побудованих на їх основі інформаційних систем в рамках їх життєвого циклу. Разом з тим засоби налаштування дають можливість досягти прийнятного рівня продуктивності інформаційної системи в процесі її експлуатації.
Однак у деяких випадках доступні СУБД загального призначення не дозволяють домогтися необхідних характеристик продуктивності і / або задовольнити задані обмеження за обсягом пам'яті, що надається для зберігання БД. Тоді доводиться розробляти спеціалізовану СУБД для даного конкретного застосування. Вирішення зазначених проблем при цьому може виявитися можливим завдяки знанню специфічних особливостей даного застосування, до яких виявляються нечутливими засоби налаштування доступних СУБД загального призначення, або за рахунок обмеження будь-яких функцій системи, що не мають життєво важливого значення. Як правило, в цій ролі виявляються, перш за все функції, що забезпечують комфортну роботу користувача.
Створення спеціалізованої СУБД - вельми трудомістка справа навіть у порівняно простих випадках, і для того, щоб обрати цей шлях, потрібно мати справді вагомі підстави і тверду убеждаемость в неможливості або недоцільності використання будь - якої СУБД загального призначення.
СУБД загального призначення - це складні програмні комплекси, призначені для виконання всієї сукупності функцій, пов'язаних зі створенням та експлуатацією БД інформаційної системи. Вони дозволяють визначити структуру створюваної БД, ініціалізувати її і провести початкове завантаження даних. Системні механізми виконують також функції управління ресурсами середовища зберігання, забезпечення логічної і фізичної незалежності даних, надання доступу користувачам до БД, захисту логічної цілісності БД, забезпечення її фізичної цілісності - захисту від руйнувань. Інша важлива група функцій - управління повноваженнями користувачів на доступ до БД, настроювання на конкретні умови застосування, організація паралельного доступу користувачів до бази даних в соціальній користувача середовищі, підтримка діяльності системного персоналу, відповідального за експлуатацію БД.
Для створення БД розробник описує її логічну структуру, організацію в середовищі зберігання, а також способи бачення бази даних користувачами. При цьому використовуються надаються СУБД мовні засоби визначення даних, і система налаштовується на роботу з конкретною БД. Такі описи БД називаються відповідно схемою (або логічною схемою, або концептуальною схемою) БД, схемою зберігання (або внутрішньою схемою) і зовнішніми схемами.
Обробляючи схеми БД, СУБД створює порожню БД необхідної структури - сховище, яке можна далі наповнити даними про предметної області почати експлуатувати для задоволення інформаційних потреб користувачів.
Принципово важлива властивість СУБД полягає в тому, що вона дозволяє розрізняти і підтримувати два незалежних погляду на БД - погляд користувача, втілювалася в «логічному» поданні даних, і «погляд» системи - «фізичне» уявлення, що характеризує організацію збережених даних. Користувача не цікавить при його роботі з БД байти і біти, що представляють дані в середовищі зберігання, їх розміщення в пам'яті, покажчика, підтримують зв'язки між структурними різними компонентами даних, що зберігаються, обрані методи доступу. У той же час ці фактори важливі для виконання функцій управління даними самої СУБД.
Забезпечення логічної незалежності даних - одна з найважливіших функцій СУБД, що надає певну ступінь свободи варіації «логічного» подання БД без необхідності відповідної модифікації «фізичного» уявлення. Завдяки цьому досягається можливість адаптації погляду користувача на БД до його реальним потребам, конструювання різних «логічних» поглядів на одну й ту ж «фізичну» БД, що дуже важливо в соціальній користувача середовищі.
Під «фізичної» незалежністю даних розуміється здатність СУБД надавати деяку свободу модифікації способів організації БД в середовищі зберігання, не викликаючи необхідність внесення відповідних змін до «логічне» уявлення. Завдяки цьому вносити зміни до організації збережених даних, проводити налаштування системи з метою підвищення її ефективності, не зачіпаючи створених прикладних програм, що використовують базу даних. «Фізична» незалежність даних реалізується в СУБД за рахунок тих же самих трансформаційних механізмів архітектури системи, які забезпечують «логічну» незалежність даних.
Підтримка логічної цілісності (несуперечності) бази даних - інша важлива функція СУБД. У розвинених системах обмеження цілісності бази даних оголошуються у схемі бази даних, і їх перевірка здійснюється при кожному оновленні об'єктів даних або зв'язків між ними, що є аргументами таких обмежень.
Глава 2. Розробка бази даних по ринку побутової хімії.
Процес розробки (проектування) бази даних включає два етапи: розробку логічної організації бази даних і створення її на носії. Логічна організація бази даних - це надання користувача про предметної області, інформація про яку повинна зберігатися в базі даних. Під фізичною організацією бази даних розуміється сукупність засобів і методів розміщення даних у зовнішній пам'яті і на їх основі внутрішня модель даних. Внутрішня модель є засобом відображення логічної моделі даних, показує, яким чином записи розміщуються в базі даних, як вони упорядковуються, як організуються зв'язку, яким шляхом можна здійснити вибірку і так далі.
В даний час розроблені і використовуються на персональних комп'ютерах близько двадцяти систем управління базами даних. Вони представляють користувачеві зручні засоби інтерактивної взаємодії з БД і мають розвинену мову програмування. Однією з найпопулярніших настільних програмних СУБД є Microsoft Access.
Однією з основних причин такої популярності Access полягає в тому, що, є по суті настільної СУБД, цей додаток увібрало в себе багато можливостей систем управління реляційними базами даних архітектури клієнт-сервер, званої також SQL базою даних. Незважаючи на те, що, Access включають в себе складні функції і може послужити прекрасним інструментом для професійного розробника додатків БД, його використання не повинне викликати проблем і у непрофесійної користувачів і навіть тих, хто раніше не працював з СУБД. Кнопки на панелях інструментів дублюють основні команди меню, розширений набір майстрів і налаштувань управляє практично всіма параметрами створення і зміни об'єктів БД (таблиць, форм, звітів, запитів і т.д.). За допомогою ACCESS можна створювати багатокористувацьких додатків, в яких файли бази даних є розділяютьсяресурсами в локальній мережі. У ACCESS реалізованого доступу до об'єктів бази даних. Microsoft Access для зберігання об'єктів БД має власну унікальну структуру для зберігання всіх зв'язаних таблиць, форм, звітів, запитів і макрософт в одному файлі. Також має можливість імпорту та експорту даних в багато широкі поширені формати БД, електронних таблиць та текстових файлів. ACCESS дозволяє пов'язувати БД із зовнішніми таблицями в форматах dBase, FoxPro, Paradox і працювати з ними у вихідному форматі. Також Access можна використовувати в якості клієнтської частини архітектури клієнт-сервер, що забезпечує застосування Microsoft Access не тільки в якості професійної системи управління бази даних, але і як потужний інструментальний засіб для створення додатків клієнт-сервер.
База даних по побутовій техніці міста Улан-Уде була розроблена в програмі Microsoft Access. Вся необхідна інформація представлена у двох таблицях. Таблиця бази даних - це сукупність відомостей. Так, наприклад, у таблиці «торгові салони» відображена інформація про торговельне салоні, адресу, телефон (рис. 1), а в таблиці «товари» - інформація про послуги, торговим салоном товари (рис. 2). Кожне поле надає собою стовпець таблиці і містить певну категорію інформації. Кожна запис надає собою рядок таблиці і містить інформацію про певний товар. Можна створити взаємозв'язку між таблицями (Мал. 10), замість того, щоб зберігати всю інформацію в одній великій таблиці, уникаючи тим самим непотрібного дублювання даних, економії пам'яті комп'ютера, а також збільшення швидкості і точності обробки інформації. Так, наприклад, кожен запис в таблиці «всі товари» містить інформацію про фірму і наданих нею товари (рис. 3). Запити використовуються приблизно також, як і таблиці. Ви можете відкрити запит і переглянути набір даних у табличному поданні. При створенні запиту вказуються таблиці, з яких буде проводиться вибірка даних, вказуються поля таблиці, які повинні бути внесені в результат запиту, зазначена умова відбору даних. У даному випадку при виборі запиту «пошук по салону» (рис. 4), вказавши назву салону, ви отримаєте цікаву для вас інформацію про товари в цьому салоні.
При виборі запиту «пошук по товарах» (рис. 3) ви отримаєте інформацію про запропоновані фірмою товари.
За допомогою форм можна відображати дані, що містяться в таблицях чи запитах, в ще більш зручне для сприйняття вигляді. За допомогою форм можна додавати в таблиці нові дані або змінювати і видаляти існуючі. Форма може містити малюнки, графіки та інші об'єкти. Форми створюються з набору окремих елементів, званих елементами управління (графічний об'єкт для надання даних). Форму для надання даних Microsoft Access надає автоматично. Після її заповнення можна переглянути інформацію повністю або частково за допомогою процедур пошуку, запиту, сортування. Для перегляду необхідної інформації за допомогою форм в моїй базі даних представлені 6 різних форм: кнопкова, всі товари, всі торгові салони, пошук, пошук по салону, пошук по товару (рис. 5-10). При виборі тієї чи іншої форми, вказавши, якщо є необхідність, назва товару, ви отримаєте цікаву для вас інформацію.
Висновок.
Таким чином, БД є найважливішою складовою частиною інформаційних систем, які призначені для зберігання і обробки інформації. Спочатку такі системи існували в письмовому вигляді. Для цього використовувалися різні картотеки, папки, журнали, бібліотечні каталоги. Розвиток засобів обчислювальної техніки забезпечило можливість для створення та широкого використання автоматизованих інформаційних систем. Розробляються інформаційні системи для обслуговування різних систем діяльності, системи управління господарськими і технічними об'єктами, модельні комплекси для наукових досліджень, системи автоматизації проектування і виробництва, всілякі тренажери і навчальні системи. Сучасні інформаційні системи засновані на концепції інтеграції даних, що характеризують великими об'єктами даних, що зберігаються, складною організацією, необхідністю задовольняти різноманітні вимоги численних користувачів. Для управління цими даними та забезпечення ефективності доступу до них були створені системи управління даними.
Таким чином, СУБД називають програмну систему, призначену для створення ЕОМ загальної бази даних для безлічі додатків, підтримки її в актуальному стані та забезпечення ефективності доступу користувачів до містяться в ній даними в рамках наданих їм повноважень.
Наведена для прикладу база даних по побутовій хімії міста Улан-Уде розроблена в програмі Microsoft Access, яка є однією з найпопулярніших серед настільних програмних систем управління базами даних. Серед причин такої популярності слід зазначити:
- Високий ступінь універсальності та продуманості інтерфейсу, який розрахований на роботу з користувачами самої різної кваліфікації. Зокрема, реалізована система управління об'єктами бази даних, що дозволяє гнучко й оперативно переходити з режиму конструктора в режим їх безпосередньої експлуатації;
- Глибоко розвинені можливості інтеграції з іншими програмними продуктами, що входять до складу Microsoft Office, а також з будь-якими програмами продуктами, що підтримують технологію OLE;
- Багатий набір візуальних засобів розробки.
Список літератури:
1. С. Бобровський С. - П. 2001р. «DELPHI 5».
2. А.Д. Хоменко «Основи сучасних комп'ютерних технологій». М. 2000р.
3. А. Я. Архангальскій «Програмування в Delphi 5» М. 2000р.
4. Ю. Бекаревич, Н. Пушкіна «MS ACCESS 2000 ЗА 30 занять».
5. С. М. Кандзюба, В. М. Громова «DELPHI 5».
6. Марко кент «DELPHI 5».
7. В. Гофман, А. Хаменко «Робота з БД в DELPHI».
8. К. Дейт «Введення
9. Введення в системи баз даних »К.2000г.
10. СУБД Microsoft Access 2.0 "Крок за кроком» М. 1995р.
Міністерство Культури РФ
Східно-Сибірська Академія Культури і МистецтвКафедра МіМІД
Курсова робота
Тема: Розробка бази даних по товарах споживчого ринку побутової техніки.Виконала студент 2 курсу
Очного відділення 425 групи
Спеціальність 071900 «Інформаційні
Системи в соціально-культурній сфері »Кваліфікація «Менеджер
Інформаційних систем »
Перевалов Станіслав Миколайович
Науковий керівник
Іванова Надія Сергіївна
Робота здана на рецензію «_____»______________________ 2002р. Допущена до захисту «_____»____________________________ 2002р.
Захищена з оцінкою ___________________________
Улан-Уде
2002р.