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

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

скачати

ЗМІСТ

ВСТУП

РОЗДІЛ 1. АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ

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

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

РОЗДІЛ 2. Інфологічне проектування

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

2.2. Зв'язки між сутностями

ВИСНОВОК

СПИСОК ЛІТЕРАТУРИ

ВСТУП

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

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

Інфологічне проектування перш за все пов'язане зі спробою подання семантики предметної області в моделі БД.

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

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

  • цілісність і несуперечність даних,

  • достовірність даних,

  • простота управління даними,

  • безпеку доступу до даних.

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

РОЗДІЛ 1. АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ

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

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

Програма працює в ОС Windows 95/98/ME, Windows 2000/2003/NT/XP. Мінімальні вимоги: комп'ютер, на якому здатна працювати якась Windows, 4 Мбайта місця на жорсткому диску плюс розмір даних. Дозвіл екрана монітора повинна бути не менш ніж 800x600.

Програма "Прокат" працює на одному або декількох комп'ютерах операторів пункту прокату і виконує наступні основні функції:

  • Реєстрація клієнтів, формування та друк персональних карток клієнтів

  • Введення товарів, друк етикеток товарів. Є засоби для розробки дизайну карток клієнтів і етикеток товарів

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

  • Видача та повернення з прокату, резервування (замовлення) та продаж товарів з реєстрацією всіх операцій в журналі обліку

  • Гнучка система налаштування різних схем обслуговування клієнтів в залежності від їх Категорії: заставна, абонементна, передоплата, VIP ...

  • Прийом оплати від клієнтів, друк чеків, прибуткових і витратних ордерів, актів, рахунків-фактур, договору з клієнтом і т.п.

  • Облік взаєморозрахунків з кожним клієнтом за всю історію, можливість застосування різних схем взаєморозрахунків

  • Всілякі звіти по товарах: каталоги, за популярністю, довідки про наявність ...

  • Експорт даних в Excel і формування там документа "Облік доходів підприємця"

  • Різні звіти по клієнтам, довідка про боржників, довідка про клієнта

  • Звіти по оборотах за день, за довільний період

  • Можливість блокування, розблокування, і заміни картки клієнта. Занесення клієнта в "чорний список"

  • Можливість роботи в будь-якій валюті (рублі, гривні, USD, EUR і т.п.)

  • Можливість автоматичного друку чеків на касовому апараті АМС-100Ф

  • Розмежування доступу до функцій системи для співробітників пункту прокату

  • Простий і зрозумілий, зручний інтерфейс користувача. Підтримка декількох мов інтерфейсу (у даний час є російський і англійський інтерфейс)

  • Детальна довідкова система, технічна підтримка користувачів

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

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

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

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

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

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

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

Сутність має ім'я, унікальний у межах моделі. При цьому ім'я сутності - це ім'я типу, а не конкретного екземпляра.

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

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

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

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

Абсолютна відмінність між типами сутностей і атрибутами відсутня. Атрибут є таким тільки в зв'язку з типом сутності. В іншому контексті атрибут може виступати як самостійна сутність.

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

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

Між двома сутностей, наприклад, А і В можливі чотири види зв'язків.

Перший тип - зв'язок один-до-одного (1:1): у кожен момент часу кожному представнику (екземпляру) сутності А відповідає 1 чи 0 представників сутності В:

Другий тип - зв'язок один-до-БАГАТЬОМ (1: М): одному представнику сутності А відповідають 0, 1 або кілька представників сутності В.

Так як між двома сутностями можливі зв'язки в обох напрямках, то існує ще два типи зв'язку багато-до-ОДНОМУ (М: 1) і БАГАТО-КО-БАГАТЬОМ (М: N).

РОЗДІЛ 2. Инфологическая ПРОЕКТУВАННЯ

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

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

Инфологическая модель застосовується після словесного опису предметної області.

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

Зв'язки діляться на три типи за множинності: один-до-одного (1:1), один-до-багатьох (1: М), багато-до-багатьох (М: М).

Зв'язок один-до-одного означає, що примірник однієї сутності пов'язаний тільки з одним примірником іншої сутності.

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

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

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

Проведемо інфологічне проектування бази даних технологічного процесу. Инфологическая модель застосовується після словесного опису предметної області. На підставі аналізу предметної області виділимо наступні сутності моделі «сутність-зв'язок» («Entity Relationship» - ER-моделі): «Рубрикатор видів діяльності», «Підприємства та організації», і зобразимо їх у вигляді графічних позначень (прямокутник, у верхній частині якого записано ім'я суті, а нижче перераховуються атрибути, причому ключові атрибути позначаються підкресленням). Вони наведені на рис. 1-2.

Довідник клієнтів

Код клієнта

Прізвище, ІВ

Адреса

Телефон

Категорія

Примітки

рис.1. «Довідник клієнтів»

Відеотека

Код касети

Найменування

Категорія

Вартість

рис.2. «Відтак»

Замовлення

Код замовлення

Дата

Код клієнта

Код касети

Сума

Дата повернення

рис.3. «Замовлення»

Співробітники

Код співробітника

Прізвище ІВ

Табельний номер

Рис.4. «Співробітники»

2.2. Зв'язки між сутностями

Визначимо зв'язку між виявленими сутностями.

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

мал.4. Зв'язок ОДИН-КО-БАГАТЬОМ

рис.5. Моделювання зв'язків між сутностями предметної області

ВИСНОВОК

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

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

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

Доцільно:

  • чітко розмежовувати такі поняття як запит на дані і ведення даних (введення, редагування та видалення);

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

  • поганий проект бази даних не може бути виправлений за допомогою будь-яких (навіть найвитонченіших) додатків.

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

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

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

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

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

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

Створення АІС сприяє підвищенню ефективності виробництва економічного об'єкта і забезпечує якість управління.

СПИСОК ЛІТЕРАТУРИ

  1. Атре Ш. Структурний підхід до організації баз даних. - М.: Фінанси і статистика, 1983. - 320 с.

  2. Бойко В.В., Савінков В.М. Проектування баз даних інформаційних систем. - М.: Фінанси і статистика, 1989. - 351 с.

  3. Дейт К. Посібник з реляційної СУБД DB2. - М.: Фінанси і статистика, 1988. - 320 с.

  4. Джексон Г. Проектування реляційних баз даних для використання з мікроЕОМ. -М.: Світ, 1991. - 252 с.

  5. Кирилов В.В. Структурізованние мову запитів (SQL). - СПб.: ІТМО, 1994. - 80 с.

  6. Мартін Дж. Планування розвитку автоматизованих систем. - М.: Фінанси і статистика, 1984. - 196 с.

  7. Мейєр М. Теорія реляційних баз даних. - М.: Світ, 1987. - 608 с.

  8. Тіорі Т., Фрай Дж. Проектування структур баз даних. У 2 кн., - М.: Світ, 1985. Кн. 1. - 287 с.: Кн. 2. - 320 с.

  9. Ульман Дж. Бази даних на Паскалі. - М.: Машинобудування, 1990.-386 с.

  10. Хаббард Дж. Автоматизоване проектування баз даних. - М.: Світ, 1984. - 294 с.

  11. Цікрітізіс Д., лохівський Ф. Моделі даних. - М.: Фінанси і статистика, 1985. - 344 с.

19


Додати в блог або на сайт

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

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


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