46883 (База даних студії веб-дизайну), страница 3
Описание файла
Документ из архива "База даних студії веб-дизайну", который расположен в категории "". Всё это находится в предмете "информатика" из 1 семестр, которые можно найти в файловом архиве . Не смотря на прямую связь этого архива с , его также можно найти и в других разделах. Архив можно найти в разделе "курсовые/домашние работы", в предмете "информатика, программирование" в общих файлах.
Онлайн просмотр документа "46883"
Текст 3 страницы из документа "46883"
Натиснувши кнопку „Добавить услугу”, з’явиться форма „Услуга_доб”, яка має як і лінійчату, так і кнопочну структуру. В цій формі необхідно заповнити поля: код послуги, назва послуги, ціна послуги, вид, виконавець. Заповнення усіх полів обов’язкове. Якщо якесь поле залишеться не заповненим, з’явиться відповідне повідомлення. Після того, як всі поля будуть заповненні, можна буде, за допомогою відповідних кнопок, додавати ще один запис, удалити запис, зберегти та знайти запис.
Форма „Добавить заказчика” має лінійну структуру, в яку входять поля зі списком необхідних даних для введення. В цю інформацію занасяться наступні дані про замовника: ПІБ, код замовника, адреса, телефон, назва фірми.
Форма „Добавить исполнителя” має лінійну структуру, в яку входять поля зі списком необхідних даних для введення. В цю інформацію занасяться наступні дані про виробника: код виконавця, ПІБ, дата народження, адреса, телефон, посада, вид послуги, зарплата.
Форми „Добавить заказчика” та „Добавить исполнителя ” мають кнопки, які дозволяють додати запис, зберегти запис або видалити його.
Форма „Договор” має кнопочну структуру, в яку входять:
-додавання договору;
-пошук договору за період часу;
Форма „Добавить договор”, в яку входять поля зі списком необхідних даних для введення. В цю інформацію заносяться наступні дані про договір: основні положення, даатз аключення, дата виконання, код договору, виконан/не виконан, причина невиконання.
Форм „Отчёт по дате ” має лінійну структуру, в яку входять поля зі списком необхідних даних для введення.Необхідно ввести початкову та кінцеву дати певного періоду та натиснути кнопку „Выполнить запрос”, повинен бути відкритися запит «Запрос по дате», в якому буде виводитися вся інформація про договори у цей період.
- виконання запиту;
Форма „Звіт” містить в собі дві кнопки: „Отчёт о предоставленніх услугах” та „Отчётность студии”.
Натиснувши першу кнопку, відкриється звіт „Отчёт о предоставляеміх услугах”, яка містить в собі код послуги, код виконавця, назва послуги, ціна, кількість, сума.
- друк звіту.
Натиснувши кнопку „Отчётность студії”, на екрані з’явиться звіт прозвітність студії, який містить у собі таку їнформацію:доходи, розрахунок заробітної плати, кількість виконаних договорів.
Окрім всіх вищезазначених кнопок, кожна з форм має також має копку „Закрити форму”, яка має вигляд - .
2.5 Розробка фізичної моделі даних
Фізична модель бази даних визначає способи розміщення даних у середовищі зберігання й способи доступу до цих даних, які підтримуються на фізичному рівні.
Фізична модель бази даних будується на основі логічної моделі даних.
Після побудови фізичної моделі необхідно провести аналіз нормалізації:
1. Таблиці перебувають в 1-й нормальній формі (НФ) тоді й тільки тоді, коли відсутні однакові картежи й у кожному з осередків будь-якої таблиці втримуються атомарні значення.
2. Таблиці перебувають в 2-й НФ, тоді й тільки тоді, коли таблиця перебуває в першій нормальній формі, і кожен не ключовий атрибут перебуває в повній функціональній залежності від всіх можливих ключів.
3. Таблиці перебувають в 3-й НФ, тоді й тільки тоді, коли таблиця перебуває в другій нормальній формі, і всі не ключові атрибути перебувають у повній нетранзитивній залежності від всіх можливих ключів.
На підставі логічної моделі даних складемо фізичну модель, згідно з особливостями обраної СУБД. Для реалізації завдання по функціонуванню аптеки була обранна СУБД “Access 2003”. База даних зберігається в даної СУБД у вигляді одного файлу з розширенням *.mdb.
Для створення фізичної моделі бази даних приведемо її проектну частину (таблиця 4).
Таблиця 4- Замовник
Атрибут | Тип данных | Размер поля в байтах | Обязательность поля | Ключ |
Код заказчика | Счетчик | 4 | Да | PK |
Ф.И.О. | Текстовый | 40 | Да | FK |
Адрес | Текстовый | 50 | Да | … |
Телефон | Текстовый | 20 | Нет | … |
Название фирмы | Текстовый | 20 | Да | … |
Таблиця 5- Послуги
Атрибут | Тип данных | Размер поля в байтах | Обязательность поля | Ключ |
Код услуги | Счетчик | 4 | Да | PK |
Вид услуги | Текстовый | 20 | Нет | … |
Название услуги | Текстовый | 30 | Да | FK2 |
Код исполнителя | Длинное целое | 4 | Да | FK1 |
Цена | Денежный | 8 | Да | … |
Дополнительные материалы | Текстовый | 50 | Да | … |
Таблиця 6- Виконавець
Атрибут | Тип данных | Размер поля в байтах | Обязательность поля | Ключ |
Код исполнителя | Счетчик | 4 | Да | PK |
Ф.И.О. | Текстовый | 40 | Да | … |
Дата рождения | Дата/время | 8 | Нет | … |
Адрес | Текстовый | 50 | Да | … |
Телефон | Текстовый | 20 | Да | … |
Должность | Текстовый | 30 | Да | FK |
Вид услуги | Текстовый | 30 | Да | … |
Зарплата | Длинное целое | ... |
Таблиця 7- Звіт
Атрибут | Тип данных | Размер поля в байтах | Обязательность поля | Ключ |
Код услуги | Длинное целое | 4 | Да | PK FK2 |
Код исполнителя | Длинное целое | 4 | Да | PK FK3 |
Код заказчика | Счетчик | 4 | Да | PK FK1 |
Вид услуги | Текстовый | 20 | Да | … |
Название услуги | Текстовый | 30 | Да | … |
Цена | Денежный | 8 | Да | … |
Кол-во | Длинное целое | 4 | Да | … |
Сумма | Денежный | 8 | Да | … |
Код договора | Длинное целое | 4 | Да | PK FK4 |
Таблиця 8- Договір
Атрибут | Тип данных | Размер поля в байтах | Обязательность поля | Ключ |
Код договора | Счетчик | 4 | Да | PK |
Положения договора | Текстовый | 90 | Нет | … |
Дата заключения | Дата/время | 8 | Да | AK |
Дата выполнения | Дата/время | 8 | Да | … |
Выполнение/не выполнение | Текстовый | 15 | Да | … |
Причина невыполнения | Текстовый | 40 | Да | … |
Після побудови фізичної моделі можна зробити висновок, що схема даних таблиці відповідає логічній схемі.
Проведемо аналіз нормалізації побудованої БД. Всі таблиці БД перебувають у третій нормальній формі (НФ). Цієї НФ досить, щоб забезпечити в даній базі високий ступінь цілісності.
При аналізі бази дані аномалії виявлені не були.
На підставі фізичної моделі складемо базу даних у середовищі Microsoft Office Access версії 2003 (рисунок 7).
Рисунок 7 – Фізична модель даних, реалізована в середовищі Microsoft Office Access версії 2003.
-
Кодування і тестування програмного забезпечення бази даних аптеки
База даних аптека була виконана в середовищі Microsoft Access 2003. Вона реалізована за допомогою таблиць, форм, запитів і звітів. Для нормального функціонування був написаний програмний код який представлений в додатку А.
Для проведення тестування роботи програмного продукту до бази даних були введені наступні дані:
-
до таблиці «Услуга» була введена інформація про 3 послуги;
-
до таблиці «Исполнитель» ввели інформацію про 5 виробникыв;
-
до таблиці «Договор» була введена інформація про 3 договори;
-
до таблиці «Заказчик» була введена інформація про 4 заказчика;
-
до таблиці «Отчёты» – інформація про звітність.
Для більш ретельного тестування приведемо приклад введення та отримання інформації, яка включає в себе дані про полсугу та вид, а також пошук за введеним видом. Для того щоб ввести дані про послугу ми повинні викликати головну форму, в якій обираємо розділ "Услуга" натисненням відповідної кнопки. Перед нами з’являється форма, яка дозволяє обрати наступні дії: або пошук послуги за назвою, або пошук товару за видом, або, або додавання послуги. Ми обираємо останнє. Перед нами з’являється форма для заповнення характерисик товару, які будуть ідентифікувати її.
Вводимо дані спочатку для одного товару, потім натискаємо додати запис – вводимо інформацію про другий товар і т.д. до 3: „Код послуги”-1,2,3; „Вид услуги”-стартовий сайт, бізнес-сайт, сайт-візитка; „Название услуги”-створення сайту, кеширування, реклама; „Код исполнителя”-3, 5, 2; „Цена”-1000р, 456р, 800р; „Дополнительные материалы”-фотографії, документи, фотографії.
Для збереження даних натискаємо на відповідну кнопку, але якщо хоча б одне поле не буде заповнене, то з'явиться повідомлення про те, що не заповненні обов’язкові поля. Якщо всі обов’язкові поля заповнені, то інформація зберігається без проблем. Закриваємо цю форму та обираємо запит, після цього бачимо, що тепер у списку дійсно існує уся інформація про послугу, що ми ввели.
Повертаємося у форму „Послуга” та натискаємо кнопку „Поиск услуги по названию”. Перед нами з’являється вікно з питанням про назву. В цьому вікні набираємо:кеширування. Після натиснення кнопки „ОК” бачимо форму, в якій вказіні лише дані про товар, що відповідає заданій назві, а саме: „Код послуги”- 2; „Вид услуги”- бізнес-сайт; „Название услуги”- кеширування; „Код исполнителя”- 5; „Цена”- 456р; „Дополнительные материалы”-, документи.
Цей тест було проведено також для пошуку послуги за видом, використовуючи всі можливості. Тому можна зробити висновок, що система працює нормально.