Создание і ведення баз данных

Введение

…2.

Бази данных…3.

Виды моделей данных…6.

Понятие інформаційного объекта…7.

Нормализация отношений…8 Типи связей…10 Функціональні можливості СУБД…11.

Информационная модель СУБД…24.

Краткая характеристика програмного забезпечення, використовуваного під час створення СУБД…32 Принципи організації даних, які у основі нових СУБД…34 Сучасні технології, використовувані регулярно працюють з данными…35 Список литературы…37.

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

Сучасні СУБД переважно є додатками Windows, оскільки дана середовище дозволяє повніше скористатися наявними можливостями персональної ЕОМ, ніж середовище DOS. Зниження вартості високопродуктивних ПК зумовив як широкий перехід до середовища Windows, де розробник програмного забезпечення може у менше ступеня турбуватися про розподілі ресурсів, але й зробив програмне забезпечення ПК загалом і СУБД зокрема менш критичними до апаратним ресурсів ЭВМ.

Серед найяскравіших представників системам управління базами даних можна назвати: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, і навіть баз даних Microsoft SQL Server і Oracle, використовувані в додатках, побудованих за технологією «клієнт-сервер». Фактично, в кожної сучасної СУБД існує аналог, що випускає інший компанією, має аналогічну сферу застосування й можливості, будь-яке додаток здатне працювати з багатьма форматами уявлення даних, здійснювати експорт нафти й імпорт даних наявністю значної частини конвертерів. Узвичаєними, також, є технологи, дозволяють скористатися наявними можливостями інших додатків, наприклад, текстових процесорів, пакетів побудови графіків тощо., і вбудовані версії мов високого рівня (частіше — діалекти SQL і/або VBA) і кошти візуального програмування інтерфейсів розроблюваних додатків. Тому немає істотного значення якою мовою на основі якого пакета написано конкретне додаток, і який формат даних у ньому використовується. Понад те, стандартом «де-факто» стала «швидка розробка додатків» чи RAD (від англійського Rapid Application Development), джерело якої в широко декларованому у літературі «відкритому підході», тобто необхідність, і зокрема можливість використання різних прикладних програм, тож технології розробки більш гнучких і потужних систем обробки даних. Тож у одному ряду з «класичними» СУБД дедалі частіше згадують мови програмування Visual Basic 4.0 і Visual З++, що дозволяють швидко створювати необхідні компоненти додатків, критичні за швидкістю роботи, які важко, інколи ж неможливо розробити засобами «класичних» СУБД. Сучасний підхід до управління базами даних передбачає і широке використання технології «клиент-сервер».

Отже, нині розробник не пов’язаний рамками будь-якого конкретного пакета, а залежність від поставленого завдання може використовувати найрізноманітніші докладання. Тому, важливішим є загальне напрям розвитку СУБД та інших засобів розробки додатків у справжнє время.

БАЗИ ДАННЫХ.

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

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

Неструктурированными називають дані, записані, наприклад, в текстовому файле.

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

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

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

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

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

Классификация баз данных По технології обробки даних бази даних поділяються на централізовані і распределенные.

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

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

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

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

Структурные елементи бази данных Понятие бази даних був із такими поняттями структурних елементів, як полі, запис, файл (таблица).

Поле — елементарна одиниця логічного організації даних, яка відповідає неподільної одиниці інформації — реквізиту. Для описи поля використовуються такі характеристики: ім'я, наприклад. Прізвище, Ім'я, По батькові, Дата народження; тип, наприклад, символьний, числової, календарний; довжина, наприклад, 15 байт, причому визначатиметься максимально можливим кількістю символів; точність для числових даних, наприклад два десяткових знака для відображення дробової частини числа. Запис — сукупність логічно пов’язаних полів. Примірник записи — окрема реалізація записи, яка містить конкретні значення її полів. Файл (таблиця) — сукупність примірників записів однієї структури. У структурі записи файла вказуються поля, значення яких є ключами первинними (ПК), які ідентифікують примірник записи, і вторинними (ВК), які виконують роль пошукових чи группировочных ознак (за значенням вторинного ключа можна знайти кілька записей).

ПЛАНИ МОДЕЛЕЙ ДАННЫХ Общие становища Ядром будь-який бази даних є модель даних. Модель даних представляє собою безліч структур даних, обмежень цілісності і операцій маніпулювання даними. З допомогою моделі даних можуть бути об'єкти предметної області й взаємозв'язку між ними.

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

Иерархическая модель данных Иерархическая структура представляє сукупність елементів, пов’язаних між собою за правилами. Об'єкти, пов’язані ієрархічними відносинами, утворюють орієнтований граф (перевернуте дерево).

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

До кожного записи бази даних є тільки один (ієрархічний) шлях від кореневої записи.

Сетевая модель данных В мережевої структури за ті самі основних поняттях (рівень, вузол, зв’язок) кожен елемент може бути зв’язаний з іншою элементом.

Реляційна модель данных Понятие реляционный (анг. relation — ставлення) пов’язані з розробками відомого американського фахівця у галузі систем баз даних Є. Кодда.

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

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

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

Щоб зв’язати дві реляционные таблиці, необхідно ключ першої таблиці увести до складу ключа другий таблиці (можливо збіг ключів); в іншому разі слід впровадити до структури першої таблиці зовнішній ключ — ключ другий таблицы.

ПОНЯТТЯ ІНФОРМАЦІЙНОГО ОБЪЕКТА Информационный об'єкт — це опис деякою сутності (реального об'єкта, явища, процесу, події) як сукупності логічно пов’язаних реквізитів (інформаційних елементів). Такими сутностями для інформаційних об'єктів можуть бути: цех, склад, матеріал, вуз, студент, складання тощо. Інформаційний об'єкт певного реквизитного складу і структури утворює клас (тип), якому присвоюється унікальне ім'я (символьне позначення), наприклад Студент, Сесія, Стипендія. Інформаційний об'єкт має безліч реалізації — примірників, кожен із яких представлений сукупністю конкретних значень реквізитів і ідентифікується значенням ключа (простого — один реквізит чи складеного — кілька реквізитів). Інші реквізити інформаційного об'єкта є описовими. У цьому одні й самі реквізити тільки в інформаційних об'єктах може бути ключовими, а іншихописовими. Інформаційний об'єкт може мати кілька ключей.

НОРМАЛІЗАЦІЯ ОТНОШЕНИЙ.

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

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

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

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

Наприклад, ставлення Студент = (Номер, Прізвище, Ім'я, По батькові, Дата, Група) наводять У першій нормальної форме.

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

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

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

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

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

ТИПИ СВЯЗЕЙ Все інформаційні об'єкти предметної області пов’язані між собою. Відрізняються зв’язку кількох типів, котрим введено такі позначення:. одне одного (1:1);. один до багатьох (1: М);. багато до багатьох (М: М).

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

При зв’язку один до багатьох (1:М) одному примірнику інформаційного об'єкта, А відповідає 0, 1 чи більше примірників об'єкта У, але кожен примірник об'єкта У пов’язаний лише із першого примірником об'єкта А. Графічно дане відповідність має вид.

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

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

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

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

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

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

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

ФУНКЦІОНАЛЬНІ МОЖЛИВОСТІ СУБД.

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

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

За рівнем універсальності розрізняють два класу СУБД:. системи загального призначення;. спеціалізовані системы.

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

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

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

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

Використовувані нині СУБД мають засобами забезпечення цілісності даних, і надійної безпеки, що дозволяє розробникам гарантувати велику безпеку даних з меншими витратах сил на низкоуровневое програмування. Продукти, функціонуючі серед WINDOWS, вигідно відрізняються зручністю користувальницького інтерфейсу і умонтованими засобами підвищення продуктивності. Розглянемо основні характеристики деяких СУБД — лідерів над ринком програм, призначених як розробників інформаційних систем, так й у кінцевих користувачів, У аналізовану групу програмних продуктів ввійшли: dBASE IV 2.0, компанії Borland International;

Microsoft Access 2.0;

Microsoft FoxPro 2.6 for DOS; Microsoft FoxPro 2.6 for Windows, корпорації Microsoft Corp; Paradox for DOS 4.5; Paradox for Windows, версія 4.5 компанії Borland.

Производительность СУБД Производительность СУБД оценивается:

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

. часом генерації отчета.

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

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

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

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

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

Access і Paradox for Windows Андрійовича значно ближча інших СУБД відповідають реляційної моделі за надійністю збереження цілісності даних лише на рівні бази даних; правила зберігаються разом із базою даних, і автоматично соблюдаются.

СУБД dBASE IV і FoxPro 2.6 (DOS і WINDOWS) не мають засобами цієї своєрідної, і введення у програмі процедур, які забезпечують виконання правил цілісності, доручається программиста.

Обеспечение безопасности.

Деякі СУБД передбачають кошти забезпечення безпеки даних. Такі кошти забезпечують виконання таких операцій: • шифрування прикладних програм; • шифрування даних; • захист паролем; • обмеження рівня доступу (до бази даних, до таблиці, до словника, для пользователя).

Найвищий рівень безпеки даних реалізований у СУБД dBASE IV. Адміністратор може робити призначення системі різні права доступу лише на рівні файла, поля, і навіть організувати автоматичне шифрування данных.

Добрими характеристиками забезпечення безпеки відрізняється Access 2.0. Він передбачає призначення паролів для індивідуальних користувачів чи груп користувачів і присвоєння різних прав доступу окремо таблицям, запитам, звітам, макрокомандам чи новим об'єктах лише на рівні користувача чи группы.

Работа в многопользовательских средах.

Практично всі аналізовані СУБД призначені до роботи на многопользовательских середовищах, але мають при цьому різними можливостями. Обробка даних в многопользовательских середовищах. передбачає виконання програмним продуктом наступних функцій:: • блокування бази даних, файла, записи, поля; • ідентифікацію станції, встановила блокування; • відновлення інформації після модифікації; • контролю над часом і повторення звернення; • обробку транзакцій (транзакція — послідовність операцій користувача над базою даних, яка її логічний цілісність); • роботи з мережними системами (LAN Manager, NetWare, Unix). Найкращими можливостями до роботи на многопользовательских середовищах мають СУБД Paradox for DOS 4.5, Access 2.0 і dBASE IV.

Импорт-экспорт Эта характеристика отражает:

• можливість обробки СУБД інформації, підготовленої іншими програмними засобами; • зокрема можливість використання іншими програмами даних, сформованих засобами аналізованої СУБД.

Особый цікаві такі формати файлів: ASCII-файлы, .DBF,, WK*, .XLS. Усі тут СУБД мають хорошими можливостями імпортуекспорту даних. Доступ до даних у вигляді мови SQL Мова запитів SQL (Structured Query Language) реалізований у цілий ряд популярних СУБД щодо різноманітних типів ЕОМ або як, або як альтернативний. Через своє використання є міжнародним стандартом мови запитів. Мова SQL надає розвинені можливості кінцевим користувачам, і фахівцям у сфері обробки даних [5].

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

СУБД мають доступом до даним SQL у таких випадках:. бази даних сумісні з ODBC (Open Database Connectivity — відкрите з'єднання баз данных);

. реалізована природна підтримка SQL-баз даних;. можлива реалізація SQL-запросов локальних данных.

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

Access 2.0 і Paradox for Windows працюють із джерелами SQL-данных, сумісних і системи ODBC. FoxPro (for dos і for Windows) поставляються з додатковими бібліотеками, що забезпечують доступом до SQL-базам даних, здатним працювати що з системою ODBC, але це можливість менш інтегрована, ніж кошти первинного введення інформацією Access і Paradox for Windows. Можна безпосередньо управляти базами даних Access з допомогою мови SQL і передавати наскрізні SQL-запросы сумісним зі спецификацией ODBC SQL-базам даних, таких як MS SQL Server і Oracle, отже Access здатна служити засобом розробки масштабируемых систем клиент-сервер.

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

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

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

Мовні кошти йдуть на виконання двох основних функцій:. описи уявлення бази даних;. операцій маніпулювання данными.

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

ЯОД який завжди синтаксично оформляється як самостійного мови. Він то, можливо складовою єдиного мови даних, поєднала можливості визначення даних, і маніпулювання данными.

Мова маніпулювання даними (ЯМД) дозволяє вимагати передбачені у системі операції над даними з даних. Є численні приклади мов СУБД, що об'єднує можливості описи даних, і маніпулювання даними в єдиних синтаксичних рамках. Популярним мовою що така є реляционный мову SQL. СУБД dBASE IV і FoxPro підтримують мову програмування xBASE, який до цього часу є важливим стандартом для баз даних. FoxPro 2.6 надає xBASE-программам віконні, событийно-управляемые якості. Під час упорядкування прикладної програми FoxPro використовує диспетчер проекту, управляючий різними файлами вихідного тексту та об'єктивності даних. Ця складова відстежує індивідуальні елементи: програми, набори екранних форм, звіти і файли баз даних, і дозволяє компілювати прикладну програму исполнимый файл. Мова програмування Access Basic містить функції забезпечення по протоколу OLE 2.0, дозволяють управляти об'єктами з деяких інших прикладних програм, сумісних з OLE 2.0. З іншого боку, цю мову дозволяє створювати об'єкти баз даних (запити, таблиці), змінювати структуру бази даних, і створювати індекси безпосередньо з прикладної програми. Усі програмні кошти мають автоматизованими засобами створення екранних форм, запитів, звітів, меню, наклейок, стандартних листів. До сформування зазначених візуальних і структурних об'єктів ряд СУБД використовує спеціальні інструментальні кошти, звані «майстрами «чи «чарівниками » .

КОМАНДИ ДЛЯ ВИКОНАННЯ ТИПОВИХ ОПЕРАЦИЙ Типовая структура інтерфейсу Працюючи з СУБД на екран виводяться робоче полі, і панель управління. Панель управління у своїй включає меню, допоміжну область управління і рядок підказки. Розташування цих галузей на екрані може бути довільним і від особливостей конкретної програми. Деякі СУБД дозволяють виводити на екран вікно директив (командне вікно) чи рядок команд. Познайомитися з виглядом екрана таких програмних засобів можна на прикладі вікна СУБД Access 2.0. Рядок меню містить основні режими програми. Вибравши них, користувач отримує доступом до ниспадающему підменю, який містить перелік назв команд. Через війну вибору деяких команд спадаючого меню з’являються додаткові підміню. Допоміжна область управління включає: • рядок стану; • панелі інструментів; • вертикальну і горизонтальну лінійки прокрутки.

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

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

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

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

. введенням з клавіатури першої літери обраної команды.

Одержати додаткову інформацію про командах, складових меню СУБД і використанні їх можна, зайшовши у режим помощи.

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

. команди до роботи з файлами;

. команди редактирования;

. команди форматирования;

. команди до роботи з окнами;

. команди до роботи на основних режимах СУБД (таблиця, форма, запит, отчет);

. отримання довідкової информации.

Команды до роботи з файлами При працювати з файлами програма дає можливість пользователю:

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

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

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

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

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

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

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

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

Создание структури таблиці не пов’язані з заповненням таблиць даними, поетом) дві операції можна рознести у времени.

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

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

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

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

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

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

Інформаційна модель СУБД.

Попереднє планування, підготовка даних, послідовність створення інформаційного модели.

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

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

Об'єкти об'єднують у класи по загальним характеристикам. Наприклад, в пропозиції «Білий Будинок є будинком», «Білий Будинок» представляє об'єкт, а «будинок» — клас. Класи позначаються абстрактними іменниками. Клас — це безліч предметів реального світу, пов’язаних спільністю структури та поведением.

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

Проектування концептуальної моделі бази даних: Аналіз даних: збір основних даних (наприклад, об'єкти, зв’язок між объектами).

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

Визначення взаимосвязей.

Взаємозв'язок висловлює відображення чи зв’язок між двома множинами даних. Розрізняють взаємозв'язку типу «одне одного», «один до багатьох» і «багато до многим».

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

Наступний що становить нам інтерес об'єкт — Товар. Цей об'єкт властиво «унікальний ключ товару», «найменування товара».

Другий аналізований об'єкт — Постачальник. Його властивостями є «унікальний ключ постачальника», «найменування поставщика».

Третій аналізований об'єкт — Замовник. Його властивостями є «унікальний ключ замовника», «найменування заказчика».

Взаємозв'язок «одне одного» (між двома типами объектов).

Припустимо, в момент часу один замовник може зробити лише одне замовлення. І тут між об'єктами Замовник і Товар встановлюється взаємозв'язок «до одному».

Взаємозв'язок «один до багатьох» (між двома типами объектов).

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

Взаємозв'язок «одне одного» (між двома свойствами).

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

Взаємозв'язок «один до багатьох» (між двома свойствами).

Ім'я постачальника та її номер існують спільно. Постачальників з однаковими іменами можна знайти багато, але вони мають різні номери. Кожному постачальнику присвоюється унікальний номер. Це означає, що даному номера постачальника відповідає тільки одне ім'я. Взаємозв'язок «один до багатьох» позначається одинарної стрілкою у напрямку «одному» і подвійний стрілкою у бік до «многим».

Початкова схема данных.

|Функціональна |Дослідження струмів |Дані виявлені в | |модель |Даних |ході розробки | |Відділ обробки | |Заявки | |заявок | | | | | |Договору | |Договорів | |Постачальники | | | |Замовники | |Ведення рахунків | |Рахунки | |Вантаження | |Накладні | | | |Товар | | | |Інвентаризація | | | |Довідки |.

рис. 1.

Визначення об'єктів Виділимо такі об'єкти: 1. ТОВАР — (Т); 2. ЗАМОВНИК — (З); 3. ПОСТАЧАЛЬНИК — (П); 4. РАХУНКИ — (З); 5. ДОГОВІР — (Д); 6. НАКЛАДНІ - (Н).

Початковий графічне уявлення концептуальної модели.

| |Т | | |З | |П | | |З | | |М | |Д |.

рис. 2.

Завдання первинних і альтернативних ключів, визначення властивостей объектов.

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

Приведення моделі до необхідному 1 рівню нормальної формы.

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

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

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

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

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

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

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

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

Ієрархічна модель даних будується за принципом ієрархії типів об'єктів, тобто один тип об'єкта головне, інші ж, що перебувають у нижчі рівні ієрархії, — підлеглими. Між головним і підлеглими об'єктами встановлюється взаємозв'язок «один до багатьох». У той водночас кожному за примірника головного об'єкта може бути кілька примірників підлеглих типів об'єктів. Взаємозв'язку між об'єктами нагадують взаємозв'язку в генеалогічному дереві за єдиним винятком: кожному за породженого (підлеглого) типу об'єкта може бути лише одне вихідний (головний) тип объекта.

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

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

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

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

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

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

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

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

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

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

У индексно-последовательном методі доступу індексний файл завжди упорядкований по так званому первинному ключу. Первинний ключ — головний атрибут фізичної записи. За значенням ідентифікується фізична запис. До того часу, доки це можливо, записи зберігаються у тієї ж логічного послідовності, як і індекс (тому й назва «индекснопослідовний метод доступу »).

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

Розглянемо докладніше програмні продукти компанії Microsoft, саме Visual FoxPro 3.0, Visual Basic 4.0, Visual З++, Access 7.0, SQL Server 6.5. Найцікавішою рисою цих пакетів є їхньою великі можливості інтеграції, співпраці і видів використання даних, оскільки дані пакети є продуктами одного виробника, і навіть використовують подібні технології обміну данными.

Visual FoxPro вирізняється високою швидкістю, має вмонтований объектно-ориентированный мову програмування з допомогою xBase і SQL, діалекти яких вмонтовані в численні СУБД. Має високий рівень об'єктної моделі. З використанням в обчислювальних мережах забезпечує як монопольний, і окремий доступ користувачів до даних. Застосовується для додатків масштабу підприємства до роботи в різних платформах: Windows 3. x, Windows 95, Macintosh… Мінімальні ресурси ПК: для Visual FoxPro версії 3.0 — процесор 468DX, Windows 3.1, 95, NT, обсяг оперативної пам’яті 8 (12) МБ, яку він обіймав обсяг на ЖМД 15−80 МБ, а Visual FoxPro версії 5.0 (випущена 1997 року) — Windows 95 чи NT, 486 з тактовою частотою 50 МГц, 10 МБ ОЗУ, від 15 до 240 МБ на ЖМД.

Access входить до складу найпопулярнішого пакета Microsoft Office. Основні переваги: знаком багатьом кінцевим користувачам й володіє високу стійкість даних, простий лідера в освоєнні, можна використовувати непрофесійним програмістом, дозволяє готувати звіти з баз даних різних форматів. Призначений до створення звітів довільній форми виходячи з різних даних, і розробки некомерційних додатків. Мінімальні ресурси ПК: процесор 468DX, Windows 3.1, 95, NT, обсяг оперативної пам’яті 12 (16) МБ, яку він обіймав обсяг на ЖМД 10−40 Мб.

Visual Basic — це універсальний объектно-ориентированный мову програмування, діалекти якого вмонтовані в Access, Visual FoxPro. Переваги: універсальність, можливість створення компонентів OLE, невисокі вимоги до апаратним ресурсів ЕОМ. Застосовується до створення додатків середньої потужності, які пов’язані з великою інтенсивністю обробки даних, розробки компонентів OLE, інтеграція компонентів Microsoft Office. Мінімальні ресурси ПК: процесор 368DX, Windows 3.1, 95, NT, обсяг оперативної пам’яті 6 (16) МБ, яку він обіймав обсяг на ЖМД 8−36 Мб.

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

SQL Server — сервер баз даних, реалізує підхід «клієнт-сервер» і взаємодіє зі зазначеними пакетами. Головні гідності: високий рівень захисту даних, потужні кошти на обробки даних, висока продуктивність. Область застосування: зберігання великих обсягів даних, зберігання високоцінних даних чи даних, потребують дотримання режиму таємності. Мінімальні ресурси ПК: процесор 468DX-33МГц, Windows NT, обсяг оперативної пам’яті 16 (32) МБ, яку він обіймав обсяг на ЖМД 80 Мб.

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

Принципи організації даних, які у основі нових СУБД.

Сучасні СУБД є объектно-ориентированными і реляционными. Основний одиницею є об'єкт, має властивості, та зв’язку між об'єктами. СУБД використовують кілька моделей даних: ієрархічну і мережну (з 1960;х років) і реляционную (з 70-х). Основне відмінність даних моделей у виставі взаємозв'язків між объектами.

Ієрархічна модель даних будується за принципом ієрархії об'єктів, тобто один тип об'єкта головне, все нижележащие — підлеглими. Встановлюється зв’язок «один до багатьох», тобто для деякого головного типу є кілька підлеглих типів об'єктів. Інакше, головний тип іменується вихідним типом, а підлеглі - породженими. У підлеглих типів можна своє чергу підлеглі типи. Найвищий в ієрархії вузол (сукупність атрибутів) називають корневым.

Мережевий модель даних будується за принципом «головний і підлеглий тип одночасно», тобто будь-який тип даних одночасно може водночас породжувати кілька підлеглих типів (власником набору) і «бути підлеглим для кількох головних (бути членом набора).

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

Об'єкт (Сутність) — елемент будь-якої системи, інформацію про якому зберігається. Об'єкт може бути як реальним (наприклад, людина), і абстрактним (наприклад, подія — надходження людини у стационар).

Атрибут — інформаційне відображення властивостей об'єкта. Кожен об'єкт характеризується набором атрибутов.

Таблиця — упорядкована структура, що складається з кінцевого набору однотипних записей.

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

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

Сучасні технології, використовувані регулярно працюють з данными.

Технологія «Клієнт-сервер» — технологія, поділяє додатокСУБД на частини: клієнтську (інтерактивний графічний інтерфейс, розташований за комп’ютером користувача) і сервер, власне що здійснює управління даними, поділ інформації, адміністрування і безпека, які перебувають на виділеному комп’ютері. Взаємодія «клієнт-сервер» здійснюється так: клієнтська частина докладання формує запит до сервера баз даних, у якому виконуються все команди, а результат виконання запиту вирушає клієнту для перегляду і видів використання. Ця технологія застосовується, коли розміри баз даних великі, коли великі розміри обчислювальної мережі, і продуктивність при обробці даних, що зберігаються не так на комп’ютері користувача (у великому установі зазвичай має місце саме що ситуація). Якщо технологія «клієнт-сервер» на застосовується, то тут для обробки навіть кількох записів весь файл копіюється на комп’ютер користувача, лише потім обробляється. У цьому різко зростає завантаження мережі, і знижується продуктивності праці багатьох сотрудников.

Microsoft Access, Microsoft Visual FoxPro, Microsoft Visual Basic забезпечують кошти на створення клієнтських частин у додатках «клієнт-сервер», які поєднують у собі кошти перегляду, графічний інтерфейс і кошти побудови запитів, а Microsoft SQL Server є нині однією з потужних серверів баз данных.

OLE 2.0 (Object Linking and Embedding — зв’язування та впровадження об'єктів) — стандарт, описує правила інтеграції прикладних програм. Застосовується від використання можливостей інших додатків. OLE 2.0 використовується визначення та Постійної спільної використання об'єктів кількома додатками, які підтримують цю технологію. Наприклад, використання у середовищі Access таблиць Excel та її потужних коштів побудови діаграм чи використання даних, підготовлених Access, у фінансових звітах складених в редакторі текстів Word (зв'язування чи включення объекта).

OLE Automation (Автоматизація OLE) — компонент OLE, дозволяє програмним шляхом встановлювати властивості і ставити команди для об'єктів іншого докладання. Дозволяє без необхідності виходу чи переходу до іншого вікно скористатися наявними можливостями потрібного докладання. Додаток, що дозволяє іншим прикладним програмам вживати свої об'єкти називається OLE сервером. Додаток, що може управляти об'єктами OLE серверів називається OLE контролер чи OLE клієнт. З розглянутих програмних засобів як OLE серверів можуть виступати Microsoft Access, і навіть Microsoft Excel, Word і Graph… Microsoft Visual FoxPro 3.0 і 5.0 може бути лише у вигляді OLE клиента.

RAD (Rapid Application Development — Швидка розробка додатків) — підхід до розробки додатків, який передбачає широке використання готових компонентів і/або додатків і пакетів (зокрема від різних производителей).

ODBC (Open Database Connectivity — відкритий доступом до баз даних) — технологія, дозволяє себе використовувати бази даних, створені іншим додатком з допомогою SQL.

SQL (Structured Query Language — мову структурованих запитів) — універсальну мистецьку мову, готовий до створення і виконання запитів, обробки даних як у власній базі даних докладання, і з базами даних, створених іншими додатками, підтримують SQL. Також SQL застосовується керувати реляционными базами данных.

VBA (Visual Basic for Applications — Visual Basic для Додатків) — різновид (діалект) объектно-ориентированного мови програмування Visual Basic, встраиваемая в програмні пакеты.

1. Б. Богумирский.

2. Ефективна робота на IBM PC серед Windows 95.

3. СПб, «Пітер», 1997, 1000с.

4. Д. Вейскас.

5. Ефективна роботу з Microsoft Access 7.0 і. «Microsoft Press», 1997, 864с.

6. Дж. Вудкок, М. Янг.

7. Ефективна роботу з Microsoft Office 95 і. «Microsoft Press», 1000с.

8. А. Горєв, З. Макашарипов, Р. Ахаян.

Ефективна роботу з СУБД.

9. СПб, «Пітер», 1997, 704с. 10. А. У. Потапкин і. Основи Visual Basic для пакета Microsoft Office ii. М, «Эком», 1995, 256с. «11. Електронна вбудована гіпертекстова довідкова система Microsoft.

Access, файл MSACC20. HLP, 4.7 Мбайта.

12. Журнал «PC Magazine Russian Edition» № 7 1994, стаття У. Плейна,.

«Microsoft Access».

13. Журнал «PC Magazine Russian Edition» № 5 1994.

14. Журнал «КомпьюТерра» № 37−38 1994.