• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Тлумачний словник
Авто
Автоматизація
Архітектура
Астрономія
Аудит
Біологія
Будівництво
Бухгалтерія
Винахідництво
Виробництво
Військова справа
Генетика
Географія
Геологія
Господарство
Держава
Дім
Екологія
Економетрика
Економіка
Електроніка
Журналістика та ЗМІ
Зв'язок
Іноземні мови
Інформатика
Історія
Комп'ютери
Креслення
Кулінарія
Культура
Лексикологія
Література
Логіка
Маркетинг
Математика
Машинобудування
Медицина
Менеджмент
Метали і Зварювання
Механіка
Мистецтво
Музика
Населення
Освіта
Охорона безпеки життя
Охорона Праці
Педагогіка
Політика
Право
Програмування
Промисловість
Психологія
Радіо
Регилия
Соціологія
Спорт
Стандартизація
Технології
Торгівля
Туризм
Фізика
Фізіологія
Філософія
Фінанси
Хімія
Юриспунденкция

Принципи та етапи проектування бази даних

Таблиця 1

Для кожної таблиці можна створити декілька індексів. Індекси дозволяють впорядковувати записи, виконувати швидкий пошук потрібних даних та встановлювати зв’язки між таблицями. Поля, які використовуються в індексах, називаються ключами записів. Ключ може бути простим та складеним. Простий ключ містить ім’я одного поля, а складений може містити декілька полів. Первинний ключ (Primary key) повинен однозначно ідентифікувати запис, тобто він може приймати тільки унікальне значення, наприклад, поле «номер замовника».

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

Таблиця 2

З табл. 2 бачимо, що замовник з номером 123 (Ткаченко) замовив товари 25 та 28. У табл. 1 первинним ключем є поле «Номер замовника», в табл. 2 первинним ключем є номер замовлення, а поле «номер замовника» в табл. 2 встановлює відношення (зв’язок) між таблицями і являє собою зовнішній ключ, тому що він посилається на первинний ключ «зовнішньої» таблиці «Замов­ники». Такий тип відношення має назву «one-to-many» (один-до-багатьох), тому що один замовник може розміщати багато замовлень, але окреме замовлення може бути розміщене тільки одним замовником. Ще існують відношення «one-to-one» (один-до-од­ного) та «many-to-many» (багато-до-багатьох). Відношення «one-to-one» (одному запису в першій таблиці відповідає один запис
у другій таблиці) у реляційній моделі застосовується дуже рід-
ко, тому що такі дві таблиці можна з’єднати в одну. Відношен-
ня «many-to-many» використовується, якщо одному запису першої таблиці відповідає декілька записів другої таблиці та одно-
му запису другої таблиці відповідає декілька записів першої
таблиці.

Реляційна модель базується на понятті теоретико-множинного відношення, яке являє собою підмножину декартового добутку списку доменів. Домен — це множина значень. Наприклад, величини, які присутні у стовпчиках НОМЕР ЗАМОВНИКА табл. 1 та табл. 2, вибрані з основного домену всіх можливих номерів замовника. Декартовим добутком доменів D1, D2, … , Dn (позначається як D1 ´ D2 ´ … ´ Dn) називається множина всіх кортежів (V1, V2, … , Vn) довжини n, таких, що V1 належить D1, V2 належить D2, … , Vn належить Dn, тощо. Наприклад, якщо n=2, D1={0,1} та D2={r,f}, тоді D1 ´ D2 є {(0,r), (0,f), (1,r), (1,f)} .

Відношення — підмножина декартового добутку одного або більше доменів. Наприклад, {(0,r), (0,f), (1,r), (1,f)} є відношення визначеної раніше підмножини D1 ´ D2. Величина n являє собою ступінь відношення. Так, для відношення ЗАМОВНИКИ ступінь має значення 5.

Елементи відношення називаються кортежами. Кожний кортеж містить n компонентів.

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

Список імен атрибутів відношення зветься схемою відношення. Наприклад, відношення має назву ЗАМОВНИКИ. Його схема буде мати такий вигляд:

DOMAIN НОМЕР ЗАМОВНИКА NUMERIC (4)

DOMAIN ПРІЗВИЩЕ CHARACTER (20)

DOMAIN ІМ’Я CHARACTER (15)

DOMAIN НОМЕР РАХУНКА NUMERIC (10)

DOMAIN АДРЕСА CHARACTER (50)

RELATION ЗАМОВНИКИ (НОМ DOMAIN НОМЕР ЗАМОВНИКА)

ПРІЗВ DOMAIN ПРІЗВИЩЕ

NAME DOMAIN ІМ’Я

РАХ DOMAIN НОМЕР РАХУНКА

АДР DOMAIN АДРЕСА

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

