Графічне представлення концептуальної моделі в третій нормальній формі

 

 

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

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

Ієрархічна модель даних будується за принципом ієрархії типів об'єктів, тобто один тип об'єкта є головним, а інші, що знаходяться на нижчих рівнях ієрархії, — підлеглими. Між головним і підлеглим об'єктами установлюється взаємозв'язок «один до багатьох». У той же час для кожного екземпляра головного об'єкта може бути кілька екземплярів підлеглих типів об'єктів. Взаємозв'язки між об'єктами нагадують взаємозв'язки в генеалогічному дереві за єдиним виключенням: для кожного народженого (підлеглого) типу об‘єкту може бути, тільки один вихідний. (головний) тип об’єкту.

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

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

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

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

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

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

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

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

 

 

Таблиця 3. Проект таблиці для фізичної моделі.

 

№ п/п	Найменування поля	Примітка
ТОВАР
1.	Key tovar	Унікальний ключ товару
2.	Key postav	Унікальний ключ постачальника
3.	Key zakaz	Унікальний ключ замовника
4.	Name tovar	Найменування товару
5.	Date	Дата виготовлення
6.	Матка	Акцизна марка
7.	Kod	Розшифровка штрих-коду
8.	Srok god	Термін придатності
9.	Ves Ь	Вага Брутто
10.	Ves n	Вага Нетто
11.	Cena 1	Ціна за одиницю
12.	Cena	Сумарна ціна
13.	Upakovka	Вид упакування
ЗАМОВНИК
1.	Key zakaz	Унікальний ключ замовника
2.	Name zakaz	Найменування замовника
3.	Yrid zakaz	Юридична приналежність
4.	FIO zakaz	ПІБ керівника
5.	Adres zakaz	Адреса
6.	Tel zakaz	Телефон/факс
7.	Cena z	Передбачувана ціна
8.	Number N	Номер накладної
9.	Oplata	Позначка про оплату
10.	Date N	Дата накладної
ПОСТАЧАЛЬНИК
1.	Key jioctav	Унікальний ключ постачальника
2.	Name postav	Найменування постачальника
3.	Yrid poctav	Юридична приналежність
4.	FIO postav	ПІБ керівника
5.	Adres postav	Адреса
6.	Tel_postav	Телефон/факс
7.	Number D	Номер договору
8	Date Z	Дата заключення
РАХУНОК
1.	Number S	Номер рахунка
2.	Date P	Дата продажу
3.	Key tovar	Унікальний ключ товару
4.	NDS	ПДВ
5.	Summa	Сума до оплати

 

Приклади форм для ІС “Оптова база”

 

Форма «ЗАМОВНИК»

Форма «ПОСТАЧАЛЬНИК»

 

Форма «ТОВАР»

 

 

Тітульна сторінка звіту

 

⇐ Предыдущая1234

Поделиться: