Зачем нужны базы данных и реляционная модель
| English | Русский |
|---|---|
| table/ˈteɪbl/ | таблица |
| relational database/rɪˈleɪʃənl ˈdeɪtəbeɪs/ | реляционная база данных |
| flat files/flæt faɪlz/ | плоские файлы |
| data redundancy/ˈdeɪtə rɪˈdʌndənsi/ | избыточность данных |
| data inconsistency/ˈdeɪtə ˌɪnkənˈsɪstənsi/ | непоследовательность данных |
| integrity/ɪnˈteɡrɪti/ | целостность |
| field/fiːld/ | поле |
| entity/ˈentɪti/ | сущность |
| record/ˈrekɔːd/ | запись |
| tuple/ˈtuːpl/ | кортеж |
| attribute/ˈætrɪbjuːt/ | атрибут |
| primary key/ˈpraɪməri kiː/ | первичный ключ |
| composite key/ˈkɒmpəzɪt kiː/ | составной ключ |
| candidate key/ˈkændɪdeɪt kiː/ | кандидатский ключ |
| secondary key/ˈsekəndəri kiː/ | вторичный ключ |
| indexing/ˈɪndeksɪŋ/ | индексирование |
| foreign key/ˈfɒrən kiː/ | внешний ключ |
| referential integrity/ˌrefəˈrenʃl ɪnˈteɡrɪti/ | справочная целостность |
| one-to-many/wʌn tə ˈmeni/ | один-ко-многим |
| many-to-many/ˈmeni tə ˈmeni/ | многие-ко-многим |
Документ IBM, который она не хотела публиковать
- В 1970 году исследователь компании Эдгар Кодд опубликовал двенадцатистраничную статью, предлагая хранить данные в простых таблицах, связанных общими значениями, и запрашивать их на языке, указывающем что нужно получить, а не где это находится на диске.
- IBM уже продавала базу данных, хранящую данные в виде деревьев, привязанных к структуре файлов, поэтому игнорировала его на протяжении многих лет. Каждую программу, написанную против этих файлов, приходилось переписывать при любом изменении структуры.
- К 1980-м годам все банки, авиакомпании и правительственные ведомства переходили на таблицы Кодда. Полвека спустя они по-прежнему работают на них.
- Этот урок касается проблем подхода на основе файлов, того, как реляционная база данных решает их, и слов, которые необходимо использовать дословно.
Подход на основе файлов
- До появления баз данных каждая программа хранила собственные плоские файлы: программа продаж имела файл клиентов, бухгалтерская программа — отдельный, программа доставки — третий.
- Каждый файл имел фиксированную структуру, зависящую от кода программы, и ничего, находящегося вне программы, не знало, что в нем содержится.
- Это работает для одной небольшой программы. Трудности начинаются, когда вторая программа тоже нуждается в тех же данных.
Три программы — три копии клиента
Ограничения
- Избыточность данных: одни и те же данные (например, адрес клиента) хранятся в нескольких файлах, тратится место и усилия.
- Несоответствие данных: копии обновляются отдельно, поэтому расходятся, и никто не знает, какая версия верна.
- Зависимость данных: программы жестко привязаны к формату файла, поэтому изменение структуры требует переписьки каждой программы, использующей этот файл.
- Сложно обеспечить целостность, безопасно делиться данными, поиск по нескольким файлам медленный, а безопасность нельзя настроить на уровне поля.
Хранение адреса клиента в нескольких отдельных файлах приводит к:
Одни и те же данные, хранящиеся во многих местах (избыточность), могут обновляться отдельно и становиться несоответствующими.
В системе плоских файлов одни и те же данные часто дублируются между файлами, что может привести к несоответствиям при обновлении только одной копии.
Эта избыточность и вызванные ею несоответствия — основная проблема, которую решает реляционная модель.
Каковы ограничения подхода на основе файлов? Выберите все применимые варианты.
Избыточность, несогласованность и зависимость данных — три названные ограничения. Таблицы и соединения относятся к реляционному подходу, который им на смену.
Как реляционная база данных решает эти проблемы
- Реляционная база данных хранит данные в таблицах, управляемых одним программным обеспечением — DBMS, которое используют все программы.
- Каждый факт сохраняется один раз, поэтому исчезают избыточность и несоответствие: адрес меняется в одном месте, и все программы видят это изменение.
- Программы запрашивают данные у DBMS по имени, поэтому хранение может меняться без изменения программ: независимость данных
- Правила целостности, права доступа и резервное копирование обеспечиваются централизованно, и любую таблицу можно искать или связывать с любой другой.
Одна копия данных, один хранитель
Как реляционная база данных устраняет несогласованность данных?
Одна копия, одно обновление, отсутствие расхождений. СУБД предоставляет каждой программе одинаковое актуальное значение.
Словарь: таблицы, строки и столбцы
- Таблица (отношение) — это сетка из строк и столбцов; одна таблица для каждого типа сущности, объекта, о котором хранятся данные:
CUSTOMER,ORDER,PRODUCT. - Запись — это одна строка, один экземпляр сущности; формальный термин — кортеж.
- Поле — это один столбец, одна единица информации о каждой записи; формальный термин — атрибут.
Строки — это записи, столбцы — это поля, и один столбец выходит в другую таблицу
Чтение реляционной таблицы с помощью SELECT
Реляционная таблица состоит из строк (записей) и столбцов (полей). WHERE оставляет строки, соответствующие условию; SELECT оставляет только запрошенные столбцы.
Словарь: ключи
- Первичный ключ — это поле или набор полей, которые однозначно идентифицируют каждую запись; он никогда не может быть пустым и никогда не дублируется. Составной ключ — это первичный ключ, состоящий из двух или более полей.
- Кандидатский ключ — это любое поле или их сочетание, которое могло бы служить первичным ключом. Вторичный ключ — это непервичное поле, на которое создан индекс для быстрого поиска; индексирование создает индекс на поле, чтобы операции поиска и соединения выполнялись быстрее.
- Внешний ключ — это поле, значение которого совпадает с первичным ключом другой таблицы, связывая две таблицы. В сокращенной записи первичный ключ подчеркивается, а внешний ключ отмечается:
CUSTOMER(CustomerID, Name, Phone)
ORDER(OrderID, CustomerID, OrderDate) -- CustomerID is a foreign key → CUSTOMER
Первичный ключ:
Первичный ключ уникально идентифицирует каждую строку. Внешний ключ — это тот, который ссылается на другую таблицу.
Соотнесите каждый вид ключа с его определением.
Первичный ключ определяет строку; внешний ключ связывает с другой таблицей; составной = несколько полей вместе; кандидатский = возможный первичный ключ.
Поле, значение которого совпадает с первичным ключом другой таблицы, является ______ ключом.
Именно внешний ключ создает связь между двумя таблицами.
Разобранный пример: назовите части библиотечной базы данных
- Библиотека ведет учет своих книг, членов читательского зала и каждой выдачи. Определите сущности, первичные ключи для каждой и внешние ключи.
- Сущности:
BOOK,MEMBER,LOAN. Первичные ключи:BookID,MemberID,LoanID; каждый выбран потому, что он уникален для каждой записи и никогда не бывает пустым; название книги или имя человека не подходят, так как у нескольких книг может быть одинаковое название. LOAN(LoanID, BookID, MemberID, DateOut, DateDue):BookIDиMemberIDявляются внешними ключами, каждый из которых соответствует первичному ключу собственной таблицы. Телефонный номер читателя должен находиться вMEMBER, а не в каждой выдаче.
В LOAN(LoanID, BookID, MemberID, DateOut) BookID и MemberID являются ____ ключами.
Каждый из них соответствует первичному ключу другой таблицы, BOOK и MEMBER, и связывает кредит с ними.
Отношения и ссылочная целостность
- Отношение связывает две сущности. Один-к-одному: у каждого читателя одна библиотечная карточка. Один-ко-многим: у одного читателя много выдач; каждая выдача принадлежит одному читателю. Многие-ко-многим: у одной книги много авторов, а один автор пишет много книг.
- Ссылочная целостность означает, что каждое значение внешнего ключа должно соответствовать существующему первичному ключу в таблице, на которую оно ссылается: нет записей о выдачах для несуществующих читателей, нет «осиротевших» записей.
- СУББ обеспечивает эту целостность: она отказывает во вставке с неизвестным внешним ключом и запрещает удаление записи, на которую все еще ссылаются другие записи.
Целостность ссылочных данных гарантирует, что:
Она предотвращает появление «осиротевших» записей — вы не можете сослаться на первичный ключ, которого не существует.
Соотнесите каждый тип связи с её названием.
Посчитайте, сколько сущностей одной стороны могут быть связаны с одной сущностью другой стороны. Связь «многие-ко-многим» требует соединительной таблицы для хранения.
Разобранный пример: что предотвращает ссылочная целостность
- Из таблицы
CUSTOMERудаляется клиент с тремя невыполненными заказами. Объясните, как применяется ссылочная целостность. - Каждый
CustomerIDзаказа является внешним ключом, который должен соответствовать существующему клиенту. Удаление клиента оставит три заказа, указывающих на запись, которой больше не существует: осиротевшие записи. - Поэтому СУББ отказывает в удалении, пока заказы не будут удалены или переназначены, или, если настроено каскадное удаление, удаляет также и заказы. В любом случае ни один заказ никогда не будет ссылаться на несуществующего клиента.
- Опишите правило, что его нарушает и что делает СУББ.
Целостность ссылочных данных позволяет удалить клиента, пока записи в другой таблице всё ещё ссылаются на этого клиента.
Это создало бы «осиротевшие» записи. СУБМ отказывает в удалении или каскадно удаляет связанные заказы, чтобы каждый внешний ключ продолжал указывать на существующую запись.
Определения, принимаемые экзаменатором
| Термин | Определение |
|---|---|
| сущность | объект, о котором хранятся данные, представленный одной таблицей |
| атрибут | одна единица данных о сущности, столбец |
| кортеж | одна строка таблицы, одна запись |
| первичный ключ | атрибут или комбинация атрибутов, однозначно идентифицирующих каждый кортеж |
| кандидатский ключ | атрибут или их сочетание, которое могло бы быть выбрано в качестве первичного ключа |
| вторичный ключ | проиндексированный атрибут, используемый для быстрого поиска в таблице |
| внешний ключ | атрибут в одной таблице, являющийся первичным ключом другой таблицы, образующий связь |
| ссылочная целостность | каждое значение внешнего ключа ссылается на существующий первичный ключ |
Потерянные баллы
- Кортеж — это строка, атрибут — это столбец. Их перестановка стоит обоих баллов.
- Само слово «уникальный» не определяет первичный ключ; он идентифицирует каждую запись и никогда не бывает пустым.
- Внешний ключ может повторяться: один клиент, много заказов. Не может повторяться только первичный ключ.
- Вторичный ключ предназначен для быстрого поиска, а не для идентификации. Не называйте его «вторым первичным ключом».
Вы поняли
- Подход на основе файлов страдает от избыточности, несогласованности и зависимости данных, обладает слабой целостностью, возможностью совместного использования, поиском и безопасностью
- Реляционная база данных хранит каждый факт один раз в таблицах, управляемых одной СУББ, поэтому программы независимы от способа хранения, а правила обеспечиваются централизованно
- сущность → таблица · кортеж → запись, строка · атрибут → поле, столбец · первичный ключ идентифицирует, внешний ключ связывает, кандидатский мог бы идентифицировать, вторичный проиндексирован для поиска
- ссылочная целостность: каждый внешний ключ соответствует существующему первичному ключу, поэтому нет осиротевших записей