Таким чином, у табл. 1 зображено відношення ЗАМОВНИКИ ступеня 5, яке визначено на доменах НОМЕР ЗАМОВНИКА, ПРІЗВИЩЕ, ІМ’Я, НОМЕР РАХУНКА, АДРЕСА. У табл. 3 показаний декартовий добуток двох множин ЗАМОВНИКИ (120, 123, 178) та КОД ТОВАРУ (25, 28).

Таблиця 3

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

1. З’єднання.З’єднання відношень R1 та R2 є множиною кортежів R3, котрі належать R1 або R2, або їм обом. Ця операція застосовується тільки до відношень, які мають однакові стовпчики. Наприклад, відношення R1 містить працівників механічного цеху, а відношення R2 — збирального цеху. Якщо відношення R3 з’єднання R1 та R2, тоді воно буде містити працівників з обох цехів.

2. Різниця.Різницею відношень R1 та R2 є множина кортежів, що належать R1, але не належать R2. Ця операція теж застосовується тільки до відношень, які мають однакові стовпчики. Наприклад, відношення R1 містить усіх працівників, а відношення R2 — тільки працівників механічного цеху. Відношення R3, якщо воно є різницею відношень R1 та R2, буде містити всіх працівників, окрім працівників механічного цеху.

3. Декартовий добуток.Якщо відношення R1 та R2 мають ступінь n1 та n2 відповідно, тоді декартовим добутком R1 ´ R2 називається множина кортежів довжини n1 + n2, перші n1 компонентів яких — це кортежі відношення R1, а останні n2 — кортежі відношення R2. Фактично ця операція повертає відношення, кортежі якого — це всі можливі комбінації рядків початкових таблиць. Якщо кількість кортежів відношення R1 — N, а відношення R2 — M, тоді результатом операції буде відношення, яке складається з N*M кортежів.

4. Проекція.Сутність цієї операції полягає у тому, що з заданого відношення R вилучаються деякі з його компонентів або (та) переупорядковуються ті, що залишилися. Наприклад, проекцією відношення ЗАМОВНИКИ може бути відношення із атрибутами: НОМЕР ЗАМОВНИКА, АДРЕСА.

5. Перехрестя.Перехрестям двох відношень R1 та R2 називається множина всіх кортежів t, що належать як R1, так і R2. Відношення R1 та R2 повинні мати однакову ступінь n та j-й атрибут одного з них повинен бути з того ж самого домену, що і j-й атрибут другого. Наприклад, відношення R1 містить працівників усього підприємства, а R2 — працівників механічного цеху. Відношення R3, яке є перехрестям відношень R1 та R2, буде містити працівників лише механічного цеху.

6. Селекція.Ця операція повертає відношення R2, котре містить ті самі атрибути, що і задане відношення R1, та частину кортежів R1. Значення певних атрибутів цих кортежів відповідають деяким умовам. Наприклад, однією з можливих рестрикцій відношення ЗАМОВНИКИ може стати відношення замовників, котрі проживають у Києві та мають ім’я Віктор.

Можна виділити такі переваги реляційної моделі даних:

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

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

· незалежність даних. Під час використання реляційної моделі інтерфейс користувача не пов’язаний з фізичною структурою даних та доступом до них;

· теоретичне обґрунтування. Під час проектування бази даних застосовуються методи, які побудовані на нормалізації відношень. Нормалізація — це структурування даних таким чином, щоб уникнути непотрібного дублювання даних та забезпечити швидкий шлях пошуку необхідних даних.

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

· база даних повинна задовольняти актуальним інформаційним потребам;

· дані перед включенням до бази даних повинні перевірятися на достовірність;

· доступ до даних повинні мати тільки особи з відповідними повноваженнями;

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

Етапи проектування бази даних:

1. Визначення мети створення бази даних.

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

3. Проектування зовнішніх моделей даних.

4. Проектування внутрішньої моделі даних.

5. Оцінка внутрішньої моделі даних.

6. Реалізація бази даних.

7. Аналіз ефективності бази даних.

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

Читайте також:

1. Active-HDL як сучасна система автоматизованого проектування ВІС.
2. III. Етапи розробки програмного забезпечення
3. VII. Етап проектування
4. VII. Етап проектування
5. Автоматизація проектування напівзамовлених ВІС.
6. Аграрна політика як складова економічної політики держави. Сут­ність і принципи аграрної політики
7. Аналіз паралельного інтерейсу з DSP-процесорами: запис даних в ЦАП, що під’єднаний до адресного простору пам’яті
8. Аналіз паралельного інтерфейсу з DSP-процесорами: читання даних з АЦП, що під’єднаний до адресного простору пам’яті
9. Аналіз статистичних даних про склад та плинність кадрів, які обіймали керівні
10. Аналіз та інтерпретація одержаних даних
11. Антикорупційні принципи
12. Архіватори даних.

Переглядів: 1583