Недостатки

Масштабируемость

Достоинства

Обзор архитектуры

· Клиент — это интерфейсный (обычно графический) компонент, который представляет первый уровень, собственно приложение для конечного пользователя.

· Сервер приложений располагается на втором уровне. На втором уровне сосредоточена бо́льшая часть бизнес-логики.

· Сервер базы данных обеспечивает хранение данных и выносится на третий уровень. Обычно это стандартная реляционная или объектно-ориентированная СУБД.

В «правильной» (с точки зрения безопасности, надёжности, масштабирования) конфигурации сервер базы данных находится на выделенном компьютере (или кластере), к которому по сети подключены один или несколько серверов приложений, к которым, в свою очередь, по сети подключаются терминалы.

· конфигурируемость —

· высокая безопасность

· высокая надёжность

· низкие требования к скорости канала (сети) между терминалами и сервером приложений

· низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости.

· более высокая сложность создания приложений;

· сложнее в разворачивании и администрировании;

· высокие требования к производительности серверов

· высокие требования к скорости канала (сети)

4. Класифікація БД за структурою організації даних.

Информация в базах данных структурирована на отдельные записи, которыми называют группу связанных между собой элементов данных. Характер связи между записями определяет два основных типа организации баз данных: иерархический и реляционный.

Иерархическая модель данных — представление базы данных в виде древовидной (иерархической) структуры, состоящей из объектов (данных) различных уровней.

В иерархической базе данных записи упорядочиваются в определенную последовательность, как ступеньки лестницы, и поиск данных может осуществляться последовательным «спуском» со ступени на ступень. Иерархическая база данных по своей структуре соответствует структуре иерархической файловой системы.

Реляционная база данных, по сути, представляет собой двумерную таблицу.
Столбцы таблицы называются полями: каждое поле характеризуется своим именем и топом данных. Поле БД – это столбец таблицы, содержащий значения определенного свойства.

В реляционной БД используются четыре основных типов полей:

· Числовой,

· Символьный (слова, тексты, коды и т.д.),

· Дата (календарные даты в форме «день/месяц/год»),

· Логический (принимает два значения: «да» - «нет» или «истина» - «ложь»).

Строки таблицы являются записями об объекте. Запись БД – это строка таблицы, содержащая набор значения определенного свойства, размещенный в полях базы данных.

5. Ієрархічна БД. Переваги та недоліки.

Иерархическая модель данных — представление базы данных в виде древовидной (иерархической) структуры, состоящей из объектов (данных) различных уровней.

Между объектами существуют связи, каждый объект может включать в себя несколько объектов более низкого уровня. Такие объекты находятся в отношении предка (объект более близкий к корню) к потомку (объект более низкого уровня), при этом возможна ситуация, когда объект-предок не имеет потомков или имеет их несколько, тогда как у объекта-потомка обязательно только один предок. Объекты, имеющие общего предка, называются близнецами.

ВООБЩЕМ СКАЗАТЬ, ТО СИСТЕМА ОДНА ИЗ ПИЕРВЫХ, СТАРАЯ И ВПРИНЦИПЕ НИГДЕ НЕИСПОЛЛЬЗУЕТТСЯ, ТАК КАК НА СМЕНУ ПРИШЛИ РЕЛЯЦИОННЫЕ БД

Основной недостаток иерархической структуры базы данных - невозможность реализовать отношения «многие-ко многим», а также ситуации, когда запись имеет не сколько предков.
Иерархические базы данных наиболее пригодны для моделирования структур, являющихся иерархическими по своей природе.

Трудности в использовании иерархической базы данных возникают при изменении типа запроса

Навигация в иерархической базе данных подобна навигации в реляционной и сетевой базах данных, она также связана с определенным порядком выборки и установкой текущих. [ 3 ]

6. Мережева модель БД. Переваги та недоліки.

Мережева модель БД — представляється сукупністю об'єктів різ­них рівнів, проте структура даних передбачає, що у кожного об’єкта може бути як кілька батьківських об’єктів, так і кілька об’єктів-нащадків.

Обмеження цілісності – передбачає збереження зв'язків між об'єктами.

До основних понять мережевої моделі бази даних належать: рівень, елемент (вузол), зв'язок.

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

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

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

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

7. Реляційна БД. Переваги та недоліки.

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

Реляційна модель орієнтована на організацію даних у вигляді двовимірних таблиць. Кожна реляційна таблиця являє собою двовимірний масив і має наступні властивості:

· кожен елемент таблиці - один елемент даних

· всі осередки в стовпці таблиці однорідні, тобто всі елементи в стовпці мають однаковий тип (числовий, символьний і т. д.)

· кожен стовпець має унікальне ім'я

· однакові рядки в таблиці відсутні

· порядок проходження рядків і стовпців може бути довільним

Базовими поняттями реляційних СУБД є:

· атрибут

· ставлення

· кортеж

8. Відносини та їх властивості. Домени. Властивості домену.

Відношення в реляційному моделюванні — набір кортежів, інакше відомий як таблиця бази даних. Поняття відно­шен­ня покладено в основу реляційних моделей, яке подають у вигляді двовимірної таблиці. Реляційна БД — це набір взаємопов’язаних відношень. Кожне відношення (таблиця) в ЕОМ подається як файл. Відношення можна поділити на два класи: об’єктні і зв’язкові.

Об’єктні відношення зберігають дані про інформаційні об’єк­ти предметної області. Наприклад: клієнт (код клієнта, назва клієнта, адреса, телефон) є об’єк­тним відношенням. В об’єктному відношенні один з атрибутів однозначно ідентифікує окремий об’єкт. Такий атрибут називається первинним ключем відношення. В наведеному відношенні роль ключа виконує атрибут «код клієнта». Ключ може вмикати кілька атрибутів, тобто бути складеним. В об’єктному відношенні не повинно бути рядків з однаковим ключем, тобто не допускається дублювання об’єктів. Це основне обмеження реляційної моделі для забезпечення цілісності даних.

Зв’язкове відношення зберігає ключі двох або більше об’єкт­них відношень. Ключі зв’язкового відношення мають на меті встановлення зв’язків між об’єктними відношеннями. Наприклад, розглянемо ще одне об’єктне відношення БАНК(код банку, назва банку, адреса банку). Тоді зв’язкове відношення БАНК-КЛІЄНТ (код банку, код клієнта) буде сполучним між двома об’єктними відношеннями БАНК іКЛІЄНТ. У зв’язковому відношенні можуть дублюватися ключові атрибути. Крім ключів, за якими встановлюють зв’язок у зв’язковому відношенні, можуть бути ще й інші атрибути, які функціонально залежать від цього складового ключа. Ключі в зв’язкових відношеннях називаються зовнішніми ключами, оскільки вони є первинними ключами інших відношень. Реляційна модель накладає на зовнішні ключі обмеження, яке називають посилковою цілісністю. Воно необхідне для забезпечення цілісності даних. Це означає, що кожному зовнішньому ключеві має відповідати рядок якогось об’єктного відношення.

У реляційній БД накладається ще одне обмеження — відношення мають бути нормалізовані.

12. Рівні моделювання баз даних.

При разработке базы данных обычно выделяется несколько уровней моделирования, при помощи которых происходит переход от предметной области к конкретной реализации базы данных средствами конкретной СУБД.

Можно выделить следующие уровни:

· Сама предметная область

· Модель предметной области

· Логическая модель данных

· Физическая модель данных

· Собственно база данных и приложения

Предметная область - это часть реального мира, данные о которой мы хотим отразить в базе данных. Таким образом, важность данных зависит от выбора предметной области.

Модель предметной области. Модель предметной области - это наши знания о предметной области. Знания могут быть как в виде неформальных знаний в мозгу эксперта, так и выражены формально при помощи каких-либо средств. В качестве таких средств могут выступать текстовые описания предметной области, наборы должностных инструкций, правила ведения дел в компании и т.п.

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

Логическая модель данных является начальным прототипом будущей базы данных. Логическая модель строится в терминах информационных единиц, но без привязки к конкретной СУБД. Основным средством разработки логической модели данных в настоящий момент являются различные варианты ER-диаграмм (Entity-Relationship, диаграммы сущность-связь). Одну и ту же ER-модель можно преобразовать как в реляционную модель данных, так и в модель данных для иерархических и сетевых СУБД, или в постреляционную модель данных.

Физическая модель данных. На еще более низком уровне находится физическая модель данных. Физическая модель данных описывает данные средствами конкретной СУБД. Мы будем считать, что физическая модель данных реализована средствами именно реляционной СУБД, хотя, как уже сказано выше, это необязательно. Отношения, разработанные на стадии формирования логической модели данных, преобразуются в таблицы, атрибуты становятся столбцами таблиц, для ключевых атрибутов создаются уникальные индексы, домены преображаются в типы данных, принятые в конкретной СУБД.

Ограничения, имеющиеся в логической модели данных, реализуются различными средствами СУБД, например, при помощи индексов, декларативных ограничений целостности, триггеров, хранимых процедур.

Собственно база данных и приложения. И, наконец, как результат предыдущих этапов появляется собственно сама база данных. База данных реализована на конкретной программно-аппаратной основе, и выбор этой основы позволяет существенно повысить скорость работы с базой данных. Но опять решения, принятые на предыдущем уровне - уровне физического проектирования, определяют границы, в пределах которых можно принимать решения по выбору программно-аппаратной платформы и настройки СУБД.

Таким образом ясно, что решения, принятые на каждом этапе моделирования и разработки базы данных, будут сказываться на дальнейших этапах. Поэтому особую роль играет принятие правильных решений на ранних этапах моделирования.

13. Типи зв'язків. Визначення зв'язку. Один-до-одного. Один-до-багатьох. Багато-до-одного. Багато-до-багатьох.

Связь — отношение общности, соединения или согласованности.

Связи, поддерживаемые между обьектами в БД разделяются на три основних типа:

- «один к одному»;

- «Один ко многим»;

- «многие к одному»;

- «многие ко многим».

Кортеж отношения — это множество пар вида «имя атрибута, значение атрибута», причем каждый атрибут отношения один и только один раз входит в кортеж. # (Саша, 19, 222222) или (Катя, 20, 353453) или (Настя, 18, 424242)

1) Определение святи «Один к одному» полностью соответствует ее названию. Связью «Один к одному» наз. такая связь, из наличия которой следует, что если имеется какая-то одна строка в одной таблице, то должна бать точно одна соответствующая ей строка в другой таблице. (в каждый момент времени каждому кортежу А соответствует 0 или 1 кортеж В).

2) Связь «один ко многим». При типе связи один-ко-многим запись из одной таблицы связывается с несколькими записями другой таблицы, но записи из второй таблицы связываются только с одной из записей первой таблицы.(каждому кортежу А соответствует несколько кортежей В)

3) «Многие к одному» (множеству кортежа А соответствует один кортеж В)

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

14. Функціональні залежності. Визначення функціональної залежності.

Функціональна залежність (далі часто ФЗ) — концепція, що лежить в основі багатьох питань, пов'язаних з реляційними базами даних, включаючи, зокрема, їхнє проектування. Математично являє собою бінарне відношення між множинами атрибутів даного відношення і є, по суті, зв'язком типу «один-до-багатьох». ФЗ забезпечує основу для наукового підходу до розв'язання деяких проблем, оскільки володіє багатим набором цікавих формальних властивостей.

Связь «один ко многим». При типе связи один-ко-многим запись из одной таблицы связывается с несколькими записями другой таблицы, но записи из второй таблицы связываются только с одной из записей первой таблицы.(каждому кортежу А соответствует несколько кортежей В)

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

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

Функциональная зависимость. В отношении R атрибут Y функционально зависит от атрибута X — если каждому значению X соответствует в точности одно значение Y. Обозначается y:x→y (x функционально определяет y)

Полная функциональная зависимость. Функциональная зависимость y:x→y называется полной, если атрибут Y не зависит функционально от любого точного подмножества X

Транзитивная функциональная зависимость. Функциональная зависимость y:x→y называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости x →z и z→y (обратная зависимость отсутствует).

15. 1, 2, 3 нормальні форми і НФ Бойса-Кодда.

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

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

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

· Друга нормальна форма (2NF); (Таблиця знаходиться в другій нормальній формі (2НФ), якщо вона задовольняє визначенню 1НФ і всі її поля, що не входять в первинний ключ, пов'язані повної функціональної залежністю з первинним ключем.)

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

· Нормальна форма Бойса-Кодда (BCNF); (Таблиця знаходиться в нормальній формі Бойса-Кодда (НФБК), якщо і тільки якщо будь-яка функціональна залежність між його полями зводиться до повної функціональної залежності від можливого ключа.)

Основні властивості нормальних форм:

· Кожна наступна нормальна форма в деякому сенсі краще попередньої;

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

16. Нормалізація. Основна ідея процедури нормалізації. Алгоритм нормалізації.

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

Метою нормалізації є:

· Зменшення об'єму для зберігання даних.

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

Отже, алгоритм нормалізації (тобто алгоритм приведення відносин до 3НФ) описується таким чином.

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

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

Крок 3 (Приведення до 3НФ). Якщо в деяких відносинах виявлена ​​залежність деяких неключових атрибутів інших неключових атрибутів, то проводимо декомпозицію цих відносин таким чином: ті неключові атрибути, які залежать інших неключових атрибутів виносяться в окреме відношення.

На практиці, при створенні логічної моделі даних, як правило, не слідують прямо наведеному алгоритму нормалізації. Досвідчені розробники зазвичай відразу будують відносини в 3НФ. Крім того, основним засобом розробки логічних моделей даних є різні варіанти ER-діаграм. Особливість цих діаграм у тому, що вони відразу дозволяють створювати відносини в 3НФ.

Дата добавления: 2015-05-10