РОЗРОБКА БАЗИ ДАНИХ

Ремонт конденсаторів, вакуумної системи і ежекторів.

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

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

Нові конденсаторні трубки проходять огляд і перевірку їх сертифікатів. Трубки, що мають явні дефекти у вигляді пробоїн, вм'ятин і тріщин, при огляді відбраковуються.

В якості матеріалу для трубок заводи застосовують латунь і мідно-нікелеві сплави, що володіють високою корозійною стійкістю. Трубки з такого сплаву, що пройшли низькотемпературний відпал при температурі до 500 ° С, поставляються на станції.

Латунні трубки, в яких після технологічного процесу їх виготовлення

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

Низькотемпературний відпал латунних трубок здійснюється в спеціальних печах (рис.1), куди подається редукований пар тиском 0,1-0,15 МПа і температурою 400-450 ° С. Нагрівання трубок може проводитись і іншим способом, наприклад індукційним.

Рис.1. Піч для відпалу конденсаторних трубок:

1-труба підводу пара; 2-манометр; 3-термопара; 4-знімна камера; 5-вхідна камера; 6-конденсаторні трубки; 7-корпус; 8-відвід пара; 9-вихідна камера; 10-гідрозатвор для відведення конденсата; 11-термопара; 12- отвори в опорних кільцях для дренування конденсата.

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

Після видалення старих трубок проводиться зачистка отворів в основних трубних дошках і проміжних опорних перегородках за допомогою пристроїв, які складаються з оправки і набором сталевих йоржів, виготовлених з дротиків діаметром 0,2-0,5 мм (рис. 2, а). В якості приводу використовуються електрозварювальні або пневматичні машинки.

Рис. 2. Пристосування для зачистки:

а- для зовнішньої зачистки кінців трубок: 1-шпиндель електроприводу; 2-оправка; 3- стакан; 4- волок; 5-шліфпорошок; б-для зачистки отворів в трубних дошках: 1- хвостовик; 2- йорж із сталевого дроту; 3- оправка; 4- натискний гвинт

До установки нових трубок перевіряється взаємне розташування отворів в трубних дошках і проміжних опорних перегородках.

Перевірка виконується за допомогою натягнутої сталевої струни (рис.3).

Рис. 3. Перевірка взаємного розташування отворів в трубних дошках і проміжних перегородках: 1-підкладка; 2- сталевий стержень; 3- трубна дошка; 4- сталева струна; 5- вантаж; 6-проміжні перегородки.

Після зачистки підготовка отворів в трубних дошках під установку нових трубок полягає у вибірковій перевірці їх діаметрів за допомогою калібрів. Оскільки зазор між вставленою незавальцьованною трубкою і отвором повинен становити 0,4 мм, а допуск на отвір - від +0,12 до -0,05 мм, значення діаметрів калібрів повинні складати: d_к^макс = (d_тр + 0,04) + 0,12 ;

d_к^мин =(d_тр + 0,4)-0,05. Наприклад, для отворів під трубки номінальним діаметром 25 мм діаметри калібрів повинні бути відповідно 25,62 і 25,35 мм.

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

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

Рис. 4. Пристосування для обрізки виступаючих кінців трубок після вальцювання: 1- втулка упорна; 2- корпус; 3- шарикопідшипник радіальний; 4-накінечник; 5- трубна дошка; 6- різець; 7- трубка.

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

Рис. 5. Вальцювання трубок в трубних дошках: а- вальцівка: 1- гайка; 2- корпус; 3- ролик; 4- корпус вальцівки; б-схема вальцювального з'єднання.

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

Основним показником якості з'єднання є ступінь вальцювання:

p=(∆d-s) /d₀ (1)

де ∆d=d₂-d₁- збільшення внутрішнього діаметра трубки в результаті вальцювання, мм; d₁, d₂-внутрішні діаметри трубки відповідно до і після вальцювання, мм;

d₀-діаметр отвору в трубній дошці до вальцювання, мм; s = d₀-d_н-різниця між діаметром отвору і зовнішнім діаметром трубки до вальцювання (рис. 5, б).

Оптимальні, результати вальцювання забезпечуються при р = 0,1 ÷ 0,6, при цьому подовження кінців труб Δl = 0,4 ÷ 0,6 мм. Значення р встановлюється за глибиною заходу конуса в вальцювання, мм, яка підраховується за формулою

h=(p + s)∙ k, (2)

де k- коефіцієнт зворотного конусности вальцювання.

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

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

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

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

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

Визначення місць нещільності в конденсатних насосах турбінної установки здійснюється опресуванням від сусідніх насосів через спеціально встановлені байпаси, які встановлюють на зворотних клапанах з напірної сторони насосів. Опресування проводиться на зупиненому насосі при відкритому вентилі байпаса до створення тиску в насосі 0,1-0,2 Мпа (1-2 кгс / см²). Необхідний тиск встановлюється прикриттям засувки на вхідній стороні насоса.

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

Рис. 6. Ущільнення штока вакуумної арматури: 1- гумове кільце; 2- тарілка засувки; 3- корпус засувки; 4- сальник; 5- шток.

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

ВСТУП

Ефективність роботи будь-якого підприємства залежить від систем обробки інформації. Така система повинна:

- забезпечувати отримання загальних та/або деталізованих звітів за підсумками роботи;

- дозволяти легко визначати тенденції зміни найважливіших показників ;

- забезпечувати отримання інформації, критичної за часом, без істотних затримок;

- виконувати точний і повний аналіз даних.

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

Для взаємодії з користувачами використовуються системи управління базами даних ( СКБД) . Однією з таких СУБД є Microsoft Visual FoxPro 9.0 . Visual FoxPro відрізняється високою швидкістю, має вбудований об'єктно-орієнтована мова програмування з використанням xBase і SQL, діалекти яких вбудовані в багато СУБД. Має високий рівень об'єктної моделі. Visual FoxPro 9.0 є об'єктно - орієнтованим , візуально програмованим мовою, керованим по подіях і повною мірою відповідає новим вимогам, що пред'являються до сучасних засобів проектування.

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

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

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

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

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

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

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

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

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

Загальні відомості: Розробка системи для обробки інформації про відділ кадрів . Повне найменування: Автоматизації відділу кадрів.

Призначення системи: Автоматизації відділу кадрів.

Об'єктом автоматизації є кадрова служба.

Характеристики об'єктів: анкетні дані про співробітників, дані про діяльність співробітників, адреси співробітників, склад сім'ї співробітників.

Вимога до складу технічних засобів: наявність персонального комп'ютера з встановленою програмою Visual FoxPro 9.0. Комп'ютер користувача повинен мати такими мінімальними характеристиками: операційна система Microsoft Windows 98, 2000, ME, XP, Vista; Процесор Pentium 344 Мгц; Миша; Клавіатура; 128 Мбайта оперативної пам'яті (ОЗУ); монітор; 350 Мбайт на жорсткому диску; Відеокарта.

Завдання для виконання курсової роботи має наступний зміст:

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

1. Зчитування інформації про вміст записів в таблиці бази даних.

2. Здатність додавати нові записи в таблицю бази даних.

3. Здатність видаляти зайві записи з таблиці бази даних.

4. Здатність пошуку даних з таблиці бази даних.

5. Виведення інформації про результати пошуку.

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

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

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

Виділяють наступні завдання кадрової служби:

- комплектування організації керівними працівниками та спеціалістами

робітниками відповідних профілю підприємства специ альностей , професії , кваліфікації ;

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

- забезпечення підвищення кваліфікації персоналу;

- облік особового складу.

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

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

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

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

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

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

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

Вхідний інформацією для рішення даної задачі є наступні дані:

1. Анкетні дані про співробітників;

2. Дані про діяльність співробітників;

3. Адреси співробітників;

4. Склад сім'ї співробітників.

Вихідними даними: звіти і запити.

РОЗРОБКА БАЗИ ДАНИХ

2.1.1 Інфологічне проектування БД

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

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

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

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

Вимоги до інфологічній моделі:

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

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

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

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

2.1.2 Виявлення сутності та зв'язків

Аналізуючи предметну область , можна виділити наступні сутності :

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

Склад атрибутів і їх опис для сутності «Анкетні дані про співробітників» представлені в таблиці 1.

Таблиця 1 - Атрибути сутності «Анкетні дані про співробітників»

У таблицях 2, 3, 4 представлені атрибути сутностей «Дані про діяльність співробітника», «Адреса співробітника», «Склад сім'ї співробітника» відповідно.

Таблиця 2 - Атрибути сутності «Дані про діяльність співробітника»

Таблиця 3 - Атрибути сутності «Адреса співробітника»

Таблиця 4 - Атрибути сутності «Склад сім'ї співробітника»

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

Таблиця 5 - Склад бази даних інформаційної системи.

Таблиця 6 - Зв'язки між об'єктами бази даних інформаційної системи

2.1.3 Побудова Er-діаграми

Для створення концептуальної моделі виконуються в CASE-засобі методології IDEF1Х за допомогою Erwin. CASE-засіб Erwin підтримує методологію IDEF1Х і стандарт IE ( Information engineering ) .

Переваги від використання CASE -засоби Erwin :

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

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

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

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

Методологія IDEF1Х підрозділяється на рівні, відповідні проектованої моделі даних системи. Кожен такий рівень відповідає певній фазі проекту. Такий підхід корисний при створенні систем за принципом «зверху вниз».

Три рівня моделей, що поєднують у собі логічні моделі , складаються з Entity Relationship Diagram (Діаграма сутність-зв'язок), Key-Based (Модель даних заснована на ключах) Model і Fully Attributed model (Повна атрибутивна модель).

Діаграма сутність-зв'язок

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

Модель даних, заснована на ключах

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

Повна атрибутивна модель

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

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

Найважливіша мета проектування інформаційної моделі-визначення непротиречивої структурованої інтерпретації реально існуючої інформації предметної області та взаємодії між її структурними компонентами. Один з підходів до семантичного моделювання даних – це концепція "сутність-зв’язок" (Entity-Relationship). Після визначення сутностей та зв’язків потрібно визначити ключові атрибути і в підсумку побудувати інфологічну модель за схемою «сутності-зв’язки».

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

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

При створенні концептуальної моделі були визначені сутності й атрибути сутностей. Була виділена одна основна сутність. З цих даних складена логічна модель бази даних представлена ​​на малюнку 1.

Рисунок 2.1 Логическая модель БД информационной системы для автоматизации отдела кадров

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

При створенні сутності необхідно виділити атрибути, які можуть стати первинним ключем (потенційні ключі), потім провести відбір атрибутів, слідуючи наступних рекомендацій:

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

2. Ніякої з атрибутів первинного ключа не повинен мати нульове значення.

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

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

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

Потенційний ключ, який не став первинним називається альтернативним ключем ( Alternate key ). Erwin може виділяти атрибути альтернативних ключів. Надалі, за замовчуванням генерується унікальний індекс. Коли створюється альтернативний ключ , на діаграмі поряд з атрибутом з'являється символ (АК) . У моїй базі даних альтернативних ключів не було.

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

2.2 Даталогічне проектування

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

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

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

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

На наступному етапі побудови логічної моделі визначаємо ключові атрибути і типи атрибутів. Типи атрибутів представлені в табліце_7.

Таблиця 7 - Типи атрибутів

Далі проводимо нормалізацію бази даних.

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

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

Функціональна залежність

Атрибут По суті Е функціонально залежить від атрибуту А сутності Е, якщо і тільки якщо кожне значення А в Е зв'язало з ним точно одне значення У в E. Іншими словами, А однозначно визначає В.

Повна функціональна залежність

Атрибут Е сутності В повністю функціонально залежить від ряду атрибутів А сутності Е, якщо і тільки якщо В функціонально залежить від А і не залежить ні від якого підряду А.

Існують наступні види нормальних форм :

• Перша нормальна форма ( 1NF ). Сутність Е знаходиться в першій нормальній формі , якщо і тільки якщо всі атрибути містять тільки атомарні значення. Серед атрибутів не повинно зустрічатися повторюваних груп , тобто декількох значень для кожного екземпляра.

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

• Третя нормальна форма ( 3NF ). Сутність Е знаходиться в третій нормальній формі, якщо вона знаходиться в другій нормальній формі, і не ключові атрибути сутності Е залежать від інших атрибутів Е.

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

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

У моделі кожна сутність або атрибут ідентифікується за допомогою імені. У Erwin підтримує коректність імен наступним чином:

• зазначає повторне використання імені суті і атрибута ;

• не дозволяє внести в сутність більше одного зовнішнього ключа;

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

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

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

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

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

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

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

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

Фізична модель даних повинна відповідати вимогам, що пред'являються до проектованої системи ;

Вибір певної фізичної моделі повинна бути аргументована;

Повинні бути визначені можливості нарощування існуючої структури зберігання , а також виявлено її обмеження. [ 3 ]

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

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

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

Таблиця 8 - Зіставлення компонентів логічної і фізичної моделі.

В отриманій моделі ще необхідно скорегувати типи і розміри полів.

Таблиця 9 - Властивості колонок таблиць фізичної моделі.

Таким чином, виконавши всі вищеописані дії, ми отримали модель БД, готову для приміщення в СУБД. Для генерації коду створення БД необхідно вибрати пункт меню Tools -> Forward Engineer / Scheme Generation, після чого відкриється вікно установки властивостей генерується схеми даних. Для генерації схеми служить кнопка Generate. У процесі генерації Erwin зв'язується з БД, виконуючи SQL-скрипт. Якщо в процесі генерації виникають які-небудь помилки, то вона припиняється, відкривається вікно з повідомленнями про помилки.

У підсумку отримаємо фізичну модель , яка автоматично згенерували в Erwin (рис 2 ) .

Рис. 2 - Фізична модель бази даних.

3 РОЗРОБКА КЛІЄНТСЬКОЇ ЧАСТИНИ БАЗИ ДАНИХ

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

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

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

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