База даних MS Access 2

ЗМІСТ

ВСТУП

1. СИСТЕМИ УПРАВЛІННЯ БАЗАМИ ДАНИХ

1.1. Системи управління базами даних

1.2. Настільні (локальні) СУБД

1.3. СУБД структури «сервер-клієнт»

2. БАЗА ДАНИХ MS ACCESS

2.1. Microsoft Access - функціонально повна реляційна СУБД

2.2. Призначення СУБД Access

ВИСНОВОК

СПИСОК ЛІТЕРАТУРИ

ВСТУП

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

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

Одне з основних призначень СУБД - підтримка програмними засобами подання, відповідного реальності.

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

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

1. СИСТЕМИ УПРАВЛІННЯ БАЗАМИ ДАНИХ

1.1. Системи управління базами даних

Для взаємодії користувача з БД використовуючи системи управління базами даних (СКБД), які забезпечують:

- Набір засобів для підтримки таблиць і співвідношень між ними;

- Розвинений користувальницький інтерфейс, що дозволяє вводити і модифікувати інформацію, проводити пошук і представляти результати;

- Засоби програмування високого рівня, що дозволяють створювати власні програми.

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

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

1.Создаваемие засобами СУБД додатки повинні мати високий ступінь мобільності і легко переноситися на різні комп'ютерні та мережеві платформи.

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

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

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

5.Проізводітелям СУБД слід забезпечити відповідність поставляються ними продуктів відкритим стандартам взаємодії.

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

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

1.2. Настільні (локальні) СУБД

Важливим етапом у розвитку настільних систем управління базами даних стали СУБД dBASE III і dBASE III PLUS фірми Ashton Tate (Ребус у вітчизняному варіанті), які по суті стали стандартом для програмних продуктів даного класу. Після версії "третя з плюсом" розроблявся проект dBASE IV, результатом якого став пакет-монстр, важкий в освоєнні і малоефективний, що призвело фірму до краху.

Фірма Fox Software починала з FохBa s e. Спочатку цей продукт мало відрізнявся від dBASE: він лише значно швидше працював і мав ряд корисних функцій, яких у dBASE не було (російська "піратська" версія FoxBase називалася "Карат-М"). Потім з'явився FoxPro - цей продукт виявився досить потужним, і дуже багато програмістів перейшли на нього. Надалі цей продукт купила MicroSoft і випустила свою версію FoxPro 2.5, потім перетворивши його в візуальний об'єктно-орієнтована продукт Visual FoxPro 3.0. з подальшим розвитком.

Компанія Nantucket виробляла компілятор Clipper. Пакет Clipper мав перевагу перед іншими XBASE-продуктами з тієї простої причини, що дозволяв створювати виконувані модулі (ЕХЕ-файли). Крім того, у нього була одна важлива властивість, актуальне й донині: він дозволяв швидко і досить простими засобами створювати корпоративні програми середньої складності (АРМ "Кадри", "Фінанси", "Бібліотека" та ін.) Друга очевидна перевага - простота освоєння. У Clipper багато компоненти були вже готові або збиралися зі шматочків за лічені хвилини, для DOS на ті часи це було велике досягнення. Недоліком було те, що у Clipper не було свого середовища розробки. Програми набиралися в якому-небудь редакторі, а потім компілювалися і запускалися. Розвиваючи її як мову програмування, фірма Nantucket мала намір зробити з Clipp er щось, подібне мови Сі + +. Орієнтація на об'єктно-орієнтована мова програмування призвела до того, що Clipper nepeстал бути самим собою. Пропала простота освоєння, а вимоги до ресурсів неймовірно зросли. Проект зазнав невдачі, цю фірму купила компанія Computer Associates і новий виробник випустив Windows-варіант допрацьованого продукту під назвою Visual Objects.

Поступово настільні системи стають мережевими, оскільки варто навіть невелику організацію розсадити по декількох віддалених один від одного офісах - і ось вже без схеми «клієнт-сервер» працювати не можна. Переростання локальної інформаційної системи в клієнт-серверну - нормальний процес, але, звичайно, робота в архітектурі «клієнт-сервер» не самоціль. Потрібно використовувати її тільки тоді, коли це дає действітепьний виграш, дійсну віддачу. Тому основні виробники настільних СУБД збудували ряд продуктів - додатків сучасних 32-розрядних операційних систем: «настільна СУБД з можливістю підключення до розподіленої базі даних з використанням стандартної мови SQL» - «візуальна об'єктно-орієнтоване середовище розробки» - «розподілена СУБД структури« сервер - клієнт »(наприклад, Microsoft Access - FoxPro - SQL Server).

Сучасні настільні СУБД входять до складу інтегрованих програмних продуктів типу Office: MS Access зі складу Office 95 і 97, Paradox 7.0 зі складу Corel Office 97, Approach зі складу Lotus SmartSuite 97.

1.3. СУБД структури «сервер-клієнт»

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

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

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

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

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

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

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

Транзакція може вносити зміни (тобто додавати, видаляти та змінювати записи) в одну або кілька таблиць бази даних. Обрані для реплікації таблиці спеціальним чином позначаються. Для кожної такої таблиці або групи її рядків, обраної по заданій умові, визначається один вузол (СУБД), в якому дані таблиці є первинними. Це той вузол, в якому відбувається найбільш активне оновлення даних. Реплікаційний сервера, обслуговуючому БД з первинними даними, задається опис тиражування (replication definition). У цьому описі, наприклад, можуть бути задані інтервали значень первинного ключа таблиці або яке-небудь іншу умову, при виконанні якого змінені дані будуть тиражуватися з цього вузла до передплатників. Якщо умова не задано, то опис тиражування діє для всіх записів таблиці. Можливість тиражування групи записів таблиці означає, зокрема, що частина записів може бути первинними даними в якомусь одному вузлі, а ще частина - в інших вузлах. В одному або декількох вузлах (СУБД), яким потрібні змінені дані, в обслуговуючому його репликационной сервері створюється передплата (subscription) на відповідний опис тиражування. Тут буде підтримуватися (з невеликою затримкою) копія первинних даних.

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

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

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

СУБД, що зберігає вторинні дані, може бути будь-який з низки доступних через шлюз: будь то Oracle, Informix, DB2, RMS, ISAM тощо. СУБД, що зберігає первинні дані, вимагає наявності менеджера журналу транзакцій (Log Transfer Manager - LTM). Зараз розроблені LTM для Sybase SQL Server і Oracle; на черзі інші СУБД. Інтерфейс LTM є відкритим, і незабаром, можливо, подібні модулі будуть створені для нестандартних джерел даних.

Взагалі, тиражування даних може знайти найрізноманітніше застосування:

- Для розвантаження сервера, що виконує активне оновлення даних (OLTP) від складних запитів, пов'язаних з підтримкою прийняття рішень (decision-support);

- Для консолідації даних від підрозділів у центрі;

- Для обміну даними по повільним або ненадійним лініях зв'язку;

- Для підтримки резервної бази даних;

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

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

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

Історично першим з'явився метод синхронного внесення змін в кілька БД, званий двофазної фіксацією (2РС, two-phase commit). Цей механізм реалізований зараз практично всіма виробниками СУБД. Суть методу двофазної фіксації полягає в тому, що при завершенні транзакції сервери БД, що беруть участь в ній, отримують команду «приготуватися до фіксації транзакції». Після отримання підтверджень від всіх серверів транзакція фіксується на Кадом з них. Таким чином, в будь-який момент часу забезпечується цілісність даних у розподіленій системі. Платою за це є вимога доступності всіх що беруть участь серверів і ліній зв'язку під час проведення транзакції, а також неможливість роботи додатків-клієнтів при недоступності, наприклад, віддаленого сервера. Крім того, необхідно високу швидкодію ліній зв'язку для забезпечення прийнятного часу реакції у програми-клієнта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. БАЗА ДАНИХ MS ACCESS

2.1. Microsoft Access - функціонально повна реляційна СУБД

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

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

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

2.2. Призначення СУБД Access

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

При проектуванні бази даних, в першу чергу, необхідно визначити, що саме потрібно зберігати.

Ця СУБД була обрана з наступних причин:

простота засобів реалізації,
легкість освоєння інструментарієм розробника (VBA),
наочність візуалізації інформації.

Також «Microsoft Access» надає велику кількість національних засобів щодо оптимізації роботи проектованого додатки. До них відносяться:

завантаження модулів на вимогу;
оптимізація дерева викликів;
використання файлів MDE;
автоматична підтримка скомпільовані стану;
використання бібліотек Windows API;
індивідуальна настройка системи;
ефективне використання індексів;
вбудований оптимізатор запитів.

Система управління базами даних (СКБД) зазвичай підтримує 4 основних типи відносин між таблицями:

- Один-до-одного (одного запису в першій таблиці відповідає один запис у другій);

- Один-до-багатьох (одного запису в першій таблиці відповідає багато записів в другій);

- Багато-до-одного (багатьом записам у першій таблиці відповідає один запис у другій);

- Багато-до-багатьох (одного запису в першій таблиці відповідає багато запіей в другій і одного запису в другій таблиці відповідає багато записів в першій).

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

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

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

Взаємозв'язки таблиць

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

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

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

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

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

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

Зв'язки-об'єднання. Між двома таблицями може бути встановлений зв'язок-об'єднання по деякому полю зв'язку. Для зв'язку-об'єднання може бути обраний один із трьох способів об'єднання записів:

Спосіб 1 - об'єднання тільки тих записів, в яких пов'язані поля обох таблиць збігаються (проводиться за умовчанням);

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

Такий тип зв'язку може бути визначений, якщо зв'язок характеризується відношенням 1:1 або 1: М, а також якщо тип ставлення не може бути визначений системою, тобто якщо не виконуються умови для цих відносин. Наприклад, при виборі в головній таблиці в якості поля зв'язку неключові поля або поля, що входить у складений ключ, Access повідомляє, що тип ставлення не може бути визначений. У цьому випадку між таблицями можливе встановлення тільки зв'язки-об'єднання.

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

Створення схеми даних

Створення схеми даних починається у вікні Бази даних (Database) з виконання команди Сервіс | Схема даних (Tools | Relationships) або натискання кнопки Схема даних (Relationships) на панелі інструментів бази даних.

Включення таблиць в схему даних. Після натискання кнопки Схема даних (Relationships) відкривається вікно Додавання таблиці (Show Table), в якому можна вибрати таблиці і запити, що включаються в схему даних. Для размещения таблицы в окне Схема данных (Relationships) надо выделить ее в окне Добавление таблицы (Show Table) и нажать кнопку Добавить (Add). Для выделения нескольких таблиц надо, удерживая клавишу , щелкнуть мышью на каждой из этих таблиц. Включив все нужные таблицы в схему данных, нажать кнопку Закрыть (Close).

В результате в окне Схема данных (Relationships) будут представлены все включенные таблицы со списком своих полей. Далее можно приступать к определению связей между ними.

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

Устанавливая в окне схемы данных связи типа 1:М между парой таблиц, надо выделить в главной таблице уникальное ключевое поле, по которому устанавливается связь. Далее, при нажатой кнопке мыши, протащить курсор в соответствующее поле подчиненной таблицы.

При создании связи по составному ключу необходимо выделить все поля, входящие в ключ главной таблицы, и перетащить их на одно из полей связи в подчиненной таблице. Для выделения всех полей, входящих в составной уникальный ключ, необходимо отмечать поля при нажатой клавише . После создания связи откроется окно Изменение связей (Edit Relationships). При этом в строке Тип отношения (Relationship Type) автоматически установится тип один-ко-многим (One-To-Many).

При составном ключе связи в окне Изменение связей (Edit Relationships) необходимо для каждого поля ключа в главной таблице ТАБЛИЦА/ЗАПРОС (Table/Query) выбрать соответствующее поле подчиненной таблицы, названной СВЯЗАННАЯ ТАБЛИЦА/ЗАПРОС (Related Table/Query).

Обеспечение целостности данных

При создании схемы данных пользователь включает в неё таблицы и устанавливает связи между ними. Для связей типа 1:1 и 1:М можно задать параметр обеспечения связной целостности данных, а также автоматическое каскадное обновление и удаление связанных записей.

Обеспечение связной целостности данных означает, что Access при корректировке базы данных обеспечивает для связанных таблиц контроль за соблюдением следующих условий:

В подчиненную таблицу не может быть добавлена запись с несуществующим в главной таблице значением ключа связи;
В главной таблице нельзя удалить запись, если не удалены связанные с ней записи в подчиненной таблице;
Изменение значений ключа связи в записи главной таблицы невозможно, если в подчиненной таблице имеются связанные с ней записи.

При попытке пользователя нарушить эти условия в операциях добавления и удаления записей или обновления ключевых данных в связанных таблицах Access выводит соответствующее сообщение и не допускает выполнения операции.

Установление между двумя таблицами связи типа 1:М или 1:1 и задание для нее параметров целостности данных возможно только при следующих условиях:

Связываемые поля имеют одинаковый тип данных, причем имена полей могут быть различными;
Обе таблицы сохраняются в одной базе данных Access;
Главная таблица связывается с подчиненной по первичному простому или составному ключу (уникальному индексу) главной таблицы.

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

Каскадное обновление и удаление связанных записей

Если для выбранной связи обеспечивается поддержание целостности, можно задать режим каскадного обновления связанных полей и режим каскадного удаления связанных записей.

В режиме каскадного обновления связанных полей при изменении значения поля связи в записи главной таблицы, Access автоматически изменит значения в соответствующем поле в подчиненных записях.

В режиме каскадного удаления связанных записей при удалении записи из главной таблицы будут автоматически удаляться все связанные записи в подчиненных таблицах. При удалении записи из главной таблицы выполняется каскадное удаление подчиненных записей на всех уровнях, если этот режим задан на каждом уровне.

При удалении записей непосредственно в таблице или через форму выводится предупреждение о возможности удаления связанных записей.

Язык SQL (аббревиатура Structured Query Language ) – это язык структурированных запросов, стандартный язык, предназначенный для создания баз данных, добавления новых и поддержки имеющихся данных, а также извлечения требуемой информации. Язык SQL с самого начала был создан, чтобы работать с данными из тех баз, которые следуют реляционной модели.

Каждому запросу MS Access можно сопоставить эквивалентную инструкцию SQL. В MS Access пользователи, знакомые с языком SQL, могут использовать его для просмотра и изменения запросов в режиме конструктора, определения свойств форм и отчетов, создания специальных запросов (запросы объединения, запросы к серверу и управляющие запросы), создания подчиненных запросов.

При создании каждого запроса MS Access автоматически составляет эквивалентную ему инструкцию SQL. Изменения, внесенные в инструкцию SQL, автоматически отражаются в бланке конструктора.

Просмотрим или изменим инструкцию SQL:

1. Выполнив анализ предметной области, создадим групповой запрос «Список студентов группы ДФД-31» на основании таблиц «Студент» и «Группа» (рис. 21), в который включим список следующих полей таблиц:

Группа.[Обозначение группы], Студент.[Номер зачетной книжки], Студент.Фамилия, Студент.Имя, Студент.Отчество, Студент.Год рождения, Студент.Адрес, Студент.[Домашний телефон], Студент.[Балл при поступлении].

В поле Группа.[Обозначение группы] используем условие отбора по коду группы: «ДФД-31».

Групповой запрос «Список студентов группы ДФД-31» в MS Access в режиме конструктора

2. Выберем Режим SQL в меню Вид или через кнопку « Режим SQL » на панели инструментов. На экране появится текущий запрос в режиме SQL эквивалентный созданному в режиме конструктора (рис. 22).

Запрос «Список студентов группы ДФД-31» в MS Access в режиме SQL

3. В этот запрос можно внести изменения, и эти изменения будут отражены в бланке конструктора. Например, попробуем удалить в текстовом окне режима SQL записи Студент.Адрес, Студент.[Домашний телефон], Студент.[Балл при поступлении].

Результат выполнения измененного запроса «Список студентов группы ДФД-31»

Основной инструкцией языка SQL, всегда содержащейся в запросе, является команда SELECT [2].

В простейшей форме эта команда занимается поиском информации в таблице. Вона має наступний формат:

SELECT field 1, field 2, …

FROM Table ;

Здесь field 1, field 2,… – список столбцов таблицы Table , которые должны быть представлены в результате запроса.

Для получения всей таблицы вместо списка столбцов необходимо поставить символ «*» (звездочка).

Команда SELECT имеет следующие параметры:

A. DISTINCT (получить список без повторений)

Формат : SELECT DISTINCT field1, field2, …

FROM Table ;

B . ALL (получить список со всеми повторениями)

Формат : SELECT ALL field1, field2, …

FROM Table;

C. WHERE ( извлечь нужные строки )

Формат : SELECT field1, field2, …

FROM Table WHERE predicate ;

Здесь predicate – логическое выражение, которое может быть истинно или ложно для каждой записи таблицы.

D . ORDER BY (рассортировать выходные данные)

Формат : SELECT field1, field2, …

FROM Table

ORDER BY field 1 DESC;

Это означает, что выходные данные будут рассортированы по столбцу field 1 в порядке убывания (порядок возрастания задается по умолчанию или с помощью слова ASC).

E . GROUP BY (группировать выходные данные)

Формат : SELECT field1, field2, …

FROM Table

GROUP BY [field1, field2, …]

ORDER BY field1 DESC;

Группировка – это объединение записей в соответствии со значениями некоторого заданного поля.

Агрегатные функции

Существуют следующие основные агрегатные функции:

Count – определение численности;
Sum – определение суммы;
First / Last – определение первого/последнего значения;
Min / Max – определение минимума/максимума;
Avg – определение среднего значения.

Для обозначения связи двух таблиц дополнительно к команде FROM используются атрибуты INNER JOIN и ON.

Так как в сложном запросе появляется несколько таблиц, то появляется необходимость указывать поле с обозначением таблицы, например, см. рис. 22.

С помощью атрибута INNER JOIN мы указали, что таблица «Студент» связана с таблицей «Группа». А с помощью атрибута ON мы указали, как именно связаны между собой две таблицы «Студент» и «Группа»: по полю Код группы (FROM Группа INNER JOIN Студент ON Группа.[Код группы] = Студент.[Код группы]).

С помощью атрибута WHERE мы указали, что нужно извлечь только строки, которые содержат запись в поле Группа.[Обозначение группы] «ДФД-31»: WHERE (((Группа.[Обозначение группы])="ДФД-31")).

ПРИМЕЧАНИЕ. Обратите внимание на то, что в качестве имени поля всегда используется то имя, которое было присвоено полю в процессе создания таблицы в режиме конструктора, а не надпись, которую мы видим на экране в таблице в режиме заполнения.

4. Запрос может быть создан также только исключительно через Режим SQL в конструкторе.

Выберем в окне базы данных «Запрос», «Создать» через опцию «Конструктор». В диалоговом окне «Добавление таблицы» выберем опцию «Закрыть». В меню Вид выберите Режим SQL . Появится окно «Запрос на выборку». Наберем следующую инструкцию SQL:

Эта инструкция предназначена для получения списков всех предметов и их кодов. Данные для этого запроса берутся из таблицы «Предмет». Результатом выполнения данного запроса будет таблица, состоящая из двух полей (Наименование предмета и Код предмета) и из всех записей таблицы «Предмет».

Результат запроса для получения списков всех предметов и их кодов

Так как в запросе используется только одна таблица, то нет необходимости указывать поле с обозначением таблицы. Очевидно, что запрос выполняется на основании таблицы «Предмет».

Рассмотрим запрос «План проведения занятий в группе», созданный на основании анализа предметной области:

SELECT Группа.[Обозначение группы], Предмет.[Наименование предмета], Преподаватель.Фамилия, Преподаватель.Имя, Преподаватель.Отчество, Преподаватель.[Табельный номер], [Учебный план].Часы, [Учебный план].[Вид занятия], [Учебный план].Семестр

FROM (Группа INNER JOIN Студент ON Группа.[Код группы] = Студент.[Код группы]) INNER JOIN (Преподаватель INNER JOIN (Предмет INNER JOIN ([Учебный план] INNER JOIN Успеваемость ON [Учебный план].[Код учебного плана] = Успеваемость.[Код учебного плана]) ON Предмет.[Код предмета] = [Учебный план].[Код предмета]) ON Преподаватель.[Код преподавателя] = [Учебный план].[Код преподавателя]) ON Студент.[Код студента] = Успеваемость.[Код студента]

GROUP BY Группа.[Обозначение группы], Предмет.[Наименование предмета], Преподаватель.Фамилия, Преподаватель.Имя, Преподаватель.Отчество, Преподаватель.[Табельный номер], [Учебный план].Часы, [Учебный план].[Вид занятия], [Учебный план].Семестр

ORDER BY Группа.[Обозначение группы], Предмет.[Наименование предмета], Преподаватель.Фамилия;

Результатом будет следующий запрос на выборку

Аналогично, следует подготовить запрос «Экзаменационная ведомость», созданный на основании анализа предметной области (см. рис. 5):

SELECT Предмет.[Наименование предмета], Группа.[Обозначение группы], Студент.[Номер зачетной книжки], Студент.Фамилия, Студент.Имя, Студент.Отчество, Успеваемость.Оценка, Успеваемость.[Дата сдачи], [Учебный план].Семестр, [Учебный план].[Вид сдачи]

WHERE ((([Учебный план].[Вид сдачи])="экзамен" Or ([Учебный план].[Вид сдачи])="Зачет"))

ORDER BY Предмет.[Наименование предмета], Группа.[Обозначение группы], Студент.Фамилия;

Рассмотрим для примера запрос «Успеваемость студентов в группах по предметам у преподавателей». Запишем текст запроса на языке SQL в окно Режим SQL :

SELECT Группа.[Обозначение группы], Студент.[Номер зачетной книжки], Студент.Фамилия, Студент.Имя, Студент.Отчество, Преподаватель.Фамилия, Преподаватель.Имя, Преподаватель.Отчество, Предмет.[Наименование предмета], Avg(Успеваемость.Оценка) AS [Avg-Оценка]

GROUP BY Группа.[Обозначение группы], Студент.[Номер зачетной книжки], Студент.Фамилия, Студент.Имя, Студент.Отчество, Преподаватель.Фамилия, Преподаватель.Имя, Преподаватель.Отчество, Предмет.[Наименование предмета]

HAVING (((Группа.[Обозначение группы])="ДФД-31"));

Результатом запроса будут сведения о средней успеваемости студентов в групп ДФД-31 у всех преподавателей во всех семестрах.

Для задания ограничений на создаваемые группы совместно с ключевым словом GROUP BY может использоваться предложение HAVING. Оно должно следовать после GROUP BY, но до предложения ORDER BY (если оно присутствует в запросе).

Сохраним запрос и просмотрим результаты этого запроса.

Любые усилия, вложенные в изучение SQL, будут оправдываться в течение долгого времени, потому что быстро сходить со сцены этот язык не собирается.

Использование форм и отчетов для создания приложений в MS Access

Формы предназначены для вывода данных на экран в удобном виде, форма может использоваться для поиска данных. Если изъять формы из MS Access, то программа превратится в заурядную СУБД, каких множество. С одной стороны, формы позволяют пользователям вводить данные в таблицы базы данных без непосредственного доступа к самим таблицам. С другой стороны, они позволяют выводить результаты работы запросов не в виде скупых результирующих таблиц, а в виде красиво оформленных форм. В связи с таким разделением существует два вида формирования структуры форм: на основе таблицы и на основе запроса, хотя возможен и комбинированный подход, – это вопрос творчества [1].

Создадим форму «Список студентов по группам» в режиме мастера форм (одиночная на основании таблицы «Студент», в столбец). Перед тем, как создать эту форму, создадим запрос «Список студентов по группам»:

SELECT Группа.[Обозначение группы], Группа.[Количество студентов], Группа.[Средний балл в группе при поступлении], Студент.[Номер зачетной книжки], Студент.Фамилия, Студент.Имя, Студент.Отчество, Студент.[Год рождения], Студент.[Балл при поступлении]

FROM Группа INNER JOIN Студент ON Группа.[Код группы]=Студент.[Код группы]

ORDER BY Студент.[Номер зачетной книжки], Студент.Фамилия;

После создания, переименуйте эту форму как «Список студентов по группам» и просмотрите данные через форму (рис. 26).

Формы предназначены и для заполнения базы данных пользователями. Создадим в режиме автоформы формы «Группа» и «Студент» и введем в формы данные (рис. 27). В соответствующих таблицах базы данных появились новые, введенные нами, данные для группы ДХГ-31.

Аналогично в режиме автоформы следует создать формы «Кафедра», «Преподаватель», «Предмет», «План», «Успеваемость».

Заполнение таблицы «Группа» базы через автоформу «Группа»

Для вывода на печать документов на основе данных из базы используются отчеты . Отчеты во многом похожи на формы, но имеют иное функциональное назначение – они служат для форматированного вывода данных на печатающие устройства и, соответственно, при этом должны учитывать параметры принтера и параметры используемой бумаги.

Создадим отчет «Список студентов по группам» в режиме мастера отчетов на основании запроса «Список студентов по группам», выполненного ранее. Отредактируем в режиме конструктора отчет, если это требуется, чтобы привести отчет в пригодный для печати вид (рис. 28).

Аналогично, следует создать отчет «Список преподавателей по кафедрам» в режиме мастера отчетов на основании запроса «Список преподавателей по кафедрам», который сформирован на основе рис. 3 предметной области.

ВИСНОВОК

В общем смысле термин «база данных» (БД) можно применить к любой совокупности связанной информации, объединенной вместе по определенному признаку, т.е. к набору данных, организованных определенным образом. При этом большинство БД использует табличный способ преставления, где данные располагаются по строкам (которые называются записями) и столбцам (которые называются полями), причем все записи должны состоять из одинаковых полей и все данные одного поля должны иметь один тип. Например, расписание движения поездов, полетов самолетов, книга заказов или учет товаров и т.п. легко могут быть представлены в такой форме. Базы данных должны содержать только независимую (первичную) информацию, поэтому не любая таблица представляет собой базу данных.

В последнее время наибольшее распространение получили реляционные базы данных (слово «реляционная» происходит от английского relation – отношение). Концепции реляционной модели данных связаны с именем известного специалиста в области систем 6aз данных Е. Кодда. Именно поэтому реляционную модель данных в литературе часто называют моделью Кодда.

