Главная Коллекция "Revolution" Программирование, компьютеры и кибернетика Розробка стратегії, аналіз, концептуальне моделювання та проектування бази даних "Авто порушення"

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

Розробка бази даних предметної області, яка має відношення до функціонування Державної автоінспекції. Визначення мети автоматизації — зняття частини трудомісткої роботи із працівників ДАІ. Ознайомлення з системним аналізом програмного забезпечення.

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык украинский
Дата добавления 13.04.2015
Размер файла 44,8 K
рефераты на заказ со скидкой

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

НАЦІОНАЛЬНИЙ АВІАЦІЙНИЙ УНІВЕРСИТЕТ

ФАКУЛЬТЕТ КОМП'ЮТЕРНИХ НАУК

КУРСОВА РОБОТА

З дисципліни: «Організація баз даних та знань»

Тема: «Розробка стратегії, аналіз, концептуальне моделювання та проектування бази даних «Авто порушення»

Виконав студент 3 курсу 30 групи

кафедри інженерії програмного забезпечення

Керівник курсової роботи:

Доцент кафедри ІПЗ, к. ф.-м. н. Резніченко В.А.

Київ 2008

Зміст

  • Вступ
  • 1. Стратегія автоматизації предметної області
    • 1.1 Загальні положення
    • 1.2 Мета, цілі та задачі створення бази даних
    • 1.3 Вимоги до інформаційного забезпечення
  • 2. Аналіз предметної області
    • 2.1 Загальні положення системного аналізу ПО
    • 2.2 Загальні положення роботи ДАІ
    • 2.3 Системний аналіз предметної області
      • 2.3.1 Авто
      • 2.3.2 Авто вопорушення
      • 2.3.3 Робітник ДАІ
      • 2.3.4 Водій
      • 2.3.5 Законодавча база
    • 2.4. Інформаційно-довідкові задачі
  • 3. Концептуальне моделювання предметної області
    • 3.1 Теоретичні положення концептуального моделювання
    • 3.2 Мова ER--моделювання ПО
    • 3.3 Побудова концептуальної моделі обліку водіїв
  • 4. Логічне та фізичне проектування бази даних
    • 4.1 Логічне проектування
    • 4.2 Фізичне проектування
      • 4.2.1 Скрипти створення бази даних
      • 4.2.2 Інформаційно-пошукові запити
  • Висновки

Вступ

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

· розробка стратегії автоматизації предметної області;

· проведення системного аналізу предметної області;

· концептуальне моделювання предметної області;

· логічне та фізичне проектування.

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

1. Стратегія автоматизації предметної області

1.1 Загальні положення

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

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

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

Основні результати цього етапу повинні включати:

· визначення цілей і завдань автоматизації;

· визначення напрямку прикладної діяльності, наприклад, мети й завдання прикладної діяльності, пріоритети, обмеження, критичні фактори успіху, ключові показники ефективності;

· визначення границь системи, сфера застосування системи баз даних;

· можлива архітектура системи;

· вимоги до системи;

· поетапний план розробки.

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

1.2 Мета, цілі та задачі створення бази даних

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

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

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

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

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

· Підвищення ефективності й продуктивності планування внесення протоколів до БД;

· Поліпшення організації оперативного контролю за функціонуванням правопорушників. Використовуючи БД, з'являється можливість миттєвого інформування про наявність того чи іншого правопорушення, тощо.

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

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

Досягнення зазначених цілей виконується за рахунок:

· створення комплексної інформаційної системи із централізованою базою даних;

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

· підвищення ефективності й продуктивності роботи обслуговуючого персоналу;

· підвищення вірогідності, несуперечності, повноти й надійності інформації;

· підвищення наочності, зручності використання й інформативності одержуваних даних;

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

1.3 Вимоги до інформаційного забезпечення

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

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

· поза машинну інформаційну базу (ІБ);

· внутрішньо-машинну ІБ.

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

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

Проектні рішення з розробки внутрішньо-машинної ІБ повинні відображати фізичний рівень зберігання інформації в системі у вигляді баз даних (БД) і масивів повнотекстової інформації і ураховувати:

