Базы данных на ПК развивались по направлению от настольных (desktop), или локальных приложений, когда реально с БД могло работать одно приложение, до систем коллективного доступа к БД.
Локальное приложение устанавливалось на единичном ПК; там же располагалась и база данных (БД), с которой работало данное приложение. Однако необходимость коллективной работы с одной и той же БД повлекло за собой перенос БД на сервер. Приложение, работающее с БД, располагалось также на сервере.

Менее характерным был другой способ, заключавшийся в хранении приложения, обращавшегося к БД, на конкретном компьютере пользователей ("клиентов"). Были выпущены новые версии локальных СУБД, которые позволяли создавать приложения, одновременно работающие с одной БД на файловом сервере. Основной проблемой была явная или неявная обработка транзакций и неизбежно встающая при коллективном доступе проблема обеспечения смысловой и ссылочной целостности БД при одновременном изменении одних и тех же данных.

Местоположение БД определяет так называемую архитектуру базы данных. Имеются четыре разновидности архитектур баз данных:

Локальные базы данных;

Архитектура "файл-сервер";

Архитектура "клиент-сервер";

Многозвенная архитектура.

Использование той или иной архитектуры накладывает сильный отпечаток на общую идеологию работы приложения и на программный код приложения.
При работе с локальными базами данных сами базы данных расположены на том же компьютере, что и приложения, осуществляющие доступ к ним. Работа с базой данных происходит в однопользовательском режиме. Приложение ответственно за поддержание целостности базы и за выполнение запросов к базе данных.
При работе в архитектуре "файл-сервер" база данных и приложение расположены на файловом сервере сети. Возможна многопользовательская работа с одной и той же базе данных, когда каждый пользователь со своего компьютера запускает приложение, расположенное на сетевом сервере. Тогда на компьютере пользователя запускается копия приложения. По каждому запросу к базе данных из приложения данные из таблиц базы данных перегоняются на компьютер пользователя, независимо от того, сколько реально нужно данных для выполнения запроса. После этого выполняется запрос.

Каждый пользователь имеет на своем компьютере локальную копию данных, время от времени обновляемых из реальной базы данных, расположенной на сетевом сервере. При этом изменения, которые каждый пользователь вносит в базу данных, могут быть до определенного момента неизвестны другим пользователям, что делает актуальной задачу систематического обновления данных на компьютере пользователя из реальной базы данных. Другой актуальной задачей является блокирование записей, которые изменяются одним из пользователей; это необходимо для того, чтобы в это время другой пользователь не внес изменений в те же данные.

В архитектуре "файл-сервер" вся тяжесть выполнения запросов к базе данных и управления целостностью базы данных ложится на приложение пользователя. База данных на сервере является пассивным источником данных.
Кардинальных различий с точки зрения архитектуры между однопользовательской архитектурой и архитектурой "файл-сервер" нет. И в том, и в ином случае в качестве СУБД применяются так называемые "персональные" (или "настольные", "локальные") СУБД, такие как paradox, dbase и пр. Сама база данных в этом случае представляет собой набор таблиц, индексных файлов, файлов полей комментариев (memo-полей) и пр., хранящихся в одном каталоге на диске в виде отдельных файлов.

В ходе эксплуатации были выявлены общие недостатки файл-серверного подхода при обеспечении многопользовательского доступа к базе данных.
Вся тяжесть вычислительной нагрузки при доступе к базе данных ложится на приложение клиента, что является следствием принципа обработки информации в системах "файл-сервер": при выдаче запроса на выборку информации из таблицы вся таблица базы данных копируется на клиентское место, и выборка осуществляется на клиентском месте. Локальные СУБД используют так называемый "навигационный подход", ориентированный на работу с отдельными записями.

Не оптимально расходуются ресурсы клиентского компьютера и сети; например, если в результате запроса мы должны получить 2 записи из таблицы объемом 10000 записей, все 10000 записей будут скопированы с файл-сервера на клиентский компьютер; в результате возрастает сетевой трафик и увеличиваются требования к аппаратным мощностям пользовательского компьютера.
В базе данных на файл-сервере гораздо проще вносить изменения в отдельные таблицы, минуя приложения, непосредственно из инструментальных средств (например, из утилиты database desktop фирмы borland для файлов paradox или dbase); подобная возможность облегчается тем обстоятельством, что, фактически, у локальных СУБД база данных – понятие более логическое, чем физическое, поскольку под базой данных понимается набор отдельных таблиц, сосуществующих в едином каталоге на диске. Все это позволяет говорить о низком уровне безопасности – как с точки зрения хищения и нанесения вреда, так и с точки зрения внесения ошибочных изменений.

Недостаточно развитый аппарат транзакций для локальных СУБД служит потенциальным источником ошибок как с точки зрения одновременного внесения изменений в одну и ту же запись, так и с точки зрения отката результатов серий объединенных по смыслу в единое целое операций над базой, когда некоторые из них завершились неуспешно, а некоторые — нет; это может нарушать ссылочную и смысловую целостность базы данных.
Недостатки настольных СУБД обычно проявляются не сразу, а лишь в процессе длительной эксплуатации, когда объем хранимых данных и число пользователей становятся достаточно велики – это приводит к снижению производительности приложений, использующих такие СУБД.

Поскольку настольные СУБД не содержат специальных приложений и сервисов, управляющих данными, а используются для этой цели файловые сервисы операционной системы, вся реальная обработка данных в таких СУБД осуществляется в клиентском приложении, и любые библиотеки доступа к данным в этом случае также находятся в адресном пространстве клиентского приложения. Поэтому при выполнении запросов данные, на основании которых выполняется такой запрос (это может быть одна или несколько таблиц целиком либо, если повезет, один или несколько индексов и выбранные с их помощью части таблиц), должны быть доставлены в то же самое адресное пространство клиентского приложения. Это и приводит к перегрузке сети при увеличении числа пользователей и объема данных, а также грозит иными неприятными последствиями, например разрушением индексов и таблиц. Недаром до сих пор популярны утилиты для "ремонта" испорченных файлов настольных СУБД.
Недостатки архитектуры "файл-сервер" решаются при переводе приложений в архитектуру "клиент-сервер", которая знаменует собой следующий этап в развитии СУБД. Характерной особенностью архитектуры "клиент-сервер" является перенос вычислительной нагрузки на сервер базы данных (sql-сервер) и максимальная разгрузка приложения клиента от вычислительной работы, а также существенное укрепление безопасности данных – как от злонамеренных, так и просто ошибочных изменений.
БД в этом случае помещается на сетевом сервере, как и в архитектуре "файл-сервер", однако прямого доступа к базе данных (БД) из приложений не происходит. Функция прямого обращения к БД осуществляет специальная управляющая программа – сервер БД (sql-сервер), поставляемый разработчиком СУБД.

Архитектура "клиент-сервер" разделяет функции приложения пользователя (называемого клиентом) и сервера.
Приложение-клиент формирует запрос к серверу, на котором расположена БД, на структурном языке запросов sql, являющимся промышленным стандартом в мире реляционных БД. Удаленный сервер принимает запрос и переадресует его sql-серверу БД. sql-сервер – это специальная программа, управляющая удаленной базой данных. sql-сервер обеспечивают интерпретацию запроса, его выполнение в базе данных, формирование результата выполнения запроса и выдачу его приложению-клиенту. При этом ресурсы клиентского компьютера не участвуют в физическом выполнении запроса; клиентский компьютер лишь отсылает запрос к серверной БД и получает результат, после чего интерпретирует его необходимым образом и представляет пользователю.

Так как клиентскому приложению посылается результат выполнения запроса, по сети "путешествуют" только те данные, которые необходимы клиенту. В итоге снижается нагрузка на сеть. Поскольку выполнение запроса происходит там же, где хранятся данные (на сервере), нет необходимости в пересылке больших пакетов данных. Кроме того, sql-сервер, если это возможно, оптимизирует полученный запрос таким образом, чтобы он был выполнен в минимальное время с наименьшими накладными расходами. Всё это повышает быстродействие системы и снижает время ожидания результата запроса.

При выполнении запросов сервером существенно повышается степень безопасности данных, поскольку правила целостности данных определяются в базе данных на сервере и являются едиными для всех приложений, использующих эту БД. Таким образом, исключается возможность определения противоречивых правил поддержания целостности. Мощный аппарат транзакций, поддерживаемый sql-серверами, позволяет исключить одновременное изменение одних и тех же данных различными пользователями и предоставляет возможность откатов к первоначальным значениям при внесении в БД изменений, закончившихся аварийно.

Функциями приложения-клиента являются:

Посылка к серверу запросов;

Интерпретация результатов запросов, полученных от сервера, и представление их пользователю в требуемой форме;

Реализация интерфейса пользователя.

sql-сервер должен быть загружен на момент принятия запроса клиента. Функциями сервера БД являются:

Прием запросов от приложений-клиентов, интерпретация запросов, выполнение запросов в БД, отправка результата выполнения запроса приложению-клиенту;

Управление целостностью БД, обеспечение системы безопасности, блокировка неверных действий приложений-клиентов;

Хранение бизнес-правил, часто используемых запросов в уже интерпретированном виде;

Обеспечение одновременной безопасной от отказоустойчивой многопользовательской работы с одними и теми же данными.

В архитектуре "клиент-сервер" используются так называемые "удаленные" (или "промышленные") СУБД. Промышленными они называются из-за того, что именно СУБД этого класса могут обеспечить работу информационных систем масштаба среднего и крупного предприятия, организации, банка. Локальные СУБД предназначены для однопользовательской работы или для обеспечения работы информационных систем, рассчитанных на небольшие группы пользователей.
К разряду промышленных СУБД принадлежат oracle, informix, sybase, ms sql server, db2, interbase и ряд других.

Как правило, sql-сервер управляется отдельным сотрудником или группой сотрудников (администраторы sql-сервера). Они управляют физическими характеристиками баз данных, производят оптимизацию, настройку и переопределение различных компонентов БД, создают новые БД, изменяют существующие и т.д., а также выдают привилегии различным пользователям.
Кроме этого, существует отдельная категория сотрудников, называемых администраторами баз данных. Как правило, это администраторы сервера, разработчики БД или пользователи, имеющие привилегии на создание, изменение, настройку оптимальных параметров отдельных серверных БД. Администраторы БД также отвечают за предоставление прав на разноуровневый доступ к сопровождаемым ими БД для других пользователей.

Механизмы доступа

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

Существует несколько способов доступа к данным из средств разработки и клиентских приложений.
Подавляющее большинство СУБД содержит в своем составе библиотеки, предоставляющие специальный прикладной программный интерфейс (application programming interface, api) для доступа к данным этой СУБД. Обычно такой интерфейс представляет собой набор функций, вызываемых из клиентского приложения. В случае настольных СУБД эти функции обеспечивают чтение/запись файлов базы данных (БД), а в случае серверных СУБД инициируют передачу запросов серверу баз данных и получение от сервера результатов выполнения запросов или кодов ошибок, интерпретируемых клиентским приложением. Библиотеки, содержащие api для доступа к данным серверной СУБД, обычно входят в состав ее клиентского программного обеспечения, устанавливаемого на компьютерах, где функционируют клиентские приложения.

В последнее время windows-версии клиентского программного обеспечения наиболее популярных серверных СУБД, в частности microsoft sql server, oracle, informix, содержат также СОМ-серверы, предоставляющие объекты для доступа к данным и метаданным.
Использование клиентского api (или клиентских СОМ-объектов) является наиболее очевидным способом манипуляции данными в приложении. Однако в этом случае созданное приложение сможет использовать данные только СУБД этого производителя, и замена ее на другую повлечет за собой переписывание значительной части кода клиентского приложения – клиентские api и объектные модели не подчиняются никаким стандартам и различны для различных СУБД.

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

Отметим, что достоинством универсальных механизмов является возможность применения одного и того же абстрактного api, а во многих случаях – СОМ-серверов, компонентов, классов для доступа к различным типам СУБД. Поэтому приложения, использующие универсальные механизмы доступа к данным, легко модифицировать, если необходима смена СУБД.
Наиболее популярными среди универсальных механизмов доступа к данным можно назвать следующие:

open database connectivity (odbc). ole db. activex data objects (ado). borland database engine (bde).

Универсальные механизмы odbc, ole db и ado фирмы microsoft представляют собой по существу промышленные стандарты. Что касается механизма доступа к данным bde фирмы borland, то он так и не стал промышленным стандартом, однако до недавнего времени применялся довольно широко, поскольку до выхода delphi 5 был практически единственным универмальным механизмом доступа к данным, поддерживаемым средствами разработки borland на уровне компонентов и классов

Что такое sql?

sql часто называют языком эсперанто для СУБД. Действительно, в мире нет другого языка для работы с базами данных (БД), который бы настолько широко использовался в программах. Первый стандарт sql появился в 1986 г. и к настоящему времени завоевал всеобщее признание. Его можно использовать даже при работе с не реляционными СУБД. В отличие от других программных средств, таких, как языки Си и Кобол, являющихся прерогативой программистов-профессионалов, sql применяется специалистами из самых разных областей. Программисты, администраторы СУБД, бизнес-аналитики — все они с успехом обрабатывают данные с помощью sql. Знание этого языка полезно всем, кому приходится иметь дело с БД.

Для создания перспективного, расширяемого и эффективного сайта любой сложности следует начинать с простого. Это процесс нелёгкий, требует определённых базовых знаний PHP и MySQL, но если его рассмотреть по пунктам - то можно составить своего рода «рабочий план», который пригодится при создании новых сайтов. Подготовим «ядро» и базу для проекта. Вначале это будет обычный сайт визитка, но потом, добавляя функционал, его можна превратить во что угодно. Итак, приступим.

1. Подготовка базы данных. Создаём первую таблицу в БД MySQL

Создаём новую базу данных, например «mysite». Лично я привык работать с кодировкой UTF-8, по-этому сразу оговорюсь: проследите, чтобы все текстовые файлы сайта, сама база, таблицы и поля таблиц были в одной кодировке.
В новой базе делаем таблицу. Назовём её «pages». В этой таблице будут храниться статические страницы будущего сайта и информация о них. Таблица должна содержать следующие поля:

• page_id - идентификатор страницы (SMALLINT, primary key, auto_increment);
• page_alias - псевдоним страницы для строки адреса ЧПУ (VARCHAR, 255);
• page_title - название страницы в окне браузера (VARCHAR, 255);
• page_meta_d - мета описание страницы для тега meta description (VARCHAR, 255);
• page_meta_k - мета ключевые слова для тега meta keywords (VARCHAR, 255);
• page_h1 - заголовок страницы (VARCHAR, 255);
• page_s_desc - краткое описание материала, например если материалы сайта будут в виде блога (TEXT);
• page_content - основной текст страницы, который будет выводиться в центральную колонку сайта (TEXT);
• page_publish - содержит «Y» - если страница опубликована, или «N» - если она скрыта (CHAR, по умолчанию «Y»).

Сразу после создания таблицы вставляем в неё значения для главной страницы сайта. В поле «page_alias» для главной страницы предлагаю вставить значение «home». Метатеги - соответственно тематике всего сайта. Таким же образом можно посоздавать другие страницы, например «О компании» с алиасом «about» и своими метатегами, или «Контакты» с алиасом «contacts» и т.д.

2. Создаём файл конфигурации сайта

В корневой папке сайта, которая должна быть пуста на данном этапе, создаём папочку «cfg», в ней с помощью.htaccess закрываем доступ директивой «deny from all». Создаём файл core.php следующего содержания:

// MYSQL
class MyDB
{
var $dblogin = "root"; // ВАШ ЛОГИН К БАЗЕ ДАННЫХ
var $dbpass = ""; // ВАШ ПАРОЛЬ К БАЗЕ ДАННЫХ
var $db = "mysite"; // НАЗВАНИЕ БАЗЫ ДЛЯ САЙТА
var $dbhost="localhost";

Var $link;
var $query;
var $err;
var $result;
var $data;
var $fetch;

Function connect() {
$this->link = mysql_connect($this->dbhost, $this->dblogin, $this->dbpass);
mysql_select_db($this->db);
mysql_query("SET NAMES utf8");
}

Function close() {
mysql_close($this->link);
}

Function run($query) {
$this->query = $query;
$this->result = mysql_query($this->query, $this->link);
$this->err = mysql_error();
}
function row() {
$this->data = mysql_fetch_assoc($this->result);
}
function fetch() {
while ($this->data = mysql_fetch_assoc($this->result)) {
$this->fetch = $this->data;
return $this->fetch;
}
}
function stop() {
unset($this->data);
unset($this->result);
unset($this->fetch);
unset($this->err);
unset($this->query);
}
}

Этот файл пока содержит только простой класс подключения к базе данных, но в дальнейшем в него можно добавлять разные полезные функции, которые будут доступны из любого места в коде сайта. Не забудьте изменить логин и пароль к Вашей базе.

Если Вы работаете в среде Windows, я могу порекоммендовать использовать редактор . В этом редакторе есть нумерация строк, и он легко переводит текст из одной кодировки в другую. ВНИМАНИЕ! Если Вы работаете в кодировке UTF-8 - конвертируйте файлы в UTF-8 without BOM - это поможет избежать проблем в будущем.

3. Создаём index.php - главный контроллер сайта

Файл конфигурации создан. Теперь в корневой папке сайта создаём index.php - это и будет основной скрипт сайта, своего рода «главный контроллер». Содержание файла index.php:

define("INDEX", ""); // УСТАНОВКА КОНСТАНТЫ ГЛАВНОГО КОНТРОЛЛЕРА

Require_once($_SERVER."/cfg/core.php"); // ПОДКЛЮЧЕНИЕ ЯДРА

// ПОДКЛЮЧЕНИЕ К БД
$db = new MyDB();
$db->connect();

// ГЛАВНЫЙ КОНТРОЛЛЕР
switch ($_GET) {
case "page":
include($_SERVER."/com/page.php");
break;
default:
include($_SERVER."/com/home.php");
break;
}

Include ($_SERVER."/template.php");
$db->close();

Переменная $_GET будет указывать главному контроллеру какой компонент сайта загружать при запросе. Сейчас в нашем сайте предусмотрено только два компонента: «страница» и «главная страница» (в принципе можно обойтись и одним компонентом вывода обычной страницы, но часто вид главной страницы сайта отличается от обычных страниц пунктов меню). Логика работы главного контроллера такова: из URL строки извлекается название нужного компонента (значение переменной $option), в зависимости от его значения подключается файл самого компонента (содержится в папке /com). Файл компонента выполняет все необходимые работы, извлекает из базы данные и записывает их в переменные, для передачи в шаблон дизайна. В самом конце подключается файл дизайна сайта, в который и передаются все переменные и данные, извлечённые в компонентах. Это звучит намного сложнее, чем работает.

4. Создаём компонент вывода обычной страницы

В корне сайта создаём папочку «com» - в ней будут храниться файлы компонентов. Компонент сайта, в моём понимании - это файл, в котором происходит обработка данных для разных разделов сайта. Например компонент обычной страницы извлекает из базы данных название, описание и текст материала, и записывает их в переменные $title, $meta_d, $meta_k, $content и др. Эти данные потом передаются в шаблон дизайна (под каждый компонент можно создавать свой шаблон дизайна) и выводятся пользователю в виде HTML-страницы. Например, компонент каталога, который можно создать в будущем, выполнял бы почти то же самое, но с данными про товары - а там своя специфика, другие поля в таблице, итд. По-этому для каждого функционального раздела сайта стоит создавать отдельный компонент. В схеме MVC (Model-View-Controller) компонент выполняет роль модели.

