49802 (Проектування каталогу мобільних телефонів у Access), страница 2

2. Концептуальний (інфологічний) рівень проектування

На концептуальному (інфологічному) рівні проектування структура бази даних відображається у виді ER-діаграми (Entry - сутність, Relatіonshіp - зв'язок). Проектування бази даних вимагає виділення всіх об'єктів, указівки їхніх властивостей і встановлення зв'язків між ними.

У даному випадку до об'єктів відносяться: Телефони із властивостями: Код, Фірма, Ціна, Вага і т.д.

Зв'язки відбивають істотні взаємини між об'єктами. Крім того, на ER-діаграмі зазначені ступені зв'язку між об'єктами, що показують, як саме зв'язані об'єкти між собою [1].

Ступені зв'язку бувають двох типів - "багато" і "один". Вони позначаються латинською буквою M для зв'язку "багато" і 1 для зв'язку "один".

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

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

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

2.2 Нормалізація форми ER-діаграми

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

- відновлення;

- видалення;

- уведення.

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

Поняття нормалізації відноситься як до ER-діаграм, так і до таблиць реляційних баз даних.

Процес нормалізації складається з декількох етапів, на кожнім з яких визначаються так називані нормальні форми: 1NF, 2NF, 3NF, BCNF (Бойса Кодда), 4NF, 5NF(форма проекції з'єднань) - PJ/NF. У більшості проектів третя нормальна форма завершує процес нормалізації.

Стосовно до ER-діаграм можна сформулювати наступні визначення нормалізації форм:

1NF - усунуті повторювані атрибути або групи атрибутів, виявлені неявні сутності.

2NF - усунуті атрибути, що залежать тільки від частини унікального складеного ключа. Ця частина визначає окрему сутність.

3NF - усунуті атрибути, що залежать від атрибутів, що не входять в унікальний ключ.

Дана ER-діаграма знаходиться в 3NF, тому що сутності не мають властивостей, що залежать від неключових властивостей [1]. У ER-діаграмі усунуті надмірність і недоцільність використання інформації в сутності "Телефон".

3.Даталогичне проектування бази даних

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

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

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

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

Після нормалізації таблиць і встановлення зв'язків між ними можна говорити про створення бази даних [1].

Реляційна схема даної бази містить 7 таблиць:

- таблиця "Телефоны" є головною таблицею

- таблиця "Фирма" Містить найменування фірм виробників

- таблиця "Тип телефона" містить тип телефону

- таблиця "Разрешение" містить роздільну здатність дисплея телефону

- таблиця "Материал" містить дані про матеріал з якого зроблено телефон

- таблиця "Дисплей тип" містить дані про технологію створення дисплею

- таблиця "Камера" містить інформацію про камеру телефона

Розглянемо, чому дана реляційна схема відноситься до 3NF:

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

2) Первинні ключі таблиць однозначно визначають запис і не надлишкові.

3) Значення кожного полю не входить у первинний ключ, не залежить від значення іншого полючи також не вхідного в первинний ключ.

4.Фізичне проектування інформаційних систем

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

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

Стадія фізичного проектування БД включає:

1) вибір способу організації БД;

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

3) опис відображення концептуальної схеми БД у внутрішній структурі керування файлами.

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

- вибір СУБД;

- відновлення структури таблиць;

- призначення типів полів для розподілу атрибутів сутностей;

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

4.1 СУБД Access

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

За допомогою Access звичайні користувачі одержали зручний засіб для створення й експлуатації досить могутніх баз даних без необхідності що-небудь програмувати. При бажанні систему можна розвивати і набудовувати власними силами. Для цього треба опанувати основами програмування мовою Vіsual Basіc.

Ще одним додатковим достоїнством Access є интегрированность цієї програми з Excel, Word і іншими програмами пакета Offіce.

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

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

У Mіcrosoft Access для обробки даних ваших таблиць використовується могутня мова SQL (Structured Query Language - Структурована мова запитів). Використовуючи, ви можете виділити з однієї або декількох таблиць необхідну для рішення конкретної задачі інформацію. Access значно спрощує задачу обробки даних. Щоб змусити Mіcrosoft Access вирішувати ваші задачі, вам зовсім не потрібно знати мова SQL. При будь-якій обробці даних з декількох таблиць використовує один раз задані вами зв'язку між таблицями. Ви можете сконцентрувати свої зусилля на рішенні інформаційних проблем, не затрачаючи сил на побудову складної системи, що відслідковує у вашій базі всі зв'язки між структурами даних [4]. У Mіcrosoft Access мається також простої й у той же час багате можливостями засіб графічного завдання запиту - так називаний "запит за зразком" (QBE, query by example), що використовується для завдання даних, необхідних для рішення деякої задачі. Використовуючи для виділення і переміщення елементів на екрані стандартні прийоми роботи з мишею в Wіndows і кілька клавіш на клавіатурі, можна буквально за секунди побудувати досить складний запит.

4.2 Об'єкти Access

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

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

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

Звіти призначені для формування вихідного документа, призначеного для висновку на печатку.

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

М одулі містять програми мовою Vіsual Basіc, що можуть розроблятися користувачем для реалізації нестандартних процедур при створення додатка [4]

4.3 Таблиці

Мал.4.3.2 Таблиця «Фірма»

Мал.4.3.3 Таблиця «Тип телефону»

Мал.4.3.4 Таблиця «Матеріал»

Мал.4.3.5 Таблиця «Дисплей тип»

Мал.4.3.6 Таблица «Роздільна здатність»

Мал.4.3.7 Таблиця «Камера»

Наступний етап проектування - визначення доменов (типів даних) таблиць, що зберігаються в стовпцях. Розглянемо таблицю "Клієнт". Щоб створити таблицю з полями потрібно:

1. Перейти на влакдку "Таблиці".