База даних (БД)

— впорядкований набір логічно взаємопов'язаних даних, що

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

• • • • База данных — организованная в соответствии с определёнными правилами и поддерживаемая в памяти компьютера совокупность данных, характеризующая актуальное состояние некоторой предметной области и используемая для удовлетворения информационных потребностей пользователей.

База данных — совокупность данных, хранимых в соответствии со схемой данных, манипулирование которыми выполняют в соответствии с правилами средств моделирования данных.

База данных — некоторый набор перманентных (постоянно хранимых) данных, используемых прикладными программными системами какого-либо предприятия.

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

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

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

СУБД (СКБД)

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

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

• • • • • • • • История баз данных в узком аспекте рассматривает базы данных в традиционном (современном) понимании. Эта история начинается с 1955 года, когда появилось программируемое оборудование обработки записей. Программное обеспечение этого времени поддерживало модель обработки записей на основе файлов. Для хранения данных использовались перфокарты.

1960-ті рр. розробка перших БД. CODASYL — мережева модель даних та одночасно незалежна розробка ієрархічної БД фірмою North American Rockwell, яка пізніше взята за основу IMS — власної розробки IBM.

Оперативные сетевые базы данных появились в середине 1960-х. Операции над оперативными базами данных обрабатывались в интерактивном режиме с помощью терминалов. Простые индексно-последовательные организации записей быстро развились к более мощной модели записей, ориентированной на наборы. За руководство работой Data Base Task Group (DBTG), разработавшей стандартный язык описания данных и манипулирования данными, Чарльз Бахман получил Тьюринговскую премию. В это же время в сообществе баз данных COBOL была проработана концепция схем баз данных и концепция независимости данных.

Сам термин database (база данных) появился в начале 1960-х годов, и был введён в употребление на симпозиумах, организованных фирмой SDC (System Development Corporation) в 1964 и 1965 годах, хотя понимался сначала в довольно узком смысле, в контексте систем искусственного интеллекта. В широкое употребление в современном понимании термин вошёл лишь в 1970-е годы.

[9] 1970 ті рр. наукове обґрунтування Едгаром Ф. Коддом основ реляційної моделі, котра на початку зацікавила лише наукові кола. Вперше цю модель було використано у БД Ingres ( Берклі) та System R (IBM), що були лише дослідними прототипами, анонсованими протягом 1976 року.

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

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

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

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

Классификация по модели данных

Иерархическая Сетевая Реляционная Объектная и объектно-ориентированная Объектно-реляционная Функциональная

Классификация по степени распределённости

Централизованная, или сосредоточенная (centralized database): БД, полностью поддерживаемая на одном компьютере.

Распределённая (distributed database): БД, составные части которой размещаются в различных узлах компьютерной сети в соответствии с каким-либо критерием. Неоднородная (heterogeneous distributed database): фрагменты распределённой БД в разных узлах сети поддерживаются средствами более одной СУБД Однородная (homogeneous distributed database): фрагменты распределённой БД в разных узлах сети поддерживаются средствами одной и той же СУБД.

Фрагментированная, или секционированная (partitioned database): методом распределения данных является фрагментирование (партиционирование, секционирование), вертикальное или горизонтальное.

Тиражированная (replicated database): методом распределения данных является тиражирование (репликация).

Классификация по содержимому

(Географическая, Историческая, Научная, Мультимедийная)

• • •

Классификация по среде постоянного хранения

Во вторичной памяти, или традиционная (conventional database): средой постоянного хранения является периферийная энергонезависимая память (вторичная память) — как правило жёсткий диск.

В оперативную память СУБД помещает лишь кеш и данные для текущей обработки.

В оперативной памяти (in-memory database, memory-resident database, main memory database): все данные на стадии исполнения находятся в оперативной памяти.

В третичной памяти (tertiary database): средой постоянного хранения является отсоединяемое от сервера устройство массового хранения (третичная память), как правило на основе магнитных лент или оптических дисков.

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

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

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

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

