Требования, предъявляемые к БД

Правильно спроектированная БД должна удовлетворять следующим требованиям:

1. Минимальная избыточность. Непротиворечивость.

2. Целостность данных.

3. Независимость данных.

4. Возможность ведения (добавления и удаления) и актуализации (корректировки, модификации) данных.

5. Безопасность и секретность.

6. Высокая производительность. Минимальные затраты.

7. Соблюдение стандартов.

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

-неоправданно большой расход памяти и уменьшение времени отклика системы при обработке излишне больших объемов данных.

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

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

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

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

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

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

Существуют специальные методы и приемы обеспечения целостности.

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

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

Целостность данных может нарушиться при неудачном завершении транзакции. Транзакцией называется некоторая неделимая последовательность операций над данными, выполняемая по одному запросу к БД. Примером транзакции является операция перевода денег с одного счета на другой в банковской системе. Здесь необходимо последовательное выполнение нескольких операций. Деньги снимаются с одного счета, данные корректируются, затем деньги добавляются к другому счету и данные вновь корректируются. Если хотя бы одно из действий не выполняется успешно, результат транзакции окажется неверным. СУБД должна отслеживать ход выполнения транзакции от начала до ее завершения. Если по какой-то причине какая-либо из операций не выполнилась, то транзакция отменяется полностью. При этом выполняется «откат» путем отмены всех уже выполненных изменений.

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

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

3. Независимость данных означает то, что прикладные программы не должны зависеть от хранимых данных, т.е. от способа хранения данных в физической памяти. Это позволяет добавлять в БД новые данные, изменять структуры хранения данных, создавать на БД новые приложения. Ранее созданные программы при этом не должны «чувствовать» эти изменения.

СУБД обычно обеспечивают это требование.

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

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

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

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

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

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

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

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

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

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

studopedia.org — Студопедия.Орг — 2014-2019 год. Студопедия не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования (0.003 с) .

Базы данных и СУБД на примере Microsoft Access

Понятие о базе данных и СУБД

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

  1. структурированностью;
  2. взаимосвязанностью;
  3. независимостью от прикладных программ.

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

Классификация БД

Базы данных можно классифицировать по разным признакам:

По характеру хранимой информации БД бывают:

  • фактографическими — хранящими краткую информацию в строго определенном формате, это, так называемые, картотеки;
  • документальными – к ним относятся всевозможные документы, причем не только текстовые, но и графические, звуковые (мультимедиа), а также видеофайлы – все это, так называемые, архивы.

По способу хранения данных (по техническим средствам) БД бывают:

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

По структуре организации данных БД бывают:

Попробуй обратиться за помощью к преподавателям

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

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

Современные СУБД должны удовлетворять требованиям:

  1. возможности манипулирования данными (например, ввод, выбор, вставка, обновление, удаление и др.);
  2. возможности поиска и формирования запроса;
  3. обеспечения целостности (согласованности) данных;
  4. обеспечения секретности и защиты данных (например, от несанкционированного доступа, от аппаратных сбоев).

Основными показателями в работе СУБД являются:

  1. высокая производительность;
  2. стоимость хранения и использования данных;
  3. простота в обращении к базе данных.

На сегодняшний день имеется большое количество СУБД, различающихся архитектурой, внутренним языком программирования, управляющей ими операционной системой и другими характеристиками. Среди СУБД, ориентированных на работу с конечным пользователем, для небольших организаций наиболее популярными являются MS Access, FoxPro, Paradox. Более сложными системами являются распределенные СУБД, предназначенные для работы с большими БД, которые распределены по нескольким серверам. К ним относятся Oracle, Sybase, Informix.

Задай вопрос специалистам и получи
ответ уже через 15 минут!

СУБД Microsoft Access

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

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

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

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

Смотрите так же:  Какая пенсия в узбекистане в 2019 году

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

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

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

Таким образом, объектами базы данных Microsoft Access являются:

  • таблицы – основной объект используется для хранения данных и структуры БД;
  • запросы – представлены специально созданными таблицами для отбора, сортировки и анализа данных;
  • формы – объекты для удобства ввода данных;
  • отчеты – выводят данные на бумагу в удобном для просмотра виде;
  • страницы – используются для работы в сети Интернет;
  • макросы – представляют собой макрокоманды для автоматизации повторяющихся операций;
  • модули – используются для обработки событий и вычислений.

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

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

При выходе из Microsoft Access измененные данные сохраняются автоматически. Однако при изменении структуры любого объекта базы данных в Microsoft Access выводится запрос на подтверждение сохранения этих изменений перед завершением работы.

Основными действиями, которые пользователь может выполнить, применяя СУБД являются:

  • создание структуры базы данных;
  • заполнение базы информацией;
  • изменение структуры и содержания базы данных;
  • поиск информации в базе;
  • сортировка данных;
  • защита базы данных.

Достоинства и недостатки Microsoft Access

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

Недостатками Microsoft Access явились слабые средства защиты и восстановления информации, ограничения на объем информации, отсутствие собственного языка программирования, низкая скорость при работе с большими объемами информации.

Так и не нашли ответ
на свой вопрос?

Просто напиши с чем тебе
нужна помощь

Требования к базе данных пример

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

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

При практической разработке БД таблицы-сущности зовутся таблицами, строки-экземпляры записями, столбцы-атрибуты — полями ТБД.

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

Понятие первичного ключа

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

Данные таблицы «Преподаватель»

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

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

Реляционные отношения (связи) между таблицами базы данных

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

Существует три разновидности связей между таблицами базы данных:

Отношение «один-ко-многим» имеет место, когда одной записи родительской таблицы может соответствовать несколько записей в дочерней таблице.

Связь «один-ко-многим» является самой распространенной для реляционных баз данных.

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

Отношение «один-к-одному» имеет место, когда одной записи в родительской таблице соответствует одна запись в дочерней таблице.

Данное отношение используют, если не хотят, чтобы таблица БД «не распухала» от второстепенной информации.

Отношение «многие-ко-многим» имеет место, когда:

а) записи в родительской таблице может соответствовать больше одной записи в дочерней таблице;

б) записи в дочерней таблице может соответствовать больше одной записи в родительской таблице.

Например, каждой студент изучает несколько дисциплин. Каждая дисциплина изучается несколькими студентами.

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

Ссылочная целостность и каскадные воздействия

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

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

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

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

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

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

· необходимо запретить изменение поля связи в записи дочерней таблицы без синхронного изменения полей связи в родительской таблице;

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

· при удалении записи в родительской таблице, следует удалить соответствующие записи в дочерней таблице.

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

Понятие внешнего ключа

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

Индексы и методы доступа

Индексы представляют собой механизмы быстрого доступа к данным в таблицах БД.

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

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

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

Определение первичных и внешних ключей таблиц БД приводят к созданию индексов по полям, объявленным в составе первичных или внешних ключей.

Нормализация таблиц при проектировании БД

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

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

Одной из таких формализаций является требование, согласно которому реляционная база данных должна быть нормализована. Процесс нормализации имеет своей целью устранение избыточности данных и заключается в приведении к третьей нормальной форме (3НФ).

Первая нормальная форма (1НФ) требует, чтобы каждое поле таблицы БД:

· не содержало повторяющихся групп.

Неделимость поля означает, что значение поля не должно делиться на более мелкие значения. Например, если в поле «Подразделение» содержится название факультета и название кафедры, требование неделимости не соблюдается и необходимо из данного поля выделить или название факультета, или кафедры в отдельное поле.

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

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

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

Пример логической модели базы данных «Сессия»

Требования к базам данных¶

Не используйте в именах таблиц и полей зарезервированные слова MySQL.

  • Таблицы, хранящие основные данные сущностей, именуются названием сущности в множественном числе. Для примера возьмём таблицу products , которая содержит основную информацию о товарах магазина.
  • Таблицы, хранящие дополнительные данные сущностей или дочерние сущности, именуются по шаблону сущность_суффикс . Добавляемый суффикс именуется во множественном числе. Для примера, таблица, содержащая цены товаров, называется product_prices .
  • Для понимания правил именования таблиц в более сложных случаях зависимостей таблиц друг от друга подойдёт такой пример:
    • products — хранит основную информацию о товарах;
    • product_features — хранит доступные для присвоения характеристики товаров;
    • product_feature_variants — хранит доступные для присвоения варианты характеристик товаров;
    • product_feature_variant_descriptions — хранит мультиязычные поля вариантов характеристик товаров для каждого языка.
Смотрите так же:  Оформить кредитную карту без регистрации

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

При установке системы администратор задаёт префикс, который будет использован при создании всех таблиц. Префикс по-умолчанию — cscart_ . В SQL-запросах, выполняемых из CS-Cart с помощью встроенных функций для работы с БД, выбранный префикс будет заменять собой плейсхолдер ?: . Таким образом, если вы упоминаете в SQL-запросе название таблицы, вы обязательно должны добавлять перед названием плейсхолдер ?: .

Названия полей первичных ключей¶

Исторически так сложилось, что поля и первичных, и внешних ключей именуются с префиксом названия сущности. Это означает, что, например, в таблице products поле с уникальным первичным ключом будет называться product_id. Cоветуем придерживаться этого правила при разработке модификаций CS-Cart. Даже если вы не согласны с таким правилом именования, это позволит всей кодовой базе выглядеть однотипно и однородно.

Интернационализация¶

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

Создаётся отдельная таблица с названием сущность_descriptions , в нашем примере это product_descriptions .

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

Кроме того, таблица должна содержать поле, которое будет содержать код языка, для которого добавлена запись в таблицу. Обычно это поле называется lang_code и имеет тип CHAR(2) .

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

В нашем примере это помимо прочих product — название товара, и full_description — подробное описание товара.

Необходимость реализации логики работы с такой таблицой ложится на PHP-код, в нашем примере она вкратце сводится к следующим пунктам:

При создании нового товара учитывать, какой язык выбран в для редактирования в панели администратора (константа DESCR_SL ) — сохранять данные в таблицу product_descriptions со значением поля lang_code равным значению константы DESCR_SL .

При выборке данных для отображения в клиентской части, нужно присоединять таблицу с мультиязычными данными по условию “lang_code равен выбранному пользователем языку в клиентской части (значение константы CART_LANGUAGE )”.

Пример подобного SQL-запроса:

Исторически сложилось, что для всех таблиц CS-Cart используется MyISAM. Однако ничто не мешает вам при необходимости сменить тип таблиц на InnoDB — система будет работать корректно в этом случае.

InnoDB имеет ряд преимуществ относительно MyISAM:

  • внешние ограничения;
  • продвинутое использование индексов в последних версиях MySQL;
  • транзакции;

Из-за особенностей внутреннего устройства запросы на запись и удаление данных в InnoDB могут занимать больше времени, чем в MyISAM.

Важно: внешние ограничения, которые вы можете добавить к таблицам в случае миграции на InnoDB, могут некорректно работать с порядком выполнения запросов изменения/удаления данных в CS-Cart. Например, при удалении категории сначала удаляется запись в таблице categories , а затем все дочерние товары и подкатегории. Это может вызвать проблемы с каскадными ограничениями ссылочной целостности вида ON UPDATE CASCADE / ON DELETE CASCADE — CS-Cart на уровне PHP-кода реализует обновление и удаление связанных сущностей.

Настоятельно рекомендуем реализовывать логику каскадного обновления/удаления данных именно в PHP-коде.

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

Целочисленные поля¶

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

Пример: Вы делаете флаговое поле (1,0) и решили использовать тип INT . Конечно тут нелогично использовать всю размерность поля INT — оно занимает 4 байта. Нужно использовать TINYINT (3) размером в 1 байт для экономии дискового пространтсва, выделяемого под данные. Так выборки будут шустрее.

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

Дополнительный числовой атрибут у типа поля вляет на отображение поэтому желательно его пропускать — MySQL сам выберет подходящую размерность. Например для TINYINT будет выбрано 3 а для SMALLINT — 5.

Описание INT полей есть на этой странице.

Сводная таблица диапазонов для INT полей, первым идёт диапазон для флага UNSIGNED :

Требования к базе данных пример

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

Во вводном уроке (номер 1) мы дали краткое, «на пальцах», толкование локальных и серверных баз данных и пояснили суть технологии клиент-сервер. На данном уроке мы рассмотрим процесс проектирования баз данных, общий для обеих технологий. И лишь детали его реализации будут различаться в разных архитектурах. Сразу оговоримся, что мы будем рассматривать только реляционные базы данных: во-первых, реляционные базы получили наибольшее распространение в мире; во-вторых, они наиболее «продвинуты» в научном плане; а в-третьих, ядро баз данных Borland Database Engine, на основе которого работают все последние продукты компании Borland, предназначено именно для работы с реляционными базами данных.

Жизненный цикл любого программного продукта, в том числе и системы управления базой данных, состоит (по-крупному) из стадий проектирования, реализации и эксплуатации.

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

Требования к базам данных

Итак, хорошо спроектированная база данных:

  • Удовлетворяет всем требованиям пользователей к содержимому базы данных. Перед проектированием базы необходимо провести обширные исследования требований пользователей к функционированию базы данных.
  • Гарантирует непротиворечивость и целостность данных. При проектировании таблиц нужно определить их атрибуты и некоторые правила, ограничивающие возможность ввода пользователем неверных значений. Для верификации данных перед непосредственной записью их в таблицу база данных должна осуществлять вызов правил модели данных и тем самым гарантировать сохранение целостности информации.
  • Обеспечивает естественное, легкое для восприятия структурирование информации. Качественное построение базы позволяет делать запросы к базе более «прозрачными» и легкими для понимания; следовательно, снижается вероятность внесения некорректных данных и улучшается качество сопровождения базы.
  • Удовлетворяет требованиям пользователей к производительности базы данных. При больших объемах информации вопросы сохранения производительности начинают играть главную роль, сразу «высвечивая» все недочеты этапа проектирования.

Следующие пункты представляют основные шаги проектирования базы данных:

  1. Определить информационные потребности базы данных.
  2. Проанализировать объекты реального мира, которые необходимо смоделировать в базе данных. Сформировать из этих объектов сущности и характеристики этих сущностей (например, для сущности «деталь» характеристиками могут быть «название», «цвет», «вес» и т.п.) и сформировать их список.
  3. Поставить в соответствие сущностям и характеристикам — таблицы и столбцы (поля) в нотации выбранной Вами СУБД (Paradox, dBase, FoxPro, Access, Clipper, InterBase, Sybase, Informix, Oracle и т.д.).
  4. Определить атрибуты, которые уникальным образом идентифицируют каждый объект.
  5. Выработать правила, которые будут устанавливать и поддерживать целостность данных.
  6. Установить связи между объектами (таблицами и столбцами), провести нормализацию таблиц.
  7. Спланировать вопросы надежности данных и, при необходимости, сохранения секретности информации.

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

Прежде чем подробно рассматривать каждый из этих шагов, остановимся на основных концепциях реляционных баз данных. В реляционной теории одним из главных является понятие отношения. Математически отношение определяется следующим образом. Пусть даны n множеств D1,D2. Dn. Тогда R есть отношение над этими множествами, если R есть множество упорядоченных наборов вида , где d1 — элемент из D1, d2 — элемент из D2, . dn — элемент из Dn. При этом наборы вида называются кортежами, а множества D1,D2. Dn — доменами. Каждый кортеж состоит из элементов, выбираемых из своих доменов. Эти элементы называются атрибутами, а их значения — значениями атрибутов. рис. ошибка! текст указанного стиля в документе отсутствует.-a представляет нам графическое изображение отношения с разных точек зрения.

Рис. Ошибка! Текст указанного стиля в документе отсутствует.-A: Термины реляционной теории и их соотношение с обработкой данных

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

  • отношение, таблица, файл (для локальных баз данных)
  • кортеж, строка, запись
  • атрибут, столбец, поле.

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

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

Смотрите так же:  Куда пожаловаться на детский сад тула

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

Для поддержания ссылочной целостности данных во многих СУБД имеется механизм так называемых внешних ключей. Смысл этого механизма состоит в том, что некоему атрибуту (или группе атрибутов) одного отношения назначается ссылка на первичный ключ другого отношения; тем самым закрепляются связи подчиненности между этими отношениями. При этом отношение, на первичный ключ которого ссылается внешний ключ другого отношения, называется master-отношением, или главным отношением; а отношение, от которого исходит ссылка, называется detail-отношением, или подчиненным отношением. После назначения такой ссылки СУБД имеет возможность автоматически отслеживать вопросы «ненарушения» связей между отношениями, а именно:

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

Замечание. Существует два подхода к удалению и изменению записей из главной таблицы:

  1. Запретить удаление всех записей, а также изменение первичных ключей главной таблицы, на которые имеются ссылки подчиненной таблицы.
  2. Распространить всякие изменения в первичном ключе главной таблицы на подчиненную таблицу, а именно:
    • если в главной таблице удалена запись, то в подчиненной таблице должны быть удалены все записи, ссылающиеся на удаляемую;
    • если в главной таблице изменен первичный ключ записи, то в подчиненной таблице должны быть изменены все внешние ключи записей, ссылающихся на изменяемую.

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

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

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

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

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

Формирование концептуальной модели базы данных включает в себя:

  • идентификацию функциональной деятельности Вашей предметной области. Например, если речь идет о деятельности предприятия, то в качестве функциональной деятельности можно идентифицировать ведение учета работающих, отгрузку продукции, оформление заказов и т.п.
  • идентификацию объектов, которые осуществляют эту функциональную деятельность, и формирование из их операций последовательности событий, которые помогут Вам идентифицировать все сущности и взаимосвязи между ними. Например, процесс «ведение учета работающих» идентифицирует такие сущности как РАБОТНИК, ПРОФЕССИЯ, ОТДЕЛ.
  • идентификацию характеристик этих сущностей. Например, сущность РАБОТНИК может включать такие характеристики как Идентификатор Работника, Фамилия, Имя, Отчество, Профессия, Зарплата.
  • идентификацию взаимосвязей между сущностями. Например, каким образом сущности РАБОТНИК, ПРОФЕССИЯ, ОТДЕЛ взаимодействуют друг с другом? Работник имеет одну профессию (для простоты!) и значится в одном отделе, в то время как в одном отделе может находиться много работников.

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

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

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

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

Эти правила включают:

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

VI. На шестом шаге устанавливаются связи между объектами (таблицами и столбцами) и производится очень важная операция для исключения избыточности данных — нормализация таблиц.

Каждый из различных типов связей должен быть смоделирован в базе данных. Существует несколько типов связей:

  • связь «один-к-одному»
  • связь «один-ко-многим»
  • связь «многие-ко-многим».

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

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

Связь «многие-ко-многим» в явном виде в реляционных базах данных не поддерживается. Однако имеется ряд способов косвенной реализации такой связи, которые с успехом возмещают ее отсутствие. Один из наиболее распространенных способов заключается во введении дополнительной таблицы, строки которой состоят из внешних ключей, ссылающихся на первичные ключи двух таблиц. Например, имеются две таблицы: КЛИЕНТ и ГРУППА_ИНТЕРЕСОВ. Один человек может быть включен в различные группы, в то время как группа может объединять различных людей. Для реализации такой связи «многие-ко-многим» вводится дополнительная таблица, назовем ее КЛИЕНТЫ_В_ГРУППЕ, строка которой будет иметь два внешних ключа: один будет ссылаться на первичный ключ в таблице КЛИЕНТ, а другой — на первичный ключ в таблице ГРУППА_ИНТЕРЕСОВ. Таким образом в таблицу КЛИЕНТЫ_В_ГРУППЕ можно записывать любое количество людей и любое количество групп.

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

После применения правил нормализации логические группы данных располагаются не более чем в одной таблице. Это дает следующие преимущества:

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

Процесс нормализации заключается в приведении таблиц в так называемые нормальные формы. Существует несколько видов нормальных форм: первая нормальная форма (1НФ), вторая нормальная форма (2НФ), третья нормальная форма (3НФ), нормальная форма Бойса-Кодда (НФБК), четвертая нормальная форма (4НФ), пятая нормальная форма (5НФ). С практической точки зрения, достаточно трех первых форм — следует учитывать время, необходимое системе для «соединения» таблиц при отображении их на экране. Поэтому мы ограничимся изучением процесса приведения отношений к первым трем формам.

Этот процесс включает:

  • устранение повторяющихся групп (приведение к 1НФ)
  • удаление частично зависимых атрибутов (приведение к 2НФ)
  • удаление транзитивно зависимых атрибутов (приведение к 3НФ).

Рассмотрим каждый из этих процессов подробней.

Приведение к первой нормальной форме

Когда поле в данной записи содержит более одного значения для каждого вхождения первичного ключа, такие группы данных называются повторяющимися группами. 1НФ не допускает наличия таких многозначных полей. Рассмотрим пример базы данных предприятия, содержащей таблицу ОТДЕЛ со следующими значениями (атрибут, выделенный курсивом, является первичным ключом):