Розробка бази даних інформаційної системи

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

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

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

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

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

1. Аналіз відомих підходів до проектування баз даних

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

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

Найчастіше концептуальна модель бази даних включає в себе:

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

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

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

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

На етапі логічного проектування враховується специфіка конкретної моделі даних, але може не враховуватися специфіка конкретної СУБД.

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

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

Основна стаття: ER-модель даних

Модель «сутність-зв'язок» (англ. «Entity-Relationship model»), або ER-модель, запропонована П. Ченом в 1976 р., є найбільш відомим представником класу семантичних (концептуальних, інфологічних) моделей предметної області. ER-модель зазвичай представляється в графічній формі, з використанням оригінальної нотації П. Чена, званої ER-діаграма, або з використанням інших графічних нотацій (Crow'sFoot, InformationEngineering та ін.)

Основні переваги ER-моделей:

1. наочність;

2. моделі дозволяють проектувати бази даних з великою кількістю об'єктів і атрибутів;

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

Основні елементи ER-моделей:

1. об'єкти (сутності);

2. атрибути об'єктів;

3. зв'язки між об'єктами.

Сутність - об'єкт предметної області, що має атрибути.

Зв'язок між сутностями характеризується:

1. типом зв'язку (1:1, 1: N, N: М);

2. класом приналежності. Клас може бути обов'язковим і необов'язковим. Якщо кожен екземпляр сутності бере участь у зв'язку, то клас приналежності - обов'язковий, інакше - необов'язковий.

1.2 Ієрархічна, мережева та реляційна моделі представлення даних

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

При використанні ієрархічної моделі представлення даних зв'язку між даними можна охарактеризувати за допомогою упорядкованого графа (або дерева). У програмуванні при описі структури ієрархічної бази даних застосовують тип даних «дерево».

Основними достоїнствами ієрархічної моделі даних є:

1) ефективне використання пам'яті ЕОМ;

2) висока швидкість виконання основних операцій над даними;

3) зручність роботи з ієрархічно впорядкованою інформацією.

До недоліків ієрархічної моделі представлення даних відносяться:

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

2) труднощі в розумінні її функціонування звичайним користувачем.

Незначне число СУБД побудовано на ієрархічній моделі даних.

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

Достоїнствами мережевої моделі представлення даних є:

1) ефективність у використанні пам'яті комп'ютера;

2) висока швидкість виконання основних операцій над даними;

3) величезні можливості (більші, ніж у ієрархічній моделі) освіти довільних зв'язків.

До недоліків мережевої моделі представлення даних відносяться:

1) висока складність і жорсткість схеми бази даних, яка побудована на її основі;

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

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

Реляційна модель представлення даних була розроблена співробітником фірми 1ВМЕ. Кодом. Його модель ґрунтується на понятті «ставлення» (relation). Найпростішим прикладом відносини служить двовимірна таблиця.

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

До недоліків реляційної моделі представлення даних відносяться:

1) відсутність стандартних засобів ідентифікації окремих записів;

2) складність опису ієрархічних і мережевих зв'язків.

Більшість СУБД, застосовуваних як професійними, так і непрофесійними користувачами, побудовані на основі реляційної моделі даних (Visual FoxPro і Access фірми Microsoft, Oracle фірми Oracle та ін.)

1.3 Реляційна модель бази даних

Реляційна модель отримала свою назву від англійського слова relation (відношення) і була запропонована 1970-х роках Едгаром Коддом.

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

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

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

Реляційна база даних - це реалізація реляційної моделі на фізичному рівні.

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

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

Кожна таблиця має свою структуру, яка складається з таких елементів:

1. описання полів;

2. ключі;

3. індекси;

4. обмеження на значення полів;

5. обмеження посилочної цілісності між таблицями;

6. права доступу.

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

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

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

Кожне відношення можна розділити на дві частини - заголовок і тіло. Тіло відношення складається з кортежів.

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

В функціональні залежності можуть входити групи атрибутів.

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

Ключ забезпечує:

1. однозначну ідентифікацію записів таблиці;

2. запобігає повторенню значень ключа;

