Модель реляционной базы данных
Модель описывается диаграммой сущностей-связей (ERD), в которой указываются сущности и связи между ними.
Затем ERD преобразуется в табличную структуру, и между таблицами устанавливаются связи.
Применительно к приложению для опроса модель на основе реляционной базы данных будет следующая:
Таблица Polls: (таблица вариантов опросов)
pollid integer(4) (ключ)
pollname varchar(40) (Название опроса)
question varchar(200) (Формулировака вопроса)
Таблица Options: (таблица вариантов ответов)
pollid integer(4) (внешний ключ)
option varchar(80) (Вариант ответа)
votes integer(4) (количество голосов)
Таблица Comments: (Таблица комментариев)
pollid integer(4) (внешний ключ)
comment text (Текст комментария)
Эта структура похожа на модель с плоскими файлами, но файлы заменены таблицами.
Программная организация обновления или удаления записей в базе не требуется. Эти операции организуются с помощью команд SQL запросов.
СУБД дают следующие преимущества:
• Высокая целостность данных (не гарантируемая файлами)
• Улучшенная непротиворечивость данных при множественном доступе
• Улучшенная защита
• Стандартный язык запросов
• Различные представления, основанные на одних и тех же структурах
• Независимость от файловых структур
• Устранение избыточности информации
• Отображение в объекты
• Экономия дискового пространства благодаря объединению таблиц без потерь
Недостатки СУБД:
• СУБД работают медленнее, чем файлы
• СУБД требуют дополнительного программного обеспечения
• Коммерческие СУБД бывают дороги
РНР отлично подходит для программирования баз данных. Он поддерживает большинство имеющихся сегодня СУБД, включая Oracle, MySQL, PostgreSQL, Sybase.
Вне зависимости от используемой модели данных должен существовать (точнее быть создан) единый интерфейс для взаимодействия с уровнем логики. Для этого уровень логики должен использовать не библиотечные функции для работы с файлами или базами данных, а специальные интерфейсные функции (методы, если используются объекты).
Уровень логики
Уровень логики - это то место, где сосредоточен весь интеллект приложения.
Основные действия, выполняемые на уровне логики:
Анализ данных
Преобразование данных
Расчеты
Получение статистики
Защита
Аутентификация
Регистрация и т.д.
При проектировании уровня логики в РНР важно — обеспечить его модульность. Для различных задач, которые должны решаться приложением, можно создать отдельные классы.
В нашем примере с опросом можно создать класс Polls и поместить в него все методы, необходимые для работы, такие как получение текущего опроса, добавление опроса, голосование, получение вариантов ответов и т. д.
При таком подходе если впоследствии, к примеру, потребуется добавить на сайт форумы, то можно будет разработать и создать новый класс-модуль, не имеющий абсолютно никаких связей или зависимостей с ранее созданными классами, или теми, что возможно будут созданы в будущем.
Уровень представления
На уровне представления к содержимому, подготовленному на уровне логики, добавляются элементы дизайна и размещения. На этом уровне генерируется HTML с применением CSS, Flash, графики и всего того, чем пользуются специалисты по дизайну для повышения привлекательности приложения.
Пример архитектуры многозвенного приложения:
Рис. 2. Архитектура многозвенного приложения
На этой схеме приближенно представлена многозвенная архитектура. Показаны три уровня, а также абстракция для языка представления и различные варианты хранения данных.
Уровень содержимого.Уровень содержимого абстрагирует используемый метод хранения данных (модель данных). Обычно в этом уровне есть два различных компонента:
Компонент доступа
Компонент обработки данных
Компонент обработки данных представляет собой клиент компонента доступа. В нее должны быть помещены все функции, необходимые для управления моделью данных: получения, записи, удаления, обновления, вставки данных и т. п.
В компоненте обработки данных для нашего примера мы должны реализовать все операции в модели данных без привязки к методу хранения данных (файлы, БД). (табл. 1):
Таблица 1. Операции, реализуемые в компоненте обработки данных
| Операция | Описание |
| createPoll($question) | Создает опрос, возвращая идентификатор pollid |
| getCurrentPolK) | Возвращает pollid текущего опроса |
| getOptions($pollid) | По данному pollid возвращает массив идентификаторов вариантов optionid |
| getOptionName($optionid) | По данному optionid возвращает имя варианта |
| getOptionVotes($optionid) | По данному optionid возвращает количество голосов, поданных за этот вариант |
| addVote($optionid) | Инкрементирует количество голосов, поданных за данный вариант |
| addOption($pollid,$name) | Добавляет вариант в опрос |
| removePoll($pollid) | Удаляет опрос и его варианты |
| removeOption($optionid) | Удаляет вариант из опроса |
| setCurrent($pollid) | Устанавливает опрос в качестве текущего |
Все эти функции можно инкапсулировать в одном классе (например, Poll_Data), использующем объект с именем DB (или любым другим) для доступа к базе данных.
Компонент доступа будет представлять собой класс, в котором перечисленные функции реализованы с помощью функций работы с файловой системой или языка запросов к той или иной БД. Таким образом, компонент доступа становится классом, абстрагирующим применяемую базу данных.
При замене базы данных (например, с MySQL на PostgreSQL) надо будет создать экземпляр объекта Базы Данных PostgreSQL с тем же именем DB. После чего класс Poll_Data сможет работать с новой базой без модификации.
Итак: