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

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

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

Власне вони в перспективі будуть користувачами ІС та БД.

У процесі проектування БД, як і при проектуванні ІС, потрібно дотримуватися принципів системної єдності розвитку, сумісності, стандартизації. Завдання створення єдиної системи БД для великої установи неймовірно складе. Виняток становлять порівняно невелики підприємства і установи.

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

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

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

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

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

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

При відновленні форми в пакетної транзакции можливі три ситуації.

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

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

3) Скасування для всіх записів. Після внесення змін у кілька записів у меню Запису вибирається команда Скасувати всі записи. Mіcrosoft Access ігнорує всі зміни і повертає форму і дані до стану перед початком пакетної транзакции. Ніякі зміни на сервер не надходять.

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

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

2.1.1 Інформаційне дослідження предметної області

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

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

2.1.2 Розробка інфологічної моделі предметної області

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

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

БД у вигляді локальних ER-діаграм і побудови глобальної інформаційної моделі - глобальної ER-діаграми.

Локальні інформаційні структури відповідають локальним задачам.

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

Розробляємо тільки в одному Загальному представленні на базі ER-моделі (модель „сутність-зв'язок”). В зв'язку з тим, що предметна область не складна - виділяємо тільки одне локальне уявлення.

1. Формуємо сутності (об'єкти ПС)

1) Начальник кафедри

2) Лабораторія

3) Співробітники лабораторії

4) Майно

5) Технічне обслуговування

2. Формуємо атрибути сутностей

Аналізуємо зв'язки між сутностіми.

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

1. Аналізуємо зв'язки між сутностями

Рис.4.

Складемо схему інфологічної моделі ПО

Рис.5.

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

1. В таблиці відсутні рядки з однаковими значеннями.

2. Відношення має домени, або стовпці, значення яких відповідає атрибутам, або назвам стовпців.

3. Кожний атрибут має унікальне і'мя

4. Порядок слідування рядків в таблиці довільний.

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

Існують 3 типи засобів маніпуляції даними:

1 тип - реляційна алгебра,

2 тип - реляційне зчислення зі змінними кортежами

3 тип - реляційне зчислення зі змінними доменами.

Операції реляційної алгебри ми розглянемо пізніше на прикладі нашої бази даних.

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

2.2.1 Вибір типу моделі даних

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

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

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

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

Композиційна схема - це проміжний елемент при переході від інфологічної схеми до логічної схеми бази данних.

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

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

Рис.6.

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

Рис.7.

Перевіримо побудовану композиційну схему на відсутність протирічь (рис.8)

Рис.8.

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

2.2.3 Розробка логічної схеми бази даних

Логічне проектування - це розробка логічної структури системи баз даних. Відстранив всі логічні і тімчасові протиріччя, ми отримали логічну схему бази даних „Кафедра” (рис.9).

Страницы: 1, 2, 3, 4