На головну

продуктивність БД

  1. Q - продуктивність;
  2. Автогрейдери. Основні параметри, робочі органи, продуктивність, область застосування.
  3. Аналіз продуктивності праці. Вплив окремих факторів на продуктивність праці.
  4. Бульдозера, компоновочная схема, робочі органи, продуктивність, область застосування.
  5. Вплив часу простою під навантаженням і розвантаженням на продуктивність рухомого складу. Шляхи його зниження.
  6. Вплив техніко-експлуатаційних показників на продуктивність роботи рухомого складу.
  7. Закон спадної віддачі і його вплив на продуктивність ресурсів.

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

22. Методологія фізічного проектування БД

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

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

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

23. Архітектура та принципи проектування інтерфейсу користувача для ЗАСТОСУВАННЯ БД

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

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

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

24. Недоліки реляційної моделі Даних. Маніфест СКБД третього поколение

Недоліки реляційної моделі:

§ далеко не завжди предметна область може бути представлена ??у вигляді "таблиць";

§ в результаті логічного проектування з'являється безліч "таблиць". Це призводить до труднощів розуміння структури даних;

§ БД займає відносно багато зовнішньої пам'яті;

§ відносно низька швидкість доступу до даних.

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

1. Наявність розвиненої системи типів.

2. Підтримка механізму наслідування.

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

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

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

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

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

8. Важливим є наявність оновлюваних уявлень.

9. Засоби вимірювання продуктивності не повинні мати ніякого відношення до моделей даних і не повинні в них бути присутнім.

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

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

12. Чи погано це чи добре, але мова SQL повинен залишатися "межгалактическим мовою роботи з даними".

13. Запити та відповіді на них повинні складати найнижчий рівень взаємодії клієнта і сервера

25. Стандарт ODMG. Система управління об'єктнімі данімі. Архітектура та основні компоненти об'єктної моделі Даних

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

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

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

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

Архітектура CORBA визначає архітектуру середовищ, що використовують ORB-брокери. Вона є основою будь-якого OMG-сумісного компонента, визначаючи складові частини ORB-брокера і пов'язаних з ним структур.

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

26. Особливості архітектури ООСКБД: користувач може отримати доступ до об'єктів у Зовнішній пам'яті, варіанти архітектури «клієнт-сервер», управління методами в ООСКБД


 Мал. 2.1. Однорівнева модель зберігання даних в ООСУБД

Об'єктно-орієнтована СУБД (ООСУБД)

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

2. ООСУБД може потім виконати кілька різних перетворень.

3. Додаток здійснює безпосередній доступ до об'єкта і оновлює його в міру необхідності.

4. Коли додатком потрібно зробити внесені зміни перманентними або просто вивантажити на час сторінку з кешу на диск, то перед копіюванням сторінки на зовнішній пристрій зберігання ООСУБД повинна виконати зворотні перетворення, аналогічні описаним вище.

Архітектура клієнт / сервер: 1. Сервер об'єктів (в цьому підході робиться спроба розподілити обробку між двома компонентами. Зазвичай серверний процес відповідає за управління сховищем, блокування, висновок даних на вторинні пристрої зберігання, реєстрацію клієнтів, процедури відновлення, підтримку безпеки і забезпечення цілісності, оптимізацію запитів і виконання збережених процедур. Клієнт відповідає за управління транзакціями і взаємодія з мовою програмування); 2. Сервер сторінок (в цьому підході велика частина функцій БД виконується клієнтом, сервер відповідає за доступ до вторинних пристроїв зберігання і надання сторінок на вимогу клієнта); 3. Сервер БД (в цьому підході велика частина функцій БД виконується сервером, клієнт просто передає запити серверу, отримує результати і передає їх з додатком).

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

27. Преимущества и Недоліки ООСКБД. Порівняння об'єктного и семантичного підходів до моделювання Даних

переваги:

1. Поліпшення можливості моделювання (дозволяє більш точно моделювати реальний світ. Об'єкт може зберігати всі зв'язки, якими він пов'язаний з іншими об'єктами); 2. Можливість розширення (в ООСУБД допускається створення нових абстрактних типів даних на основі існуючих типів); 3. Усунення проблеми невідповідності (простий інтерфейс між мовою маніпулювання даними та мовою програмування дозволяє усунути проблему їх невідповідності); 4. Більш виразний мову запитів (визначений декларативний мову запитів, побудований на об'єктно-орієнтованої формі мови SQL); 5. Підтримка еволюції схеми (сувора зв'язок між даними і додатками в ООСУБД робить еволюцію схеми більш гнучкою); 6. Підтримка довготривалих транзакцій (спірно); 7. Застосування для складних спеціалізованих додатків баз даних; 8. Підвищена продуктивність.

недоліки:

1. Відсутність універсальної моделі даних; 2. Недостатність досвіду експлуатації; 3. Відсутність стандартів; 4. Вплив оптимізації запитів на інкапсуляцію (для оптимізації запитів і організації ефективного доступу до БД необхідно володіти знаннями про особливості реалізації); 5. Вплив блокування на рівні об'єкта на продуктивність (у багатьох СУБД блокування використовується як основа побудови протоколу управління паралельною. Однак застосування блокування на рівні об'єкта може викликати проблеми з блокуванням щодо ієрархії успадкування, а також зробити істотний вплив на загальну продуктивність системи); 6. Складність; 7. Відсутність підтримки уявлень; 8. Недостатність коштів забезпечення безпеки.

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

28. Розшірена реляційна модель Даних и об'єктно-реляційні СКБД

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

Найчастіше використовується термін Об'єктно-реляційна СУБД або ОРСУБД. Розробка стандартів в цій сфері побудована на розширенні стандарту мови SQL.



Створення і перевірка глобальної логічної моделі даних | Порівняння моделей даних

Проекція (Project) | Вибір (Select) | З'єднання (Join) | Команди управління транзакціями | SELECT DISTINCT Блюдо, Вихід, Основа FROM Страви; | закриття курсорів | Durability - Довговічність | Вимоги, що пред'являються до інфологічної моделі | Зв'язки між об'єктами | категоризація |

© um.co.ua - учбові матеріали та реферати