Логічна архітектура бази даних

Головна | Про нас | Зворотній зв'язок

Планування конфігурації бази даних

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

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

· Загальна модель предметної області;

· Логічна модель даних;

· Фізична модель даних;

· База даних і додатки.

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

ЗАГАЛЬНА МОДЕЛЬ ПРЕДМЕТНОЇ ОБЛАСТІ

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

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

ЛОГИЧЕСКАЯ МОДЕЛЬ ДАНИХ

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

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

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

ФІЗИЧНА МОДЕЛЬ ДАНИХ

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

БАЗА ДАНИХ І ДОДАТКИ

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

Access і бази даних

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

Логічна архітектура бази даних

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

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

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

Як і з картотекою, з БД проводять ряд операцій над содер-жащейся в ній інформацією, наприклад:

# 9632; додавання нової інформації;

# 9632; пошук інформації;

# 9632; зміна інформації;

# 9632; видалення інформації.

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

# 9632; управління даними в БД - зберігання даних і управління службовою інформацією, що забезпечує роботу СУБД;

# 9632; управління пам'яттю комп'ютера - використання буферизується-ції даних 6 оперативної пам'яті комп'ютера;

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

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

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

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

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

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

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