Шпора БД. 1. Основні поняття. Бази даних, банк даних, інформаційна система. Традиційні файлові системи. Бази даних. Системи управління базами даних (субд). Компоненти банку даних. Основні поннятя
 Скачать 299.76 Kb.
|
|
1.Основні поняття. Бази даних, банк даних, інформаційна система. Традиційні файлові системи. Бази даних. Системи управління базами даних (СУБД). Компоненти банку даних. Основні поннятя: База даних (скорочено — БД) — впорядкований набір логічно взаємопов'язаних даних, що використовуються спільно та призначені для задовільненя інформаційних потреб користувачів. У технічному розумінні включно й система керування БД. Головне завдання БД — гарантоване збереження значних обсягів інформації та надання доступу до неї користувачеві або ж прикладній програмі. Таким чином, БД складається з двох частин: збереженої інформації та системи керування нею. З метою забезпечення ефективності доступу записи даних організовують як множину фактів (елемент даних). Дані (date) — це компонент БД, над яким виконуються в ІС дії. Банк даних (data bank) - це автоматизована система, сукупність інформаційних, програмних, технічних засобів і персоналу, що забезпечує зберігання, нагромадження, оновлення, пошук і видачу даних. База даних та банк даних , інформаційна система: До складу БнД входять такі складові: сукупність технічного та програмного забезпечення, база даних, СУБД, словник даних, адміністратор БД. Головні складові банк у даних — база даних і програмний продукт, який називається системою управління базою даних (СУБД). Система управління базами даних (СУБД) — це програмні засоби, за допомогою яких можна створювати бази даних, поповнювати їх та працювати з ними. Банк даних (БнД) — це автоматизована система, сукупність інформаційних, програмних, технічних засобів і персоналу, що забезпечує зберігання, нагромадження, оновлення, пошук і видачу даних. На всіх етапах життєвого циклу БД складається з двох компонентів: структури та даних. На різних рівнях опису БД її структура зображується: на інфологічному рівні (сутність — зв’язок); на датологічному рівні вона може бути однією з моделей даних — ієрархічною, мережевою, реляційною. на фізичному рівні (структура файлів даних і допоміжних файлів). Більшість баз даних мають табличну структуру. Файли даних також складаються зі структури та даних. Структура охоплює такі компоненти: ім’я поля, тип поля, довжина поля. Використання принципів бази та банку даних передбачає організацію зберігання інформації у вигляді БД.Така організація даних усуває цілий ряд проблем: 1.відпадає потреба в кожній прикладній програмі детально вирішувати питання організації файлів; 2.усуває багаторазове введення й дублювання одних і тих самих даних; 3.не виникає проблеми зміни прикладних програм у зв’язку із заміною фізичних пристроїв або зміни структури даних; 4.підвищує рівень надійності та захищеності інформації; 5.зменшує надлишок даних. Технологія баз і банків — провідний напрям організації внутрішньомашинного інформаційного забезпечення. Розвиток технологій баз і банків даних визначається рядом чинників: ростом інформаційних потреб користувачів, вимогами ефективного доступу до інформації, появою видів масової пам’яті, збільшенням її об’ємів, новими засобами та можливостями в галузі комунікації. Адміністратор БД (АБД) — особа або група осіб, які відповідають за загальне керування БД. Важливе завдання адміністратора БД — захист даних від злому, несанкціонованого та некомпетентного доступу. Для виконання функції адміністратора в СУБД передбачено різні службові програми. Адміністрування БД передбачає виконання функцій для забезпечення надійної та ефективної роботи бази даних, задоволення інформаційних потреб користувача. Традиційні файлові системи традиційних пакетних системах обробки інформації, які функціонували донедавна на машинах типу ЄС ЕОМ, дані були організовані у вигляді незв'язаних між собою локальних інформаційних файлів лінійної структури. Суть такого підходу до організації інформаційного забезпечення (І3) полягає в тому, що файли проектуються окремо для кожної конкретної задачі чи для їх комплексів. Такі системи інколи називаються файловими. Незважаючи на відносну простоту організації файлові системи мають ряд недоліків, головними з яких є такі. 1. Надлишковість даних. Файлові системи характеризуються значною надлишковістю, оскільки нерідко для розв'язування різних задач управління використовуються одні й ті самі дані, розміщені в різних файлах. Через дублювання даних у різних файлах пам'ять на зовнішніх запам'ятовуючих пристроях використовується неекономно, інформація одного й того самого об'єкта управління розподіляється між багатьма файлами. При цьому досить важко уявити загальну інформаційну модель предметної області. 2. Неузгодженість даних. Ураховуючи, що одна і та сама інформація може розміщуватися в різних файлах, технологічно важко простежити за внесенням змін одночасно в усі файли. Через це може виникнути неузгодженість даних, коли одне і те саме поле в різних файлах може мати різні значення. 3. 3алежність структур даних і прикладних програм. При файловій організації логічна і фізична структури файла мають відповідати їх опису в прикладній програмі. Прикладна програма має бути модифікована при будь-якій зміні логічної чи фізичної структури файла. Оскільки зміни в одній програмі часто потребують внесення змін до інших інформаційно пов'язаних програм, то інколи простіше створити нову програму, ніж вносити зміни в стару. Тому цей недолік файлових систем призводить до значного збільшення вартості супроводження програмних засобів. Зазначимо, що інколи вартість супроводження програмних засобів може досягати близько 70 % вартості їх розробки. Компоненти банку даних · Інформаційна база; · Лінгвістичні засоби; · Програмні засоби; · Технічні засоби; · Організаційно-адміністративні підсистеми та нормативно-методичне забезпечення. 2.Розподіл обов'язків в системах з базами даних. Історія розвитку СУБД. Класифікація банків даних. Переваги та недоліки СУБД. Історія розвитку СУБД Вважається, що початки розвитку СУБД були закладені в 60-х роках, коли в США була прийнята програма польоту людини на Місяць. На той час ще не існувало системи, яка могла б обробляти великі масиви інформації. Був розроблений проект під назвою GUAM (Generalized Update Access Method). Основна ідея проекту – об’єднання більш малих компонентів в більш великі до тих пір, поки не буде зібраним весь проект. Це була так звана ієрархічна структура. Наступним кроком було створення фірмою IDS в середині 60-х років СУБД нового типу – мереженої.1965 рік – створення стандартів баз даних. Група DBTG (Data Base Task Group). В 1971 група запропонувала такі стандарти: - мережева схема – це логічна організація всієї бази в цілому, що включає в себе визначення імен, типів кожного запису та компонентів кожного типу; - під схема –частина БД з точки зору користувача чи додатку;- мова управління даними – інструмент визначення характеристик і структури даних, а також управління ними. Офіційно ці стандарти не були прийняті, але системи, розроблені за цими стандартами називають СУБЛ першого покоління. В 1970 році Кодд опублікував статтю про реляційну модель БД. За 10 років були розроблені багато реляційних БД та мова запитів до них. Реляційні СУБД – СУБД другого покоління. На сьогоднішній день розроблені об’єктно-орієнтовані та об’єктно-реляційні СУБД – СУБД третього покоління. Класифікація банків даних Найбільш очевидними класифікаціями є : - за формою представлення інформації: - аудіо; - мультимедіа; - візуальні; - за структурою: - неструктуровані БД; - частково структуровані; - структуровані: - ієрархічні; - мережеві; - реляційні; - об’єктно-орієнтовані; - мультимодельні; - за характером організації зберігання: - локальні; - розподілені. Переваги та недоліки Переваги: - контроль за надлишковістю даних; - несуперечливість даних; - спільне використання даних; - підтримка цілісності даних; - підвищена безпека; - застосування стандартів; - підвищення доступності даних і їх готовності до роботи; - покращення показників продуктивності; - спрощення супроводу системи за рахунок незалежності від даних; - покращене управління паралельністю; - розвиток служби резервного копіювання та відновлення. Недоліки: - складність; - розмір; - вартість СУБД; - додаткові затрати на апаратне забезпечення; - витрати на перетворення; - більш серйозні наслідки при виході системи з ладу. Розподіл обов’язків в системах з базами даних. Всі користувачі СУБД можна розділити на 4 групи: - Адміністратори даних і адміністратори баз даних; - Розробники баз даних; - Прикладні програмісти; - Кінцеві користувачі. Адміністратор даних (АД) відповідає за управління даними, включаючи планування бази даних, розробку і супровід стандартів, бізнес-правил і ділових процедур, а також за концептуальне та логічне проектування БД. Адміністратор даних консультує і дає свої рекомендації керівництву вищої ланки Адміністратор бази даних (АБД) – відповідає за фізичну реалізацію БД, за забезпечення безпеки та цілісності БД, за супровід операційної системи, за забезпечення максимальної продуктивності додатків та користувачів. Розробники БД можна розділити на дві групи: розробники логічної БД та розробники фізично БД. Розробники логічної БД займаються ідентифікацією даних, зв’язками між даними, встановлюють обмеження, які накладають на дані. Розробник фізичної БД отримує готову логічну модель даних і займається її фізичною реалізацією. 3.Середовище бази даних. Трьохрівнева архітектура ANSI-SPARK. Зовнішній рівень. Концептуальний рівень. Трьохрівнева архітектура ANSI-SPARK Перша спроба створення стандартної термінології та загальної архітектури СУБД б ла зроблена в 1971 році групою, званою DBTG. Вона була створена після конференції CODASYL (Conference on Data Systems and Languaguages - Конференція з мов і системам даних), що пройшла в цьому ж році. Група DBTG визнала необхід ність використання дворівневого підходу, побудованого на основі використання системного уявлення, тобто схеми (schema), і користувальницьких уявлень, тобто подсхем (subschema). Подібні термінологія та архітектура були запропоновані в 1975 році Комітетом планування стандартів і норм SPARC (Standards Planning and Requirements Committee) Національного Інституту Стандартизації США (American National Standard Institute- ANSI), ANSI / X3 / SPARC (ANSI, 1975). Комітет ANSI / SPARC визнав необхідність використання трирівневого підходу. У цих матеріалах відображені пропозиції, які були зроблені організаціями Guide / Share, що складаються з користувачів продуктів корпорації IBM, і опубліковані за кілька років до цього. Основна увага в них було сконцентровано на необхідності вопло щення незалежного рівня для ізоляції програм від особливостей подання дан -них на більш низькому рівні (Guide / Share, 1970). Хоча модель ANSI / SPARC не стала стан Дартом, проте вона все ще являє собою основу для розуміння деяких функціональних особливостей СУБД. В даному випадку для нас найбільш фундаментальним моментом у цих та подальших звітах дослідницьких груп є ідентифікація трьох рівнів абстракції, тобто трьох різних рівнів опису елементів даних. Ці рівні формують трехуров невую архітектуру, яка охоплює зовнішній, концептуальний і внутрішній рівні, як показано на рис. 2.1. Мета трирівневої архітектури полягає у відділенні користувальницького уявлення бази даних від її фізичного представлення. Нижче перераховано кілька причин, за якими бажано виконувати такий поділ. • Кожен користувач повинен мати можливість звертатися до одних і тих же даних, використовуючи своє власне уявлення про них. Каж дий користувач повинен мати можливість змінювати своє представле ня про дані, причому ця зміна не повинно впливати на інших користувачів. • Користувачі не повинні безпосередньо мати справу з такими детально стями фізичного зберігання даних в базі, як індексування і хеши вання (додаток А, "Навчальний проект Wellmeadows Hospital "). Інакше кажучи, взаємодія користувача з базою не повинно залежати від осо бенностей зберігання в ній даних. • Адміністратор бази даних (АБД) повинен мати можливість змінювати структуру зберігання даних в базі, не надаючи впливу на користувачські уявлення. • Внутрішня структура бази даних не повинна залежати від таких зраді ний фізичних аспектів зберігання інформації, як перемикання на але ше пристрій зберігання. • АБД повинен мати можливість змінювати концептуальну або глобальну структуру бази даних без будь-якого впливу на всіх пользователя. Рівень, на якому сприймають дані користувачі ,, називається зовнішнім рівнем (external level), тоді як СУБД і операційна система сприймають дані на внутрішньому рівні (internal level). Саме на внутрішньому рівні дані реально зберігаються з використанням всіх тих структур і файлової організації, які описані в додатку нии Б, "Структура даних у файлах з різною організацією".Концептуальний рівень (conceptual level) представлення даних призначений для відображення зовнішнього рівня на внутрішній і забезпечення необхідної незалежності один від одного. Зовнішній рівень Зовнішній Подання бази даних з точки зору користувачів. Цей уро рівень вень описує ту частину бази даних, яка відноситься до кожного користувача. Зовнішній рівень складається з декількох різних зовнішніх уявлень ба зи даних. Кожен користувач має справу з виставою "реального світу", вираженим в найбільш зручній для нього формі. Зовнішнє уявлення содер жит тільки ті суті, атрибути та зв'язку "реального світу", які цікаві користувачеві. Інші суті, атрибути або зв'язку, які йому нецікаві, також можуть бути представлені в базі даних, але користувач може навіть не по дозрівати про їх існування. Крім цього, різні уявлення можуть по-різному відображати одні й ті ж дані. Наприклад, один користувач може переглядати дати у форматі (день, місяць, рік), а інший - у форматі (рік, місяць, день). Деякі уявлення можуть включати похідні або обчислювані дані, що не зберігаються в базі даних як такі, а створюються в міру потреби. Наприклад, у проекті DreamHome можна було б орга нізовать перегляд даних про вік співробітників. Однак навряд чи варто зберігати ці відомості в базі даних, оскільки в такому разі їх довелося б щодня оновлювати. Замість цього в базі даних зберігаються дати народження співробітників, а вік обчислюється засобами СУБД по виявленні відповідного посилання. Уявлення можуть також включати комбіновані або похідні дані з декількох об'єктів. Більш детально подання розглядаються в розділах 3.5 і 14.1. Концептуальний рівень На концептуальному рівні здійснюється інтегрований опис предметної області, для якої розробляється БД, незалежно від її сприйняття окремими користувача ми та способів реалізації в комп'ютерній системі. Дамо означення основних по нять, що використовуються на концептуальному рівні. Предметна область (ПО) - частина реального світу, для якої здійснюється концептуальне моделювання. Концептуальна модель ПО - формальне зображення сукупності думок, які характеризують можливі стани ПО, а також переходи з одного стану в інший (включно з класифікацією наявних у ПО сутностей, чинних правил, законів, обме жень тощо). Концептуальне моделювання ПО - процес побудови концептуальної моделі ПО, яка б відображувала ПО з урахуванням вимог, висунутих до цього процесу. Концептуальна схема - фіксація концептуальної моделі ПО засобами кон кретних мов моделей даних. У СКБД концептуальна модель подається у вигляді концептуальної схеми. Опишемо властивості концептуальної моделі (схеми) й характерні особли вості концептуального моделювання. ♦ Спільне та однозначне тлумачення предметної області всіма зацікавленими особами. До розробки складної бази даних залучається великий колектив: експерти, системні аналітики, проектувальники, розробники, ті, хто займа ється впровадженням і супроводом. Усі вони повинні однозначно розуміти, чим є ПО, в чому зміст використаних понять, як вони взаємопов'язані між со бою, які обмеження висуваються до моделі ПО тощо. Спільність понять має забезпечувати концептуальна модель. ♦ Концептуальна схема відображує лише концептуально важливі аспекти ПО, виключаючи будь-які аспекти зовнішнього або внутрішнього відображення даних. Ця модель не повинна відображувати конкретні потреби окремих ко ристувачів або застосувань. Вона має фіксувати, чим є ПО в цілому, а не з точ ки зору інтересів або потреб користувачів. Для отримання цілісного уявлення про ПО її модель має інтегрувати думки, погляди та інтереси окремих корис тувачів, але саме інтегрувати, а не виражати їхні конкретні побажання. ♦ Визначення допустимих меж еволюції бази даних. У процесі експлуатації база даних може розвиватися, проте цей розвиток може відбуватися тільки в межах, допустимих для концептуальної схеми. ♦ Відображення зовнішніх схем на внутрішню. Саме через концептуальну схе му зовнішні дані відображуються на внутрішні, й навпаки. У такий спосіб створюється єдина основа для опису даних і підтримки цих відображень. ♦ Забезпечення незалежності даних. Наявність відображень концептуальний-зовнішній і концептуальний-внутрішній дає змогу вирішувати проблему логіч ної та фізичної незалежності даних. Будь-які зміни в тій чи іншій зовнішній моделі не повинні спричиняти зміни в концептуальній або внутрішній моде лях. У цьому випадку має змінитися тільки відповідне відображення «кон цептуальний-зовнішній». ♦Централізоване адміністрування. Саме через концептуальну схему здійсню ється адміністрування баз даних. 4.Внутрішній рівень. Мови баз даних. Моделі даних і концептуальне моделювання. Функції СУБД. Компоненти СУБД. Внутрішній рівень Внутрішній Фізичне представлення бази даних у комп'ютері. Цей рівень рівень описує, як інформація зберігається в базі даних. Внутрішній рівень описує фізичну реалізацію бази даних і предна значен для досягнення оптимальної продуктивності і забезпечення економно го використання дискового простору. Він містить опис структур даних і організації окремих файлів, що використовуються для зберігання даних в запоми нающіх пристроях. На цьому рівні здійснюється взаємодія СУБД з ме методами доступу операційної системи (допоміжними функціями зберігання та вилучення записів даних) з метою розміщення даних на запам'ятовуючих вуст ройстве, створення індексів, вилучення даних і т.д. На внутрішньому рівні зберігається наступна інформація: • розподіл дискового простору для зберігання даних та індексів; • опис подробиць збереження записів • відомості про розміщення записів; • відомості про стиснення даних і обраних методах їх шифрування. Концептуальне проектування Концептуальне проектування передбачає виконання наступних кроків: 1) аналіз вимог до БД із боку користувачів і побудову так називаної користувацької моделі (вивчення і систематизація інформації про користувачів, їхні інформаційні потреби, джерела інформації, реальні інформаційні потоки і бізнес-правила); 2) виявлення основних об'єктів (сутностей), що підлягають відображенню в моделі, виходячи зі специфіки предметної області, цілей замовника і наявного ділового регламенту; 3) визначення атрибутів сутностей і їхнє приведення у відповідність із вимогами майбутньої об'єктної моделі; 4) визначення зв'язків між сутностями і властивостей сутностей; 5) вибір типу інфологічної (об'єктної) моделі і її побудова. Найчастіше це модель «сутність – зв'язок» (ER-діаграма); 6) перевірку моделі даних; 7) побудову розподіленої моделі даних; 8) вибір моделі організації даних у концептуальній схемі. Мови баз даних • FoxProK (язык программирования) • PL/Perl • PL/pgSQL • PL/Python • PL/SQL • PL/Tcl • RPG (язык программирования) • SQL/PSM • Transact-SQL СУБД найчастіше використовуються дві основні мови опису запитів:− SQL (Structured Query Language) – структурована мова запитів − QBE (Query By Example) – мова запитів за зразком. Головна різниця між цима мовами полягає в тому, що мова QBE передбачає ручне або візуальне формування запиту, а мова SQL – програмування запиту. Функції СУБД Абстракція даних, управління словником даних. Функціонування СУБД передбачає, що визначення елементів даних і їх відносин (метадані) зберігаються в словнику даних (data dictionary). У свою чергу будь-які програми отримують доступ до даних за допомогою СУБД. Для пошуку необхідних структур даних і їх відносин СУБД використовує словник даних, допомагаючи уникнути кодування таких складних взаємозв'язків в кожній програмі. Вдобавок будь-які зміни, які робляться в структурі бази даних, автоматично реєструються в словнику даних, що також звільняє програміста від необхідності модифікувати програми доступу до змінених структур даних. СУБД забезпечує абстракцію даних, тим самим усуваючи в системі структурну залежність і залежність за даними. Управління зберіганням даних. СУБД створює складні структури, необхідні для зберігання даних, звільняючи програмістів від визначення і програмування фізичних властивостей даних. Сучасні СУБД забезпечують зберігання не тільки даних, але і пов'язаних із даними екранних форм, схем звітів, правил перевірки даних, коду процедур, систем обробки мультимедіа, форматів зображень, і т. п. Перетворення і представлення даних. СУБД бере на себе задачу структуризації даних, що вводяться, перетворюючи їх у форму, зручну для зберігання. Тому СУБД і в даному випадку позбавляє людину від рутинної роботи по перетворенню логічного формату даних у фізичний формат. Забезпечуючи незалежність даних, СУБД перетворює логічні запити в команди, що визначають їх фізичне місцеположення і витяг. Таким чином, СУБД забезпечує програмну незалежність і абстракцію даних. Управління безпекою. СУБД створює систему безпеки, яка забезпечує захист користувача і конфіденційність даних усередині БД. Правила безпеки встановлюють, які користувачі можуть одержати доступ до бази даних, до яких елементів даних користувач може отримати доступ, які операції з даними (читання, додавання, видалення або зміну) може виконувати користувач.Управління багатокористувацьким доступом. СУБД створює складні структури, що забезпечують доступ до даних декількох користувачів одночасно. Управління резервним копіюванням і відновленням. В СУБД є процедури резервного копіювання і відновлення даних, що забезпечують їх безпеку і цілісність. Сучасні СУБД містять спеціальні утиліти, за допомогою яких адміністратори бази даних можуть виконувати регулярні та екстрені процедури резервного копіювання і відновлення даних. Відновлення даних проводиться після пошкодження БД, наприклад, у випадку появи збійних секторів на жорсткому диску або після аварійного відключення живлення. Така можливість необхідна для забезпечення цілісності даних. Управління цілісністю даних. В СУБД передбачені правила, що забезпечують цілісність даних, що дозволяє мінімізувати надмірність даних і гарантувати їх несуперечність. Для забезпечення цілісності даних використовуються їх зв'язку, які зберігаються в словнику даних. Підтримка мови доступу до даних і інтерфейсів прикладного програмування. СУБД забезпечує доступ до даних за допомогою мови запитів. Мова запитів - це непроцедурного мова, тобто він надає користувачеві можливість визначити, що необхідно виконати, не вказуючи, як це зробити. До складу мови запитів СУБД входять два основних компоненти: мова визначення даних (Data Definition Language, DDL) і мова маніпулювання даними (Data Manipulation Language, DML). DDL визначає структури, в яких розміщуються дані, а DML дозволяє кінцевим користувачам отримувати дані з БД. На практиці для визначення структури бази даних використовуються оператори DDL, а для заповнення цих таблиць даними і вибірки з них інформації за допомогою запитів — оператори DML. Ці мови у різних СКБД можуть різнитися. Найбільше поширення отримали дві стандартизовані мови: - мова запитів за зразком, QBE (Query By Example) ; - структурована не процедурна мова з відносно невеликим (близько 30) набором команд, SQL (Structured Query Language). Компоненти СУБД. СУБД - це спеціалізоване ПО, призначене для забезпечення ефективного доступу до бази даних, яка використовується для надання тільки необхідної інформації, забезпечення незалежності від можливих змін у структурі (тієї частини бази даних, якої не обробляє програма). Функції: · управління даними у зовнішній і оперативної пам'яті комп'ютера · управління транзакціями · журналізації змін БД · підтримки мов доступу до даних Компоненти: 1) ядро , яке відповідає за управління даними у зовнішній і оперативної пам'яті і журналізацію, 2) процесор мови бази даних , що забезпечує оптимізацію запитів на вилучення та зміну даних і створення, як правило, машинно-незалежного виконуваного внутрішнього коду, 3) підсистему підтримки виконання , яка інтерпретує програми маніпуляції даними, що створюють користувальницький інтерфейс із СУБД 4) а також сервісні програми (зовнішні утиліти), що забезпечують ряд додаткових можливостей по обслуговуванню інформаційної системи. Типи даних: Деякі елементарні: · Символ · Ціле · Дробове · Булево (правда / неправда) Деякі складові: · Рядок символів · Набір допустимих значень (напр. Одружений / Не одружений / Неодружений) · байтовой набір (напр. зображення) Моделі даних і концептуальне моделювання. Основою бази даних є модель даних — фіксована система понять і правил для представлення даних структури, стану і динаміки проблемної області в базі даних. У різний час послідовне застосування одержували ієрархічна, мережна і реляційна моделі даних. У наш час усе більшого поширення набуває об'єктно-орієнтований підхід до організації баз даних ГІС. Концептуальна модель 1. Формулювання змістовного і внутрішнього представлення, що поєднує концепцію користувача й розробника моделі. Вона включає в явному виді логіку, алгоритми, припущення й обмеження. 2. Абстрактна модель, яка виявляє причинно-наслідкові зв'язки, властиві досліджуваному об'єктові в межах, визначених цілями дослідження. По суті, це формальний опис об'єкта моделювання, який відображає концепцію (погляд) дослідника на проблему. Концептуальна модель - модель предметної області, що складається з переліку взаємопов'язаних понять, що використовуються для опису цієї області, разом з властивостями й характеристиками, класифікацією цих понять, за типами, ситуацій, ознаками в даній області і законів протікання процесів в ній. (Тлумачний словник по штучному інтелекту) Концептуальна (змістовна) модель - це абстрактна модель, що визначає структуру модельованої системи, властивості її елементів і причинно-наслідкові зв'язки, властиві системі і суттєві для досягнення мети моделювання. Основні елементи концептуальної моделі: умови функціонування об’єкта, визначені характером взаємодії між об’єктом і його оточенням, а також між елементами об’єкта; мета дослідження об’єкта та напрямок покращення його функціонування; можливості керування об’єктом, визначення складу керованих змінних об’єкта. 5.Етап концептуального проектування. Основні поняття концептуального проектування. Концептуальне проектування. Об'єкти і їх властивості. Взаємовідношення об'єктів. Етап концептуального проектування Етап концептуального проектування полягає в описі і синтезі інформаційних вимог користувачів у початковий проект БД. Вихідними даними можуть бути сукупність документів користувача при класичному підході або алгоритми додатків (алгоритми бізнесу) при сучасному підході. Результатом цього етапу є високорівневе подання (у вигляді системи таблиць БД) інформаційних вимог користувачів на основі різних підходів. Спочатку вибирається модель БД. Потім створюється структура БД, яка заповнюється даними за допомогою систем меню, екранних форм або в режимі перегляду таблиць БД. Тут же забезпечується захист і цілісність (у тому числі посилальна) даних за допомогою СУБД або шляхом побудови тригерів. Концептуальне проектування Концептуальне проектування бази даних - процес створення моделі використовуваної на підприємстві інформації, що не залежить від будь-яких фізичних аспектів її представлення. Перша фаза процесу проектування бази даних називається концептуальним проектуванням бази даних. Вона полягає в створенні концептуальної моделі даних для аналізованої частини підприємства. Ця модель даних створюється на основі інформації, записаної в специфікаціях вимог користувачів. Концептуальне проектування бази даних абсолютно не залежить від таких подробиць її реалізації, як тип обраної цільовий СКБД, набір створюваних прикладних програм, використовувані мови програмування, тип обраної обчислювальної платформи, а також від будь-яких інших особливостей фізичної реалізації. При розробці концептуальна модель даних постійно піддається тестуванню і перевірці на відповідність вимогам користувачів. Створена концептуальна модель дані підприємства є джерелом інформації для фази логічного проектування бази даних. Приступаючи до розроблення локальної концептуальної моделі даних для представлення користувача «Диспетчер» та «Головний інженер» у базі даних «Автотранспортне підприємство», насамперед, варто виявити різні компоненти цієї моделі, використовуючи наявні специфікації вимог користувача (далі - просто "специфікації"). У кожну створювану модель даних входять наступні компоненти: ·типи сутностей; ·типи зв'язків; ·атрибути; ·домени атрибутів; ·потенційні ключі; ·первинні ключі. Основні поняття концептуального проектування Концептуальну модель даних, що відображає узагальнене представлення про дані, незалежне від типу обраної СУБД. При цьому виділяють інфологічну, чи власне концептуальну модель, що не залежить від типу обраної СУБД узагалі, і логічну, котра відбиває логічне представлення про дані у вигляді, адекватному моделі організації даних у СУБД визначеного типу, але не залежить від конкретної СУБД (тобто це може бути будь-яка СУБД реляційного типу – Access, FoxPro, DB2 тощо).; Проектування баз даних поділяється на декілька етапів: Концептуальне проектування - виділяються всі об’єкти, які будуть використані в БД та встановлюють зв’язок між ними. Ступені зв’язку між двома об’єктами позначаються у вигляді пари : 1 – 1 (один до одного) 1 – М (один до багатьох) М – 1 (багато до одного) М – М (багато до багатьох) Логічне проектування – перетворення вибраних об’єктів та зв’язків між ними в логічну модель. Перші два етапи виконують на папері. Фізичне проектування – це етап створення БД на комп’ютері. 6.Слабкі та складні сутності. Проведення етапу концептуального проектування СУБД. Слабкі та складні сутності Іноді виникає ситуація, коли первинний ключ деякого типу сутності складається з властивостей, які належать іншому типу сутності. Слабка сутність (weak entity) — такий тип сутності, первинний ключ якої складається (повністю або частково) з властивостей іншого типу сутностей. Інакше, слабка сутність називається залежною від інших. Зауваження: можлива ситуація, коли слабка сутність може залежати від декількох типів сутностей Розрізняють такі типи сутностей: прості, тобто неподільні сутності, і складні сутності Складні сутності бувають: • складові — відповідають відображенню "ціле — частина"; • узагальнені — відповідають відображенню "рід — вид" або "супертип — підтип"; • агреговані — відповідають, зазвичай, якому-небудь процесу, в який залучені інші об'єкти. Проведення етапу концептуального проектування СУБД. Будь-яка база даних (БД) — деяка модель предметної області, тобто в БД зберігаються тільки ті факти реального світу, які необхідні в конкретній задачі. Отже, при проектуванні потрібно виділити факти, що цікавлять користувачів, і відсікти непотрібні, а потім формально описати потрібні факти. Семантичне моделювання — найпопулярніший підхід до формального опису предметної області. Цей підхід заснований на визнанні факту існування в реальному світі об'єктів. Об'єкти мають набори характеристик (або властивостей) і взаємодіють між собою за допомогою зв'язків. Переваги підходу "Об’єкт — Властивість — зв'язок" — як найпопулярнішого з підходів семантичного моделювання такі: • незалежність від подальшої реалізації; • віддзеркалення семантики предметної області (значення кожного об'єкту, зв'язку, властивості). Особливо важливим є те, що використання підходу "Об’єкт — Властивість — зв'язок" дозволяє зберегти не тільки дані, але і частково значення (семантику) цих даних. Методології проектування, засновані на ідеях семантичного моделювання, часто називають низхідними методологіями, оскільки вони починають з вищого рівня абстракції - конструкції реального світу, і закінчуються на рівні, коли створюється конкретна схема БД. 7. Графічне представлення предметної області. Діаграми "Сутність – Зв'язок". Приклади діаграм Чена. Інструменти візуалізації схеми бази даних Діаграми "сутність-зв'язок" (ERD) призначені для розробки моделей даних і забезпечують стандартний спосіб визначення даних і відносин між ними. Фактично за допомогою ERD здійснюється деталізація сховищ даних проектованої системи, а також документуються сутності системи і способи їх взаємодії, включаючи ідентифікацію об'єктів, важливих для предметної області (сутностей), властивостей цих об'єктів (атрибутів) та їх відносин з іншими об'єктами (зв'язків).ER-модель зручна при проектуванні інформаційних систем, баз даних, архітектур комп'ютерних застосувань та інших систем (моделей). За допомогою такої моделі виділяють найсуттєвіші елементи (вузли, блоки) моделі і встановлюють зв'язки між ними  Приклади діаграм Чена  Графічне представлення.Основною формою представлення семантичної мережі є граф. Поняття семантичної мережі записуються в овалах або прямокутниках і з'єднуються стрілками з підписами — дугами .Це найзручніша форма яка сприймається людиною. Її недоліки виявляються, коли ми починаємо будувати складніші мережі або намагаємося врахувати особливості природної мови. 8. Реляційна модель бази даних. Історія розвитку реляційної моделі. Структура реляційних даних. Відношення в базі та їх властивості. Типи даних. Реляційна модель даних — логічна модель даних. Вперше була запропонована британським ученим співробітником компанії IBM Едгаром Франком Коддом (E. F. Codd) в 1970 році в статті «A Relational Model of Data for Large Shared Data Banks». В даний час ця модель є фактичним стандартом, на який орієнтуються практично всі сучасні комерційні системи керування базами даних (СКБД).У реляційній моделі досягається більш високий рівень абстракції даних, ніж в ієрархічній або мережевій. У згаданій статті Е. Ф. Кодда стверджується, що «реляційна модель надає засоби опису даних на основі тільки їх природної структури, тобто без потреби введення якоїсь додаткової структури для цілей машинного представлення». Іншими словами, подання даних не залежить від способу їх фізичної організації. Це забезпечується за рахунок використання математичного поняття відношення До складу реляційної моделі даних зазвичай включають теорію нормалізації. Крістофер Дейт визначив три складові частини реляційної моделі даних:структурна маніпуляційна цілісна.Реляційна база даних — база даних, основана на реляційній моделі даних. Слово «реляційний» походить від англ. relation. Для роботи з реляційними БД застосовують реляційні СКБД. Інакше кажучи, реляційна база даних — це база даних, яка сприймається користувачем як набір нормалізованих відношень різного ступеню.Структурна частина моделі визначає, що єдиною структурою даних є нормалізоване n-арне відношення. Відношення зручно представляти у формі таблиць, де кожен рядок є кортеж, а кожен стовпець — атрибут, визначений на деякому домені. Даний неформальний підхід до поняття відношення дає більш звичну для розробників і користувачів форму представлення, де реляційна база даних являє собою кінцевий набір таблиць. Цілісна частина описує обмеження спеціального виду, які повинні виконуватися для будь-яких відношень в будь-яких реляційних базах даних. Це цілісність сутностей і цілісність зовнішніх ключів. Маніпуляційна частина описує два еквівалентних способи маніпулювання реляційними даними - реляційну алгебру і реляційне числення. Перший механізм базується в основному на класичній теорії множин (з деякими уточненнями), а другий - на класичному логічному апараті обчислення предикатів першого порядку. Ми розглянемо ці механізми більш докладно далі, а поки лише зауважимо, що основною функцією маніпуляційної частини реляційної моделі є забезпечення заходів реляційності будь-якої конкретної мови реляційних БД: мова називається реляційною, якщо вона володіє не меншою виразністю і потужністю, ніж реляційна алгебра або реляційне числення. Відношення — фундаментальне поняття реляційної моделі даних. З цієї причини модель і називається Відношення має просту графічну інтерпретацію, воно може буде представлене у вигляді таблиці, стовпці (поля, атрибути) якої відповідають входженням доменів у відношення, а рядки (записи, кортежі) — наборам з n значень, що взяті з початкових доменів. Кількість рядків n, називають кардинальним числом відношення, або потужністю відношення. ряд властивостей:
Тип даних.Поняття тип даних в реляційній моделі даних повністю адекватно поняттю типу даних в мовах програмування. Зазвичай всі сучасні реляційні БД підтримують наступні типи даних: числові; символьні; великі двійкові об'єкти (малюнки та медіа-файли); бітові рядки; спеціалізовані числові дані (такі як «гроші»); спеціальні «темпоральні дані» (дата, час та часовий інтервал). 9. Нормалізація відношень баз даних. Нормальні форми. Цілі нормалізації. Надлишковість даних і аномалії оновлення. Нормалізація відношень- покроковий процес розділення (декомпозиції) початкових відношень БД на простіші. Кроки цього процесу переводять схему відношення БД в послідовні нормальні форми. Кожна наступна форма володіє кращими властивостями ніж попередня. Кожній нормальній формі відповідає певний набір обмежень. При переведенні структури відношення у форми вищого порядку досягають видалення з таблиць надмірної описової інформації.Процес нормалізації заснований на понятті функціональної залежності атрибутів. Перша нормальна форма. Відношення відповідає 1NF тоді, коли на перетині кожного стовпця і кожного рядка знаходяться тільки елементарні (неподільні) значення атрибутів і не містяться групи, що повторюються. Друга нормальна форма.Відношення знаходиться в 2NF, якщо виконуються обмеження 1NF і кожен описовий атрибут функціонально повно залежить від первинного ключа (у тому числі і складеного). Третя нормальна форма.Відношення знаходиться у ЗNF, якщо виконуються обмеження 2NF і всі описові атрибути відношення взаємно незалежні і повністю залежать від первинного ключа, тобто кожний описовий атрибут не транзитивно залежить від ключа. Четверта нормальна форма (4НФ, 4NF) вимагає, аби в схемі баз даних не було нетривіальних багатозначних залежностей множин атрибутів від будь чого, окрім надмножини ключа-кандидата. Вважається, що таблиця знаходиться у 4НФ тоді, і тільки тоді, коли вона знаходиться в НФБК, та багатозначні залежності є функціональними залежностями. Четверта нормальна форма усуває небажані структури даних — багатозначні залежності. П'ята нормальна форма (5НФ, 5NF, PJ/NF) вимагає, аби не було не тривіальних залежностей об'єднання, котрі б не витікали із обмежень ключів. Вважається, що таблиця в п'ятій нормальній формі, тоді, і тільки тоді, коли вона знаходиться в 4НФ, та кожна залежність об'єднання зумовлена її ключами-кандидатами. |