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

Курсовой проект - Компьютеры, программирование

Другие курсовые по предмету Компьютеры, программирование

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

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 тип реляц?/p>