· розподілене збереження інформаційних ресурсів;

· динаміку актуалізації інформації;

· спосіб представлення та структуризацію інформації (реляційні БД, текстові файли, електронні документи і т. ін.).

БД має містити наступну інформацію:

· Кількісний та якісний склад робочого устаткування.

· Систему продажу товару.

· Контроль надходження товару.

БД повинна бути спроектована таким чином, щоб задовольняти вимогам щодо реакції системи на запити. Для диспетчера задовільним є 1-3 секунди, а для інших користувачів бази даних 1-5 секунд.

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

2. Аналіз предметної області

2.1 Загальні положення системного аналізу ПО

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

Аналіз включає:

· проведення всіляких бесід з користувачами й узяття в них інтерв'ю;

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

· аналіз потоку документів (документообіг);

· аналіз розв'язуваних в організації завдань і способів їхнього рішення;

· фіксація всіляких правил, обмежень, законів, що діють у ПО.

Факторами успіху проведення аналізу ПО є наступні:

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

· ретельна перевірка вірогідності, повноти, несуперечності отриманої інформації .

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

· точні об'ємно-частотні характеристики даних;

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

2.2 Загальні положення роботи міліціонерів на дорозі

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

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

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

· Контроль роботи передбачає безперервність та послідовність його проведення при одержанні потрібного достатнього обсягу практичних знань.

· Зміст і послідовність контролю визначається керівництвом та особами безпосередньо задіяними в відповідних відділах або департаментах.

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

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

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

