Читайте также:
|
|
Ключові поняття й терміни. Для переходу від опису даних предметної області у вигляді концептуального опису (об'єктів, процесів, функцій, документів та ін.) до опису даних у вигляді баз даних використовується проміжний опис – у вигляді інформаційно-логічної моделі предметної області. Елементами такої моделі є інформаційні об'єкти й зв'язки між ними.
Інформаційний об'єкт (ІО) – це інформаційний опис деякого реального об'єкта, процесу, явища або події предметної області, який утворюється сукупністю логічно зв'язаних реквізитів, що представляють кількісні і якісні характеристики сутності, і який має лінійну структуру (рис.2.1).
Предметна область, яка ототожнюється із підсистемою інформаційної системи підприємства, може бути концептуально уявлена сукупністю документів, що забезпечують її функціонування. Тоді, на початковій стадії проектування БД ПО, можна обмежитися інформаційними обєктами ПО, які будуть виділені із документів ПО.
Рис.2.1. Структура ІО, як складової одиниці інформації.
С1 – складова одиниця інформації; Р1 – Рn – реквізити.
Структура багатьох документів є лінійною. Так лінійну структуру мають класифікатори й цінники. Але більшість інших документів ПО мають ієрархічну структуру. Наприклад, ієрархічну структуру має документ “Вимога на видачу запасних частин”. Для його опису необхідно застосовувати два ІО, а саме: ІО1, що описує загальну й заключну частину документа, та ІО2, що описує табличну частину документа. Тепер визначимо кількість примірників цих ІО, що замінюють один заповнений документ “Вимога”. ІО1 створюється в одному примірнику, а ІО2 буде мати стільки примірників, скільки рядків має таблиця документа Вимога (наприклад, 5 рядків).
Таким чином документи з ієрархічною структурою відображуються як відповідна сукупність лінійних структур, кожна з яких є окремим ІО.
Уведемо поняття первинного ключа ІО. Первинним к лючем ІО є один або декілька його реквізитів, які забезпечують ідентифікацію кожного екземпляра ІО. Так ключовими реквізитами ІО1 будуть реквізити: “Номер вимоги”, “Дата видачі”. Ключовими реквізитами ІО2 будуть всі ключові реквізити ІО1, до яких додано реквізит “Номер рядка”. Усі інші реквізити інформаційного об'єкта будуть описовими.
ІО прийнято відображувати у вигляді прямокутників. У прямокутнику вказується: назва ІО, його ідентифікатор, ідентифікатори первинного ключа і наближена кількість примірників (рис.2.2 а). Приклад відображення ІО1 приведений на рис.2.2 б.
Рис.2. Графічне зображення ІО (а) та ІО1 (б).
Інформаційні об'єкти можуть мати зв'язки (відношення). Реальні відношення між екземплярами пари ІО можуть бути: “одно- однозначні” (1:1), “одно- багатозначні” (1:М), “багато- багатозначні” (1:N). “Одно-однозначні” відношення мають місце, коли кожному екземпляру ІО1 відповідає тільки один екземпляр ІО2. Такі ІО при необхідності легко об'єднати в один ІО, структура якого утворюється шляхом з'єднання реквізитів обох ІО. Первинним ключем об'єднаного ІО може виступати любий з ключів складових ІО.
“Одно-багатозначні” відношення мають місце, коли кожному екземпляру ІО1 відповідає декілька екземплярів ІО2, а одному екземпляру ІО2 відповідає тільки один екземпляр ІО1. Це ієрархічний тип відношень між ІО. ІО1 визначається як головний, а ІО2 – як підлеглий.
Рис. 2.3. Графічне відображення відносин між ІО.
а) одно-однозначні; б) одно- багатозначні; в) багато-багатозначні
“Багато-багатозначні” відношення мають місце, коли кожному екземпляру ІО1 відповідає декілька екземплярів ІО2, і кожному екземпляру ІО2 відповідає декілька екземплярів ІО1. Графічне відображення можливих відносин між ІО показане на рис.2.3.
На рис 2.4. представлені ІО, що були створені на основі документа “Вимога”, разом із зв'язками між ними. Таке зображення всіх ІО ПО носить назву інформаційно-логічної моделі предметної області (ІЛМ ПО).
Рис.2.4. ІЛМ ПО “Технічна служба АТП” (фрагмент).
Література: [1] с.447-453, [2], [3], [6]
Тема 2.2. Методика проектування реляційної бази даних на прикладі предметної області “Управління технічною службою “.
Методика дозволяє на основі наукових засад здійснити перехід від інформаційної системи управління підприємством, заснованої на обробці інформації вручну, до автоматизованої інформаційної системи управління на основі інформаційної технології СУБД.
Методика використовує для опису даних предметної області інформаційні об'єкти й зв'язки між ними. Сукупність реквізитів стосовно інформаційного об'єкта повинна відповідати вимогам нормалізації: інформаційний об'єкт повинен включати унікальний ідентифікатор (ключ); ключ може бути простим, якщо він складається з одного ключового реквізиту, або складовим, якщо – із декількох; усі описові реквізити повинні бути взаємонезалежними; кожний описовий реквізит повинен функціонально залежати від ключа; кожний описовий реквізит не може залежати від ключа транзитивно, тобто через другий проміжний реквізит. Якщо існує транзитивна залежність між реквізитами, необхідно розділяти сукупність реквізитів з утворенням двох інформаційних об'єктів замість одного.
Виконання умов нормалізації забезпечує побудову реляційної бази без дублювання даних і надає можливість підтримки їх зв'язаної цілісності.
Правила виділення інформаційних об'єктів:
· на основі аналізу визначити документи предметної області, які слід зберігати у базі даних;
· визначити стосовно кожного документа функціональні залежності між реквізитами. Функціональну залежність реквізитів можна відобразити графічно у вигляді ліній зі стрілками, що йдуть від ключового реквізиту до описового;
· вибрати всі залежні реквізити і вказати для кожного всі його ключові реквізити;
· згрупувати реквізити, які залежні від однакових ключових реквізитів. Отримані групи залежних реквізитів разом із їх, ключовими реквізитами утворюють інформаційні об'єкти.
Сукупність виділених інформаційних об'єктів дозволяє отримати інформаційно-логічну модель реляційної бази даних ПО, яка відповідає вимогам нормалізації. Методика, що пропонується, являє собою послідовність робіт по створенню проекту реляційної бази даних ПО. Роботи поділяються на 3 етапи:
Етап 1. Виділення інформаційних об'єктів ПО.
1.1.Встановлення функціональної залежності реквізитів документів ПО.
1.2 Розподіл реквізитів документів на ключові і описові.
1.3 Визначення складу інформаційних об'єктів.
Етап 2. Побудова канонічної ІЛМ ПО.
2.1. Установлення структурних зв'язків між інформаційними об'єктами (ІО).
2.2. Побудова ІЛМ ПО в канонічній формі.
Етап 3. Створення проекту БД ПО МПТС.
3.1. Побудова логічної моделі реляційної БД ПО.
3.2. Створення макетів БД.
Метою етапу 1.1 є встановлення функціональної залежності реквізитів кожного документа. При цьому виділяються ключові реквізити, призначені для ідентифікації екземпляра документа. Усі інші реквізити будуть називатися описовими. Виконання етапу 1.1 відображується в таблиці 2.1
При створенні табл.2.1 у колонку 2 заносяться назви документів ПО. В колонці 3 послідовно наведені всі реквізити - ознаки кожного документа. В колонці 4 кожному реквізиту надається ідентифікатор. Він утворюється як сукупність символів, взятих із слів, що описують реквізит-ознаку. Перший символ слова пишеться з великої літери. В колонці 5 показана функціональна залежність реквізитів документа. Ключові реквізити, що ідентифікують або екземпляр документа або рядок таблиці, яку може містити документ, позначаються стрілками, що направлені праворуч. Описові реквізити позначаються стрілками, що направлені ліворуч. Зв'язок між реквізитами відображується у вигляді вертикальної лінії.
Метою етапу 1.2 є призначення кожному з описових реквізитів, що були визначені в таблиці 2.1, відповідних ключових реквізитів, що його ідентифікують у документі. Виконання етапу 1.2 відображується в табл.2.2.
При цьому кожний описовий реквізит аналізується на предмет його вилучення зі списку описових реквізитів, якщо відсутня потреба в його обробці в задачах управління.
Треба також вилучати описові реквізити, що мають реквізитів-дублерів. Такими реквізитами-дублерами є назви об'єктів та їхні коди. Вони вживаються разом тільки в інформаційних об'єктах, що є класифікаторами. В усіх інших документах залишаються тільки коди об'єктів.
В колонку 1 табл.2.2 заноситься назва документа. В колонці 2 перелічуються всі ідентифікатори описових реквізитів документів, що підлягають включенню в табл. 2.2 із урахуванням вищезгаданих правил відбору описових реквізитів. В колонку 3 стосовно кожного описового реквізиту заносяться його ключові реквізити. Слід пам'ятати, що до ключових реквізитів табличної частини документа додаються ключові реквізити, що ідентифікують сам документ. В колонці 4 вказуються важливіші ознаки ключових реквізитів. При заповненні колонки необхідно враховувати такі властивості ключових реквізитів як унікальність (у). простота (п), складність (с) і вторинність (в). Унікальним є ключ, значення якого не повторюються серед екземплярів ІО. Простим є ключ, що утворюється одним реквізитом. Складним є ключ, що утворюється двома або більше реквізитами. Вторинність ключа – це властивість, яка вказує, що ключ є підлеглим до головного. В колонці 5 приводиться ідентифікатор ІО, який містить описовий реквізит.
Метою етапу 1.3 є визначення складу інформаційних об'єктів, що були вказані в колонці 5 табл.2.2. Склад кожного ІО формується шляхом групування всіх описових реквізитів, які належать даному ІО. До складу ІО також додаються також і ключові реквізити, що ідентифікують даний ІО. Список реквізитів ІО повинен починатися з ключових реквізитів у порядку їх старшинності. Виконання етапу 1.3 відображується в табл.2.3.
Метою етапу 2.1 є формалізоване представлення предметної області у вигляді графічного зображення ІО і структурних зв'язків між ними (Рис.2.5), що зветься інформаційно-логічною моделлю предметної області (ІЛМ ПО).
Метою етапу 2.2 є побудова ІЛМ ПО у канонічній формі. Канонічна форма ІЛМ ПО застосовується для відображення ієрархічної підлеглості ІЛМ ПО. При цьому дозволяються зв'язки типів 1:1, 1:М. У кожній зв'язаній парі ІО головний ІО розміщується на більш високому рівні ніж підлеглий ІО. Для упорядкування розміщення ІО стосовно рівнів використовується їх розміщення з урахуванням індексів ІО. Індекс любого ІО можна визначити, якщо підрахувати кількість зв'язків, що мають місце у найбільшому по довжині шляху од верхнього рівня до даного ІО. На Рис.2.6 представлена ІЛМ ПО у канонічній формі.
Метою виконання етапу 3.1 є створення на основі ІЛМ ПО логічної моделі реляційної бази даних предметної області (Рис.2.7), яка відображує на папері схему зв'язків між ключовими реквізитами ІО і яка максимально наближена до діалогового вікна “Схема даних” СУБД Access. Слід відмітити, що взаємне розташування ІО на схемі повинно бути таким, щоб пересічення зв'язків було найменшим. Ключові реквізити на схемі відмічаються зірочками (*).
Метою етапу 3.2 є створення макетів об'єктів Access “Таблиця” для кожного з ІО, представлених у табл.2.3. Приклад створення макету стосовно ІО “КласМарка” приведено в табл.2.4. Для заповнення колонок 2, 3 таблиці використовуємо дані табл.1. В колонці 4 вказуємо тип даних реквізиту.
Можливі такі типи даних: символьний (текстовий), чисельний, дата, логічний, мемо, лічильник і OLE. Тип мемо застосовується для текстових даних невизначеної довжини. Тип OLE застосовується для даних графічного типу. Тип даних Лічильник застосовується для реквізитів, що відображують порядковий номер. В колонці 5 вказуємо максимальний розмір реквізиту у знаках (байтах). В колонці 6 для чисельних реквізитів указується кількість розрядів для десяткової частини. В колонці 7 вказуємо найменування реквізиту для відображення його у назві колонки таблиці, представленої у вигляді відеограми або табуляграми. Дані для колонок 8,9 вибираємо дані із таблиці 2. Якщо реквізит у таблиці 2 помічено як ключовий, то в колонку 8 заносимо так. Якщо в таблиці 2 реквізит помічено як простий ключовий, то в колонку 9 заносимо так. В усіх інших випадках у колонки 8,9 заносимо ні. В колонку 10 заносимо так, якщо реквізит обов'язково повинен мати значення. В колонку 11 заноситься маска вводу, яка застосовується при вводі реквізитів типу телефонний номер, номер паспорта та ін. В колонці 12 приводяться умови для перевірки правильності вводу реквізитів.
Реалізація методики буде провадитися на основі декількох документів ПО “Технічна служба АТП”, а саме: Класифікатор марок автомобілів, Класифікатор груп деталей автомобілів (Додаток 1, рис1.1, 1.14). Більш повний перелік документів ПО “Технічна служба АТП” представлений у Додатку 1, рис.1.1÷1.14.
Таблиця 2.1
Функціональна залежність реквізитів документів ПО.
№ пп | Назва документа | Найменування реквізита | Ідентифі- катор | Функціональ-на залежність реквізитів |
Класифікатор марок автомоб | Код марки автомобіля Назва марки автомоб. | КМарка НМарка | ||
Класифікатор груп деталей марок автомобілів | Код марки автомобіля Код групи деталей Назва групи деталей | КМарка КГруп НГруп |
Таблиця 2.2.
Відповідність ключових і описових реквізитів документів.
Назва документа | Ідентифікатор описового реквізиту | Ідентифікатори ключових реквізитів | Вид ключа | Ідентифікатор інформацій-ного об'єкту |
Класиф. марок авт | НМарка | КМарка | п,у | КласМарка |
Класиф. груп авт. | НГруп | КМарка+КГруп | с,у,в | КласГруп |
Таблиця 2.3.
Реквізитний склад ІО.
Ідентифікатор реквізиту | Ознаки ключа | Ідентифі- катор ІО | Назва ІО | Опис ІО |
КМарка_____ НМарка | П,У | КласМарка | Класифіка-тор марок автомобілів | Містить дані про назви марок автомобілів та їх коди |
КМарка КГруп______ НГруп | С,У,В | КласГруп | Класифіка-тор груп марок автомобілів | Містить дані про назви й коди груп (агрегатів і систем) та коди марок автомобілів |
Таблиця 2.4
Макет інформаційного об'єкта “КласМарка” (Класифікатор марок).
№ пп | Найменування реквізиту | Ідентифікатор | Тип даних | Розмір | Кільк. дес.зн. |
Код марка | КМарка | Текст | |||
Назва марки | НМарка | Текст |
продовження табл. 2.4.
Підпис | Зв'язок | Обов. поле | Маска вводу | Умова на значення | |
Ключове поле | Унікальне поле | ||||
Код марки | да | да | да | ||
Марка | ні | ні | да |
Література: [1] с.448-457, 505-518, [2] с.35-49, [3], [6]
Дата добавления: 2015-08-18; просмотров: 155 | Нарушение авторских прав
<== предыдущая страница | | | следующая страница ==> |
Тема 1.1. Економічні інформаційні системи підприємств (ЕІС ). | | | Тема 3.1 Зберігання інформації у базі даних |