Реферат - СУБД
32

яким буде реєструватися сам SQL Server, краще після установки змінити це ім'я з LocalSystem на "нормальне" ім'я. Це стане в нагоді при створенні резервних копій на жорстких дисках інших комп'ютерів, а також при роботі з Microsoft Exchange. Видалена і автоматична інсталяція Є два способи полегшити собі роботу по установці SQL Server. Перший - це видалена інсталяція, використовуючи яку ви можете не переходжувати від комп'ютера до комп'ютера, і при цьому встановити SQL Server на декілька серверів. Другий спосіб - автоматична інсталяція, при якій ви наперед створюєте текстовий файл, що містить параметри інсталяції і звільняючий вас від необхідності відповідати на питання програми setup. ПРОБЛЕМИ ПРИ УСТАНОВЦІ? Якщо ви перевірили відповідність вашого комп'ютера вимогам, про які ми говорили вище, то проблем, швидше за все, не буде. Але краще бути готовими до всього і знати, що робити, якщо вони з'являться. Де можна знайти інформацію про те, що трапилося під час інсталяції: 1. Журнал реєстрації подій Windows NT. 1. Журнал помилок SQL Server (знаходиться в каталозі '\SQL60\LOG\'). 3.Выходные файли інсталяційних скриптів. В директорії '\SQL60\INSTALL\' ви знайдете близько 20 файлів з розширенням '.SQL' (скрипти) і відповідних їм файлів з тими ж іменами і розширенням '.OUT' #@:. В процесі інсталяції SQL Server виконує скрипти #@; і результати виконання записуються у вихідні файли. Проглядаючи вихідні файли, ви можете знайти повідомлення про помилки. ОПТИМІЗАЦІЯ І НАСТРОЙКА MICROSOFT SQL SERVER Ключі до продуктивності * Структура бази даних; * Шляхи доступу до даних; * Апаратура; * Фізичний розподіл даних; * Настройка параметрів середовища і SQL Server Проектування бази даних - фундамент продуктивності Грамотне проектування баз даних, на думку багатьох фахівців і моєму власному, є найкритичнішим моментом в оптимізації продуктивності системи, побудованої на SQL Server. Якщо система поволі працює - швидше за все, справа в поганому проектуванні структури таблиць, запитів і індексів. І саме цьому слід надавати головну увагу. Слід ухвалювати проектні рішення, постійно задаючись питанням - як це рішення позначиться на продуктивності? І в першу чергу, тут важливе оптимальне логічне проектування баз даних. Логічне проектування бази даних Оптимальне логічне проектування баз даних базується на вживанні трьох основних методологій: 1. Моделювання даних; 2. Нормалізація; 3. Розумна денормалізація Моделювання даних Для моделювання даних традиційно застосовується методологія діаграм "Єство-Зв'язок", яка дозволяє побудувати закінчену логічну модель даних, тобто уявлення у вигляді зв'язаних таблиць. Існують різні модифікації цієї методології, як правило реалізовувані фірмами-виробниками CASE-інструментів в своїх продуктах. Базова методологія побудови діаграм "Єство-Зв'язок" зафіксована в стандарті IDEF1X. Деякі CASE-інструменти засновані на методологіях, що розширюють можливості цього стандарту. До таких інструментів відноситься, зокрема, S-Designor фірми Powersoft. Є і інші методології, зокрема Об'єктно-ролеве моделювання, яке дозволяє описувати наочну область на більш абстрактному рівні, ніж моделювання "Єство-Зв'язок", принаймні базовий варіант останньої. Об'єктно-ролеве моделювання реалізовано в CASE-інструменті InfoModeler фірми Asymetrix. Вживання S-Designor і InfoModeler розглянуто в докладі "Проектування структур баз даних з використанням CASE-інструментів S-Designor і InfoModeler". Нормалізація В процесі побудови логічної моделі здійснюється також нормалізація, тобто побудована модель задовольняє вимогам трьох рівнів нормалізації: 1. Перша нормальна форма - відсутність багатозначних полів. 2. Друга нормальна форма - кожне неключове поле в таблиці повинне залежати від всього первинного ключа, а не від якої-небудь його частини. 3. Третя нормальна форма - неключове поле не повинне залежати від іншого неключового поля. По суті, нормалізація приводить до більшої кількості більш вузьких таблиць в логічній моделі. Дотримання правил нормалізації знижує надмірність даних і, відповідно, складність їх оновлення і займаний ними об'єм на носії. Зв'язки між одержаними таблицями дозволяються через побудову складних сполучаючих запитів. Оптимізатор запитів SQL Server уміє будувати ефективні плани виконання запитів, що зв'язують високо нормалізовані таблиці. Цьому сприяє також побудова індексів, заснована на зв'язку первинних і зовнішніх ключів таблиць. CASE-інструменти, як правило, будують логічну модель в третій нормальній формі. Денормалізація Проте часто, розумна, саме розумна, свідома денормалізація логічної структури може підвищити швидкість виконання певних запитів. Якщо проектування нормалізованої структури йде, так би мовити, "від даних", то денормалізація йде "від процесів". Тобто, денормалізація повинна бути заснована на знанні того, які дії здійснюватимуться з даними при роботі з ними клієнтських додатків. Ось декілька практичних рад з денормалізації: * Якщо спроектована база даних вимагає скріплення в одному запиті 4-х і більш таблиць, варто ввести надмірність, додаючи поля в таблиці або цілі таблиці. * Заміните довгі ключі на штучно введені короткі ключі і текстові поля на символьні рядки обмеженої довжини. * Якщо певна група запитів зачіпає тільки частину полів широкої таблиці, її можна розбити на декілька більш вузьких таблиць, продублювавши в них первинний ключ початкової таблиці. Це може зменшити кількість операцій уведення-виведення і полегшити одночасну роботу різних користувачів. * Якщо певна група запитів зачіпає тільки частину рядків таблиці великого об'єму, її можна розбити по горизонталі на декілька таблиць, особливо якщо певні групи користувачів звертаються до різних горизонтальних підмножин таблиці. Суперечності логічного проектування Нормалізація і денормалізація - дві діалектично суперечливі стратегії, які необхідно застосовувати при проектуванні логічної структури. І ця не єдина суперечність в цьому процесі. Наприклад - використовування типів даних із змінною довжиною приводить, з одного боку, до скорочення займаного

---

Сторінки: 1 2 3 4 5 6 7 8 9 10