Дореляционные модели данных — студенческий портал



Бесплатный Видеокурс по PHP! Пример создания реального PHP-сайта с нуля! Подробнее

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

• Построить набор предварительных таблиц и указать первичные ключи.
• Провести процесс нормализации.

Первый пункт мы рассматривали в третьем уроке, со вторым мы пока не знакомы, но ознакомимся на практике.
Итак, нам надо построить набор таблиц. Сделать это несложно, т.к. таблицы — это наши объекты, а поля таблиц — атрибуты объектов.
Набор предварительных таблиц, исходя из нашей концептуальной модели, выглядит так:
Таким образом, у нас определены таблицы, поля, первичные ключи (РК) и связи (FK). Обратите внимание, в таблицах Журнал поставок и
Журнал покупок первичные ключи — составные, т.е. состоят из двух полей. Теоретически бывают таблицы, в которых все поля являются
одним составным ключом.

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

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

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

• 1НФ — первая нормальная форма
• 2НФ — вторая нормальная форма
• 3НФ — третья нормальная форма
• НФБК — нормальная форма Бойса-Кодда
• 4НФ — четвертая нормальная форма
• 5НФ — пятая нормальная форма

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

Первая нормальная форма

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

Вторая нормальная форма

Эта форма применяется к таблицам с составными ключами. Таблица, у которой первичный ключ включает только одно поле, всегда находится во 2НФ.
Таблица находится во второй нормальной форме, если она находится в первой нормальной форме, а каждое неключевое поле функционально
полно зависит от составного ключа.
В нашей базе данных две таблицы имеют составной ключ — Журнал покупок и Журнал поставок. Значение поля Количество зависит, как
от Поставки (Покупки), так и от Товара. Значит, наши таблицы находятся во 2НФ.
Но предположим, что на этапе концептуального моделирования нашей базы данных, мы не выделили объекты Поставка и Покупка. Тогда наши таблицы
могли бы выглядеть так:
Посмотрим теперь на таблицу Журнал поставок: поле Количество зависит от Наименования товара и от Даты поставки,
но не зависит от того, кто поставил товар (поле Поставщика). Т.е. таблица не находится во 2НФ. Если бы на этапе концептуального
моделирования нашей базы данных, мы не выделили объекты Поставка и Покупка, нам бы пришлось это делать сейчас. Но мы их выделили,
поэтому все наши таблицы находятся во 2НФ.

Третья нормальная форма

Таблица находится в третьей нормальной форме, если она находится во второй нормальной форме, и каждое неключевое поле нетранзитивно
зависит от первичного ключа.
Транзитивная зависимость наблюдается в том случае, если одно из двух неключевых полей зависит от первичного ключа, а другое
зависит от первого неключевого поля. На примере будет понятнее.
Посмотрим на нашу таблицу Товар. В ней есть поле Цена, но цены, как известно, имеют свойство меняться. Если мы будем их менять
прямо здесь, то будет пропадать вся информация о предыдущих ценах. Чтобы не терять эту информацию, надо добавить поле Дата
(когда изменилась цена). Тогда наша таблица будет выглядеть так:
Даже не прибегая к 3НФ видно, что такая таблица будет содержать избыточную информацию. Но посмотрим на ее поля: поля Наименование
и Дата зависят от id товара, а поле Цена зависит также и от Даты. Т.е. таблица не находится в 3НФ. Для устранения транзитивной
зависимости необходимо провести «расщепление» объекта на два:
Все остальные таблицы нашей базы данных находятся в 3НФ. Кстати, в таблице Товар можно было и не вводить поле id товара, а сделать
первичным ключом поле Наименование, но как уже говорилось в третьем уроке суррогатные ключи все-таки предпочтительнее.
Подведем итог. Схема нашей базы данных после нормализации несколько изменилась и выглядит теперь так:
Таким образом, мы преобразовали нашу концептуальную модель в реляционную. Дальше необходимо эту модель реализовать в
конкретной СУБД. Для этого нам понадобится сама СУБД и знание языка SQL. Этим вопросам будут посвящены Уроки SQL.
А пока подведем итог уроков «Основы БД». Проектирование БД процесс, как правило, трудоемкий и небыстрый. Ведь нужно очень
хорошо изучить предметную область, чтобы учесть все нюансы, пожелания и требования пользователей. Затем всю собранную
информацию изобразить в виде объектов, атрибутов и связей. Причем сделать это надо наиболее рационально.
Вообще, среди разработчиков наблюдаются различные взгляды на процесс проектирования БД. Одни игнорируют всякую теорию
и руководствуются только своим опытом и здравым смыслом. Другие считают этот процесс искусством, отводя главную роль интуиции.
Но в любом случае, знания не бывают лишними. И если вы к интуиции и здравому смыслу добавите теорию, то результат будет гораздо
лучше.
Да, база данных — это всего лишь хранилище данных, но от того насколько грамотно вы организуете это хранилище,
будет зависеть работа вашего приложения, использующего данные. Помните об этом и не пренебрегайте теорией.
В заключение хотелось бы напомнить, зачем вообще вам нужно уметь проектировать базы данных. Предположим, вы решили организовать
у себя на сайте регистрацию пользователей с тем, чтобы обеспечить им доступ к закрытым материалам сайта.
Для реализации этого вопроса вам потребуется создать БД, которая будет хранить информацию о пользователях, их логинах и паролях.
А также сделать html-формы регистрации и входа в закрытый раздел. Когда пользователь регистрируется, эти данные программными
средствами (например, с помощью языка PHP) заносятся в созданную вами БД. Когда пользователь вводит логин и пароль в форме
входа в закрытый раздел, к базе данных отправляется запрос (на языке SQL), есть ли пользователь с такими данными. И если
ответ положительный, то пользователю посылается запрашиваемая страница (разумеется тоже с помощью программы на PHP).
Таким образом, чтобы реализовывать такие приложения вам необходимо уметь создавать БД, строить запросы на языке SQL к БД и знать
какой-нибудь язык программирования, применимый для разработки динамических web-страниц (например, PHP).
В принципе, вы можете сначала изучить язык программирования, а потом изучать БД и SQL. Но на этом сайте обучение построено
в следующем порядке: БД — SQL — PHP. Сделано это потому, что без баз данных ничего интересного на PHP сделать не удастся.
Поэтому до встречи в Уроках SQL.

Перед тем, как переходить к уроках SQL, вам потребуется установить сервер MySQL. В принципе вы можете установить только его,
но для полноценной дальнейшей работы вам понадобится интерфейс phpMyAdmin, а для работы с ним — модуль PHP и локальный сервер.

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

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

Предыдущий урок Вернуться в раздел 

Если этот сайт оказался вам полезен, пожалуйста, посмотрите другие наши статьи и разделы.

Код кнопки:

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

Источник: https://www.site-do.ru/db/db5.php

Информатика и вычислительная техника

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

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

         С БД взаимодействуют следующие категории лиц:

1.          пользователи (вводят и извлекают данные);
2.          программисты (пишут и отлаживают программы обработки данных);
3.          администраторы БД (отвечают за проектирование, реализацию, эксплуатацию и сопровождение БД).

    Рис. 1.  Структура БД.

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

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

Личное дело № 16493, Сергеев Петр Михайлович, дата рождения 1 января 1976 г.; л/д 1 16593 Петров Анатолий Владимирович, дата  рождения 15 марта 1975 г.

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

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

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

№ личного дела	Фамилия	Имя	Отчество	Дата рождения
16493 16593	Сергеев Петров	Петр Анатолий	Михайлович Владимирович	1.01.1976

Источник: https://moodle.kstu.ru/mod/book/view.php?id=11619&chapterid=252&lang=ja

Ранние (дореляционные) СУБД

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

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

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

b) Все ранние системы не основывались на каких-либо абстрактных моделях. Понятие модели данных фактически вошло в обиход специалистов в области БД только вместе с реляционным подходом. Абстрактные представления ранних систем появились позже на основе анализа и выявления общих признаков у различных конкретных систем.

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

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

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

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

Не нашли то, что искали? Воспользуйтесь поиском:

Источник: https://studopedia.ru/3_74710_rannie-dorelyatsionnie-subd.html

Реляционно-сетевая модель данных

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

Первая проблема – низкая эффективность для больших данных (big data). Источниками больших данных являются социальные сети, системы видеонаблюдения, пространственные сенсоры, биллинг и т.п.

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

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

Второе – поиск, вычисление запросов в РБД с таблицами огромных размеров – это задача высокой алгоритмической сложности.

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

Третий недостаток РБД вытекает из жестких требований к схемам данных в рамках канонических «нормальных форм».

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

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

«Красота» и строгость реляционной модели, реализуемой на SQL, на протяжении 3-х десятков лет восхищали программистов. «Старые» модели: сетевая или иерархическая были почти забыты. Да программных продуктов таких почти не осталось, за исключением, пожалуй, «почти бессмертной» IDMS [1].

В последнее десятилетие идет активная работа по созданию альтернативных систем управления БД (СУБД), которые так просто и называются – NoSQL. Под это понятие сейчас подпадают очень разные системы, которые сильно отличаются между собой. Интересно, что «старые» сетевая и иерархическая модели в понятие NoSQL не входят! Хорошие обзоры в этой области можно найти в [2,3,4].

В категорию NoSQL включают «графовые» БД [5], которые абстрактно близки к канонической сетевой модели CODASYL [6]. Как и следует из самого названия, такие системы представляют собой два неорганизованных множества – узлы (вершины) и ребра (дуги).

Главное преимущество сетевых БД – навигация «определяется» не в момент обработки запроса, как в РБД, а в момент добавления новых данных (для графов — вершин и ребер), полностью справедливо и для графовых систем.

Но графовая БД не структурирована до начала ее наполнения, в отличие от БД по CODASYL.

NoSQL системы, как правило, работают на базе распределенных файловых систем, обеспечивающих масштабируемость и надежность [9].

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

Источник: https://habr.com/post/462025/

Реляционная модель данных: теоретические основы

Реляционная модель данных — созданная Эдгаром Коддом логическая модель данных, описывающая:

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

Эдгар Франк «Тед» Кодд — (23 августа 1923 —18 апреля 2003) — британский учёный, работы которого заложили основы теории реляционных баз данных. Работая в компании IBM, он создал реляционную модель данных. В 1970 издал работу «A Relational Model of Data for Large Shared Data Banks», которая считается первой работой по реляционной модели данных.

Реляционная модель данных — это способ рассмотрения данных, то есть предписание для способа представления данных (посредством таблиц) и для способа работы с таким представлением (посредством операторов). Она связана с тремя аспектами данных: структурой (объекты), целостностью и обработкой данных (операторы).

В 2002 журнал Forbes поместил реляционную модель данных в список важнейших инноваций последних 85 лет.

Цели создания реляционной модели данных:

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

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

отношение;

атрибут;

домен;

кортеж;

степень;

кардинальность;

первичный ключ.

Отношение — это плоская (двумерная) таблица, состоящая из столбцов и строк:

ID	Фамилия	Имя	Должность	г.р.
1	Петров	Игорь	Директор	1968
2	Иванов	Олег	Юрист	1973
3	Ким	Елена	Бухгалтер	1980
4	Сенин	Илья	Менеджер	1981
5	Васин	Сергей	Менеджер	1978

Атрибут — это поименованный столбец отношения.

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

Кортеж — это строка отношения.

Степень определяется количеством атрибутов, которое оно содержит

Кардинальность — это количество кортежей, которое содержит отношение.

Первичный ключ — это уникальный идентификатор для таблицы.

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

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

Отношение R на множестве доменов D1, D2, …, Dn — это подмножество декартова произведения этих доменов:

R ⊆ D1 × D2 × … × Dn

Пример 1. Определены домены: D1 — множество фамилий преподавателей, D2 — множество аудиторий, D3 — множество учебных групп, D4 — множество учебных дисциплин. Записать отношения: 1) закрепление преподавателей за учебными курсами; 2) расписание занятий в группах.

• Решение.
• 1) закрепление преподавателей за учебными курсами:
• R ⊆ D1 × D4.
• Это отношение определяет множество преподавателей, ведущих множество учебных дисциплин.
• 2) расписание занятий в группах:
• R ⊆ D2 × D3 × D4.
• Это отношение определяет множество аудиторий, в которых проводятся занятия по множеству учебных дисциплин для множества учебных групп.

Свойства отношений:

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

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

Виды отношений:

• именованное отношение;
• базовое отношение;
• производное отношение;
• выражаемое отношение;
• представление (view);
• снимки (snapshot);
• результат запроса;
• промежуточный результат.

Именованное отношение — это переменная отношения, определённая в СУБД (системе управления базами данных) посредством оператора CREATE (CREATE TABLE, CREATE BASE RELATION, CREATE VIEW, CREATE SNAPSHOT).

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

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

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

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

Множество всех выражаемых отношений — это множество всех базовых и всех производных отношений.

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

Результат запроса — это неименованное производное отношение. СУБД не обеспечивает постоянного существования результатов запросов. Для сохранения результата запроса его можно присвоить какому-либо именованному отношению.

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

Ключи отношения могут быть следующми:

• суперключ;
• потенциальный ключ;
• первичный ключ;
• внешний ключ;
• суррогатный ключ.

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

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

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

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

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

В отношении может быть больше одного потенциального ключа.

Первичный ключ (primary key, PK) — это один из потенциальных ключей отношения, выбранный в качестве основного ключа. Допустимо объявление одного и только одного первичного ключа. Атрибуты первичного ключа не могут принимать значения Null.

Внешний ключ (foreign key, FK) — это ключ, объявленный в базовом отношении, который при этом ссылается на первичный того же самого или какого-то другого базового отношения.

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

В таблице наличие есть поля: «Аптека» (в ней — идентификаторы аптек), «Препарат» (в ней — идентификаторы препаратов), «Количество».

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

Решение. Можно объявить первичным ключём таблицы «Наличие» составной ключ, состоящий из идентификатора аптеки и идентификатора препарата. Тогда в таблице невозможно повторение в разных записях сочетания аптеки и прапарата. Первичный ключ может быть не только простым, но и составным.

Понятия реляционной целостности:

• определитель NULL;
• целостность сущностей;
• ссылочная целостность;
• корпоративные ограничения целостности.

Определитель NULL. Значение Null обозначает тот факт, что значение не определено. Null не принадлежит никакому типу данных и может присутствовать среди значений любого атрибута, определенного на любом типе данных. Двуместная «арифметическая» операция с Null даёт Null. Операция сравнения с Null даёт UNKNOWN.

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

Ссылочная целостность.

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

Ссылочная целостность: удаление кортежа. Существует три подхода удаления кортежа из отношения, на которое ведет ссылка.

1. Ограничение удаления–Delete: Restrict.
2. Каскадное удаление–Delete: Cascade.
3. Установка значения NULL, перевод значения внешнего ключа в неопределённое состояние – Delete: Set NULL.

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

Каскадное удаление. При удалении кортежа из отношения, на которое ведет ссылка, из ссылающегося отношения автоматически удаляются все ссылающиеся кортежи.

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

Пример 3. Есть база данных портала новостей. В ней есть таблица «Рубрики» (политика, экономика, спорт и т.д), есть таблица «Автора» (фамилии и имена авторов).

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

Решение. Первый способ: установить запрет на удаление рубрики или автора из соответствующих таблиц, в случае, если в таблицы «Тексты» есть ссылки на эту рубрику или на этого автора.

Второй способ: задать автоматическое удаление из таблицы «Тексты» записей, в которой фигурируют эта рубрика или этот автор.

Третий способ: в случае удаления рубрики или автора из соответствующих таблиц в ссылающихся кортежах таблицы «Тексты» значения идентификатора этой рубрики или этого автора становятся неопределёнными (NULL).

Как это делается на уровне языка запросов SQL — в материале SQL ALTER TABLE — изменение таблицы базы данных.

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

Поделиться с друзьями

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

Источник: https://function-x.ru/sql_relation_data_model.html

Реляционная модель данных / Основы реляционных баз данных

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

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

Если вы захотите копнуть глубже, то смотрите ссылки в дополнительных материалах.

Иерархическая модель

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

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

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

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

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

Проблемы начинаются, когда у одного ребёнка может быть несколько родителей.

В современных сервисах такси есть возможность оплачивать счёт за такси совместно — это значит, что у одного заказа сразу несколько клиентов.

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

Сетевая модель

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

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

Реляционная модель

Для прохождения курса необходима подписка
Получить доступ к курсу

Источник: https://ru.hexlet.io/courses/rdb-basics/lessons/relations/theory_unit

19. Реляционная модель данных

• Рассмотрим
  реляционную
  модель данных,
  в которой данные хранятся в виде двумерных
  таблиц.
• Таблицы
  обладают следующими свойствами:
• —
  каждая ячейка таблицы является одним
  элементом данных;

—
каждый столбец содержит данные одного
типа (числа, текст и т. п.);

1. —
   каждый столбец имеет уникальное имя;
2. —
   таблицы организуются так, чтобы одинаковые
   строки отсутствовали;
3. —
   порядок следования строк и столбцов
   произвольный.
4. Для
   идентификации записей выделяют следующие
   виды ключей – полей, определяющих
   запись:
5. —
   первичный: однозначно определяет запись;
6. —
   вторичный: выполняет роль поисковых и
   группировочных признаков и позволяет
   найти несколько записей.
7. Первичный
   ключ
   должен обладать следующими свойствами:
8. —
   уникальность: не должно существовать
   двух или более записей, имеющих одинаковые
   значения полей, входящих в первичный
   ключ;
9. —
   не избыточность: первичный ключ не
   должен содержать поля, удаление которых
   из ключа не нарушит его уникальность
10. (пиши
    ВСЕ, ЧТО ВЫШЕ, а потом можешь взять пример
    из текста ниже)
11. ___________________________________________________________________________

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

Структура
реляционной модели данных:

• структурная
• манипуляционная
• целостная

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

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

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

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

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

Структура
реляционной модели данных

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

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

Например,
связь между отношениями ОТДЕЛ и СОТРУДНИК
создается путем копирования первичного
ключа «Номер_отдела» из первого
отношения во второе. Таким образом:

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

1. из таблицы ОТДЕЛ установить значение атрибута «Номер_отдела», соответствующее данному «Наименованию_отдела»

2. выбрать из таблицы СОТРУДНИК все записи, значение атрибута «Номер_отдела» которых равно полученному на предыдущем шаге

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

1. определяем «Номер_отдела» из таблицы СОТРУДНИК

2. по полученному значению находим запись в таблице ОТДЕЛ

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

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

Недостатки
реляционной модели:

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

Источник: https://studfile.net/preview/1677090/