Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
Не вказано
Кафедра:
Не вказано
Інформація про роботу
Рік:
2024
Тип роботи:
Розрахункова робота
Предмет:
Організація баз даних і знань
Частина тексту файла (без зображень, графіків і формул):
Міністерство освіти і науки України
НУ«Львівська політехніка»
Кафедра ІСМ
Розрахункова робота
з курсу
Організація баз даних та знань
Зміст
Вступ…………………………………………………………………………………3
Визначення та опис предметної області БД………………………………...4
Побудова концептуальної моделі типу «сутність- зв’зок» до предметної області…………………………………………………………………………6
Побудова логічної структури БД, визначення атрибутів, відношень зв’язків……………………………………………………………………….11
Визначення ключів відношень, нормалізація БД до другої нормальної форми………………………………………………………………………...13
Побудова прикладів відношень і наповнення їх текстовими значеннями даних…………………………………………………………………………14
Виконання над відношеннями операцій реляційної алгебри:…………...17
Перетин, об’єднання та різниця відношень з його копією;…………..18
Декартовий добуток відношення;……………………………………....18
Селекція, проекція одного з відношень;……………………………….18
Натуральне та умовне з’єднання відношень;………………………….19
Включення, виключення кортежів, зміна значень атрибутів у одному з відношень;………………………………………………………………..19
Визначення нового атрибута, вилучення атрибута, зміна параметрів атрибута в одному з відношень…………………………………………20
Висновок……………………………………………………………………………21
Список використаної літератури………………………………………………….22
Вступ
Поняття бази даних (data base) як засобу опрацювання інформації з'явилось на етапі застосування комп'ютерних систем у сфері бізнесу, фінансів та управління. Початковою базою даних називався будь-який масив, в якому дані накопичувались для подальшого опрацювання. 3 часом сам термін набув більш конкретного поняття, а технології створення, зберігання i застосування баз даних розвинулись в окрему галузь комп'ютерних наук.
Теpмін "база даних" загалом є достатньо об'ємним, складним та багатостороннім для однозначного визначення. Попередньо визначимо, що база даних - це множина взаємопов'язаних даних, об’єднаних спільним середовищем зберігання, спільним застосуванням, єдиною формою представлення, єдиними методами i засобами керування.
Завданням даної розрахункової роботи є опис певної предметної області, на основі якої буде розроблена реляційна база даних. Отже, оберемо таку предметну область:
Відомо множину магазинів, які займаються реалізацією продуктових товарів. Потрібно побудувати базу даних для роботи з цими магазинами, тобто вести облік наявних товарів.
Визначення та опис предметної області бази даних
Предметна область (ПО) – частина реального світу, що існує незалежно від людини і становить інтерес щодо її відображення у базі даних.
Модель бази даних – це сукупність логічних конструкцій, що використовуються за кодами структури даних і зв’язків між ними у середині бази даних (БД).
Моделювання даних – діяльність, яка пов’язана з визначенням вимог до даних і проектування баз даних, сховищ даних або інших систем, що використовують ресурси даних, результатом якої є опис предметної області системи засобами якої-небудь моделі даних.
Концептуальна модель ПО – формальне подання сукупності поглядів, що характеризують безліч можливих станів ПО і безліч можливих переходів із одного стану в інший. Потрібно побудувати концептуальну модель ПО, яка б враховувала вимоги до цього процесу, адекватно відображала її.
Предметна область передбачає подання конкретних описів процесу чи предметів, явищ та їх властивостей, що підлягають до завдання розрахункової роботи.
Довідник призначений для зберігання даних про літаки (назва, дата виготовлення, постачальник), льотчик (ім’я, звання, дата народження, адреса телефон) постачальників (назва, адреса).
Для обліку і пошуку потрібної інформації в довіднику літаків виділяємо такі ознаки або властивості:
Головна (номер п/п, код літака, ІД льотчика, взятий на експлуатацію, списаний).
Літаки (код літака, марка, дата виготовлення, код постачальника, вартість, величина пробігу).
Льотчики (ІД льотчика, ім’я, звання, дата народження, адреса, телефон).
Постачальники (код постачальника, фірма постачальник, адреса постачальника, телефон постачальника, країна виробник).
Усі переліченні властивості літаків можна представити такими інформаційними відношеннями:
Головна містить інформацію в кодах про кожен літак і його льотчика в базі.
Літаки містить властивості про літак, інформацію в кодах про льотчика, постачальника.
Льотчики включає всю інформацію про льотчика.
Постачальник містить контактні дані про фірму-постачальника даного літака.
До об’єктів і властивостей, що описують літаки можна зарахувати:
Код літака
Назва літака
Дата виготовлення
Вартість
Величина пробігу
ІД льотчика
Взятий на експлуатацію
До інформації про льотчика можна віднести:
ІД льотчика
Ім’я
Звання
Дата народження
Адреса телефон
Код закріпленого за ним літака
До інформації про постачальника можна віднести:
Код постачальника
Фірма постачальник
Адреса постачальника
Країна постачальник
Телефон постачальника
Літак, що постачається
Дата виготовлення
Вартість літака
Величина пробігу.
Побудова концептуальної моделі типу «сутність – зв’язок» до предметної області
Процес проектування бази даних починається з аналізу того, якого змісту інформація і які взаємозв’язки між інформаційними елементами потрібно подавати. Структура або схема бази даних визначається засобами різних мов або систем позначень, придатних до опису проектів. По завершенні етапу уточнень і погоджень проект перетвориться у форму, яка сприймається або інтерпретується СУБД і база даних починає власне життя.
Одним із найпоширеніших засобів абстрактного відображення структур баз даних є ER-модель або модель «сутність-зв’язок». У ER-моделі структура даних подається графічно, у вигляді діаграми сутностей і зв’язків, яка складається з елементів трьох основних типів, а саме: множин сутностей, атрибутів і зв’язків.
Сутність – це абстрактний об’єкт визначеного виду. Набір однорідних сутностей утворює клас сутностей. Сутності поділяються на звичайні і слабкі. Слабкою називається така сутність, існування якої залежить від іншої сутності, тобто вона не може існувати, якщо цієї іншої сутності немає. Кожна сутність має хоча б один тип, але у деяких сутностей може бути одночасно декілька типів.
Кожній множині сутностей одного типу відповідає набір атрибутів, що зображають їх властивості. Атрибут – це будь-яка деталь або аспект, що сприяє якісному або кількісному опису сутностей, їх ідентифікації, класифікації або відображенню їх стану. У ER-моделі атрибути є атомарними значеннями.
Атрибути поділяються на пості і складені (групові). Груповий – це атрибут, який потім можна поділити на декілька додаткових атрибутів. Однозначний атрибут – це атрибут, що може приймати єдине значення. Багатозначні або множинні атрибути – це атрибути, які можуть приймати множину значень (номера телефонів, імена).
Зв’язки – це відповідність між двома або більше множинами сутностей. Сутність, включена у зв’язок, називається його учасником, а кількість учасників зв’язку називається його ступенем. Якщо кожен примірник сутності бере участь хоча б у одному примірнику зв’язку, то участь сутності у зв’язку називається повною, інакше – частковою. Прикладний зв’язок або просто зв’язок – це деяка найменована асоціація двох сутностей. Найпоширенішим різновидом є бінарні зв’язки, що з’єднують дві множини сутностей, ER-модель допускає наявність зв’язків, що охоплюють довільну кількість множин сутностей – багатосторонні або множинні зв’язки. Бінарні зв’язки є декількох типів, а саме: «один - до - одного» (1:1), «багато – до - одного» (N:1), «багато – до - багатьох» (N:M).
ER-діаграма графічно зображає множину сутностей, їхні атрибути, зв’язки. Елементи названих видів описуються вершинами графа, і для завдання приналежності елемента до визначеного виду використовують спеціальні графічні фігури.
Прямокутник – для множин сутностей. Назва сутності (іменник) записується у центрі прямокутника. Прямокутники сутностей слабких типів позначаються подвійною лінією (рис. 2.1).
а) б)
рис.2.1. а – звичайна, б – слабка.
Овал – для атрибутів. У кожному овалі міститься ім’я того атрибута, який він зображає. Атрибути, імена яких підкреслені, є елементами ключа (рис.2.2).
Ромб – для зв’язків. Кожен зв’язок ідентифікується описовою назвою. Назва зв’язку (дієслово) записується у середині ромба. Іноді буває зручно асоціювати атрибут зі зв’язком. Ромб рисують подвійною лінією, якщо це зв’язок між слабкою сутністю і сутністю, від якої залежить її існування
(рис. 2.3).
а) б)
рис. 2.3. а- простий, б – слабкий.
У розрахунковій роботі необхідно визначити ключові атрибути сутностей, розробити обмеження унікальності цілісності посилань, доменного і загального вигляду для множин сутностей. Аналіз визначених об’єктів і атрибутів дає можливість створення реляційної бази даних, побудувавши її інфологічну модель засобами ER-діаграми (рис. 2.4).
Наведемо перелік звичайних сутностей:
Головна (Номер п/п, Код літака, ІД льотчика, Взятий на експлуатацію, Списаний).
Це сутність для збереження кодової інформації про літак і льотчика;
Літаки (Код літака, Марка, Дата виготовлення, Код постачальника, Величина пробігу, Вартість).
У даній сутності зберігається інформація про літаки.
Льотчики (ІД льотчика, Ім’я, звання, дата народження, адреса, телефон).
Дана сутність служить для зберігання усіх характеристик льотчиків.
ПОСТАЧАЛЬНИК (Код постачальника, Фірма постачальник, адреса постачальника, телефон постачальника, країна виробник).
У цій сутності відображена інформація про постачальників.
Побудова логічної структури бази даних, визначення атрибутів, відношень, зв’язків.
Концептуальна модель передбачає два етапи реалізації: інфологічний та даталогічний.
Інфологічна модель – будується без врахованих засобів і технологій реалізації проекту.
Даталогічна модель – опис структури в термінах конкретної СУБД чи технології, які вибираються для реалізації бази даних на основі інфологічної моделі.
Інфологічний етап. На цьому етапі розробляється логічна структура бази даних, яка відповідає концептуальній моделі ПО. Результатом виконання цього етапу є схема БД. Оскільки переважна більшість комерційних систем баз даних застосовує реляційну модель, доречно припустити, що під час проектування було б доцільно застосувати ту саму модель, замість моделі «сутність-зв’язок».
Даталогічний етап. На цьому етапі інфологічна модель, яка є достатньо загальною і не є пов’язаною з технологією реалізації, перетворюється опис схеми бази даних у термінах вибраної СУБД, після аналізу потреб і особливостей бази даних, вивчених на інфологічному етапі.
У даному розділі необхідно побудувати логічну схему бази даних, яка складається із схем не менше, ніж трьох взаємопов’язаних таблиць, тобто, щоб вона містила поля всіх типів, що підтримує СУБД MS ACCESS – символьні, числові, дата, час, об’єкт. Отже, до предметної області процедури проектування подаються у відповідних таблицях:
ТАБЛИЦЯ Головна *(звичайна сутність)
ПЕРВИННИЙ КЛЮЧ (номер п/п)
ПОЛЯ (код літака числовий, ІД льотчика числовий, Взятий на експлуатацію дата, Списаний дата)
ТАБЛИЦЯ Літаки *( звичайна сутність)
ПЕРВИННИЙ КЛЮЧ (код літака)
ПОЛЯ (Марка текстовий 50, Дата виготовлення дата, код постачальника числовий, вартість грошовий, величина пробігу числовий)
ТАБЛИЦЯ Льотчики *(звичайна сутність)
ПЕРВИННИЙ КЛЮЧ (ІД льотчика)
ПОЛЯ (ім’я текст 20, звання текст 50, Дата народження дата, Адреса текст 50, телефон числовий)
ТАБЛИЦЯ Постачальники *(звичайна сутність)
ПЕРВИННИЙ КЛЮЧ (код постачальника)
ПОЛЯ (фірма постачальник текст 30, адреса постачальника 30, телефон постачальника числовий, країна виробник текст 30)
Визначення ключів відношень, нормалізація бази даних до другої нормальної форми.
У межах реляційної моделі даних Е.Ф. Кодд розробив апарат нормалізації відношень і запропонував механізм, який дає змогу привести відношення до третьої нормальної форми. Нормалізація схеми відношення виконується шляхом декомпозиції схеми.
Нормалізація – це розбиття таблиці на дві або більше, що володіють кращими властивостями під час додавання, зміни і видалення даних. Остаточна мета нормалізації зводиться до отримання такого проекту бази даних, в якому кожен факт розташовується лише в одному місці, тобто виключена надмірність інформації. Це робиться не стільки з метою економії пам’яті, скільки для виключення можливої суперечності даних, що зберігаються. Кожна таблиця у реляційній базі даних задовольняє умову, відповідно до якої у позиції на перетині кожного рядка і стовпця таблиці завжди знаходиться єдине атомарне значення, і ніколи не може бути множина таких значень. Будь-яка таблиця, що задовольняє цю умову, називається нормалізованою. Фактично, ненормалізовані таблиці, тобто таблиці, які містять групи, що повторюються навіть не реалізуються у реляційних БД.
Кожна нормалізована таблиця автоматично вважається таблицею у першій нормальній формі. Таблиця перебуває у 2НФ, якщо вона перебуває у 1НФ і задовольняє, крім того, деяку додаткову умову. Отже, кожна нормальна форма є у певному сенсі обмеженою але і прийнятнішою, ніж попереднє.
У розрахунковій роботі необхідно здійснити нормалізацію відношень бази даних до третьої (другої) НФ. Так, як логічна, була побудована у попередньому розділі, зараз варто перевірити чи не порушені у предметній області принципи нормалізації, тобто кожне не ключове поле кожної таблиці.
Побудова прикладів відношень і наповнення їх текстовими значеннями даних.
Рис. 5.1 Структура зв’язків.
У таблиці Головна:
Номер п/п – ключове поле, лічильник.
Код літака – числове поле.
ID льотчика – числове поле.
Взятий на експлуатацію – поле дати довгого формату.
Списаний – поле дати довгого формату.
У таблиці Літаки:
Код літака – числове поле.
Марка – текстове поле.
Дата виготовлення – поле дати.
Код постачальника – числове поле.
Вартість – грошове поле.
Довжина пробігу – числове поле.
У таблиці Льотчики:y6
ID льотчика – числове поле.
Ім’я – текстове поле.
Звання – текстове поле.
Дата народження – поле типу дати.
Адреса – текстове поле.
Телефон – числове поле.
У таблиці Постачальник:
Код постачальника – числове поле.
Фірма постачальник – текстове поле.
Адреса постачальника – текстове поле.
Телефон постачальника – числове поле.
Фірма виробник – текстове поле.
Адреса виробник – текстове поле.
Телефон виробника – числове поле.
Рис. 5.2 Наповнення таблиці Головна.
Рис. 5.10 Наповнення таблиці Літаки.
Рис. 5.11 Наповнення таблиці Льотчики.
Рис. 5.12 Наповнення таблиці Постачальники.
Виконання над відношеннями операцій реляційної алгебри.
Відношення є самі по собі множинами, тому до них застосовані всі поняття й операції, характерні до множин, плюс специфічні поняття й операції. Операндами для операцій реляційної алгебри є відношення. Результатом виконання операцій реляційної алгебри також є відношення.
Реляційна алгебра – це множина операцій над відношеннями реляційних баз даних, яка підтримується в усіх базах даних реляційного типу незалежно від їх змісту, галузі застосування та технології, на основі якої вони реалізовані.
Умовно всі операції реляційної алгебри за змістом та способами виконання прийнято розділяти на декілька груп. Теоретико - множині операції ґрунтуються на тому, що кожне відношення бази даних можна розглядати як множину однотипних кортежів і відповідно до них можна застосувати операції, запозичені з теорії множин.
Отже, виконаємо операції реляційної алгебри над відношеннями бази даних фірми. Оскільки теоретико – множинні операції виконуються над відношеннями з однаковими множинами атрибутів, створимо копію відповідного відношення МАГАЗИН – МАГАЗИН_1, змінивши його інформаційне наповнення (рис.6.1 і 6.2).
Рис. 6.1 початковий стан відношення Головна
Рис. 6.2 початковий стан відношення Головна_1
Рис. 6.3 результат об’єднання відношень
Рис. 6.4 результат перетину відношень
Рис. 6.5 результат різниці відношень Головна\ Головна_1
Рис. 6.6 результат декартового добутку ГоловнаЛітаки
Рис. 6.7 результат проекції відношення Головна
Рис. 6.8 результат операції селекції Головна=(Номер<3)
Рис. 6.9 результат натурального з’єднання Головна * Літаки
Рис. 6.10 проекція відношення Льотчики
Рис. 6.11 результат умовного з’єднання Головна * Льотчики
Рис. 6.12 результат включення нового кортежу Головна
Рис. 6.13 результат вилучення кортежу Головна
Рис. 6.14 результат зміни значень атрибутів Головна_1
Рис. 6.15 результат визначення нового атрибутів Головна_1 „колір”
Рис. 6.16 результат вилучення атрибутів Головна_1 „Списаний”
Рис. 6.17 результат зміни імені атрибута Головна (Код_літака, ІД_льотчика, Взятий_на_експлуатацію)
Рис. 6.18 результат функції С(дата)
Рис. 6.19 результат зміни області атрибута
Висновок
СУБД MS ACCESS є достатньо ефективним і потужним засобом розробки як локальних застосувань середнього та малого обсягу різноманітного характеру, так і клієнтських засобів доступу до бази даних в архітектурі «клієнт - сервер». У розпорядження користувача та розробника СУБД надає набір засобів для виконання основних функцій:
створення, модифікація та супровід баз даних реляційного типу;
підтримка другої нормальної форми баз даних, гнучкої системи зв’язків між даними та правил цілісності;
розробка запитів різного характеру та типу;
імпорт, експорт та підключення зовнішніх даних, у тому числі, і серверних баз даних;
візуальна розробка і від лагодження екранних засобів відображення та опрацювання даних із застосуванням об’єктно – орієнтованого підходу та ситуаційного керування процесами;
проектування форм вихідних документів із застосуванням як вбудованого, так і зовнішніх генераторів звітів;
розробка застосувань із застосуванням макрокоманд для керування процесами та реалізації основних дій користувача;
можливість розробки прикладних систем, сумісних із іншими СУБД та середовищами.
Список використаної літератури
1. Бекаревич Ю., Пушкина Н. Самоучитель Microsoft Access 2000. - СПб.: БХВ- Санкт-Петербург, 1999. -432 с.
2. Берко А.Ю. Проектування та експлуатація баз даних реляційного типу: Методичні вказівки по виконанню лабораторних робіт з курсу «Організація баз даних» для студентів, що навчаються за базовим напрямком «Комп'ютеры науки». - Львів, ДУ ЛП, 1996. - 56 с.
3. Вейскас Дж. Эффективная работа с СУБД Microsoft Access 7.0 для Windows 95. - СПб.: Питер, 1997. - 848 с.
4. Дейт К. Дж. Введение в системы баз данных: Пер. с англ. - К.: Диалектика, 2000. - 784 с.
5. Мейер Д. Теория реляционных баз данных: Пер. с англ. - М.: Мир, 1987. - 608 с.
6. Михеева В., Харитонова И. Microsoft Access 2000. -СПб.: БХВ- Санкт-Петербург, 1999.
7. Новиков Ф., Яценко A. Microsoft Office 2000 в целом. -СПб.: БХВ-Санкт-Петербург, 1999.
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора