49738 (База даних "Телефонний довідник"), страница 3

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

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

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

Рисунок 1.15 – Бізнес-модель процесу створення логічної моделі БД

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

Основна мета вирішення цього завдання: перетворити логічну модель реляційної БД у послідовність команд SQL для створення об'єктів реляційної БД. Таким чином, розробник

БД відображає відношення логічної моделі реляційної БД (сутності ПО, подані в нормалізованій формі на ER-діаграмах) у таблиці й індекси реляційної БД.

Це завдання включає виконання ряду обов'язкових послідовних процедур:

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

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

· ухвалити рішення щодо засобів підтримки посилальної цілісності в БД. Якщо буде вирішено підтримувати посилальну цілісність на рівні команд SQL, то розробити специфікацію обмеження посилальної цілісності. Це завдання вирішується в чотири етапи: ідентифікувати первинні ключі кожної таблиці; побудувати індекси первинного ключа; визначити зовнішні ключі в дочірніх таблицях, якщо необхідно; побудувати команди SQL, які ідентифікують зовнішні ключі в дочірніх таблицях і правила підтримки посилальної цілісності; якщо необхідно, побудувати подання зовнішньої схеми БД.

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

Створення об'єктів для зберігання даних:

Створення таблиць:

Ідентифікування таблиці

Визначення типів даних колонок

Визначення первинного ключа

Додавання обмежень

Створення таблиць для взаємозв'язку "множина-до-множини"

Створення індексів

Створення подань

Створення інших об'єктів БД

Перевірка коректності створеної фізичної моделі

На рис. 1.16 нижче подана модель бізнес-процесу першої ітерації фізичної моделі БД.

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

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

Рисунок 1.16 – Декомпозиція етапу проектування - створення першої ітерації фізичної моделі БД: внутрішня схема

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

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

На цьому етапі проектування фізичної моделі розробник реляційної БД:

· виходячи з вимог до характеру обробки даних, визначає тип додатка БД;

· за наявними вимогами й описами виконує систематизацію й опис за можливістю всіх транзакцій;

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

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

· для кожної критичної транзакції необхідно оцінити кардинальність кожної колонки, задіяної у транзакції й, за можливістю, кардинальність вибірки;

· далі, розглядаючи в першу чергу критичні транзакції й таблиці, які в них беруть участь, розробник БД приймає суб'єктивні рішення по зміні структури таблиць внутрішньої схеми БД, виходячи з тих механізмів, які йому надає конкретна СКБД;

· по завершенні зміни структур таблиць розробник БД документує ці зміни, приводячи обґрунтування своїх рішень для адміністратора БД.

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

Побудова бізнес-моделі етапу проектування фізичної моделі реляційної БД: облік впливу транзакцій проходить у кілька таких етапів (рис. 1.17):

Визначення основного типу додатка БД;

Документування й опистранзакцій;

Визначення критичних транзакцій;

Для кожної критичної транзакції:

Визначення таблиць транзакції

Визначення способу підвищення продуктивності

Денормализація таблиці;

Розбиття таблиці;

Секціонування таблиці;

Кластерізація таблиці;

Побудова додаткових індексів;

Зміна структури внутрішньої схеми БД;

Документування змін;

Для кожної таблиці БД Вибір індексів:

Визначення транзакцій таблиці;

Визначення кардинальності таблиць;

Визначення кардинальності колонок;

Визначення індексів;

Зміна внутрішньої схеми;

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

Рисунок 1.17 – Декомпозиція етапу проектування - створення першої ітерації фізичної моделі БД: внутрішня схема

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

3. Постановка завдання

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

4. Загальний опис програми

Програмний продукт написаний в середовищі об'єктно орієнтованого програмування Microsoft Visual C# 2008 Exspress Edition.

Сама програма містить 3 основні форми:

MainForm.cs – головна форма програми. Зосереджено основний інтерфейс.

ItemForm.cs – форма вводу інформації про абонента записної книжки.

UserForm.cs – форма створення користувача БД(телефонного довідника). Інтерфейс захисту БД.

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

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

Також ми можемо заходити в БД під своїм логіном та паролем.

Висновок

В рамках даної курсової роботи було поставлено завдання розробити базу даних (БД),що дозволяє зберігати інформацію про абонентів(Ім’я, телефон, мобільний, адреса, email, дата рейестрації). База даних містить утримувати основні функції: додавання добавляти запису, видалення віддалення запису, редагування запису, пошук заданої інформації.

Було проведено ознайомлення з відповідною літературою по дисципліні «бази даних». Після цього була написана програма в середовищі об’єктно-орієнтованого програмування Microsoft Visual C# 2008 Express Edition.

Програмний продукт містить простий та інтуїтивно-зрозумілий інтерфейс. Після тестування програми можна зробити висновок, що вона коректно працює в середовищі Microsoft Windows XP SP3. Вона повністю відповідає вимогам, поставлених в даній курсовій роботі, належить до категорії Open Source, тобто має можливість бути змінена, вдосконалена за бажанням в подальшій розробці.

Додаток 1: Вихідний код програми

Головна форма:

using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Data;

using System.Drawing;

using System.Linq;

using System.Text;

using System.Windows.Forms;

using Phonebook.Classes;

using System.Diagnostics;

using System.IO;

using System.Xml.Linq;

using System.Globalization;

namespace Phonebook

{

public partial class MainForm: Form

{

float FontSize = 10.0f;

public MainForm()

{

InitializeComponent();

}

#region Buttons

void buttonNew_Click(object sender, EventArgs e)

{

try