Конспект лекцій Суми Видавництво Сумду 2009 Міністерство освіти І науки України Сумський державний університет icon

Конспект лекцій Суми Видавництво Сумду 2009 Міністерство освіти І науки України Сумський державний університет




НазваКонспект лекцій Суми Видавництво Сумду 2009 Міністерство освіти І науки України Сумський державний університет
Сторінка2/19
Дата04.06.2013
Розмір1.62 Mb.
ТипКонспект
1   2   3   4   5   6   7   8   9   ...   19
^

1.2 Предметна область БД та її моделі




1.2.1 Поняття предметної області


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





Рисунок 1.6  Основні типи моделей даних


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

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





Рисунок 1.7  Класифікації об'єктів ПО


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

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

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

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

^ Приклад. Розглянемо висловлювання: Студент Іванов А.А, народився у 1982 році. Воно виражає такі властивості об'єкта "Іванов А.А.":

у явному вигляді - рік народження;

у неявному - приналежність до студентів.

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

^ НАРОДИВСЯ (Іванов А.А., 1982)

Є СТУДЕНТОМ (Іванов А.А.)

На рис. 1.8 наведений один із підходів до класифікації ситуацій у рамках ПО.





Рисунок 1.8 – Класифікація ситуацій ПО


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

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

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

^

1.2.2 Інформаційна модель ПО БД


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

Інформаційна модель ПО БД містить такі основні конструкції:

  • діаграми "сутність-зв'язок" (Entity - Relationship Diagrams);

  • визначення сутностей;

  • унікальні ідентифікатори сутностей;

  • визначення атрибутів сутностей;

  • відношення між сутностями;

  • супертипи й підтипи.

Елементи інформаційної моделі даних ПО є вхідними даними для вирішення завдання проектування БД - створення логічної моделі даних.

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

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

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

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

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

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

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

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

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

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

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





Рисунок 1.9 – Подання сутності Person (персонал) на ER-діаграмі з атрибутами й унікальним ідентифікатором сутності


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

Домени призначаються аналітиками й фіксуються в спеціальному документі - словнику даних (Data Dictionary). На стадіях розроблення логічної й фізичної моделей реляційної БД домени уточнюються у сутностях на ER-діаграмі.

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





Рисунок 1.10 – Візуалізація визначення доменів атрибутів на ER-діаграмі при створенні фізичної моделі реляційної БД


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

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

^

1.2.3 Функціональна модель ПО БД


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




Рисунок 1.11 – Подання відношення між двома сутностями на ER-діаграмі


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

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

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

Моделі процесів:

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

  • модель потоку даних.

Моделі станів:

  • модель життєвого циклу сутності;

  • набір специфікацій функцій системи (вимоги);

  • опис функцій системи через сутності й атрибути;

  • бізнес-правила, які реалізують функції.

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

^

1.2.4 Процес проектування БД


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

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

  • функціональність й адаптованість;

  • продуктивність обробки транзакцій;

  • пропускна здатність;

  • час реакції;

  • безпека.

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

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

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

Як правило, ІТ-проекти зі створення БД містять у собі такі етапи:

  1. Визначення стратегії побудови системи.

  2. Аналіз вимог до БД.

  3. Проектування БД.

  4. Реалізація БД.

  5. Тестування

  6. Впровадження БД.

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

Процес проектування БД охоплює кілька основних сфер:

  • проектування об'єктів БД (таблиці, подання, індекси, тригери, збережені процедури, функції, пакети) для подання даних ПО в БД;

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

  • проектування БД під конкретне обчислювальне середовище або інформаційну технологію (архітектура "клієнт-сервер", паралельні архітектури, розподілене обчислювальне середовище);

  • проектування БД під призначення системи (інтелектуальний аналіз даних, OLAP, OLTP і т.д.).


Типова бізнес-модель процесу проектування БД

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

  • відобразити суб'єктивну думку розробника БД на процес проектування конкретної БД;

  • врахувати особливості ІТ-проекту, у рамках якого проектується БД;

  • досить швидко скласти план проектування конкретної БД;

  • прорахувати тривалість проектних робіт (створити тимчасову модель проектування).

Розглянемо типову бізнес-модель процесу проектування БД. На рис. 1.12 наведена контекстна діаграма процесу проектування БД.

Як бачимо з рисунка, на вхід процесу проектування БД подаються:

  • інформаційна модель ПО БД: діаграми "сутність-зв'язок" (ER-діаграми);

  • функціональна модель ПО БД: бізнес-модель процесів, діаграми потоку даних (DF-діаграми), діаграми станів, - діаграми життєвих циклів сутностей, специфікації на системи (вимоги), бізнес-правила;

  • загальносистемні вимоги й обмеження;

  • завдання зворотного впливу.

На виході процесу проектування БД формуються такі результати:

  • фізична модель БД, що може бути перетворена у скрипт для створення БД;

  • фізична БД;

  • специфікація модулів додатків БД;

  • план тестування БД.

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





Рисунок 1.12 – Контекстна діаграма процесу проектування БД


відбиває основні найбільш великі професійні завдання (етапи) проектування БД (рис. 1.13).

Такими завданнями (етапами) є:

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

  • створення логічної моделі БД – це етап, на якому на підставі інформаційної моделі ПО БД створюється логічна структура БД, незалежна від її реалізації;

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

реалізації. На цьому етапі виконується перетворення відношення логічної моделі реляційної БД у команди




Рисунок 1.13 – Діаграма декомпозиція процесу проектування БД: перший рівень


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

  • створення фізичної моделі БД: облік впливу транзакцій – це етап, на якому аналізуються можливі транзакції системи, виконується при потребі денормалізація відношення для забезпечення більш високої продуктивності БД;

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

  • проектування модулів додатків БД – це етап, на якому створюються специфікації модулів додатків, розробляються стратегії тестування БД і додатків, створюється план тестування додатків БД і готуються тестові дані;

  • контроль якості проектування БД полягає в перевірці якості результатів проектування на кожному його етапі;

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

Коротко розглянемо бізнес-моделі другого рівня.

Бізнес-модель процесу проектування БД: збір й аналіз вхідних даних

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

Такими завданнями є:

  • збір документації з результатами аналізу ПО БД у вигляді діаграм, специфікацій і вимог;

  • контроль якості результатів аналізу ПО БД;

  • систематизація вимог і специфікацій замовника до БД;

  • підготовка плану проектування БД.





Рисунок. 1.14 – Діаграма декомпозиції процесу проектування БД: збір й аналіз вхідних даних


У ході контролю якості основними моментами діяльності є контроль ER-діаграм і контроль діаграм функціональної моделі ПО. На підставі ER-діаграм створюється логічна модель реляційної БД; на підставі діаграм функціональної моделі розробляється серверний код і проектуються модулі додатків БД.

Систематизація вимог замовника до БД виконується з метою їх адекватного розподілу по етапах проектування БД. Важливим результатом систематизації є висновок про достатність вимог і можливість реалізації БД. Аналіз вимог на можливість реалізації БД у рамках конкретного ІТ-проекту є основою для ухвалення рішення менеджером проекту про можливості реалізації в цілому.

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

Бізнес-модель процесу проектування реляційної БД: створення логічної моделі БД (рис. 1.15). Основною метою етапу створення логічної моделі БД є перетворення інформаційної моделі ПО БД у логічну модель реляційної БД. Створення логічної моделі БД припускає рішення таких основних завдань і виконання операцій у рамках таких завдань:

  • нормалізація сутностей ПО: одержати список атрибутів сутності; визначити функціональні залежності (ФЗ) у сутності; визначити детермінанти сутності; визначити можливі ключі відношення, зокрема, розглянувши унікальний ідентифікатор сутності; виконати нормалізацію сутності (перетворити сутність у відношення); для отриманого відношення призначити первинні ключі; сформувати список кандидатів на зовнішні ключі, якщо необхідно; сформувати бізнес-правила підтримки цілісності сутності, якщо необхідно;

  • нормалізація відношення логічної моделі БД;

  • визначити ступінь зв'язку сутностей;

  • визначити клас приналежності сутності до зв'язку: нормалізувати відношення (дозволити зв'язку);

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

  • перевірка правильності логічної моделі реляційної БД: перевірка відношень на відповідність нормальній формі Бойса-Кодда; перевірка відношень на властивості з'єднання без втрат і збереження функціональних залежностей; запобігання втрати даних;

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

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

  • документування логічної моделі реляційної БД;

  • ухвалення рішення про можливість реалізації побудованої логічної моделі реляційної БД;

ухвалення рішення про розроблення фізичної моделі реляційної БД.

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

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





Рисунок 1.15 – Бізнес-модель процесу створення логічної моделі БД


Бізнес-модель етапу проектування - створення фізичної моделі реляційної БД

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

Це завдання включає виконання ряду обов'язкових послідовних процедур:

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

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

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

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

Створення об'єктів для зберігання даних:

Створення таблиць

Ідентифікування таблиці

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

Визначення первинного ключа

Додавання обмежень

Створення таблиць для взаємозв'язку "множина-до-множини"

Створення індексів

Створення подань

Створення інших об'єктів БД

Перевірка коректності створеної фізичної моделі

На рис. 1.16 нижче подана модель бізнес-процесу першої ітерації фізичної моделі БД.

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

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




Рисунок 1.16 – Декомпозиція етапу проектування - створення першої ітерації фізичної моделі БД : внутрішня схема


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

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

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

  • виходячи з вимог до характеру обробки даних, визначає тип додатка БД;

  • за наявними вимогами й описами виконує систематизацію й опис за можливістю всіх транзакцій;

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

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

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

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

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

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

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

Визначення основного типу додатка БД

Документування й опис транзакцій

Визначення критичних транзакцій

Для кожної критичної транзакції:

Визначення таблиць транзакції

Визначення способу підвищення продуктивності

Денормализація таблиці?

Розбиття таблиці?

Секціонування таблиці?

Кластерізація таблиці?

Побудова додаткових індексів?

Зміна структури внутрішньої схеми БД

Документування змін

Для кожної таблиці БД

Вибір індексів

Визначення транзакцій таблиці

Визначення кардинальності таблиць

Визначення кардинальності колонок

Визначення індексів

Зміна внутрішньої схеми

Короткий розгляд завдань створення серверного коду й підготовки скріпту

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





Рисунок 1.17 – Декомпозиція етапу проектування - створення першої ітерації фізичної моделі БД: внутрішня схема


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

У клієнт-серверному обчислювальному середовищі додаток може взаємодіяти із сервером БД за іншою схемою: коли додаток відправляє запит, цей запит обробляється на сервері, а додатку вертається готовий результат. Робота додатка за другою схемою ґрунтується на використанні так званого серверного коду (server-side code) - будь-якого коду, який виконується комп'ютером, на якому встановлена СКБД. Ядро СКБД виконує цей код у БД і повертає додатку тільки результат. Наприклад, це може бути трішки колонок рядка або обчислене значення.

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

Таким чином, розробка серверного коду зводиться до рішення таких підзадач:

  • ухвалення рішення й створення збережених процедур;

  • ухвалення рішення й створення функцій;

  • ухвалення рішення й створення пакетів;

  • ухвалення рішення й створення тригерів.

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

Завдання створення скріпту БД складається з вирішення великих підзадач:

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

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

  • створення інсталяційного скріпту;

  • документування БД.



1   2   3   4   5   6   7   8   9   ...   19

Схожі:

Конспект лекцій Суми Видавництво Сумду 2009 Міністерство освіти І науки України Сумський державний університет iconКонспект лекцій Суми Сумський державний університет 2012 Міністерство освіти і науки, молоді та спорту України Сумський державний університет
Внутрішній економічний механізм підприємства: конспект лекцій / укладач Н. В. Мішеніна.– Суми : Сумський державний університет, 2012....
Конспект лекцій Суми Видавництво Сумду 2009 Міністерство освіти І науки України Сумський державний університет iconКонспект лекцій Суми Видавництво Сумду 2010 міністерство освіти І науки україНи
Затверджено на засіданні кафедри фінансів як конспект лекцій з дисципліни "Інформаційні системи і технології у фінансах"
Конспект лекцій Суми Видавництво Сумду 2009 Міністерство освіти І науки України Сумський державний університет iconМіністерство освіти І науки україни сумський державний університет до друку та в світ дозволяю на підставі «Єдиних правил»
Методи прийняття управлінських рішень. Конспект лекцій / Укладач Д. О. Смоленніков. – Суми: Вид-во СумДУ, 2008. – 89 с
Конспект лекцій Суми Видавництво Сумду 2009 Міністерство освіти І науки України Сумський державний університет iconКонспект лекцій Суми Видавництво Сумду 2009
Внутрішній економічний механізм підприємства: Конспект лекцій/ Укладач І. В. Новикова. – Суми: Вид-во СумДУ, 2009. – 185с
Конспект лекцій Суми Видавництво Сумду 2009 Міністерство освіти І науки України Сумський державний університет iconМіністерство освіти І науки україНи Сумський державний університет Менеджмент персоналу
Менеджмент персоналу: конспект лекцій / Укладач: К. В. Ілляшенко. – Суми: Вид-во СумДУ, 2010. – 78с
Конспект лекцій Суми Видавництво Сумду 2009 Міністерство освіти І науки України Сумський державний університет iconКонспект лекцій Суми Видавництво Сумду 2009
Психологія творчості : Конспект лекцій / Укладач О. А. Кривопишина.– Суми: Вид-во СумДУ, 2009.– 81 с
Конспект лекцій Суми Видавництво Сумду 2009 Міністерство освіти І науки України Сумський державний університет iconКонспект лекцій Суми Видавництво Сумду 2009
Психологія творчості : Конспект лекцій / Укладач О. А. Кривопишина.– Суми: Вид-во СумДУ, 2009.– 81 с
Конспект лекцій Суми Видавництво Сумду 2009 Міністерство освіти І науки України Сумський державний університет iconМіністерство освіти І науки україни сумський державний університет граматичні таблиці з української мови для студентів-іноземців підготовчого відділення Суми Видавництво СумДУ
Граматичні таблиці з української мови для студентів-іноземців підготовчого відділення / Уклад.: Н. О. Ворона, Т. О. Дегтярьова, Н....
Конспект лекцій Суми Видавництво Сумду 2009 Міністерство освіти І науки України Сумський державний університет iconМіністерство освіти І науки україни сумський державний університет історія України
України: навчальні матеріали для студентів-іноземців підготовчого відділення / Укладачі: М. С. Казанджиєва, О. П. Коньок, Н. О. Тубол,...
Конспект лекцій Суми Видавництво Сумду 2009 Міністерство освіти І науки України Сумський державний університет iconМіністерство освіти І науки україни сумський державний університет медичний інститут кафедра інфекційних хвороб І епідеміології
Методичні рекомендації до семінарських занять лікарів-інтернів спеціальності “Інфекційні хвороби” / Укладачі М. Д. Чемич, Н.І. Ільїна,...
Додайте кнопку на своєму сайті:
Документи


База даних захищена авторським правом ©zavantag.com 2000-2013
При копіюванні матеріалу обов'язкове зазначення активного посилання відкритою для індексації.
звернутися до адміністрації
Документи