Реферат на тему:

ГІС. Бази даних в економічних системах

ПЛАН

1. Структура інформаційного забезпечення.

2. Бази даних в природних ресурсних системах

1.Структура інформаційного забезпечення

Для органiзацiї iнформацiйної взаємодiї рiзноманiтних iнформацiйних
систем мiж собою, а також з рiзними групами користувачiв данi потрiбно
вiдповiдним чином однотипово описати в усiх системах на рiзних рiвнях,
тобто вирiшити проблему їх iнформацiйної сумiсностi в найширшому
розумiннi. Цього досягають створенням iнформацiйного забезпечення, пiд
яким розумiють сукупнiсть форм документiв, нормативної бази та
реалiзованих рiшень щодо обсягiв, розмiщення i форм iснування
iнформацiї, яка використовується в iнформацiйнiй системi при її
функцiонуваннi (ГОСТ 34.003-90.АС.Термины та означення).

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

Мал. 1. Структура iнформацiйного забезпечення

Системи класифiкацiї i кодування — це перелiк описiв i систем
супроводження класифiкаторiв технiко–економiчної iнформацiї на
економiчному об’єктi.

Основнi принципи створення iнформацiйного забезпечення: цiлiснiсть,
вiрогiднiсть, контроль, захист вiд несанкціонованого доступу , єднiсть i
гнучкiсть, стандартизацiя та унiфiкацiя, адаптивнiсть, мiнiмiзацiя
введення i виведення iнформацiї (однократнiсть введення iнформацiї,
принцип введення — виведення тiльки змiн).

Цілісність здатнiсть даних задовольняти принцип повного узгодження,
точнiсть, доступнiсть i достовiрне вiдображення реального стану об’єкта.

Існують два пiдходи до створення IБ: аналiз сутностей; синтез атрибутiв.

Аналiз сутностей спадний пiдхiд, або “згори — вниз” , який поділяє
процес створення на чотири стадії:

1)моделювання уявлень користувачів;

2)об’єднання уявлень;

3)складання i аналiз моделi (схеми);

4)реальне (фiзичне) проектування.

Синтез атрибутiв зростаючий пiдхiд, або “знизу — вгору”, оскільки вiн
починається iз синтезу атрибутiв найнижчого рiвня, з яких формуються
сутностi та зв’язки верхнього рiвня. Виділяють чотири стадiї для цього
пiдходу:

1)класифiкацiя атрибутiв;

2)композиція сутностей;

3)формування зв’язкiв;

4)графiчне уявлення.

Кожний з цих пiдходiв має свої переваги й недолiки i визначається
виходячи iз потреб проектування IC. Для створення великих IC, у яких є
структура, найбiльш прийнятний аналiз сутностей, для автономних
невеликих IC без структури — атрибутний (локальний).

Інформаційне забезпечення не можна успiшно спроектувати без загального
планування “згори — вниз” i детального проектування “знизу — вгору”.
Походження двох пiдходiв, в свою чергу, не можна досягти без відповідної
методики, загальні контури якої ми розглядаємо.

Вимоги до iнформацiйного забезпечення (ГОСТ 24.104-85 “Автоматизовані
системи управління. Загальні вимоги”) такi:

1.Iнформацiйне забезпечення має бути достатнiм для виконання всiх
функцiй IC, якi автоматизуються.

2.Для кодування iнформацiї, яка використовується тiльки в цiй IC, має
бути застосованi класифiкатори , якi є у замовника IC.

3.Для кодування в IC вихiдної iнформацiї, яка використовується на вищому
рiвнi, мають бути використанi класифiкатори цього рiвня, крiм спецiально
обумовлених випадкiв.

4.Iнформацiйне забезпечення IC має бути сумiщене з iнформаційним
забезпеченням систем, якi взаємодiють з нею, за змiстом, системою
кодування, методами адресацiї, форматами даних i формами подання
iнформацiї, яка отримується і видається інформаційною системою.

5.Форми документiв, якi створюються iнформацiйною системою, мають
вiдповiдати вимогам стандартiв УСД чи нормативно — технiчним документам
замовника IC.

6.Форми документiв i вiдеокадрiв, якi вводяться чи коригуються через
термінали IC, мають бути погодженнi з вiдповiдними технiчними
характеристиками термiналiв.

7.Сукупнiсть інформаційних масивiв IC має бути органiзована у виглядi
бази даних на машинних носiях.

8.Форми подання вихiдної iнформацiї IC мають бути узгодженi iз
замовником (користувачем) системи.

9.Термiни i скорочення, якi застосовуються у вихiдних повiдомленнях,
мають бути загальноприйнятими в цiй предметнiй областi й погодженi iз
замовником системи.

10.У IC мають бути передбаченi необхiднi заходи щодо контролю i
оновлення даних в iнформацiйних масивах IC, оновлення масивiв пiсля
вiдмови будь-яких технiчних засобiв IC, а також контролю iдентичностi
однойменної iнформацiї в базах даних.

Можуть створюватись також самостiйнi iнформацiйнi засоби i вироби для
конкретного користувача.

Інформаційний засiб — комплекс упорядкованої, вiдносно постiйної
iнформацiї на носiях даних, якi описують параметри та характеристики
заданої предметної областi застосування, i вiдповiдної документацiї,
призначеної для поставки користувачевi.

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

Ефективне функцiонування iнформацiйної системи об’єкта можливе лише при
вiдповiднiй органiзацiї iнформацiйної бази — сукупностi впорядкованої
iнформацiї, яка використовується при функцiонуваннi IC i подiляється на
зовнiшньо — i внутрiшньомашинну (машинну) бази (ГОСТ 34.003-90).

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

Внутрiшньомашинна iнформацiйна база — частина iнформацiйної бази, що
використовується в IC на носiях даних.

Така зовнiшньомашинна IБ має багато модифiкацiй вiд подання у виглядi
повiдомлень на паперовому носiї, запитiв на екранi дисплея, мовного
спiлкування з ЕОМ та ін.

Внутрiшньомашинна IБ пройшла три етапи еволюцiї.

Перший етап характеризується роз’єднаним фондом даних:

1)програми розв’язання кожної окремої задачі становили одне цiле з
масивами, якi оброблялися;

2)використання будь-якого масиву для iншої задачі забезпечувалось
iндивiдуально пристосуванням до форм подання даних, структур елементiв
масивiв i. т. ін. ;

3)опис даних не потрiбний, оскiльки структура ранiше була вiдома;

4)коригування масивiв виконувалось iндивідуальними засобами;

5)задача розв’язувалася в пакетному режимi, користувач отримував
результати винятково у виглядi машинограм i виробничих документiв через
групу пiдготовки i оформлення даних.

Данi розглядаємо на трьох рiвнях, i є пряма залежнiсть логiчного рiвня
програм, фiзичного та логiчного рiвня збереження.

Другий етап централiзований фонд даних.

1.Данi вiдокремленi вiд процедур їх обробки i органiзованi в бiблiотецi
масивiв загального користування. Подання iнформацiї, формати елементiв
даних i структура масивiв унiфiкованi i не залежать вiд конфiгурацiї
пам’ятi та органiзацiї .

2.Опис даних вiдокремлено як вiд програм, так i вiд самих даних, тому
данi i програми їх обробки стають значною мiрою незалежними. Це полегшує
змiну структур даних i програм. Але реорганiзацiя бiблiотеки i її
окремих груп компонентiв потребує змiни програми обробки.

Залишаються залежнi логiчнi рiвнi програми i збереження.

Третiй етап — організація баз даних характеризується:

1)об’єднанням не лише iнформацiї, а й апаратно програмних засобiв її
поповнення, коригування i видачi користувачевi;

2)повним вiдокремленням функцiй нагромадження, ведення і реорганізації
даних від функцій їх обробки. Дані коригуються поза рівнем програм
користувача за допомогою власного апарату бази даних;

3)появою логічного буферу, системи управління базою даних, розв’язки між
програмами користувача і базою даних;

4)можливістю оперативної реалізації довільних запитів у режимі
безпосереднього зв’язку з ЕОМ;

5)високим ступенем централізації загальносистемних масивів, яка
передбачає спільне використання загальних даних;

6)різноманітністю даних і поєднанням в довільні логічні структури;

7)наявністю потужного програмного забезпечення і мовних засобів.

Усі рівні незалежні.

Нині існують другий і третій етапи. Основною задачею є визначення
потрібної кількості баз даних і оптимального розподілу інформації між
ними з урахуванням того, що економічний об’єкт — це динамічна система,
яка перебуває в постійному розвитку. Використовуючи пріоритет виробничих
функцій, необхідно побудувати таку базу даних. Так , навколо поняття
“Модель виробу” формуються дві оболонки: внутрішня являє конструкторську
документацію, зовнішня — технологічну і управлінську інформацію (мал.
9).

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

Описуючи організацію інформаційної бази (РД 50-34, 698-90), потрібно
дати опис логічної і структурної бази даних.

Документ складається з двох частин:

1)опис внутрішньомашинної інформаційної бази;

2)опис зовнішньомашинної інформаційної бази.

Мал. 2.Структура бази даних “Модель виробу”

Кожна частина складається з таких розділів:

1)логічна структура;

2)фізична структура (для зовнішньомашинної інформаційної бази);

3)організація ведення інформаційної бази.

У розділі “Логічна структура” наводять опис складу даних, їх формати і
взаємозв’язки між даними.

У розділі “Фізична структура” наводять опис вибраного варіанта
розміщення даних на конкретних машинних носіях даних.

При описі структури внутрішньомашинної інформаційної бази наводять
перелік баз даних і масивів та логічні зв’язки між ними. Для масиву
інформації вказують логічну структуру масиву чи дають посилання на
документ “Опис масиву інформації”.

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

Якщо цю інформацію наведено у документах “Перелік вхідних сигналів і
даних” і “Перелік вихідних сигналів”, можна посилатися на ці документи.

У розділі “Організація ведення інформаційної бази”, описуючи
внутрішньомашинну базу, наводять послідовність процедур при створенні і
обслуговуванні бази із зазначенням в разі потреби реґламенту виконання
процедур і засобів захисту бази від руйнування і несанкціонованого
доступу, а також зв’язків між масивами баз даних і масивами вхідної
інформації.

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

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

1)повнота подання даних;

2)мінімальний склад даних;

3)мінімізація часу вибірки даних;

4)незалежність структури масивів від програмних засобів їх організації;

5)динамічність структури інформаційної бази.

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

Останнім часом склалися такі основні підходи до побудови
внутрішньомашинної інформаційної бази:

1)проектування масиву як відображання змісту окремого документа;

2)проектування масивів для окремих процесів управління;

3)проектування масивів для комплексів процесів управління, які
реалізуються;

4)проектування бази даних;

5)проектування кількох баз даних.

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

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

Поняття складу і змісту масивів передбачає визначення оптимальної
кількості масивів і переліку атрибутів (полів) , які у них містяться.

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

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

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

Вхідні масиви — це проміжна ланка між первинними інформаційними
повідомленнями і основними масивами. Зміст і розміщення даних у вхідному
масиві аналогічні змісту і розміщенню їх у первинному інформаційному
повідомленні.

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

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

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

Вихідні масиви формуються в процесі розв’язання задачі й
використовуються для модифікації основних масивів і виведення вихідних
(результатних) інформаційних повідомлень.

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

Взаємозв’язок користувача з базою даних зображено на мал.10.

База даних є сукупність даних, що використовується при функціонуванні
IC, організована за певними правилами, які передбачають загальні
принципи опису, зберігання і маніпулювання даними і незалежна від
прикладних програм (ГОСТ 24.003-84).

Система управління базами даних — це сукупність програм і мовних
засобів, які призначені для управління даними в базі даних і
забезпечують взаємодію її з прикладними програмами (ГОСТ 20886- 85).

Мал. 3. Взаємозв’язок користувача з базою даних

Масив даних — це конструкція даних, компоненти якої ідентичні за своїми
характеристиками і є значенням функції від фіксованої кількості
цілочисельних аргументів ( ГОСТ 20886- 85).

Файл — це ідентифікована сукупність примірників повністю описаного в
конкретній програмі типу даних, розміщених ззовні програми в зовнішній
пам’яті та доступних програмі, за допомогою спеціальних операцій (ГОСТ
20886- 85).

2. Бази даних в природних ресурсних системах

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

Електронною базою даних (БД) називається послідовність даних заданої
структури, записана на магнітний диск комп’ютера.

Системи управління базами даних (СУБД) є набором програмних засобів,
необхідних для створення, використання і підтримки баз даних.

База даних – це набір даних з наступними властивостями:

дані логічно пов’язані між собою і несуть відповідну інформацію;

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

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

Система управління даними першого покоління

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

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

Системи управління даними другого покоління

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

Системи управління даними третього покоління

Можливості СУБД розширились. Створені розвинуті інтерфейси, що
забезпечують інтерактивний доступ звичайним користувачам.

Переваги СУБД :

Скорочення надлишку даних;

Без баз даних неможливо уникнути зберігання надлишкових даних;

При наявності центрального контролю баз даних деякі надлишкові дані
можна усунути;

Надлишкові дані не можуть бути повністю усунені, оскільки велику роль в
СУБД відіграють питання часу і достовірності.

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

Найпоширенішими СУБД є Visual FoxPro та Microsoft Access.

СУБД VFP — це реляційна база даних. Кожна таблиця зберігається в
окремому файлі з розширенням dbf. Усі інші об’єкти — форми (form),
запити (query), звіти (report), програми (program), меню (menu),
уявлення (view) теж зберігаються в окремих файлах з відповідними типами.

Типи даних. Дані поділяються на змінні бази даних (поля), змінні пам’яті
(використовуються для проміжного зберігання даних) та масиви змінних
пам’яті. Ім’я змінної може мати довжину до 10 символів, містити літери
від А до Z, всі цифри та знак підкреслювання (—). У таблиці 1 перелічені
типи даних, які можуть

приймати змінні.

Таблиця 1

Тип даних Характеристика

Character Може містити всі символи клавіатури, максимальна довжина — 254

Currency Грошовий тип, може приймати значення від -900Е8 до +900Е8,
містить 4 дробові розряди

Float Може містити цифри, десяткову крапку. Максимальна довжина поля —
20 символів

Numeric Може містити цифри, десяткову крапку. Максимальна довжина поля —
20 символів (ціла частина + дробова частина + 1, якщо є десяткова
крапка)

Date Містить дату в такому вигляді: місяць/число/рік, наприклад,
10/31/01

Date Time Містить дату та час, наприклад, 10/31/01 11:59 РМ

Double Може містити числові дані, але обчислення виконуються з більшою
точністю, ніж з даними типу Numeric

Logical Логічний тип даних. Може приймати два значення Т (True) та F
(False)

Memo Дозволяє зберігати текст необмеженого розміру. Дані у цьому випадку
зберігаються в іншому файлі

General Може містити OLE-об’єкти, компоненти Windows, об’єкти,
що створені в інших додатках

Character (binary) Може містити будь-які 8-бітні значення та символ null
(0)

Memo (binary) Дозволяє зберігати відскановані зображення, оцифровану
музику тощо.

Система управління базами даних Microsoft Access входить до складу
пакета Microsoft Office. Вона дозволяє розв’язувати широке коло завдань
користувачів без програмування і доступна для широкого кола
непрофесійних користувачів персональних комп’ютерів.

Система управління базами даних (СУБД) Access розроблена для
експлуатації у комп’ютерних мережах у середовищі Windows.

