Теорія баз даних

1. Теорія баз даних

2. База Даних (DataBase) База даних (БД) — впорядкований набір логічно взаємопов'язаних даних, що використовуються спільно, та призначені для задоволення інформаційних потреб користувачів. У технічному розумінні включно й система керування БД (СКБД, СУБД). • База данных — организованная в соответствии с определёнными правилами и поддерживаемая в памяти компьютера совокупность данных, характеризующая актуальное состояние некоторой предметной области и используемая для удовлетворения информационных потребностей пользователей. • База данных — совокупность данных, хранимых в соответствии со схемой данных, манипулирование которыми выполняют в соответствии с правилами средств моделирования данных. • База данных — некоторый набор перманентных (постоянно хранимых) данных, используемых прикладными программными системами какого-либо предприятия.[ • База данных — совместно используемый набор логически связанных данных (и описание этих данных), предназначенный для удовлетворения информационных потребностей организации. Головним завданням БД є гарантоване збереження значних обсягів інформації (т.зв. записи даних) та надання доступу до неї користувачеві або ж прикладній програмі. Таким чином БД складається з двох частин: - збереженої інформації - системи управління нею. З метою забезпечення ефективності доступу записи даних організовують як множину фактів (елемент даних).

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

4. Історія розвитку • История баз данных в узком аспекте рассматривает базы данных в традиционном (современном) понимании. Эта история начинается с 1955 года, когда появилось программируемое оборудование обработки записей. Программное обеспечение этого времени поддерживало модель обработки записей на основе файлов. Для хранения данных использовались перфокарты. • 1960-ті рр. розробка перших БД. CODASYL — мережева модель даних та одночасно незалежна розробка ієрархічної БД фірмою North American Rockwell, яка пізніше взята за основу IMS — власної розробки IBM. • Оперативные сетевые базы данных появились в середине 1960-х. Операции над оперативными базами данных обрабатывались в интерактивном режиме с помощью терминалов. Простые индексно-последовательные организации записей быстро развились к более мощной модели записей, ориентированной на наборы. За руководство работой DataBaseTaskGroup (DBTG), разработавшей стандартный язык описания данных и манипулирования данными, Чарльз Бахман получил Тьюринговскуюпремию. В это же время в сообществе баз данных COBOL была проработана концепция схем баз данных и концепция независимости данных. • Сам термин database (база данных) появился в начале 1960-х годов, и был введён в употребление на симпозиумах, организованных фирмой SDC (SystemDevelopmentCorporation) в 1964 и 1965 годах, хотя понимался сначала в довольно узком смысле, в контексте систем искусственного интеллекта. В широкое употребление в современном понимании термин вошёл лишь в 1970-е годы.[9] • 1970-ті рр. наукове обґрунтування Едгаром Ф. Коддом основ реляційної моделі, котра на початку зацікавила лише наукові кола. Вперше цю модель було використано у БД Ingres (Берклі) та System R (IBM), що були лише дослідними прототипами, анонсованими протягом 1976 року. • 1980-ті рр. поява перших комерційних версій реляційних БД Oracle та DB2. Реляційні БД починають успішно витісняти мережеві та ієрархічні. Дослідження децентралізованих (розподілених) систем БД, проте вони не відіграють особливої ролі на ринку БД. • 1990-ті рр. увага науковців спрямовується у сторону об'єктно-орієнтованих БД, які знайшли застосування у першу чергу в тих областях, де використовуються комплексні дані: інженерні, мультимедійні БД. • 2000-ні рр. головним новоденням є підтримка та застосування XML у БД. Розробники комерційних БД, які панували на ринку у 1990-их рр., отримують все більшу конкуренцію зі сторони руху відкритого програмного забезпечення. Реакцією на це стає поява безкоштовних версій комерційних БД.

5. Класифікація БД Классификация по модели данных Иерархическая Сетевая Реляционная Объектная и объектно-ориентированная Объектно-реляционная Функциональная Классификация по степени распределённости Централизованная, или сосредоточенная (centralizeddatabase): БД, полностью поддерживаемая на одном компьютере. Распределённая (distributeddatabase): БД, составные части которой размещаются в различных узлах компьютерной сети в соответствии с каким-либо критерием. Неоднородная (heterogeneousdistributeddatabase): фрагменты распределённой БД в разных узлах сети поддерживаются средствами более одной СУБД Однородная (homogeneousdistributeddatabase): фрагменты распределённой БД в разных узлах сети поддерживаются средствами одной и той же СУБД. Фрагментированная, или секционированная (partitioneddatabase): методом распределения данных является фрагментирование (партиционирование, секционирование), вертикальное или горизонтальное. Тиражированная (replicateddatabase): методом распределения данных является тиражирование (репликация). Классификация по содержимому (Географическая, Историческая, Научная, Мультимедийная)

6. Классификация по среде постоянного хранения • Во вторичной памяти, или традиционная (conventionaldatabase): средой постоянного хранения является периферийная энергонезависимая память (вторичная память) — как правило жёсткий диск.В оперативную память СУБД помещает лишь кеш и данные для текущей обработки. • В оперативной памяти (in-memorydatabase, memory-residentdatabase, mainmemorydatabase): все данные на стадии исполнения находятся в оперативной памяти. • В третичной памяти (tertiarydatabase): средой постоянного хранения является отсоединяемое от сервера устройство массового хранения (третичная память), как правило на основе магнитных лент или оптических дисков.Во вторичной памяти сервера хранится лишь каталог данных третичной памяти, файловый кеш и данные для текущей обработки; загрузка же самих данных требует специальной процедуры.

7. Иерархическая модель данных Иерархические базы данных могут быть представлены как дерево, состоящее из объектов различных уровней. Верхний уровень занимает один объект, второй — объекты второго уровня и т. д. Между объектами существуют связи, каждый объект может включать в себя несколько объектов более низкого уровня. Такие объекты находятся в отношении предка (объект более близкий к корню) к потомку (объект более низкого уровня), при этом возможна ситуация, когда объект-предок не имеет потомков или имеет их несколько, тогда как у объекта-потомка обязательно только один предок. Объекты, имеющие общего предка, называются близнецами. Например, если иерархическая база данных содержала информацию о покупателях и их заказах, то будет существовать объект «покупатель» (родитель) и объект «заказ» (дочерний). Объект «покупатель» будет иметь указатели от каждого заказчика к физическому расположению заказов покупателя в объект «заказ». В этой модели запрос, направленный вниз по иерархии, прост (например: какие заказы принадлежат этому покупателю); однако запрос, направленный вверх по иерархии, более сложен (например, какой покупатель поместил этот заказ). Также, трудно представить не-иерархические данные при использовании этой модели. Иерархической базой данных является файловая система, состоящая из корневого каталога, в котором имеется иерархия подкаталогов и файлов.

8. Мережеві БД • К основным понятиям сетевой модели базы данных относятся: уровень, элемент (узел), связь. • Узел — это совокупность атрибутов данных, описывающих некоторый объект. На схеме иерархического дерева узлы представляются вершинами графа. В сетевой структуре каждый элемент может быть связан с любым другим элементом. • Сетевые базы данных подобны иерархическим, за исключением того, что в них имеются указатели в обоих направлениях, которые соединяют родственную информацию. • Несмотря на то, что эта модель решает некоторые проблемы, связанные с иерархической моделью, выполнение простых запросов остается достаточно сложным процессом. • Также, поскольку логика процедуры выборки данных зависит от физической организации этих данных, то эта модель не является полностью независимой от приложения. Другими словами, если необходимо изменить структуру данных, то нужно изменить и приложение.

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

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

11. 12правил Кодда, яким повинна відповідати реляційна СУБД Оскільки реляційна модель баз даних являється найпоширенішою за рахунок простоти побудови і роботи з базою даних, то саме на на ній ми і зосередимо свою увагу. Але. перед тим. як розпочати засвоєння практичних навичок, потрібно засвоїти основні правила, яким повинна відповідати будь-яка реляційна база даних. Ці правила були запропоновані у 1970р. Англійським математиком Е.Ф.Коддом з компанії IBM. В термінології Кодда таблиці реляційної бази даних називаються відношеннями (relation). - звідси і назва самої моделі. Всіх правил - 12 (насправді 13). Основне правило, яке не входить до переліку, говорить про те. що будь-яка реляційна СУБД повинна повністю управляти базою даних, використовуючи зв'язки між даними. Всі інші 12 правил представлені нижче: • Правило інформації (TheInformationRule). Вся інформація в базі даних повинна бути представлена у вигляді даних, що зберігаються в комірках таблиць. Причому порядок записів (рядків) в реляційній таблиці не повинен впливати на суть зберігаємих даних. • Правило гарантованого доступу (Guaranteed Access Rule). Доступ до даних в реляційній БД повинен забезпечуватись шляхом використання комбінації імені таблиці, первинного ключа та імені стовпчика. • Правило підтримки недійсних значень (SystematicTreatmentofNullValues). Вказує на те. що будь-які відсутні дані можна представити за допомогою недійсного значення NULL. • Правило інтерактивного каталогу, основаного на реляційній моделі (Active On-Line CatalogBasedontheRelationalModel). Вказує на те. що реляційна база даних повинна сама себе описувати. Іншими словами, база данних повинна містити набір реляційних системних таблиць, що описують структуру самої бази даних. При цьому, потрібно забезпечити, щоб доступ до цих таблиць був аналогічний доступу до звичайних таблиць бази даних. • Правило вичерпної підмови даних (ComprehensiveDataSublanguageRule). Реляційна СУБД повинна підтримувати хоча б одну реляційну мову, яка має: - лінійній синтаксис: - може використовуватись як інтерактивно, так і для прикладних додатків: - підтримує операції роботи з даними (вставка, видалення, обновлення), забезпечує їх цілісність тощо.

12. Можливість модифікації представлень (ViewUpdatingRule). Всі представлення (view) повинні підтримувати операції маніпулювання даними, подібно реляційним таблицям: вибірка даних, вставка, обновлення та їх видалення. • Правило високорівневих операцій додавання, обновлення і видалення (High-Level Insert. Update, andDelete). Тут акцентується увага на тому, що бази даних по своїй природі орієнтовані на множини. Воно вимагає, щоб операції додавання, видалення та обновлення можна було виконувати як над одиничними даними, так і над множинами записів (рядків). • Правило незалежності фізичних даних (PhysicalDataIndependence). Вказує на те. що дані бази даних не повинні залежати від використовуваних способів збереження даних на носіях, від апаратного забезпечення комп'ютера, на яких встановлена СУБД. • Правило незалежності логічних даних (LogicalDataIndependence). Представлення даних в прикладних додатках не повинно залежати від структури реляційних таблиць. Іншими словами, якщо в базі даних відбулась зміна її структури (деякі таблиці були розділені на кілька, добавлені інші таблиці тощо), то в прикладній програмі відображення даних не повинно змінитись. • Правило незалежності контроля цілісності (IntegrityIndependence). Вся інформація, яка необхідна для забезпечення цілісності даних повинна зберігатись в системних таблицях. Використовуючи ці дані. СУБД повинна перевіряти всі вхідні дані на відповідність їх умовам цілісності. • Правило незалежності розприділення (DistributionIndependence). Дозволяє базі даних бути розприділеною. тобто знаходитись на різних комп'ютерах. Причому перенесення даних на інший комп'ютер не повинно вплинути на її роботоздатність. • Правило узгодженості мов різних рівнем (TheNonsubversionRule). Якщо використовується низькорівнева мова для доступу до даних, то вона не повинна ігнорувати правила безпеки і цілісності даних, які підтримуються мовою більш низького рівня.

13. Проектування бази даних Перш, ніжпочатибудувати свою базу даних. їїнеобхідноспроектувати, тобтовизначити для збереженняякихсамеданих вона призначена, хто буде нею користуватисьтощо. Сам процеспобудовибазиданихмассвійжиттєвий цикл, який проходить ряд етапів: 1. Аналізданихвключає в себе етапиформулювання і аналізувимог. Етап аналізу даних являється самим складним і самим головним. Як правило, він здійснюється в тісній взаємодії з замовником. Його можна поділити ще на ряд підетапів: • Концептуальнепроектування, щовключаєзбір, аналіз і редагуваннявимог до даних. Для цьогоздійснюютьсянаступнідії: дослідженняпредметноїобласті, вивченняїїструктури: визначеннякористувачівмайбутньоїбазиданих: визначеннявимогкористувачів до базиданих, тобтощокожен з користувачівхочеотримати в результатістворенняБД: визначення інформаційних об'єктів, які повинні бути присутні в базі даних та зв'язків між ними. • Логічнепроектування - перетвореннявимог до даних в конкретніоб'єктиданих. В результаті, на виході ми отримуємоорієнтовну структуру базиданих. • Фізичнепроектування - визначенняособливостейзберіганняданих (здійснюєтьсягрупуванняданих, створюютьсяіндекси), методів доступу тощо. 2. Проектуваннябазиданихпередбачаєбезпосереднєстворенняоб'єктів та зв'язківбазиданих. 3. Ввід в експлуатаціювключає: • перенесеннябазиданих на робочу машину: написаннятехнічноїдокументації: передача користувачу: • аналіз функціонування, підтримка та модифікація бази даних.