Атрибут - це властивості, що характеризують сутність. Серед атрибутів (і/або, можливо, зв'язків) існує такий набір властивостей, які унікально ідентифікують будь-які екземпляри сутності. Виділяються обов'язкові й факультативні атрибути. Зв'язок - це будь-яка пойменована асоціація двох сутностей.

Бізнес-правила - це правила й обмеження, що діють у ПО відносно основних понять інформаційної структури (сутностей, атрибутів і зв'язків). Виділяються бізнес правила, що мають відносини до атрибутів однієї сутності (унікальність атрибутів, ідентифікація сутності, спеціальні правила, наприклад, тривалість практики вказується в годинниках і не повинна перевищувати 500 годин), до зв'язків між сутностями (факультативність закінчення зв'язку, потужність закінчень зв'язку (1:1, 1:n, m:n), ступінь зв'язку, наприклад, на факультеті повинне бути не більше 10 кафедр).

Інформаційно-довідкові задачі (на відміну від прикладних задач) -- це ті задачі, які вибирають деяку підмножину даних з інформаційної моделі ПО.

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

У результаті аналізу ПО були визначені наступні сутності, їх атрибути та зв'язки.

2.3.1 Авто

Короткий опис сутності. Авто містить дані про машину, які мають доступ до даних про водія. Суть Авто - закріплена за одним водієм. До складу машини може входити номер авто, паспорт авто та марку.

Атрибути. Авто характеризується наступними атрибутами:

· Номер машини

· Марка машини

· Номер паспорту машини

Зв'язки. Авто має наступні зв'язки з іншими сутностями:

· Авто має одне або більше Авто порушень

Бізнес-правила:

· Атрибут «Номер машини» унікально ідентифікує його , так як не можуть бути два і більше із однаковим номером, має 5 цифр;

· Атрибут «Номер паспорту машини» мають 3 букви та 6 цифер, унікальний;

· усі інші атрибути є обов'язковими

2.3.2 Авто порушення

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

Атрибути. Сутності Авто порушення характеризується наступними атрибутами:

· Номер протоколу

· Дата правопорушення

· Місце порушення

· Сума виплати

Зв'язки. Сутність Правопорушень має наступні зв'язки з іншими сутностями: автоінспекція автоматизація програмний

· Авто порушення обов'язково має бути зафіксовано лише єдиний раз на Авто

· Номер статті обов'язково має єдину трактовки у Законодавчій Базі

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

· Авто порушення обов'язково має бути зафіксоване одним Робітником ДАІ

Бізнес-правила:

· Атрибут «Номер Протоколу» унікально ідентифікує його , так як не можуть бути два і більше із однаковим номером. Протокол складається з 5 цифр.

· усі інші атрибути є обов'язковими

2.3.3 Робітник ДАІ

Короткий опис сутності. Робітник ДАІ містить дані про міліціонерів. До складу Робітник ДАІ може входити номер міліціонера, ім'я та його посада.

Атрибути. Робітник ДАІ порушення характеризується наступними атрибутами:

· Номер міліціонера

· Ім'я

· Посада

· Вік

· Стать

Зв'язки. Сутність Робітника ДАІ має наступні зв'язки з іншими сутностями:

· Робітник ДАІ обов'язково має одне або декількох зафіксованих Авто порушень;

Бізнес-правила:

· Атрибут «номер міліціонера» унікально ідентифікує сутність , так як не можуть бути два і більше з однаковим номером, має 6 цифр;

· Атрибут Стать може приймати тільки 2 значення: «м», «ж»;

· усі інші атрибути є обов'язковими;

2.3.4 Водій

Короткий опис сутності. Водій містить дані про водія, які мають доступ до даних про його машину. Суть Водія - закріплена за одним авто. До складу Водій може входити номер його паспорту та адресу

Атрибути. Водій характеризується наступними атрибутами:

· Ім'я водія

· Номер паспорту

· Дата народження

· Номер соц. страховки на авто

Зв'язки. Сутність Водій має наступні зв'язки з іншими сутностями:

· Водій обов'язково має одне або декількох Авто порушень;

Бізнес-правила:

· Атрибут «Номер паспорту» унікально ідентифікує його , так як не можуть бути два і більше із однаковим номером. Номер паспорту має 3 букви та 6 цифр;

· Атрибут «Номер соц. Страховки» має тільки 8 цифр та є унікальними;

· усі інші атрибути є обов'язковими

2.3.5 Законодавча база

Короткий опис сутності. Законодавча База порушення містить дані про статті з авто порушеннями, які мають доступ до даних Конституції України. До складу Авто порушень може входити номер авто, ім'я водія, дата та місце порушення.

Атрибути. Законодавча База характеризується наступними атрибутами:

· Номер статті

· Трактовка статті

· Дата її прийняття

Зв'язки. Сутність крамниці мають наступні зв'язки з іншими сутностями:

· Законодавча База обов'язково має одну або більше статей з Авто правопорушень;

Бізнес-правила:

· Атрибут «номер статті» унікально ідентифікує сутність , так як не можуть бути два і більше з однаковим номером, має максимум 4 цифри;

· Атрибут «Трактовка статті» є унікальною;

· усі інші атрибути є обов'язковими

2.4 Інформаційно-довідкові задачі

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

По-перше, інформація, що пов'язана з пошуковими задачами:

· Надання повної та несуперечливої інформації про Правопорушення.

· Надання повної та несуперечливої інформації стосовно Водіїв та їх транспорту.

· Можливість збору статистичних даних.

По-Друге,можливість вирішення організаційних питань

· надання інформації по водіям та міліціонерам

· Спосіб полегшення механізму контролю протоколів

3. Концептуальне моделювання предметної області

3.1 Теоретичні положення концептуального моделювання

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

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

Властивостями концептуальної моделі є наступні.

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

· Вона включає тільки концептуально релевантні аспекти ПО, крім, таким чином, БУДЬ-ЯКИХ аспектів зовнішнього або внутрішнього представлення даних. Це означає, по перше, що концептуальна модель жодним чином не повинна фіксувати конкретні потреби окремих груп користувачів або додатків. Вона повинна фіксувати, що собою представляє ПО в цілому, а не з погляду інтересів або потреб користувачів. Вона повинна інтегрувати думки, погляди й інтереси окремих користувачів, але саме інтегрувати, для одержання цілісної картини, а не виражати їхні конкретні погляди, побажання думки. По-друге, у концептуальній моделі ПО ні яким чином не повинні відбиватися які-небудь аспекти майбутньої реалізації БД у комп'ютерному середовищі. Усе, що пов'язане з такими поняттями, як способи зберігання, методи доступу, ефективність виконання, оптимізація й т.д. перебувають за межами концептуальної моделі.

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

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

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

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

Ключовими результатами етапу концептуального моделювання э наступні:

· формальний опис інформаційного забезпечення предметної області.

· докладний і строгий опис сховищ даних.

· детальний опис потоків даних.

· детальний опис ієрархії розв'язуваних завдань із детальною специфікацією всіх завдань.

· детальний опис діючих у предметній області правил і обмежень.

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

3.2 Мова ER--моделювання ПО

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

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

Розглянемо коротко основні властивості, формальні позначення й визначення сутностей, зв'язків, атрибутів.

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

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

· ім'я;

· ступінь/потужність;

· факультативність -- обов'язкова або факультативна.

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

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

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

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

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

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

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

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

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

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

3.3 Побудова концептуальної моделі обліку водіїв

На основі проведеного аналізу предметної області була побудована концептуальна модель з використанням мови ER-моделювання. Концептуальна модель наведена на наступному рисунку. Дамо декілька зауважень:

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

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

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

4. Логічне та фізичне проектування бази даних

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

Логічне проектування -- це розробка логічної структури системи баз даних без прив'язки до конкретної СУБД, структур збереження, методам доступу і т.д..

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

4.1 Логічне проектування

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

Для перетворення концептуальної моделі, представленої у вигляді мови ER-моделювання, у реляційну модель, був використаний наступний алгоритм.

· Крок 1. Перетворення сутностей у таблиці. Кожна сутність перетворюється у таблицю. Ім'я сутності представляється у вигляді семантично осмисленого імені у латинському алфавіті.

· Крок 2. Перетворення атрибутів у стовпці. Кожний атрибут перетвориться в стовпець. Ім'я атрибуту представляється у вигляді семантично осмисленого імені у латинському алфавіті. У цей момент уточнюється формат представлення значень стовпця. Факультативні атрибути стають NULL-стовпцями. Обов'язкові атрибути стають NOT NULL-стовпцями.

· Крок 3. Подання унікальних ідентифікаторів ключами таблиць. Складові унікального ідентифікатора сутності стають первинним ключем таблиці. Нагадаємо, що сутність може мати більш ніж один унікальний ідентифікатор Тому вибирається той, котрий використовується найбільше часто. Всі інші унікальні ідентифікатори приймають обмеження цілісності UNIQUE NOT та NOT NULL.

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

· Крок 4. Перетворення зв'язків багато-до-одного й один-до-одного в зовнішні ключі. Зв'язки типу багато-до-одного й один-до-одного породжують зовнішні ключі. Інакше кажучи, необхідно взяти унікальні ідентифікатори кожної сутності, розташованої в закінчення зв'язку зі ступенем один, і ввести його у відношення, розташоване з боку зв'язку "багато" як стовпці. Факультативним зв'язкам відповідають NULL-стовпці. Обов'язковим зв'язкам відповідають NOT NULL-стовпці.

· Крок 5. Введення спеціальних первинних ключів. Для більш адекватного відображення логічного проекту бази даних у фізичний, вводимо у всі таблиці один спеціальний стовпець з обмеженням цілісності первинного ключа. Всі ті стовпці, які мають властивість первинного ключа згідно з концептуальною моделлю, набувають обмеження цілісності UNIQUE та NOT NULL.

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

Таблиця 1. Відношення сутності Авто Car

Ім'я стовпця

Тип

Довжина

Призначення

Обмеження цілісності стовпців

CNUM

ціле число

5

Унікальний ID

Первинний ключ

CNAME

Рядок

50

Марка машини

Обов'язковий

Car_Pas

Рядок

9

Паспорт машини

Унікальний,

3 букви та 6 цифер

Обмеження цілісності таблиці

Unique (Car_Pas)

Таблиця 2. Відношення сутності Авто порушення

Unlaw Ім'я стовпця

Тип

Довжина

Призначення

Обмеження цілісності стовпців

NumProtokol

ціле число

5

Унікальний ID

Первинний ключ

NumStat

ціле число

4

Унікальний ID

Зовнішній ключ, що посилається на первинний ключ

відношення Law Base

Факультативний

UDate

Date

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

Обов'язковий

CNUM

ціле число

5

Унікальний ID

Зовнішній ключ, що посилається на первинний ключ

відношення Car

Факультативний

CopNum

ціле число

6

Унікальний ID

Зовнішній ключ, що посилається на первинний ключ

відношення DAI

Факультативний

Dr_PAS

Рядок

9

Унікальний ID

Зовнішній ключ, що посилається на первинний ключ

відношення Driver

Факультативний

Suma

ціле число

Сума виплати

Обов язковий

Таблиця 3. Відношення сутності Робітник ДАІ Cop

Ім'я стовпця

Тип

Довжина

Призначення

Обмеження цілісності стовпців

COPNUM

ціле число

6

Унікальний ID

Первинний ключ

ОDate

дата

Дата народження

Обов'язковий

CopName

Рядок

40

Ім я міліціонера

Обов'язковий

POST

Рядок

30

Должность

Обов'язковий

Sex

varChar

1

Стать робітника

Приймає значення «m» або «f»

Таблиця 4. Відношення сутності Водії Driver

Ім'я стовпця

Тип

Довжина

Призначення

Обмеження цілісності стовпців

DrName

Рядок

50

Ім'я водія

Обов'язковий

Dr_Pas

Рядок

9

Унікальний ID

Первинний ключ

City

Рядок

20

Місто проживання

Обов'язковий

Insurance

Ціле число

8

Номер соц. страховки

Унікальний та складається з 8 цифр

Обмеження цілісності таблиці

Unique (insurance)

Таблиця 5. Відношення сутності Законодавча База LawBase

Ім'я стовпця

Тип

Довжина

Призначення

Обмеження цілісності стовпців

NumStat

ціле число

4

Унікальний ID

Первинний ключ

article

Рядок

100

Статья

Обов'язковий

LDate

Date

Дата прийняття

закону

Обов'язковий

Обмеження цілісності таблиці

Unique (article)

4.2 Фізичне проектування

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

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

4.2.1 Скрипти створення бази даних

Наведемо скрипт мови SQL, який створює таблиці БД.

Створення таблиці Авто

Create TABLE Car(

CNUM int(5) PRIMARY KEY ,

CNAME varchar(50) NOT NULL,

Car_PAS varchar(9) NOT NULL,

UNIQUE (Car_PAS));

Створення таблиці Авто порушення

Create TABLE Unlaw(

NumProt int(5) PRIMARY KEY ,

NumStat int(4) REFERENCES LawBase(NumStat),

UDate date NOT NULL,

CNUM int(5) REFERENCES Cars(CNUM),

CopNUM int(6) REFERENCES DAI(CopNum),

Dr_PAS varchar(9) REFERENCES Driver(dr_PAS),

Suma int not null);

Створення таблиці Робітників ДАІ

Create TABLE COP(

CopNUM int(6) PRIMARY KEY ,

ODate date NOT NULL,

CopName varchar(40) NOT NULL,

Post varchar(30),

Sex varchar(1) check (Sex='m' or Sex='f'));

Створення таблиці Водії

Create TABLE Driver(

DrName varchar(50) NOT NULL,

Dr_Pas varchar(9) Primary key,

City varchar(20) not null,

Insurance int(8) not null,

UNIQUE (insurance));

Створення таблиці Законодавча База

Create TABLE LawBase(

NumStat int(4) PRIMARY KEY ,

Article varchar(100) NOT NULL,

LDate date NOT NULL,

UNIQUE (article));

4.2.2 Інформаційно-пошукові запити

Наведемо приклади інформаційно пошукових запитів відносно тих задач, які були окреслені в підрозділі «2.4. Інформаційно-довідкові задачі». Приклади наведемо у мові SQL Oracle з використанням бази даних, визначеної у попередньому підрозділі.

Інформаційні запити, що пов'язані з правопорушеннями

Запит 1.Вивести найвищій штраф, дату його виписки та марку машини.

Select Max(suma), udate, cname

From Car, Unlaw

Where car.cnum=unlow.cnum;

Запит 2Вивести грошову суму штрафів для авто з номерними паспорту «АВК5263524».

Select SUM(Suma)

FROM Unlaw

WHERE Unlaw.cnum = (select Car.cnum

From Car

Where Car_Pas='АВК5263524');

Запит 3Вивести ім я міліціонерів та посаду, у яких жіноча стать та у яких кількість протоколів більша 10.

SELECT CopName, Post

FROM Cop

WHERE Sex='f' and Car.CopNum in (select Unlaw.copnum

From Unlaw

Group by unlaw.copnum

Having count(numprotokol)>100);

Інформація організаційного характеру

Запит 1.Вивести номера техпаспорту машини правопорушника та соц. страховку.

SELECT Car_Pas, insurance

From Cars, unlaw, driver

Where cars.cnum=unlaw.cnum And unlaw.dr_Pas=Driver.Dr_Pas;

Запит 2Вивести усі авто та водія, які були затримані по статті = 104.

SELECT *

From Cop, unlaw

Where cop.copnum=unlaw.copnum and unlaw.numstat=104

Union

SELECT *

From Car, unlaw

Where car.cnum=unlaw.cnum and unlaw.numstat=104;

Запит 3Вивести ім я водія та зміст порушеної статті.

SELECT D.DrName, L.article

From Driver D, LawBase L

Where D.dr_pas = (select C.dr_pas

From Cars C

Where L.numstat=C.numstat);

Інформація про Авто

Запит 1.Вивести усю інформацію про Авто та їх водіїв.

SELECT *

From Cop, unlaw

Where cop.copnum=unlaw.copnum

Union

SELECT *

From Car, unlaw

Where car.cnum=unlaw.cnum;

Запит 2Вивести номер авто та марку, Паспорт яких має начало з «А…».

SELECT cnum, cname

From Car

Where Car_Pas like `A%';

Запит 3Вивести кількість правопорушників з Києву.

SELECT count(UnLaw.Dr_Pas)

From UnLaw, Driver

Where unlaw.dr_Pas=Driver.dr_Pas and Driver.City='Кієв';

Висновки

Проектування баз даних -- це складний, багатокроковий процес перетворення інформаційного середовища ПО у інформаційну модель у вигляді бази даних. Цей процес складається з різних етапів, а саме: розробка стратегії автоматизації, аналіз ПО, побудова концептуальної моделі ПО, логічне та фізичне проектування БД. На сучасному етапі розвитку інформатики проектування баз даних перетворилося на цілком сформовану наукову дисципліну, яка має у своєму складі формально-теоретичну та технологічну складові. Теоретичної основою проектування баз даних є теорія нормалізації, яка дозволяє чітко і строго відповісти на таке запитання: як слід проводити перетворення початкової схеми ПО таким чином, щоб результуюча схема бази даних була еквівалентна початковій і була краща за неї. Методологія проектування детально описує усі етапи життєвого циклу створення бази даних з використанням сучасних мов опису ПО.

Ціллю курсової роботи було проектування бази даних дорожніх правопорушення.

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

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

Логічне та фізичне проектування БД складалося з конвертації концептуальної моделі ПО у реляційну модель даних. При цьому був використаний алгоритм конвертування схеми ПО у мові ER в схему реляційної бази даних. Після цього реляційна база даних була представлена у вигляді команд створення таблиць бази даних у мові SQL ORACLE. Крім того, у мові SQL описані деякі інформаційно-пошукові запити.

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

Размещено на Allbest.ru

...

Подобные документы

  • Розробка бази даних "Автосалон" в середовищі MSAccess

    Розробка структури бази даних. ER-моделі предметної області. Проектування нормалізованих відношень. Розробка форм, запитів, звітів бази даних "Автосалон". Тестування роботи бази даних. Демонстрація коректної роботи форми "Додавання даних про покупців".

    курсовая работа [4,0 M], добавлен 02.12.2014

  • Меблева фірма: розробка бази даних

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

    курсовая работа [1,4 M], добавлен 24.10.2010

  • База даних "Кафедра" в Access з меню MDI

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

    курсовая работа [861,7 K], добавлен 21.02.2010

  • Розробка бази даних розкладу занять у тренажерному залі

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

    курсовая работа [946,8 K], добавлен 02.07.2015

  • База даних "Магазин тенісного устаткування"

    Побудова інформаційної системи "Магазин товарів для настільного тенісу" з автоматизації роботи магазину. Концептуальне моделювання бази даних. Обґрунтування вибору СУБД. Логічне проектування бази даних. Схема бази даних. Створення таблиць в конструкторі.

    курсовая работа [8,8 M], добавлен 16.12.2015

  • Інформаційна система "Відділення банку"

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

    курсовая работа [3,5 M], добавлен 28.11.2011

  • Розробка бази даних

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

    курсовая работа [55,1 K], добавлен 15.03.2015

  • Проект бази даних

    Опис предметної області. Визначення проблеми та постановка задачі. Проектування бази даних. Концептуальна модель. Логічна модель. Фізична модель. Розробка програмних модулів.

    курсовая работа [136,3 K], добавлен 14.07.2007

  • Розробка програмного засобу для вирішення задачі автоматизації платіжного доручення на малому підприємстві

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

    курсовая работа [3,2 M], добавлен 30.01.2014

  • Автоматизація роботи магазину будівельних матеріалів

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

    курсовая работа [559,2 K], добавлен 09.05.2016

  • Проектування та створення бази даних реєстратури в поліклініці засобами MySQL

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

    курсовая работа [2,9 M], добавлен 06.11.2011

  • Операції з нерухомістю

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

    курсовая работа [1,5 M], добавлен 10.06.2013

  • Розробка бази даних автоінспекції

    Проектування інформаційної системи для супроводу баз даних. Моделі запиту даних співробітником автоінспекції та обробки запиту про машини та їх власників. База даних за допомогою SQL-сервер. Реалізація запитів, процедур, тригерів і представлення.

    курсовая работа [1,7 M], добавлен 18.06.2012

  • База даних клієнтів і замовлень

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

    курсовая работа [1,4 M], добавлен 29.04.2010

  • Концепція автоматизованого програмування

    Розробка бази даних для обробки інформації про діяльність туристичного агентства. Визначення предметної області, вхідних та вихідних даних, їх організації. Генерація схеми бази даних. Реалізація функціональних вимог. Інструкція з експлуатації системи.

    курсовая работа [5,3 M], добавлен 12.05.2015

  • Розробка бази даних Access "Агентство нерухомості"

    Аналіз предметної області, проектування бази даних, її фізичної реалізації в СУБД Access. Схема даних зі зв'язками між таблицями. Форми, що забезпечують інтерфейс. Запити у режимі Конструктора і мовою SQL. Звіти в режимі звіту і в режимі Конструктора.

    курсовая работа [5,2 M], добавлен 01.04.2016

  • Розробка комп'ютерної гри "Міста"

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

    курсовая работа [2,3 M], добавлен 02.06.2016

  • Розробка бази даних "Відділ комп’ютерних комплектуючих"

    Властивості та функції бази даних. Вибір та обгрутування програмного забезпечення Microsoft Access. Розробка бази даних за методом сутність-зв’язок. Етапи розробки бази даних "Відділ комп’ютерних комплектуючих" за допомогою СУБД Microsoft Office Access.

    курсовая работа [7,4 M], добавлен 12.06.2019

  • Концептуальне та логічне проектування навчальної бази даних "Автотранспортне підприємство"

    Концептуальна модель бази даних, визначення зв’язків між ними, атрибутів сутностей їх доменів. Створення ORM source model та Database model diagram для бази даних "Автотранспортне підприємство". Генерування ddl-скрипта для роботи в СУБД SQL-Server.

    курсовая работа [47,3 K], добавлен 17.10.2013

  • Проектування та розробка бази даних маршрутів міського транспорту

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

    курсовая работа [35,6 K], добавлен 19.08.2012

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены