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

• Переклад

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


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

Який функціонал потрібний від бази даних

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

Фото: binaryape

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

Визначення необхідних таблиць та полів

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

Використовуйте інструмент моделювання даних

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

Є також більш відомий, якісний, як на мене, інструмент - Microsoft Visio (тільки під Windows, ціна $249.99). Але не лякайтеся, є дешевші альтернативи, багато з яких є open-source проектами, у тому числі два, згадані вище.
Ознайомтеся із загальними графічними позначеннями та стандартними візуальними елементами, необхідними для створення моделі бази даних, та почніть попереднє планування за допомогою блок-схем та діаграм. Це дозволить уникнути логічних помилок, перш ніж буде створено вже якусь конкретну базу даних.

Угруповання та поділ даних

Що стосується полів, також важливо знати, коли групувати певну частину даних, а коли ні. Хороший спосіб визначити, яка інформація має бути в одному полі чи навпаки, подумати, чи буде потреба змінювати якусь її частину? Наприклад, чи потрібно зберігати адресу, розбивши її на складові: 1) вулиця, 2) місто, 3) штат, 4) поштовий код, 5) країна?
Це невід'ємна частина функціоналу сайту (можливо, користувачі чи адміністратори захочуть шукати інших користувачів за адресою чи штатом), чи просто збільшення місця, яке займає база даних на диску? Якщо це не так важливо, навіщо тоді навантажувати базу даних на зміну 5 полів, коли можна оновити лише одне рядкове поле. Більш зручним може бути варіант отримання цих даних з HTML-форми, де поля розділені, а перед додаванням адреси в базу даних об'єднувати значення з відповідних полів в один рядок.
Це тільки один приклад, але завжди майте уявлення про найбільш ефективні способи організації полів таблиці, коли об'єднувати їх, коли утримувати окремо, задля підтримки функціональності сайту.

Нормалізація бази даних

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

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

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

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

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

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

Рис. 2.5. Схема організації програмного та інформаційного забезпечення

З використанням субд

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

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

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

Рис. 2.6. Схема злиття ядра БД та додатків

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

Елементи бази даних

База даних системою, тобто. вона складається з деякого числа елементів та відносин між ними (рис. 2.7)

Рис. 2.7. Структурні одиниці БД

Найменшим є елемент даних, який у ряді випадків називають також полем або атрибутом і який відповідає одному реквізиту. Отже, елемент даних - це найменша семантично значуща названа одиниця даних. Елемент даних визначається такими характеристиками: ім'ям (П.І.Б., дата народження, найменування підприємства), типом (символьний, числовий, календарний), довжиною (максимально можлива кількість символів - 15 байт) та точністю (кількість знаків після коми для числових даних).

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

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

База даних, таким чином, є сукупністю взаємозалежних файлів бази даних.

Значення наведених термінів можна пояснити схемою (рис. 2.8).

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

Рис.2.8. Приклад взаємозв'язку структурних одиниць БД

Життєвий цикл баз даних

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

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

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

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

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

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

Проектування баз даних

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

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

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

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

Модель "сутність-зв'язок" зображається графічно у формі ER-діаграми, що складається з набору множин значень, що описують властивості сутності та зв'язку (Entity - Relationship Diagrams).

До переваг цієї моделі відносяться:

легкість формалізації,

простота розуміння;

опис графічними засобами;

наочність зображення різних типів зв'язків;

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

Основними компонентами моделі «сутність-зв'язок» є сутність, атрибути та зв'язки (рис. 2.9).

Рис.2.9. ER -діаграма

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

Зв'язок (Relationship) - названа асоціація між двома сутностями, значуща для аналізованої предметної області.

Зв'язку надається ім'я, причому ім'я кожного зв'язку між двома сутностями має бути унікальним.

Концептуальна модель складається на основі інтерв'ю та опитувань експертів - фахівців у предметній галузі і має задовольняти низці вимог:

має бути незалежною від конкретної СУБД;

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

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

повинна по можливості існувати у формі, що сприймається комп'ютером. І тут вона придатна для автоматизованого проектування БД.

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

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

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

Ієрархічна та мережева моделі даних стали застосовуватися в системах управління базами даних на початку 1960-х років. На початку 1970-х років. була запропонована реляційна модель даних.

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

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

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

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

на етапі концептуального проектування широко використовуються графічні методи;

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

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

Типи логічних моделей даних

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

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

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

Основні переваги ієрархічної моделі - простота опису ієрархічних структур реального світу та швидке виконання запитів, що відповідають структурі даних. Однак такі моделі часто містять надлишкові дані та погано пристосовані для представлення взаємозв'язків типу «багато хто до багатьох». Крім того, не завжди зручно щоразу починати пошук потрібних даних з кореня, а іншого способу переміщення по базі в ієрархічних структурах немає. Ієрархічні системи - старе покоління систем баз даних, вони розроблялися для високих ЕОМ.

Рис. 2.10. Ієрархічна структура моделі БД

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

Рис. 2.11. Мережна структура моделі БД

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

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

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

Основні поняття реляційних баз даних

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

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

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

Таблиця 2.6

Співробітники

Табельний номер	Прізвище І.Б.	Код відділу	Робочий телефон
	ПЕТРОВ А.В.
	РОМАНЕНКО С.Т.
	СТЕПАНОВА І.С.

Можна побачити, що всі три записи атрибути однакові, однак набувають різних значень. Так, для запису № 1 атрибут «табельний номер» набуває значення 008976, а запису № 2 - 008980 тощо. Значення деяких атрибутів у різних записів можуть збігатися, наприклад записи № 1 і № 2 однакове значення атрибута «код відділу». Однак у кожній таблиці має бути атрибут (або сукупність атрибутів), значення якого ніколи не повторюється та однозначно ідентифікує кожен рядок таблиці. Це потрібно для того, щоб під час роботи з базою можна було відрізняти один запис від іншого. Такі атрибути називають унікальними. Унікальний атрибут таблиці чи сукупність її унікальних атрибутів називають первинним ключемабо ключовим полем.У цій таблиці ключем є атрибут «табельний номер».

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

У ряді випадків атрибут може не мати жодного значення: наприклад, співробітник № 3 не має робочого телефону і відповідний атрибут не заповнений. І тут кажуть, що атрибут має нульове значення. Ключ не може мати нульового значення.

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

Таблиця 2.7

Між двома наведеними таблицями можна встановити відношення "СПІВРОБІТНИК - працює в - ВІДДІЛІ". Якщо потрібно дізнатися інформацію про відділ, у якому працює співробітник №2, потрібно взяти значення атрибута "код відділу" у таблиці "СПІВРОБІТНИКИ" та знайти відповідний код у таблиці "ВІДДІЛИ". Таким чином, два записи з різних таблиць як би об'єднаються

РОМАНЕНКО С.Т.

ВІДДІЛ КАДРІВ

Можна побачити, що відносини між двома таблицями встановлюються на основі відповідності значень атрибутів двох таблиць, у нашому випадку це атрибут "код відділу" таблиці "СПІВРОБІТНИКИ" та атрибут "код" таблиці "ВІДДІЛИ". Такі атрибути називають атрибутами зв'язку.Атрибут зв'язку в одній таблиці має бути ключем. У наведеному прикладі атрибут "код" є ключем для таблиці "ВІДДІЛИ" Якби це було не так і коди відділів у цій таблиці повторювалися, неможливо було б визначити, про який відділ йдеться в першій таблиці. Другий атрибут зв'язку – у цьому випадку "код відділу" таблиці "СПІВРОБІТНИКИ" – називають зовнішнім ключем, Оскільки він посилається на ключ іншої (зовнішньої) таблиці (рис. 2.12).

Первинний ключ таблиці 2

Постріляційні бази даних

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

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

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

РАХУНКИ-ФАКТУРИ РЯДКИ

РАХУНКІВ-ФАКТУР

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

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

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

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

Сховище даних

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

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

забезпечення повсякденної роботи підприємства щодо введення та обробки інформації;

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

Завдання першого класу – автоматизація оперативної діяльності – повністю вирішуються ПроLTР-Системами (Online Transactional Process­ ing - оперативна обробка трансакції), до яких належать автоматизовані банківські системи, облікові системи та ін. Для роботи з аналітичними даними призначені OLAP- системи (Online Analytical Processing - оперативна аналітична обробка), які побудовані за технологією сховища даних та призначені для агрегованого аналізу великих обсягів даних. Ці системи є складовою частиною систем прийняття рішень або управлінських систем класу middle і top manage­ ment, тобто. систем, призначених для користувачів середнього та вищого рівнів управління компанією.

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

Таблиця 2.8

Характеристики операційних та аналітичних інформаційних систем

Властивостіданих	Система
	операційної обробки	аналітичної обробки
Призначення	Оперативний пошук, нескладні види обробки	Аналітична обробка, прогнозування, моделювання
Рівень агрегації	Деталізовані дані	Агреговані дані
Час зберігання	Від кількох місяців до одного року	Від кількох десятків років і більше
Частота оновлення	Висока. Оновлення малими порціями	Низька. Оновлення великими порціями до декількох мільйонів записів за один раз
Критерій ефективності	Кількість трансакцій за одиницю часу	Швидкість виконання складних запитів та прозорість структури зберігання для користувачів

Таким чином, сучасна ЕІС є системою, заснованою на спільному використанні трансакційних OLTP- систем та сховищ даних (Data Warehouse).

Термін «сховище даних» став популярним у 1990-х роках. Згідно з визначенням Вільяма Інмона, який є основоположником даної технології, сховище даних (ХД) є предметно-орієнтованим, інтегрованим, незмінним, що підтримує хронологію набір даних, організований з метою підтримки прийняття рішень.

Відмінними рисами сховища даних є:

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

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

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

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

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

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

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

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

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

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

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

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

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

Апарат виконання розрахунків.Спеціальний апарат виконання розрахунків забезпечує:

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

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

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

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

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

Архітектура системи управління сховищем даних показано на рис. 2.15.

Рис. 2.15. Архітектура системи управління сховищем даних

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

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

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

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

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

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

Таким чином, багатовимірну модель ХД доцільно використовувати, коли її об'єм невеликий (не більше 10-20 гігабайт), а гіперкуб має стабільний у часі набір вимірів.

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

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

Рис. 2.16. Логічна схема комбінованого сховища даних

Вітрини даних

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

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

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

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

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

Наступна відмінність полягає у ступеня деталізації даних, оскільки вітрина даних містить агреговані дані. У сховищі даних, навпаки, є максимально деталізовані дані.

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

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

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

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

Рис. 2.17. Взаємозв'язок вітрин даних та сховища даних

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

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

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

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

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

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

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

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

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

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

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

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

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

Виділяють такі види СУБД:

* повнофункціональні СУБД;

* сервери БД;

* Засоби розробки програм роботи з БД.

Повнофункціональні СУБД є традиційні СУБД. До них відносяться dBaseIV, Microsoft Access, Microsoft FoxPro та ін.

Сервери БД призначені організації центрів обробки даних у мережах ЕОМ. Сервери БД забезпечують обробку запитів клієнтських програм, зазвичай за допомогою операторів SQL. Прикладами серверів БД є: Microsoft SQL Server, InterBase та інших.

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

Засоби розробки програм роботи з БД можуть використовуватись для створення наступних програм:

* клієнтських програм;

* серверів БД та їх окремих компонентів;

* Користувацьких додатків.

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

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

* Можливість організації спільної паралельної роботи багатьох користувачів;

* масштабованість;

* Перенесення на різні апаратні та програмні платформи;

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

* забезпечення безпеки даних і розвиненої структурованої системи доступу до них.

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

* відносна простота експлуатації, що дозволяє створювати на їх основі працездатні користувацькі додатки;

* щодо обмежені вимоги до апаратних ресурсів.

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

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

· Мова опису даних - високорівневий непроцедурний мов структури даних;

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

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

СУБД реалізує такі основні функції низького рівня:

* управління даними у зовнішній пам'яті;

* управління буферами оперативної пам'яті;

* Управління транзакціями;

* ведення журналу змін у БД;

* забезпечення цілісності та безпеки БД.

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

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

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

Транзакції притаманні три основні властивості:

* атомарність (виконуються всі операції, що входять в транзакцію, або жодна);

* серіалізуемість (відсутня взаємний вплив виконуваних одночасно і транзакцій);

* Довговічність (навіть крах системи не призводить до втрати результатів зафіксованої транзакції).

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

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

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

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

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

Щоб змінити структуру бази даних на вашому комп'ютері, необхідно встановити програму Access.

У цій статті

Спільне використання даних за допомогою мережевих папок

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

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

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

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

Якщо спільна папка мережі відсутня, її потрібно налаштувати.

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

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

1. Запустіть Access і на вкладці Файлвиберіть пункт Параметри.

   У вікні Параметри Accessвиберіть пункт Параметри клієнта.

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

На комп'ютері кожного користувача створіть ярлик файлу бази даних. У діалоговому вікні "Властивості ярлика" вкажіть шлях до файлу бази даних у властивості Ціль, використовуючи замість букви підключеного диска UNC-адресу. Наприклад, замість шляху F:\sample.accdbвкажіть шлях \\ім'я_комп'ютера\shared.accdb.

Примітка:Цю дію користувачі можуть виконати самостійно.

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

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

Переваги поділу бази даних

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

Підвищена доступністьТранзакції бази даних, наприклад, редагування записів, виконуються швидше.

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

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

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

Якщо цей метод вам підходить, перейдіть до інструкцій у статті Розділ бази даних Access.

Спільне використання бази даних на веб-сайті SharePoint

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

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

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

Служби Access надають платформу для створення даних, які можна використовувати в Інтернеті. Веб-бази даних конструюються та публікуються за допомогою Access 2010 та SharePoint, після чого можна використовувати веб-базу даних через веб-браузер.

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

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

Запити та макроси даних виконуються на сервері: вся обробка SQL-коду виконується на сервері. Це підвищує продуктивність мережі, оскільки по ній передаються лише результати набори.

Збереження бази даних у бібліотеці документів

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

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

Відкрийте базу даних, яку потрібно використовувати спільно.

На вкладці Файлвиберіть пункт Зберегти як.

Примітка:Якщо ви використовуєте Access 2010, виберіть елементи Файл > Зберегти та опублікувати > Зберегти базу даних як > SharePoint.

У діалоговому вікні Збереження у SharePointперейдіть до відповідної бібліотеки документів.

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

Для отримання додаткових відомостей див . статті Публікація у службах Access та Імпорт та зв'язування даних зі списком SharePoint .

Спільне використання бази даних шляхом зв'язування зі списками SharePoint

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

Цей спосіб включає три основні дії.

Переміщення даних до списків SharePoint.

Створення посилань на ці списки.

Розповсюдження файлу бази даних.

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

Використання майстра експорту таблиць у SharePoint

На вкладці Робота з базами данихв групі Перенесення данихклацніть елемент SharePoint.

Примітка:Цей елемент доступний лише у випадку, якщо файл бази даних збережено у форматі ACCDB.

Виконуйте вказівки майстра експорту таблиць у SharePoint; зокрема, вкажіть розташування сайту SharePoint. Щоб скасувати процес, натисніть кнопку скасування.

Щоб переглянути додаткові відомості про перенесення, на останній сторінці майстра встановіть прапорець Деталі.

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

Коли всі майстри будуть завершені, натисніть кнопку Готово.

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

Примітка:Щоб переглянути списки на веб-сайті SharePoint, клацніть в області швидкого запуску кнопку Спискиабо виберіть пункт Переглянути весь вміст вузла. Ви можете оновити сторінку у веб-браузері. Щоб відобразити списки в області швидкого запуску на веб-сайті SharePoint або змінити інші параметри (наприклад, увімкнути відстеження версій), можна змінити установки списків на веб-сайті SharePoint. Додаткові відомості див. у довідці для SharePoint.

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

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

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

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

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

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

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

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

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

Основні етапи використання Access із сервером баз даних

Чинники, які слід враховувати під час вибору методу

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

30.03.17 3.4K

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

Процес проектування бази даних

Належним чином структурована база даних:

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

Розробка БД включає наступні етапи:

1. Аналіз вимог чи визначення мети бази даних;
2. Організація даних у таблицях;
3. Вказівка ​​первинних ключів та аналіз зв'язків;
4. Нормалізація таблиць.

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

Аналіз вимог: визначення мети бази даних

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

Ось кілька способів збирання інформації перед створенням бази даних:

• Опитування людей, які її використовуватимуть;
• Аналіз бізнес-форм, таких як рахунки-фактури, розклади, опитування;
• Розгляд всіх існуючих систем даних ( включаючи фізичні та цифрові файли).

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

Клієнти

• Адреса;
• Місто, штат, поштовий індекс;
• Адреса електронної пошти.

Товари

• Назва;
• Ціна;
• Кількість у наявності;
• Кількість на замовлення.

Замовлення

• Номер замовлення;
• Торговий представник;
• Дата;
• Товар;
• Кількість;
• Ціна;
• Вартість.

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

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

Структура бази даних: побудова блоків

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

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

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

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

• CHAR – конкретна довжина тексту;
• VARCHAR – текст різної довжини;
• TEXT – великий обсяг тексту;
• INT - позитивне або негативне ціле число;
• FLOAT, DOUBLE - числа з плаваючою комою;
• BLOB – двійкові дані.

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

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

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

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

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

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

Створення зв'язків між сутностями

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

Кожен об'єкт може бути взаємопов'язаний з іншим за допомогою одного із трьох типів зв'язку:

Зв'язок «один-до одного»

Коли існує лише один екземпляр об'єкта A для кожного екземпляра об'єкта B, кажуть, що між ними існує зв'язок «один-до одного» ( часто позначається 1:1). Можна вказати цей тип зв'язку в ER діаграмі лінією з тире на кожному кінці:

Якщо при проектуванні та розробці баз даних у вас немає підстав розділяти ці дані, зв'язок 1:1 зазвичай вказує на те, що краще об'єднати ці таблиці в одну.

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

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

Зв'язок «один-багатьом»

Ці зв'язку виникають, коли запис в одній таблиці пов'язана з декількома записами в іншій. Наприклад, один клієнт міг розмістити багато замовлень, або читача може бути відразу кілька книг, взятих у бібліотеці. Зв'язки «один-багатьом» (1:M) позначаються так званою «влучною ногою ворони», як у цьому прикладі:

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

Зв'язок «багатьом-багатьом»

Коли кілька об'єктів таблиці можуть бути пов'язані з декількома об'єктами іншого. Кажуть, що вони мають зв'язок багато хто до багатьох» ( M:N). Наприклад, у випадку студентів та курсів, оскільки студент може відвідувати багато курсів, і кожен курс може відвідувати багато студентів.

На ER-діаграмі ці зв'язки відображаються за допомогою наступних рядків:

При проектуванні структури бази даних реалізувати такого зв'язку неможливо. Натомість потрібно розбити їх на два зв'язки «один-багатьом».

Для цього потрібно створити між цими двома таблицями нову сутність. Якщо між продажами та продуктами існує зв'язок M:N, можна назвати цей новий об'єкт. sold_products», оскільки він міститиме дані для кожного продажу. І таблиця продажів, і таблиця товарів матимуть зв'язок 1: M із sold_products . Цей вид проміжного об'єкта у різних моделях називається таблицею посилань, асоціативним об'єктом чи таблицею зв'язків.

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

Обов'язково чи ні?

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

Два об'єкти можуть бути взаємозалежними ( один не може існувати без іншого).

Рекурсивні зв'язки

Іноді під час проектування бази даних таблиця свідчить про себе. Наприклад, таблиця співробітників може мати атрибут «керівник», який посилається на іншу особу у цій же таблиці. Це називається рекурсивним зв'язком.

Зайві зв'язки

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

Нормалізація бази даних

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

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

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

Перша форма нормалізації

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

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

Друга форма нормалізації

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

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

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

Таким чином, таблиця з цими полями не відповідатиме другій формі нормалізації, оскільки атрибут «назва товару» залежить від ідентифікатора продукту, але не від номера замовлення:

• Номер замовлення (первинний ключ);
• ID товару (первинний ключ);
• Назва товару.

Третя форма нормалізації

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

Відповідно до 3NF , не можна зберігати в таблиці будь-які похідні дані, такі як стовпець «Податок», який у наведеному нижче прикладі безпосередньо залежить від загальної вартості замовлення:

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

Багатовимірні дані

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

Правила цілісності даних

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

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

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

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

Додавання індексів та уявлень

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

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

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

Розширені властивості

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

SQL та UML

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

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

Добре погано