Что такое база данных и как она используется для сайтов. База данных зачем нужна


Для чего нужна база данных на сайте: простое и понятное объяснение

Здравствуйте, уважаемые читатели блога start-luck. Сегодня обойдемся без шуток. Я решил написать статью на достаточно серьезную и сложную тему. Постараюсь изложить ее так, чтобы каждому было понятно. Вопрос непростой, а потому вам придется настроиться на восприятие, а мне очень постараться, чтобы дать ответы на все вопросы.

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

Зачем она нужна

Прежде чем создать сайт, человек в идеале сначала изучает html, затем css, ну и потом JavaScript. Первое помогает справиться с текстом, второе определяет дизайн, третье дает возможность создавать скрипты. Кстати, такой подход – явная заявка на успех в интернет-сфере.

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

Даже если вы все это постигли и на данный момент создали портал по всем правилам, пока его нельзя назвать динамическим. Им он станет после того, как перестанет просто лежать на сервере, а начнет обновляться.

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

Давайте предположим, вы создаете не сайт, а библиотеку. Это поможет разобраться с БД (базами данных). Вполне реальную библиотеку с полками и всем прочим. Человек приходит и видит где стоят книги, это видимая часть контента, то есть сами статьи на портале.

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

Картотека – это архив с небольшими записочками, в которые внесена вся основная информация о изданиях: где расположена книга, кто ее автор, в каком году он ее написал. Это и есть база данных. Только сейчас мы говорим о базе для сайта.

Когда книг не много, то можно обойтись и без архива, у вас все на виду. Вы найдете необходимый материал, но когда у вас огромный портал вы или ваш читатель потратит уйму времени, пока не отыщет нужное среди книг и полок.

Существуют движки, которые себе в преимущество ставят то, что они обходятся без Mysql. Но что это значит? По факту, где-то должен располагаться текстовый документ, в котором все равно находится информация о новых публикациях.

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

Реляционная база данных

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

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

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

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

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

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

Чтобы каждый раз не писать «слева» и «справа», ведь числа читать проще не только нам, но и машинам. Существует другая таблица, в которой обозначено лево – цифрой 1, а право – 2. В итоге, третья колонка у нас состоит только из этих обозначений: 1 и 2, но чтобы получить расшифровку, нужно обратиться к третьей таблицу, получить внешний ключ.

Именно на этом принципе и строятся реляционные таблицы. Все они взаимосвязаны. Без одной вам не получить информацию о другой.

SQL и MySQL

Из предыдущей главы, думаю, в общих чертах вы поняли, что такое SQL. Переводится эта аббревиатура как язык структурированных запросов. Создана она для того, чтобы работа с разными типами баз данных строилась по одному стандарту, а значит и управлять бы ей стало легче.

Что же можно делать при помощи этого языка? Создавать и менять структуру базы, сортировать, добавлять новые записи и так далее. Однако, не все так просто. Зная язык программирования его нужно еще и применять каким-то образом.

Зная html и css многие все равно обращаются к таким программам как Dreamweaver или Notepad++, чтобы было удобнее и быстрее работать. В конце концов они открывают хотя бы обычный блокнот, чтобы выполнять эти операции.

С SQL точно также. Для того чтобы его использовать, на хостинге устанавливается MySQL, через которую и ведется вся работа.

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

Стоит ли его изучать

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

Решать вам стоит ли срочно хвататься за книги. Если вы хотите научиться создавать мощные проекты с огромным бюджетом и потому по всем правилам, то да, тем более, что это не займет так уж много времени. Особенно если сравнивать с силами.

Могу предложить вам две книги для изучения языка. «SQL за 10 минут» Бена Форта. Учебник с краткой информацией и конкретными примерами. Напрягать мозг придется минимально, особенно если у вас уже есть какие-то знания, то это лучший вариант.

Второй учебник более основателен. Называется «SQL для чайников» от Аллена Тейлора. Создан он в лучших традициях издательства «Вильямс». Многим знакома эта серия хотя бы внешне. Что могу сказать о содержании? Все очень скрупулезно описано, не сомневаюсь, что поймет даже не слишком усидчивый ученик.

Ну вот и все. Теперь вы знаете что делать дальше. Подписывайтесь на рассылку и узнавайте больше о мире интернета. До новых встреч и простоты в изучении.

start-luck.ru

что это такое, зачем она нужна, почему следует делать резервные копии

Тематический трафик – альтернативный подход в продвижении бизнеса

Мы выпустили новую книгу «Контент-маркетинг в социальных сетях: Как засесть в голову подписчиков и влюбить их в свой бренд».

Подпишись на рассылку и получи книгу в подарок!

База данных для сайта - это место на веб-сервере, где хранится контент веб-ресурса. Каждая база состоит из таблиц, в которой размещены записи — кортежи данных.

База данных по автомобилям состоит из множества таблиц. Это модели: ВАЗ, ГАЗ, FORD, VW, Ferrari и т.д. Каждая таблица имеет поля.

ВАЗ: 2101, 2104, 2105, 2107 и т.д.

В каждом поле внесены записи со значениям-характеристиками: цветовые гаммы, ЛС, мощность движка и т.д.

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

Базы данных и организация веб-ресурса

Каждый сайт состоит из HTML-страниц. На них есть определенный каркас — то, что одинаково на любой странице. И есть контент — на каждой странице он разный.

Раньше интернет-сайты создавали на чистом HTML, и это было неудобно, так как все данные были представлены как отдельные HTML-файлы. Нельзя было осуществлять поиск, группировку, сортировку информации. К тому же, информация могла часто дублироваться. При появлении PHP у веб-мастеров появилась возможность разделения сайта на его каркас и данные в базе. Теперь структуру сайта можно хранить отдельно от контента, что позволяет быстрее и удобнее администрировать веб-ресурс, легко дорабатывать его дизайн и функционал.

Структура веб-ресурса хранится в коде или в отдельных шаблонах (специальных файлах). Контент размещается в базе данных - определенном наборе таблиц с однотипными данными.

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

Преимущества использования базы банных

  • Быстрое управление посредством СУБД. Любая система управления БД работает на языке запросов SQL. К примеру, для сортировки данных достаточно указать всего лишь один параметр в SQL-запросе.
  • Четкое структурирование и организация логики. К примеру, можно сделать выборку и точно узнать, сколько фото размещены в альбоме “Наше производство”. Или на сайте театра можно точно узнать, в каких спектаклях работает один катер.
  • С применением БД легко решаются такие вопросы как поиск, сортировка, пагинация (разбиение на материалов постранично), работа пользователей в личном кабинете.

Как работать с БД

Если вы в совершенстве владеете html и css, то все равно обращаетесь к Dreamweaver, чтобы снизить сложность работы с версткой сайта. Для работы с БД необходима также программа обработки SQL под названием MySQL. Она установлена на хостинге в оболочке phpMyAdmin.

По умолчанию сама БД сайта находится в каталоге data на веб-сервере интернет-проекта. К примеру, если БД имеет название bd, то все ее значения находятся в data/bd. Как правило, на хостинге доступ к файлам БД закрыт, их следует “вытягивать” посредством запросов SQL через консоль. Упрощает работу с запросами именно MySQL. Для того чтобы попасть в MySQL, необходимо зайти по ссылке, которую дает хостинг-провайдер, и ввести логин-пароль от базы.

Подключение базы к сайту происходит в конфигурационном файле при помощи указания названия, пользователя и пароля. Название файла и его и месторасположение зависит от вида вашей CMS. Для MODx это config.inc по пути /core/config/.

Резервное копирование - почему оно необходимо

Необходимо периодически создавать бэкапы — резервные копии сайта и базы данных. Обычно хостинги предоставляют услуги по созданию копий сайта.

Это нужно:

  • Чтобы “откатить” неудачные изменения на сайте и вернуться к предыдущей версии.
  • Для восстановления веб-ресурса после вирусной атаки или взлома сайта.
  • Для восстановления после сбоев.

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

semantica.in

Для чего нужны базы данных на предприятиях и в бизнесе?

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

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

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

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

