Инфологическая модель бази даних Захист доступу

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати

ЗМІСТ
  Введення. 2
1. Системний аналіз предметної області. 4
1.1. Коротка характеристика предметної області. 4
1.2. Опис предметної області. 13
2. Інфологічне моделювання. 18
2.1.Модель «сутність-зв'язок». 18
2.2. Зв'язки між сутностями инфологической моделі. 20
Висновок. 23
Список літератури .. 24

Введення

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

1. Системний аналіз предметної області

1.1. Коротка характеристика предметної області

У залежності про розміщення типових компонентів додатка по вузлах мережі інформаційні системи і відповідні додатки можуть будуватися різними способами, такими як системи на основі локальної мережі персональних комп'ютерів (файл-серверні додатки), системи з архітектурою клієнт-сервер та ін
Суть моделі файлового сервера полягає в тому, що один з комп'ютерів в мережі вважається файловим сервером і надає послуги з обробки файлів інших комп'ютерів. Файл-сервер працює під управлінням мережевої операційної системи і відіграє роль компонента доступу до інформаційних ресурсів. На інших комп'ютерах в мережі функціонує додаток, в якому функції подання інформації та логіка прикладної обробки суміщені. Звернення за сервісом управління даними відбувається через середовище передачі за допомогою операторів мови SQL або викликом функцій бібліотеки API (Application Programming Interface - інтерфейс прикладного програмування). Основна перевага такої моделі полягає у великому достатку готових СУБД, що мають SQL-інтерфейси, та існуючих інструментальних сердством, що забезпечують швидке створення програм клієнтської частини. Засоби розробки найчастіше підтримують графічний інтерфейс користувача в MS Windows, стандарт інтерфейсу ODBC і засоби автоматичної генерації коду.
Недоліки моделі файл-сервер:
* високий мережевий трафік (внаслідок того, що вся логіка зосереджена в додатку, а оброблювані дані розташовані на віддаленому вузлі;
* під час роботи додатків зазвичай по мережі передаються цілі БД);
* вузький спектр операцій маніпуляції з даними;
* відсутність надійних засобів безпеки доступу до даних (захист тільки на рівні файлової системи).
Тому переважно застосовувати технологію клієнт-сервер, коли сервер бази даних використовується не тільки для зберігання інформації, але і для обробки запитів до бази даних. Запити робочої станції обробляються сервером бази даних і назад повертається тільки результат виконання запиту. Такий підхід зменшує потік даних у мережі. Крім того, обробка запитів сервером бази даних здійснюється швидше, ніж на робочій станції, так як:
* в якості сервера бази даних використовується набагато більш потужний комп'ютер
* СУБД, що використовується в якості сервера бази даних, володіє більш досконалими засобами обробки даних
Так як обробка запитів здійснюється на сервері бази даних, а не на робочій станції, робоча станція називається клієнтом сервера бази даних. При роботі в режимі клієнт-сервер серверна частина системи управління базами даних встановлюється на файл-сервері, а клієнтська частина - на робочій станції. У ряді випадків клієнтська і серверна частини є окремими компонентами однієї СУБД (наприклад, Oracle або SQLbase). В інших випадках в якості клієнтської частини використовуються настільні СУБД або спеціальні системи розробки додатків клієнт / сервер (наприклад, PowerBuilder або SQLWindows), а в якості сервера бази даних - потужна СУБД типу Oracle або SQL Server.
Основне завдання, яка повинна бути надійно вирішена при розробці багатокористувацького додатки - це управління можливими зіткненнями користувачів при одночасній модифікації одних і тих же даних. Ця проблема повинна бути вирішена на двох рівнях:
перший - це зведення кількості таких конфліктів до мінімуму і
другий - розробка чіткого алгоритму їх дозволу.

Таблиця 1
Низька конкуренція (випадок 1)
Висока конкуренція (випадок 2)
Блокування запису
Запис даних в змінні
Читання записи
Читання змінних
Повноекранне редагування
Запит на збереження даних
Збереження даних
Блокування запису
-
Запис даних із змінних в БД
Зняття блокування з запису
У таблиці 1 наведено два можливих алгоритму модифікації даних в багатокористувацьких системах з низьким і високим рівнями конкуренції користувачів при спробі доступу до одних і тих же даних. У першому випадку ми отримуємо поза сумнівом, більш стабільну систему за рахунок захоплення потрібного запису і тим самим повного усунення можливості одночасної модифікації одних і тих же даних. У той же час захоплені дані можуть залишатися недоступними довгий час у випадку, якщо користувач раптом помітив якусь помилку і надовго застряг в пошуках шляхів її виправлення або просто вирішив відпочити в момент подноекранного редагування. Для уникнення подібних ситуацій можна поставити обмеження на час редагування, але тоді ці можуть раптом ізчезнуть з екрану прямо на очах здивованого зазівався користувача.
При другому варіанті продожітельность блокування не залежить від поведінки користувача. Цей час буде визначатися тільки тривалістю запису даних. Під час редагування дані продовжують залишатися доступними для інших користувачів. Чи добре це? Дуже добре, ми досягли приголомшливою гнучкості! Але в той же час отримали масу турбот, тому що під час редагування даних одним користувачем їх може змінити і інший. При такому підході є ризик, що після того, як перший користувач успішно модифікує запис, її тут же освіжить і другий працівник, який в очі не бачив оновлених перший абонентом мережі даних. Адже у нього на екрані були дані з БД до їх зміни першим користувачем.
Для вирішення цих проблем в СУБД пропонується використовувати буферизацію даних. Розглянемо типовий набір блокувань:
* відсутність буферизації.
* песимістична буферизація запису;
* оптимістична буферизація запису;
* песимістична буферизація таблиці;
* оптимістична буферизація таблиці.
Буферизація на рівні запису означає, що перед початком редагування вміст поточного запису буде збережено у внутрішньому буфері СУБД. Буферизація нв рівні таблиці зберігає в буфері зміст усіх відібраних для редагування записів. Оптимістична буферизація забезпечує блокування записів тільки на час збереження вмісту буфера у файлі, що відповідає наведеним вище нагоди 2. Песимістична буферизація працює як у випадку 1, тобто блокує запис перед копіюванням її вмісту в буфер.
Використання буферизації дозволяє автоматизувати процес переносу даних з полів БД в змінні і назад. При цьому група функцій дозволяє отримати вичерпну інформацію про стан буферизованная таблиці, що дає можливість організувати дуже ефективний алгоритм вирішення можливих конфліктів при зміні даних (схема їх взаємодії наведена на малюнку 1).

ТАБЛИЦЯ
Редагування
Оновлення даних
Скасування змін
OLDVAL ()
CURVAL ()
TABLEUPDATE ()
TABLEREVERT ()

Рис.1 Функції для роботи з буферизованная таблицею
OLDVAL () - повертає первісне значення поля, яке було модифіковано, але не оновлювалося.
CURVAL () - повертає значення поля безпосередньо з диска або з удаженного джерела.
TABLEUPDATE () - фіксує зміни, внесені до буферизованная запис або у буферизованная таблицю або курсор.
TABLEREVERT () - скидає зміни, внесені до буферизованная запис або у буферизованная таблицю або курсор і відновлює вміст за даними OLDVAL ().
При буферизації таблиці ми маємо можливість додавати і видаляти записи в буфері. При додаванні нова запис поміщається в кінець буфера і отримує номер з від'ємним значенням. Доступ до цього запису може бути виконаний за допомогою функції RECNO () з негативним параметром, наприклад -1.
RECNO () - повертає номер поточного запису в поточній або заданої таблиці
При написанні багатокористувацьких додатків необхідно враховувати, що цілий ряд команд при їх використанні виконує автоматичне блокування.
Якщо ви вирішили керувати блокуванням вручну, то дотримуйтеся наступного алгоритму:
* перевірте стан блокування запису або таблиці;
* якщо блокування немає, то необхідні ресурси можна заблокувати;
* якщо ресурси блоковані, спробуйте ще раз, але при цьому слід уникати надто частих спроб. Крім надмірної завантаження мережі це ні до чого не приведе.
При розробці алгоритму блокування намагайтеся дотримуватися чіткої послідовності подій. Наприклад, в наступному прикладі при боротьбі за декілька ресурсів буде спостерігатися патова ситуація (глухий кут):
Користувач 1
Користувач 2
Спроба блокувати запис 1
Спроба блокувати запис 4
Спроба блокувати запис 4
Спроба блокувати запис 1
Якщо спроба невдала, ждлем звільнення ресурсів
Якщо спроба невдала, ждлем звільнення ресурсів
Чекаємо, чекаємо, чекаємо ...
Чекаємо, чекаємо, чекаємо ...
Існують два прості правила, які допомагають уникнути даної ситуації. По-перше, необхідно виконувати всі дії в однаковій послідовності, тобто 2-й користувач повинен намагатися блокувати запису, також починаючи з першої. По-друге, завжди необхідно ставити обмеження по часу на спроби блокування, щоб дати можливість хоча б одному користувачу закінчити роботу.
Ряд команд і функцій автоматично забезпечують зняття блокування:
* Закриття таблиці
* Завершення транзакції
* Завершення сеансу роботи з СУБД
* Фіксація змін, внесених до буферизованная запис або таблицю
Якщо ви хочете забезпечити захист змінюваних даних і можливість відновлення початкових значень протягом певного періоду іспольненія програми, використовуйте механізм вбудованих транзакцій. При використанні транзакцій з моменту видачі команди «Почати транзакцію» всі зміни спочатку зберігаються в пам'яті комп'ютера або на диску і тільки при завершенні транзакції переносяться в таблицю. При цьому таблиця обов'язково повинна бути включена в базу даних. Якщо в процесі роботи з'ясувалася недоцільність використання зроблених змін, до виконання команди «Завершити транзакцію» завжди залишається можливість повернутися до початкового стану таблиці, видавши команду «Скасувати зміни, внесені в ході поточної транзакції». Для організації логічних груп з оновлення даних можна використовувати вкладені транзакції.
У загальному випадку при використанні транзакцій кращою є буферизація запису в порівнянні з буферизацією таблиці.
Використання транзакцій не може гарантувати збереження змінених даних, наприклад, при вимиканні комп'ютера. У цьому випадку автоматично виконається відкат до стану таблиці до початку транзакції.
Інтерфейс прикладного програмування ODBC API надає загальні методи доступу SQL як до реляційних, так і до нереляційні (ISAM) джерел даних.
У ANSI SQL входить інтерфейс на рівні викликів (CLI - call-level interface), який використовується ODBC для забезпечення доступу і роботи з даними в багатьох системах управління базами даних. Інтерфейс CLI відповідає вимогам, встановленим у 1991 році групою SQL Access Group, які визначають загальний синтаксис SQL і API. Мати загальний метод доступу до джерел даних зручно тому, що тоді база даних на сервері стає прозорою для додатків, які написані у відповідності з деяким заданим рівнем сумісності ODBC.
Інтерфейс ODBC API реалізований як набір розшарованих DLL-функцій для Windows. Динамічна бібліотека ODBC.DLL - це основна бібліотека управління драйверами ODBC, яка викликає спеціалізовані драйвери для різних підтримуваних системою баз даних. Кожен драйвер сумісний зі своїм рівнем CLI і відноситься до однієї з двох категорій: однорівневі або багаторівневі драйвери.
Однорівневі драйвери призначені для використання при роботі з тими джерелами даних, які не можуть бути оброблені ANSI SQL. Зазвичай це локальні бази даних на персональних комп'ютерах, такі як dBase, Paradox, FoxPro і ін Драйвери, відповідні цих баз даних, переводять граматику ANSI SQL в інструкції низького рівня, які безпосередньо обробляють складові базу даних файли.
Багаторівневі драйвери використовують сервер СУРБД для обробки SQL-пропозицій і призначені для роботи в середовищі клієнт-сервер. Крім обробки ANSI SQL, вони також можуть підтримувати і власну граматику конкретної СУРБД, оскільки ODBC може без трансляції передавати SQL-пропозиції джерел даних (механізм "passthrough").
Драйвери ODBC для баз даних типу клієнт-сервер реалізовані для Oracle, Informix, Microsoft і Sybase SQL Server, Rdb, DB2, Ingres, HP / Image і Any SQL.
Існує 4 важливі етапи (кроки) процедури запиту даних через API.
Крок 1 - встановлення з'єднання. Перший крок полягає в розміщенні покажчиків (handle) середовища ODBC, які виділяють оперативну пам'ять під ODBC драйвери та бібліотеки. Потім відбувається виділення пам'яті для покажчиків з'єднання, і з'єднання встановлюється.
Крок 2 - виконання пропозиції SQL. Виділяється покажчик пропозиції, локальні змінні зв'язуються зі стовпцями в SQL-вираженні (це необязате ~ ьное дію), і вираз представляється на розбір головному ODBC драйверу для обробки.
Крок 3 - вилучення даних. Перед витяганням даних повертається інформація про результуючому наборі, така як число стовпців в наборі. Виходячи з цього числа, результуючий набір поміщається в буфер записів, виконується цикл по ньому і витягується по одному стовпцю в локальні змінні. Цей крок необов'язковий, якщо використовується зв'язування стовпців.
Крок 4 - звільнення ресурсів. Після того, як дані отримані, звільняються ресурси викликом функцій звільнення покажчиків пропозиції, з'єднання і середовища. Покажчики пропозиції і з'єднання можуть бути використані в процесі обробки.
Технологія ODBC розроблялася як загальний, незалежний від джерел даних, спосіб доступу до даних. Також її застосування повинно було забезпечити переносимість додатків на різні бази даних без переробки самих додатків. У цьому сенсі технологія ODBC вже стала промисловим стандартом, її підтримують практично всі виробники СУБД і засобів розробки.
Проте універсальність коштує дорого. Якщо при розробці додатків одним з основних критеріїв є переносимість на різні СУБД, то використання ODBC є виправданим. Для збільшення продуктивності і ефективності програми активно застосовують специфічні для даної СУБД розширення мови SQL, використовують збережені на сервері процедури і функції. У цьому випадку втрачається роль ODBC як загального методу доступу до даних. Тим більше, що для різних СУБД драйвери ODBC підтримують різні рівні сумісності. Тому багато виробників засобів розробки крім підтримки ODBC постачають "прямі" драйвери до основних СУБД.

1.2. Опис предметної області
В управлінській, економічної, фінансової, правової сферах широко використовується інформація, що представляє собою неструктуровану інформацію (крім структурованої інформації, організованої в БД, що знаходяться під управлінням СУБД). Інформаційні ресурси представляють собою окремі документи і окремі масиви документів в інформаційних системах (бібліотеках, архівах, фондах, банках даних, інших видах інформаційних систем). До них відносяться рукописні, друковані та електронні видання, що містять нормативну, розпорядчу, фактографічну, довідкову, аналітичну та ін інформацію з різних напрямків суспільної діяльності (законодавство, політика, демографія, соціальна сфера, наука, техніка, технологія і т.д.) .
Для однокористувацьких АС характерне використання наступних баз даних:
локальні реляційні бази даних, що знаходяться під управлінням однієї або кількох СУБД (Microsoft Access, FoxPro і т.п.) і призначені для вирішення користувачем прикладних задач з використанням власного або покупного спеціального програмного забезпечення на його Армі;
локальні бази неструктурованої інформації (текстових і табличних документів, створених користувачем засобами Microsoft Word і Microsoft Excel, отриманих по електронній пошті, на машинних носіях, а також документів, отриманих у результаті рішення користувачем прикладних задач з використанням інформації реляційних баз даних), організовані і зберігаються у вигляді каталогів і підкаталогів на його Армі;
бази даних, розміщені на віддалених ПК у федеральних і міжнародних мережах, до яких організовано доступ самим користувачем зі свого АРМ (якщо АРМ підключений до федеральних і міжнародних мереж передачі даних).
Сучасні автоматизовані інформаційні системи являють собою, як правило, ЛВС, підключені до федеральних і міжнародних мереж передачі даних. Користувач ЛВС використовує не тільки перераховані вище локальні бази даних, а й розподілені:
реляційні бази даних на сервері ЛВС, що знаходяться під управлінням однієї або кількох СУБД;
бази неструктурованої інформації (документів, створених і отриманих різними користувачами ЛВС), організовані і зберігаються у вигляді каталогів і підкаталогів на сервері ЛВС;
бази даних різних придбаних АС, встановлені в ЛВС і доступні всім користувачам мережі;
бази даних, розміщені на віддалених ПК у федеральних і міжнародних мережах, до яких організовано доступ для всіх користувачів ЛОМ.
Значна частина неструктурованої інформації у вищеназваних базах є, як правило, гіпертекстовими і гіпермедіа-документами, об'єднаними за допомогою гіперпосилань у гіпертекстові бази даних.
В останні роки знаходять все більш широке застосування так звані геоінформаційні системи. Геоінформаційні системи (ГІС)-це інтегровані в єдиному інформаційному середовищі електронні просторово-орієнтовані зображення (карти, схеми, плани тощо) і бази даних (БД). В якості БД можуть використовуватися таблиці, паспорти, ілюстрації, розкладу і т. п. Така інтеграція значно розширює можливості системи і дозволяє спростити аналітичні роботи з координатно-прив'язаної інформацією. Принциповою відмінністю ГІС є наявність у них картографічних даних місцевості, регіону і т.д., до яких прив'язується інша інформація системи. Геоінформаційні системи вже широко використовуються в управлінні містобудуванням, транспортом, природними ресурсами і т.п.
Для сучасного етапу розвитку інформаційних технологій характерна наявність різноманітних інструментальних засобів і покупного спеціального програмного забезпечення, якими може оволодіти будь-який користувач, а також наявність великої кількості промислово функціонуючих БД комерційних організацій, органів державної влади та місцевого самоврядування, підприємств і організацій.
Така ситуація дозволяє при створенні багатьох АС відмовитися від проектування і розробки власних реляційних баз даних і власного спеціального програмного забезпечення. Використання сучасних інструментальних засобів дозволяє користувачеві самостійно (без допомоги системного програміста) організовувати зі свого АРМ доступ до різних інформаційних ресурсів, наприклад, створювати каталоги нормативно-правових актів, каталоги адрес WWW-серверів Інтернету і т.п. Поява ОПО останніх версій дозволяє користувачеві організовувати доступ до різних ресурсів АРМ і ЛВС через гіперпосилання (за принципом "павутини") замість ієрархічного принципу доступу (принципу "дерева").
Розподілена система організації баз даних передбачає наявність відповідної технології доступу користувачів до інформаційних ресурсів, орієнтованої, перш за все, на обчислювальні моделі типу "клієнт-сервер".
Технологія "клієнт-сервер" передбачає поділ функцій обробки даних на три групи: функції вводу / виводу та відображення даних; прикладні функції, характерні для даної предметної області; функції зберігання та управління даними. Кожна група функцій виконується окремим логічним компонентом.
Відмінності в реалізації програм у рамках "клієнт-сервер" визначаються механізмом використання та розподілу між комп'ютерами в мережі цих компонент, відповідно до цього виділяють три підходи, реалізовані в моделях:
модель доступу до віддалених даних (Remote Data Access-RDA), в якій компонент подання та прикладної компонент суміщені і виконуються на одному комп'ютері. Запити до інформаційних ресурсів направляються по мережі до віддаленого комп'ютера, який обробляє запити і повертає блоки даних. Ця модель є найпростішою і традиційно використовується в локальних обчислювальних мережах, де швидкість обміну досить висока, проте вона неприйнятна при роботі в середовищі низькошвидкісних каналів передачі даних. Оскільки вся логіка локалізована на одному комп'ютері, то додаток потребує передачі по мережі більшого, часто надлишкового об'єму даних, що істотно підвищує завантаження інформаційної системи в цілому і може призвести до тривалого блокування даних від інших користувачів;
модель сервера бази даних (DataBase Server-DBS), яка будується в припущенні, що процес, що виконується на комп'ютері-клієнті, обмежується функціями подання, в той час як власне прикладні функції реалізовані в збережених безпосередньо в базі даних процедурах, що виконуються на комп'ютері-сервері БД. Переваги DBS-моделі перед RDA полягають в очевидному зниженні мережевого трафіку. Однак DBS-модель не забезпечує необхідної ефективності використання обчислювальних ресурсів, якщо є кілька серверів;
модель сервера додатків (Application Server-AS), в якій процес, що виконується в комп'ютері-клієнті, реалізує функції першої групи. Прикладні функції виконуються на віддаленому комп'ютері. Доступ до інформаційних ресурсів, необхідних для вирішення прикладних завдань, забезпечується тим же способом, що і в RDA моделі. AS-модель не вимагає забезпечення міграції прикладних функцій між серверами, що значно полегшує адміністрування системи в цілому, однак, для забезпечення достатньої швидкості обробки даних сервер додатків і сервер БД повинні знаходиться в одній ЛВС або бути з'єднані по виділеному каналу.
На практиці часто для створення більш гнучких і динамічних систем використовуються змішані моделі.
Комп'ютер-клієнт і комп'ютер-сервер можуть працювати в умовах ЛВС і бути абонентами глобальної комп'ютерної мережі, спілкуючись між собою по організовуваний віртуальному каналу або, використовуючи для цього (при зниженні вимог на реактивність системи) електронну пошту.
В даний час існує цілий ряд програмних засобів, як системних, так і прикладних, що реалізують описані вище моделі. Варто відзначити такі пакети, як Oraclе SQL Server і Sybase SQL Server для платформи NetWare, продукт Microsoft Windows NTSQL Server, Oracle для середовища Unix, Lotus Notes. Всі ці програмні засоби працюють на різних платформах (на машинах з процесорами Intel, на RISC-серверах і станціях виробництва HP, DEC і т.д.), у різних операційних середовищах. СУБД Oracle виділяється серед інших винятковим швидкодією, потужними мережевими засобами та засобами міжплатформене зв'язку. Розвинені засоби електронної пошти пакета Oracle дозволяють організувати безпаперовий документообіг, спільну підготовку та обробку документів. Існує інтегрований програмний продукт ORACLE 2000WG, об'єднуюча переваги популярної мережевої операційної системи Novell NetWare і СУБД Oracle. У структурах управління федеральних, державних і місцевих органів влади все ширше застосовується пакет Lotus Notes.

2. Інфологічне моделювання

2.1.Модель «сутність-зв'язок»

Инфологическая модель відображає реальний світ у деякі зрозумілі людині концепції, цілком незалежні від параметрів середовища зберігання даних. Існує безліч підходів до побудови таких моделей: графові моделі, семантичні мережі, модель "сутність-зв'язок" і т.д. Найбільш популярною з них виявилася модель "сутність-зв'язок" або звана ще ER-моделлю (від англ. Entity-Relationship, тобто сутність-зв'язок).
Инфологическая модель застосовується після словесного опису предметної області.
Проведемо аналіз предметної області проектованої БД.
Користувачі
Код користувача
Логін
Пароль
Примітка
Права користувача
Код доступу
Права
Сеанс
Код сеансу
Код користувача
Код доступу
Номер сеансу
Час початку
Час закінчення
Як будь-яка модель, модель «сутність-зв'язок» має кілька базових понять, які утворюють вихідні цеглинки, з яких будуються вже більш складні об'єкти за наперед визначеними правилами.
Ця модель найбільшою мірою узгоджується з концепцією об'єктно-орієнтованого проектування, яка зараз, безсумнівно, є базовою для розробки складних програмних систем, тому багато понять вам можуть здатися знайомими, і якщо це дійсно так, то тим простіше вам буде освоїти технологію проектування баз даних, засновану на ER-моделі.
Сутність, за допомогою якої моделюється клас однотипних об'єктів. Сутність має ім'я, унікальне в межах модельованої системи. Так як сутність відповідає деякому класу однотипних об'єктів, то передбачається, що в системі існує безліч екземплярів даної суті. Об'єкт, якому відповідає поняття сутності, має свій набір атрибутів - характеристик, що визначають властивості даного представника класу. При цьому набір атрибутів повинен бути таким, щоб можна було розрізняти конкретні екземпляри сутності.
Розглянемо сутності БД на прикладі досліджуваної предметної області.
Користувачі
Код користувача
Логін
Пароль
Примітка


Сеанс
Код сеансу
Код користувача
Код доступу
Номер сеансу
Час початку
Час закінчення
Доступ

Код доступу
Рік народження батькові
Домашній телефон
Адреса
Права користувача
Блок-схема: альтернативний процес: Код доступу
Блок-схема: альтернативний процес: Права користувача
Блок-схема: альтернативний процес: Рік народження батькові
Блок-схема: альтернативний процес: Адреса
Блок-схема: альтернативний процес: Домашній телефон


2.2. Зв'язки між сутностями инфологической моделі

Між сутностями можуть бути встановлені зв'язки - бінарні асоціації, що показують, яким чином сутності співвідносяться або взаємодіють між собою. Зв'язок може існувати між двома різними сутностями або між сутністю і їй же самій (рекурсивна зв'язок). Вона показує, як пов'язані екземпляри сутностей між собою. Якщо зв'язок встановлюється між двома сутностями, то вона визначає взаємозв'язок між екземплярами однієї й іншої сутності.
Визначимо зв'язку між виявленими сутностями.
Зв'язок ОДИН-КО-БАГАТЬОМ (1: М): одному представнику сутності А відповідають 0, 1 або кілька представників сутності В.


У різних нотациях потужність зв'язку зображується по-різному. Між двома сутностями може бути задано скільки завгодно зв'язків з різними смисловими навантаженнями. Зв'язок будь-якого з цих типів може бути обов'язковою, якщо в даній зв'язку повинен брати участь кожен екземпляр сутності, необов'язковою - якщо не кожен екземпляр сутності повинен брати участь у цьому зв'язку. При цьому зв'язок може бути обов'язковою з одного боку і необов'язковою з іншого боку. Обов'язковість зв'язку теж по-різному позначається в різних нотациях. Ми знову використовуємо нотацію POWER DESIGNER. Тут необов'язковість зв'язку позначається порожнім кружечком на кінці зв'язку, а обов'язковість перпендикулярної лінією, який перекреслює зв'язок. І ця нотація має просту інтерпретацію. Кружальце означає, що жоден примірник не може брати участь в цьому зв'язку. А перпендикуляр інтерпретується як те, що, принаймні, один примірник сутності бере участь в цьому зв'язку.
Сутність має ім'я, унікальний у межах моделі. При цьому ім'я сутності - це ім'я типу, а не конкретного екземпляра.
Сутності поділяються на сильні і слабкі. Сутність є слабкою, якщо її існування залежить від іншої сутності - сильної по відношенню до неї.
Сутність може бути розщеплена на два або більше взаємовиключних підтипів, кожен з яких включає загальні атрибути та / або зв'язку. Ці загальні атрибути та / або зв'язку явно визначаються один раз на більш високому рівні. У підтипах можуть визначатися власні атрибути та / або зв'язку. У принципі виділення підтипів може тривати більш низьких рівнях, але в більшості випадків виявляється достатньо двох-трьох рівнів.
Зв'язки діляться на три типи за множинності: один-до-одного (1:1), один-до-багатьох (1: М), багато-до-багатьох (М: М).
Зв'язок один-до-одного означає, що примірник однієї сутності пов'язаний тільки з одним примірником іншої сутності.
Зв'язок один-до-багатьох (1: М) означає, що один примірник сутності, розташований зліва по зв'язку, може бути пов'язаний з декількома екземплярами суті, розташованими праворуч по зв'язку.
Зв'язок «багато-до-багатьох (М: М) означає, що кілька екземплярів першої сутності можуть бути пов'язані з декількома екземплярами друге суті, і навпаки. Між двома сутностями може бути задано скільки завгодно зв'язків з різними смисловими навантаженнями.


Висновок

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

Список літератури

1. Бекаревич Ю.Б., Пушкіна Н.В. Самовчитель Microsoft Access 2002. - СПб.: БХВ-СПб., 2003. - 720 с.
2. Виноградова І.А., Грибова Е.А., Зубков В.Г. Практикум на ЕОМ. MS Access: Навчальний посібник для студентів заочної (дистанційної) форми навчання. - М.: ГІНФО, 2000. - 124 с.
3. Голіцина О.Л., Максимов Н.В., Попов І.І. Бази даних: Навчальний посібник. - М.: ФОРУМ: ИНФРА-М, 2003. - 352 с.
4. Інформатика. Базовий курс. / Под ред. С. В. Симоновича. - СПб.: Питер, 1999. - 640 с.
5. Карпова Т.С. Бази даних: моделі, розробка, реалізація. - СПб.: Пітер, 2002. - 304 с.
6. Петров В.М. Інформаційні системи. - СПб.: Пітер, 2003. - 688 с.
7. Тихомиров Ю.В. MS SQL Server 2000: розробка додатків. - СПб.: БХВ-Петербург, 2000. - 368 с.
Додати в блог або на сайт

Цей текст може містити помилки.

Програмування, комп'ютери, інформатика і кібернетика | Курсова
89кб. | скачати


Схожі роботи:
Инфологическая модель бази даних Тестування
Инфологическая модель бази даних Відепрокат
Инфологическая модель бази даних дистанційної освіти
Инфологическая модель бази даних технологічного процесу
Инфологическая модель бази даних Паспортний облік
Инфологическая модель баз даних Сутність-зв`язок
Захист даних від несанкціонованого доступу
Захист даних і адміністрування бази даних
Просопографіческіе бази даних Росії на прикладі баз даних Comandarm і Duma1
© Усі права захищені
написати до нас