Реферати

Дипломна робота: Нарощування економічної і статистичної інформації в двухструктурних реляційних базах даних

Доля Герасима по повісті И. С. Тургенєва Муму. Доля Герасима (по повісті И. С. Тургенєва "Муму") Автор: Тургенєв И. С. Герасим був "самим чудовим обличчям". Автор писав про нього: "Чоловік 12 вершків росту, складений богатирем і глухонімий від народження". Обдаровано він надзвичайною силою. Працював за четверо- усі спорилось у його руках. От чим відрізнявся Герасим від іншої челяді барині, що побоювалася його.

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

Мережі FDDI. Принцип дії, застосовуване устаткування, варіанти використання. Використання волоконної оптики. ЛВС і механізми контролю потоків.

Приведення поверхні другого порядку до канонічного виду шляхом перетворення систем координа. ФГОУ ВПО "Чуваський державний університет імені И. Н. Ульянова" Кафедра вищої математики КУРСОВА РОБОТА З дисципліни: "Алгебра і геометрія"

Вплив нав'язливості продавців на здійснення покупки. Міністерство утворення і науки Федеральне агентство по утворенню Державна освітня установа вищого професійного утворення

ЗМІСТ

Введення...

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].

База даних може розроблятися для пакетної обробки даних, обробки в реальному часі або оперативної обробки (в цьому випадку обробка кожного запиту завершується до певного моменту часу, але при цьому на час обробки не накладається жорстких обмежень, існуючих в системах реального часу). У багатьох базах даних передбачена сукупність цих методів обробки, а в багатьох системах з базами даних обслуговування терміналів в реальному часі відбувається одночасно з пакетною обробкою даних.[2].

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

Некерована надмірність має декілька недоліків. По-перше, зберігання декількох копій даних приводить до додаткових витрат. По-друге, при оновленні, принаймні, декількох надлишкових копій необхідно виконувати багаторазові операції оновлення. Надмірність тому обходиться значно дорожче в тих випадках, коли при обробці файлів оновлюється велика кількість інформації або, що ще гірше, часто вводяться нові елементи або знищуються старі. По-третє, внаслідок того, що різні копії даних можуть відповідати різним стадіям оновлення, інформація, що видається системою, може бути суперечливою.[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. На рівнях з великим номером знаходяться залежні вершини. Вершин попереднього рівня є початковою для нових залежних вершин.

4. Кожна вершина, що знаходиться на рівні i, сполучена з однією і тільки однією вершиною рівня i-1, за винятком кореневої вершини.

5. Коренева вершина може бути пов'язана з однією або декількома залежними вершинами.

6. Доступ до кожної вершини відбувається через кореневу по єдиному шляху

7. Існує довільна кількість вершин кожного рівня.

Ієрархічна модель даних складається з декількох дерев, т. е. є лісом. Кожна коренева вершин утворить початок запису логічної бази даних. У ИМД вершини, що знаходяться на рівні i, називають породженими вершин мі н рівні i-1.

Операції в ИМД мають нелогічний позаписний характер. Апарат переміщення по структурі в графових моделях служить для установки тих об'єктів даних, до яких буде застосовуватися чергова операція маніпулювання даними. Такі об'єкти називаються поточними. Механізми доступу до даних і переміщення по структурі даних в таких моделях досить складні і істотним образом спираються на концепцію поточного стану механізму доступу.[7, 10, 11, 12].

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

До числа СУБД ієрархічного типу можна віднести PC/Focus, Team-Up, Data Edge, також розроблену в нашій країні систему НИКА, спадкоємицю широко поширеної радянської системи ИНЕС для ЄС ЕОМ.

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

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

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

Щоб отримати доступ до даних, що містяться в базі даних, програма могла:

- знайти конкретну деталь (праві двері) по її номеру;

- перейти "вниз" до першого нащадка (ручка дверей);

- перейти "вгору" до предка (корпус);

- перейти "в сторону" до іншого нащадка (праві двері).

Таким чином, для читання даних з ієрархічної бази даних було потрібен переміщатися по записах, за один раз переходячи на один запис вгору, вниз або в сторону.

Обмеження цілісності.

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

У ієрархічних системах підтримувалася деяка форма уявлень БД на основі обмеження ієрархії.

5.2. Мережева модель даних

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

У СМД елементарні дані і відносини між ними представляються у вигляді орієнтованої мережі (вершини - дані, дуги - відносини).[7].

Якщо структура даних виявлялася складнішою, ніж звичайна ієрархія, простота структури ієрархічної бази даних ставала її недоліком. Наприклад, в базі даних для зберігання замовлень одне замовлення могло брати участь в трьох різних відносинах предок/нащадок, зв'язуючих замовлення з клієнтом, що розмістив його, зі службовцем, що прийняв його, і із замовленим товаром, що ілюструє мал. 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 році. У першій реляційній СУБД не були реалізовані деякі з ключових частин моделі Кодда, і цей пропуск був заповнений тільки згодом. По мірі зростання популярності реляційної концепції реляційними стали називатися багато які бази даних, які на ділі такими не були.

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

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

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

Оскільки в програмній реалізації дипломної роботи вибраний реляційний підхід, як найбільш відповідний, опишемо його більш детально.[3, 7, 8, 12].

5.3.1. Таблиці

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

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

Структура таблиці включає наступну інформацію:

- Ім'я таблиці- Ім'я, по якому до таблиці можна звернутися у властивостях, методах і операторах SQL.

- Стовпці таблиці-Категорії інформації, збереженої в таблиці. Кожний стовпець має ім'я і тип даного.

- Табличні і столбцовие обмеження-Обмеження цілісності, визначені на рівні таблиці або на рівні стовпця.[3, 7, 8, 12].

Більш наочно структуру таблиці ілюструє рис 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.

Таблиця 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.

Зовнішні ключі

Стовпець однієї таблиці, значення в якому співпадають зі значеннями стовпця, що є первинним ключем іншої таблиці, називаетсявнешним ключем. На мал. 7 стовпець NUM_DIS являє собою зовнішній ключ для таблиці DISCIPLS. Значення, що містяться в цьому стовпці, являють собою ідентифікатори дисциплін, що вивчаються. Ці значення відповідають значенням в стовпці NDIS, який є первинним ключем таблиці DISCIPLS. Сукупно первинний і зовнішній ключі створюють між таблицями, в яких вони містяться, таке ж відношення предок/нащадок, як і в ієрархічній базі даних.

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

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

стовпець REP є зовнішнім ключем для таблиці SALESREPS і

зв'язує кожне замовлення зі службовцем, що прийняв його;

стовпець CUST є зовнішнім ключем для таблиці CUSTOMES і

зв'язує кожне замовлення з клієнтом, що розмістив його;

стовпці 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

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. Згідно з цією загальною схемою, ми маємо ланцюжок

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

Місцеположення Ядра БД і баз даних залежить від архітектури, що використовується. Є чотири різновиди архітектури баз даних:

- локальні бази даних; ' архітектура "файл-сервер";

- архітектура "клієнт-сервер";

- многозвенная (трехзвенная N-tier або multi-tier) архітектура.

Використання тієї або інакшої архітектури накладає сильний відбиток на загальну ідеологію роботи додатку, на програмний код в додатку, на склад компонентів для роботи з БД, що використовується в додатку (передусім це торкається невізуальних компонентів).[4, 15].

7.1. Локальні бази даних і архітектура "файл-сервер"

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

При роботі "вархитектуре файл-сервер'БД і додаток розташовані на файловому сервері мережі (наприклад, 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) і з З++.[4, 6]. Я вважаю, що Turbo Pascal істотно перевершує Basic за рахунок повноцінного об'єктного підходу, що включає в себе розвинені механизмиинкапсуляції, успадкування і поліморфізм. Остання версія мови, вживана в Delphi, по своїх можливостях наближається до З++. З основних механізмів, властивих З++, відсутнє тільки множинне успадкування. (Проте, цим красивим і могутнім механізмом породження нових класів користується лише невелика частина програмістів, пишучих на З++.) Плюси застосування мови Pascal очевидні: з одного боку, на відміну від Visual Basic, заснованого на інтерпретації проміжного коду, для нього є компілятор, що генерує машинний код, що дозволяє отримувати значно більш швидкі програми. З іншою - на відміну від З++ синтаксис мови 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-файли, що використовуються в компіляторах мови З, значно більш гнучкі.

Visual Component Library (VCL) Багатство палітри об'єктів для побудови призначеного для користувача інтерфейса - один з ключових чинників при виборі інструмента візуального програмування. При цьому для користувача має значення як число елементів, включених безпосередньо в середу, так і доступність елементів відповідного формату на ринку. [4, 22].

8.1. Високопродуктивний компілятор в машинний код

Компілятори мови Pascal компанії Borland ніколи не примушували користувача подовгу чекати результатів компіляції. Виробники затверджують, що на сьогодні даний компілятор - самий швидкий в світі. Компілятор, вбудований в Delphiпозволяет обробляти 120 тис. рядків початкового тексту в хвилину на машині 486/33 або 350 тис. - при використанні процесора Pentium/90. Він пропонує легкість розробки і швидкий час перевірки готового програмного блоку, характерного для мов четвертого покоління (4GL) і в той же час забезпечує якість коду, характерного для компілятора 3GL. Крім того, Delphi забезпечує швидку розробку без необхідності писати вставки на Сі або ручного написання коду (хоч це можливе).

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

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

Ймовірно, то обставина, що Delphi позиціонується як засіб створення додатків, взаємодіючих з базами даних, і орієнтовано переважно на ринок інструментальних засобів клієнт/сервер, де до даного моменту домінують мови, що інтерпретуються, дозволило його авторам не задумуватися над створенням оптимізуючого компілятора, здатного використати всі достоїнства архітектури сучасних процесорів. [22].

8.2. Могутня об'єктно-орієнтована мова

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

Об'єктно-орієнтований підхід в новій версії мови отримав значний розвиток. Перерахуємо основні новини.

- введене поняття класу.

- реалізовані методи класів, аналогічні статичним методам З++. Вони оперують не примірником класу, а самим класом.

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

- введена обробка виняткових ситуацій. ВDelphiето влаштоване в стилі З++. Виключення представлені у вигляді об'єктів, вмісних специфічну інформацію про відповідну помилку (тип і місце- знаходження помилки). Розробник може залишити обробку помилки, що існувала за умовчанням, або написати свій власний обробник. Обробка виключень реалізована у видеexception blocks(також ще називаетсяprotected blocks), які встановлюються ключовими словами try і end. Існують два типи таких блоків:try...exceptиtry...finally.

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

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

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

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

Мова программирования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 на форму це виглядає, як просто іконка. Іконки даного типу називаютневизуальним компонентом, оскільки вони невидимі під час виконання програми.

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

TLabelслужит для відображення тексту на екрані. Можна змінити шрифт і колір мітки, якщо двічі клацнути на властивість Font в Інспекторові Об'єктів. Це легко зробити і під час виконання програми, написавши усього одну строчку коду.

TEdit- стандартний керуючий елемент Windows для введення. Він може бути використаний для відображення короткого фрагмента тексту і дозволяє користувачу вводити текст під час виконання програми.

TMemo - інакша форма TEdit. Має на увазі роботу з великими текстами. TMemo може перенести слова, зберігати в ClipBoard фрагменти тексту і відновлювати їх, і інші основні функції редактора. TMemo має обмеження на об'єм тексту в 32Кб, це становить 10-20 сторінок (є подібні компоненти, де ця межа снят).

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

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

TRadioButtonпозволяет вибрати тільки одну опцію з декількох.

TListBoxнужен для показу списку, що прокручується. Класичний приклад ListBox'а в середовищі Windows - вибір файла з списку в пункті меню File ¦ Open багатьох додатків. Назви файлів або директорія і знаходяться в ListBox'е.

TComboBoxво багато чому нагадує ListBox, за винятком того, що дозволяє водити інформацію в маленькому полі введення зверху ListBox. Є декілька типів ComboBox, але найбільш популярний той, що спадає вниз (drop-down combo box), який можна бачити внизу вікна діалогу вибору файла.

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

TGroupBoxиспользуется для візуальних цілей і для вказівки Windows, який порядок переміщення по компонентах на формі (при натисненні клавіші TAB).

TRadioGroupиспользуется аналогічне TGroupBox, для угруповання об'єктів TRadioButton.

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

TBitBtn - кнопка на зразок TButton, однак на ній можна розмістити картинку (glyph). TBitBtn має декілька приречених типів (bkClose, bkOK і др), при виборі яких кнопка приймає відповідний вигляд. Крім того, натиснення кнопки на модальному вікні приводить до закриття вікна з відповідним модальним результатом.

TSpeedButton - кнопка для створення панелі швидкого доступу до команд (SpeedBar). Приклад - SpeedBar зліва від Палітри Компонент в середовищі Delphi. Звичайно на дану кнопку вміщується тільки картинка (glyph).

TTabSet- горизонтальні закладки. Звичайно використовується разом з TNoteBook для створення многостраничних вікон. Назву сторінок можна задати у властивості Tabs.

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

TTabbedNotebook- многостраничний діалог з вбудованими закладками, в цьому випадку - закладки зверху.

TMaskEdit - аналог TEdit, але з можливістю форматованого введення. Формат визначається у властивості EditMask. У редакторі властивостей для EditMask є заготівлі деяких форматів: дати, валюти і т. п.

TOutline- використовується для представлення ієрархічних відносин пов'язаних даних. Наприклад - дерево директорія.

TStringGrid - служить для представлення текстових даних у вигляді таблиці. Доступ до кожного елемента таблиці відбувається через властивість Cell.

TDrawGrid- служить для представлення даних будь-якого типу у вигляді таблиці. Доступ до кожного елемента таблиці відбувається через властивість CellRect.

TImage - відображає графічне зображення на формі. Сприймає формати BMP, ICO, WMF. Якщо картинку підключити під час дизайну програми, то вона прикомпилируется до EXE файла.

TShape - служить для відображення найпростіших графічних об'єктів на формі: коло, квадрат і т. п.

TBevel- елемент для рельєфного оформлення інтерфейса.

THeader- елемент оформлення для створення заголовків із змінними розмірами для таблиць.

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

TTimer - таймер, подія OnTimer періодично викликається через проміжок часу, вказаний у властивості Interval. Період часу може складати від 1 до 65535 мс.

TPaintBox - місце для малювання. У обробники подій, пов'язаних з мишкою передаються відносні координати мишки в TPaintBox, а не абсолютні в формі.

TFileListBox - спеціалізований ListBox, в якому відображаються файли з вказаного директорія (св-у Directory). На назви файлів можна накласти маску, для цього служить св-у Mask. Крім того, в св-ве FileEdit можна указати об'єкт TEdit для редагування маски.

TDirectoryListBox - спеціалізований ListBox, в якому відображається структура директорія поточного диска. У св-ве FileList можна указати TFileListBox, який буде автоматично відстежувати перехід в іншого директорія.

TDriveComboBox - спеціалізований ComboBox для вибору поточного диска. Має властивість DirList, в якій можна указатьTDirectoryListBox, який буде відстежувати перехід на інший диск.

TFilterComboBox- спеціалізований ComboBox для вибору маски імені файлів. Список масок визначається у властивості Filter. У властивості FileList вказується TFileListBox, на який встановлюється маска.

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

TMediaPlayer - служить для управління мултимедйними пристроями (типу CD-ROM, MIDI і т. п.). Виконаний у вигляді панелі управління з кнопками Play, Stop, Record і інш. Для відтворення може знадобитися як відповідне обладнання, так і програмне забезпечення. Підключення пристроїв і установка ПО виготовляється в середі Windows. Наприклад, для відтворення відео, записаного в форматі AVI, в зажадається встановити ПО MicroSoft Video (в Windows 3.0, 3.1, WFW 3.11).

TOLEContainer- контейнер, вмісний OLE об'єкти. Підтримується OLE 2.02

TDDEClientConv, TDDEClientItem, TDDEServerConv, TDDEServerItem -4 об'єкта для організації DDE. За допомогою цих об'єктів можна побудувати додаток як DDE-сервер, так і DDE-клієнт.

TChartFX - ділова графіка. Компонент дозволяє будувати всілякі графіки і гістограми.

8.5. Форми, модулі і метод розробки "Two-Way Tools"

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

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

Така синхронізація і робить Delphitwo-way-інструментом, забезпечуючи повну відповідність між кодом і візуальним уявленням. Як тільки додається новий об'єкт або код, Delphiустанавливает т. н. "кодову синхронизацию'между візуальними елементами і відповідними ним кодовими уявленнями.

Two-way tools-однозначна відповідність між візуальним проектуванням і класичним написанням тексту программиЕто означає, що розробник завжди може бачити код, відповідний тому, що він побудував за допомогою візуальних інструментів і навпаки.

Візуальний построитель інтерфейсів (Visual User-interface builder) дає можливість швидко створювати клієнта-серверний додатки візуально, просто вибираючи компоненти з відповідної палітри. У процесі побудови додатку розробник вибирає з палітри компонент готові компоненти як художник, що робить велику мазки кистю. Ще до компіляції він бачить результати своєї роботи - після підключення до джерела даних їх можна бачити відображеними на формі, можна переміщатися за даними, представляти їх в тому або інакшому вигляді.[4, 22].

8.6. Кошти, що Масштабуються для побудови баз даних

Потужність і гнучкість Delphi при роботі з базами даних заснована на низкоуровневомядре- процесорі баз даннихBorland Database Engine(BDE). Егоїнтерфейсспрікладниміпрограммаміназиваєт 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 також входить безліч утиліт для роботи і управління базами даних. Ось деякі з них.

Database Desktop- це утиліта, багато в чому схожа на Paradox, яка постачається разом з Delphi для інтерактивної роботи з таблицями різних форматів локальних баз даних - Paradox і dBase, а також SQL-серверний баз даних InterBase, Oracle, Informix, Sybase (з використанням SQL Links). Вона дозволяє створювати як структуру реляційних таблиць, так і всілякі обмеження цілісності таблиць, індекси, первинні ключі і зовнішні ключі.

WISQL(Windows Interactive SQL) - інтерактивний засіб посилки SQL-запитів до InterBase (в тому числі і локальному InterBase), вхідне в постачання Delphi, дозволяє створювати таблиці - через посилку SQL-запитів. Database Desktop не володіє всіма можливостями по управлінню SQL-серверний базами даних. Тому з допомогою Database Desktop зручно створювати або локальні бази даних або тільки найпростіші SQL-серверний бази даних, що складаються з невеликого числа таблиць, не дуже сильно пов'язаних один з одним. Якщо ж необхідно створити базу даних, що складається з великого числа таблиць, що мають складні взаємозв'язки, можна скористатися мовою SQL. Можна записати всю послідовність SQL-пропозицій в одну так звану скрипт і послати його на виконання. Конкретні реалізації мови SQL трохи відрізняються в різних SQL-серверах, однак базові пропозиції залишаються однаковими для всіх реалізацій. Практика показує, що якщо немає необхідності створювати таблиці під час виконання програми, то краще скористатися WISQL.

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).

ReportSmith використовує концепцію "живих даних", т. е. робота відбувається з справжніми даними весь час, а не тільки тоді, коли запускається перегляд (preview). Крім цього, ReportSmith легко працює з надзвичайно великою БД за допомогою адаптивної технології управління пам'яттю. У ReportSmith можна управляти тим, де зберігається результат вибірки даних з БД: в локальний пам'яті клієнтської PC, на жорсткому диску клієнтської PC, або на сервері.

8.7. Середа розробника

,

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

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

Оскільки вDelphiпрограмма будується візуальним образом, всі ці компоненти мають своє графічне представлення в полі форм для того, щоб можна було б ними відповідним образом оперувати. Але для працюючої програми видимими залишаються тільки візуальні компоненти. Компоненти згруповані на сторінках палітри по своїх функціях. Наприклад, компоненти, що представляють "Windows common dialogs" все розміщені на сторінці палітри з назвою "Dialogs".

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

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

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

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

- Інспектор об'єктів. Цей інструмент представляє з себе окреме вікно, де ви можете в період проектування програми встановлювати значення властивостей і подій об'єктів (Properties & Events).

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

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

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

- Експерти. Це набір інструментальних програм, що полегшують проектування і настройку Ваших додатків. Є можливість підключати самостійно розроблені експерти. Потенційно це та можливість, за допомогою якої треті фірми можуть расширятьDelphiCASE-інструментами, розробленими спеціально для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.

Инфологическая модель даних

Предметна область- частина реального світу відображена в базу даних.

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

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

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

Атрибут-поименованная характеристика суті. Атрибутом суті є будь-яка деталь, яка служить для уточнення, ідентифікації, класифікації, числової характеристики або вираження стану суті. Його найменування повинне бути унікальним для конкретного типу суті, але може бути однаковим для різного типу сутностей (наприклад, КОЛІР може бути визначений для багатьох сутностей: СОБАКА, АВТОМОБІЛЬ, ДИМ і т. д.). Атрибути використовуються для визначення того, яка інформація повинна бути зібрана про суть. Прикладами атрибутів для суті АВТОМОБІЛЬ є ТИП, МАРКА, НОМЕРНИЙ ЗНАК, КОЛІР і т. д. Тут також існує відмінність між типом і примірником. Тип атрибута КОЛІР має багато примірників або значень: Червоний, Синій, Банановий, Біла ніч і т. д., однак кожному примірнику суті привласнюється тільки одне значення атрибута.

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

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

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

При визначенні инфологической моделі необхідно брати до уваги наступну:

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

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

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

- База даних повинна легко розширятися при реорганізації і розширенні предметної області.

- База даних повинна легко змінюватися при зміні програмної і апаратної середи.

9.2. Инфологическая модель даних "суть-зв'язок"

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

На використанні різновидів ER-моделі заснована більшість сучасних підходів до проектування баз даних (головним чином, реляційних). Модель була запропонована Ченом (Chen) в 1976 р. Моделювання предметної області базується на використанні графічних діаграм, що включають невелике число різнорідних компонентів. У зв'язку з наглядністю представлення концептуальних схем баз даних ER-моделі набули широкого поширення в системах CASE, підтримуючих автоматизоване проектування реляційних баз даних.

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

Між двома сутностям, наприклад, А і В можливі чотири вигляду зв'язків.

Перший тип - зв'язок ОДИН-До-ОДНОМУ (1:1): в кожний момент часу кожному представнику (примірнику) суті А відповідає 1 або 0 представників суті В:

Студент може не "запрацювати" стипендію, отримати звичайну або одну з підвищених стипендій. Або, допустимо, в певний момент часу один клієнт може зробити тільки одне замовлення. У цьому випадку між об'єктами КЛІЄНТ і ЗАМОВЛЕННЯ встановлюється взаємозв'язок "один до одного", що означається одинарними стрілками.

Між даними, що зберігаються в об'єктах КЛІЄНТ і ЗАМОВЛЕННЯ, буде існувати взаємозв'язок, в якому кожний запис в одному об'єкті буде однозначно вказувати на запис в іншому об'єкті. Ні в одному, ні в іншому об'єкті не може існувати запису, не пов'язаному з яким-небудь записом в іншому об'єкті.

Другий тип - зв'язок ОДИН-ДО-БАГАТЬОМ (1: М): одному представнику суті А відповідають 0, 1 або трохи представників суті Або, наприклад, в певний момент часу один клієнт може стати володарем декількох моделей автомобілів, при цьому трохи клієнтів не можуть бути володарями одного автомобіля. Взаємозв'язок "один до багато чим" можна визначити за допомогою одинарної стрілки в напрямі до "одного" і двійчастої стрілки в напрямі до "багато чим". У цьому разі одного запису даних першого об'єкта (його часто називають батьківським або основним) буде відповідати декілька записів другого об'єкта (дочірнього або підлеглого). Взаємозв'язок "один до багато чим" дуже поширена при розробці реляційних баз даних.

Третій тип - зв'язок БАГАТО ЯКІ-До-ОДНОМУ (М:1): одному представнику суті В відповідають 0, 1 або трохи представників суті до. між двома сутностями можливі зв'язки в обох напрямах і все залежить від того з якими сутностями пов'язані дані.

Четвертий тип - зв'язок БАГАТО ЯКІ-ДО-БАГАТЬОМ (N: М): одному представнику суті В відповідають 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] (ПОС, ПР, Дата_П, Ціна, Вага (кг))

Міста (Місто, Країна)

Рецепти (БЛ, Рецепт) {Блюда}

Витрата (БЛ, Дата_Р, Порцій) {Блюда}

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

Існує ще найбільш поширена модифікація 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. Отримання статистичної інформації про якість і кількість зерна. За результатами роботи за період (як правило, рік) формуються статистичні звіти для статистичного управління про середні якісні показники зерна.

10.2. Визначення об'єктів бази даних

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

1. Клієнти (Код клієнта, Назва клієнта, Тип клієнта, Банківські реквізити, Юридична адреса, Телефон)

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

2. Культури (Код культури, Назва культури, Клас, Базисна вогкість, Базисна зернова домішка, Базисна смітна домішка, Базисна стекловидность, Базисна натура, Базисна клейковина)

3. Вигляд надходження (Код вигляду надходження, Назва вигляду надходження).

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

4. Накладні (Номер_накладной, Дата накладної, Код клієнта, Номер_автомашини, Код культури, Код вигляду надходження, Маса брутто, Маса тари, Маса нетто, Номер складу, Номер лабораторного аналізу).

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

10.3. Инфологическая і даталогическая моделі бази даних

Інфологичеська модель бази даних зображена на мал. 17.

Рис. 17. Инфологическая модель бази даних.

Зірочками на инфологической моделі показані ключові атрибути.

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

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

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

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

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

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

10.4. Фізичний опис моделі

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

Типи даних, що зберігаються в таблицях dBase, дуже різноманітні. Це і символьні значення і різноманітні типи числових значень, включаючі цілочисельні, дійсні, речовинні з плаваючою комою, числа в двійковому і двійково-десятеричному форматі, логічні типи, спеціальні формати для зберігання значень дати, часу і грошових сум, графічні типи для зберігання графічних зображень в самих популярних форматах, а також рядкові значення необмеженої довжини (в тому числі і форматовані в форматі rtf) і навіть типи фірми, що підтримуються технологією OLE (Object Linking and Embedding) Micrоsoft. Така різноманітність типів даних може відповідати навіть самим вишуканим задачам, яким покликана служити база даних, що створюється і без сумніву підходить для рішення кола задач покладеного на базу даних об зерна зернопереробного підприємства.

База даних ZERNO представлена 4-мя таблицями (або по термінології реляційних баз даних - 4-мя реляційними відносинами): Dorg, Dkul, Dtyp, Fnakl. Розглянемо структуру кожної більш детально.

У таблицеDorgпредставлена інформація про клієнтів. Поля, їх типи, і призначення представлені в таблиці 2.

Первинним ключем таблиці є поле O_Kod, яке однозначно визначає кожний запис в таблиці.

У таблицеDkulпредставлена інформація про культури. Поля, їх типи, і призначення представлені в таблиці 3.

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

У таблицеDtypпредставлена інформація про види надходження зерна.. Поля, їх типи, і призначення представленни в таблиці 4.

У таблице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 якого процедура підрахування дуже швидко і ефективно виводить результат.

Висновок

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

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

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

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

Список літератури

1. Дж. Тельман, "Основи систем баз даних", Москва, Фінанси і статистика', 1983 р.

2. Дейт До., "Введення в системи баз даних", Москва, ' Наука', 1980 р.

3. Когловский М. Р., "Технологія баз даних на персональних ЕОМ", Москва, ' Фінанси і статистика', 1992 р.

4. "Шумаков П. В. Delphi 3.0 і створення баз даних". Москва 1997 р.

5. Джон Матчо, Девід Р. Фолкнер. "Delphi" - пер. з англ. - М.: Біном, 1995 р.

6. A.M. Епанешников., "Програмування в середовищі 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. Брябрин В. М., "Програмне забезпечення персональних ЕОМ", Москва, ' Наука', 1989 р.

19. Шафрин Ю. А. "Основи комп'ютерної технології". М., 1998

20. "Кібернетичні діалогові системи", І. П. Кузнецов.

21. "Рекоммендації по общепользовательскому інтерфейсу", Microsoft, редакція 2000 р.

22. Тейксейра З., Пачеко К. Delphi 5. Керівництво разоработчика. Москва-Санкт-Петербург-Київ, 2000 р.