В компьютерном варианте в реляционной БД информация хранится, как правило, в нескольких таблицах-файлах, связанных между собой посредством одного или нескольких совпадающих в этих таблицах полей (в некоторых компьютерных системах все таблицы одной базы помещаются в один файл). Каждая строка в таблице реляционной БД должна быть уникальна (т.е. не должно быть одинаковых строк-записей). Такие уникальные столбцы (или уникальные группы столбцов), используемые, чтобы идентифицировать каждую строку и хранить все строки отдельно, называются первичными ключами таблицы.

Первичные ключи таблицы важный элемент в структуре базы данных. Они - основа системы записи в файл и, когда необходимо найти определенную строку в таблице, то ссылаются к этому первичному ключу. Кроме того, первичные ключи гарантируют, что данные имеют определенную целостность. Если первичный ключ правильно используется и поддерживается, то можно быть уверенным, что нет пустых строк таблицы и, что каждая строка отличается от любой другой строки.

Основным назначением БД является быстрый поиск содержащейся в ней информации. При этом БД могут содержать значительный объем информации, например, список домашних телефонов г.Астрахани (с его недостаточной степенью телефонизации) составляет десятки тысяч абонентов. В телефонной книге абоненты упорядочены (отсортированы) в алфавитном порядке и поиск по фамилии займет не очень много времени, однако, поиск по адресу или неточному номеру телефона и т.п. вручную – не решаемая практически задача.

Мир баз данных становится все более и более единым, с развитием Internet - и Intranet - технологий появилась возможность доступа к удаленным БД, что привело к необходимости создания стандартного языка, который мог бы использоваться так, чтобы функционировать в большом количестве различных видов компьютерных сред. Стандартный язык позволил бы пользователям, знающим один набор команд, использовать их, чтобы создавать, отыскивать, изменять и передавать информацию независимо от того, работают ли они на персональном компьютере, сетевой рабочей станции или на универсальном компьютере.

По этой причине ANSI (Американским Национальным Институтом Стандартов) был разработан стандарт языка SQL (Структурированный Язык Запросов) . При этом SQL не изобретался ANSI. Это по существу изобретение IBM. Но другие компании подхватили SQL и сразу же, по крайней мере одна компания (Oracle), получила право на рыночную продажу SQL продуктов. Однако после этого появились некоторые проблемы, которые возникли в результате стандартизации ANSI языка в виде некоторых ограничений. Конкретные программы Баз Данных обычно дают ANSI SQL дополнительные особенности, часто ослабляют многие ограничения стандарта.

СПИСОК ЛІТЕРАТУРИ

Атре Ш. Структурний підхід до організації баз даних. - М.: Фінанси і статистика, 1983. - 320 с.
Бойко В.В., Савінков В.М. Проектування баз даних інформаційних систем. - М.: Фінанси і статистика, 1989. - 351 с.
Голіцина О.Л., Максимов Н.В., Попов І.І. Бази даних: Навчальний посібник. - М.: ФОРУМ: ИНФРА-М, 2003. – 352 с.
Джексон Г. Проектування реляційних баз даних для використання з мікроЕОМ. -М.: Світ, 1991. - 252 с.
Карпова Т.С. Бази даних: моделі, розробка, реалізація. - СПб.: Пітер, 2002. - 304 с.
Кирилов В.В. Структурізованние мову запитів (SQL). - СПб.: ІТМО, 1994. - 80 с.
Корнеев И.К., Машурцов В.А. Информационные технологии в управлении. - М.: ИНФРА-М, 2001. – 158 с.
Мартін Дж. Планування розвитку автоматизованих систем. - М.: Фінанси і статистика, 1984. - 196 с.
Хаббард Дж. Автоматизоване проектування баз даних. - М.: Світ, 1984. - 294 с.