Еще одну, очень большую проблему решает введение программного обеспечения (ПО) на предприятии — это скрытие информации для разных отделов. С этого момента подробнее. Например, бухгалтерия ведет учет клиентов и платежей. Сотрудники отдела продаж хотят видеть данные о клиентах, заказах, встречах и т.д. А секретарю важны только координаты клиентов. При этом некоторые отделы не хотят показывать ту или иную информацию другим отделам. Согласитесь, зачем секретарю предоставлять информацию о доходах предприятия.

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

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

А если ваше ПО работает еще и через интернет, то приятным бонусом будет поработать дома, а не в офисе, так как вся информация всегда с собой.

exaoffice.ru

Введение в базы данных Зачем нужны базы

Введение в базы данных

Зачем нужны базы данных ? - Есть «идеальное» средство работы с электронными таблицами Microsoft Excel, позволяющее делать с содержимым таблиц практически все, что угодно - Ни чуть не хуже обычные текстовые файлы, хранящие необходимые данные в некотором формате и не нужно быть великим программистом, чтобы написать программу, работающую с этими данными на любом языке программирования Зачем же нужны всякие там СУБД, стоящие десятки тысяч долларов, когда уже и так все есть ? ? ?

Присматриваясь внимательно… Файл имеет определенную структуру, нарушение которой потребует внесение изменений в текст программ, работающих с данным файлом Для того, чтобы другой программист смог воспользоваться данными из этого файла, он должен обязательно знать его структуру, которая обязательно должна оставаться неизменной Что проще – изменить 5 – 10 прикладных программ, выбирающих из данного файла строки определенной длины для увеличения размера выбираемых данных или создать еще один файл, с которым будет работать 11 -ая программа ?

Что получается ? n Полное отсутствие гибкости (изменение структуры – изменение программного текста) n Невозможность нормальной многопользовательской работы с данными и как следствие – усложнение написания прикладных программ (каждый разработчик, должен «идти на компромисс» с другими разработчиками при работе с файлами) n Вынужденная избыточность (проще создать еще одну копию данных, чем вносить изменения в десятки программ)

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

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

О моделях данных Не является тайной, то что планируемые к внесению в базу данных данные в подавляющем большинстве случаев связаны между собой. (Например, с отделом связано множество сотрудников, с которыми в свою очередь связаны должности, которые они занимают …). Наличие множества связей требует создания определенной структуры описания данных, которые называются моделями данных. Исторически первой появилась иерархическая модель, например == Отдел ==> сотрудники ==> должности == Однако оказалось, что поиск данных от листьев к корню выполняется значительно медленнее, чем от корня к листьям (быстрый запрос — должности занимаемые сотрудником, медленный запрос — количество программистов в каждом отделе работающих на 0. 5 ставки). Созданная сетевая модель (связанные кольца двухуровневых деревьев), оказалась настолько сложной, что проектированием данных могли заниматься только высококвалифицированные специалисты.

Реляционная модель В 70 гг. была предложена реляционная (relation — отношение, связь) или иначе табличная модель данных, обладающая следующими основными свойствами: 1. Данные воспринимаются пользователями как таблицы (и никак иначе). 2. Каждая таблица состоит из однотипных строк и имеет уникальное имя. 3. Строки имеют фиксированное число полей (столбцов) и значений (множественные поля и повторяющиеся группы недопустимы). Иначе говоря, в каждой позиции таблицы на пересечении строки и столбца всегда имеется в точности одно значение или ничего.

Реляционная модель (продолжение) 4. Строки таблицы обязательно отличаются друг от друга хотя бы единственным значением, что позволяет однозначно идентифицировать любую строку такой таблицы. 5. Столбцам таблицы однозначно присваиваются имена, и в каждом из них размещаются однородные значения данных (даты, фамилии, целые числа или денежные суммы). 6. При выполнении операций с таблицей ее строки и столбцы можно обрабатывать в любом порядке безотносительно к их информационному содержанию. Этому способствует наличие имен таблиц и их столбцов, а также возможность выделения любой их строки или любого набора строк с указанными признаками.

Попытаемся разобраться на примере… Какая таблица является таблицей реляционной базы данных ? Для этого рассмотрим в качестве примера предметную область «Кадры сотрудников организации» … Мы будем работать со сведениями о сотрудниках, включающих информацию : n ФИО, пол, дата рождения n Должность и отдел, где сотрудник работает n Даты оформления и увольнения сотрудника на работу, или срок работы (если сотрудник принимался на период времени) n Условия приема сотрудника на некоторую должность в некоторый отдел (основное, совместительство) n Сведения о заработной плате

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

Таблица_сотрудников ид фамилия имя отчество дата_рождения пол отдел должность условия_приема зарплата Наша таблица удовлетворяет всем требованиям реляционной модели ! Таблица состоит из однотипных строк и имеет уникальное имя Строки имеют фиксированное число полей (столбцов) и значений (множественные поля и повторяющиеся группы недопустимы). Иначе говоря, в каждой позиции таблицы на пересечении строки и столбца всегда имеется в точности одно значение или ничего. Строки таблицы обязательно отличаются друг от друга хотя бы единственным значением, что позволяет однозначно идентифицировать любую строку такой таблицы. Столбцам таблицы однозначно присваиваются имена, и в каждом из них размещаются однородные значения данных (даты, фамилии, целые числа или денежные суммы).

Таблица_сотрудников ид фамилия имя отчество дата_рождения пол отдел должность условия_приема зарплата Однако, возникают некоторые проблемы, которые не решены при организации данной таблицы Данные большинства столбцов в нашей таблице многократно повторяются т. е. возникает избыточность. Так, для каждого сотрудника одного и того же отдела будут повторяться названия должности, и соответственно если сотрудник работает в разных отделах с разными условиями приема ( «основное» , «совместительство» ), для него будут повторяться фамилия, имя, отчество

Таблица_сотрудников ид фамилия имя отчество дата_рождения пол отдел должность условия_приема зарплата Вследствие избыточности могут возникать проблемы при изменении данных Аномалии обновления. Если, например, сотрудница поменяла фамилию, то при изменении в таблице множества экземпляров ее фамилии можно «забыть» обновить некоторые строки со старой фамилией и тем самым «потерять» какие-либо данные об этой сотруднице. Аномалии включения. В таблицу нельзя внести данные о том, какие должности будут введены в организации в будущем месяце, до тех пор, пока на эти должности не будут приняты или переведены какие-либо сотрудники. Аномалии удаления. Обратные проблемы возникают при необходимости удаления из таблиц сведений о каком-либо сотруднике или должности.

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

Таблица_сотрудников ид фамилия имя отчество дата_рождения пол отдел должность условия_приема зарплата Выделим из нашей таблицы сотрудников «независимые» (стержневые) таблицы и «зависимые» таблицы В независимые стержневые таблицы можно выделить следующую информацию • Информацию о людях, имеющих отношение к организации (назовем эту таблицу ЛЮДИ) • Информацию об отделах, существующих в организации (назовем эту таблицу ОТДЕЛЫ) • Информацию о должностях, существующих в организации (назовем эту таблицу ДОЛЖНОСТИ) В зависимые таблицы можно выделить следующую информацию • Информацию о сотрудниках, работающих в организации (назовем эту таблицу СОТРУДНИКИ)

В процессе определения столбцов таблицы необходимо обязательно определить их первичные ключи Ключ — минимальный набор столбцов, по значениям которых можно однозначно найти требуемую строку таблицы. Минимальность означает, что исключение из набора любого из столбцов не позволяет идентифицировать строку по оставшимся значениям. Первичный ключ — любой из возможных ключей (лучше несоставной и целочисленный). В большинстве случаев имеет смысл ввести дополнительный столбец, значения которого были бы уникальными и он как раз и был бы первичным ключом для некоторой таблицы. Так например, для таблицы ЛЮДИ логично ввести дополнительный столбец – «табельный номер» , который и будет однозначно идентифицировать строку таблицы.

Внешние ключи Для зависимых таблиц необходимо рассмотреть еще одно понятие — внешний ключ. Это столбец или набор столбцов зависимой (дочерней) таблицы, с помощью которого (которых) производится ссылка на первичный ключ другой (родительской) таблицы, т. е. как бы производится связывание таблиц. При этом родительской может быть как независимая, так и зависимая таблица — цепочка связей между таблицами ничем не ограничивается и может иметь чрезвычайно сложную структуру.

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

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

Получим наконец-то нашу «правильную» базу данных ! Таблица «ЛЮДИ» ЛЮДИ Ид Фамилия Имя Отчество Дата_рождения Пол Ид – уникальный идентификатор человека, столбец – первичный ключ. Каждый новый номер целесообразно получать с помощью процедуры, наращивающей последний существующий номер на единицу. Пол – пол человека, может быть только «м» или «ж» В случае острой необходимости возможно ввести и другие ограничения, например на регистр в ФИО и интервал дат в дате рождения

Таблица «ОТДЕЛЫ» ОТДЕЛЫ Ид Наименование Отд_ид Ид – уникальный идентификатор отдела, столбец – первичный ключ. Наименование – полное наименование отдела Отд_ид – идентификатор отдела, подразделением которого является данный отдел. Например, Для головного отдела организации, в отд_ид заносится NULL. Например, кафедра ВТ, принадлежит факультету КТи. У, который в свою очередь является подразделением университета. Поле Отд_ид является внешним ключом к полю Ид

Таблица «ДОЛЖНОСТИ» (Совсем все просто) ДОЛЖНОСТИ Ид Наименование Ид – уникальный идентификатор должности, столбец – первичный ключ. Наименование – полное наименование должности

Таблица «СОТРУДНИКИ» СОТРУДНИКИ Ид Члвк_ид Долж_ид Отд_ид Зарплата Ставка Условия_приема Начало Конец Ид – уникальный идентификатор должности, столбец – первичный ключ. Члвк_ид – идентификатор человека, внешний ключ к таблице ЛЮДИ, не может быть NULL Долж_ид – идентификатор должности, внешний ключ к таблице ДОЛЖНОСТИ, не может быть NULL Отд_ид – идентификатор отдела, внешний ключ к таблице ОТДЕЛЫ, не может быть NULL Зарплата, ставка – числовые поля (с точностью до сотых) Условия приема – каким образом оформлен сотрудник на некоторую должность в некотором отделе, в поле могут заноситься только значения «основное» , «совместительство» Начало, конец – даты начала и окончания срока работы сотрудника по некоторой должности в некотором отделе. Конец по умолчанию устанавливается « 09. 9999» , т. е. срок окончания работы не ограничивается.

Что получилось… Модель базы данных «КАДРЫ»

И что теперь с этим делать ? Теперь у нас есть модель которую можно описать на языке SQL и создать в системе уже реальные таблицы. Язык SQL (Structured Query Language, структуризованный язык запросов) – это набор команд, необходимых всем программам и пользователям для работы с базой данных. Язык разработан в 1974 году фирмой IBM для экспериментальной реляционной СУБД System R. После появления на рынке двух пионерских СУБД этой фирмы - SQL/DS (1981 год) и DB 2 (1983 год) - он приобрел статус стандарта де-факто для профессиональных реляционных СУБД. В 1987 году SQL стал международным стандартом языка баз данных, а в 1992 году вышла вторая версия этого стандарта.

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

В основе синтаксиса SQL лежат следующие основные команды n SELECT - используется для извлечения данных из таблиц n UPDATE – для внесения изменений в существующие данные в n INSERT – предназначена для добавления данных в таблицы n DELETE – для удаления данных из таблиц n CREATE – используется для создания объектов базы данных n ALTER – для внесения изменений в определения объектов и n DROP – используется для удаления объектов из базы данных таблицах параметры базы данных

Существующие на сегодняшний день СУБД можно разделить на несколько групп: Промышленные - Интенсивно развивающиеся Oracle, DB 2, Microsoft SQL Server - Существующие Ingress, Informix и т. д. Малые Postgre. SQL, My. SQL, Access и т. д.

present5.com

Для чего сайту нужна база данных?

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

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

Структуру сайта обычно хранят непосредственно в коде (допустим, в PHP-скриптах), либо в отдельных файлах, так называемых шаблонах. Встает вопрос, как хранить контент сайта. Вот для этой задачи как нельзя лучше подходит база данных. С точки зрения движка веб-сайта база данных представляет собой набор таблиц. Каждая таблица — это сущность, в которой хранятся однотипные данные.

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

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

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

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

www.myfirstsite.ru

СУБД - это система управления данными

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

субд этоЧто такое база данных

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

что такое субдЧто такое СУБД

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

субд mysqlЗачем нужна СУБД Mysql

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

- многопоточностью, то есть одновременно в этой системе могут выполняться несколько запросов;

- простотой построения сервера;

- надежной системой защиты, включающей гибкую структуру паролей и прав;

- возможность использование данных как фиксированной, так и переменной длины;

- качественной системой хранения, основанной на потоках;

- возможность размещения до 16 ключей в таблице.

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

Mysql, как СУБД, это удобная и логичная система, которая позволяет выполнять все необходимые операции над данными.

fb.ru

Зачем нужна денормализация баз данных, и когда ее использовать

В нашем блоге на Хабре мы не только рассказываем о развитии своего продукта — биллинга для операторов связи «Гидра», но и публикуем материалы о работе с инфраструктурой и использовании технологий.

Недавно мы писали об использовании Clojure и MongoDB, а сегодня речь пойдет о плюсах и минусах денормализации баз данных. Разработчик баз данных и финансовый аналитик Эмил Дркушич (Emil Drkušić) написал в блоге компании Vertabelo материал о том, зачем, как и когда использовать этот подход. Мы представляем вашему вниманию главные тезисы этой заметки.

Что такое денормализация?
Обычно под этим термином понимают стратегию, применимую к уже нормализованной базе данных с целью повышения ее производительности. Смысл этого действия — поместить избыточные данные туда, где они смогут принести максимальную пользу. Для этого можно использовать дополнительные поля в уже существующих таблицах, добавлять новые таблицы или даже создавать новые экземпляры существующих таблиц. Логика в том, чтобы снизить время исполнения определенных запросов через упрощение доступа к данным или через создание таблиц с результатами отчетов, построенных на основании исходных данных.

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

Рассмотрим нормализованную модель для простейшей CRM-системы:

Пробежимся по имеющимся здесь таблицам:

  • Таблица user_account хранит данные о пользователях, зарегистрированных в приложении (для упрощения модели роли и права пользователей из нее исключены).
  • Таблица client содержит некие базовые сведения о клиентах.
  • Таблица product — это список предлагаемых товаров.
  • Таблица task содержит все созданные задачи. Каждую из них можно представить в виде набора согласованных действий по отношению к клиенту. Для каждой есть список звонков, встреч, предложенных и проданных товаров.
  • Таблицы call и meeting хранят данные о заказах и встречах с клиентами и связывают их с текущими задачами.
  • Словари task_outcome, meeting_outcome и call_outcome содержат все возможные варианты результата звонков, встреч и задания.
  • product_offered хранит список продуктов, которые были предложены клиентам;
  • product_sold — продукты, которые удалось продать.
  • Таблица supply_order хранит информацию обо всех размещенных заказах.
  • Таблица writeoff содержит перечень списанных по каким-либо причинам товаров.
В этом примере база данных сильно упрощена для наглядности. Но нетрудно увидеть, что она отлично нормализована — в ней нет никакой избыточности, и все должно работать, как часы. Никаких проблем с производительностью не возникает до того момента, пока база не столкнется с большим объёмом данных.
Когда полезно использовать денормализацию
Прежде чем браться разнормализовывать то, что уже однажды было нормализовано, естественно, нужно четко понимать, зачем это нужно? Следует убедиться, что выгода от применения метода перевешивает возможные негативные последствия. Вот несколько ситуаций, в которых определенно стоит задуматься о денормализации.
  1. Сохранение исторических данных. Данные меняются с течением времени, но может быть нужно сохранять значения, которые были введены в момент создания записи. Например, могут измениться имя и фамилия клиента или другие данные о его месте жительства и роде занятий. Задача должна содержать значения полей, которые были актуальны на момент создания задачи. Если этого не обеспечить, то восстановить прошлые данные корректно не удастся. Решить проблему можно, добавив таблицу с историей изменений. В таком случае SELECT-запрос, который будет возвращать задачу и актуальное имя клиента будет более сложным. Возможно, дополнительная таблица — не лучший выход из положения.
  2. Повышение производительности запросов. Некоторые запросы могут использовать множество таблиц для доступа к часто запрашиваемым данным. Пример — ситуация, когда необходимо объединить до 10 таблиц для получения имени клиента и наименования товаров, которые были ему проданы. Некоторые из них, в свою очередь, могут содержать большие объемы данных. При таком раскладе разумным будет добавить напрямую поле client_id в таблицу products_sold.
  3. Ускорение создания отчетов. Бизнесу часто требуется выгружать определенную статистику. Создание отчетов по «живым» данным может требовать большого количества времени, да и производительность всей системы может в таком случае упасть. Например, требуется отслеживать клиентские продажи за определенный промежуток по заданной группе или по всем пользователям разом. Решающий эту задачу запрос в «боевой» базе перелопатит ее полностью, прежде чем подобный отчет будет сформирован. Нетрудно представить, насколько медленнее все будет работать, если такие отчеты будут нужны ежедневно.
  4. Предварительные вычисления часто запрашиваемых значений. Всегда есть потребность держать наиболее часто запрашиваемые значения наготове для регулярных расчетов, а не создавать их заново, генерируя их каждый раз в реальном времени.
Вывод напрашивается сам собой: не следует обращаться к денормализации, если не стоит задач, связанных с производительностью приложения. Но если чувствуется, что система замедлилась или скоро замедлится, впору задуматься о применении данной техники. Однако, прежде чем обращаться к ней, стоит применить и другие возможности улучшения производительности: оптимизацию запросов и правильную индексацию.
Не все так гладко
Очевидная цель денормализации — повышение производительности. Но всему есть своя цена. В данном случае она складывается из следующих пунктов:
  • Место на диске. Ожидаемо, поскольку данные дублируются.
  • Аномалии данных. Необходимо понимать, что с определенного момента данные могут быть изменены в нескольких местах одновременно. Соответственно, нужно корректно менять и их копии. Это же относится к отчетам и предварительно вычисляемым значениям. Решить проблему можно с помощью триггеров, транзакций и хранимых процедур для совмещения операций.
  • Документация. Каждое применение денормализации следует подробно документировать. Если в будущем структура базы поменяется, то в ходе этого процесса нужно будет учесть все прошлые изменения — возможно, от них вообще можно будет к тому моменту отказаться за ненадобностью. (Пример: в клиентскую таблицу добавлен новый атрибут, что приводит к необходимости сохранения прошлых значений. Чтобы решить эту задачу, придется поменять настройки денормализации).
  • Замедление других операций. Вполне возможно, что применение денормализации замедлит процессы вставки, модификации и удаления данных. Если подобные действия проводятся относительно редко, то это может быть оправдано. В этом случае мы разбиваем один медленный SELECT-запрос на серию более мелких запросов по вводу, обновлению и удалению данных. Если сложный запрос может серьезно замедлить всю систему, то замедление множества небольших операций не отразится на качестве работы приложения столь драматических образом.
  • Больше кода. Пункты 2 и 3 потребуют добавления кода. В то же время они могут существенно упростить некоторые запросы. Если денормализации подвергается существующая база данных, то потребуется модифицировать эти запросы, чтобы оптимизировать работу всей системы. Также понадобится обновить существующие записи, заполнив значения добавленных атрибутов — это тоже потребует написания некоторого количества кода.
Денормализация на примере
В представленной модели были применены некоторые из вышеупомянутых правил денормализации. Синим отмечены новые блоки, розовым — те, что были изменены.

Что изменилось и почему?

Единственное нововведение в таблице product — строка units_in_stock. В нормализованной модели мы можем вычислить это значение следующим образом: заказанное наименование — проданное — (предложенное) — списанное (units ordered — units sold — (units offered) — units written off). Вычисление повторяется каждый раз, когда клиент запрашивает товар. Это довольно затратный по времени процесс. Вместо этого можно вычислять значение заранее так, чтобы к моменту поступления запроса от покупателя, все уже было наготове. С другой стороны, атрибут units_in_stock должен оновляться после каждой операции ввода, обновления или удаления в таблицах products_on_order, writeoff, product_offered и product_sold.

В таблицу task добавлено два новых атрибута: client_name и user_first_last_name. Оба они хранят значения на момент создания задачи — это нужно, потому что каждое из них может поменяться с течением времени. Также нужно сохранить внешний ключ, который связывает их с исходным пользовательским и клиентским ID. Есть и другие значения, которые нужно хранить — например, адрес клиента или информация о включенных в стоимость налогах вроде НДС.

Денормализованная таблица product_offered получила два новых атрибута: price_per_unit и price. Первый из них необходим для хранения актуальной цены на момент предложения товара. Нормализованная модель будет показывать лишь ее текущее состояние. Поэтому, как только цена изменится, изменится и «ценовая история». Нововведение не просто ускорит работу базы, оно улучшает функциональность. Строка price вычисляет значение units_sold * price_per_unit. Таким образом, не нужно делать расчет каждый раз, как понадобится взглянуть на список предложенных товаров. Это небольшая цена за увеличение производительности.

Изменения в таблице product_sold сделаны по тем же соображениям. С той лишь разницей, что в данном случае речь идет о проданных наименованиях товара.

Таблица statistics_per_year (статистика за год) в тестовой модели — абсолютно новый элемент. По сути, это денормализованная таблица, поскольку все ее данные могут быть рассчитаны из других таблиц. Здесь хранится информация о текущих задачах, успешно выполненных задачах, встречах, звонках по каждому заданному клиенту. В данном месте также хранится общая сумма проведенных начислений за каждый год. После ввода, обновления или удаления любых данных в таблицах task, meeting, call и product_sold приходится пересчитывать эти данные для каждого клиента и соответствующего года. Так как изменения, скорее всего, касаются лишь текущего года, отчеты за предыдущие годы теперь могут оставаться без изменений. Значения в этой таблице вычисляются заранее, поэтому мы сэкономим время и ресурсы, когда нам понадобятся результаты расчетов.

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

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

Наш опыт
Мы в Латере много занимаемся оптимизацией производительности нашей биллинговой системы «Гидра», что неудивительно, учитывая объемы наших клиентов и специфику телеком-отрасли.

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

«Гидра» имеет глубоко проработанную систему привилегий для пользователей, операторов биллинга. Права выдаются несколькими способами — можно разрешить определенные действия конкретному пользователю, можно заранее подготовить роли и выдать им разные наборы прав, можно наделить определенный отдел специальными привилегиями. Только представьте, насколько медленными стали бы обращения к любым сущностям системы, если бы каждый раз нужно было пройти всю эту цепочку, чтобы убедиться: «да, этому сотруднику разрешено заключать договоры с юридическими лицами» или «нет, у этого оператора недостаточно привилегий для работы с абонентами соседнего филиала». Вместо этого мы отдельно храним готовый агрегированный список действующих прав для пользователей и обновляем его, когда в систему вносятся изменения, способные на этот список повлиять. Сотрудники переходят из одного отдела в другой намного реже, чем открывают очередного абонента в интерфейсе биллинга, а значит вычислять полный набор их прав нам приходится настолько же реже.

Конечно, денормализация хранилища — это только одна из принимаемых мер. Часть данных стоит кэшировать и непосредственно в приложении, но если промежуточные результаты в среднем живут намного дольше, чем пользовательские сессии, есть смысл всерьез задуматься о денормализации для ускорения чтения.

Другие технические статьи в нашем блоге:

habr.com