functіon Test() { echo "Test from A\n"; }
// Тестова функція - просто переадресує на Test()
functіon Call() { Test(); }
}
class B extends A {
// Функція Test() для класу B
functіon Test() { echo "Test from B\n"; }
}
$a=new A();
$b=new B();
?>
Використовуємо наступні команди:
$ a-a->Call(); // виводить "Test from A"
$ b-b->Test(); // виводить "Test from B"
$ b-b->Call(); // Увага! Виводить "Test from B"!
Зверніть увагу на останній рядок: всупереч очікуванням, викликається не функція Test() із класу A, а функція із класу B! Складається враження, що Test() з B просто перевизначила функцію Test() з A. Так воно насправді і є. Функція, переобумовлена в похідному класі, називається віртуальної.
Спадкування - це не просте створення точної копії класу, а розширення вже існуючого класу, щоб нащадок міг виконувати які-небудь нові, характерні тільки йому функції.
Отже, нехай у нас є деякий клас A з певними властивостями й методами. Але те, що цей клас робить, нас не зовсім улаштовує - наприклад, нехай він виконує більшість функцій, що нам необхідні, але не реалізує деяких інших. Задамося метою створити новий клас B, як би "розширював" можливості класу A, що додає йому кілька нових властивостей і методів.
Тепер на практиці розглянемо, що ж являє собою спадкування (або розширення можливостей) класів:
class B extends A {
functіon B(параметри_для_A, інші_параметри)
{ $thіs->A(параметри_для_A);
инициализируем інші поля B
}
functіon Test() { ... }
functіon Test() { ... }
}
Ключове слово extends говорить про те, що створюваний клас є лише "розширенням" класу A, і не більше того. Тобто B містить ті ж самі властивості й методи, що й A, але, крім них і ще деякі додаткові, "свої". Тепер "частина A" перебуває прямо усередині класу B і може бути легко доступна, нарівні з методами й властивостями самого класу B. Наприклад, для об'єкта $obj класу B припустимі вираження $obj->Test() і $obj->Test().
Отже, ми бачимо, що, дійсно, клас B є втіленням ідеї "розширення функціональності класу A". Зверніть також увагу: ми можемо тепер забути, що B успадкував від A деякі властивості або методи - зовні все виглядає так, начебто клас B реалізує їх самостійно.
У лекції розглядаються такі питання:
Способи проектування бази даних для Web.
Створення бази даних користувачів.
База даних – це сукупність зв'язаних даних, організованих за певними правилами, що передбачає загальні принципи опису, зберігання й маніпулювання, незалежна від прикладних програм. База даних є інформаційною моделлю предметної області. Звертання до баз даних здійснюється за допомогою системи керування базами даних (СУБД). СУБД забезпечує підтримку створення баз даних, централізованого керування й організації доступу до них різних користувачів.
Реляційна база даних - база даних, заснована на реляційній моделі. Слово "реляційний" походить від англійського "relatіon" (відношення). Для роботи з реляційними БД застосовують Реляційні СУБД.
Теорія реляційних баз даних була розроблена доктором Коддом з компанії ІBM в 1970 році. У реляційних базах даних всі дані представлені у вигляді простих таблиць, розбитих на рядки й стовпці, на перетинанні яких розташовані дані. Запити до таких таблиць повертають таблиці, які самі можуть ставати предметом подальших запитів. Кожна база даних може включати кілька таблиць. Коротко особливості реляційної бази даних можна сформулювати в такий спосіб:
Дані зберігаються в таблицях, що складаються зі стовпців ("атрибутів") і рядків ("записів", "кортежів" );
На перетинанні кожного стовпця й рядка стоїть в точності одне значення;
У кожного стовпця є своє ім'я, що служить його назвою, і всі значення в одному стовпці мають один тип.
Запити до бази даних повертають результат у вигляді таблиць, які теж можуть виступати як об'єкт запитів.
Рядки в реляційній базі даних невпорядковані - упорядкування проходить в момент формування відповіді на запит.
Загальноприйнятим стандартом мови роботи з реляційними базами даних є мова SQL.
Переваги використання реляційних баз даних у порівнянні із двовимірними файлами. Серед них:
СУРБД забезпечують більш швидкий доступ до даних, чим двовимірні файли.
СУРБД можна просто відправити запит на пошук наборів даних, відібраних за певним критерієм.
СУРБД мають убудований механізм для роботи з паралельним доступом, так що вам, як програмістові, турбуватися про цьому не потрібно.
СУРБД забезпечують довільний доступ до даних.
СУРБД мають убудовані системи підтримки привілеїв.
Якщо говорити більш предметно, то використання реляційної бази даних дає можливість швидко й без особливих зусиль відповісти на такі питання, як: "звідки ваші покупці?", "який тип продукції продається найбільше ефективно?" або "які покупці витрачають більше грошей?"
База даних складається з таблиць. Кожна таблиця являє собою набір упорядкованих стовпців, називаних полями (атрибутами). Кожний стовпець має унікальне ім'я усередині таблиці й має певний тип даних. Таблицю можна також представляти як набір рядків (або записів, кортежів), що складаються зі стовпців. Кожний стовпець відповідає одному запису в таблиці. У кожного рядка ті самі стовпці (атрибути). Деякі стовпці мають певну функцію - вони є ключами. За значенням у таких стовпцях можна однозначно визначити унікальність запису в таблицях. Ключ також часто має сполучну функцію, тобто забезпечує зв'язок даних із двох різних таблиць, що дозволяє співвідносити запису у двох таблицях за спеціальними правилами. Сам зв'язок, утворений ключами, називається відношенням між таблицями. Відношення може бути трьох типів: "один до одного", "один до багатьох" і "багато до багатьох". Всі разом: таблиці, правила їхніх відносин і зв'язків, - називається схемою бази даних і являє собою структуроване креслення, що візуально відображає структуру бази даних.
Перед тим, як почати проектування бази даних, подумайте про реальні об'єкти. Адже, як правило, вам треба буде моделювати предмети й відносини між ними виходячи з їхнього положення в реальному світі. Опираючись на це, на кожний "предмет" реального світу вам буде потрібна своя таблиця.
Як приклад візьмемо такий варіант: одержання замовлень на поставку запчастин із заводу-виробника дилерам. Нам будуть потрібні дані про запчастини, клієнтів, замовлення і їхні особливості. Запчастини мають відповідні атрибути - каталожним кодом (номером), назвою й ціною. Виходячи із цього, у базі даних повинні бути як мінімум три таблиці: запчастини (Materіals), інформація про клієнтів (Clіents) і замовлення (Orders).
Система Web-сервера складається із двох об'єктів: Web-браузера й Web-сервера. Між ними повинен існувати канал зв'язку. Web-браузер надсилає запит на сервер, сервер відсилає назад відповідь. Для сервера, що відсилає звичайні статичні сторінки, така архітектура підходить.
Архітектура ж сайту, що містить у собі базу даних, трохи складніше.
Типова транзакція Web-бази даних складається з етапів. Ми розглянемо їх на прикладі магазина " Book-O-Rama".
Web-браузер користувача відправляє HTTP-запит певної Web-сторінки. Наприклад, пошук у магазині "Book-O-Rama" всіх книг, написаних Лорой Томсон (Laura Thomson), використовуючи HTML-форму. Сторінка з результатами пошуку називається results.
Web-сервер приймає запит на results.php, одержує файл і передає його механізму РНР на обробку.
Механізм РНР починає синтаксичний аналіз сценарію. У сценарії присутній команда підключення до бази даних і виконання запиту в ній (пошук книг). РНР відкриває з'єднання із сервером MySQL і відправляє необхідний запит.
Сервер MySQL приймає запит у базу даних, обробляє його, а потім відправляє результати - у цьому випадку, список книг - назад у механізм РНР.
Механізм РНР завершує виконання сценарію, форматувати результати запиту у вигляді HTML, після чого відправляє результати в HTML-форматі Web-серверу.
Web-сервер пересилає HTML у браузер, за допомогою якого користувач переглядає список необхідних книг.
Завдання тривалого зберігання й обробки інформації з'явилося практично відразу з появою перших комп'ютерів. Для рішення цього завдання наприкінці 60-х років були розроблені спеціалізовані програми, що одержали назву систем керування базами даних (СУБД). СУБД проробили тривалий шлях еволюції від системи керування файлами, через ієрархічні й мережні бази даних. Наприкінці 80-х років домінуючою стала система керування реляційними базами даних (СУРБД). Із цього часу такі СУБД стали стандартом де-факто, і для того, щоб уніфікувати роботу з ними, була розроблена структурована мова запитів (SQL), що являє собою мову керування саме реляційними базами даних.
Модель реляційної бази даних представляє дані у вигляді таблиць, розбитих на рядки й стовпці, на перетинанні яких перебувають дані. Приклад такої таблиці показаний у таблиці:
Таблиця 8.1- Структура реляционной бази даних.
|
|
стовпець |
|
|
|
рядок |
id_forum |
name |
Description |
|
|
1 |
дизайн |
Обговорюються питання дизайну |
|
|
2 |
MySQL |
Обговорюються питання, пов'язані з MySQL |
|
|
3 |
PHP |
Обговорюються питання, пов'язані з PHP |
|
|
4 |
різне |
Інші питання |
У табл. 8.1 наведений приклад таблиці forums бази даних великого форуму, у якому є кілька розділів, присвячених різним етапам побудови Web-додатка. Кожний рядок цієї таблиці являє собою один розділ форуму. Чотири рядки таблиці являють собою весь форум.
Кожний стовпець таблиці forums представляє один елемент даних для кожного з форумів. Стовпець іd_forum містить унікальний ідентифікатор форуму, стовпець name містить назву форуму й стовпець descrіptіon містить короткий опис проблеми, обговорюваної на форумі.
Процес цей, як правило, протікає незалежно від того, який сценарний механізм і який сервер баз даних використовується. Найчастіше програмне забезпечення Web-сервера, механізм РНР і сервер баз даних перебувають на одній машині. Правда, не менш часто сервер бази даних працює на іншій машині. Це робиться з міркувань безпеки, збільшення обсягу або поділу потоку. З погляду перспектив розвитку, у роботі обидва варіанти однакові, однак у плані продуктивності другий варіант може виявитися більш кращим.