Создаём в папке «com» файл «page.php». Содержимое файла следущее:

/* КОМПОНЕНТ СТРАНИЦЫ */
$alias = $_GET;
$query = "SELECT * FROM pages WHERE page_alias="".$alias."" AND page_publish="Y" LIMIT 1";
$db->run($query);
$db->row();
// ПЕРЕМЕННЫЕ КОМПОНЕНТА
$id = $db->data;
$alias = $db->data;
$title = $db->data;
$h1 = $db->data;
$meta_d = $db->data;
$meta_k = $db->data;
$s_desc = $db->data;
$component = $db->data;
// ЕСЛИ СТРАНИЦЫ НЕ СУЩЕСТВУЕТ
if (!$id) {
header("HTTP/1.1 404 Not Found");
$component = "ОШИБКА 404! Данной страницы не существует";
}
$db->stop();

5. Создаём компонент вывода главной страницы

Главная страница у нас в базе данных хранится под псевдонимом «home», и пока по своей структуре не отличается от обычных страниц сайта - это просто статья. Тем не менее создадим для неё отдельный компонент - на перспективу, так сказать.

Содержимое компонента «home.php» в папке «com» почти совпадает с содержимым компонента обычной страницы, за исключением строки запроса к базе и названия компонента. Строка запроса теперь выглядит так:

$query = "SELECT * FROM wx_pages WHERE page_alias="home" LIMIT 1";

6. Создаём шаблон дизайна всего сайта

В корне сайта создаём файл template.php. По сути это обычный макет web-дизайна в формате HTML+CSS, только с PHP переменными в нужных местах. Между тегами title вставочка , в центральной колонке сайта вставочка и так по всему шаблону расставляем нужные переменные, которые объявлены в компонентах.

В корневой папке также должны быть папки «css» и «images» для элементов дизайна. В файле /css/style.css - можно настроить стили по своему усмотрению.

7. Чистые ссылки и файл.htaccess

Для создания чистых ссылок я использую mod_rewrite с прямыми указаниями правил для каждого компонента отдельно, так как разбор адресной строки средствами самого контроллера считаю излишним функционалом. Содержимое.htaccess на данном этапе такое:

RewriteEngine On
RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f

# ЗАПРЕЩЁННЫЕ ФАЙЛЫ
RewriteRule .htaccess - [F]
RewriteRule template.php - [F]

# ПРАВИЛА mod_rewrite
RewriteRule page/(+)([\/]{0,1})\.htm$ index.php?option=page&alias=$1 [L]

В будущем мы будем дописывать правила для компонентов поиска, каталога, блога статей и т.д. Смысл один: преобразовать ссылки вида «mysite.com/index.php?option=pages&alias=about » в ссылку вида «mysite.com/pages/about.htm » - смотрится довольно красиво. Старайтесь в разработке избегать массива $_GET в целях безопасности и не надеяться на него. Целесообразно хранить в нём только параметры для главного контроллера (переменная $option) и для компонента (переменная $alias).

Также в каждой папке сайта «на всякий случай» создайте пустой файл index.html - это нужно для того, чтобы при обращении к каталогу через адресную строку ничего не отображалось.

Теги: php, mysql, движок сайта, контроллер, создание сайта, mvc

Создайте базу данных. В командной строке MySQL введите команду CREATE DATABASE ; . Замените названием вашей базы данных. Оно не может содержать пробелы.

• К примеру, чтобы создать базу данных всех американских штатов, можно ввести CREATE DATABASE us_states;
• Примечание: Команды необязательно вводить в верхнем регистре.
• Примечание: Все команды MySQL должны оканчиваться ";". Если вы забыли поставить точку с запятой, то просто введите ";" на следующей строке, чтобы началась обработка предыдущей команды.

Отобразите список доступных баз данных. Введите команду SHOW DATABASES; , чтобы отобразить список хранящихся баз данных. Кроме только что созданной базы данных, вы так же увидите базы данных mysql и test . Сейчас можете их проигнорировать.

Выберите базу данных. Когда база данных создана, нужно ее выбрать, чтобы начать редактирование. Введите команду USE us_states; . Вы увидите сообщение Database changed , которое уведомляет, что сейчас активной базой данных является us_states .

Создайте таблицу. Таблица - это место хранения информации в базе данных. Чтобы создать таблицу, нужно одной командой ввести всю ее структуру. Чтобы создать таблицу, введите такую команду: CREATE TABLE states (id INT NOT NULL PRIMARY KEY AUTO_INCREMENT, state CHAR(25), population INT(9)); . Эта команда создаст таблицу под названием "states" с тремя полями: id , state , and population .

• Команда INT указывает на то, что поле id будет содержать только числа (целые числа).
• Команда NOT NULL указывает на то, что поле id не должно быть пустым (обязательно для ввода).
• PRIMARY KEY обозначает, что поле id является ключевым полем в таблице. Ключевое поле - это поле, которое не может содержать одинаковых значений.
• Команда AUTO_INCREMENT будет автоматически присваивать возрастающие значения полю id , по сути автоматически нумеруя каждую запись.
• Команды CHAR (символы) and INT (целые числа) обозначают тип данных, допустимый в соответствующих полях. Число, следующее за командой, обозначает сколько символов или цифр поле может содержать.

Введение

Базы данных - совокупность данных, организованная по определенным правилам, предусматривающая общие принципы описания, хранения, манипулирования данными, независимыми от прикладных программ.

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

Формирование и поддержание БД.

Обработка информации.

Прием запросов.

Предоставление информации пользователям.

Обеспечение целостности и реорганизации ценностей БД.

Организация совместной работы пользователей.

На сегодняшний день существует множество различных систем управления базами данных. Они все используют разные средства и функции, но преимущественно у всех СУБД в основе лежат одинаковые понятия. Поэтому для обобщения этих понятий, приемов и методов на весь класс СУБД, я хотела бы взять программу, входящую в Microsoft Office, Microsoft Access.

Microsoft Access -реляционная СУБД, в которой предусмотрены все необходимые средства для определения и обработки данных, а также управления ими при работе с большим объемом информации.

Access - функционально полная система, имеющая мощные средства для работы в этой программе. Ее преимуществом перед другими является простота, наличие всех средств для успешной обработки и управления БД.

Создание базы данных

Этапы проектирования базы данных

1. Определение цели создания базы данных

На первом этапе проектирования базы данных необходимо определить цель создания базы данных, основные ее функции и информацию, которую она должна содержать.

Моя база данных разработана для проката видеодисков. Схема работы очень проста. Клиент (все данные и контакты находятся в таблице Клиенты) берет на прокат видеодиск (например, «фильм Чемпионы».). Этот прокат заносится в таблицу Прокат. Остальные таблицы (Жанр, Клиенты, Режиссеры, Страны), формы, запросы базы будут нужны для информационной, правильной, четкой, работы. Чтобы можно было сразу узнать кто режиссер, производитель, т.е. страна, жанр фильма. Также можно узнать продолжительность фильма и год выпуска. Таблица Прокат показывает такую важную информацию, как отметка о возврате и цена проката видеодиска.

2. Определение таблиц, которые должна содержать база данных

Один из наиболее сложных этапов в процессе создания базы данных - разработка таблиц, так как результаты, которые должна выдавать база данных не всегда дают полное представление о структуре таблицы.

Таблицы должны содержать всю информацию разрабатываемой базы. В моем случае это Видеодиски, Клиенты, Прокат, Режиссеры, Жанры и Страна. Все таблицы хранят максимально полную характеристику, информацию и описание для дальнейшей успешной работы с базой данных.

3. Присвоение ключевых полей

Для связи данных из разных таблиц, например, данные о заказчике и продукции, каждая таблица должна содержать набор полей или поле, где будет задаваться индивидуальное значение каждой записи в таблице. Такое поле или набор полей называют основным ключом. Именно благодаря ключам будет функционировать база данных, сопоставляя, связывая и формируя информацию из разных таблиц. Количество ключей варьируется от одного до нескольких. Вообще, ключ - это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности.

4. Редактирование структуры базы данных

Для проверки правильности работы базы необходимо создать несколько таблиц, определить связи между ними и ввести несколько записей в каждую таблицу, а затем посмотреть, отвечает ли база данных поставленным требованиям. Рекомендуется также создать отчеты и формы и проверить, выдают ли они требуемую информацию. Кроме того, необходимо исключить всевозможные повторения данных. Иначе база не будет работать и выдавать нужный запрос или информацию или будет работать с ошибками, что для серьезной организации неприемлемо.

5. Добавление данных и создание других объектов базы данных

Если структуры таблиц отвечают поставленным требованиям, то можно вводить все данные (в режиме конструктора таблиц). После ввода создаются любые запросы, формы, отчеты, макросы и модули (удобнее, проще и правильнее создавать все с помощью мастеров).

Инфологическая модель

Прежде чем начинать проектирование базы данных, необходимо разобраться, как функционирует предметная область создаваемой БД. Для этих целей используют искусственные формализованные языковые средства. В связи с этим под инфологической моделью понимают описание предметной области, выполненное с использованием специальных языковых средств, не зависящих от используемых в дальнейшем программных средств. Вообще, лучше сначала нарисовать на бумаге таблицы с данными, потом преобразовать их из 1 Нормальной Формы во Вторую, и из Второй - в Третью. Так удобнее будет.

Определяют три основные класса сущностей:

стержневые

ассоциативные

характеристические.

Стержневая сущность - независимая сущность, которая имеет независимое существование, хотя может обозначать другие сущности.

Характеристическая сущность (характеристика) - это связь вида "многие-к-одному" или "одна-к-одной" между двумя сущностями (частный случай ассоциации). Цель характеристики состоит в описании или уточнении некоторой другой сущности предметной области.

Ассоциативная сущность (ассоциация) - это связь вида "многие-ко-многим" между двумя или более сущностями или экземплярами сущности.

Это теория. Для наглядности покажу на примере торговой организации:

Стержневая сущность

«Видеодиски», «Клиент», «Прокат»

Видеодиски (Название фильма, режиссер, жанр фильма, страна производитель, год выпуска, продолжительность).

Клиенты (Данные Удостоверения Личности, ФИО, Телефон).

Прокат (Код УДЛ, Код Клиента, Код диска, Дата выдачи, Количество дней, Стоимость, Отметка о возврате).

Характеристическая сущность.

«Режиссеры», «Жанры», «Страны».

Режиссеры (Код Режиссера, ФИО Режиссера).

Жанры (Код жанра,жанр).

Страны (Код страны, Страна).

Даталогическая модель.

Структура моей базы данных.

Моя База Данных содержит 6 таблиц:

Видеодиски.

Режиссеры.

Клиенты.

Во всех таблицах в режиме конструктора указываются первичные ключи.

Таблица Видеодиски: предназначена для хранения всех видеодисков с полным их описанием. Например, кем произведены, когда и продолжительность фильма.

Код диска - присваивается самостоятельно.

Название фильма - вводится вручную в режиме конструктора название фильма.

Режиссер - берется из таблицы Режиссеры

Страна производитель - производитель фильма. Берется из таблицы Страны.

Жанр фильма - поле, в котором содержится Код жанра фильма. Данные берутся из таблицы Жанры.

Год выпуска - Год выпуска фильма. Значение вводится вручную.

Продолжительность - продолжительность фильма. Время вводится от руки.

Таблица Клиенты: дает описание всех клиентов данной организации.

Данные Удостоверения личности - данные удостоверения личности клиента.

ФИО и Телефон - более подробная информация. Все поля таблицы заполняются пользователем.

Таблица Режиссеры состоит из двух полей:

Код Режиссера - Код режиссера

ФИО режиссера - поле предоставляет Фамилию Имя о режиссере.

Таблица Жанры: состоит из двух полей:

В таблице указывается Код жанра и сам жанр.

Таблица Страны: состоит из двух полей:

Таблица содержит Код страны и Страну.

Таблица Прокат: содержит полную информацию о прокате видеодиска:

Код УДЛ - код удостоверения личности клиента.

Код клиента - код клиента берущего на прокат видеодиск. Берется из таблицы Клиенты.

Код диска - берется из таблицы Видеодиски.

Дата выдачи - дата выдачи диска, вводится вручную.

Количество дней - срок, на который берется видеодиск на прокат. Вводится самостоятельно.

Стоимость - цена определяется пользователем.

Отметка о возврате - при получении диска обратно, информация отмечается в данном поле.

Аннотация: Определяется процесс создания базы данных. Описываются операторы создания, изменения базы данных. Рассматривается возможность указания имени файла или нескольких файлов для хранения данных, размеров и местоположения файлов. Анализируются операторы создания, изменения, удаления пользовательских таблиц. Приводится описание параметров для объявления столбцов таблицы. Дается понятие и характеристика индексов. Рассматриваются операторы создания и изменения индексов. Определяется роль индексов в повышении эффективности выполнения операторов SQL.

База данных

Создание базы данных

В различных СУБД процедура создания баз данных обычно закрепляется только за администратором баз данных . В однопользовательских системах принимаемая по умолчанию база данных может быть сформирована непосредственно в процессе установки и настройки самой СУБД. Стандарт SQL не определяет, как должны создаваться базы данных , поэтому в каждом из диалектов языка SQL обычно используется свой подход. В соответствии со стандартом SQL, таблицы и другие объекты базы данных существуют в некоторой среде. Помимо всего прочего, каждая среда состоит из одного или более каталогов , а каждый каталог – из набора схем . Схема представляет собой поименованную коллекцию объектов базы данных , некоторым образом связанных друг с другом (все объекты в базе данных должны быть описаны в той или иной схеме ). Объектами схемы могут быть таблицы , представления, домены, утверждения, сопоставления, толкования и наборы символов. Все они имеют одного и того же владельца и множество общих значений, принимаемых по умолчанию.

Стандарт SQL оставляет за разработчиками СУБД право выбора конкретного механизма создания и уничтожения каталогов , однако механизм создания и удаления схем регламентируется посредством операторов CREATE SCHEMA и DROP SCHEMA . В стандарте также указано, что в рамках оператора создания схемы должна существовать возможность определения диапазона привилегий, доступных пользователям создаваемой схемы . Однако конкретные способы определения подобных привилегий в разных СУБД различаются.

В настоящее время операторы CREATE SCHEMA и DROP SCHEMA реализованы в очень немногих СУБД. В других реализациях, например, в СУБД MS SQL Server, используется оператор CREATE DATABASE .

Создание базы данных в среде MS SQL Server

Процесс создания базы данных в системе SQL-сервера состоит из двух этапов: сначала организуется сама база данных , а затем принадлежащий ей журнал транзакций . Информация размещается в соответствующих файлах, имеющих расширения *.mdf (для базы данных ) и *.ldf . (для журнала транзакций ). В файле базы данных записываются сведения об основных объектах (таблицах , индексах , представлениях и т.д.), а в файле журнала транзакций – о процессе работы с транзакциями (контроль целостности данных, состояния базы данных до и после выполнения транзакций).

Создание базы данных в системе SQL-сервер осуществляется командой CREATE DATABASE . Следует отметить, что процедура создания базы данных в SQL-сервере требует наличия прав администратора сервера.

<определение_базы_данных> ::= CREATE DATABASE имя_базы_данных [ <определение_файла> [,...n] ] [,<определение_группы> [,...n] ] ] [ LOG ON {<определение_файла>[,...n] } ] [ FOR LOAD | FOR ATTACH ]

Рассмотрим основные параметры представленного оператора.

При выборе имени базы данных следует руководствоваться общими правилами именования объектов. Если имя базы данных содержит пробелы или любые другие недопустимые символы, оно заключается в ограничители (двойные кавычки или квадратные скобки). Имя базы данных должно быть уникальным в пределах сервера и не может превышать 128 символов.

При создании и изменении базы данных можно указать имя файла, который будет для нее создан, изменить имя, путь и исходный размер этого файла. Если в процессе использования базы данных планируется ее размещение на нескольких дисках, то можно создать так называемые вторичные файлы базы данных с расширением *.ndf . В этом случае основная информация о базе данных располагается в первичном (PRIMARY ) файле, а при нехватке для него свободного места добавляемая информация будет размещаться во вторичном файле . Подход, используемый в SQL-сервере, позволяет распределять содержимое базы данных по нескольким дисковым томам.

Параметр ON определяет список файлов на диске для размещения информации, хранящейся в базе данных .

Параметр PRIMARY определяет первичный файл . Если он опущен, то первичным является первый файл в списке.

Параметр LOG ON определяет список файлов на диске для размещения журнала транзакций . Имя файла для журнала транзакций генерируется на основе имени базы данных , и в конце к нему добавляются символы _log .

При создании базы данных можно определить набор файлов, из которых она будет состоять. Файл определяется с помощью следующей конструкции:

<определение_файла>::= ([ NAME=логическое_имя_файла,] FILENAME="физическое_имя_файла" [,SIZE=размер_файла ] [,MAXSIZE={max_размер_файла |UNLIMITED } ] [, FILEGROWTH=величина_прироста ])[,...n]

Здесь логическое имя файла – это имя файла, под которым он будет опознаваться при выполнении различных SQL-команд.

Физическое имя файла предназначено для указания полного пути и названия соответствующего физического файла, который будет создан на жестком диске. Это имя останется за файлом на уровне операционной системы.

Параметр SIZE определяет первоначальный размер файла; минимальный размер параметра – 512 Кб, если он не указан, по умолчанию принимается 1 Мб.

Параметр MAXSIZE определяет максимальный размер файла базы данных . При значении параметра UNLIMITED максимальный размер базы данных ограничивается свободным местом на диске.

При создании базы данных можно разрешить или запретить автоматический рост ее размера (это определяется параметром FILEGROWTH ) и указать приращение с помощью абсолютной величины в Мб или процентным соотношением. Значение может быть указано в килобайтах, мегабайтах, гигабайтах, терабайтах или процентах (%). Если указано число без суффикса МБ, КБ или %, то по умолчанию используется значение MБ. Если размер шага роста указан в процентах (%), размер увеличивается на заданную часть в процентах от размера файла. Указанный размер округляется до ближайших 64 КБ.

Дополнительные файлы могут быть включены в группу:

<определение_группы>::=FILEGROUP имя_группы_файлов <определение_файла>[,...n]

Пример 3.1 . Создать базу данных , причем для данных определить три файла на диске C, для журнала транзакций – два файла на диске C.

CREATE DATABASE Archive ON PRIMARY (NAME=Arch1, FILENAME=’c:\user\data\archdat1.mdf’, SIZE=100MB, MAXSIZE=200, FILEGROWTH=20), (NAME=Arch2, FILENAME=’c:\user\data\archdat2.mdf’, SIZE=100MB, MAXSIZE=200, FILEGROWTH=20), (NAME=Arch3, FILENAME=’c:\user\data\archdat3.mdf’, SIZE=100MB, MAXSIZE=200, FILEGROWTH=20) LOG ON (NAME=Archlog1, FILENAME=’c:\user\data\archlog1.ldf’, SIZE=100MB, MAXSIZE=200, FILEGROWTH=20), (NAME=Archlog2, FILENAME=’c:\user\data\archlog2.ldf’, SIZE=100MB, MAXSIZE=200, FILEGROWTH=20) Пример 3.1. Создание базы данных.