В этой модели запрос, направленный вниз по иерархии, прост (например: какие заказы принадлежат этому покупателю); иерархические данные при использовании этой модели.

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

• • • • • К основным понятиям сетевой модели базы данных относятся: элемент (узел), связь.

уровень, Узел — это совокупность атрибутов данных, описывающих некоторый объект.

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

Сетевые базы данных подобны иерархическим, за исключением того, что в них имеются указатели в обоих направлениях, которые соединяют родственную информацию.

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

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

Реляційна база даних — база даних, основана на реляційній моделі даних. Слово «реляційний» походить від англ. relation. Для роботи з реляційними БД застосовують реляційні СКБД. Інакше кажучи, реляційна база даних — це база даних, яка сприймається користувачем як набір нормалізованих відношень різного ступеню.

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

• • Реляційна модель орієнтована на організацію у вигляді двовимірних таблиць. Кожна реляційна таблиця являє собою двовимірний масив і має такі властивості: • кожний елемент таблиці - один елемент даних • всі комірки в стовпці таблиці однорідні, тобто всі елементи в стовпці мають однаковий тип • кожний стовпець має унікальне ім'я однакові рядки в таблиці відсутні порядок наступності рядків і стовпців може бути довільним • • • • Приклали реляційних СУБД: Microsoft SQL Server; Oracle; Interbase/Firebird Microsoft Access: / MySQL.

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

Таблиці

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

Запити

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

Structured Query Language

даними.

.

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

Оскільки реляційна модель баз даних являється найпоширенішою за рахунок простоти побудови і роботи з базою даних, то саме на на ній ми і зосередимо свою увагу. Але. перед тим. як розпочати засвоєння практичних навичок, потрібно засвоїти основні правила, яким повинна відповідати будь-яка реляційна база даних. Ці правила були запропоновані у 1970р. Англійським математиком Е.Ф.Коддом з компанії IBM.

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

Всі інші 12 правил представлені нижче: 1.

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

2.

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

3.

4.

5.

Правило підтримки недійсних значень (Systematic Treatment of Null Values). Вказує на те. що будь-які відсутні дані можна представити за допомогою недійсного значення NULL.

Правило інтерактивного каталогу, основаного на реляційній моделі (Active On-Line Catalog Based on the Relational Model).

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

Правило вичерпної підмови даних (Comprehensive Data Sublanguage Rule). Реляційна СУБД повинна підтримувати хоча б одну реляційну мову, яка має: - лінійній синтаксис: - може використовуватись як інтерактивно, так і для прикладних додатків: - підтримує операції роботи з даними (вставка, видалення, обновлення), забезпечує їх цілісність тощо.

6.

7.

8.

9.

10.

11.

12.

Можливість модифікації представлень (View Updating Rule). Всі представлення (view) повинні підтримувати операції маніпулювання даними, подібно реляційним таблицям: вибірка даних, вставка, обновлення та їх видалення.

Правило високорівневих операцій додавання, обновлення і видалення (High-Level Insert. Update, and Delete). Тут акцентується увага на тому, що бази даних по своїй природі орієнтовані на множини. Воно вимагає, щоб операції додавання, видалення та обновлення можна було виконувати як над одиничними даними, так і над множинами записів (рядків).

Правило незалежності фізичних даних (Physical Data Independence). Вказує на те. що дані бази даних не повинні залежати від використовуваних способів збереження даних на носіях, від апаратного забезпечення комп'ютера, на яких встановлена СУБД.

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

Правило незалежності контроля цілісності (Integrity Independence). Вся інформація, яка необхідна для забезпечення цілісності даних повинна зберігатись в системних таблицях. Використовуючи ці дані. СУБД повинна перевіряти всі вхідні дані на відповідність їх умовам цілісності.

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

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

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

Етап аналізу даних являється самим складним і самим головним. Як правило, він здійснюється в тісній взаємодії з замовником. Його можна поділити ще на ряд підетапів: 1.

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

2.

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

3.

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

2. Проектування бази даних передбачає безпосереднє створення об'єктів та зв'язків бази даних.

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