Проектування Бази Даних для комерційного підприємства

Виконав студент групи 31 І 230103 Автоматизовані системи обробки інформації та управління (у промисловості)

Ярославський державний університет імені П.Г. Демидова

Ярославль 2007

Об'єкт дослідження: Borland Delphi 7 як засіб розробки баз даних, проектування та моделювання баз даних, проектування баз даних предметної області «Склад».

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

Основні завдання:

Зібрати інформацію за видами товарів на складі підприємства;

Вивчити середовище розробки додатків Borland Delphi 7;

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

Основні результати:

Створено програмне забезпечення "Магазин автозапчастин";

Програмне забезпечення впроваджено для використання на підприємстві ТОВ «_______».

Введення

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

забезпечувати отримання загальних та/або деталізованих звітів за підсумками роботи;

дозволяти легко визначати тенденції зміни найважливіших показників;

забезпечувати отримання інформації, критичної за часом, без істотних затримок;

виконувати точний і повний аналіз даних.

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

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

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

Глава 1. Області застосування баз даних.

1.1. Нові тенденції розвитку СУБД і областей їх застосування.

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

В тлумачному словнику з обчислювальної техніки, виданому в 2002 р., наводиться таке визначення системи управління базами даних (database management system): "додаток, що забезпечує створення, зберігання, оновлення та пошук інформації в базі даних, а також управління безпекою і цілісністю даних ". Загалом це тлумачення було вірно і 30 років тому, але все ж таки змістовна частина СУБД зараз зовсім інша, ніж у ті далекі часи (відзначимо, що у визначенні вже відсутня додаткова фраза, яка використовувалася для уточнення поняття ще вісім років тому, - "програмна оболонка, що знаходиться між базою даних і користувачем ").

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

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

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

2.1. Нові області застосування баз даних.

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

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

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

бази даних з економічної та кон'юнктурної інформації (статистична, кредитно-фінансова, зовнішньоторговельна)

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

бази транспортних даних систем

довідкові дані для населення та закладів (енциклопедії та довідники, розклади літаків і поїздів, адреси і телефони громадян і організацій)

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

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

фактографічні бази даних у галузі культури та мистецтва

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

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

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

1.База даних Системи спостереження Землі (EOSDIS)

Система спостереження Землі (EOS - Earth Observing System) являє собою безліч супутників, які запускає NASA починаючи з 1998. Їх призначення - збір інформації, необхідної для дослідників, зайнятих вивченням довгострокових тенденцій стану атмосфери, океанів, земної поверхні. Супутники будуть поставляти інформацію в обсязі 1/3 Пбайт (Petabyte - 1015 байт) на рік. Передбачається, що ці дані будуть інтегруватися з уже існуючою інформацією, а також з даними з інших джерел (закордонні супутники, наземні станції спостереження) і накопичуватися в базі даних EOSDIS (EOS Data and Information System) небачених раніше масштабів.

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

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

Вироблення ефективних механізмів перегляду та пошуку інформації, що цікавить.

2.Електронная комерція

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

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

Система електронної комерції повинна мати високонадійні засоби розподіленої аутентифікації і переказу грошових сум.

3.Інформаціонная система охорони здоров'я

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

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

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

4.Електронние публікації

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

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

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

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

5. Колективне проектування

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

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

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

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

Глава 2. Бази даних

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

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

Структурування - Це введення угод про способи представлення даних.

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

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

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

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

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

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

2.1. Класифікація баз даних

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

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

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

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

Системи централізованих баз даних з мережевим доступом передбачають різні архітектури подібних систем:

• файл-сервер;

• клієнт-сервер.

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

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

2.2. Структурні елементи бази даних

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

Поле - Елементарна одиниця логічної організації даних, яка відповідає неподільної одиниці інформації - реквізиту. Для опису поля використовуються наступні характеристики:

ім'я (Прізвище, Ім'я, По батькові, Дата народження);

тип (символьний, числовий, календарний);

довжина (наприклад, 15 байт, причому буде визначатися максимально можливою кількістю символів);

точність для числових даних, наприклад два десяткових знака для відображення дробової частини числа.

Запис - Сукупність логічно пов'язаних полів. Примірник запису - окрема реалізація запису, що містить конкретні значення її полів.

Файл (таблиця) - сукупність примірників записів однієї структури.

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

2.3. Поняття інформаційного об'єкта.

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

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

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

2.4. Нормалізація відносин.

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

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

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

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

Перша нормальна форма.

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

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

Друга нормальна форма.

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

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

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

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

В випадку складного ключа вводиться поняття функціонально повної залежності.

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

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

Третя нормальна форма.

Поняття третій нормальної форми грунтується на понятті нетранзітівной залежності.

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

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

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

2.5. Типи зв'язків.

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

один до одного (1:1);

один до багатьох (1: М);

багато до багатьох (М: М).

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

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

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

Глава 3. Моделі даних

3.1. Відомості про моделі даних.

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

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

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

Мережеві моделі також створювалися для мало ресурсних ЕОМ. Це досить складні структури, що складаються з «наборів» - пойменованих дворівневих дерев. «Набори» з'єднуються за допомогою «записів-зв'язок», утворюючи ланцюжки і т.д. При розробці мережевих моделей було вигадано безліч «маленьких хитрощів», що дозволяють збільшити продуктивність СУБД. Але істотно ускладнити останні. Прикладної програміст повинен знати масу термінів, вивчити декілька внутрішніх мов СУБД, детально представляти логічну структуру бази даних для здійснення навігації серед різних примірників, наборів, записів і т.п. Один з розробників операційної системи UNIX сказав: «Мережева база - це самий вірний спосіб втратити дані ».

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

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

3.2. Види моделей даних.

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

Модель даних - сукупність структур даних та операцій їх обробки.

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

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

Ієрархічна модель даних

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

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

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

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

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

Реляційна модель даних

Поняття реляційних (англ. relation - відношення) пов'язано з розробками відомого американського фахівця в області систем баз даних Е. Кодда.

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

Реляційна модель орієнтована на організацію даних у вигляді двовимірних таблиць. Кожна реляційна таблиця являє собою двовимірний масив і має наступні властивостями:

кожен елемент таблиці - один елемент даних;

все стовпці в таблиці однорідні, тобто всі елементи в стовпці мають однаковий тип (числовий, символьний і т.д.) і довжину;

кожен стовпець має унікальне ім'я;

однакові рядка в таблиці відсутні;

порядок слідування рядків і стовпців може бути довільною.

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

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

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

3.3. Проектування моделі даних

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

В теорії проектування інформаційних систем предметну область (або, якщо завгодно, весь реальний світ у цілому) прийнято розглядати у вигляді трьох уявлень:

подання предметної області в тому вигляді, як вона реально існує

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

як вона може бути описана за допомогою символів.

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

Дані, використовувані для опису предметної області, представлені у вигляді трирівневої схеми (див. схему 1):

Схема 1. Так звана модель ANSI/SPARC

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

Звідси випливають основні етапи, на які розбивається процес проектування бази даних інформаційної системи:

Концептуал