Одна з основних переваг СУБД Ассеss полягає у тому, що вона має прості
та зручні засоби обробки кількох таблиць у одній базі даних. Таблиця є
основним об’єктом бази даних. У одній базі даних зберігається кілька
таблиць та засоби зв’язування таблиць.

У системі Acсess є різні способи управління даними, а саме:

система меню;

панелі інструментів;

контекстивне меню;

укажчик миші;

комбінації клавіш.

СУБД Access має значну кількість спеціальних програм – “майстрів”. Є
майстер таблиць, майстер кнопок, майстер форм та ін. Майстри здійснюють
діалог з користувачем, у процесі якого визначаються дані, необхідні для
розв’язування відповідної задачі. Для зручності роботи кожен майстер має
певні етапи (кроки). Будь-який етап можна пропустити або звернутись до
попередніх.

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

Етапи створення бази даних у середовищі Microsoft Access:

визначення мети створення бази даних;

визначення таблиць, які повинна містити база даних;

визначення структури таблиць (полів та їх типів);

призначення ключів таблиць та створення потрібних індексів;

визначення зв’язків між таблицями;

завантаження даних;

створення інших об’єктів бази даних: запитів, форм, звітів, макросів та
модулів;

аналіз ефективності бази даних за допомогою майстра таблиць (меню
СЕРВИС>АНАЛИЗ>ТАБЛИЦА) та аналізатора швидкодії (меню
СЕРВИС>АНАЛИЗ>БЬІСТРОДЕЙСТВИЕ).

Розглянемо призначення об’єктів Access.

Таблиця призначена для збереження даних у вигляді записів (рядків) і
полів (стовпців). Таблиці складають основу бази даних. Саме в них
зберігається інформація, організована певним чином.

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

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

Звіт — об’єкт, призначений для друку даних.

Макроси — засоби для автоматизації роботи з формами, звітами та ін.

Модулі — програмні модулі мовою Visual Basic.

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

Проектування бази даних

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

Пропонуємо майбутнім користувачам систем управління базами даних два
підходи, два варіанти проектування баз даних. Перший варіант широко
відомий, бо він запропонований фірмою Microsoft. Другий варіант
відображає практичний досвід проектування, і за основу взято варіант,
надрукований у «ComputerWorld — Moscow» за 1996 рік.

Варіант 1. Етапи проектування бази даних

Нижче наведені основні етапи проектування бази даних:

Визначення мети створення бази даних.

Визначення таблиць, що їх повинна містити база даних.

Визначення необхідних у таблиці полів.

Завдання індивідуального значення кожному полю.

Визначення зв’язків між таблицями.

Відновлення структури бази даних.

Додавання даних і створення запитів, форм, звітів та інших

об’єктів бази даних.

Використання засобів аналізу в СУБД.

Розглянемо ці етапи дещо детальніше.

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

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

Визначення таблиць, які повинні містити база даних.

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

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

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

3. Визначення необхідних у таблиці полів. Кожна таблиця містить
інформацію на окрему тему, а кожне поле в таблиці містить окремі дані по
темі таблиці. Наприклад, у таблиці з даними про клієнта можуть бути поля
з назвою компанії, адресою, містом, країною і номером телефону. Під час
розробки полів для кожної таблиці необхідно пам’ятати:

кожне поле має бути пов’язане з темою таблиці;

не рекомендується включати до таблиці дані, що є результатом виразу;

у таблиці має бути вся необхідна інформація;

інформацію варто розбивати на найменші логічні одиниці (наприклад, поля
«Ім’я» і «Прізвище», а не загальне поле «Ім’я»).

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

основним ключем.

5. Визначення зв’язків між таблицями. Після розподілу даних по таблицях
і визначення ключових полів необхідно вибрати схему для зв’язку даних у
різних таблицях. Для цього потрібно визначити зв’язки між таблицями.
Бажано вивчати зв’язки між таблицями в уже існуючій базі даних. Для
перегляду зв’язків у вибраній базі даних відкриваємо її і вибираємо
відповідні команди.

6. Відновлення структури бази даних.

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

7. Додавання даних і створення інших об’єктів бази даних. Якщо структури
таблиць відповідають поставленим вимогам, то можна вводити всі дані.
Потім можна створювати будь-які запити, форми, звіти, макроси та модулі.

8. Використання засобів аналізу в СУБД. Наприклад, у СУБД Microsoft
Access є два інструменти для вдосконалення структури баз даних. Майстер
аналізу таблиць досліджує таблицю, в разі потреби пропонує нову її
структуру та зв’язки, а також переробляє її. Аналізатор швидкодії
досліджує всю базу даних, дає рекомендації з її поліпшення, а також
реалізує їх.

Варіант 2. Розробка проекту бази даних

1. Розробка логічної моделі даних. Логічні моделі використовуються
розробниками баз даних для формального представлення інформаційних
потреб виробництва, економіки, бізнесу тощо. Найрозповсюдженішою формою
відображення цієї моделі слугують ER-діаграми. Основними поняттями
ER-моделі є сутність, зв’язок та атрибут. Кожна з частин такої діаграми
повідомляє дещо про структуру даних або про те, як ці дані
співвідносяться з іншими.

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

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

2. Підготовка звіту про логічну модель. Для відстежування процесу
проектування логічної моделі використовуються звіти.

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

Перетворення логічної моделі у фізичну. У процесі розробки фізичної
моделі сутності, атрибути та зв’язки складають фізичну модель,
відображаються у таблиці та стовпчиках. До раніш заданих властивостей
стовпчиків (типів даних, протяжностей і невизначених значень) додаються
нові — первинні та зовнішні ключі, індекси, перевірочні обмеження та
правила підтримки посилкової цілісності. Щоб правильно і добре виконати
цей етап проектування, засоби моделювання даних повинні працювати з
кількома популярними СУБД SQL-типу, графічно відображати фізичні
характеристики, дозволяти призначати та модифікувати триггери1 за
замовчування, створювати власні триггери, денормалізувати фізичну
модель, не торкаючись при цьому логічної.

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

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

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

Звернене проектування, що виходить з існуючої бази даних. Відтворення
схеми існуючої бази даних служить кільком цілям. Воно дає змогу
побудувати модель цієї бази даних, перенести існуючу базу даних з однієї
СУБД на іншу, а також досить просто модифікувати схему бази даних, що
функціонує. Ключо вими параметрами для виконання такого завдання є
точність та гнучкість. Ми повинні мати можливість задати елементи схеми,
з якими працюватиме програма, й очікується, що внаслідок генерації схеми
бази даних за відновленою моделлю має з’явитися тотожна копія початкової
схеми.

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

Використана література:

Вінер Н. “Бази даних”, М.: Наука, 1993

Інформаційні системи та технології в економіці Кельдер Т. Л..- ЗДУ ,
2002.

Стефанюк В.Л. “Інформаційні системи і їх застосування”. – К., 1999.

“Обчислювальна техніка і її застосування”. – Москва, 2000.

PAGE

PAGE 16

Зовнішньо-машинна ІБ

Внутрішньо-машинна ІБ

Інформаційні повідомлення

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

Нормативно-довідкові документи

Вхідні

Вихідні

Методичні інструктивні матеріали

Системи класифікації і кодування

Інформаційна база

Iнформацiйне забезпечення

МОДЕЛЬ ВИРОБУ

Технологічна документація

Креслення деталі

Технічна іллюстрація

Параметри виробу

Топологія конструкції

Тестування і контроль за допомогою ЕОМ

Виготовлення деталей

Аналіз діяльності об’єкта

Планування виробництва

Технологія обробки

Інструменти і оснаска

Дані для наступного аналізу

Управління розподіленої бази даних

Розробка технологічних процесів

субд

БД

супп

користувач

Похожие записи