ВСТУП

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

Введення інформації із зовнішніх та внутрішніх джерел;

Обробка вхідної інформації;

Зберігання інформації для її подальшого використання;

Виведення інформації у зручному для користувача вигляді.

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

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

Інформація про працівників;

Інформація про організацію;

Інформація про документи;

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

СТРУКТУРА БАЗИ ДАНИХ

інформаційна система інтерфейс сервер

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

Основним засобом розробки логічної моделіданих у теперішній моментє різні варіанти ER-діаграм (Entity-Relationship, діаграми сутність-зв'язок).

На малюнку 1 представлена ​​логічна схема бази даних предметної області Офіс. На логічній схемі зображені такі сутності: Organization, Employee, Job_Title, Document, Document_type. Опис сутностей міститься у таблиці 1.

Малюнок 1 - Логічна схемаБД

Таблиця 1 – Опис сутностей логічної моделі даних

Назва	Призначення
	Описує працівників, що перебувають у штаті організації. Містить атрибути: ПІБ, посада та організація в штаті якої перебуває. Пов'язана зв'язком "один до одного" з сутністю "JobTitle".
	Описує організацію, в якій працюють співробітники. Містить атрибути: назву, адресу. Пов'язана зв'язком один до одного з сутністю Employee.
	Довідник посад. Містить атрибут: посада (назва посади).
	Описує всі документи і хтось із працівників над ними працює. Містить атрибути: назву, тип документа, працівника. Пов'язана зв'язком один до одного з сутністю Employee і зв'язком один до одного з сутністю DocumentType.
	Довідник типів документів. Містить тип документа атрибут.

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

На малюнку 2 представлена ​​фізична схема БД. На схемі зображені сутності, і навіть зазначені типи даних. Так як сутності "Document_type" і "Employee" пов'язані з сутністю "Document" зв'язком "один до одного", у фізичній схемі додаються сутності-зв'язки "Document_typeDocument" і "EmployeeDocument". Сутності-зв'язки містять зовнішні ключі, Що забезпечують вид зв'язку "один до одного".

Малюнок 2 – Фізична схема БД

Створення схеми даних

Після створення структур таблиць БД слід створити схему даних. Попередньо всі таблиці БД мають бути закриті. Створювати або змінювати зв'язки між відкритими таблицямине можна.

Створення схеми даних починається у вікні База данихз вибору команди Сервіс Схема даних. Після виконання зазначеної команди відкривається два вікна: Схема данихі Додавання таблиці,при цьому активним є вікно Додавання таблиці(рис. 12), в якому можна вибрати таблиці, що включаються до схеми даних.

Мал. 12. Два вікна: Схема даних та Додавання таблиці

Після вибору потрібних таблицьу вікні Схема данихбудуть представлені відповідні таблиці зі списком своїх полів. За потреби розміри вікон таблиць можна змінити, щоб список полів було видно повністю. Далі можна починати визначення зв'язків між таблицями.

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

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

Після виконання зазначених дійвідчиниться вікно Зміна зв'язків(Рис. 13). При цьому в полі Тип відношенняавтоматично встановиться значення одним-багатьом.

Мал. 13. Вікно Зміна зв'язків

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

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

Забезпечення зв'язкової цілісності даних означає, що за коригування бази даних Accessзабезпечує для пов'язаних таблиць контроль за дотриманням таких умов:

q До підпорядкованої таблиці не може бути додано запис з неіснуючим у головній таблиці значенням ключа зв'язку;

q У головній таблиці не можна видалити запис, якщо не видалено пов'язані з нею записи в підпорядкованій таблиці;

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

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

Встановлення між двома таблицями зв'язку типу 1:М або 1:1 і завдання зв'язку параметрів цілісності даних можливе тільки за наступних умов:

q Пов'язані поля мають однаковий тип даних;

q Обидві таблиці зберігаються в одній базі даних;

q Головна таблиця пов'язується з підлеглою таблицею за первинним простим чи складовим ключем головної таблиці.

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

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

У режимі каскадного оновлення пов'язаних полів при зміні значень даних у полі зв'язку головної таблиці Access автоматично змінить значення даних у відповідному полі в підпорядкованих таблицях.

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

Міжтабличний зв'язок, що утворився, відображається у вікні Схема даниху вигляді лінії, що з'єднує два поля різних таблиць. При цьому на лінії зв'язку у головній таблиці відображається символ - 1 , у підпорядкованої таблиці символ - нескінченність ( ¥ ) (рис. 14) .

Мал. 14. Схема даних. Зв'язок двох таблиць ключового поля Код постачальника.

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

Схема як структура бази даних

Основними об'єктами схеми є таблиці та зв'язки.

Схема як об'єкт бази даних

Є й інше поняття схеми теорії баз даних.

В Oracle вона прив'язується тільки до одного користувача (USER) і є логічним наборомоб'єктів бази даних Схема створюється під час створення користувачем першого об'єкта, і наступні об'єкти створені цим користувачем стають частиною цієї схеми.

Вона може включати інші об'єкти, що належать цьому користувачу:

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

Існують і подібні схеми, такі як:

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

Існують об'єкти незалежно від схеми

• каталоги,
• профілі,
• ролі,
• сегменти,
• табличні області
• користувачі.

Рівні схеми бази даних

• Концептуальна схема - карта концепцій та їх зв'язків
• Логічна схема - карта сутностей та їх атрибутів та зв'язків
• Фізична схема – часткова реалізація логічної схеми
• Схема об'єкта - об'єкт БД Oracle

Примітки

Див. також

• Моделювання даних

Wikimedia Foundation. 2010 .

Дивитись що таке "Схема бази даних" в інших словниках:

Схема бази даних- 53. Схема бази даних Data base scheme Опис бази даних у контексті конкретної моделіданих Джерело: ГОСТ 20886 85: Організація даних у системах обробки даних. Терміни та визначення …

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

Концептуальна схема бази даних- 56. Концептуальна схема бази даних Концептуальна схема Conceptual scheme Схемабази даних, визначальна подання бази даних, єдине всім її додатків і залежить від використовуваного у системі управління цією базою даних… … Словник-довідник термінів нормативно-технічної документації

зовнішня схема бази даних- Зовнішня схема Схема бази даних, що підтримується системою управління бази даних для додатків. [ГОСТ 20886 85] Тематики організація даних у сист. оброб. даних Синоніми зовнішня схема EN external scheme … Довідник технічного перекладача

Зовнішня схема бази даних - 54. Зовнішня схемабази даних Зовнішня схема External scheme Схема бази даних, підтримувана системою управління бази даних додатків Джерело: ГОСТ 20886 85: Організація даних у системах обробки даних. Терміни та визначення … Словник-довідник термінів нормативно-технічної документації

внутрішня схема бази даних- Внутрішня схема Схема бази даних, що визначає подання даних у середовищі зберігання та шляхи доступу до них. [ГОСТ 20886 85] Тематики організація даних у сист. оброб. даних Синоніми внутрішня схема EN internal scheme … Довідник технічного перекладача

Внутрішня схема бази даних - 55. Внутрішня схемабази даних Внутрішня схема Internal scheme Схема бази даних, що визначає подання даних у середовищі зберігання та шляхи доступу до них Джерело: ГОСТ 20886 85: Організація даних у системах обробки даних. Терміни та… … Словник-довідник термінів нормативно-технічної документації

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

У цій статті не вистачає посилань на джерела інформації. Інформація має бути перевіряється, інакше вона може бути поставлена ​​під сумнів та видалена. Ви можете … Вікіпедія

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

Книги

• Логічне проектування баз даних, Є. А. Морозов. Робота присвячена проблемі проектування баз даних. Розглядається одна із стадій іроектування, а саме стадія логічного проектування, в ході виконання якої розробляється схема ...

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

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

Малюємо діаграму

Припустимо, потрібно спроектувати схему бази даних, в якій зберігається інформація про музичних виконавців, альбоми та пісні. на початковому етапіКоли у нас ще зовсім нічого немає, зручно почати з малювання діаграми майбутньої схеми. Можна почати з начерку ручкою на аркуші паперу, можна відразу взяти спеціалізований редактор. Їх зараз дуже багато, всі вони влаштовані досить схожим чином. Під час підготовки цієї нотатки я скористався DbSchema. Це платна програмаале мені здається, що вона коштує своїх грошей. До того ж у нормальних компаніях зазвичай оплачують вартість софту, необхідного для роботи. Тріал у DbSchema, якщо що, становить два тижні.

Намалювати наступну діаграму зайняло у мене близько десяти хвилин:

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

Генеруємо SQL і згодовуємо його СУБД

Неважко помітити, що дана діаграмалегко відображається в код для створення схеми бази даних на мові SQL. У DbSchema згенерувати SQL можна, сказавши Schema → Generate Schema and Data Script. Потім отриманий скрипт можна згодувати СУБД, що використовується вами:

cat music.sql psql -hlocalhost test_database test_user

Я використовував PostgreSQL. Інформацію про те, як встановити цю СУБД, ви знайдете в цій статті.

Отже, чим я керувався при проектуванні схеми?

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

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

Грубо кажучи, таблиця знаходиться в першій нормальній формі (1НФ), якщо на перетині будь-якого рядка і будь-якого стовпця в таблиці знаходиться одне значення. У сучасних РСУБД ця умова завжди виконується. Навіть якщо СУБД підтримує безліч чи масив, на перетині рядка і стовпця зберігається рівно одне значення типу безліч або масив. Але в таблиці (user varchar(100), phone integer)не може бути рядки alex - 1234, 5678. У 1НФ може бути лише два терміни - alex-1234 і alex-5678.

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

Таблиця знаходиться в третій нормальній формі, якщо вона знаходиться в 2НФ і жоден неключовий атрибут не знаходиться в транзитивній функціональної залежностівід первинного ключа Наприклад, розглянемо таблицю (employee varchar(100) primary key, department varchar(100), department_phone integer). Очевидно, що вона знаходиться у 2НФ. Але телефон відділу перебуває у транзитивної функціональної залежності від імені співробітника, оскільки співробітник однозначно задає відділ, а відділ однозначно задає телефон відділу. Для приведення таблиці в 3НФ потрібно розбити її на дві таблиці - employee-department та departmnet-phone.

Легко бачити, що нормалізація зменшує надмірність бази даних та перешкоджає внесенню випадкових помилок. Наприклад, якщо залишити таблицю з останнього прикладу в 2НФ, то можна помилково прописати одному й тому ж відділу різні телефони. Або розглянемо компанію з п'ятьма відділами та 1000 співробітниками. Якщо у відділу змінився номер телефону, то для його оновлення в базі даних у разі 2НФ потрібно просканувати 1000 рядків, а у випадку з 3НФ лише п'ять.

Схема даних

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

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

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

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

Зв'язки у схемі даних можуть бути встановлені для будь-якої пари таблиць з однаковим полем, що дозволяє поєднувати дані таблиці.

Схеми даних відображаються в області навігації у вікні БД лише у проектах Access, які працюють із базами даних сервера. Щоб відобразити схему даних у БД Access використовують команду Схема даних, розміщену у групі Відносинина вкладці Робота з базами даних.

Приклад 1

Розглянемо модель даних предметної області «Постачання товарів» (рисунок 1). Схема даних Access, побудована для цієї моделі даних, представлена ​​малюнку 2.

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

Особливості схеми даних

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

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

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