Проектування інформаційної системи "Довідник астронома"

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Національний технічний університет «Харківський політехнічний інститут»

Курсова робота

Проектування інформаційної системи "Довідник астронома"

Обаполенко В.Р.

Харків - 2019

Зміст

Вступ

1. Постановка задачі

2. Основи реляційних баз данних

3. Інфологічна модель даних

4. Даталогічна модель даних

5. Посібник користовачу

Висновки

Список використаної літератури

Вступ

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

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

В ієрархічній моделі зв'язок даних «один до одного» означає, що кожному значенню елемента даних відповідає одне і тільки одне значення, пов'язаного з ним елемента.

В сітьовій моделі зв'язок «один до багатьох» означає, що значенню елемента відповідають багато (більше одного) значень, пов'язанню з ним елементів.

В реляційній моделі зв'язок «багатьох до багатьох» указує на те, що декільком значенням елементів даних відповідає декілька значені елементів даних.

У даній роботі розглядається автоматизація бази даних для довідника астронома.

1. Постановка задачі

Система розрахована для обробки даних про видимі зірки, пошук зірок.

2. Основи реляційних баз данних

Реляційна база даних - база даних, заснована на реляційній моделі даних. Для роботи з реляційними БД застосовують реляційні СКБД. Інакше кажучи, реляційна база даних - це база даних, яка сприймається користувачем як набір нормалізованих відношень різного ступеня. Реляційна база даних є сукупністю елементів даних, організованих у вигляді набору формально описаних таблиць, з яких дані можуть бути доступними або повторно зібрані багатьма різними способами без необхідності реорганізації таблиць бази даних. Використання реляційних БД було запропоноване Едгаром Коддом в 1970 році.

1. Нормалізація

Нормалізація схеми бази даних - покроковий процес розбиття одного відношення (на практиці: таблиці) відповідно до алгоритму нормалізації на декілька відношень на базі функціональних залежностей.

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

2. Нормальні форми

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

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

Перша нормальна форма

Перша нормальна форма (1НФ, 1NF) утворює ґрунт для структурованої схеми бази даних:

· кожна таблиця повинна мати основний ключ: мінімальний набір колонок, які ідентифікують запис;

· уникнення повторень груп (категорії даних, що можуть зустрічатись різну кількість разів в різних записах) правильно визначаючи неключові атрибути;

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

Друга нормальна форма

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

Схема бази даних повинна відповідати вимогам першої нормальної форми. Дані, що повторно з'являються в декількох рядках, виносяться в окремі таблиці.

Третя нормальна форма

Третя нормальна форма (3НФ, 3NF) вимагає, аби дані в таблиці залежали винятково від основного ключа:

· схема бази даних повинна відповідати всім вимогам другої нормальної форми;

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

Нормальна форма Бойса - Кодда

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

· проекція без атрибутів залежної частини такої функціональної залежності;

· проекція на всі атрибути цієї функціональної залежності.

Четверта нормальна форма

Четверта нормальна форма (4НФ, 4NF) потребує, аби в схемі баз даних не було нетривіальних багатозначних залежностей множин атрибутів від будь чого, окрім надмножини ключа-кандидата. Вважається, що таблиця знаходиться у 4НФ тоді і лише тоді, коли вона знаходиться в НФБК та багатозначні залежності є функціональними залежностями. Четверта нормальна форма усуває небажані структури даних - багатозначні залежності.

П'ята нормальна форма

П'ята нормальна форма (5НФ, 5NF, PJ/NF) вимагає, аби не було нетривіальних залежностей об'єднання, котрі б не витікали із обмежень ключів. Вважається, що таблиця в п'ятій нормальній формі тоді і лише тоді, коли вона знаходиться в 4НФ та кожна залежність об'єднання зумовлена її ключами-кандидатами.

Нормальна форма домен/ключ

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

Шоста нормальна форма

Таблиця знаходиться у 6NF, якщо вона знаходиться у 5NF та задовольняє вимозі відсутності нетривіальних залежностей. Зазвичай 6NF ототожнюють з DKNF.

3. Ключі

Ключ - це стовпець (може бути декілька стовпців), що додається до таблиці і дозволяє встановити зв'язок із записами в іншій таблиці.

Існують ключі двох типів: первинні і вторинні (зовнішні).

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

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

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

Існує три типи первинних ключів: ключові поля лічильника (лічильник), простий ключ і складовий ключ.

Поле лічильника (Тип даних «Счетчик»). Для кожного запису цього поля таблиці автоматично заноситься унікальне числове значення.

Простий ключ. Якщо поле містить унікальні значення, такі як коди чи інвентарні номери, то це поле можна визначити як первинний ключ. В якості ключа можна визначити всі поля, що містить дані, якщо це поле не містить повторювані значення або значення Null.

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

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

4. Робота з тригерами

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

· додаванням INSERT,

· вилученням рядка в заданій таблиці DELETE,

· або зміною даних у певному стовпці заданої таблиці UPDATE.

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

Момент запуску тригера визначається за допомогою ключових слів BEFORE (тригер запускається до виконання пов'язаного з ним події; наприклад, до додавання запису) або AFTER (після події). У випадку, якщо тригер викликається до події, він може внести зміни у модифікований подією запис (звичайно, за умови, що подія - не вилучення запису).

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

інформаційна система реляційний тригер

create trigger Zirkr

on Звезды

instead of insert

as

declare @с nvarchar (40)

declare cur cursor for

select Название_звездfrom inserted

open cur

fetch next from cur into @с

while @@FETCH_STATUS = 0

begin

if not exists (select * from Звезды where Название_звезд= @с)

insert into Звезды (Название_товара) values (@с)

fetch next from cur into @с

raiserror ('плохо',16,10)

end

close cur

deallocate cur

go

5. Представлення

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

У даній роботі було створено декілька представлень.

6. Збережені процедури

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

Типи процедур, що зберігаються:

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

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

* Тимчасові збережені процедури, існують лише деякий час, після чого автоматично знищуються сервером. Вони діляться на локальні і глобальні. Локальні тимчасові Збережені процедури, можуть бути викликані тільки з того з'єднання, в якому створені. При створенні такої процедури їй необхідно дати ім'я, що починається з одного символу #. Як і усі тимчасові об'єкти, процедури цього типу, що зберігаються, автоматично віддаляються при відключенні користувача, перезапуску або зупинці сервера. Глобальні тимчасові Збережені процедури, доступні для будь-яких з'єднань сервера, на якому є така ж процедура. Для її визначення досить дати їй ім'я, що починається з символів ##. Віддаляються ці процедури при перезапуску або зупинці сервера, а також при закритті з'єднання, в контексті якого вони були створені.

У даній роботі було створено декілька збережених процедур. Цей приклад видаляє зірку з бази.

CREATE PROCEDURE [dbo].[sp_dezirka]

@zirkaID int

AS

declare @zirkacode int

declare @delError int

BEGIN transaction

select @zirkacode = Код_Звезды from Звезды where Код_Звезды = @zirkaID

BEGIN

DELETE FROM Звезды WHERE Код_Звезды = @zirkaID

select @delError = @@ERROR

COMMIT TRAN

END

3. Інфологічна модель даних

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

4. Даталогічна модель даних

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

5. Посібник користувачу

База даних має головну сторінку, де знаходяться кнопки переходу за категоріями.

Висновки

У даній роботі була створена свою база даних працівника магазину «Оптика». База була створена в Microsoft SQL Managmant Studio та автоматизована за допомогою програмного продукту в Visual Studio. Для створення бази були використані запити, тригери, представлення та збережені процедури.

Список використаної літератури

1. Гайна Г.А. Основи проектування баз даних: Навчальний посібник. ? К.: КНУБА, 2005. - 204 с.

2. https://studfiles.net/preview/5784260/

3. https://studopedia.com.ua/1_10927_osnovni-ponyattya-relyatsiynih-baz-danih.html

4. https://studfiles.net/preview/5210288/page:32/

Размещено на Allbest.ru