Нарощування економічної і статистичної інформації в двухструктурних реляційних базах даних
ЗМІСТ
"1-4"
Введення ................................................. .................................................. .........
1. Поняття інформаційної системи ............................................... .............
2. Поняття бази даних ............................................... ...................................
3. Еволюція концепцій баз даних .............................................. .................
4. Вимоги, яким повинна задовольняти організація бази даних.
4.1. Встановлення багатосторонніх зв'язків ............................................... ....
4.2. Продуктивність ................................................. ..............................
4.3. Мінімальні витрати ................................................ ...........................
4.4. Мінімальна надмірність ................................................ ..................
4.5. Можливості пошуку ................................................ ..............................
4.6. Цілісність ................................................. ...........................................
4.7. Безпека і секретність ............................................... .....................
4.8. Зв'язок з минулим ............................................... .....................................
4.9. Зв'язок з майбутнім ............................................... .....................................
4.10. Простота використання ................................................ .....................
5. Моделі представлення даних ............................................... ....................
5.1. Ієрархічна модель даних ............................................... ...............
5.2. Мережева модель даних ............................................... ..........................
5.3. Реляційна модель даних ............................................... ...................
5.3.1. Таблиці ................................................. ............................................
5.3.2. Ключові поля ................................................ ..................................
5.3.3. Індекси ................................................. ............................................
5.3.4. Відносини предок / нащадок .............................................. ...............
5.3.5. Зовнішні ключі ................................................ ................................
5.3.6. Реляційна алгебра ................................................ ........................
5.3.7. Нормалізація бази даних ............................................... ..............
5.3.7.1. Перша нормальна форма ............................................... ...........
5.3.7.2. Друга нормальна форма ............................................... ...........
5.3.7.3. Третя нормальна форма ............................................... ...........
5.3.7.4. Четверта нормальна форма ............................................... ......
5.3.7.5. П'ята нормальна форма ............................................... .............
6. Мова SQL як стандартна мова баз даних ........................................... .
6.1. Мова SQL ................................................ ................................................
6.2. Переваги SQL ................................................ ....................................
6.2.1. Незалежність від конкретних СУБД .............................................. .
6.2.2. Переносимість з однієї обчислювальної системи на інші .........
6.2.3. Стандарти мови SQL ............................................... ........................
6.2.4. Схвалення SQL компанією IBM (СУБД DB2 ).................................
6.2.5. Протокол ODBC і компанія Microsoft ...........................................
6.2.6. Реляційна основа ................................................ ..........................
6.2.7. Високорівнева структура, що нагадує англійську мову ....
6.2.8. Інтерактивні запити ................................................ ...................
6.2.9. Програмний доступ до бази даних ............................................. ..
6.2.10 ............................................... ..... Різні представлення даних
6.2.11 ............................ Повноцінний мову для роботи з базами даних
6.2.12 ............................................... ... Динамічне визначення даних
6.2.13 ............................................... ................ Архітектура клієнт / сервер
7. Архітектури баз даних ............................................... .............................
7.1. Локальні бази даних та архітектура "файл-сервер ".......................
7.2. Віддалені бази даних та архітектура "клієнт-сервер "....................
8. Середовище Delphi як засіб для розробки СУБД .....................................
8.1. Високопродуктивний компілятор в машинний код ....................
8.2. Потужний об'єктно-орієнтована мова ..........................................
8.3. Об'єктно-орієнтована модель програмних компонент ............
8.4. Бібліотека візуальних компонент ............................................... ........
8.5. Форми, модулі та метод розробки "Two-Way Tools ".......................
8.6. Масштабовані кошти для побудови баз даних ......................
8.7. Налаштовувана середовище розробника ............................................... .......
8.8. Незначні вимоги до апаратних засобів .........................
9. Проектування бази даних ............................................... .....................
Инфологическая модель даних ............................................... ....................
9.2. Инфологическая модель даних "сутність-зв'язок "..............................
9.3. Даталогіческая модель даних ............................................... ..............
9.4. Перехід від ER - моделі до реляційної ........................................... ....
9.5. Фізична модель даних ............................................... .....................
9.6. Етапи проектування бази даних .............................................. ......
10. Практична частина ................................................ ......................................
10.1. Предметна область і завдання, покладені на базу даних ...........
10.2. Визначення об'єктів бази даних .............................................. .....
10.3. Инфологическая і даталогіческая моделі бази даних ..................
10.4. Фізичний опис моделі ............................................... ...............
10.5. Програмна реалізація ................................................ ......................
Висновок ................................................. .................................................. .....
Список літератури ................................................ ...........................................
ВСТУП
Досвід застосування комп'ютерів для побудови прикладних систем обробки даних показує, що найефективнішим інструментом тут є системи управління базами даних (СКБД, англ. DBMS - DataBase Management System).
Потоки інформації, що циркулюють у світі, який нас оточує, величезні. У часі вони мають тенденцію до збільшення. Тому в будь-якій організації, як великий, так і маленькою, виникає проблема такої організації управління даними, яка забезпечила б найбільш ефективну роботу. Деякі організації використовують для цього шафи з папками, але більшість віддає перевагу комп'ютеризовані способи - бази даних, що дозволяють ефективно зберігати, структурувати і систематизувати великі обсяги даних. І вже сьогодні без баз даних неможливо уявити роботу більшості фінансових, промислових, торговельних та інших організацій. Не будь баз даних, вони б просто захлинулися в інформаційній лавині.
Існує багато вагомих причин переведення існуючої інформації на комп'ютерну основу. Зараз вартість зберігання інформації у файлах на комп'ютері дешевше, ніж на папері. Бази даних дозволяють зберігати, структурувати інформацію і витягувати оптимальним для користувача чином. Використання клієнт / серверних технологій дозволяють зберегти значні кошти, а головне і час для отримання необхідної інформації, а також спрощують доступ і ведення, оскільки вони грунтуються на комплексній обробці даних і централізації їх зберігання. Крім того комп'ютер дозволяє зберігати будь-які формати даних текст, креслення, дані в рукописній формі, фотографії, записи голосу і т.д.
Для використання таких величезних обсягів збереженої інформації, крім розвитку системних пристроїв, засобів передачі даних, пам'яті необхідні засоби забезпечення діалогу людина-комп'ютер, які дозволяють користувачеві вводити запити, читати файли, модифіковані записані дані, додавати нові дані або приймати рішення на підставі даних, що зберігаються. Для забезпечення цих функцій створені спеціалізовані засоби - системи управління базами даних (СКБД). Сучасні СУБД - розраховані на багато системи управління базою даних, які спеціалізується на управлінні масивом інформації одним або безліччю одночасно працюючих користувачів.
Нарощування економічної і статистичної інформації відбувається щодня і щомиті. Якщо раніше, у зв'язку з недостатньою комп'ютеризацією економіки, інформації в електронному вигляді було дуже мало, то сьогодні це вже звичайна справа. У зв'язку з цим виникає нова проблема - пошук і відбір потрібної інформації серед того океану даних, які ми можемо сьогодні спостерігати в Інтернеті і локальних корпоративних мережах. Тому правильна організація нарощування економічної та статистичної інформації для подальшого її швидкого вилучення та ефективного використання - дуже актуальна тема сьогодні.
Мета даної дипломної роботи - дати оцінку новим технологіям організації накопичення, заощадження, швидкого пошуку, відбору та добування інформації, які базуються на реляційної концепції моделей даних, і на конкретному прикладі показати переваги однієї з розглянутих технологій.
Реалізація даного завдання проводиться в системі програмування Delphi 5.0, яка має широкими можливостями щодо створення додатків баз даних, необхідним набором драйверів для доступу до найвідоміших форматів баз даних, зручними і розвиненими засобами для доступу до інформації, розташованої як на локальному диску, так і на віддаленому сервері, а також великим колекцією візуальних компонент для побудови відображаються на екрані вікон, що необхідно для створення зручного інтерфейсу між користувачем і виконуваним кодом.
Якщо ми розглянемо сукупність деяких об'єктів, то зможемо виділити об'єкти, що володіють однаковими властивостями. Такі об'єкти виділяють в окремі класи. Усередині виділеного класу об'єкти можна впорядковувати як за загальними правилами класифікування, наприклад за алфавітом, так і по деяких конкретних загальних ознак, наприклад за кольором або матеріалу. Групування об'єктів за певними ознаками значно полегшує пошук і відбір інформації. Всі ці відомості накопичуються в сукупності файлів званої базою даних, а для управління цими файлами створюються спеціальні програми - системи управління базами даних (СКБД). [10].
Інформаційні системи (ІС) можна умовно розділити на фактографічні та документальні.
У фактографічних ІС реєструються факти - конкретні значення даних (атрибутів) про об'єкти реального світу. Основна ідея таких систем полягає в тому, що всі відомості про об'єкти (прізвища людей та назви предметів, числа, дати) повідомляються комп'ютера в якомусь заздалегідь обумовленому форматі (наприклад дата - у вигляді комбінації ДД.ММ.РРРР). Інформація, з якою працює фактографічна ІС, має чітку структуру, що дозволяє машині відрізняти одне дане від іншого, наприклад прізвище від посади людину, дату народження від зростання і т.п. Тому фактографічна система здатна давати однозначні відповіді на поставлені питання.
Документальні ІС обслуговують принципово інший клас завдань, які не передбачають однозначної відповіді на поставлене питання. Базу даних таких систем утворює сукупність неструктурованих текстових документів (статті, книги, реферати і т.д.) і графічних об'єктів, забезпечена тим чи іншим формалізованим апаратом пошуку. Мета системи, як правило, - видати у відповідь на запит користувача список документів або об'єктів, в якійсь мірі задовольняють сформульованим у запиті умов.
Зазначена класифікація ІС певною мірою застаріла, оскільки сучасні фактографічні системи часто працюють з неструктурованими блоками інформації (текстами, графікою, звуком, відео), забезпеченими структурованими опису. При відомі чинники фактографічна система може перетворитися на документальну (і навпаки). [1,11].
Для систем обробки економічної і статистичної інформації більше підходять фактографічні ІС, які використовуються буквально у всіх сферах людської діяльності.
Дійсно, більшість існуючих на сьогоднішній день баз даних призначено для обмеженого ряду додатків. Часто на одному комп'ютері створюється кілька баз даних. Згодом бази даних, призначені для реалізації окремих споріднених функцій, можна буде об'єднати, якщо таке об'єднання буде сприяти збільшенню ефективності та інтенсивності використання всієї системи.
Базу даних можна визначити як сукупність взаємозв'язаних що зберігаються разом при наявності такої мінімальної надмірності, яка допускає їх використання оптимальним чином для одного або декількох додатків; дані запам'ятовуються так, щоб вони були незалежні від програм, що використовують ці дані; для додавання нових або модифікації існуючих даних , а також для пошуку даних в базі даних застосовується загальний керований спосіб. [1,12].
Кажуть, що система містить сукупність баз даних, якщо ці бази даних структурно повністю самостійні. У системах з простою організацією даних для кожного додатка створюється своя сукупність записів. Призначення бази даних полягає в тому, щоб одну і ту ж сукупність даних можна було використовувати для максимально можливого числа додатків. Виходячи з цього, базу даних часто розробляють як сховище такої інформації, необхідність якої виникає в процесі виконання певних функцій на заводі, урядовій установі або який-небудь іншої організації. Така база даних повинна забезпечувати можливість не тільки отримання інформації, але також постійної її модифікації, необхідної для процесів управління в даній організації, може виявитися, що для отримання інформації для цілей планування або відповідей на питання потрібно здійснювати пошук в базі даних. Сукупністю даних можуть користуватися кілька відомств незалежно від того, чи є при цьому між ними відомчі бар'єри. [12].
ReportSmith використовує концепцію "живих даних", тобто робота відбувається з справжніми даними весь час, а не тільки тоді, коли запускається перегляд (divview). Крім цього, ReportSmith легко працює з надзвичайно великими БД за допомогою адаптивної технології управління пам'яттю. У ReportSmith можна керувати тим, де зберігається результат вибірки даних з БД: в локальний пам'яті клієнтської PC, на жорсткому диску клієнтської PC, або на сервері. ЗМІСТ
"1-4"
Введення ................................................. .................................................. .........
1. Поняття інформаційної системи ............................................... .............
2. Поняття бази даних ............................................... ...................................
3. Еволюція концепцій баз даних .............................................. .................
4. Вимоги, яким повинна задовольняти організація бази даних.
4.1. Встановлення багатосторонніх зв'язків ............................................... ....
4.2. Продуктивність ................................................. ..............................
4.3. Мінімальні витрати ................................................ ...........................
4.4. Мінімальна надмірність ................................................ ..................
4.5. Можливості пошуку ................................................ ..............................
4.6. Цілісність ................................................. ...........................................
4.7. Безпека і секретність ............................................... .....................
4.8. Зв'язок з минулим ............................................... .....................................
4.9. Зв'язок з майбутнім ............................................... .....................................
4.10. Простота використання ................................................ .....................
5. Моделі представлення даних ............................................... ....................
5.1. Ієрархічна модель даних ............................................... ...............
5.2. Мережева модель даних ............................................... ..........................
5.3. Реляційна модель даних ............................................... ...................
5.3.1. Таблиці ................................................. ............................................
5.3.2. Ключові поля ................................................ ..................................
5.3.3. Індекси ................................................. ............................................
5.3.4. Відносини предок / нащадок .............................................. ...............
5.3.5. Зовнішні ключі ................................................ ................................
5.3.6. Реляційна алгебра ................................................ ........................
5.3.7. Нормалізація бази даних ............................................... ..............
5.3.7.1. Перша нормальна форма ............................................... ...........
5.3.7.2. Друга нормальна форма ............................................... ...........
5.3.7.3. Третя нормальна форма ............................................... ...........
5.3.7.4. Четверта нормальна форма ............................................... ......
5.3.7.5. П'ята нормальна форма ............................................... .............
6. Мова SQL як стандартна мова баз даних ........................................... .
6.1. Мова SQL ................................................ ................................................
6.2. Переваги SQL ................................................ ....................................
6.2.1. Незалежність від конкретних СУБД .............................................. .
6.2.2. Переносимість з однієї обчислювальної системи на інші .........
6.2.3. Стандарти мови SQL ............................................... ........................
6.2.4. Схвалення SQL компанією IBM (СУБД DB2 ).................................
6.2.5. Протокол ODBC і компанія Microsoft ...........................................
6.2.6. Реляційна основа ................................................ ..........................
6.2.7. Високорівнева структура, що нагадує англійську мову ....
6.2.8. Інтерактивні запити ................................................ ...................
6.2.9. Програмний доступ до бази даних ............................................. ..
6.2.10 ............................................... ..... Різні представлення даних
6.2.11 ............................ Повноцінний мову для роботи з базами даних
6.2.12 ............................................... ... Динамічне визначення даних
6.2.13 ............................................... ................ Архітектура клієнт / сервер
7. Архітектури баз даних ............................................... .............................
7.1. Локальні бази даних та архітектура "файл-сервер ".......................
7.2. Віддалені бази даних та архітектура "клієнт-сервер "....................
8. Середовище Delphi як засіб для розробки СУБД .....................................
8.1. Високопродуктивний компілятор в машинний код ....................
8.2. Потужний об'єктно-орієнтована мова ..........................................
8.3. Об'єктно-орієнтована модель програмних компонент ............
8.4. Бібліотека візуальних компонент ............................................... ........
8.5. Форми, модулі та метод розробки "Two-Way Tools ".......................
8.6. Масштабовані кошти для побудови баз даних ......................
8.7. Налаштовувана середовище розробника ............................................... .......
8.8. Незначні вимоги до апаратних засобів .........................
9. Проектування бази даних ............................................... .....................
Инфологическая модель даних ............................................... ....................
9.2. Инфологическая модель даних "сутність-зв'язок "..............................
9.3. Даталогіческая модель даних ............................................... ..............
9.4. Перехід від ER - моделі до реляційної ........................................... ....
9.5. Фізична модель даних ............................................... .....................
9.6. Етапи проектування бази даних .............................................. ......
10. Практична частина ................................................ ......................................
10.1. Предметна область і завдання, покладені на базу даних ...........
10.2. Визначення об'єктів бази даних .............................................. .....
10.3. Инфологическая і даталогіческая моделі бази даних ..................
10.4. Фізичний опис моделі ............................................... ...............
10.5. Програмна реалізація ................................................ ......................
Висновок ................................................. .................................................. .....
Список літератури ................................................ ...........................................
ВСТУП
Досвід застосування комп'ютерів для побудови прикладних систем обробки даних показує, що найефективнішим інструментом тут є системи управління базами даних (СКБД, англ. DBMS - DataBase Management System).
Потоки інформації, що циркулюють у світі, який нас оточує, величезні. У часі вони мають тенденцію до збільшення. Тому в будь-якій організації, як великий, так і маленькою, виникає проблема такої організації управління даними, яка забезпечила б найбільш ефективну роботу. Деякі організації використовують для цього шафи з папками, але більшість віддає перевагу комп'ютеризовані способи - бази даних, що дозволяють ефективно зберігати, структурувати і систематизувати великі обсяги даних. І вже сьогодні без баз даних неможливо уявити роботу більшості фінансових, промислових, торговельних та інших організацій. Не будь баз даних, вони б просто захлинулися в інформаційній лавині.
Існує багато вагомих причин переведення існуючої інформації на комп'ютерну основу. Зараз вартість зберігання інформації у файлах на комп'ютері дешевше, ніж на папері. Бази даних дозволяють зберігати, структурувати інформацію і витягувати оптимальним для користувача чином. Використання клієнт / серверних технологій дозволяють зберегти значні кошти, а головне і час для отримання необхідної інформації, а також спрощують доступ і ведення, оскільки вони грунтуються на комплексній обробці даних і централізації їх зберігання. Крім того комп'ютер дозволяє зберігати будь-які формати даних текст, креслення, дані в рукописній формі, фотографії, записи голосу і т.д.
Для використання таких величезних обсягів збереженої інформації, крім розвитку системних пристроїв, засобів передачі даних, пам'яті необхідні засоби забезпечення діалогу людина-комп'ютер, які дозволяють користувачеві вводити запити, читати файли, модифіковані записані дані, додавати нові дані або приймати рішення на підставі даних, що зберігаються. Для забезпечення цих функцій створені спеціалізовані засоби - системи управління базами даних (СКБД). Сучасні СУБД - розраховані на багато системи управління базою даних, які спеціалізується на управлінні масивом інформації одним або безліччю одночасно працюючих користувачів.
Нарощування економічної і статистичної інформації відбувається щодня і щомиті. Якщо раніше, у зв'язку з недостатньою комп'ютеризацією економіки, інформації в електронному вигляді було дуже мало, то сьогодні це вже звичайна справа. У зв'язку з цим виникає нова проблема - пошук і відбір потрібної інформації серед того океану даних, які ми можемо сьогодні спостерігати в Інтернеті і локальних корпоративних мережах. Тому правильна організація нарощування економічної та статистичної інформації для подальшого її швидкого вилучення та ефективного використання - дуже актуальна тема сьогодні.
Мета даної дипломної роботи - дати оцінку новим технологіям організації накопичення, заощадження, швидкого пошуку, відбору та добування інформації, які базуються на реляційної концепції моделей даних, і на конкретному прикладі показати переваги однієї з розглянутих технологій.
Реалізація даного завдання проводиться в системі програмування Delphi 5.0, яка має широкими можливостями щодо створення додатків баз даних, необхідним набором драйверів для доступу до найвідоміших форматів баз даних, зручними і розвиненими засобами для доступу до інформації, розташованої як на локальному диску, так і на віддаленому сервері, а також великим колекцією візуальних компонент для побудови відображаються на екрані вікон, що необхідно для створення зручного інтерфейсу між користувачем і виконуваним кодом.
1. Поняття інформаційної системи
Століттями людство накопичувало знання, навички роботи, відомості про навколишній світ, іншими словами - збирало інформацію. Спочатку інформація передавалася з покоління в покоління у вигляді переказів та усних оповідань. Виникнення і розвиток книжкової справи дозволило передавати і зберігати інформацію в більш надійному письмовому вигляді. Відкриття в галузі електрики привели до появи телеграфу, телефону, радіо, телебачення - коштів, що дозволяють оперативно передавати і накопичувати інформацію. Розвиток прогресу зумовило різке зростання інформації, у зв'язку з чим, питання про її збереження та переробки ставав рік від року гостріше. З появою обчислювальної техніки значно спростилися способи зберігання, а головне, обробки інформації. Розвиток обчислювальної техніки на базі мікропроцесорів призводить до вдосконалення комп'ютерів і програмного забезпечення. З'являються програми, здатні обробити великі потоки інформації. За допомогою таких програм створюються інформаційні системи. Метою будь-якої інформаційної системи є обробка даних про об'єкти та явища реального світу і надання людині потрібної інформації про них. [11].Якщо ми розглянемо сукупність деяких об'єктів, то зможемо виділити об'єкти, що володіють однаковими властивостями. Такі об'єкти виділяють в окремі класи. Усередині виділеного класу об'єкти можна впорядковувати як за загальними правилами класифікування, наприклад за алфавітом, так і по деяких конкретних загальних ознак, наприклад за кольором або матеріалу. Групування об'єктів за певними ознаками значно полегшує пошук і відбір інформації. Всі ці відомості накопичуються в сукупності файлів званої базою даних, а для управління цими файлами створюються спеціальні програми - системи управління базами даних (СКБД). [10].
Інформаційні системи (ІС) можна умовно розділити на фактографічні та документальні.
У фактографічних ІС реєструються факти - конкретні значення даних (атрибутів) про об'єкти реального світу. Основна ідея таких систем полягає в тому, що всі відомості про об'єкти (прізвища людей та назви предметів, числа, дати) повідомляються комп'ютера в якомусь заздалегідь обумовленому форматі (наприклад дата - у вигляді комбінації ДД.ММ.РРРР). Інформація, з якою працює фактографічна ІС, має чітку структуру, що дозволяє машині відрізняти одне дане від іншого, наприклад прізвище від посади людину, дату народження від зростання і т.п. Тому фактографічна система здатна давати однозначні відповіді на поставлені питання.
Документальні ІС обслуговують принципово інший клас завдань, які не передбачають однозначної відповіді на поставлене питання. Базу даних таких систем утворює сукупність неструктурованих текстових документів (статті, книги, реферати і т.д.) і графічних об'єктів, забезпечена тим чи іншим формалізованим апаратом пошуку. Мета системи, як правило, - видати у відповідь на запит користувача список документів або об'єктів, в якійсь мірі задовольняють сформульованим у запиті умов.
Зазначена класифікація ІС певною мірою застаріла, оскільки сучасні фактографічні системи часто працюють з неструктурованими блоками інформації (текстами, графікою, звуком, відео), забезпеченими структурованими опису. При відомі чинники фактографічна система може перетворитися на документальну (і навпаки). [1,11].
Для систем обробки економічної і статистичної інформації більше підходять фактографічні ІС, які використовуються буквально у всіх сферах людської діяльності.
2. Поняття бази даних.
Існує добре відоме, але важко реалізовується на практиці поняття бази даних як великого за обсягом сховища, в яке організація поміщає всі необхідні їй дані і з якого різні користувачі можуть ці дані отримувати. Пристрої пам'яті, в яких зберігаються всі дані, можуть бути розташовані в одному або декількох місцях, у останньому випадку вони повинні бути пов'язані засобами передачі даних. До даних повинні мати доступ програми.Дійсно, більшість існуючих на сьогоднішній день баз даних призначено для обмеженого ряду додатків. Часто на одному комп'ютері створюється кілька баз даних. Згодом бази даних, призначені для реалізації окремих споріднених функцій, можна буде об'єднати, якщо таке об'єднання буде сприяти збільшенню ефективності та інтенсивності використання всієї системи.
Базу даних можна визначити як сукупність взаємозв'язаних що зберігаються разом при наявності такої мінімальної надмірності, яка допускає їх використання оптимальним чином для одного або декількох додатків; дані запам'ятовуються так, щоб вони були незалежні від програм, що використовують ці дані; для додавання нових або модифікації існуючих даних , а також для пошуку даних в базі даних застосовується загальний керований спосіб. [1,12].
Кажуть, що система містить сукупність баз даних, якщо ці бази даних структурно повністю самостійні. У системах з простою організацією даних для кожного додатка створюється своя сукупність записів. Призначення бази даних полягає в тому, щоб одну і ту ж сукупність даних можна було використовувати для максимально можливого числа додатків. Виходячи з цього, базу даних часто розробляють як сховище такої інформації, необхідність якої виникає в процесі виконання певних функцій на заводі, урядовій установі або який-небудь іншої організації. Така база даних повинна забезпечувати можливість не тільки отримання інформації, але також постійної її модифікації, необхідної для процесів управління в даній організації, може виявитися, що для отримання інформації для цілей планування або відповідей на питання потрібно здійснювати пошук в базі даних. Сукупністю даних можуть користуватися кілька відомств незалежно від того, чи є при цьому між ними відомчі бар'єри. [12].
8.7. Налаштовувана середовище розробника
Після запуску Delphi у верхньому вікні горизонтально розташовуються іконки палітри компонент. Якщо курсор затримується на одній з ікон, під нею в жовтому прямокутнику з'являється підказкаЗ цієї палітри компонент можна вибирати компоненти, з яких можна будувати програми. Компоненти включають в себе як візуальні, так і логічні компоненти. Такі речі, як кнопки, поля редагування - це візуальні компоненти; а таблиці, звіти - це логічні.
Оскільки в Delphi програма будується візуальним образом, всі ці компоненти мають своє графічне представлення в полі форм для того, щоб можна було б ними відповідним чином оперувати. Але для працюючої програми видимими залишаються тільки візуальні компоненти. Компоненти згруповані на сторінках палітри за своїми функціями. Приміром, компоненти, які мають Windows "common dialogs" всі розміщені на сторінці палітри з назвою "Dialogs".
У Delphi можна визначити свою групу компонент і розмістити її на сторінці палітри, а якщо виникне необхідність, перегрупувати компоненти або видалити невикористовувані.
· Інтелектуальний редактор. Редагування програм можна здійснювати, використовуючи запис і виконання макросів, роботу з текстовими блоками, що настроюються комбінації клавіш і колірне виділення рядків.
· Графічний відладчик. Delphi має найпотужнішим, вбудованим в редактор графічним відладчиком, що дозволяє знаходити і усувати помилки в коді. Можна встановити точки зупину, перевірити та змінити змінні, за допомогою покрокового виконання в точності зрозуміти поведінку програми. Якщо ж потрібні можливості більш тонкої налагодження, можна використовувати окремо доступний Turbo Debugger, перевіривши асемблерні інструкції та регістри процесора.
· Інспектор об'єктів. Цей інструмент являє собою окреме вікно, де ви можете в період проектування програми встановлювати значення властивостей і подій об'єктів (Properties & Events).
· Менеджер проектів. Дає можливість розробнику проглянути всі модулі у відповідному проекті і постачає зручним механізмом для управління проектами. Менеджер проектів показує імена файлів, час / дату вибраних форм та ін Можна негайно попась в текст або форму, просто клацнувши мишкою на відповідне ім'я.
· Навігатор об'єктів. Показує бібліотеку доступних об'єктів і здійснює навігацію по додатком. Можна подивитися ієрархію об'єктів, прекомпільованних модулі в бібліотеці, список глобальних імен вашого коду.
· Дизайнер меню. Можна створювати меню, зберегти створені у вигляді шаблонів і потім використовувати в їх в будь-якому додатку.
· Експерти. Це набір інструментальних програм, що полегшують проектування і налаштування Ваших додатків. Є можливість підключати самостійно розроблені експерти. Потенційно це та можливість, за допомогою якої треті фірми можуть розширювати Delphi CASE-інструментами, розробленими спеціально для Delphi. Включає в себе:
Експерт форм, що працюють з базами даних
Експерт стилів і шаблонів додатків
Експерт шаблонів форм
До складу RAD Pack входить експерт для перетворення ресурсів, виготовлених в Borland Pascal 7.0, до форм Delphi. Вже з'явилися експерти, що полегшують побудову DLL і навіть написання власних експертів
· Інтерактивна навчальна система. Дозволяє більш повно освоїти Delphi. Вона є не просто системою підказок, а показує можливості Delphi на самому середовищі розробника.
8.8. Незначні вимоги до апаратних і програмних засобів
Delphi це високопродуктивний інструмент створення додатків. Для запуску Delphi потрібно як мінімум 386 комп'ютер з 4MB пам'яті. Більш відповідною машиною буде 486DX 66MHz з 8MB ОЗУ.Невеликі програми, створені на Delphi будуть працювати на будь-якому комп'ютері. Іншими словами, вони не вимагають того ОЗУ або швидкості процесора, що необхідно для середовища Delphi. [4].
9. Проектування бази даних
Проектування БД пов'язано з вирішенням проблем представлення даних між кінцевими користувачами. Вони продиктовані різними потребами і завданнями осіб, які використовують ці дані. Користувачі можуть бути виділені в окремі групи. Кожна з груп впливає на результати проектування в різних напрямках. Необхідно зібрати інформацію про реальних і потенційних додатках, а також про користувачів бази даних, щоб усунути всі суперечності ще на початковому етапі, так як багаторічний світовий досвід використання інформаційних систем, побудованих на основі баз даних, показує, що недоліки проекту допущені на етапі проектування неможливо усунути будь-якими хитрощами в програмах додатків.Проектування зазвичай доручається людині (групі осіб) - адміністратора бази даних (АБД). Ним може бути як спеціально виділений співробітник, так і майбутній користувач бази даних, досить добре знайомий з машинною обробкою даних.
В основу проектування БД повинні бути покладені уявлення кінцевих користувачів конкретної організації - концептуальні вимоги до системи. Саме кінцевий користувач у своїй роботі приймає рішення з урахуванням одержуваної в результаті доступу до бази даних інформації. Від оперативності і якості цієї інформації буде залежати ефективність роботи організації. Дані, що поміщаються в базу даних, також надає кінцевий користувач. Крім того, БД повинна надавати доступ до даних користувачам, які практично не мають або не хочуть мати уявлення про фізичний розміщенні в пам'яті даних і їхніх описів, про механізми пошуку потрібних даних або про підтримку баз даних в актуальному стані. [15].
Прикладні програмісти хотіли б мати в одному місці (наприклад, в одній таблиці) всі дані, необхідні їм для реалізації запиту з прикладної програми або з терміналу.
АБД ж піклуються про виключення можливих спотворень даних, що зберігаються при введенні в базу даних нової інформації та оновлення або видалення існуючої. Для цього вони видаляють з бази даних дублікати і небажані функціональні зв'язки між таблицями, розбиваючи базу даних на безліч маленьких таблиць.
Щоб розрізняти представлення даних кінцевими користувачами, програмістами і АБД створюються різні рівні моделей даних. Їх загальна структура представлена на рис. 14.
Основна відмінність між зазначеними вище трьома типами моделей даних (концептуальної, логічної і фізичної) полягає у засобах представлення взаємозв'язків між об'єктами. При проектуванні БД потрібно розрізняти взаємозв'язку між об'єктами, між властивостями одного об'єкта і між властивостями різних об'єктів. Розглянемо кожну з них більш докладно.
9.1. Рис. 14. Рівні моделей даних.
Инфологическая модель даних
Предметна область - частина реального світу відображена в базу даних. Рис. 14. Рівні моделей даних. |
Об'єднуючи приватні уявлення про вміст бази даних, отримані в результаті опитування користувачів, і свої уявлення про дані, які можуть знадобитися в майбутніх додатках, АБД спочатку створює узагальнене неформальний опис створюваної бази даних. Цей опис, виконане з використанням природної мови, математичних формул, таблиць, графіків і інших засобів, зрозумілих всім людям, що працюють над проектуванням бази даних, називають инфологической моделлю данна х.
Мета інфологічне моделювання - забезпечення найбільш природних для людини способів збору та подання тієї інформації, яку передбачається зберігати в створюваній базі даних. Тому інфологічну модель даних намагаються будувати за аналогією з природною мовою. Основними конструктивними елементами инфологической моделей є сутності, зв'язки між ними і їх властивості (атрибути).
Сутність - будь-який реальний чи не реальний помітний об'єкт (об'єкт, який ми можемо відрізнити від іншого), інформацію про який необхідно зберігати в базі даних. Сутності можуть бути люди, місця, літаки, рейси, смак, колір і т.д. Необхідно розрізняти такі поняття, як тип сутності й екземпляр сутності. Поняття тип сутності відноситься до набору однорідних особистостей, предметів, подій чи ідей, які виступають як ціле. Примірник сутності відноситься до конкретної речі в наборі. Наприклад, типом сутності може бути МІСТО, а екземпляром - Москва, Київ і т.д.
Атрибут - пойменована характеристика сутності. Атрибутом суті є будь-яка деталь, яка служить для уточнення, ідентифікації, класифікації, числової характеристики або вираження стану сутності. Його найменування повинне бути унікальним для конкретного типу сутності, але може бути однаковим для різного типу сутностей (наприклад, КОЛІР може бути визначений для багатьох сутностей: СОБАКА, АВТОМОБІЛЬ, ДИМ і т.д.). Атрибути використовуються для визначення того, яка інформація повинна бути зібрана про сутність. Прикладами атрибутів для сутності АВТОМОБІЛЬ є ТИП, МАРКА, номерний знак, колір і т.д. Тут також існує розходження між типом і екземпляром. Тип атрибута КОЛІР має багато екземплярів чи значень: Червоний, Синій, Банановий, Біла ніч і т.д., однак кожному екземпляру сутності привласнюється тільки одне значення атрибута.
Абсолютна відмінність між типами сутностей і атрибутами відсутня. Атрибут є таким тільки в зв'язку з типом сутності. В іншому контексті атрибут може виступати як самостійна сутність. Наприклад, для автомобільного заводу колір - це тільки атрибут продукту виробництва, а для лакофарбової фабрики колір - тип сутності.
Зв'язок - асоціювання двох або більше сутностей. Ця асоціація завжди є бінарною і може існувати між двома різними сутностями або між сутністю і їй же самій (рекурсивна зв'язок). У будь-якому зв'язку виділяються два кінці (відповідно до існуючої парою пов'язують сутностей), на кожному з яких вказується ім'я кінця зв'язку, ступінь кінця зв'язку (скільки екземплярів даної суті пов'язується), обов'язковість зв'язку (тобто чи будь-який примірник даної суті повинен брати участь в зв'язку з цим).
Якби призначенням бази даних було тільки збереження окремих, не пов'язаних між собою даних, то її структура могла б бути дуже простий. Однак одна з основних вимог до організації бази даних - це забезпечення можливості відшукання одних сутностей за значеннями інших, для чого необхідно встановити між ними певні зв'язки. А так як у реальних базах даних нерідко містяться сотні чи навіть тисячі сутностей, то теоретично між ними може бути встановлено більше мільйона зв'язків. Наявність такої безлічі зв'язків і визначає складність инфологической моделей.
При визначенні инфологической моделі необхідно брати до уваги наступне:
· База даних повинна задовольняти актуальним інформаційним потребам організації. Отримана інформація повинна за структурою і змістом відповідати важливість справ.
· База даних повинна забезпечувати одержання необхідних даних за прийнятний час, тобто відповідати заданим вимогам продуктивності.
· База даних повинна задовольняти виявленим і знову виникаючим вимогам всіх користувачів.
· База даних повинна легко розширюватися при реорганізації і розширенні предметної області.
· База даних повинна легко змінюватися при зміні програмної та апаратної середовища.
9.2. Инфологическая модель даних "сутність-зв'язок"
Инфологическая модель відображає реальний світ у деякі зрозумілі людині концепції, цілком незалежні від параметрів середовища зберігання даних. Існує безліч підходів до побудови таких моделей: графові моделі, семантичні мережі, модель "сутність-зв'язок" і т.д. Найбільш популярною з них виявилася модель "сутність-зв'язок" або звана ще ER-моделлю (від англ. Entity-Relationship, тобто сутність-зв'язок).На використанні різновидів ER-моделі засновано більшість сучасних підходів до проектування баз даних (головним чином, реляційних). Модель була запропонована Ченом (Chen) в 1976 р. Моделювання предметної області базується на використанні графічних діаграм, що включають невелике число різнорідних компонентів. У зв'язку з наочністю подання концептуальних схем баз даних ER-моделі отримали широке поширення в системах CASE, що підтримують автоматизоване проектування реляційних баз даних.
У них сутності зображуються позначеними прямокутниками, асоціації (зв'язку) - позначеними ромбами чи шестикутниками, атрибути - позначеними овалами, а зв'язки між ними - ненаправленими ребрами, над якими може проставлятися ступінь зв'язку (1 чи буква, що заміняє слово "багато") і необхідне пояснення .
Між двома сутностей, наприклад, А і В можливі чотири види зв'язків.
Перший тип - зв'язок один-до-одного (1:1): у кожен момент часу кожному представнику (екземпляру) сутності А відповідає 1 чи 0 представників сутності В:
Студент може не "заробити" стипендію, одержати звичайну чи одну з підвищених стипендій. Або, припустимо, в певний момент часу один клієнт може зробити тільки одне замовлення. У цьому випадку між об'єктами КЛІЄНТ і ЗАМОВЛЕННЯ встановлюється взаємозв'язок "один до одного", що позначається одинарними стрілками.
Між даними, що зберігаються в об'єктах КЛІЄНТ і ЗАМОВЛЕННЯ, буде існувати взаємозв'язок, в якій кожен запис в одному об'єкті буде однозначно вказувати на запис в іншому об'єкті. Ні в одному, ні в іншому об'єкті не може існувати запису, не пов'язаної з будь-якої записом в іншому об'єкті.
Другий тип - зв'язок один-до-БАГАТЬОМ (1: М): одному представнику сутності А відповідають 0, 1 або кілька представників сутності В.
Квартира може пустувати, у ній може жити один чи кілька мешканців. Або, наприклад, в певний момент часу один клієнт може стати володарем декількох моделей автомобілів, при цьому кілька клієнтів не можуть бути власниками одного автомобіля. Взаємозв'язок "один до багатьох" можна позначити за допомогою одинарної стрілки в напрямку до "одного" і подвійної стрілки у напрямку до "багатьох". У цьому випадку одного запису даних першого об'єкта (його часто називають батьківським або основним) буде відповідати кілька записів другого об'єкта (дочірнього або підлеглого). Взаємозв'язок "один до багатьох" дуже поширена при розробці реляційних баз даних.
Третій тип - зв'язок БАГАТО-К-ОДНОМУ (М: 1): одному представнику сутності B відповідають 0, 1 або кілька представників сутності А.
У принципі немає ніякої різниці між зв'язком ОДИН-КО-БАГАТЬОМ і БАГАТО-К-ОДНОМУ, тому що між двома сутностями можливі зв'язки в обох напрямках і все залежить від того з якими сутностями пов'язані дані.
Четвертий тип - зв'язок БАГАТО-КО-БАГАТЬОМ (N: М): одному представнику сутності B відповідають 0, 1 або кілька представників сутності А і одночасно одному представнику сутності А відповідають 0, 1 або кілька представників сутності В.
Це також обумовлено тим, що між двома сутностями можливі зв'язки в обох напрямках.
Якщо зв'язок між сутностями ЧОЛОВІКА і ЖІНКИ називається ШЛЮБ, то існує чотири можливих подання такого зв'язку:
Або наприклад кожен продавець може обслуговувати кількох клієнтів. З іншого боку, купуючи автомобілі в різний час, кожен клієнт цілком може бути обслужений різними продавцями. Між об'єктами КЛІЄНТ і ПРОДАВЕЦЬ існує взаємозв'язок "багато до багатьох". Такий взаємозв'язок позначається подвійними стрілками.
Характер зв'язків між сутностями не обмежується перерахованими. Існують і більш складні зв'язки:
· Безліч зв'язків між одними і тими ж сутностями
(Пацієнт, маючи одного лікуючого лікаря, може мати також кілька лікарів-консультантів; лікар може бути лікуючим лікарем декількох пацієнтів і може одночасно консультувати кілька інших пацієнтів);
· Тренарние зв'язку:
· Зв'язку більш високих порядків, семантика (зміст) яких іноді дуже складна.
У наведених прикладах зв'язків не показані атрибути сутностей і асоціацій у всіх ER-діаграмах. Так, введення лише кількох основних атрибутів в опис шлюбних зв'язків значно ускладнить ER-діаграму (мал. 2.1, а). У зв'язку з цим мова ER-діаграм використовується для побудові невеликих моделей і ілюстрації окремих фрагментів великих. Частіше ж застосовується менш наочний, але більш змістовний мова інфологічне моделювання (ЯІМ), в якому сутності й асоціації представляються пропозиціями виду:
СУТНІСТЬ (атрибут 1, атрибут 2, ..., атрибут n)
АСОЦІАЦІЯ [СУТНІСТЬ S1, СУТНІСТЬ S2, ...]
(Атрибут 1, атрибут 2, ..., атрибут n)
де S - ступінь зв'язку, а атрибути, що входять у ключ, повинні бути відзначені за допомогою підкреслення.
Так, розглянутий вище приклад безлічі зв'язків між сутностями, може бути описаний на ЯІМ наступним чином:
Лікар (Номер_врача, Прізвище, Ім'я, По батькові, Спеціальність)
Пацієнт (Регістраціонний_номер, Номер ліжка, Прізвище,
Ім'я, По батькові, Адреса, Дата народження, Пол)
Лечащій_врач [Лікар 1, Пацієнт M]
(Номер_врача, Регістраціонний_номер)
Консультант [Лікар M, Пацієнт N]
(Номер_врача, Регістраціонний_номер).
Для прикладу ER-діаграма бази даних "Харчування" показана на рис.16, а модель мовою ЯІМ має наступний вигляд:
Страви (БЛ, Страва, Вигляд)
Продукти (ПР, Продукт, Калорійність)
Постачальники (ПОС, Місто, Постачальник) [Місто]
Склад [Страви M, Продукти N] (БЛ, ПР, Вага (г))
Постачання [Постачальники M, Продукти N] (ПОС, ПР, Дата_П, Ціна, Вага (кг))
Міста (Місто, Країна)
Рецепти (БЛ, Рецепт) {Страви}
Витрата (БЛ, Дата_Р, Порцій) {Страви}
Рис. 15. ER-діаграма бази даних 'Харчування'. |
У цих моделях Страва, продукт та Постачальник - найменування, а БЛ, ПР і ПОС - цифрові коди страв, продуктів і організацій, що постачають ці продукти.
Рис. 16. Діаграма "Таблиці-зв'язку" |
Існує ще найбільш поширена модифікація ER-діаграм для подання инфологической моделі баз даних - "Таблиця-зв'язок", приклад використання якого наведено на рис. 16. У ньому всі сутності зображуються одностолбцовимі таблицями із заголовками, що складаються з імені та типу сутності. Рядки таблиці - це перелік атрибутів сутності, а ті з них, які складають первинний ключ, розташовуються поруч і обводяться рамкою. Зв'язки між сутностями вказуються стрілками, спрямованими від первинних ключів або їх складових. Саме цей тип діаграм буде використовуватися при побудові инфологической моделі бази даних, яка розробляється в даній дипломній роботі.
9.3. Даталогіческая модель даних
Опис, створюване за инфологической моделі даних, називають даталогіческой моделлю даних. Даталогіческая модель відображає логічні зв'язки між елементами даних незалежно від їх змісту і середовища зберігання. Користувачам виділяються підмножини цієї логічної моделі, які називаються зовнішніми моделями, що відображають їхнє представлення про предметної області. Зовнішня модель відповідає уявленням, які користувачі отримують на основі логічної моделі, в той час як концептуальні вимоги відбивають уявлення, які користувачі спочатку бажали мати і які лягли в основу розробки инфологической моделі. Даталогіческая модель відображається у фізичну пам'ять, таку, як диск, стрічка або який-небудь інший носій інформації. Даталогіческая модель в основному використовується прикладними програмістами для реалізації вимог, які висунули кінцеві користувачі, відображених у инфологической концептуальної моделі.Типи даталогіческіх моделей вже обговорювалися нами раніше. Це є не що інше, як Моделі представлення даних, таким чином даталогіческая модель даних може бути реляційної, ієрархічної або мережевий.
При розробці даталогіческой моделі, крім вимог що пред'являються для побудови инфологической моделі, пред'являються додаткові вимоги:
· Завантажені в базу даних коректні дані повинні залишатися коректними.
· Дані до включення в базу даних повинні перевірятися на достовірність.
· Доступ до даних, розміщених у базі даних, повинні мати тільки особи з відповідними повноваженнями.
· Вирішення проблем, що виникають при одночасному запиті одних і тих же даних багатьма користувачами (прикладними програмами);
· Способи забезпечення захисту даних від некоректних відновлень і (або) несанкціонованого доступу;
Якщо инфологическая модель даних призначена для наочного відображення уявлення користувачів, тобто є людино-орієнтованої, то даталогіческая модель вже є компьютеро-орієнтованою. З її допомогою СУБД дає можливість програмам і користувачам здійснювати доступ до збережених даними лише за їхніми іменами, не піклуючись про фізичне розташування цих даних.
9.4. Перехід від ER - моделі до реляційної.
Перехід від инфологической моделі "сутність-зв'язок" - це порівняно проста задача, оскільки в термінології та принципи ER-моделі та реляційного підходу є взаємно однозначна відповідність. Існує ряд добре зарекомендували себе правил з пощью яких з ER-діаграм отроются реляційні таблиці.1. Кожна проста сутність перетворюється в таблицю. Проста сутність - сутність, яка не є підтипом і не має підтипів. Ім'я суті стає ім'ям таблиці.
2. Кожен атрибут стає можливим стовпцем з тим же ім'ям, може вибиратися більш точний формат. Стовпці, відповідні необов'язковим атрибутам, можуть містити невизначені значення; стовпці, що відповідають обов'язковим атрибутам, - не можуть.
3. Компоненти унікального ідентифікатора суті перетворюються на первинний ключ таблиці. Якщо є кілька можливих унікальних ідентифікаторів, вибирається найбільш використовуваний. Якщо до складу унікального ідентифікатора входять зв'язку, до числа стовпців первинного ключа додається копія унікального ідентифікатора суті, що знаходиться на далекому кінці зв'язку (цей процес може тривати рекурсивно). Для іменування цих стовпців використовуються імена решт зв'язків та / або імена сутностей.
4. Зв'язки багато-до-одного (і один-до-одного) стають зовнішніми ключами. Тобто робиться копія унікального ідентифікатора з кінця зв'язку "один", і відповідні стовпці складають зовнішній ключ. Необов'язкові зв'язку відповідають стовпцям, допускає невизначені значення; обов'язкові зв'язку - стовпцях, що не допускає невизначені значення.
5. Індекси створюються для первинного ключа (унікальний індекс), зовнішніх ключів і тих атрибутів, на яких передбачається в основному базувати запити.
6. Якщо у концептуальній схемі були присутні підтипи, то можливі два способи: всі підтипи в одній таблиці (а) або для кожного підтипу - окрема таблиця (б). При застосуванні способу (а) таблиця створюється для найбільш зовнішнього супертіпа, а для підтипів можуть створюватися подання. У таблицю додається, принаймні, один стовпець, що містить код ТИПУ, він стає частиною первинного ключа. При використанні методу (б) для кожного підтипу першого рівня (для більш нижніх - подання) супертіп відтворюється за допомогою представлення UNION (з усіх таблиць підтипів вибираються загальні стовпці - стовпці супертіпа).
7. Є два способи роботи при наявності виключають зв'язків: загальний стовпець і явні зовнішні ключі (б). Якщо залишаються зовнішні ключі все в одному домені, тобто мають загальний формат (спосіб (а)), то створюються два стовпці: ідентифікатор зв'язку та ідентифікатор сутності. Стовпець ідентифікатора зв'язку використовується для розрізнення зв'язків, що покриваються дугою винятку. Стовпець ідентифікатора суті використовується для зберігання значень унікального ідентифікатора суті на дальньому кінці відповідної зв'язку. Якщо результуючі зовнішні ключі не належать до одного домену, то для кожного зв'язку, покривається дугою винятку, створюються явні стовпці зовнішніх ключів; всі ці стовпці можуть містити невизначені значення.
9.5. Фізична модель даних
Фізична модель даних - модель, що визначає розміщення даних на зовнішніх носіях, методи доступу й техніку індексування. Вона так само називається внутрішньої моделлю системи.Зовнішні моделі (даталогіческіе моделі) ніяк не пов'язані з типом фізичної пам'яті, в якій будуть зберігатися дані, і з методами доступу до цих даних. Внутрішні моделі (фізичні моделі) навпаки визначають і оперують розміщенням даних та їх взаємозв'язках на запам'ятовуючих пристроях.
Фізична організація даних робить основний вплив на експлуатаційні характеристики БД. Розробники СУБД намагаються створити найбільш продуктивні фізичні моделі даних, пропонуючи користувачам той чи інший інструментарій для поднастройкі моделі під конкретну БД. Існує велика різноманітність способів реалізації та коригування фізичних моделей сучасних промислових БД, що не дозволяє розглянути їх детально.
Фізична модель даних є повністю комп'ютерно-орієнтованої і кінцеві користувачі, а часом і прикладні програмісти, не мають жодного уявлення про те, яким чином дані запам'ятовуються і витягуються або яким способом організуються індекси в таблицях для швидкого пошуку або посилальна цілісність. Ці та безліч інших функцій за методами доступу і підтримці баз даних на зовнішніх носіях, а також способів пошуку і доступу до даних в сучасних СУБД забезпечується в основному ядром бази даних, що значно полегшує завдання створення БД і їх ведення.
Трирівнева архітектура (інфологічне, даталогіческій і фізичний рівні) дозволяє забезпечити незалежність збережених даних від використовують їх програм. АБД може при необхідності переписати збережені дані на інші носії інформації та (або) реорганізувати їхню фізичну структуру, змінивши лише фізичну модель даних. АБД може підключити до системи будь-яке число нових користувачів (нових додатків), доповнивши, якщо треба, даталогіческую модель. Зазначені зміни фізичної та даталогіческой моделей не будуть помічені існуючими користувачами системи (виявляться "прозорими" для них), так само як не будуть помічені і нові користувачі. Отже, незалежність даних забезпечує можливість розвитку системи баз даних без руйнування існуючих додатків.
9.6. Етапи проектування бази даних
Етапи проектування бази даних з урахуванням розглянутих вище аспектів:1. Проектування инфологической концептуальної моделі баз даних:
а) Дослідження предметної області застосування та виявлення вимог кінцевих користувачів і розв'язуваних завдань.
в) Аналіз даних: збір основних даних (об'єкти, зв'язки між об'єктами).
з) Побудова ER-діаграми бази даних.
2. Проектування даталогіческой моделі бази даних (враховувати вимоги СУБД).
a) Потенційно можливі прикладні програми: збір інформації про потенційні можливості використання даних.
3. Проектування фізичної моделі бази даних (оцінка експлуатаційних характеристик прикладних програм).
4. Реалізація бази даних (оцінка при незадовільних експлуатаційних характеристиках).
10. Практична частина
10.1. Предметна область і завдання, покладені на базу даних
Для демонстрації практичного прикладу організації бази даних за допомогою описаних в дипломній роботі засобів, спроектуємо базу даних для зберігання інформації про якісні характеристики і кількості зерна пшениці. Об'єкт - зернопереробне підприємство борошномельної промисловості. Технологія приймання зерна наступна: клієнти привозять на підприємство зерно, працівники виробничої лабораторії беруть проби зерна з кожної машини і проводять лабораторні аналізи, в результаті яких визначаються такі характеристики зерна - вологість, зернова домішка, смітна домішка, прохід (сито), клейковина, натура, скловидність. Все це якісні характеристики, від яких залежить кількість борошна, яке забере клієнт в обмін на зерно. Наша мета - спроектувати базу даних, в якій буде зберігатися інформація про зерно, прийнятому від клієнтів. Мається на увазі, що інформація накопичується постійно з кожним днем, вона може змінюватися; дана база даних є частиною великого комплексу автоматизованої системи управління підприємством (АСУП).База даних безсумнівно носить характер фактографічної інформаційної системи і повинна видавати однозначні відомості на поставлені запити. Кінцевими користувачами бази даних є працівники виробничої лабораторії, зернопереробного цеху, бухгалтерії (відділ збуту готової продукції), які відносяться до категорії користувачів не досвідчених у питаннях ведення, адміністрування баз даних і підтримці їх в актуальному стані. Це накладає певні вимоги на розробку системи управління базою даних, при якій всі методи доступу, пошуку і більшість функцій адміністрування приховані усередині програми і прозорі при роботі що, безсумнівно, позначиться на розробці програмного інтерфейсу. Більш докладно всі вимоги перераховані нижче:
1. Надання загальної інформації про кількість прийнятого зерна та його якісні характеристики. Це сукупність відомостей про кількість зерна, привезеному кожним клієнтом, включає в себе загальну інформацію таку як назва фірми клієнта або прізвище (якщо це фізична особа), дата приймання зерна, номер автомашини , клас пшениці, маса брутто (з автомашиною), маса тари (автомашини), маса нетто (чисто зерно), номер складу (куди надійшло зерно). Мається на увазі, що інформація буде змінюватися і поповняться постійно.
2. Ведення довідника клієнтів. Клієнти бувають постійні і одноразові, але, незважаючи на це, інформація про них залишається в базі даних. Довідник постійно поповнюється, редагується. Як правило, видаленням інформації про клієнтів і поповненням довідника займається одна людина.
3. Ведення довідника сільськогосподарських культур. По кожній культурі по кожному класу необхідно вести дані про базисних якісних характеристиках, на основі яких надалі буде визначатися відхилення фактичних характеристик від базисних. Як правило, видаленням інформації про культури та поповненням довідника займається теж одна людина. Потрібно враховувати і той факт, що в майбутньому підприємство може працювати не тільки з пшеницею, а й з іншими культурами, наприклад, з Кукурудз.
4. Розподіл клієнтів. З цим завданням стикаються в процесі формування квитанцій на видачу борошна. Йде розподіл по платниках і неплатникам ПДВ, за юридичним і фізичним особам.
5. Надання інформації про конкретний клієнта. Всі інформація про надходження зерна ведеться в розрізі кожного клієнта і може бути видана на вимогу самого клієнта або, наприклад, працівникам податкової інспекції.
6. Одержання статистичної інформації про якість і кількість зерна. За результатами роботи за період (як правило, рік) формуються статистичні звіти для статистичного управління про середні якісних показниках зерна.
1. Клієнти (Код клієнта, Назва клієнта, Тип клієнта, Банківські реквізити, Юридична адреса, Телефон)
Ця сутність відводиться для зберігання основних відомостей про клієнтів. Реквізит "Тип клієнта" введений для вказівки юридичної або фізичної особи, а також - платник або неплатник він ПДВ. Реквізит "Код клієнта" введений для однозначної ідентифікації клієнта в рамках підприємства.
2. Культури (Код культури, Назва культури, Клас, Базисна вологість, Базисна зернова домішка, Базисна смітна домішка, Базисна скловидність, Базисна натура, Базисна клейковина)
3. Вид надходження (Код виду надходження, Назва виду надходження).
Дана сутність являє собою вид надходження зерна на підприємство. Зерно можуть привозити клієнти для переробки на борошно (давальницька зерно), а також підприємство може купувати зерно для власних потреб (власне зерно). Крім цього, підприємство може брати участь у державній програмі з заготівлі зерна (зерно держрезервів).
4. Накладні (Номер_накладной, Дата накладної, Код клієнта, Номер_автомашіни, Код культури, Код виду надходження, Маса брутто, Маса тари, Маса нетто, Номер складу, Номер лабораторного аналізу).
Сутність відображає надходження зерна на підприємство з накладних клієнтів.
Рис. 17. Инфологическая модель бази даних.
Зірочками на инфологической моделі показані ключові атрибути.
Як даталогіческой моделі бази даних була обрана реляційна модель, оскільки саме реляційна модель є результатом більш розвинених уявлень про формування і ведення баз даних, на які накладено строгий математичний апарат. Реляційні моделі найбільш логічно і наочно відображають структуру зберігається, та внутрішніх зв'язків, що дозволяє більш повно аналізувати структуру бази даних при розробці. Це призвело до того, що саме реляційні моделі баз даних найбільш поширені в даний час і є стандартом, на який переводяться всі існуючі раніше бази даних з ієрархічної і мережевою моделлю. Ще одним вагомим доказом на користь вибору реляційної моделі є той факт, що переважна більшість коштів, що надаються для розробки баз даних орієнтовані виключно на реляційну модель. Крім того, реляційні бази даних надалі легше розширювати та інтегрувати, що є невід'ємною частиною подальшого розвитку баз даних, зі збільшенням покладених на них завдань.
Инфологическая модель бази даних легко відображається в реляційну даталогіческую модель, використовуючи описані раніше правила з перекладу. У результаті виходить сім таблиць реляційної бази даних, де кожна сутність безпосередньо відбивається в окрему таблицю, атрибути кожної суті стають полями цієї таблиці, а первинні ключі суті стають первинними ключами таблиці. На даному етапі необхідно також провести нормалізацію отриманих таблиць з метою усунення надмірності даних. Ця процедура в подальшому значно полегшить зусилля, які витрачатимуться на підтримці таблиць бази даних у цілісному стані.
Правила нормалізації, описані раніше, наказують для таких випадків заводити окрему таблицю для кожного поля і зберігати в ній всі значення характерні тільки для одного поля. Я ж прийняв рішення звести значення для всіх полів в одну таблицю і розрізняти їх не тільки за унікальним номером-ідентифікатором, а й вказувати таблицю, до якої це поле належить, а також назва самого поля. Вибір такого варіанту виправданий тим, що таких полів в таблицях бази даних більше десяти. Організація окремих таблиць для кожного такого поля істотно ускладнить структуру бази даних. Крім того додавання нових атрибутів з подібним обмеженим числом значень зажадає організовувати нову таблицю і витрату великих зусиль по зміні інтерфейсу взаємодії з кінцевим користувачем і виправлення програмного коду, ніж від додавання цих значень в одну універсальну таблицю.
Звичайно, в цьому випадку таблиці бази даних не будуть до кінця нормалізовані, що накладає деякі вимоги на процедури підтримки бази даних в цілісному стані, але дає можливість "безболісних змін" у програмному коді, що може істотно скоротити час розробки в подальшому. Процедури з підтримання цілісності можна реалізувати в програмному коді, зробивши їх таким чином прозорими для кінцевого користувача.
Таким чином, в результаті нормалізації таблиць бази даних і проведеного аналізу складу полів цих таблиць вийшла ще одна таблиця, яка містить значення тих полів, які приймають обмежену кількість значень. Склад полів, первинний ключ (виділено жирним шрифтом з курсивом) і опис полів представлені в таблиці 1.
Такий склад таблиць дозволяє виконувати всі покладені завдання, оскільки він виведений з инфологической моделі, проектованої виходячи з вимог кінцевих користувачів.
Типи даних, що зберігаються в таблицях dBase, дуже різноманітні. Це і символьні значення та різноманітні типи числових значень, що включають цілочисельні, речові, речові з плаваючою комою, числа в двійковому та двійково-десятковому форматі, логічні типи, спеціальні формати для зберігання значень дати, часу і грошових сум, графічні типи для зберігання графічних зображень в самих популярних форматах, а також строкові значення необмеженої довжини (у тому числі і форматовані у форматі rtf) і навіть типи підтримувані технологією OLE (Object Linking and Embedding) фірми Micrоsoft. Така різноманітність типів даних може відповідати навіть самим вишуканим завданням, яким покликана служити створювана база даних і без сумніву підходить для вирішення кола завдань покладеного на базу даних про зерна зернопереробного підприємства.
База даних ZERNO представлена 4-ма таблицями (або за термінологією реляційних баз даних - 4-ма реляційними відносинами): Dorg, Dkul, Dtyp, Fnakl. Розглянемо структуру кожної більш докладно.
У таблиці Dorg представлена інформація про клієнтів. Поля, їх типи, і призначення представлені в таблиці 2.
Первинним ключем таблиці є поле O_Kod, яке однозначно визначає кожний запис у таблиці.
У таблиці D kul представлена інформація про культури. Поля, їх типи, і призначення представлені в таблиці 3.
Первинним ключем є поле K_Kod, однозначно визначає будь-який запис у таблиці.
У таблиці Dtyp представлена інформація про види надходження зерна .. Поля, їх типи, і призначення представлені в таблиці 4.
У таблиці Fnakl представлена інформація про накладні, за якими надходить зерно. Поля, їх типи, і призначення представлені в таблиці 5.
Ключові поля даної таблиці - N_Nomer і N_Date. По полю N_Nana дана таблиця пов'язана з базою даних лабораторії, де міститься інформація про фактичні якісних показниках прийнятого зерна. Структуру таблиць бази даних лабораторії я тут приводити не буду, це окреме завдання. Крім того, на базі даної таблиці (Fnakl) в задачі реалізації готової продукції формуються квитанції і накладні на видачу борошна клієнтам.
В основу створення даної СУБД покладено принцип економії часу і зусиль кінцевого користувача, тобто працівників зернопереробного підприємства, припускаючи, що машина бере на себе всі рутинні функції управління та доступу до збережених даних. Цей принцип простежувався у всіх моментах реалізації даної СУБД, включаючи створення зручного інтерфейсу для роботи кінцевих користувачів з цим програмним продуктом, продуманою структурою реляційних таблиць, обраним форматом баз даних виконують SQL-запити за найбільш короткий час. Навіть функції адміністрування бази даних не вимагають знайомства з теорією реляційної баз даних, СУБД самостійно тестує знаходяться в базі даних запису і виробляє приведення бази даних до цілісного стану. Користувачеві залишається погодитися з усією виконаною роботою (або її частиною) або провести все самостійно. За збереження введених даних можна не турбуватися, оскільки ніяка інформація, внесена в базу даних не може бути вилучена без підтвердження користувача.
Короткий опис програмного проекту
Проект Azagot, який реалізує доступ до БД Zerno виконаний у вигляді бібліотеки DLL. Складається з двох форм MainForm (головна форма) і NaklForm (форма для введення накладних). З бібліотеки Global.DLL в проект імпортуються функції роботи з довідниками клієнтів, культур і видів надходження відповідно ShowDovOrg, ShowDovKul, ShowDovTyp.
Доступ до таблиць БД реалізований з допомогою компоненти DataModule. Тексти програм наведено у додатку до дипломної роботи. Оскільки база даних про зерно тісно пов'язана з завданнями реалізації борошна і лабораторією, в програмному інтерфейсі зарезервовані візуальні компоненти для взаємозв'язку з цими завданнями.
Щоб потрапити у вікно введення накладних, потрібно на головній формі натиснути кнопку з написом "ЗЕРНО". Після цього відкриється вікно, через яке безпосередньо реалізується робота з базою даний "ЗЕРНО".
Для підрахунку загальної кількості зерна за день в програмі використовується компонент TQuery, за допомогою властивості SQL якого процедура підрахунку дуже швидко і ефективно виводить результат.
Процес проектування баз даних детально описаний. Крім цього, автором розроблена база даних для зернопереробного підприємства, в якій зберігається інформація про якість і кількість зерна, що надійшло від клієнтів на переробку. Дана система може бути успішно використана на підприємствах борошномельно промисловості.
Таким чином, автором, на розробленому конкретному прикладі, показано процес оптимальної організації бази даних для нарощування економічної і статистичної інформації. Мета дипломної роботи досягнута.
Матеріали дипломної роботи будуть корисними для студентів, які вивчають теорію економічних інформаційних систем, проектування баз даних, а також програмістам і аналітикам підприємств зернопереробної промисловості, які займаються розробкою інформаційних систем з управління процесами на підприємстві.
2. Дейт К., "Введення в системи баз даних", Москва, 'Hаука', 1980 р.
3. Когловскій М.Р., "Технологія баз даних на персональних ЕОМ", Москва, "Фінанси і статистика", 1992 р.
4. Шумаков П. В. "Delphi 3.0 та створення баз даних". Москва 1997р.
5. Джон Матч, Девід Р. Фолкнер. "Delphi" - пер. з англ. - М.: Біном, 1995р.
6. AMЕпанешніков., "Програмування в середовищі Delphi 2.0"
7. Дж. Мартін., "Організація баз даних в обчислювальних системах" М: Світ 1978р.
8. С. М. Діго "Проектування та використання баз даних". Москва: Фінанси і статистика 1995.
9. Горєв А., Ахаян Р., Макашарипов С. "Ефективна робота із СУБД". СПб.: Пітер, 1997 .- 704 с., Іл.
10. Атре Ш. Структурний підхід до організації баз даних. - М.: Фінанси і статистика, 1983. - 320 с.
11. Бойко В.В., Савінков В.М. Проектування баз даних інформаційних систем. - М.: Фінанси і статистика, 1989. - 351 с.
12. Джексон Г. Проектування реляційних баз даних для використання з мікроЕОМ. -М.: Світ, 2001. - 252 с.
13. Кирилов В.В. Структурізованние мову запитів (SQL). - СПб.: ІТМО, 1994. - 80 с.
14. Мейєр М. Теорія реляційних баз даних. - М.: Світ, 1998. - 608 с.
15. Тіорі Т., Фрай Дж. Проектування структур баз даних. У 2 кн., - М.: Світ, 1999. Кн. 1. - 287 с.: Кн. 2. - 320 с.
16. Цікрітізіс Д., лохівський Ф. Моделі даних. - М.: Фінанси і статистика, 1985. - 344 с.
17. Paradox for Windows: Практичне керівництво. Під редакцією Оспіщева Д. А. Видавництво АОЗ '"Алевар", 1993.
18. Брябрін В.М., "Програмне забезпечення персональних ЕОМ", Москва, 'Hаука', 1989 р.
19. Шафрін Ю.А. "Основи комп'ютерної технології". М., 1998
20. "Кібернетичні діалогові системи", І. П. Кузнєцов.
21. "Рекомендації з общепользовательскому інтерфейсу", Microsoft, редакція 2000р.
22. Тейксейра С., Пачеко К. Delphi 5. Керівництво разоработчіка.Москва-Санкт-Петербург-Київ, 2000р.
База даних може розроблятися для пакетної обробки даних, обробки в реальному часі або оперативної обробки (в цьому випадку обробка кожного запиту завершується до певного моменту часу, але при цьому на час обробки не накладається жорстких обмежень, що існують в системах реального часу). У багатьох базах даних передбачена сукупність цих методів обробки, а в багатьох системах з базами даних обслуговування терміналів в реальному часі відбувається одночасно з пакетною обробкою даних. [2]. 5. Надання інформації про конкретний клієнта. Всі інформація про надходження зерна ведеться в розрізі кожного клієнта і може бути видана на вимогу самого клієнта або, наприклад, працівникам податкової інспекції.
6. Одержання статистичної інформації про якість і кількість зерна. За результатами роботи за період (як правило, рік) формуються статистичні звіти для статистичного управління про середні якісних показниках зерна.
10.2. Визначення об'єктів бази даних
Аналіз визначених вище завдань дозволяє виділити сутності (об'єкти) проектованої бази даних і, побудувати її інфологічну модель на мові "Таблиці-зв'язку". У результаті аналізу було визначено наступні об'єкти бази даних:1. Клієнти (Код клієнта, Назва клієнта, Тип клієнта, Банківські реквізити, Юридична адреса, Телефон)
Ця сутність відводиться для зберігання основних відомостей про клієнтів. Реквізит "Тип клієнта" введений для вказівки юридичної або фізичної особи, а також - платник або неплатник він ПДВ. Реквізит "Код клієнта" введений для однозначної ідентифікації клієнта в рамках підприємства.
2. Культури (Код культури, Назва культури, Клас, Базисна вологість, Базисна зернова домішка, Базисна смітна домішка, Базисна скловидність, Базисна натура, Базисна клейковина)
3. Вид надходження (Код виду надходження, Назва виду надходження).
Дана сутність являє собою вид надходження зерна на підприємство. Зерно можуть привозити клієнти для переробки на борошно (давальницька зерно), а також підприємство може купувати зерно для власних потреб (власне зерно). Крім цього, підприємство може брати участь у державній програмі з заготівлі зерна (зерно держрезервів).
4. Накладні (Номер_накладной, Дата накладної, Код клієнта, Номер_автомашіни, Код культури, Код виду надходження, Маса брутто, Маса тари, Маса нетто, Номер складу, Номер лабораторного аналізу).
Сутність відображає надходження зерна на підприємство з накладних клієнтів.
10.3. Инфологическая і даталогіческая моделі бази даних
Инфологическая модель бази даних зображена на рис.17. * Номер накдладной * Дата накладної, Код клієнта, Номер_автомашіни, Код культури, Код виду надходження, Маса брутто, Маса тари, Маса нетто, Номер складу, Номер лабораторного аналізу |
НАКЛАДНІ |
КЛІЄНТИ |
* Код культури, Назва культури, Клас культури, Базисна вологість, Базисна зернова домішка, Базисна смітна домішка, Базисна скловидність, Базисна натура, Базисна клейковина |
КУЛЬТУРИ |
* Код виду надходження Назва виду надходження |
НАДХОДЖЕННЯ |
Рис. 17. Инфологическая модель бази даних.
Зірочками на инфологической моделі показані ключові атрибути.
Як даталогіческой моделі бази даних була обрана реляційна модель, оскільки саме реляційна модель є результатом більш розвинених уявлень про формування і ведення баз даних, на які накладено строгий математичний апарат. Реляційні моделі найбільш логічно і наочно відображають структуру зберігається, та внутрішніх зв'язків, що дозволяє більш повно аналізувати структуру бази даних при розробці. Це призвело до того, що саме реляційні моделі баз даних найбільш поширені в даний час і є стандартом, на який переводяться всі існуючі раніше бази даних з ієрархічної і мережевою моделлю. Ще одним вагомим доказом на користь вибору реляційної моделі є той факт, що переважна більшість коштів, що надаються для розробки баз даних орієнтовані виключно на реляційну модель. Крім того, реляційні бази даних надалі легше розширювати та інтегрувати, що є невід'ємною частиною подальшого розвитку баз даних, зі збільшенням покладених на них завдань.
Инфологическая модель бази даних легко відображається в реляційну даталогіческую модель, використовуючи описані раніше правила з перекладу. У результаті виходить сім таблиць реляційної бази даних, де кожна сутність безпосередньо відбивається в окрему таблицю, атрибути кожної суті стають полями цієї таблиці, а первинні ключі суті стають первинними ключами таблиці. На даному етапі необхідно також провести нормалізацію отриманих таблиць з метою усунення надмірності даних. Ця процедура в подальшому значно полегшить зусилля, які витрачатимуться на підтримці таблиць бази даних у цілісному стані.
Правила нормалізації, описані раніше, наказують для таких випадків заводити окрему таблицю для кожного поля і зберігати в ній всі значення характерні тільки для одного поля. Я ж прийняв рішення звести значення для всіх полів в одну таблицю і розрізняти їх не тільки за унікальним номером-ідентифікатором, а й вказувати таблицю, до якої це поле належить, а також назва самого поля. Вибір такого варіанту виправданий тим, що таких полів в таблицях бази даних більше десяти. Організація окремих таблиць для кожного такого поля істотно ускладнить структуру бази даних. Крім того додавання нових атрибутів з подібним обмеженим числом значень зажадає організовувати нову таблицю і витрату великих зусиль по зміні інтерфейсу взаємодії з кінцевим користувачем і виправлення програмного коду, ніж від додавання цих значень в одну універсальну таблицю.
Звичайно, в цьому випадку таблиці бази даних не будуть до кінця нормалізовані, що накладає деякі вимоги на процедури підтримки бази даних в цілісному стані, але дає можливість "безболісних змін" у програмному коді, що може істотно скоротити час розробки в подальшому. Процедури з підтримання цілісності можна реалізувати в програмному коді, зробивши їх таким чином прозорими для кінцевого користувача.
Таблиця 1.
|
Таким чином, в результаті нормалізації таблиць бази даних і проведеного аналізу складу полів цих таблиць вийшла ще одна таблиця, яка містить значення тих полів, які приймають обмежену кількість значень. Склад полів, первинний ключ (виділено жирним шрифтом з курсивом) і опис полів представлені в таблиці 1.
Такий склад таблиць дозволяє виконувати всі покладені завдання, оскільки він виведений з инфологической моделі, проектованої виходячи з вимог кінцевих користувачів.
10.4. Фізичний опис моделі
База даних організована в популярному форматі локальних баз даних dBase. Цей формат для організації реляційних баз даних досить поширений, оскільки має дуже розвинену систему збережених типів даних, можливостями індексування полів, що дозволяє отримувати доступ до даних за мінімальний час, а також функціями щодо забезпечення посилальної цілісності між реляційними таблицями, що дозволяє розробнику мінімізувати тимчасові витрати на створення бази даних, а кінцевому користувачеві витрати на підтримку цілісності даних, що зберігаються та отримання з бази даних самих даних, що зберігаються. Оскільки бази даних dBase - реляційні бази даних, то запити до даних здійснюються за допомогою реляційного мови запитів SQL. Завдяки розвиненій системі визначення ключових полів і індексів при створенні таблиць запити будуть виконуватися з мінімальними тимчасовими витратами. Хоча цей чинник для локальних баз даних не є ключовим, однак, при зростанні обсягу збережених даних саме швидкість виконання запитів ставати вирішальним фактором при виборі формату баз даних.Типи даних, що зберігаються в таблицях dBase, дуже різноманітні. Це і символьні значення та різноманітні типи числових значень, що включають цілочисельні, речові, речові з плаваючою комою, числа в двійковому та двійково-десятковому форматі, логічні типи, спеціальні формати для зберігання значень дати, часу і грошових сум, графічні типи для зберігання графічних зображень в самих популярних форматах, а також строкові значення необмеженої довжини (у тому числі і форматовані у форматі rtf) і навіть типи підтримувані технологією OLE (Object Linking and Embedding) фірми Micrоsoft. Така різноманітність типів даних може відповідати навіть самим вишуканим завданням, яким покликана служити створювана база даних і без сумніву підходить для вирішення кола завдань покладеного на базу даних про зерна зернопереробного підприємства.
База даних ZERNO представлена 4-ма таблицями (або за термінологією реляційних баз даних - 4-ма реляційними відносинами): Dorg, Dkul, Dtyp, Fnakl. Розглянемо структуру кожної більш докладно.
У таблиці Dorg представлена інформація про клієнтів. Поля, їх типи, і призначення представлені в таблиці 2.
Таблиця 2.
|
Первинним ключем таблиці є поле O_Kod, яке однозначно визначає кожний запис у таблиці.
Таблиця 3.
|
У таблиці D kul представлена інформація про культури. Поля, їх типи, і призначення представлені в таблиці 3.
Первинним ключем є поле K_Kod, однозначно визначає будь-який запис у таблиці.
Таблиця 4.
|
У таблиці Dtyp представлена інформація про види надходження зерна .. Поля, їх типи, і призначення представлені в таблиці 4.
Таблиця 5.
|
У таблиці Fnakl представлена інформація про накладні, за якими надходить зерно. Поля, їх типи, і призначення представлені в таблиці 5.
Ключові поля даної таблиці - N_Nomer і N_Date. По полю N_Nana дана таблиця пов'язана з базою даних лабораторії, де міститься інформація про фактичні якісних показниках прийнятого зерна. Структуру таблиць бази даних лабораторії я тут приводити не буду, це окреме завдання. Крім того, на базі даної таблиці (Fnakl) в задачі реалізації готової продукції формуються квитанції і накладні на видачу борошна клієнтам.
10.5. Програмна реалізація
Всі описані таблиці, що становлять основу бази даних, функціонують у рамках створеної системи управління базою даних "Zernot". СУБД "Zernot" створена засобами середовища програмування Delphi 5.0.В основу створення даної СУБД покладено принцип економії часу і зусиль кінцевого користувача, тобто працівників зернопереробного підприємства, припускаючи, що машина бере на себе всі рутинні функції управління та доступу до збережених даних. Цей принцип простежувався у всіх моментах реалізації даної СУБД, включаючи створення зручного інтерфейсу для роботи кінцевих користувачів з цим програмним продуктом, продуманою структурою реляційних таблиць, обраним форматом баз даних виконують SQL-запити за найбільш короткий час. Навіть функції адміністрування бази даних не вимагають знайомства з теорією реляційної баз даних, СУБД самостійно тестує знаходяться в базі даних запису і виробляє приведення бази даних до цілісного стану. Користувачеві залишається погодитися з усією виконаною роботою (або її частиною) або провести все самостійно. За збереження введених даних можна не турбуватися, оскільки ніяка інформація, внесена в базу даних не може бути вилучена без підтвердження користувача.
Короткий опис програмного проекту
Проект Azagot, який реалізує доступ до БД Zerno виконаний у вигляді бібліотеки DLL. Складається з двох форм MainForm (головна форма) і NaklForm (форма для введення накладних). З бібліотеки Global.DLL в проект імпортуються функції роботи з довідниками клієнтів, культур і видів надходження відповідно ShowDovOrg, ShowDovKul, ShowDovTyp.
Доступ до таблиць БД реалізований з допомогою компоненти DataModule. Тексти програм наведено у додатку до дипломної роботи. Оскільки база даних про зерно тісно пов'язана з завданнями реалізації борошна і лабораторією, в програмному інтерфейсі зарезервовані візуальні компоненти для взаємозв'язку з цими завданнями.
Щоб потрапити у вікно введення накладних, потрібно на головній формі натиснути кнопку з написом "ЗЕРНО". Після цього відкриється вікно, через яке безпосередньо реалізується робота з базою даний "ЗЕРНО".
Для підрахунку загальної кількості зерна за день в програмі використовується компонент TQuery, за допомогою властивості SQL якого процедура підрахунку дуже швидко і ефективно виводить результат.
Висновок
У даній дипломній роботі детально розглянуті фундаментальні поняття теорії економічних інформаційних систем, даний огляд новітнім технологіям організації доступу до даних, побудов моделей та систем управління базами даних. На основі загальноприйнятих критеріїв аргументований вибір реляційної моделі бази даних і середовища Borland Delphi 5.0 для практичної реалізації програми для управління роботою бази даних.Процес проектування баз даних детально описаний. Крім цього, автором розроблена база даних для зернопереробного підприємства, в якій зберігається інформація про якість і кількість зерна, що надійшло від клієнтів на переробку. Дана система може бути успішно використана на підприємствах борошномельно промисловості.
Таким чином, автором, на розробленому конкретному прикладі, показано процес оптимальної організації бази даних для нарощування економічної і статистичної інформації. Мета дипломної роботи досягнута.
Матеріали дипломної роботи будуть корисними для студентів, які вивчають теорію економічних інформаційних систем, проектування баз даних, а також програмістам і аналітикам підприємств зернопереробної промисловості, які займаються розробкою інформаційних систем з управління процесами на підприємстві.
Список літератури
1. Дж. Тельман, "Основи систем баз даних", Москва, Фінанси і статистика ", 1983р.2. Дейт К., "Введення в системи баз даних", Москва, 'Hаука', 1980 р.
3. Когловскій М.Р., "Технологія баз даних на персональних ЕОМ", Москва, "Фінанси і статистика", 1992 р.
4. Шумаков П. В. "Delphi 3.0 та створення баз даних". Москва 1997р.
5. Джон Матч, Девід Р. Фолкнер. "Delphi" - пер. з англ. - М.: Біном, 1995р.
6. AMЕпанешніков., "Програмування в середовищі Delphi 2.0"
7. Дж. Мартін., "Організація баз даних в обчислювальних системах" М: Світ 1978р.
8. С. М. Діго "Проектування та використання баз даних". Москва: Фінанси і статистика 1995.
9. Горєв А., Ахаян Р., Макашарипов С. "Ефективна робота із СУБД". СПб.: Пітер, 1997 .- 704 с., Іл.
10. Атре Ш. Структурний підхід до організації баз даних. - М.: Фінанси і статистика, 1983. - 320 с.
11. Бойко В.В., Савінков В.М. Проектування баз даних інформаційних систем. - М.: Фінанси і статистика, 1989. - 351 с.
12. Джексон Г. Проектування реляційних баз даних для використання з мікроЕОМ. -М.: Світ, 2001. - 252 с.
13. Кирилов В.В. Структурізованние мову запитів (SQL). - СПб.: ІТМО, 1994. - 80 с.
14. Мейєр М. Теорія реляційних баз даних. - М.: Світ, 1998. - 608 с.
15. Тіорі Т., Фрай Дж. Проектування структур баз даних. У 2 кн., - М.: Світ, 1999. Кн. 1. - 287 с.: Кн. 2. - 320 с.
16. Цікрітізіс Д., лохівський Ф. Моделі даних. - М.: Фінанси і статистика, 1985. - 344 с.
17. Paradox for Windows: Практичне керівництво. Під редакцією Оспіщева Д. А. Видавництво АОЗ '"Алевар", 1993.
18. Брябрін В.М., "Програмне забезпечення персональних ЕОМ", Москва, 'Hаука', 1989 р.
19. Шафрін Ю.А. "Основи комп'ютерної технології". М., 1998
20. "Кібернетичні діалогові системи", І. П. Кузнєцов.
21. "Рекомендації з общепользовательскому інтерфейсу", Microsoft, редакція 2000р.
22. Тейксейра С., Пачеко К. Delphi 5. Керівництво разоработчіка.Москва-Санкт-Петербург-Київ, 2000р.
Велика частина дискових або стрічкових бібліотек, які існували до використання засобів управління базами даних, містили велику кількість повторюваної інформації. При запам'ятовуванні багатьох елементів даних допускалася надмірність, так як на носії інформації для різних цілей записувалися одні й ті ж дані і, крім того, зберігалися різні варіанти модифікацій одних і тих же даних. База даних надає можливість в значній мірі позбутися такої надмірності. Базу даних іноді визначають як ненадлишковим сукупність елементів даних. Проте насправді для зменшення часу доступу до даних або спрощення способів адресації в багатьох базах даних надмірність в незначній мірі присутній. Деякі записи повторюються для того, щоб забезпечити можливість відновлення даних при їх випадкової втрати. Щоб база даних була ненадлишковим і задовольняла іншим вимогам, доводиться йти на компроміс. У цьому випадку говорять про керованої, або мінімальної, надмірності або про те, що добре розроблена база даних вільна від зайвої надмірності.
Некерована надмірність має кілька недоліків. По-перше, зберігання кількох копій даних призводить до додаткових витрат. По-друге, при оновленні, принаймні, кількох надлишкових копій необхідно виконувати багаторазові операції оновлення. Надмірність тому обходиться значно дорожче в тих випадках, коли при обробці файлів оновлюється велика кількість інформації або, що ще гірше, часто вводяться нові елементи або знищуються старі. По-третє, внаслідок того, що різні копії даних можуть відповідати різним стадіям оновлення, інформація, яка видається системою, може бути суперечливою. [12].
Якщо не використовувати бази даних, то при обробці великої кількості інформації з'явиться так багато надлишкових даних, що фактично стане неможливим зберігати їх все на одному і тому ж рівні оновлення. Дуже часто користувачі виявляють явні протиріччя в даних і тому відчувають недовіру до отриманої від комп'ютера інформації. Неможливість зберігання надлишкових даних на однаковому рівні оновлення є основною перешкодою в обробці даних за допомогою комп'ютера.
Однією з найбільш важливих характеристик більшості баз даних є їх постійна зміна та розширення. У міру додавання нових типів даних або при появі нових додатків повинна бути забезпечена можливість швидкої зміни структури бази даних. Реорганізація бази даних повинна здійснюватися по можливості без перезапису прикладних програм і в цілому викликати мінімальну кількість перетворень. Простота зміни бази даних може мати великий вплив на розвиток додатків баз даних в управлінні виробництвом. [10].
Про незалежність даних часто говорять як про один з основних властивостей бази даних. Під цим мається на увазі незалежність даних і використовують їх прикладних програм один від одного в тому сенсі, що зміна одних не призводить до зміни інших. Зокрема, прикладний програміст ізольований від впливу змін даних та їх організації, а також від зміни характеристик фізичних пристроїв, на яких вони зберігаються. У дійсності ж повністю незалежними дані бувають так само рідко, як і повністю ненадлишковим. Як ми побачимо нижче, незалежність даних визначається з різних точок зору. Відомості, якими повинен мати у своєму розпорядженні програміст для доступу до даних, різні для різних баз даних. Тим не менш, незалежність даних-це одна з основних причин використання систем управління базами даних.
У тому випадку, коли один набір елементів даних використовується для багатьох програм, між елементами цього набору встановлюється безліч різних взаємозв'язків, необхідних для відповідних прикладних програм. Організація бази даних в значній мірі залежить від реалізації взаємозв'язків між елементами даних і записами, а також від того, як і де ці дані зберігаються. У базі даних, що використовується багатьма програмами, повинні бути встановлені численні проміжні взаємозв'язку між елементами. У цьому випадку при зберіганні і використанні даних контролювати їх правильність, забезпечувати їх захист і таємність важче, ніж при зберіганні даних у простих, незв'язаних файлах. Що стосується забезпечення секретності даних і відновлення їх після збоїв, то це питання є дуже важливим при конструюванні баз даних. [8].
У деяких системах кошти управління базами даних застосовуються для того, щоб користувачі могли використовувати дані таким шляхом, який не був передбачений розробниками системи. Адміністратори або співробітники можуть звертатися до обчислювальної системи з питаннями, які заздалегідь в ній не передбачалися. Наявність цієї можливості означає таку організацію даних у системі, при якій доступ до них можна здійснювати за різними шляхами, причому одні і ті ж дані можуть використовуватися для відповідей на різні питання. Вся істотна інформація про об'єкти запам'ятовується одночасно і повністю, а не тільки та її частина, яка необхідна для однієї програми. [10].
В даний час існують СУБД, реалізують ці можливості як на рівні локальних баз даних, розташованих на одному диску (Paradox, Dbase), так і промислових баз даних (Acsess, Oracle, FoxPro).
3. Еволюція концепцій баз даних
Поняття база даних з'явилося наприкінці 60-х років. До цього у сфері обробки даних говорили про файли даних і про набори даних.До появи комп'ютерів третього покоління (перші з них були встановлені в 1965 р.) програмне забезпечення обробки даних здійснювало в основному операції введення-виведення. 0б організації даних доводилося дбати при написанні прикладних програм, і робилося це елементарним способом, тобто дані зазвичай організовувалися у вигляді простих послідовних файлів на магнітній стрічці. Незалежність даних відсутня. Якщо організація даних або запам'ятовуючі пристрої змінювалися, прикладний програміст повинен був відповідним чином модифіковані програми, заново їх компілювати і потім налагоджувати. Для того щоб оновити файл, потрібно було записати новий. Старий файл зберігався і називався вихідним. Попередній варіант також зберігався, а нерідко зберігалися і більш ранні версії файлу. Багато пристроїв використовувалися для однієї програми. Для інших програм часто використовували ті ж самі дані, але звичайно в іншій формі, з іншими полями, і тому доводилося з одних і тих же даних створювати різні файли. Внаслідок цього рівень надмірності в системі був дуже високий і існували різні файли, що містять одні й ті ж елементи даних.
Іноді використовувалися файли з довільним доступом до даних, які дозволяли користувачу отримати безпосередній доступ до будь-якого запису у файлі замість того, щоб послідовно переглядати весь файл. Засоби адресації записів забезпечувалися прикладним програмістом при написанні програми. Якщо змінювалися запам'ятовуючі пристрої, в прикладну програму необхідно було вносити великі зміни. На практиці зміна запам'ятовуючих пристроїв неминуче. Нова технологія призвела до значного зменшення витрат на зберігання одного біта інформації, а розміри файлів сьогодні часто перевищують за обсягом використовувалися раніше запам'ятовуючі пристрої. [7].
Етап 2 (кінець 60-х років) характеризується зміною в порівнянні з етапом 1 як природи файлів, так і пристроїв, на яких вони запам'ятовувалися. Робиться спроба захистити прикладного програміста від впливу змін в апаратурі. Програмне забезпечення допускає можливість зміни фізичного розташування даних без зміни при цьому їх логічного представлення за умови, що вміст записів або основна структура файлів не змінюється.
Файли, що відповідають цьому етапу розвитку засобів обробки даних, подібно файлів етапу 1, призначаються для однієї програми або для тісно пов'язаних між собою програм.
У міру розвитку засобів обробки комерційних даних ставало ясно, що прикладні програми бажано зробити незалежними не тільки від змін в апаратних засобах зберігання файлів і від збільшення розмірів файлів, але також і від додавання до збережених даними нових полів і нових взаємозв'язків. [7].
Відомо, що база даних є постійно розвивається об'єкт, який використовується зростаючою кількістю додатків. До бази даних додаються нові записи, а в існуючі записи включаються нові елементи даних. Структура бази даних буде змінюватися з метою підвищення ефективності її функціонування та при додаванні нових типів запитів. Користувачі будуть змінювати вимоги і модифікувати типи запитів на дані.
Структура бази даних є менш статичною, ніж файлова структура. Елементи даних, що зберігаються і способи їх запам'ятовування безперервно змінюються. Якщо на організацію даних з боку обчислювальної системи накладається обмеження у вигляді вимоги сталості файлової структури, то це призводить до того, що в разі її зміни програмісти витрачають багато часу на модифікацію існуючих програм, замість того щоб займатися розробкою нових програм.
В одному випадку може повідомлятися лише ім'я елемента даних або запису, яку він хоче отримати. В іншому випадку (при наявності іншого програмного забезпечення) він повинен був повідомляти ідентифікацію елемента даних та ім'я набору, в якому цей елемент даних міститься. Додавання нових елементів даних у записі без зміни прикладних програм можливо за тієї умови, що програмне забезпечення пов'язане з даними на рівні елементів даних (полів), а не на рівні записів. Це часто призводить до створення складних структур даних. Однак хороше програмне забезпечення баз даних позбавляє прикладного програміста від труднощів, пов'язаних зі складністю структури. Незалежно від того, яким чином дані організовані насправді, прикладний програміст повинен уявляти собі файл у вигляді порівняно простої структури, яка спланована відповідно до його вимог.
Програмне забезпечення баз даних етапу 3 (початок 70-х років) у своєму розпорядженні засобами відображення файлової структури прикладного програміста в таку фізичну структуру даних, яка запам'ятовується на реальному носії і навпаки.
Залежно від рівня програмного забезпечення прикладної програміст елемента даних повинен також знати організацію файлу даних. У цьому випадку йому, можливо, доведеться поставити машинний адресу даних. Якщо відсутня незалежність даних, прикладного програмісту необхідно знати точний фізичний формат запису. Найгірший варіант - це випадок, коли програміст повинен бути "навігатором". [7].
Процес перетворення звернення прикладного програміста до логічної запису або до елементів логічної запису в машинні звернення до фізичної запису і її елементів називається прив'язкою. Прив'язка - це зв'язок фізичного представлення даних з програмою, яка ці дані використовує. Після виконання процесу прив'язки програма вже не буде незалежною від фізичних даних. [7, 3].
Отже, для 3-го етапу:
· Різні логічні файли могли бути отримані з одних і тих же фізичних даних.
· Доступ до одних і тих же даних здійснювався різними додатками різними шляхами, що відповідають вимогам цих додатків.
· Програмне забезпечення містило засоби зменшення надлишковості даних.
· Елементи даних були загальними для різних додатків.
· Фізична структура даних незалежна від прикладних програм. Її можна було змінювати з метою підвищення ефективності бази даних, не викликаючи при цьому модифікації прикладних програм,
· Дані адресуються на рівні полів або груп. [7].
У міру накопичення досвіду використання перших систем управління базами даних досить скоро стало очевидно, що необхідний додатковий рівень незалежності даних. Загальна логічна структура даних, як правило, складна, і в міру росту бази даних вона неминуче змінюється. Тому важливо забезпечити можливість зміни загальної логічної структури без зміни використовуваних при цьому численних прикладних програм. У деяких системах зміну загальної логічної структури даних складає форму її існування, тобто ця структура знаходиться в стані постійного розвитку. Тому потрібні два рівні незалежності даних. Їх називають логічної і фізичної незалежністю даних.
Логічна незалежність даних означає, що загальна логічна структура даних може бути змінена без зміни прикладних програм (зміна, звичайно, не повинно полягати у видаленні з бази даних таких елементів, які використовуються прикладними програмами).
Фізична незалежність даних означає, що фізичне розташування та організація даних можуть змінюватися, не викликаючи при цьому змін ні спільної логічної структури даних, ні прикладних програм. [7, 8, 3].
Етап 4 характеризується ідей логічної і фізичної незалежності даних; логічна структура даних може сильно відрізнятися від фізичної структури даних і від їх уявлень в конкретних прикладних програмах. Програмне забезпечення баз даних буде фактично перетворювати подання даних прикладного програміста в загальне логічне уявлення, а потім буде відображати логічне уявлення у фізичне представлення даних.
Призначення такої структури забезпечує максимум свободи у зміні структур даних без переробки при цьому виконаної раніше роботи щодо формування та використання бази даних.
· База даних може розвиватися без великих витрат на ведення.
· Кошти, передбачені для адміністратора даних, дозволяють йому виконувати функції контролера і забезпечувати схоронність даних.
· Забезпечуються ефективні процедури управління захистом секретності, цілісності та безпеки даних.
· У деяких системах використовуються інвертовані файли, що дозволяють здійснювати швидкий пошук даних в базі даних.
· Бази даних конструюються для видачі відповідей на не плановані заздалегідь інформаційні запити.
· Забезпечуються засоби переміщення даних. [7].
4. Вимоги, яким повинна задовольняти організація бази даних.
Вивченням цього питання довгий час займалися різні групи людей в установах, що використовують комп'ютери, в урядових комісіях, на обчислювальних центрах колективного користування. Комітет CODASYL опублікував звіти на цю тему (CODASYL-організація, що розробила мову КОБОЛ). Організації користувачів IBM SHARE і GUIDE у своєму звіті сформулювали вимоги до системи управління базами даних. Організація ACiM (Association for Computing Machinery) також займалася вивченням цього питання.Нижче перераховані основні вимоги до організації бази даних.
4.1. Встановлення багатосторонніх зв'язків
Різним програмістам потрібні різні логічні файли. Ці файли виходять з однієї і тієї самої сукупності даних. Між елементами запам'ятовуються даних можуть існувати різні зв'язку. Деякі бази даних будуть містити складні переплетення взаємозв'язків. Метод організації даних повинен бути таким, щоб забезпечувалася можливість зручного подання цих взаємозв'язків і швидкого узгодження внесених до них змін. Система управління базами даних повинна забезпечувати можливість отримання необхідних логічних файлів з наявних даних і існуючих між ними зв'язків. Необхідно, щоб існувало хоча б невелика схожість між поданням логічного файлу в прикладній програмі та у спосіб фізичного зберігання даних. [7, 10, 11].4.2. Продуктивність
Бази даних, спеціально розроблені для використання їх оператором терміналу, забезпечують час відповіді, задовільний для діалогу людини - термінал. Крім того, система баз даних повинна забезпечувати відповідну пропускну здатність. У системах, розрахованих на невеликий потік запитів, пропускна здатність накладає незначні обмеження на структуру бази даних. У системах з великим потоком запитів, наприклад, у системах резервування авіаквитків, пропускна здатність робить вирішальний вплив на вибір організації фізичного зберігання даних.У системах, призначених лише для пакетної обробки, час відповіді не так важливо і метод фізичної організації може вибиратися з умов забезпечення ефективної пакетної обробки. [7, 10, 11].
4.3. Мінімальні витрати
Для зменшення витрат на створення і експлуатацію бази даних вибираються такі методи організації, які мінімізують вимоги до зовнішньої пам'яті. При використанні цих методів фізичне уявлення даних у пам'яті може сильно відрізнятися від того уявлення, яке використовує прикладний програміст. Перетворення одного подання до іншого здійснюють програмне забезпечення або, якщо можливо, апаратні або мікропрограмні кошти. У таких випадках доводиться вибирати між витратами на алгоритм перетворення і економією пам'яті. [7, 10, 11].4.4. Мінімальна надмірність
У системах обробки, які існували до використання систем управління базами даних, інформаційні фонди мали дуже високим рівнем надмірності. Більшість стрічкових бібліотек містило велику кількість надлишкових даних. Навіть при використанні баз даних в міру зростання інформації, об'єднаній в інтегровані бази даних, потенційна можливість появи надлишкових даних поступово збільшується. Надлишкові дані дороги в тому сенсі, що вони займають більше пам'яті, ніж це необхідно, і вимагають більш однієї операції оновлення. Метою організації бази даних повинне бути знищення надлишкових даних там, де це вигідно, і контроль за тими суперечностями, які викликаються наявністю надлишкових даних. [7, 10, 11].4.5. Можливості пошуку
Користувач бази даних може звертатися до неї з самими різними питаннями з приводу збережених даних. У більшості сучасних комерційних додатків типи запитів зумовлені, і фізична організація даних розробляється для їх обробки з необхідною швидкістю. Зрослі вимоги до систем полягають у забезпеченні обробки таких запитів або формування таких відповідей, які заздалегідь не заплановані. [7, 10, 11].4.6. Цілісність
Якщо база даних містить дані, які використовуються багатьма користувачами, дуже важливо, щоб елементи даних і зв'язку між ними не руйнувалися. Необхідно враховувати можливість виникнення помилок і різного роду випадкових збоїв. Зберігання даних, їх оновлення, процедури включення даних повинні бути такими, щоб система в разі виникнення збоїв могла відновлювати дані без втрат. Необхідно, щоб обчислювальна система гарантувала цілісність збережених у ній даних. [7, 10, 11].4.7. Безпека і секретність
Дані в системах баз даних повинні зберігатися в таємниці й схоронності. Запам'ятовується інформація іноді дуже важлива для використовує її установи. Вона не повинна бути загублені або викрадена. Для збільшення життєстійкості інформації в базі даних важливо захищати її від апаратних або програмних збоїв, від катастрофічних і кримінальних ситуацій, від некомпетентного або коректного використання особами, які можуть її неправильно спожити.Під безпекою даних розуміють захист даних від випадкового або навмисного доступу до них осіб, які не мають на це право, від неавторизованої модифікації даних або їх знищення.
Секретність визначають як право окремих осіб чи організацій визначати, коли, як і яку кількість відповідної інформації може бути передане іншим особам або організаціям. [7, 10, 11].
4.8. Зв'язок з минулим
Організації, які протягом якогось часу експлуатують системи обробки даних, витрачають значні кошти на написання програм, процедур і організацію зберігання даних. У тому випадку, коли фірма починає використовувати на обчислювальній установці нове програмне забезпечення управління базами даних, дуже важливо, щоб при цьому вона могла працювати з вже існуючими на цій установці програмами, оброблювані дані можна було б відповідним чином перетворювати. Така умова вимагає наявності програмної та інформаційної сумісності, і її відсутність може стати основним стримуючим чинником при переході до нових систем управління базами даних. Важливо, однак, щоб проблема зв'язку з минулим не стримувала розвиток засобів управління базами даних. [7, 10, 11].4.9. Зв'язок з майбутнім
Особливо важливою представляється зв'язок з майбутнім. У майбутньому дані і середовище їх зберігання зміняться з багатьох напрямків. Будь-яка комерційна організація з часом зазнає змін. Особливо дорогими ці зміни виявляються для користувачів системами обробки даних. Величезні витрати, які потрібні для реалізації самих простих змін, сильно гальмують розвиток цих систем. Ці витрати витрачаються на перетворення даних, перезапис і налагодження прикладних програм, які стали результатом внесення змін. З часом число прикладних програм в організації зростає, і тому перспектива перезапису всіх цих програм здається нереальною. Одна з найбільш важливих завдань при розробці баз даних-запланувати базу даних таким чином, щоб зміни її можна було виконувати без модифікації прикладних програм. [7, 10, 11].4.10. Простота використання
Засоби, які використовуються для надання загального логічного опису даних, повинні бути простими і витонченими.Інтерфейс програмного забезпечення повинен бути орієнтований на кінцевого користувача і враховувати можливість того, що користувач не має необхідної бази знань з теорії баз даних. [7, 10, 11].
5. Моделі представлення даних
Зі зростанням популярності СУБД в 70-80-х роках з'явилося безліч різних моделей даних. У кожної з них були свої достоїнства і недоліки, які зіграли ключову роль у розвитку реляційної моделі даних, що з'явилася в чому завдяки прагненню спростити і впорядкувати перші моделі даних.Сучасні БД грунтуються на використанні моделей даних (МД), що дозволяють описувати об'єкти предметних областей і взаємозв'язку між ними існують три основні МД та їх комбінації, на яких грунтуються БД: реляційна модель даних (РМД), мережева модель даних (СМД), ієрархічна модель даних (ІМД).
Основна відмінність між цими моделями даних полягає у засобах опису взаємодій між об'єктами і атрибутами. Взаємозв'язок виражає відношення між множинами даних.
Використовують взаємозв'язку "один до одного", "один до багатьох" і "багато до багатьох". "Один до одного" - це взаємно однозначна відповідність, яке встановлюється між одним об'єктом і одним атрибутом. "Один до багатьох" - це відповідність між одним об'єктом і багатьма атрибутами. "Багато до багатьох" - це відповідність між багатьма об'єктами і багатьма атрибутами. [10, 11, 12].
Розглянемо ці моделі даних більш докладно.
5.1. Ієрархічна модель даних
ІМД заснована на понятті дерев, що складаються з вершин і ребер. Вершині дерева ставиться у відповідність сукупності атрибутів даних, що характеризують деякий об'єкт. Вершини і ребра дерева ніби утворюють ієрархічну деревоподібну структуру, що складається з n рівнів.Першу вершину називають кореневою вершиною. Він задовольняє умовам:
1. Ієрархія починається з кореневої вершини.
2. Кожна вершина відповідає одному або декільком атрибутам.
3. Hа рівнях з великим номером знаходяться залежні вершини. Вершин попереднього рівня є початковою для нових залежних вершин.
4. Кожна вершина, що знаходиться на рівні i, з'єднана з одного і тільки однією вершиною рівня i-1, за винятком кореневої вершини.
5. Коренева вершина може бути пов'язана з однією або кількома залежними вершинами.
6. Доступ до кожної вершині відбувається через кореневу по єдиному шляху
7. Існує довільну кількість вершин кожного рівня.
Ієрархічна модель даних складається з декількох дерев, тобто є лісом. Кожна коренева вершин утворює початок запису логічної бази даних. У ІМД вершини, що знаходяться на рівні i, називають породженими вершин ми н рівні i-1.
Операції в ІМД мають нелогічний позапісний характер. Апарат переміщення по структурі в графових моделях служить для установки тих об'єктів даних, до якої застосовуватиметься чергова операція маніпулювання даними. Такі об'єкти називаються поточними. Механізми доступу до даних і переміщення по структурі даних в таких моделях досить складні і істотним чином спираються на концепцію поточного стану механізму доступу. [7, 10, 11, 12].
Основні переваги ІМД: простота побудови та використання, забезпечення певного рівня незалежності даних, простота оцінки операційних характеристик. Основні недоліки: відношення "багато до багатьох" реалізується дуже складно, дає громіздку структуру і вимагає зберігання надлишкових даних, що особливо небажано на фізичному рівні, ієрархічна впорядкованість ускладнює операції видалення і включення, доступ до будь-якої вершині можливий тільки через кореневу, що збільшує час доступу .
До числа СУБД ієрархічного типу можна віднести PC / Focus, Team-Up, Data Edge, також розроблену в нашій країні систему HІКА, спадкоємицю широко поширеною радянської системи ІHЕС для ЄС ЕОМ.
Однією з найбільш важливих сфер застосування перших ієрархічних СУБД було планування виробництва для компаній, що займаються випуском продукції. Наприклад, якщо автомобільна компанія хотіла випустити 10000 машин однієї моделі і 5000 машин іншої моделі, їй необхідно було знати, скільки деталей слід замовити у своїх постачальників. Щоб відповісти на це питання, необхідно визначити, з яких деталей складаються ці частини і т.д. Наприклад, машина складається з двигуна, корпусу і ходової частини; двигун складається з клапанів, циліндрів, свічок і т.д. Робота зі списками складових частин була неначе спеціально призначена для комп'ютерів.
Список складових частин виробу за своєю природою є ієрархічною структурою. Для зберігання даних, що мають таку структуру, була розроблена ієрархічна модель даних, яку ілюструє рис. 1.
У цій моделі кожна запис бази даних представляла конкретну деталь. Між записами існували відносини предок / нащадок, що зв'язують кожну частину з деталями, що входять до неї.
Рис. 1. Ієрархічна база даних, що містить інформацію про складові частини |
Автомобіль |
Двигун |
Корпус |
Ходова частина |
Дах |
Днище |
Права двері |
Ліва двері |
Замок |
Вікно |
Ручка |
Записи |
Щоб отримати доступ до даних, які містяться у базі даних, програма могла:
· Знайти конкретну деталь (праві двері) по її номеру;
· Перейти "вниз" до першого нащадку (ручка дверей);
· Перейти "вгору" до предка (корпус);
· Перейти "в бік" до іншого нащадку (праві двері).
Таким чином, для читання даних з ієрархічної бази даних було потрібно переміщатися по записах, за один раз переходячи на одну запис вгору, вниз або убік.
Обмеження цілісності.
Автоматично підтримується цілісність посилань між предками і нащадками. Основне правило: ніякої нащадок не може існувати без свого батька. Зауважимо, що аналогічне підтримку цілісності по посиланнях між записами, що не входять в одну ієрархію, не підтримується. [7, 9].
В ієрархічних системах підтримувалася деяка форма уявлень БД на основі обмеження ієрархії.
5.2. Мережева модель даних
Мережева модель даних задумувалася як інструмент для користувачів баз даних - програмістів. У зв'язку з цим у СМД більше уваги приділяється структуризації даних, ніж розвитку її операційних можливостей.У СМД елементарні дані і відносини між ними представляються у вигляді орієнтованої мережі (вершини - дані, дуги - відношення). [7].
Acme Mfg. |
Bill Adams |
Size 4 Widget |
# 112963 |
Замовлення |
Клієнти |
Службовці |
Товари |
Рис. 2. Множинні відносини предок / нащадок |
Якщо структура даних виявлялася складніше, ніж звичайна ієрархія, простота структури ієрархічної бази даних ставала її недоліком. Наприклад, в базі даних для зберігання замовлень одне замовлення міг брати участь у трьох різних відносинах предок / нащадок, що пов'язують замовлення з клієнтом, що розмістили його, зі службовцем, який його прийняв, і із замовленим товаром, що ілюструє рис. 2. Такі структури даних не відповідали суворої ієрархії IMS.
У зв'язку з цим для таких додатків, як обробка замовлень, була розроблена нова мережева модель даних. Вона була поліпшеної ієрархічною моделлю, в якій один запис могла брати участь в декількох аспектах предок / нащадок. У мережній моделі такі відносини називалися множинами. У 1971 році на конференції за мовами систем даних був опублікований офіційний стандарт мережевих баз даних, який відомий як модель CODASYL. Компанія IBM не стала розробляти власну мережеву СУБД і замість цього продовжувала нарощувати можливість IMS. Але в 70-х роках незалежні виробники програмного забезпечення реалізували мережеву модель в таких продуктах, як IDMS компанії Cullinet, Total компанії Cincom і СУБД Adabas, які набули великої популярності.
Мережні бази даних володіли рядом переваг:
· Гнучкість. Множинні відносини предок / нащадок дозволяли мережевий базі даних зберігати дані, структура яких була складнішою простий ієрархії.
· Стандартизація. Поява стандарту CODASYL популярність мережевої моделі, а такі постачальники міні-комп'ютерів, як Digital Equipment Corporation і Data General, реалізували мережеві СУБД.
· Швидкодія. Всупереч своїй великої складності, мережеві бази даних досягали швидкодії, порівнянного з швидкодією ієрархічних баз даних. Безлічі були представлені покажчиками на фізичні запису даних, і в деяких системах адміністратор міг задати кластеризацію даних на основі безлічі відносин.
Звичайно, у мережевих баз даних були недоліки. Як і ієрархічні бази даних, мережеві базі даних були дуже жорсткими. Набори відносин і структуру записів доводилося ставити наперед. Зміна структури бази даних зазвичай означало перебудову всієї бази даних.
Як ієрархічна, так і мережева база даних були інструментами програмістів. Щоб отримати відповідь на питання типу "Який товар найбільш часто замовляє компанія Acme Manufacturing?", Програмістові доводилося писати програму для навігації по базі даних. Реалізація користувача запитів часто затягувалася на тижні і місяці, і до моменту появи програми інформація, яку вона надавала, часто виявлялася марною. [7, 10].
Обмеження цілісності.
В принципі їх підтримку не потрібно, але іноді вимагають цілісності по посиланнях (як в ієрархічній моделі).
5.3. Реляційна модель даних
Недоліки ієрархічної й мережної моделей призвели до появи нової, реляційної моделі даних, створеної Коддом в 1970 році і викликала загальний інтерес. Реляційна модель була спробою спростити структуру бази даних. У ній були відсутні явні покажчики на предків і нащадків, а всі дані були представлені у вигляді простих таблиць, розбитих на рядки і стовпці. На рис. 3. показана реляційна версія мережевої бази даних, яка містить інформацію про замовлення і наведеної на рис. 2.На жаль, практичне визначення поняття "реляційна база даних" виявилося набагато більш розпливчастим, ніж точне математичне визначення, дане цьому терміну Коддом в 1970 році. У перших реляційних СУБД не були реалізовані деякі з ключових частин моделі Кодда, і цю прогалину було заповнено лише згодом. У міру зростання популярності реляційної концепції реляційними стали називатися багато баз даних, які на ділі такими не були.
| ||||||||||||
Рис. 3. Реляційна база даних, що містить інформацію про замовлення |
У відповідь на неправильне використання терміну "реляційний" Кодд в 1985 році написав статтю, де сформулював 12 правил, яким повинна задовольняти будь-яка база даних, що претендує на звання реляційної. З тих пір дванадцять правил Кодда вважаються визначенням реляційної СУБД. Однак можна сформулювати й простіше визначення:
Реляційної називається база даних, в якій всі дані, доступні користувачеві, організовані у вигляді таблиць, а всі операції над даними зводяться до операцій над цими таблицями.
Наведене визначення не залишає місця вбудованим вказівниками, наявними в ієрархічних і мережевих СУБД. Незважаючи на це, реляційна СУБД також здатна реалізувати відносини предок / нащадок, проте ці відносини представлені виключно значеннями даних, що містяться в таблицях.
Оскільки в програмній реалізації дипломної роботи обрано реляційний підхід, як найбільш підходящий, опишемо його більш докладно. [3, 7, 8, 12].
5.3.1. Таблиці
Таблиці - фундаментальні об'єкти реляційної бази даних, в яких зберігається основна частина даних програми. Окрема таблиця найчастіше зберігає інформацію по конкретній темі (наприклад, відомості про службовців компанії або адреси замовників). Інформація в таблиці організується в рядки (записи) і стовпці (поля). Таблиці притаманні два компоненти: структура таблиці і дані таблиці.Структура таблиці (також називається визначенням таблиці) специфицируется при створенні таблиці. Структура таблиці повинна бути спроектована і створена перед введенням в таблицю будь-яких даних. Вона визначає, які дані таблиця буде зберігати, а також правила, асоційовані з введенням, зміною або видаленням даних (бізнес-правила, або обмеження).
Структура таблиці включає наступну інформацію:
· Ім'я таблиці - Ім'я, по якому до таблиці можна звернутися у властивостях, методах і операторах SQL.
· Стовпці таблиці - Категорії інформації, що зберігається у таблиці. Кожен стовпець має ім'я і тип даного.
· Табличні та столбцовие обмеження - Обмеження цілісності, визначені на рівні таблиці або на рівні стовпця. [3, 7, 8, 12].
| ||||||||||||||||||||||||||||||||||||||||||
Дата народження |
Номер підгрупи |
Дані про підгрупі для ІВАНОВА |
Дані про підгрупі для Крохіна |
Рис. 4. Структура реляційної таблиці. |
Більш наочно структуру таблиці ілюструє рис 4., На якому зображена таблиця STUDENTS. Кожна горизонтальна рядок цієї таблиці представляє окрему фізичну сутність - одного студента. Всі дані, що містяться в конкретній рядку таблиці, відносяться до студента, який описується цим рядком.
Кожен вертикальний стовпець таблиці STUDENTS представляє один елемент даних для кожного зі студентів. Наприклад, у стовпці GROUP містяться номери груп, в яких розташовані студенти. У стовпці DATE містяться дати народження кожного студента.
Дані таблиці - інформація, яка збережена в таблиці. Всі дані таблиці зберігаються в рядках, кожна з яких містить порції інформації у стовпцях, визначених у структурі таблиці. Дані - та частина таблиці, до якої зазвичай повинні мати доступ користувачі програми (наприклад, дані таблиці можуть виводитися в елементах управління, розміщених у формах і звітах).
На перетині кожного рядка з кожним стовпцем таблиці міститься в точності одне значення даних. Наприклад, у другому рядку в стовпці FAMILY міститься значення "ІВАНОВ". У стовпці PODGRP того ж рядка міститься значення 1, який є номером підгрупи, в якій знаходиться даний студент.
Всі значення, що містяться в одному і тому ж стовпці, є даними одного типу. Наприклад, у стовпці FAMILY містяться тільки слова, у стовпці DATE містяться дати, а в стовпці NUMBER містяться цілі числа, що представляють ідентифікатори студентів. Безліч значень, які можуть міститися в стовпці, називається доменом цього стовпця. Доменом стовпця FAMILY є безліч прізвищ студентів. Доменом стовпця DATE є будь-яка дата.
У кожного стовпця в таблиці є своє ім'я, яке зазвичай служить заголовком стовпця. Всі стовпчики в одній таблиці повинні мати унікальні імена, проте дозволяється присвоювати однакові імена стовпців, розташованим в різних таблицях. На практиці такі імена стовпців, як NUMBER, FAMILY, NAME, GROUP, DATE, PODGRP, часто зустрічаються в різних таблицях однієї бази даних.
Стовпці таблиці впорядковані зліва направо, і їх порядок визначається при створенні таблиці. У будь-якій таблиці завжди є як мінімум один стовпець. У стандарті ANSI / ISO не вказується максимально допустиму кількість стовпців в таблиці, проте майже у всіх комерційних СУБД ця межа існує і зазвичай становить приблизно 255 стовпців.
На відміну від стовпців, рядки таблиці не мають певного порядку. Це означає, що якщо послідовно виконати два однакових запиту для відображення вмісту таблиці, немає гарантії, що обидва рази рядки будуть перераховані в одному і тому ж порядку.
У таблиці може міститися будь-яку кількість рядків. Цілком припустимо існування таблиці з нульовою кількістю рядків. Така таблиця називається порожньою. Порожня таблиця зберігає структуру, певну її стовпцями, просто в ній не міститься дані. Стандарт ANSI / ISO не накладає обмежень на кількість рядків у таблиці, і в багатьох СУБД розмір таблиць обмежений лише вільним дисковим простором комп'ютера. В інших СУБД є максимальна межа, проте він вельми високий - близько двох мільярдів рядків, а іноді й більше. [12].
5.3.2. Ключові поля
Міць реляційних баз даних полягає в тому, що з їх допомогою можна швидко знайти і зв'язати дані з різних таблиць за допомогою запитів; форм і звітів. Для цього кожна таблиця повинна містити одне або кілька полів, однозначно ідентифікують кожний запис у таблиці. Ці поля називаються ключовими полями таблиці. Ключові поля ще також називають первинним ключем. Можна виділити три типи ключових полів: лічильник, простий ключ і складовою ключ.Оскільки рядки в реляційної таблиці не впорядковані, не можна вибрати рядок по її номеру в таблиці. У таблиці немає "першої", "останньої" або "тринадцяту" рядка. Тоді яким же чином можна вказати в таблиці конкретну рядок, наприклад рядок для студента з прізвищем Іванов?
Ключове поле можна задати таким чином, щоб при додаванні кожного запису в таблицю в це поле автоматично вносилося порядкове число, тобто організувати лічильник. Це найбільш простий спосіб створення ключових полів.
Якщо поле містить унікальні значення, такі як коди чи інвентарні номери, то це поле можна визначити як простий ключ. Якщо вибране поле містить повторювані або порожні значення, то воно не буде визначено як ключове. Для визначення записів, що містять повторювані дані, можна виконати запит на пошук повторюваних записів. Якщо усунути повтори шляхом зміни значень неможливо, то слід або додати в таблицю поле лічильника і зробити його ключовим, або визначити складовою ключ. [3, 7, 8, 12].
На перший погляд, первинним ключем таблиці STUDENTS можуть служити і стовпець FAMILY. Проте в житті досить часто зустрічаються однофамільці, отже, стовпець FAMILY більше не може виконувати роль ключа. На практиці в якості первинних ключів таблиць звичайно треба вибирати ідентифікатори, такі як ідентифікатор студента NUMBER в таблиці STUDENTS.
| ||||||||||||||||||||||||||||||
Первинний ключ |
Рис. 5. Приклад таблиці з складовим первинним ключем |
Таблиця ORDERS, фрагмент якої показано на рис. 5., Є прикладом таблиці, в якій первинний ключ являє собою комбінацію стовпців. Такий первинний ключ називається складовим ключем.
Він застосовується у випадках, коли неможливо гарантувати унікальність значень кожного окремого поля. Найчастіше така ситуація виникає для таблиці, використовуваної для скріплення двох таблиць у відношенні "багато-до-багатьох".
Стовпець NSTUD містить ідентифікатори студентів, перерахованих в таблиці, а стовпець NORDER містить номери, наказам. Може здатися, що стовпець NORDER міг би й один виконувати роль первинного ключа, проте ніщо не заважає одному студенту кілька разів потрапити під відрахування і потім відновитися на факультеті. Таким чином, в якості первинного ключа таблиці ORDERS необхідно використовувати комбінацію стовпців NSTUD і NORDER. Для кожного зі студентів, що містяться в таблиці, комбінація значень в цих стовпцях буде унікальною.
Первинний ключ для кожного рядка таблиці є унікальним, тому в таблиці з первинним ключем немає двох абсолютно однакових рядків. Таблиця, в якій всі рядки відрізняються один від одного, в математичних термінах називається відношенням. Саме цьому терміну реляційні бази даних і зобов'язані своєю назвою, оскільки в їх основі лежать відносини (таблиці з відмінними один від одного рядками).
Хоча первинні ключі є важливою частиною реляційної моделі даних, у перших реляційних СУБД (System / R, DB2, Oracle та інших) не була забезпечена явним чином їх підтримка. Як правило, проектувальники бази даних самі стежили за тим, щоб у всіх таблиць були первинні ключі, проте в самих СУБД не було можливості визначити для таблиці первинний ключ. І тільки в СУБД DB2 Version 2, що з'явилася у квітні 1988 року, компанія IBM реалізувала підтримку первинних ключів. Після цього подібна підтримка була додана в стандарт ANSI / ISO. [3, 7, 8, 12].
5.3.3. Індекси
Індекси - об'єкти бази даних, які забезпечують швидкий доступ до окремих рядків у таблиці. Індекс створюється з метою підвищення продуктивності операцій запитів і сортування даних таблиці. Індекси також використовуються для підтримки в таблицях деяких типів ключових обмежень; ці індекси часто створюються автоматично при визначенні обмеження.Індекс - незалежний об'єкт, логічно окремий від таблиці; створення або видалення індексу ніяк не впливає на визначення або дані індексованої таблиці. Він зберігає високо оптимізовані версії всіх значень одного чи більше стовпців таблиці. Коли значення запитує з індексованого стовпця, процесор (ядро) бази даних використовує індекс для швидкого знаходження необхідного значення. Індекси повинні постійно підтримуватися, щоб відображати останні зміни індексованих стовпців таблиці. Процедури оновлення індексу при вставці, модифікації або видалення значення в індексований стовпець автоматично виконуються процесором бази даних. Хоча ці операції не вимагають ніяких дій з боку користувача, вони, однак, знижують ефективність деяких операцій маніпулювання даними (крім запитів на вибірку). Однак зменшення продуктивності, асоційоване з підтриманням індексу, в більшості випадків з лишком компенсується перевагами підвищення швидкодії доступу до даних, яке забезпечує індекс. Індекси забезпечують найбільші вигоди для відносно статичних таблиць, за якими часто виконуються запити.
Створити індекси, як і ключі, можна по одному або декількох полях. Складові індекси дозволяють при відборі даних групувати записи, в яких перші поля можуть мати однакові значення. Індексувати поля потрібно для виконання частих пошуків, сортувань або об'єднань з полями з інших таблиць в запитах. Ключові поля таблиці індексуються автоматично. Не можна індексувати поля з типом даних поле МЕМО, гіперпосилання або об'єкт OLE. Для решти полів індексування використовується, якщо поле має текстовий, числовий, грошовий тип або тип дати / часу і потрібно здійснювати пошук і сортування значень у полі. Якщо передбачається, що буде часто виконуватися сортування або пошук одночасно по двох і більше полів, можна створити складовою індекс. Наприклад, якщо для одного і того ж запиту часто встановлюється критерій для поля Назва та Прізвище, то для цих двох полів має сенс створити складовою індекс. Під час сортування таблиці за складеним індексу спочатку здійснюється сортування по першому полю, визначеного для даного індексу. Якщо в першому полі містяться записи з повторюваними значеннями, то сортування здійснюється по другому полю і т. д. [3, 7, 8, 12].
5.3.4. Відносини предок / нащадок
Однією з відмінностей реляційної моделі від перших моделей представлення даних було те, що в ній були відсутні явні покажчики, використовувані для реалізації відносин предок / нащадок в ієрархічній моделі даних. Однак цілком очевидно, що відносини предок / нащадок існують і в реляційних базах даних. Наприклад, у нашій базі даних кожній оцінці на іспиті відповідає дисципліна, тому ясно, що між рядками таблиці DISCIPLS і таблиці EXAMINE існує відношення.Як випливає з рис.6, це жодним чином не приводить до втрати інформації. На малюнку зображено кілька рядків з таблиць DISCIPLS і EXAMINE. Звернемо увагу на те, що в стовпці NUMBER таблиці EXAMINE міститься ідентифікатор студента. Доменом цього стовпця (безліччю значень, які можуть у ньому зберігатися) є безліч ідентифікаторів студентів, що містяться в стовпці NUMBER таблиці EXAMINE.
Ставлення предок / нащадок, що існує між дисциплінами та оцінками за іспит, в реляційній моделі не втрачено; просто воно реалізоване у вигляді однакових значень даних, що зберігаються у двох таблицях, а не у вигляді явного покажчика. Всі відносини, що існують між таблицями реляційної бази даних, реалізуються в такому вигляді.
5.3.5. Таблиця DISCIPLS
NDIS
NAME
TYPEDIS
22
МАТ.АНАЛІЗ
Загаль
11
ФІЗИКА
Естеств
12
ІН.ЯЗИК
Гуманітарна
Таблиця EXAMINE
NUMBER
NUM_DIS
SEMESTR
RESULT
105
22
1
3
109
11
1
3
102
11
2
4
106
12
5
5
Рис. 6. Ставлення предок / нащадок в реляційної базі даних
Зовнішні ключі
Стовпець однієї таблиці, значення в якому збігаються зі значеннями стовпця, що є первинним ключем іншої таблиці, називається зовнішнім ключем. На рис. 7 стовпець NUM_DIS являє собою зовнішній ключ для таблиці DISCIPLS. Значення, що містяться в цьому стовпці, представляють собою ідентифікатори дисциплін, що вивчаються. Ці значення відповідають значенням у стовпці NDIS, який є первинним ключем таблиці DISCIPLS. Сукупно первинний і зовнішній ключі створюють між таблицями, в яких вони містяться, таке ж відношення предок / нащадок, як і в ієрархічній базі даних.
| |||||||||||||||
| ||||||||||||||||||||||||
Рис. 6. Ставлення предок / нащадок в реляційної базі даних |
Зовнішній ключ, як і первинний ключ, теж може бути комбінацією стовпців. На практиці зовнішній ключ завжди буде складовим (що складається з декількох стовпців), якщо він посилається на складовою первинний ключ в іншій таблиці. Очевидно, що кількість шпальт і їх типи даних у первинному і зовнішньому ключах збігаються.
Якщо таблиця пов'язана з кількома іншими таблицями, вона може мати декілька зовнішніх ключів. На рис. 7. показані три зовнішніх ключа таблиці ORDERS з навчальної бази даних:
стовпець REP є зовнішнім ключем для таблиці SALESREPS і
пов'язує кожне замовлення зі службовцем, який його прийняв;
стовпець CUST є зовнішнім ключем для таблиці CUSTOMES і
пов'язує кожне замовлення з клієнтом, що розмістили його;
| ||||||||||
| ||||||||||
| |||||||||||||||
| ||||||||||||||||||||||||||||||
Рис. 7. Множинні відносини предок / нащадок в реляційної базі даних |
стовпці MRF і PRODUCT сукупно є складовою зовнішній ключ для таблиці PRODUCTS, який пов'язує кожне замовлення із замовленим товаром.
Реляційна модель даних володіє всіма можливостями мережевої моделі за частиною вираження складних відносин.
Зовнішні ключі є невід'ємною частиною реляційної моделі, оскільки реалізують відносини між таблицями бази даних. До нещастя, як і у випадку з первинними ключами, підтримка зовнішніх ключів відсутня в перших реляційних СУБД. Вона була введена в системі DB2 Version 2 і тепер є у всіх комерційних СУБД.
5.3.6. Реляційна алгебра
Основна ідея реляційної алгебри полягає в тому, що коли незабаром таблиці є множинами, то кошти маніпулювання ними можуть базуватися на традиційних теоретико-множинних операціях, доповнених деякими спеціальними операціями, специфічними для баз даних.Використовується трохи розширений початковий варіант алгебри, який був запропонований Коддом. У цьому варіанті набір основних алгебраїчних операцій складається з восьми операцій, які діляться на два класи - теоретико-множинні операції, і спеціальні реляційні операції. До складу теоретико-множинних операцій входять операції:
· Об'єднання таблиць;
· Перетину таблиць;
· Взяття різниці таблиць;
· Прямого твори таблиць.
Спеціальні реляційні операції включають:
· Обмеження таблиці;
· Проекцію таблиці;
· З'єднання таблиць;
· Поділ таблиць.
Крім того, до складу алгебри включається операція присвоювання, що дозволяє зберегти в базі даних результати обчислення алгебраїчних виразів, і операція перейменування атрибутів, що дає можливість коректно сформувати заголовок (схему) результуючої таблиці.
Обмеження цілісності.
Існують три підходи, кожен з яких підтримує цілісність по посиланнях. Перший підхід полягає в тому, що забороняється проводити видалення запису, на яку існують посилання (тобто спочатку потрібно або видалити посилаються запису, або відповідним чином змінити значення їх зовнішнього ключа). При другому підході при видаленні запису, на яку є посилання, у всіх посилань записах значення зовнішнього ключа автоматично стає невизначеним. Нарешті, третій підхід (каскадне видалення) полягає в тому, що при видаленні запису з таблиці, на яку веде посилання, з посилається таблиці автоматично видаляються всі посилаються запису. [7, 12, 13].
5.3.7. Нормалізація бази даних
Процес трансформації даних в реляційну форму називається нормалізацією [9]. Говорячи простіше, нормалізація - це видалення надлишкових даних з кожної таблиці в базі даних. У нормалізації подвійна мета - видалити зайві копії даних і забезпечити максимальну гнучкість як у структурах таблиць, так і в інтерфейсних додатках на випадок можливих майбутніх змін у базах даних.Про нормалізацію таблиць в базі даних потрібно піклується на ранньому етапі проектування програми, тому що при "живих" даних досить важко змінювати структуру бази. Іноді процес нормалізації породжує додаткові таблиці, які були не включені в початковий проект. Дізнавшись про це якомога раніше, не доведеться даремно витрачати сили на їх розробку.
Нормалізація звичайно підрозділяється на п'ять форм або стадій-від першої нормальної форми по п'яту нормальну форму. Тобто просто п'ять установок реляційного критерію, який або виявляє таблицю, або ні. Кожна наступна стадія будується на попередній. Формально існує п'ять форм, але на практиці, як правило, використовується тільки перші три. Останні дві вважаються занадто спеціальними, щоб їх застосовувати до звичайних проектів баз даних. [7, 8, 10].
5.3.7.1. Перша нормальна форма
Для того щоб таблиця вважалася нормалізованої до першої нормальної форми, кожна з її полів повинна бути неподільним і не повинно містити ніяких повторюваних груп.Поле вважається неподільним, якщо воно містить тільки один елемент даних. Наприклад, поле Address, яке містить не тільки назву вулиці, але також і міста, поштовий код, не є неподільним. Щоб відповідати першій нормальній формі, такі стовпці повинні бути розбиті на декілька полів. [7, 8, 10].
Повторювана група - це поле, яке повторюється всередині визначення запису з метою зберігання кількох значень для атрибута.
5.3.7.2. Друга нормальна форма
Для того щоб привести таблицю до другої нормальної форми, потрібно, щоб все не ключові поля повністю залежали від первинного ключа таблиці і від кожного поля в первинному ключі, якщо останній складається з декількох полів. Це означає, що кожне не ключове поле повинно унікально визначатися первинним ключем і полями, його складовими. [7, 8, 10].5.3.7.3. Третя нормальна форма
Для того щоб таблиця була приведена до третьої нормальній формі, потрібно, щоб все не ключові поля повністю залежали від первинного ключа таблиці і не залежали один від одного. Таким чином, до кваліфікації другої нормальної форми додається вимога незалежності кожного не ключового поля таблиці від інших не ключових полів. [7, 8, 10].5.3.7.4. Четверта нормальна форма
Четверта нормальна форма забороняє зберігати незалежні елементи в одній і тій же таблиці, коли між цими елементами існують взаємини типу багато-до-багатьох. Четверта нормальна форма вимагає, щоб запам'ятали такі елементи в окремих таблицях і створили таблицю відносин для організації зв'язків між таблицями, що характеризуються взаємовідносинами типу багато-до-багатьох.Звичайно ж, оскільки два стовпці знаходяться у стосунках багато-до-багатьох, то вони вже не є незалежними, і тим самим уже порушують третю нормальну форму. З цієї причини четверта нормальна форма розглядається більше теоретично, тому що частково вона перекривається третій нормальній формою. [7, 8, 10].
5.3.7.5. П'ята нормальна форма
П'ята нормальна форма вимагає, щоб ви мали можливість перебудовувати свої дані в нормалізованих таблицях, в які вони були переведені. Це означає, що якщо ви починаєте з ненормалізованих таблиць, то у вас не повинно бути перешкод до вирізки і вставці даних і після нормалізації. Це здійсненні, якщо є гарантія, що в процесі нормалізації не буде втрати даних.На практиці ідея збереження всіх елементів у базі даних в процесі нормалізації втілюється чисто інтуїтивно. Адже навряд чи будуть сліпо викидати з таблиць елементи даних. Але тим не менш, п'ята нормальна форма покликана застрахувати вас від такого нещасного випадку. [7, 8, 10].
6. Мова SQL як стандартна мова баз даних.
Стрімке зростання популярності SQL є однією з найважливіших тенденцій у сучасній комп'ютерній промисловості. За кілька останніх років SQL став єдиною мовою баз даних. На сьогоднішній день SQL підтримують понад ста СУБД, що працюють як на персональних комп'ютерах, так і на великих ЕОМ. Був прийнятий, а потім доповнено офіційний міжнародний стандарт на SQL. Мова SQL є важливою ланкою в архітектурі систем управління базами даних, що випускаються всіма провідними постачальниками програмних продуктів, і служить стратегічним напрямом розробок компанії Microsoft в галузі баз даних. Зародившись у результаті виконання другорядного дослідницького проекту компанії IBM, SQL сьогодні широко відомий і в якості потужного ринкового фактора. [13]6.1. Мова SQL
Рис. 8. Застосування SQL для доступу до бази даних |
QL є інструментом, призначеним для обробки і читання даних, що містяться в комп'ютерній базі даних. SQL - це скорочена назва структурованого мови запитів (Structured Query Language). Як випливає з назви, SQL є мовою програмування, який застосовується для організації взаємодії користувача з базою даних. Насправді SQL працює тільки з базами даних реляційного типу. На рис. 8 зображена схема роботи SQL. Відповідно до цієї схеми, в обчислювальній системі є база даних, в якій зберігається важлива інформація. Якщо обчислювальна система відноситься до сфери бізнесу, то в базі даних може зберігатися інформація про матеріальні цінності, що випускається продукції, обсяги продажів і зарплати. У базі даних на персональному комп'ютері може зберігатися інформація про виписаних чеках, телефонах і адресах або інформація, що витягує з більш великої обчислювальної системи. Комп'ютерна програма, яка керує базою даних, називається системою управління базою даних, або СУБД.
Якщо користувачеві необхідно прочитати дані з бази даних, він запитує їх у СУБД за допомогою SQL. СУБД обробляє запит, знаходить необхідні дані і посилає їх користувачеві. Процес запрашіванія даних і отримання результату називається запитом до бази даних: звідси й назва - структурований мова запитів.
Однак ця назва не зовсім відповідає дійсності. По-перше, сьогодні SQL представляє собою щось набагато більше, ніж простий інструмент створення запитів, хоча саме для цього він і був спочатку призначений. Незважаючи на те, що читання даних як і раніше залишається однією з найбільш важливих функцій SQL, зараз ця мова використовується для реалізації всіх функціональних можливостей, які СУБД надає користувачеві, а саме:
· Організація даних. SQL дає користувачеві можливість змінювати структуру представлення даних, а також встановлювати відносини між елементами бази даних.
· Читання даних. SQL дає користувачу або додатку можливість читати з бази даних містяться в ній, і користуватися ними.
· Обробка ванних. SQL дає користувачу або додатку можливість змінювати базу даних, тобто додавати в неї нові дані, а також видаляти або обновляти вже наявні в ній дані.
· Управління доступом. За допомогою SQL можна обмежити можливості користувача по читанню і зміні даних і захистити їх від несанкціонованого доступу.
· Спільне використання даних. SQL координує спільне використання даних користувачами, що працюють паралельно, щоб вони не заважали один одному.
· Цілісність даних. SQL дозволяє забезпечити цілісність бази даних, захищаючи її від руйнування через неузгоджені змін або відмови системи.
Таким чином, SQL є достатньо потужним мовою для взаємодії з СУБД.
По-друге, SQL - це не повноцінний комп'ютерний мова типу COBOL, FORTRAN або С. У SQL немає оператора IF для перевірки умов, немає оператора GOTO для організації переходів і немає операторів DO або FOR для створення циклів. SQL є підмовою баз даних, до якого входить близько тридцяти операторів, призначених для управління базами даних. Оператори SQL вбудовуються в базовий мову, наприклад COBOL, FORTRAN або С, і дають можливість отримувати доступ до баз даних. Крім того, з такої мови, як С, оператори SQL можна посилати СУБД в явному вигляді, використовуючи інтерфейс викликів функцій.
Нарешті, SQL - це слабо структурований мову, особливо в порівнянні з такими сильно структурованими мовами, як С або Pascal. Оператори SQL нагадують англійські пропозиції і містять "слова-пустушки", які не впливають на зміст оператора, але полегшують його читання. У SQL майже немає нелогічностей, до того ж є ряд спеціальних правил, що запобігають створення операторів SQL, які виглядають як абсолютно правильні, але не мають сенсу.
Незважаючи на не зовсім точну назву, SQL на сьогоднішній день є єдиним стандартним мовою для роботи з реляційними базами даних. SQL - це досить потужний і в той же час відносно легкий для вивчення мову. [13, 8].
6.2. Переваги SQL
SQL - це легкий для розуміння мову і в той же час універсальне програмний засіб управління даними.Успіх мови SQL принесли наступні його особливості:
• незалежність від конкретних СУБД;
• переносимість з однієї обчислювальної системи на іншу;
• наявність стандартів;
• схвалення компанією IBM (СУБД DB2);
• підтримка з боку компанії Microsoft (протокол ODBC);
• реляційна основа;
• Високорівнева структура, що нагадує англійську мову;
• можливість виконання спеціальних інтерактивних запитів:
• забезпечення програмного доступу до баз даних;
• можливість різного представлення даних;
• повноцінність як мови, призначеного для роботи з базами даних;
• можливість динамічного визначення даних;
• підтримка архітектури клієнт / сервер.
Всі перераховані вище фактори призвели до того, що SQL став стандартним інструментом для управління даними на персональних комп'ютерах, міні-комп'ютерах і великих ЕОМ. Нижче ці фактори розглянуті більш докладно. [13, 8, 17].
6.2.1. Незалежність від конкретних СУБД
Всі провідні постачальники СУБД використовують SQL, і жодна нова СУБД, не підтримуюча SQL, не може розраховувати на успіх. Реляційну базу даних та програми, які з нею працюють, можна перенести з однієї СУБД на іншу з мінімальними доробками і перепідготовкою персоналу. Програмні засоби, що входять до складу СУБД для персональних комп'ютерів, такі як програми для створення запитів, генератори звітів і генератори додатків, працюють з реляційними базами даних багатьох типів. Таким чином, SQL забезпечує незалежність від конкретних СУБД, що є однією з найбільш важливих причин його популярності.6.2.2. Переносимість з однієї обчислювальної системи на інші
Постачальники СУБД пропонують програмні продукти для різних обчислювальних систем: від персональних комп'ютерів і робочих станцій до локальних мереж, міні-комп'ютерів і великих ЕОМ. Програми, створені за допомогою SQL і розраховані на однокористувацькі системи, в міру свого розвитку можуть бути перенесені на більш потужні системи. Інформація з корпоративних реляційних баз даних може бути завантажена в бази даних окремих підрозділів або в особисті бази даних. Нарешті, програми для реляційних баз даних можна спочатку змоделювати на економічних персональних комп'ютерах, а потім перенести на дорогі багатокористувацькі системи.6.2.3. Стандарти мови SQL
Офіційний стандарт мови SQL був опублікований Американським інститутом національних стандартів (American National Standards Institute - ANSI) і Міжнародною організацією по стандартах (International Standards Organization - ISO) в 1986 році і значно розширений у 1992 році. Крім того, SQL є федеральним стандартом США по обробці інформації (FIPS - Federal Information Processing Standard) і, отже, відповідність йому є одним з основних вимог, що містяться у великих урядових контрактах, які стосуються галузі обчислювальної техніки. В Європі стандарт X / OPEN для стерпної середовища програмування на основі операційної системи UNIX включає в себе SQL як стандарт для доступу до баз даних. SQL Access Group - консорціум постачальників комп'ютерного устаткування і баз даних - визначив для SQL стандартний інтерфейс викликів функцій, який є основою протоколу ODBC компанії Microsoft і входить також в стандарт X / OPEN. Ці стандарти є як би офіційною печаткою, що схвалює SQL, і вони прискорили завоювання їм ринку. [13, 8, 17].6.2.4. Схвалення SQL компанією IBM (СУБД DB2)
SQL був придуманий науковими співробітниками компанії IBM і широко використовується нею в безлічі пакетів програмного забезпечення. Підтвердженням цьому служить флагманська СУБД DB2 компанії IBM. Всі основні сімейства комп'ютерів компанії IBM підтримують SQL: система PS / 2 для персональних комп'ютерів, система середнього рівня AS/400. система RS/6000 на базі UNIX, а також операційні системи MVS і VM великих ЕОМ. Широка підтримка SQL фірмою IBM прискорила його визнання і ще на самому початку виникнення і розвитку ринку баз даних стала свого роду недвозначним вказівкою для інших постачальників баз даних і програмних систем, в якому напрямку необхідно рухатися.6.2.5. Протокол ODBC і компанія Microsoft
Компанія Microsoft розглядає доступ до баз даних як важливу частину своєї операційної системи Windows. Стандартом цієї компанії із забезпечення доступу до баз даних є ODBC (Open Database Connectivity - взаємодія з відкритими базами даних) - програмний інтерфейс, заснований на SQL. Протокол ODBC підтримується найбільш поширеними додатками Windows (електронними таблицями, текстовими процесорами, базами даних тощо), розробленими як самою компанією Microsoft, так і іншими провідними постачальниками. Підтримка ODBC забезпечується всіма провідними реляційними базами даних. Крім того, ODBC спирається на стандарти, схвалені консорціумом постачальників SQL Access Group, що робить ODBC як стандартом де-факто компанії Microsoft, так і стандартом, незалежним від конкретних СУБД. [13, 8, 17].6.2.6. Реляційна основа
SQL є мовою реляційних баз даних, тому він став популярним тоді, коли популярною стала реляційна модель представлення даних. Таблична структура реляційної бази даних інтуїтивно зрозуміла користувачам, тому мова SQL є простим і легким для вивчення. Реляційна модель має солідний теоретичний фундамент, на якому були засновані еволюція і реалізація реляційних баз даних. На хвилі популярності, викликаної успіхом реляційної моделі, SQL став єдиною мовою для реляційних баз даних. [13, 8, 17].6.2.7. Високорівнева структура, що нагадує англійську мову
Оператори SQL виглядають як звичайні англійські пропозиції, що спрощує їх вивчення та розуміння. Частково це обумовлено тим, що оператори SQL описують дані, які необхідно отримати, а не визначають спосіб їх пошуку. Таблиці та стовпці в реляційної бази даних можуть мати довгі описові імена. У результаті більшість операторів SQL означають саме те, що точно відповідає їх іменами, тому їх можна читати як прості, зрозумілі пропозиції.6.2.8. Інтерактивні запити
SQL є мовою інтерактивних запитів, який забезпечує користувачам негайний доступ до даних. За допомогою SQL користувач може в інтерактивному режимі отримати відповіді на найскладніші запити в лічені хвилини або секунди, тоді як програмісту потрібні були б дні або тижні, щоб написати для користувача відповідну програму. Через те, що SQL допускає негайні запити, дані стають більш доступними і можуть допомогти у прийнятті рішень, роблячи їх більш обгрунтованими. [13, 8, 17].6.2.9. Програмний доступ до бази даних
Програмісти користуються мовою SQL, щоб писати програми, в яких містяться звернення до баз даних. Одні й ті ж оператори SQL використовуються як для інтерактивного, так і для програмного доступу, тому частини програм, що містять звернення до бази даних, можна спочатку тестувати в інтерактивному режимі, а потім вбудовувати в програму. У традиційних базах даних для програмного доступу використовуються одні програмні засоби, а для виконання негайних запитів - інші, без будь-якої зв'язку між цими двома режимами доступу. [13, 8, 17].6.2.10. Різні представлення даних
За допомогою SQL творець бази може зробити так, що різні користувачі бази даних будуть бачити різні представлення її структури та вмісту. Наприклад, базу даних можна спроектувати таким чином, що кожен користувач буде бачити тільки дані, пов'язані з його підрозділу або торговому регіону. Крім того, дані з різних частин бази даних можуть бути скомбіновані і представлені користувачеві у вигляді однієї простої таблиці. Отже, уявлення можна використовувати для посилення захисту бази даних та її настройки під конкретні вимоги окремих користувачів. [13, 8, 17].6.2.11. Повноцінний мову для роботи з базами даних
Спочатку SQL був задуманий як мова інтерактивних запитів, але зараз він вийшов далеко за рамки читання даних. SQL є повноцінним і логічним мовою, призначеним для створення бази даних, управління її захистом, зміни її вмісту, читання даних і спільного використання даних декількома користувачами, що працюють паралельно. Прийоми, освоєні при вивченні одного розділу мови, можуть потім застосовуватися в інших командах, що підвищує продуктивність роботи користувачів. [13, 8, 17].6.2.12. Динамічне визначення даних
За допомогою SQL можна динамічно змінювати і розширювати структуру бази даних навіть в той час, коли користувачі звертаються до її вмісту. Це велика перевага перед мовами статичного визначення даних, які забороняють доступ до бази даних під час зміни її структури. Таким чином, SQL забезпечує максимальну гнучкість, так як дає базі даних можливість адаптуватися до мінливих вимог, не перериваючи роботу програми, що виконується в реальному масштабі часу. [13, 8, 17].6.2.13. Архітектура клієнт / сервер
SQL - природний засіб для реалізації додатків клієнт / сервер. У цій ролі SQL служить сполучною ланкою між клієнтською системою, що взаємодіє з користувачем, і серверної системою, що управляє базою даних, дозволяючи кожній системі зосередитися на виконанні своїх функцій. Крім того, SQL дозволяє персональним комп'ютерам функціонувати в якості клієнтів по відношенню до мережевих серверів або більше великим баз даних, встановленим на великих ЕОМ; це дозволяє отримувати доступ до корпоративних даних з додатків, що працюють на персональних комп'ютерах. [13, 8, 17].7. Архітектури баз даних
Для розгляду способів організації баз даних потрібно визначити кілька понять.Ядро БД відповідає за управління даними у зовнішній пам'яті, управління буферами оперативної пам'яті, управління транзакціями і журналізацію. Відповідно, можна виділити такі компоненти ядра (принаймні, логічно, хоча в деяких системах ці компоненти виділяються явно), як менеджер даних, менеджер буферів, менеджер транзакцій. Ядро БД володіє власним інтерфейсом, не доступним користувачам прямо та використовуються в програмах, вироблених компілятором SQL і утилітах БД. Ядро БД є основною резидентної частиною СУБД. При використанні архітектури "клієнт-сервер" ядро є основною складовою серверної частини системи.
Основною функцією компілятора мови БД є компіляція операторів мови БД в деяку виконувану програму.
В окремі утиліти БД звичайно виділяють такі процедури, які занадто накладно виконувати з використанням мови БД, наприклад, завантаження і вивантаження БД, збір статистики, глобальна перевірка цілісності БД і т.д. Утиліти програмуються з використанням інтерфейсу ядра БД, а іноді навіть з проникненням всередину ядра.
Додаток |
Невізуальні компоненти для роботи з БД |
Візуальні компоненти для роботи з БД |
База даних |
Ядро БД |
Рис. 10. Загальний склад засобів для роботи готового додатку з БД. |
База даних |
Ядро БД |
Додаток для роботи з БД |
Комп'ютер користувача |
Рис. 11. Однокористувальницька архітектура при роботі з локальними БД |
Загальний склад коштів, необхідних для роботи готового додатку з БД, показаний на рис. 10. Відповідно до цієї загальній схемі, ми маємо ланцюжок
Додаток -> Ядро БД -> бази даних. У структурі програми є ланцюжок Невізуальні компоненти -> Візуальні компоненти. Невізуальні компоненти надають програмісту деякі функції з управління ядром бази даних, а також самими даними. За допомогою Візуальних компонент дані відображаються на екрані (таблиці, списки, списки, що випадають, графіки та ін.) Розташування ядра БД і самих баз даних у цьому ланцюжку не відображені.
Розташування Ядра БД і баз даних залежить від використовуваної архітектури. Є чотири різновиди архітектур баз даних:
• локальні бази даних; 'архітектура "файл-сервер";
• архітектура "клієнт-сервер";
• многозвенная (трехзвенная N-tier або multi-tier) архітектура.
Використання тієї або іншої архітектури накладає сильний відбиток на загальну ідеологію роботи програми, на програмний код в додатку, на склад компонентів для роботи з БД, що використовуються в додатку (насамперед це стосується невізуальних компонентів). [4, 15].
7.1. Локальні бази даних та архітектура "файл-сервер"
При роботі з локальними базами даних самі БД розташовані на тому ж комп'ютері, що і додатки, що здійснюють доступ до них. Робота з БД відбувається в режимі одного користувача. Ядро БД розташувався на комп'ютері користувача. Додаток відповідально за підтримку цілісності БД та за виконання запитів до БД. Загальна схема однокористувальницької архітектури показана на рис. 11. Додаток для роботи з БД |
Комп'ютер користувача |
Ядро БД |
Копія бази даних |
База даних |
Мережевий сервер |
Рис. 12. Архітектура "Файл-Сервер" |
Додаток для роботи з БД (Клієнт) |
Ядро БД |
Комп'ютер користувача |
База даних |
Сервер бази даних |
Віддалений сервер |
Рис. 13. Архітектура "Клієнт-Сервер" |
При роботі в архітектурі "файл-сервер" БД і додаток розташовані на файловому сервері мережі (наприклад, Novell NetWare). Можлива багатокористувацька робота з однією і тією ж БД, коли кожен користувач зі свого комп'ютера запускає додаток, розташоване на мережевому сервері. Тоді на комп'ютері користувача запускається копія додатку. По кожному запиту до БД з додатку дані з таблиць БД переганяються на комп'ютер користувача, незалежно від того, скільки реально потрібно даних для виконання запиту. Після цього виконується запит.
Кожен користувач має на своєму комп'ютері локальну копію даних, час від часу оновлюваних з реальної БД, розташованої на мережевому сервері. При цьому зміни, які кожен користувач вводить в БД, можуть бути до певного моменту невідомі іншим користувачам, що робить актуальним завдання систематичного оновлення даних на комп'ютері користувача з реальної БД. Іншою актуальною задачею є блокування записів, які змінюються одним з користувачів: це необхідно для того, щоб в цей час інший користувач не вніс змін у ті ж дані. В архітектурі "файл-сервер" весь тягар виконання запитів до БД р, управління цілісністю БД лягає на додаток користувача. БД та сервері є пасивним джерелом даних. Загальна схема архітектуру "файл-сервер" показана на рис. 12.
Кардинальних відмінностей з точки зору архітектури між однокористувальницької архітектурою та архітектурою "файл-сервер" немає. І в тому. і в іншому випадку в якості СУБД застосовуються так звані "персональні" (або "локальні") СУБД. такі як Paradox, dBase та ін Сама база даних в цьому випадку представляє собою набір таблиць, індексних файлів, файлів полів коментарів (мемо-полів) та ін, що зберігаються в одному каталозі на диску у вигляді окремих файлів. [4].
7.2. Віддалені бази даних та архітектура "клієнт-сервер"
Архітектура "файл-сервер" неефективна, принаймні, у двох відносинах:1. При виконанні запиту до бази даних, розташованої на файловому сервері, в дійсності відбувається запит до локальної копії даних на комп'ютері користувача. Тому перед виконанням запиту дані в локальній копії оновлюються з реальної БД. Дані оновлюються у повному обсязі. Так, якщо таблиця БД складається з 1000 записів, а для виконання запиту (наприклад, видати суму премій за жовтень у відділі Y) реально потрібно 10 записів, все одно переганяються всі 1000 записів. Таким чином, не потрібно мати дуже багато користувачів і запитів від них, щоб серйозно''забити "мережа, що, звичайно ж, не може не позначитися на її швидкодії.
2. Забезпечення цілісності БД проводиться з додатків. Це потенційне джерело помилок, що порушують фізичну і логічну цілісність БД, оскільки різні додатки можуть проводити контроль цілісності БД по-різному, взаємовиключними способами, або не проводити такого контролю зовсім. Набагато ефективніше керувати БД з єдиного місця і за єдиними законами, ніж з різних додатків і по потенційно різними законами (все залежить від того, як написано додаток). Тому безпека при роботі в архітектурі "файл-сервер" невисока і завжди присутній елемент невизначеності. Секретність і конфіденційність при роботі з БД в архітектурі "файл-сервер" забезпечити також важко - будь-який, хто має доступ до каталогу мережевого сервера, де зберігається БД, може змінювати таблиці БД будь-яким чином, копіювати їх, замінювати і т.д. [4].
Архітектура "клієнт-сервер" поділяє функції програми користувача (званого клієнтом) і сервера (Мал. 13.).
Додаток-клієнт формує запит до сервера, на якому розташована БД, на структурному мовою запитів SQL. Віддалений сервер приймає запит і переадресує його SQL-серверу БД. SQL-сервер - це спеціальна програма, що керує віддаленою базою даних. SQL-сервер забезпечує інтерпретацію запиту, його виконання в базі даних. формування результату виконання запиту та видачу його додатку-клієнту. При цьому ресурси клієнтського комп'ютера не беруть участь у фізичному виконанні запиту; клієнтський комп'ютер лише відсилає запит до серверної БД і отримує результат, після чого інтерпретує його необхідним чином і надає користувачеві. Так як клієнтського додатку надсилається результат виконання запиту, по мережі "подорожують" тільки ті дані, які необхідні клієнтові. У результаті знижується навантаження на мережу. Оскільки виконання запиту відбувається там же, де зберігаються дані (на сервері), немає необхідності в пересиланні великих пакетів даних. Крім того, SQL-сервер, якщо це можливо, оптимізує отриманий запит таким чином, щоб він був виконаний у мінімальний час з найменшими накладними витратами.
Все це підвищує швидкодію системи і знижує час очікування результату запиту.
При виконанні запитів сервером істотно підвищується ступінь безпеки даних, оскільки правила цілісності даних визначаються в базі даних на сервері і є єдиними для всіх додатків, що використовують цю БД. Таким чином, виключається можливість визначення суперечливих правил підтримки цілісності. Потужний апарат транзакцій, підтримуваний SQL-серверами, дозволяє виключити одночасна зміна одних і тих же даних різними користувачами та надає можливість відкатів до первинних значень при внесенні до БД змін, що закінчилися аварійно. Таким чином, функціями програми-клієнта є:
1. посилка до сервера запитів;
2. інтерпретація результатів запитів, отриманих від сервера, і представлення їх користувачеві в необхідній формі;
3. реалізація інтерфейсу користувача.
SQL-сервер - це програма, розташована на комп'ютері мережного сервера. SQL-сервер повинен бути завантажений на момент прийняття запиту від клієнта. Функціями сервера БД є:
1. прийом запитів від додатків-клієнтів, інтерпретація запитів, виконання запитів до БД, відправка результату виконання запиту додатку-клієнту;
2. управління цілісністю БД, забезпечення системи безпеки, блокування невірних дій додатків-клієнтів;
3. зберігання бізнес-правил, часто використовуваних запитів у вже інтерпретованому вигляді;
4. забезпечення одночасно безпечної і відмовостійкої роботи багатьох користувачів з одними і тими ж даними. В архітектурі "клієнт-сервер" використовуються так звані "віддалені" (або "промислові") СУБД. Промисловими вони називаються через те. що саме СУБД цього класу можуть забезпечити роботу інформаційних систем масштабу середнього і великого підприємства, організації, банку. Локальні СУБД призначені для однокористувальницької роботи або для забезпечення роботи інформаційних систем, розрахованих на невеликі групи користувачів. [4, 15, 11].
До розрядку промислових СУБД належать: Oracle, Gupta, Informix, Sybase, MS SQL Server, DB2, InterBase і ряд інших.
Як правило, SQL-сервер управляється окремим співробітником або групою співробітників (адміністратори SQL-сервера). Вони управляють фізичними характеристиками баз даних, виробляють оптимізацію, настройку і перевизначення різних компонентів БД, створюють нові БД, змінюють існуючі і т.д., а також видають привілеї (дозволу на доступ певного рівня до конкретних БД, SQL-серверу) різним користувачам.
Крім цього, існує окрема категорія співробітників, званих адміністраторами баз даних. Як правило, це адміністратори сервера, розробники БД або користувачі, що мають привілеї на створення, зміна, налаштування оптимальних параметрів окремих серверних БД-Адміністратори БД також відповідають за надання прав на різнорівневий доступ до супроводжуваним ними БД для інших користувачів. [4, 15, 11 ].
Використання архітектури "клієнт-сервер":
1. різко зменшує мережевий трафік:
2. знижує складність додатків-клієнтів (оскільки тим вже немає необхідності забезпечувати цілісність і безпеку БД і стежити за параметрами роботи багатьох користувачів з БД);
3. знижує вимоги до апаратних засобів, на яких ці програми функціонують (тобто до комп'ютерів користувачів-клієнтів):
4. підвищує надійність БД, її цілісність, безпеку і секретність.
8. Середовище Delphi як засіб для розробки СУБД
Оскільки використання баз даних є одним з наріжних каменів, на яких побудовано існування різних організацій, пильну увагу розробників додатків баз даних викликають інструменти, за допомогою яких такі програми можна було б створювати. Висунуті до них вимоги у загальному вигляді можна сформулювати як: "швидкість, простота, ефективність, надійність".Серед великої різноманітності продуктів для розробки додатків Delphi займає одне з провідних місць. Delphi віддають перевагу розробники з різним стажем, звичками, професійними інтересами. За допомогою Delphi написано колосальну кількість додатків, десятки фірм і тисячі програмістів-одинаків розробляють для Delphi додаткові компоненти. [4].
В основі такої загальновизнаної популярності лежить той факт, що Delphi, як ніяка інша система програмування, задовольняє викладеним вище вимогам. Дійсно, застосування за допомогою Delphi розробляються швидко, причому взаємодія розробника з інтерактивним середовищем Delphi не викликає внутрішнього відторгнення, а навпаки, залишає відчуття комфорту. Delphi-додатки ефективні, якщо розробник дотримується певні правила (і часто - якщо не дотримується). Ці додатки надійні і при експлуатації мають передбачуваним поведінкою. [4, 22].
Пакет Delphi - продовження лінії компіляторів мови Pascal корпорації Borland. Pascal як мова дуже простий, а суворий контроль типів даних сприяє ранньому виявленню помилок і дозволяє швидко створювати надійні та ефективні програми. Корпорація Borland постійно збагачувала мову. Колись у версію 4.0 були включені засоби роздільної трансляції, пізніше, починаючи з версії 5.5, з'явилися об'єкти, а до складу шостої версії пакету увійшла повноцінна бібліотека класів Turbo Vision, що реалізує віконну систему в текстовому режимі роботи відеоадаптера. Це був один з перших продуктів, які містили інтегроване середовище розробки програм.
У класі інструментальних засобів для початківців програмістів продуктів компанії Borland довелося конкурувати з середовищем Visual Basic корпорації Microsoft, де питання інтеграції та зручності роботи були вирішені краще. Коли на початку 70-х років Н. Вірт опублікував повідомлення про Pascal, це був компактний, з невеликою кількістю основних понять і зарезервованих слів мова програмування, націлений на навчання студентів. Мова, на якому належить працювати користувачеві Delphi, відрізняється від вихідного не тільки наявністю безлічі нових понять і конструкцій, а й ідейно: у ньому замість мінімізації числа понять і використання найпростіших конструкцій (що, безумовно, добре для навчання, але не завжди виправдане в практичній роботі), перевага віддається зручності роботи професійного користувача. Як мова Turbo Pascal природно порівнювати з його найближчими конкурентами - численними варіаціями на тему мови Basic (у першу чергу з Visual Basic корпорації Microsoft) і з C + +. [4, 6]. Я вважаю, що Turbo Pascal істотно перевершує Basic за рахунок повноцінного об'єктного підходу, що включає в себе розвинуті механізми інкапсуляції, успадкування і поліморфізм. Остання версія мови, що застосовується в Delphi, за своїми можливостями наближається до C + +. З основних механізмів, властивих C + +, відсутній тільки множинне спадкування. (Втім, цим красивим і потужним механізмом породження нових класів користується лише невелика частина програмістів, які пишуть на С + +.) Плюси застосування мови Pascal очевидні: з одного боку, на відміну від Visual Basic, заснованого на інтерпретації проміжного коду, для нього є компілятор , що генерує машинний код, що дозволяє отримувати значно більш швидкі програми. З іншого - на відміну від C + + синтаксис мови Pascal сприяє побудові дуже швидких компіляторів. [6].
Середовище програмування нагадує пакет Visual Basic. У вашому розпорядженні декілька окремих вікон: меню та інструментальні панелі, Object Inspector (у якому можна бачити властивості об'єкта та пов'язані з ним події), вікна візуального будівника інтерфейсів (Visual User Interface Builder), Object Browser (що дозволяє вивчати ієрархію класів і переглядати списки їх полів, методів і властивостей), вікна управління проектом (Project Manager) і редактора.
Delphi містить повноцінний текстовий редактор типу Brief, призначення клавіш у якому відповідають прийнятим у Windows стандартам, а глибина ієрархії операцій Undo необмежена. Як це стало вже обов'язковим, реалізовано колірне виділення різних лексичних елементів програми. Процес побудови програми досить простий. Потрібно вибрати форму (у поняття форми входять звичайні, діалогові, батьківські і дочірні вікна MDI), задати її властивості і включити в неї необхідні компоненти (видимі і, якщо знадобиться, неотображаемие): меню, інструментальні панелі, рядок стану і т. п. , задати їх властивості і далі написати (за допомогою редактора вихідного коду) обробники подій. Object Browser Вікна типу Object Browser стали невід'ємною частиною систем програмування на об'єктно-орієнтованих мовах. Робота з ними стає можливою відразу після того, як ви скомпілював додаток.
Projeсt Manager - це окреме вікно, де перераховуються модулі і форми, які утворюють проект. При кожному модулі вказується маршрут до каталогу, в якому знаходиться вихідний текст. Жирним шрифтом виділяються змінені, але ще не збережені частини проекту. У верхній частині вікна є набір кнопок: додати, видалити, показати вихідний текст, показати форму, задати опції і синхронізувати вміст вікна з текстом файлу проекту, тобто з головним програмою на мові Pascal.
Опції, включаючи режими компіляції, задаються для всього проекту в цілому. У цьому відношенні традиційні make-файли, використовувані в компіляторах мови C, значно більш гнучкі.
Visual Component Library (VCL) Багатство палітри об'єктів для побудови користувацького інтерфейсу - один з ключових чинників при виборі інструмента візуального програмування. При цьому для користувача має значення як число елементів, включених безпосередньо в середу, так і доступність елементів відповідного формату на ринку. [4, 22].
8.1. Високопродуктивний компілятор в машинний код
Компілятори мови Pascal компанії Borland ніколи не змушували користувача подовгу чекати результатів компіляції. Виробники стверджують, що на сьогодні даний компілятор - найшвидший у світі. Компілятор, вбудований в Delphi дозволяє обробляти 120 тис. рядків вихідного тексту в хвилину на машині 486/33 або 350 тис. - при використанні процесора Pentium/90. Він пропонує легкість розробки і швидкий час перевірки готового програмного блоку, характерного для мов четвертого покоління (4GL) і в той же час забезпечує якість коду, характерного для компілятора 3GL. Крім того, Delphi забезпечує швидку розробку без необхідності писати вставки на Сі чи ручного написання коду (хоча це можливо).У сенсі проектування Delphi мало чим відрізняється від проектування в интерпретирующей середовищі, проте після виконання компіляції ми отримуємо код, який виконується в 10-20 разів швидше, ніж теж саме, зроблене за допомогою інтерпретатора. Крім того, компілятор компілятору ворожнечу, в Delphi компіляція проводиться безпосередньо у рідній машинний код, в той час як існують компілятори, що перетворюють програму у так званий p-код, який потім інтерпретується віртуальною p-машиною. Це не може не позначитися на фактичному швидкодії готового додатку.
По всій імовірності, така висока швидкість пояснюється в першу чергу відмовою від демонстрації в процесі роботи числа скомпільованих рядків. Слід відзначити також, що завдяки опції оптимізації сегментів вдається істотно скоротити розмір виконуваного файлу. Можна запустити компілятор в режимі перевірки синтаксису. При цьому найбільш тривала операція компонування і виготовлення виконуваного файлу виконуватися не буде.
Ймовірно, та обставина, що Delphi позиціонується як засіб створення додатків, взаємодіючих з базами даних, і орієнтоване переважно на ринок інструментальних засобів клієнт / сервер, де до цього моменту домінують інтерпретуються, дозволило його авторам не замислюватися над створенням оптимизирующего компілятора, здатного використовувати всі гідності архітектур сучасних процесорів. [22].
8.2. Потужний об'єктно-орієнтована мова
Сумісність з програмами, створеними раніше засобами Borland Pascal, зберігається, незважаючи на те, що в мову внесені істотні зміни. Необхідність у деяких удосконаленнях давно відчувалася. Найпомітніше з них - апарат виняткових ситуацій, подібний до того, що мається на C + +, був першим реалізований в компіляторах корпорації Borland. Не секрет, що при написанні об'єктно-орієнтованих програм, що активно працюють з динамічною пам'яттю і іншими ресурсами, чималу трудність представляє акуратне звільнення цих ресурсів у разі виникнення нештатних ситуацій. Особливо це актуально для середовища Windows, де кількість видів ресурсів досить велике, а неохайна робота з ними може швидко привести до зависання всієї системи. Передбачений в Delphi апарат винятків максимально спрощує кодування обробки позаштатних ситуацій та звільнення ресурсів.Об'єктно-орієнтований підхід у новій версії мови набув значного розвитку. Перерахуємо основні нововведення.
- Введено поняття класу.
· Реалізовані методи класів, аналогічні статичним методам C + +. Вони оперують не екземпляром класу, а самим класом.
· Механізм інкапсуляції багато в чому вдосконалений. Введено захищені поля і методи, які, подібно приватним, не видно ззовні, але відрізняються від них тим, що доступні з методів класу-спадкоємця.
· Введена обробка виняткових ситуацій. У Delphi це влаштовано в стилі С + +. Винятки представлені у вигляді об'єктів, що містять специфічну інформацію про відповідну помилку (тип і місце-знаходження помилки). Розробник може залишити обробку помилки, що існувала за замовчуванням, або написати свій власний обробник. Обробка винятків реалізована у вигляді exception-handling blocks (також ще називається protected blocks), які встановлюються ключовими словами try і end. Існують два типи таких блоків: try ... except і try ... finally.
· З'явилося кілька зручних синтаксичних конструкцій, в числі яких перетворення типу об'єкта з контролем коректності (у разі невдачі ініціюється виняток) та перевірка об'єкта на приналежність класу.
· Посилання на класи надають додатковий рівень гнучкості, так, коли ви хочете динамічно створювати об'єкти, чиї типи можуть бути відомі лише під час виконання коду. Наприклад, посилання на класи використовуються при формуванні користувачем документа з різного типу об'єктів, де користувач набирає потрібні об'єкти з меню або палітри. Власне, ця технологія використовувалася і при побудові Delphi.
· Введено засіб, відоме як механізм делегування. Під делегуванням розуміється те, що якийсь об'єкт може надати іншому об'єкту відповідати на деякі події. Він використовується в Delphi для спрощення програмування подієво-орієнтованих частин програм, тобто для користувача інтерфейсу і всіляких процедур, що запускаються у відповідь на маніпуляції з базою даних.
Після того як Borland внесла перераховані зміни, вийшов потужний об'єктно-орієнтована мова, можна порівняти за своїми можливостями з C + +. Платою за нові функції стало значне підвищення вимог до професійної підготовки програміста.
Мова програмування Delphi базується на Borland Object Pascal.
Крім того, Delphi підтримує такі низькорівневі особливості, як підкласи елементів керування Windows, перекриття циклу обробки повідомлень Windows, використання вбудованого асемблера. [22].
8.3. Об'єктно-орієнтована модель програмних компонент
Основний упор цієї моделі в Delphi робиться на максимальному повторному використанні коду. Це дозволяє розробникам будувати програми досить швидко з заздалегідь підготовлених об'єктів, а також дає їм можливість створювати свої власні об'єкти для середовища Delphi. Ніяких обмежень по типах об'єктів, які можуть створювати розробники, не існує. Дійсно, все в Delphi написано на ньому ж, тому розробники мають доступ до тих же об'єктів та інструментів, які використовувалися для створення середовища розробки. У результаті немає ніякої різниці між об'єктами, що поставляються Borland або третіми фірмами, і об'єктами, які ви можете створити.У стандартну поставку Delphi входять основні об'єкти, які утворюють вдало підібрану ієрархію з 270 базових класів. На Delphi можна однаково добре писати як додатки до корпоративних баз даних, так і, наприклад, ігрові програми. Багато в чому це пояснюється тим, що традиційно в середовищі Windows було досить складно реалізовувати користувальницький інтерфейс. Подієва модель в Windows завжди була складна для розуміння і налагодження. Але саме розробка інтерфейсу в Delphi є найпростішим завданням для програміста.
Завдяки такій можливості програми, виготовлені за допомогою Delphi, працюють надійно і стійко. Delphi підтримує використання вже існуючих об'єктів, включаючи DLL, написані на С і С + +, OLE сервера, VBX, об'єкти, створені за допомогою Delphi. З готових компонент працюючі додатки збираються дуже швидко. Крім того, оскільки Delphi має повністю об'єктну орієнтацію, розробники можуть створювати свої повторно використовувані об'єкти для того, щоб зменшити витратах на розробку.
Delphi пропонує розробникам - як у складі команди, так і індивідуальним - відкриту архітектуру, що дозволяє додавати компоненти, де б вони не були виготовлені, і оперувати цими нововведеними компонентами у візуальному побудувачеві. Розробники можуть додавати CASE-інструменти, кодові генератори, а також авторські help'и, доступні через меню Delphi. [22].
8.4. Бібліотека візуальних компонент
Компоненти, що використовуються при розробці в Delphi, вбудовані в середовище розробки додатків і вдають із себе набір типів об'єктів, використовуваних як фундаменту при будівництві додатки.Цей кістяк називається Visual Component Library (VCL). У VCL є такі стандартні елементи управління, як рядки редагування, статичні елементи керування, рядки редагування зі списками, списки об'єктів. Ще є такі компоненти, які раніше були доступні тільки в бібліотеках третіх фірм: табличні елементи управління, закладки, багатосторінкові записні книжки. Всі об'єкти розбиті на сторінки по своїй функціональності і представлені в палітрі компонент.
VCL містить спеціальний об'єкт, предоставлющій інтерфейс графічних пристроїв Windows, і дозволяє розробникам малювати, не піклуючись про звичайні для програмування в середовищі Windows деталях.
Ключовою особливістю Delphi є можливість не тільки використовувати візуальні компоненти для будівництва додатків, але і створення нових компонентів. Така можливість дозволяє розробникам не переходити в інше середовище розробки, а навпаки, вбудовувати нові інструменти в існуючу середу. Крім того, можна поліпшити або повністю замінити існуючі за умовчанням в Delphi компоненти.
Тут слід зазначити, що звичайних обмежень, властивих середах візуальної розробки, в Delphi немає. Сам Delphi написаний за допомогою Delphi, що говорить про відсутність таких обмежень.
TMainMenu дозволяє помістити головне меню у програмі. При приміщенні TMainMenu на форму це виглядає, як просто іконка. Іконки такого типу називають невізуальні компонентом, оскільки вони невидимі під час виконання програми.
За допомогою останніх чотирьох компонент (TFileListBox, TDirectoryListBox, TDriveComboBox, TFilterComboBox) можна побудувати свій власний діалог вибору файлу, причому для цього не потрібно буде написати жодного рядка коду.
TOLEContainer - контейнер, що містить OLE об'єкти. Підтримується OLE 2.02
8.5. Форми, модулі та метод розробки "Two-Way Tools"
Форми - це об'єкти, в які поміщаються інші об'єкти для створення призначеного для користувача інтерфейсу будь-якого додатку. Модулі складаються з коду, який реалізує функціонування програми, обробники подій для форм і їх компонент.Інформація про форми зберігається у двох типах файлів -. Dfm і. Pas, причому перший тип файлу - двійковий - зберігає образ форми і її властивості, другий тип описує функціонування обробників подій і поведінку компонент. Обидва файли автоматично синхронізуються Delphi, так що якщо додати нову форму проект, пов'язаний з ним файл. Pas автоматично буде створений, і його ім'я буде додано до проекту.
Така синхронізація і робить Delphi two-way-інструментом, забезпечуючи повну відповідність між кодом і візуальним поданням. Як тільки додається новий об'єкт або код, Delphi встановлює т.зв. "Кодову синхронізацію" між візуальними елементами і відповідними їм кодовими уявленнями.
Two-way tools - однозначна відповідність між візуальним проектуванням і класичним написанням тексту програми Це означає, що розробник завжди може бачити код, відповідний тому, що він побудував за допомогою візуальних інструментів і навпаки.
Візуальний будівник інтерфейсів (Visual User-interface builder) дає можливість швидко створювати клієнт-серверні додатки візуально, просто вибираючи компоненти з відповідної палітри. У процесі побудови програми розробник вибирає з палітри компонент готові компоненти як художник, що робить великі мазки пензлем. Ще до компіляції він бачить результати своєї роботи - після підключення до джерела даних їх можна бачити відображеними на формі, можна переміщатися за даними, представляти їх у тому чи іншому вигляді. [4, 22].
8.6. Масштабовані кошти для побудови баз даних
Потужність і гнучкість Delphi при роботі з базами даних заснована на низькорівневої ядрі - процесорі баз даних Borland Database Engine (BDE). Його інтерфейс з прикладними програмами називається Integrated Database Application Programming Interface (IDAPI). У принципі, зараз не розрізняють ці дві назви (BDE і IDAPI) і вважають їх синонімами. BDE дозволяє здійснювати доступ до даних, як з використанням традиційного record-орієнтованого (навігаційного) підходу, так і з використанням set-орієнтованого підходу, що використовується в SQL-серверах баз даних. Крім BDE, Delphi дозволяє здійснювати доступ до баз даних, використовуючи технологію (і, відповідно, драйвери) Open DataBase Connectivity (ODBC) фірми Microsoft. Але, як показує практика, продуктивність систем з використанням BDE набагато вище, ніж оних при використанні ODBC. ODBC драйвера працюють через спеціальний "ODBC socket", який дозволяє вбудовувати їх в BDE.Всі інструментальні засоби баз даних Borland - Paradox, dBase, Database Desktop - використовують BDE. Всі особливості, наявні в Paradox або dBase, "успадковуються" BDE, і тому цими ж особливостями володіє і Delphi.
Бібліотека об'єктів містить набір візуальних компонент, значно спрощують розробку додатків для СУБД з архітектурою клієнт-сервер. Об'єкти інкапсулюють у себе нижній рівень - Borland Database Engine.
Передбачено спеціальні набори компонент, що відповідають за доступ до даних, і компонент, що відображають дані. Компоненти доступу до даних дозволяють здійснювати з'єднання з БД, робити вибірку, копіювання даних, і т.п.
Компоненти візуалізації даних дозволяють відображати дані вигляді таблиць, полів, списків. Відображені дані можуть бути текстового, графічного або довільного формату.
Таблиці зберігаються в базі даних. Деякі СУБД зберігають базу даних у вигляді декількох окремих файлів, що представляють собою таблиці (в основному, всі локальні СУБД), у той час як інші складаються з одного файлу, який містить у собі всі таблиці та індекси (InterBase). Наприклад, таблиці dBase і Paradox завжди зберігаються в окремих файлах на диску. Директорій, що містить dBase. DBF файли або Paradox. DB файли, розглядається як база даних. Іншими словами, будь-директорій, що містить файли у форматі Paradox або dBase, розглядається Delphi як єдина база даних. Для перемикання на іншу базу даних потрібно просто перемкнутися на інший директорій. InterBase зберігає всі таблиці в одному файлі, що має розширення. GDB, тому цей файл і є база даних InterBase.
Об'єкти БД в Delphi засновані на SQL і включають в себе повну міць Borland Database Engine. До складу Delphi також включено Borland SQL Link, тому доступ до СУБД Oracle, Sybase, Informix і InterBase відбувається з високою ефективністю. Крім того, Delphi включає в себе локальний сервер Interbase для того, щоб можна було розробити розгортаються на будь-які зовнішні SQL-сервера програми в офлайновом режимі. Розробник в середовищі Delphi, який проектує інформаційну систему для локальної машини (наприклад, невелику систему обліку медичних карток для одного комп'ютера), може використовувати для зберігання інформації файли формату. Dbf (як в dBase або Clipper) або. Db (Paradox). Якщо ж він буде використовувати локальний InterBase for Windows 4.0 (це локальний SQL-сервер, що входить в постачання), то його застосування без жодних змін буде працювати і в складі великої системи з архітектурою клієнт-сервер.
Масштабованість на практиці - одне і те ж додаток можна використовувати як для локального, так і для більш серйозного клієнт-серверного варіантів. [4, 22].
До складу пакету Delphi також входить безліч утиліт для роботи і управління базами даних. Ось деякі з них.
WISQL (Windows Interactive SQL) - інтерактивний засіб посилки SQL-запитів до InterBase (у тому числі і локального InterBase), що входить у поставку Delphi, дозволяє створювати таблиці - через посилку SQL-запитів.
InterBase - це система управління реляційними базами даних, що поставляється корпорацією BORLAND для побудови додатків з архітектурою клієнт-сервер довільного масштабу: від мережного середовища невеликої робочої групи з сервером під управлінням Novell NetWare або Windows NT на базі IBM PC до інформаційних систем крупного підприємства на базі серверів IBM, Hewlett-Packard, SUN і т.п.
У пакет Delphi входить однокористувальницька версія InterBase для Windows - Local InterBase. Використовуючи Local InterBase можна створювати і відлагоджувати додатки, що працюють з даними за схемою клієнт-сервер, без підключення до цього сервера. Надалі буде потрібно тільки переналаштувати використовуваний псевдонім бази даних і програма буде працювати з реальною базою без перекомпіляції. Крім того, Local InterBase можна використовувати у програмах для роботи з даними замість таблиць Paradox.
Важливою складовою частиною програми є виведення даних на друк - отримання звіту. У пакет Delphi входить засіб для генерації та друку звітів - ReportSmith. Ви можете об'єднати звіт з додатками Delphi. Також, бібліотека візуальних компонент Delphi включає спеціальний компонент TReport. У даному уроці показано, як використовувати компоненту TRepor і розглянуті основні принципи проектування звітів у ReportSmith.
Borland ReportSmith є інструментом для отримання звітів і інтегрований в середу Delphi. Звіт може бути доданий до додатків Delphi. Звіти можуть бути створені для SQL БД або локальних БД і не вимагають знання складних команд БД. Інтерфейс ReportSmith використовує стандартні інструменти Windows типу tool bar, formatting ribbon, і "drag and drop". Якщо користувач вже знайомий з інтерфейсом стандартних Windows-програм, типу Word for Windows або Quattro Pro for Windows, йому буде "знаком" і інтерфейс ReportSmith. ReportSmith пропонує 4 типи звітів: Табличний, Крос-таблиця (CrossTab), Форма (Form) і Наклейка (Label).