Здавалка
Главная | Обратная связь

Побудова концептуальної моделі у вигляді ER-діаграми



Перший етап

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

З метою визначення сутностей необхідно:

1) зрозуміти, яка інформація буде оброблятися, чи можна зафіксувати її як сутність;

2) привласнити ім’я;

3) виявити та поіменувати атрибути;

4) визначити унікальний ідентифікатор.

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

Другий етап

Локальна модель об’єднується в узагальнену концептуальну модель. Вона повинна задовольняти вимогам:

1) адекватно відображати уявлення користувача;

2) давати можливість відповідей на запити користувачів з мінімальними витратами;

3) представляти дані з мінімальним дублюванням.

Це процес є творчим і не може бути формалізованим, проте є певні закономірності при виборі варіанту побудови.

Варіативність моделювання обумовлюється неоднозначністю вибору сутності та зв’язків. Введемо сутність «КАФЕДРА» з атрибутами «Номер», «Назва». «ФАКУЛЬТЕТ» складається з «КАФЕДР». Після того, як вибраний раціональний вигляд моделі, дається ім’я сутностям, атрибутам та зв’язкам.

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

Третій етап

Об’єднання локальних моделей виконується такими шляхами:

1) злиття ідентичних елементів;

2) встановлення зв’язків між наборами сутностей;

3) введення нових агрегованих елементів для представлення зв’язків між елементами різних моделей;

4) узагальнення різноманітних сутностей;

5) злиття ідентичних моделей.

17. Побудова концептуальної моделі у вигляді ER-діаграми. Моделювання локальнихпредставлень

Локальна модель повинна задовольняти вимогам:

1.адекватно відображати уявлення користувача;

2.давати можливість відповідей на запити користувачів з мінімальними витратами;

3.представляти дані з мінімальним дублюванням.

Усуваються синоніми та распливчаті найменування.

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

Варіативність моделювання обумовлюється неоднозначністю вибору сутностей, атрибутів і зв'язків. В одному варіанті можна щось узяти за сутність, в іншому варіанті це ж можна узяти за атрибут (декілька атрибутів), в третьому варіанті це можна визначити як зв'язок. Так, наприклад, раніше ми визначили сутність ФАКУЛЬТЕТ з атрибутами "номер факультету", "назва факультету". Введемо сутність КАФЕДРА з атрибутами "номер кафедри", "назва кафедри". Між цими сутностями є зв'язок "факультет складається з кафедр". Можливий інший варіант, в якому вищезгаданий зв'язок представляється через атрибути сутностей (в сутності ФАКУЛЬТЕТ введемо додаткові атрибути, що представляють номери і назви усіх кафедр цього факультету).

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

  • усуваються розпливчаті найменування (всі найменування повинні однозначно розумітися кожним користувачем);
  • усуваються синоніми (різні найменування одного і того ж поняття);
  • усуваються омоніми (одне і те ж найменування різних понять).

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

18. Побудова концептуальної моделі у вигляді ER-діаграми. Об’єднання локальнихпредставлень

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

 

Об’єднання локальних моделей виконується такими шляхами:

1. злиття ідентичних елементів;

2. встановлення зв’язків між наборами сутностей;

3. введення нових агрегованих елементів для представлення зв’язків між елементами різних моделей;

4. узагальнення різноманітних сутностей;

5. злиття ідентичних моделей.

Злиття – якщо однакове смислове навантаження. Об’єднання моделей з ідентичними елементами здійснюється шляхом злиття їх в один. Два набори «СПЕЦІАЛЬНІСТЬ» мають в двох моделях одне і те саме значення і можуть бути замінені одним і тим самим набором сутностей.

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

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

19. Побудова концептуальної моделі у вигляді ER-діаграми. Обмеження цілісності

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

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

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

Зовнішні обмеження пов’язані з адекватністю віддзеркалення предметної області (обмеження на рік народження: ПОТОЧНИЙ РІК - 17 > GR > ПОТОЧНИЙ РІК - 90; або перерахування скінчених значень даних).

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

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

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

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

Визначимо основні структури моделі даних СУБД, використовувані для представлення сутностей, зв’язків і т.п.

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

Поіменована сукупність полів - використовується для представлення сукупностей атрибутів сутностей.

Екземпляр запису - запис із конкретним значенням полів.

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

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

Набір файлів - поіменована сукупність файлів, які обробляються в системі.

Група - поіменована сукупність елементів даних, або елементів даних інших груп.

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

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

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

Модель даних СУБД описується таким чином:

1) визначені можливі типи і характеристики логічних структур даних;

2) задані правила складання структур;

3) визначений спосіб представлення зв’язків за допомогою додаткових полів;

4) визначені можливі дії над структурами і правила їх виконання.

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

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

 

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

Мережева модель даних - одна з найбільш ранніх моделей даних СУБД. Пов’язана з Комітетом CODASYL (Conference of Data System Languages), що є стандартизуючим органом в системі БД. Структура даних визначається в термінах попереднього розділу. Реалізація групових відношень здійснюється з використанням спеціально виділених додаткових полів - покажчиків, які встановлюють зв’язки між власником і членом групового відношення.

Якщо один із варіантів встановлення зв’язку один до одного очевидний, то можливість представлення зв’язків 1 до N, M до N є проблематичною. Це пояснює введення додаткового типу записів і відповідного файлу.

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

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

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

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

Розглянемо приклад запису частини ER-діаграми в термінах мережевої СУБД. розглянемо екземпляри сутностей «СТУДЕНТ» і «ФАКУЛЬТЕТ». Нехай студенти Іванов, Петров, Мішин вчаться на факультеті МВК, Сидоров і Кащенко - на механіко-математичному факультеті. Відзначимо, що в додатковому файлі відсутній подальший зв’язок з одним із елементів.

