Концептуальна модель бази данних

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

При цьому виявляється обмеженість реляційної моделі даних в таких аспектах:

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

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

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

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

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

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

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

2.2. Технічний проект

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

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

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

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

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

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

2.2.1 Вибір середовища та засобів розробки

Для розробки комп'ютерних засобів навчання використовуються різні програми, які зазвичай називаються інструментальними середовищами (ІС).

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

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

Найчастіше використовуються наступні стратегії вибору:

Використовувати ІС, наявну в навчальному закладі та рекомендованої до застосування навчальним управлінням - користуватися не тим що треба, а тим, що є;

Підібрати «піратську» версію відповідного продукту - шлях незаконний і багате неприємними наслідками;

Провести аналіз ринку і придбати легальну версію слушною і перевіреної ІС;

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

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

Наведемо, напевно, не повний, список факторів, що впливають на вибір інструментального середовища (ІС).

Цільове призначення КСВ:

інформаційні (електронні конспекти лекцій, довідники та ін.);

для практичних занять (задачники, практикуми та ін.);

комп'ютерні моделі (тренажери, лабораторні роботи, ділові ігри та ін.);

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

навчальні (включають всі необхідні попередні).

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

Подання навчальної інформації:

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

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

Організація контролю засвоєння ЗУН

Введення і аналіз відповідей;

Організація сценарію контролю ЗУН;

Прийняття рішення за результатами контролю за одне питання і контрольну серію.

Управління вченням

Управління зв'язками між компонентами КСВ;

Управління вирішенням завдань - надання допомоги, діагностика та корекція помилок і т.п.;

Генерація послідовності пред'явлення тестів;

Управління тактикою і стратегією вчення.

Збір та обробка статистики про хід навчання.

Інструментарій розробника:

Наявність коштів візуального проектування і редагування;

Інтерфейс розробника - Панелі інструментів, редагування методом Drag and Drop, довідкова система, контекстна довідка, робота з шаблонами, майстра створення складних елементів, друк слайдів і структури;

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

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

Наявність засобів формування дистрибутива продукту і створення програми його установки.

Засоби програвання:

За допомогою стандартних програм входять до складу операційної системи (ОС) або в комплект поставки ОС, наприклад MS Internet Explorer;

За допомогою спеціалізованих програм - програвачів;

настройка готового курсу викладачем в залежності від мети конкретного заняття.

Засоби доставки змісту КСВ обучающемуся:

Автономні;

Мережеві, які в свою чергу можна розділити на:

Для використання в локальних мережах;

Для використання в глобальних мережах.

Інтегровані, в яких різні компоненти (модулі) можуть бути доступні в глобальних або локальних мережах.

Програмно-технічні фактори:

Підтримувані обчислювальні платформи. Вимоги до мінімальної конфігурації обчислювальної системи.

Забезпечувані способи захисту продукту і його компонентів від несанкціонованого копіювання та використання.

Економічні чинники:

Вартість і термін дії ліцензії;

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

Умови супроводу (період безкоштовного супроводу, вартість консультацій, забезпечення технічної підтримки по телефону і Internet і т.д.);

Умови надання оновлених і нових версій.

Спеціальні вимоги до програмних систем контролю ЗУН:

Відповідність засобів введення та аналізу відповідей заявленому (необхідному) рівню засвоєння ЗУН.

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

Функціонально-валідний інтерфейс.

Відповідність виду контролю ЗУН (тест, контрольна робота, діагностика і т.п.)

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

2.2.2. Розробка архітектури веб-додатку

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

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

Розглянемо окремо завдання побудови ієрархічної структури робіт. Кожне web-додаток можна представити в наступному вигляді:

Рисунок 2.2.2 Ієрархічна структура роботи

Іншими словами, кожне web-додаток відправляє http запити на web-сервер для отримання корисних даних. Програма під управлінням web-сервера використовує ту чи іншу модель для зберігання даних. У сучасному світі найчастіше використовуються бази даних, SQL або NoSQL.

Формально кожне web-додаток можна розбити на 3 взаємно незалежні частини.

1. Модуль, який виконується WEB-браузером. Ця програма може бути написано на будь-якій мові, який підтримує браузер. Найчастіше використовується мова JavaScript, як найбільш підтримуваний і має велику бібліотечну підтримку. Це дуже важливо, оскільки дозволяє істотно економити бюджети проектів.

2. Модуль, що виконується на серверній стороні під управлінням web-сервера. Ця програма може бути написано на будь-якій мові, інтерпретацію якого підтримує вибраний Вами web-сервер. Останнім часом, часто, в якості мови програмування вибирається мова Java. Ця мова також має серйозну бібліотечну підтримку.

3. База даних. У цій області так само існує досить широкий вибір. Є промислові бази даних, такі як Oracle, DB2, PostgreSQL. Є легкі бази даних, такі як MySQL. База даних вибирається грунтуючись на цілях та області вирішуваних завдань.

Можливі еталонні моделі розробки web-додатків.

При розробці архітектури web — додатка необхідно максимально зменшити залежність між структурними одиницями. У загальному випадку програма складається з трьох структурних одиниць, зображена на рис.2.2.2.1.

Рисунок. 2.2.2.1. діаграма моделі розробки web-додатків.

1. Модуль, який працює під управлінням браузера.

2. Модуль, який працює під управлінням web-сервера.

3. База даних.

Ці структурні одиниці породжують два види зв'язків.
1. Зв'язок між браузером і серверною частиною.

2. Зв'язок між серверною частиною і базою даних.

Для досягнення мети максимальної незалежності між структурними одиницями, необхідно щоб кожна структурна одиниця оперувала тільки необхідним їй набором даних. Розглянемо більш докладно.
Браузер — це прикладне програмне забезпечення для перегляду веб сторінок.
HTML — це стандартна мова розмітки документів. Більшість сучасних web-браузерів здатні інтерпретувати HTML.
Web-сервер — це програмне забезпечення, яке здатне приймати HTTP запити від клієнтів, обробляти їх і відправляти відповідь у відповідності зі стандартом протоколу.
База даних — це представлена в об'єктивній формі сукупність самостійних матеріалів, систематизованих таким чином, щоб ці матеріали могли бути знайдені і оброблені за допомогою ЕОМ.(Wiki)

Мінімізація залежностей

Для мінімізації залежностей між «Оглядача» і Web-сервером необхідно, щоб мова розмітки HTML був задіяний тільки в браузері, а Web-сервер надавав інтерфейс для отримання необхідних даних для сторінки.
Для вирішення цієї задачі необхідно:
Визначити цілі і область вирішуваних завдань, які будуть вирішуватися в рамках створюваного інтерфейсу.

Визначити API серверної частини.

Вибрати протокол взаємодії між серверною і клієнтською частиною.

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

Написати документ, в якому буде викладено протокол.

Наша діаграма може бути перетворена в наступний вигляд:

Рисунок 2.2.2.2. діаграма моделі розробки web-додатків.

Далі «Браузер» перетвориться в UML діаграми станів. На цих діаграмах буде відображено, в якому випадку викликається той чи інший метод.

Дана модель досяжна двома шляхами:

Виконувана Програма «Оглядача» написана на JavaScript і спілкується з Web-Сервером через AJAX, отримуючи відповіді у відповідність з визначеним протоколом.

Браузер інтерпретує тільки HTML код, а перетворення відбуваються за допомогою XSLT-перетворень на стороні Web-Сервера.

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

Взаємодія Web-Сервера і Бази даних

Взаємодія бази даних і web-сервера можливо організувати на основі двох принципово різних сценаріях:
Бізнес логіка знаходиться в базі даних.

Бізнес логіка знаходиться в коді web-сервера.

У першому випадку база даних зберігає дані і надає інтерфейс доступу до даних:
Вибірка даних — вирішується через подання.

Модифікація даних — вирішується через збережені процедури.

Програма для web-сервера є драйвером для доступу до бізнес-логікою. Тобто вона просто пов'язує Браузер з бізнес логікою, яка реалізована в базі даних.

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

Ієрархічна структура робіт
На підставі викладеного вище матеріалу ієрархічна структура робіт прийме наступний вигляд:

1. Модуль для «Оглядача».

2. Модуль для Web-Сервера.

3. Модуль для Бази даних.

4. Протокол обміну між модулем «Браузера» і Web-Сервером.

5. Інтерфейс взаємодії між модулем «Браузера» і Web-Сервером.

6. Інтерфейс взаємодії між Web-Сервером і Базою даних.

2.2.3. Специфікація модулів веб-додатків

При розробці додатків з модульною структурою на JavaScript виникає дві проблеми:

Опис і задоволення залежностей різних частин додатки, необхідність організації підключення залежностей на серверній стороні;

Експорт змінних в глобальну область видимості і їх колізія.

Обидві ці завдання вирішуються при використанні підходу Asynchronous Module Definition. Він зводиться до опису модулів функцією define та підключення їх за допомогою require. На даний момент є кілька інструментів, що реалізують AMD. Я почав своє знайомство з ними з RequireJS і був здивований, наскільки зручно і просто можна описувати залежності модулів. Розповім, як це працює, на простому прикладі.

Підключення завантажувача

Маємо наступну структуру каталогів:

siteroot/

js/

app.js

require.js

jquery.js

mymodule.js

index.html

Для початку, підключимо в index.html завантажувач. Будемо використовувати RequireJS:

<script data-main="/js/app" src="/js/require.js"></script>

Відмінно, це єдиний тег script, який нам потрібен. Іншу роботу з підключення JS зробить завантажувач. Зазначений в data-атрибуті файл (розширення js для стислості в RequireJS завжди опускається) буде своєрідною точкою входу нашого застосування. У ньому ми зможемо підключити необхідні модулі за допомогою require і здійснити задумані дії.

Опис модуля

Опишемо наш модуль в /js/module.js за допомогою define:

define(

'mymodule',

['jquery'],

function($){

return {

foo: 'bar'

};

}

);

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

Використання

У /js/app.js підключимо потрібні модулі за допомогою JS і виконаємо свій код:

require(

['mymodule', 'jquery'],

function(Module, $){

$('body').append(Module.foo);

}

);

Module при цьому не буде доступна в глобальній області видимості, як і інші змінні, що експортуються бібліотеками з залежностей. Не дивлячись на те, що бібліотека jQuery з версії 1.7 підтримує AMD-архітектуру, вона є винятком: експортує свій долар в глобальну область видимості. Швидше за все, це зроблено для збереження сумісності з армією плагінів, написаних за багато років.

Конфігурація

RequireJS володіє рядом параметрів, які можна передавати перед використанням. Для цього служить об'єкт require.config.

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

require.config =

{ shim: {

'oldmodule': {

deps: [],

exports: 'OldModule'

}

}

};

Тепер можна вказувати його в якості залежності:

require(

['mymodule', 'jquery', 'oldmodule'],

function(){}

);

Крім shim є ще багато параметрів: коренева директорія підключення файлів baseUrl, псевдоніми для більш зручного підключення paths.

Дата добавления: 2015-07-11