3. прискорення виконання записів до БД;

4. встановлення зв'язків між окремими таблицями БД;

5. використання обмежень посилочної цілісності.

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

Використання індексу забезпечує:

1. збільшення швидкості доступу (пошуку) до даних;

2. сортування записів;

3. встановлення обмежень посилочної цілісності.

Модель даних - найабстрактніший рівень проектування баз даних. Елементами описання моделі даних є сутності, атрибути, домени та відношення.

У Кренке Дано таке визначення «сутність»: «Сутність - це деякий об'єкт системи, що ідентифікується в робочому середовищі користувача, який має певний набір атрибутів. Атрибутом називають пойменовану характеристику сутності»

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

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

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

Зв'язки один до одного зустрічаються досить рідко, в основному, між сутностями надтипів та підтипів.

Зв'язки один до багатьох зустрічаються більш частіше.

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

Участь кожної сутності в певному зв'язку може бути частковою або повною. Якщо існування даної сутності повністю визначається її участю у зв'язку, то така участь буде повною, в іншому випадку - частковою.

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

1.4 Організація обмежень посилальної цілісності

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

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

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

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

Отже, зв'язки можна класифікувати один із трьох можливих способів:

- повні та часткові;

- обов'язкові та необов'язкові;

- слабкі та звичайні сутності.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Розрізняються склади і за ступенем механізації складських операцій:

- Немеханізовані,

- Комплексно-механізовані,

- Автоматизовані

- Автоматичні.

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

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

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

За цією ознакою склади можна розділити на дві основні групи:

1) склади на ділянці руху продукції виробничо-технічного призначення;

2) склади на ділянці руху товарів народного споживання.

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

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

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

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

- Тимчасове розміщення та зберігання матеріальних запасів.

- Перетворення матеріальних потоків.

- Забезпечення логістичного сервісу в системі обслуговування.

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

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

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

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

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

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

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

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

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

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

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

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

Продукція зі складів направляється замовникам відповідно до укладених договорів. Відправляється продукція на підставі товарно-транспортної накладної. Товарно-транспортна накладна складається з: загальної частини (номер накладної, номер договору, дата відвантаження) і специфікації (вид і кількість продукції, що відвантажується).

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

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

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

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

Багато організацій використовують склади як зручні місця для виконання та інших видів робіт. Очевидно, склади можна використовувати для інспектування і сортування матеріалів і розбивки опту (поділу великих партій матеріалів на невеликі). Їх також можна використовувати для доведення продукції до потрібної кондиції, наклеювання етикеток, упаковки, підготовки продуктів для рітейлерів, щоб ті могли відразу виставляти її на продаж, виконання робіт, пов'язаних зі зменшенням комерційного ризику (проведення заключних робіт в останній момент), надання послуги «запаси, керовані продавцем» і т.д. Загальна тенденція така, що в даний час склади виконують все більше завдань, безсумнівно додаючи цінність продукту, а не будучи чистими центрами витрат.

Обмеження предметної області

При створенні проекту були виявлені наступні обмеження:

- На складі зберігатися декілька найменувань продукції;

- Кількість продукції вимірюється цілим числом;

Кожен договір укладається з одним замовником, але з одним замовником може бути укладено декілька договорів;

- Номер договору незмінний і унікальний;

- В одному договорі можуть бути перераховані кілька найменувань товару;

- Одне і те ж виріб може бути зазначено в договорі кілька разів, але з різними термінами відвантаження;

- Товарно-транспортна накладна відноситься до одному договору і може містити кілька найменувань виробів;

- Номер товарно-транспортної накладної унікальний для підприємства;

- Номер платіжного доручення унікальний для конкретного замовника і відповідає конкретній товарно-транспортної накладної;

- Однією товарно-транспортною накладною може відповідати кілька платіжних доручень.

Система складається з декількох підсистем:

- Інформація про співробітника

- Облік міграції кадрів

- Облік документації

2.2 Підсистема «ID»

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

2.2.1 Зовнішні сутності:

Інвестор - Зберігає базову інформацію про інвестора.

Магазин - Зберігає необхідну про магазини.

Реклама - зберігання інформації про умови контракту з рекламодавцем.

Робітник - Зберігає інформацію про працівників.

Товари - Зберігає інформацію про товари та їх характеристики

2.3 «Реклама»

Підсистема «Реклама» включаю в себе облік контактів компаній в рекламних цілях. Вхідними даними для системи є інформації про назви вище зазначених компаній а на виході ми маємо облік всіх рекламних контрактів - заключних між компаніями.

2.4 Категорії користувачів

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

- адміністратора БД;

- групи експертів.

Адміністратор системи здійснює заповнення БД інформацією, що групою експертів. Внесення змін у БД системи здійснюється лише адміністратором системи під керівництвом групи експертів. Працівники та начальники є зовнішніми користувачами, що працюють з системою відповідно до ролей доступу в інформаційно-пошуковому режимі. Можливості, що надаються користувачам системи:

Проблема подання семантики давно цікавила розробників, і в сімдесятих роках було запропоновано кілька моделей даних, названих семантичними моделями. До них можна віднести семантичну модель даних, запропоновану Хаммером (Hammer) і Мак-Леоном (McLeon) в 1981 році, функціональну модель даних Шипман (Shipman), також створену в 1981 році, модель «сутність-зв'язок», запропоновану Ченом (Chen) в 1976 році, і ряд інших моделей. У всіх моделей були свої позитивні і негативні сторони, але випробування часом витримала лише остання. І зараз саме модель Чена «сутність-зв'язок», або «EntityRelationship», стала фактичним стандартом при інфологіческого моделювання баз даних.

Модель «сутність-зв'язок» називають також «ER-моделлю» (essence-сутність, relation-зв'язок).

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

1. Зв'язку вила 1:1 утворюється у випадку, коли всі поля запису основної таблиці та додаткової таблиці є ключовими.

2. Зв'язок 1: М може бути у випадку, коли одного запису основної таблиці відповідає кілька записів додаткової таблиці.

3. Зв'язок М: 1 може бути тоді, коли декільком записам основної таблиці ставиться у відповідності один запис додаткової.

4. Зв'язок М: М виникає в тому випадку коли декільком записам основної таблиці відповідає кілька записів додаткової. У реляційної БД зв'язок М: М реалізується через додаткові таблиці.

Розглянемо зв'язки між виявленими сутностями:

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

2. Між атрибутами співробітники і відрядження буде зв'язок 1: М, так як співробітник може скільки завгодно разів їздити у відрядження.

3. Між атрибутами співробітники і лікарняний буде зв'язок 1: М, так як співробітник може скільки завгодно разів йти на лікарняний.

4. Між атрибутами співробітники і відпустка буде зв'язок 1: М, так як співробітник може скільки завгодно разів ходити у відпустку.

5. Між атрибутами співробітники та курси підвищення кваліфікації (переклад) буде зв'язок 1: М, так як співробітник може проходити курси підвищення кваліфікації скільки завгодно разів.

6. Між атрибутами співробітники і звільнення буде зв'язок 1:1, так співробітник може звільнитися тільки один раз.

7. Між атрибутами співробітники і табель робочого часу буде зв'язок 1:1, так як одному співробітнику відповідає тільки один запис кожного місяця у табелі.

4 Реляційна модель БД

Реляційна модель баз даних була запропонована співробітником фірми IBM Е. Кодом на початку 70-х років. Будучи математиком, він запропонував використовувати для обробки даних апарат теорії множин (об'єднання, перетин, різниця і Декартово твір). Він показав, що будь-яке представлення даних зводиться до сукупності двовимірних таблиць особливого виду, відомих в математиці як відношення.

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

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

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

Склад таблиць

Название

Тип данных

Тип поля

Тип

Фамилия

Текстовый

String

Имя

Текстовый

String

Отчество

Текстовый

String

Стаж работы

Счетчик

Number

Должность

Текстовый

String

Место жительства

Текстовый

String

ID

Счетчик

Ключевое

Number

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

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

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

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

Атрибут співробітники так само має унікальні поля, такі як номер паспорта та ІПН, але номер паспорта не може бути ключем, так як номер паспорта може мінятися, а ІПН може бути ключовим, але нам зручніше використовувати як ключ табельний номер.

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

Нормалізація відносин:

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

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

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

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

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

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

Складемо ER-діаграму, визначаючи типи атрибутів і зв'язки між сутностями. Всі сутності будуть залежними від сутності «Фізична особа». Зв'язки будуть типу «один-до-багатьох».

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

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

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

Метою створення фізичної моделі є забезпечення адміністратора відповідною інформацією для переносу логічної моделі даних у СКБД. Erwin підтримує автоматичну генерацію фізичної моделі даних для конкретної СКБД. При цьому логічна модель трансформується у фізичну за наступним принципом: сутності стають таблицями, атрибути стають стовпцями, а ключі стають індексами.

Різниця між моделями

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

Побудова фізичної моделі

Перейдемо до побудови фізичної моделі. Перед побудовою фізичної моделі необхідно вибрати тип бази даних у меню при створенні фізичної моделі. Виберемо в якості Database Oracle 11G. В отриманій моделі необхідно скорегувати типи й розміри полів. Крім того, на етапі створення фізичної моделі даних вводяться правила валідації колонок - списки, що визначають припустимі значення і значення за замовчуванням (закладка Oracle у атрибута).

Властивості колонок таблиць фізичної моделі БД працівників

Логічна назва

Фізична назва

Тип

Розмір

Правила валідації

Фамилия

Lastname

VARCHAR2

20

Имя

Firstname

VARCHAR2

15

Отчество

Thirtname

VARCHAR2

15

Должность

Doljnost

VARCHAR2

20

Стаж работы

Worktime

Number

2

>0

Место жительства

Adress

VARCHAR2

100

Після налаштування правил валідації (для цього спочатку треба дати ім'я Validation Name, а потім відредагувати Validation Rule) в діалоговому вікні Validation Rule Editor повинні вийти наступні правила.

Налаштування правил валідації

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

Встановлення правил валідації

Кінцева фізична модель

Фізична модель БД

Генерація моделі до СКБД

Таким чином, проробивши всі вищеописані дії, була одержана модель БД, яка є готовою до переміщення в СКБД. Для генерації коду створення БД необхідно вибрати пункт меню Tools/Forward Engineer/Schema Generation, після чого відкриється вікно налаштування властивостей схеми даних, що генерується.

Генерація моделі у СКБД

Для попереднього перегляду SQL-скрипта служить кнопка Preview.

Висновок

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

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

Використана література

1. Дейт, К.Дж. Введение в системы баз данных, 8-е издание.: Пер. с англ. /К.Дж. Дейт. - М.: Издательский дом «Вильямс», 2005. - 1328 с.: ил. - Парал. тит. англ.

2. Конноли Т. Базы данных: проектирование и сопровождение. Теория и практика. /Т. Конноли, К. Бегг, А. Страчан.

3. Луни К. Oracle Database 10G. Полный справочник в 2 томах. / К. Луни. - М.: Издательство «Лори», 2004.

4. Дорогий Я.Ю. Методична розробка до виконання лабораторної роботи «Створення застосувань в Oracle 11G XE» [Електронне видання]. / Я.Ю. Дорогий. - К.: ІССЗІ НТУУ «КПІ», 2012

база реляційний цілісність фізичний

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


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

  • Аналіз відомих підходів до проектування баз даних. Ієрархічна, мережева та реляційна моделі представлення даних, їх особливості. Концептуальне проектування: приклад документів, побудова ER-діаграми, модель "сутність-зв'язок". Побудова фізичної моделі.

    курсовая работа [541,5 K], добавлен 29.01.2013

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

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

  • Розробка бази даних в середовищі Microsoft SQL Server 2008 для обліку послуг фітнес-клубу. Таблиці для баз даних, їх властивості. Аналіз сукупності вхідних і вихідних параметрів, опис інформаційної бази, розробка логічної і фізичної моделі даних в ІС.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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