СУБД, що підтримують цю модель, широко використовуються (IDMS, UniBank та інші їхні аналоги). Прикладом є db_Vista III, реалізована мовою C, тому є мобільною і може бути перенесена на будь-яку платформу.

 

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

Ієрархічна модель даних - частковий випадок мережевої моделі, в якій, на відміну від мережевої, існує ряд особливостей:

1) групові відношення є відношеннями підпорядкованості (вихідна група - предок, підпорядковані - нащадком);

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

3) може існувати декілька дерев.

Операція завжди починає пошук з кореневої вершини, що є перевагою. Програми, що реалізовують операції з цією моделлю, є істотно простішими. СУБД з цією структурою досить широко використовувались в обчислювальних комп’ютерах. Прикладами є СУБД «Ока», «Кама», що широко використовувалися в СРСР і пізніше перетворилися на ІНЕС.

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

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

 

23. Друга стадія концептуального проектування БД. Типові моделі даних СУБД і представлення концептуальної моделі. Реляційна модель даних

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

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

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

Розглянемо зразок створення ER-діаграми в реляційній моделі даних (мал.5.2)

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

Недолік реляційної моделі: дублювання інформації при представленні зв’язків.

 

24. Друга стадія концептуального проектування БД. Типові моделі даних СУБД і представлення концептуальної моделі. Багатовимірна модель даних

Розглянемо сутність «УСПІШНІСТЬ СТУДЕНТІВ» з атрибутами «Кількість 2», «Кількість 3», «Кількість 4», «Кількість 5». Якщо використовувати реляційну модель, необхідно вводити таблицю для кожного курсу і кожного року. Тому для цього використовують багатовимірну модель даних - використання технології OLAP (On-line Analytical Processing). Багатовимірність позначає багатовимірне логічне представлення в структурі інформації, не пов’язане з багатовимірністю.

Кожна грань куба є розмірністю. Основними поняттями є вимір та комірка.

Вимір(dimension) - впорядкований набір значень, що приймається конкретним параметром, відповідно одній з граней гіперкуба. Комірка(cell) - поле, відповідне атрибуту сутності, значення якого однозначно визначається фіксованим набором параметрів

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

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

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

 

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

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

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

Таким чином, створення працездатної бази даних можна умовно розділити на три етапи:

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

кодування – створення структур баз даних і закінченого інтерфейсу користувача і

супровід готової бази даних.

Основна ідея застосування засобів автоматизованого проектування баз даних полягає в тому, що процес ручного кодування починається лише після закінчення процесу проектування. На стадії проектування схема бази даних і інтерфейс користувача для доступу до бази даних створюються автоматично, виходячи з опису концептуальної моделі, за допомогою так званих CASE-засобів (Computer Aided Software/System Engineering). Звичайно, створений таким чином інтерфейс не є закінченим програмним продуктом, проте він дозволяє замовникові оцінити можливості кінцевого продукту і внести свої корективи. Лише після схвалення замовником робочого прототипу розробники приступають до ручного кодування – створення закінченого додатку.

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

На практиці частіше за все CASE-засоби використовуються для створення схеми бази даних у вигляді ER-діаграм і генерації структур баз даних для конкретної СУБД. Після отримання від замовника змін розробники вносять відповідні виправлення до діаграми "сутність – зв'язок" і заново генерують структури баз даних. Засоби автоматичної генерації інтерфейсів використовуються рідше.

В наш час практично кожен виробник СУБД пропонує власний програмний продукт автоматизованого проектування. Це Oracle Designer (Oracle), Power Desinger (Sybase) та інші.

 

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

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

Розглянемо для прикладу конкретну схему відношень і проаналізуємо її недоліки. Припустимо, що дані про студентів, факультети, спеціальності, включені в таблицю з наступною схемою відношення: СТУДЕНТ (Код студента, Прізвище, Назва факультету, Назва спеціальності).

Ця схема відношень обумовлює такі недоліки відповідної бази даних:

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

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

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

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

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

 

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

Нехай R(A1, A2 ..., An) – схема відношення, а X і Y – підмножини {A1, A2 ..., An}.

Функціональна залежність на відношенні R – це твердження вигляду "Якщо два кортежі R збігаються по атрибутах множини X {A1, A2 ..., An} (тобто ці кортежі мають у відповідних один одному компонентах одні і ті ж значення для кожного атрибуту множини X), то вони повинні збігатися і по атрибутах множини YÌ {A1, A2 ..., An}. Формально ця залежність записується виразом X ® Y, причому говориться, що X функціонально визначає Y.

Часто використовується інше твердження: X функціонально визначає Y або Y функціонально залежить від X (позначається X ® Y) тоді і лише тоді, коли кожне значення множини X відношення R пов'язане з одним значенням множини Y відношення R. Інакше кажучи, якщо два кортежі R збігаються за значенням X, вони збігаються і за значенням Y.

Зауваження. Взагалі кажучи, під терміном "відношення" можуть матися на увазі два поняття:

· відношення як змінна, яка може набувати різних значень (таблиця, в рядки і стовпці якої можуть бути вписані різні значення);

· відношення, як набір конкретних значень (таблиця із заповненими елементами).

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

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

Приклад функціональних залежностей для відношення ІСПИТОВА ВІДОМІСТЬ

Код студента ® ПрізвищеКод студента, Код іспиту ® Оцінка

Приклад функціональних залежностей для відношення СТУДЕНТ, наведених на початку цієї лекції

Код студента ® ПрізвищеКод студента ® Факультет

Відмітимо, що остання залежність існує за умови, що один студент не може навчатися на декількох факультетах.







©2015 arhivinfo.ru Все права принадлежат авторам размещенных материалов.