Выбираем базу данных

Базовые и производные отношения

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

Домен

Домен описывает набор возможных значений для данного атрибута и может считаться ограничением на значение атрибута. Математически присоединение домена к атрибуту означает, что любое значение атрибута должно быть элементом указанного набора. Например, символьная строка «ABC» находится не в целочисленной области, а целочисленное значение 123 . Другой пример домена описывает возможные значения поля «CoinFace» как («Головы», «Решки»). Таким образом, поле CoinFace не принимает входные значения, такие как (0,1) или (H, T).

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

  • Фактографическая – содержит краткую информацию об объектах некоторой системы в строго фиксированном формате;
  • Документальная – содержит документы самого разного типа: текстовые, графические, звуковые, мультимедийные;
  • Распределённая – база данных, разные части которой хранятся на различных компьютерах, объединённых в сеть;
  • Централизованная – база данных, хранящихся на одном компьютере;
  • Реляционная – база данных с табличной организацией данных;
  • Неструктурированная (NoSQL) — база данных, в которой делается попытка решить проблемы масштабируемости и доступности за счёт атомарности (англ. atomicity) и согласованности данных, но не имеющих четкой (реляционной) структуры.

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

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

Задачи этого списка называются стандартными.

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

База данных в разных системах имеет различную структуру.

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

В БД содержатся банные некоторого множества объктов. Каждая запись содержит данные одного объекта. Каждая такая БД определяется именем файла, списком полей, шириной полей. Например, БД Школа (Ученик, Класс, Адрес).

Примером БД может служить расписание движения поездов или автобусов. Здесь каждая строчка – запись отражает данные строго одного объекта. База включает поля: номер рейса, маршрута следования, время отправления и т.д.

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

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

Объекты для работы с базами данных

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

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

В нашем случае эта триада реализуется в виде:

  • Table
  • DataSource
  • DBGrid

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

Однако, поскольку Table является невизуальным компонентом, хотя связь с базой и установлена, пользователь не в состоянии увидеть какие – либо данные. Поэтому необходимо добавить визуальные компоненты, отображающие эти данные. В нашем случае это сетка DBGrid. Сетка сама по себе «не знает», какие данные ей нужно отображать, её нужно подключить к Table, что и делается через компонент – посредник .

А зачем нужен компонент – посредник? Почему бы сразу не подключаться к Table?

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

Приложения баз данных – нить, связывающая БД и пользователя:

БД => набор данных –=> источник данных => визуальные компоненты => пользователь

Набор данных:

  • Table(таблица, навигационный доступ)
  • Query(запрос, реляционный доступ)

Визуальные компоненты:

  • Сетки DBGrid, DBCtrlGrid
  • Навигатор DBNavigator
  • Всяческие аналоги Lable, Editи т.д.
  • Компоненты подстановки

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

Эта модель организует данные в одну или несколько таблиц (или «отношений») столбцов и строк с уникальным ключом, идентифицирующим каждую строку. Строки также называются записями или кортежами . Столбцы также называются атрибутами. Как правило, каждая таблица / отношение представляет один «тип объекта» (например, покупателя или продукта). Строки представляют экземпляры этого типа объекта (например, «Ли» или «председатель»), а столбцы — значения, приписываемые этому экземпляру (например, адрес или цена).

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

Применение реляционной модели данных

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

База данных о подразделениях и сотрудниках предприятия

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

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

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

Операция деления

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

Запрос SQL

SELECT DISTINCT A1, A4 from R5 WHERENOT EXIST (SELECT * from R6 WHERE NOT EXIST
R6.A2 = R5.A2 AND
R6.A3 = R5.A3)

Давайте посмотрим, что получится в результате выполнения этой операции
реляционной алгебры и соответствующего ей запроса SQL. Даны два отношения R5 и R6:

R5 R6
A1 A2 A3 A4 A2 A3
2 S3 4 sun R4 8
3 X8 7 kab X8 7
3 R4 8 kab

Комбинации всех кортежей отношения R6 соответствуют вторая и третья строки
отношения R5. Но после исключения атрибутов (столбцов) А2 и А3 эти строки становятся идентичными.
Поэтому в новом отношении присутствует эта строка один раз. Новое отношение:

R
A1 A4
3 kab

История

Термин «реляционная база данных» был изобретен EF Codd в IBM в 1970 году. Кодд ввел этот термин в свою исследовательскую работу «Реляционная модель данных для больших общих банков данных». В этой и последующих статьях он определил, что он имел в виду под словом «реляционный». Одно хорошо известное определение того, что составляет систему реляционных баз данных, состоит из 12 правил Кодда . Однако никакие коммерческие реализации реляционной модели не соответствуют всем правилам Кодда, поэтому этот термин постепенно стал описывать более широкий класс систем баз данных, который как минимум:

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

В 1974 году IBM начала разработку System R , исследовательского проекта по разработке прототипа СУБД. Первой системой, проданной как РСУБД, была система Multics Relational Data Store (июнь 1976 г.). Oracle была выпущена в 1979 году компанией Relational Software, ныне Oracle Corporation .. Ingres и IBM BS12 . Другие примеры СУБД включают DB2 , SAP Sybase ASE и Informix . В 1984 году началась разработка первой СУБД для Macintosh под кодовым названием Silver Surfer, позже она была выпущена в 1987 году как 4th Dimension и известна сегодня как 4D.

Первые системы, которые были относительно точными реализациями реляционной модели, были от:

  • Мичиганский университет — Микро СУБД (1969)
  • Массачусетский технологический институт (1971)
  • Британский научный центр IBM в Питерли — IS1 (1970–72) и его преемник PRTV (1973–79)

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

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

По состоянию на 2009 год большинство коммерческих реляционных СУБД используют SQL в качестве языка запросов .

Были предложены и реализованы альтернативные языки запросов, в частности, реализация Ingres QUEL до 1996 года .

Другие модели баз данных (ООСУБД)

В последнее время на рынке СУБД появились продукты, представленные объектными и объектно-ориентированной моделью данных, такие как Gem Stone и Versant ОСУБД. Также производятся исследования в области многомерных и логических моделей данных.

Особенности объектно-ориентированных систем управления базами данных (ООСУБД):

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

А также поддержку классов объектов и наследование свойств и методов классов подклассами и их объектами.

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

Примеры ООСУБД:

  • D Gemstone;
  • IRS;
  • ORION;
  • ONTOS.

Применение ООСУБД:

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

Пожалуйста, оставляйте ваши отзывы по текущей теме статьи. За комментарии, отклики, дизлайки, лайки, подписки низкий вам поклон!

Модель ACID¶

Большинство реляционных баз данных реализует транзакционную модель. Акроним ACID содержит основные принципы такого подхода.

Атомарность (Atomicity)

Атомарность гарантирует, что никакая транзакция не будет зафиксирована в
системе частично. Будут либо выполнены все её подоперации, либо не выполнено ни
одной. Поскольку на практике невозможно одновременно и атомарно выполнить всю
последовательность операций внутри транзакции, вводится понятие «отката»
(rollback): если транзакцию не удаётся полностью завершить, результаты всех её
до сих пор произведённых действий будут отменены и система вернётся во «внешне
исходное» состояние — со стороны будет казаться, что транзакции и не было.
Сигнал завершения транзакции называется «фиксация» (commit).

Согласованность (Consistency)

Транзакция достигающая своего нормального завершения (EOT — end of transaction,
завершение транзакции) и, тем самым, фиксирующая свои результаты, сохраняет
согласованность базы данных. Другими словами, каждая успешная транзакция по
определению фиксирует только допустимые результаты. Это условие является
необходимым для поддержки четвёртого свойства.

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

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

Изолированность (Isolation)

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

  • Read uncommitted. Низший (нулевой) уровень изоляции. Он гарантирует только отсутствие потерянных обновлений Если несколько параллельных транзакций пытаются изменять одну и ту же строку таблицы, то в окончательном варианте строка будет иметь значение, определенное последней успешно выполненной транзакцией. При этом возможно считывание не только логически несогласованных данных, но и данных, изменения которых ещё не зафиксированы.
  • Read committed. На этом уровне обеспечивается защита от чернового, «грязного» чтения, тем не менее, в процессе работы одной транзакции другая может быть успешно завершена и сделанные ею изменения зафиксированы. В итоге первая транзакция будет работать с другим набором данных.
  • Repeatable Read. Уровень, при котором читающая транзакция «не видит» данные, которые были изменены но еще не зафиксированы другой транзакцией. При этом никакая другая транзакция не может изменять данные читаемые текущей транзакцией, пока та не окончена.
  • Serializable. Самый высокий уровень изолированности; транзакции полностью изолируются друг от друга, каждая выполняется так, как будто параллельных транзакций не существует. Только на этом уровне параллельные транзакции не подвержены эффекту «фантомного чтения» (ситуация, когда при повторном чтении в рамках одной транзакции одна и та же выборка дает разные множества строк).

Надежность (Durability)

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

Связывание таблиц

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

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

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

  • один к одному;
  • один ко многим;
  • многие ко многим.

Связи «один к одному» встречаются довольно редко. «Один ко многим» применяются чаще, например, кассир продаёт много билетов. «Многие ко многим» тоже встречаются часто. Например, студент изучает много предметов. Связи «многие ко многим» нельзя организовывать непосредственно. Для установления отношения необходимо сопоставить каждому primary key внешний ключ, который представляет собой primary key другой таблицы. Реляционные системы базируются на теории реляционной модели, которая включает в себя три аспекта:

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

Под их руководством:

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

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

Организация информации в реляционной базе данных

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

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

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

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

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

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

Узнать более подробно об организации информации в реляционных базах данных все желающие смогут в рамках профессиональной подготовки по курсу «Инструментальные средства бизнес-аналитики», которую проводит ВШБИ НИУ ВШЭ. Записаться на обучение по данному курсу можно на нашем сайте.

Как хранится информация в БД

В основе всей структуры хранения лежат три понятия:

  • База данных;
  • Таблица;
  • Запись.

База данных

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

Таблица

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

Запись

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

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

  • Создадим для сайта новую БД и дадим ей название «weather_diary».
  • Создадим в БД новую таблицу с именем «weather_log» и определим там следующие столбцы:
    • Город (тип: текст);
    • День (тип: дата);
    • Температура (тип: число);
    • Облачность (тип: число; от 0 (нет облачности) до 4 (полная облачность));
    • Были ли осадки (тип: истина или ложь);
    • Комментарий (тип: текст).
  • При сохранении формы будем добавлять в таблицу weather_log новую запись, и заполнять в ней все поля информацией из полей формы.

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

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

Английское слово „relation“ можно перевести как связь, отношение. А определение «реляционные базы данных» означает, что таблицы в этой БД могут вступать в отношения и находиться в связи между собой. Что это за связи? Например, одна таблица может ссылаться на другую таблицу. Это часто требуется, чтобы сократить объём и избежать дублирования информации. В сценарии с дневником погоды пользователь вводит название своего города. Это название сохраняется вместе с погодными данными. Но можно поступить иначе:

  • Создать новую таблицу с именем „cities“.
  • Все города в России известны, поэтому их все можно добавить в одну таблицу.
  • Переделать форму, изменив поле ввода города с текстового на поле типа «select», чтобы пользователь не вписывал город, а выбирал его из списка.
  • При сохранении погодной записи, в поле для города поставить ссылку на соответствующую запись из таблицы городов.

Так мы решим сразу две задачи:

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

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

Это интересно: Трудовая книжка

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

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

Основные компоненты реляционного отношения

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

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

Именованное множество пар «имя атрибута – имя домена» называется схемой отношения. Мощность этого множества — называют степенью или «арностью» отношения. Набор именованных схем отношений представляет из себя схему базы данных.

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector