База даних "Телефонний довідник" (стр. 4 из 7)
У результаті вирішення даного завдання робиться важливий вивід про правильність отриманої першої ітерації фізичної моделі БД, здійснюється документування фізичної моделі даних у вигляді скріпту, береться рішення про характер подальшої розробки фізичної моделі даних. Зі вказаної в попередніх розділах лекції зрозумілий такий алгоритм дій:
Створення об'єктів для зберігання даних:
Створення таблиць:
Ідентифікування таблиці
Визначення типів даних колонок
Визначення первинного ключа
Додавання обмежень
Створення таблиць для взаємозв'язку "множина-до-множини"
Створення індексів
Створення подань
Створення інших об'єктів БД
Перевірка коректності створеної фізичної моделі
На рис. 1.16 нижче подана модель бізнес-процесу першої ітерації фізичної моделі БД.
Головна мета етапу - створити послідовність команд SQL для створення об'єктів зберігання даних. Також можна створювати інші об'єкти, такі як синоніми, подання й індекси. Можна ухвалити рішення щодо підтримки посилальної цілісності БД програмними механізмами СКБД і створити відповідний набір команд SQL.
Бізнес-модель етапу проектування - створення фізичної моделі реляційної БД: облік впливу транзакцій. Вирішуючи професійне завдання створення фізичної моделі даних - облік впливу транзакцій, - розробник реляційної прагне створити таку фізичну модель даних, яка б, на його думку, давала найбільшу продуктивність обробки запитів БД. На практиці, особливо при створенні й розробці нових БД, таке завдання навряд чи може бути вирішене повністю. Ясно, що для його вирішення необхідно мати перелік всіх запитів до БД, їхній частоті й обсязі вибірок по кожному, що в принципі неможливо.
Рисунок 1.16 – Декомпозиція етапу проектування - створення першої ітерації фізичної моделі БД: внутрішня схема
Тому розробники БД на основі аналізу вихідної документації й опитувань потенційних користувачів намагаються систематизувати транзакції до БД, оцінити кардинальність таблиць у цілому й окремих колонках зокрема. На основі таких оцінок розробник БД намагається визначити критичні транзакції й налаштувати структури таблиць, задіяних у таких транзакціях, на досягнення максимальної продуктивності. При цьому він висуває гіпотези про застосовність того або іншого засобу підвищення продуктивності обробки запитів й перевіряє їх. Далі ухвалюється рішення щодо застосування найбільш підходящого.
Слід розуміти, що завдання забезпечення високої продуктивності БД - це завдання, яке постійно вирішує адміністратор БД у процесі її експлуатації. На цьому етапі проектування БД розробник, у міру можливості, готовить успішне вирішення цього завдання. Цей етап є дуже відповідальним у фізичному проектуванні БД, тому варто дотримувати при вирішенні цього завдання розумного прагматизму і документувати свої рішення. Повинне діяти емпіричне правило: якщо розробник БД не має досить даних для надійного вирішення завдання підвищення продуктивності БД, то рішення цього завдання повинне бути передане адміністраторові БД.
На цьому етапі проектування фізичної моделі розробник реляційної БД:
· виходячи з вимог до характеру обробки даних, визначає тип додатка БД;
· за наявними вимогами й описами виконує систематизацію й опис за можливістю всіх транзакцій;
· відштовхуючись від вихідної документації, визначає можливі розміри таблиць, а якщо це неможливо, робить припущення про їхній можливий розмір;
· виходячи з фактичних розмірів таблиць і вимог до продуктивності виконання транзакцій, визначає критичні транзакції;
· для кожної критичної транзакції необхідно оцінити кардинальність кожної колонки, задіяної у транзакції й, за можливістю, кардинальність вибірки;
· далі, розглядаючи в першу чергу критичні транзакції й таблиці, які в них беруть участь, розробник БД приймає суб'єктивні рішення по зміні структури таблиць внутрішньої схеми БД, виходячи з тих механізмів, які йому надає конкретна СКБД;
· по завершенні зміни структур таблиць розробник БД документує ці зміни, приводячи обґрунтування своїх рішень для адміністратора БД.
У результаті розробник БД створює фізичну модель БД, що враховує характер обробки даних у БД, виражений через облік впливу транзакцій.
Побудова бізнес-моделі етапу проектування фізичної моделі реляційної БД: облік впливу транзакцій проходить у кілька таких етапів (рис. 1.17):
Визначення основного типу додатка БД;
Документування й опистранзакцій;
Визначення критичних транзакцій;
Для кожної критичної транзакції:
Визначення таблиць транзакції
Визначення способу підвищення продуктивності
Денормализація таблиці;
Розбиття таблиці;
Секціонування таблиці;
Кластерізація таблиці;
Побудова додаткових індексів;
Зміна структури внутрішньої схеми БД;
Документування змін;
Для кожної таблиці БД Вибір індексів:
Визначення транзакцій таблиці;
Визначення кардинальності таблиць;
Визначення кардинальності колонок;
Визначення індексів;
Зміна внутрішньої схеми;
Короткий розгляд завдань створення серверного коду й підготовки скріпту Професійне завдання проектування БД - розроблення серверного коду БД - виникають, як правило, в обчислювальному середовищі з багатьма користувачами. У цих системах користувачі спільно використовують обчислювальні ресурси, зокрема ресурси дискової пам'яті й оперативної пам'яті процесора. Обчислювальні ресурси можуть бути сконцентровані в одному місці (централізовані обчислення) або бути розосередженими в різних вузлах, об'єднаних у комп'ютерну мережу (розподілені обчислення). СКБД у кожному разі покликана координувати й здійснювати доступ користувачів до баз даних та їхніх об'єктів.
Рисунок 1.17 – Декомпозиція етапу проектування - створення першої ітерації фізичної моделі БД: внутрішня схема
Більшість сучасних СКБД підтримують концепцію клієнт-серверної технології для розподілених обчислень. Це означає, що існують концентратори обчислень (названі серверами), на яких виконується найбільший обсяг обчислень із даними (сервери БД), і машини користувачів (клієнти), на яких виконуються додатки користувачів. Додатки формують запити у формі команд SQL до БД, відправляють їхнім серверам БД, одержують запитувані дані й обробляють їх.
Написати базу даних (БД), що дозволяє накопичувати інформацію, а саме - телефонний довідник Програма повинна містити утримувати основні функції: додавання добавляти запису, видалення віддалення запису, редагування запису, пошук. Додатково розробити ступені захисту до БД.
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
{
ItemForm newForm = new ItemForm(true, false);
newForm.Font = new Font(this.Font.Name, this.FontSize, this.Font.Style, this.Font.Unit, this.Font.GdiCharSet, this.Font.GdiVerticalFont);
newForm.Text = "Додати новий запис";
newForm.lableRegDate.Text = christianToolStripMenuItem.Checked ? DateTime.Now.ToString(): ConvertToPersianDate(DateTime.Now.ToString());
newForm.ShowDialog();
LoadPhoneBookItems();
int contactsNumbers = Variables.xDocument.Descendants("Item").Where(q => q.Attribute("UserID").Value == Variables.CurrentUserID).Count();
this.Text = Variables.Caption + Variables.CurrentUserName + ": " + contactsNumbers.ToString() + " Contacts";
}
catch (Exception ex)
{
StackFrame file_info = new StackFrame(true);
Messages.error(ref file_info, ex.Message, this);
}
}
void buttonClearSearchTextBox_Click(object sender, EventArgs e)
{
textBoxSearch.Text = "";
LoadPhoneBookItems();
}
void buttonEdit_Click(object sender, EventArgs e)
{
try
{
if (listView1.SelectedItems.Count < 1) return;
string id = listView1.SelectedItems[0].Name.Replace("Item", "");
var item = (from q in Variables.xDocument.Descendants("Item")